はじめに
2017/1/26に MackrelMeetUP #9 をレコチョクで開催されました。
多く方が来場されていて、Mackerelの注目の高さを改めて感じました。
ご来場いただいた皆様、レコチョクで開催をして頂きましたはてなさん、ありがとうございました。
全体的なMackerel MeetUPのレポートは、はてなさんのMackerel ブログで見て頂くとよいかと思います。
さて、レコチョクでは、Mackerel x Twilio ~レコチョクの場合~と題して、
伊藤・鷹箸組のダブルスで登壇をさせて頂きました。
- 伊藤パート 既存の監視方式と課題、そしてMackerel導入してどうなったか
- 鷹箸パート Mackerel x Twilio 連携についてと今後の展開
簡単ですが、伊藤パートについて、お話しした内容についてお伝えします。
既存の監視
監視対象は、AWSで、AWSアカウントがシステム単位で100以上あって、DevOpsで開発・運用するぞということで、システム担当もいっぱいいて、
という環境をZabbixで監視しています。そして、Zabbixは、一元管理です。
Zabbixを管理する側としては、
AWSだから、スケールするだろうし、トライ&エラーで作ったり消したりするだろうし、まあ、スピード感に追いつくのは難しいなーと。
なので、エージェントレスで、監視対象側からアラート受け口をシンプルに準備して、アラートを待ち受けています。
そして、グラフは、割り切って、Cloudwatchに任せました。
そんなこともあり、余談ですが、
Mackerelプロデューサーの杉山さんが『The 2017 Mackerel Product Roadmap.』の中でお話ししていた。
運用ツールもクラウドへ。
これは、すごくささりました。登壇前で、そわそわしてたんですが、ささりました。
既存の課題
まあまあ、課題はありまして。
監視設定もシステム担当でやった方がスピード感出るじゃないか。
そして、グラフは、システム間で情報共有を簡単にできるといいじゃないか。
でも、どっちも実現するには、既存の監視だと苦しい。。。
っていう運用管理と監視ツールの問題と、各システム担当がアラート設計しなきゃなんだけど、
DevOpsに振り切ったものの、開発よりの担当が多くて。。。
という、監視レベルが標準化されていない（システム的、人的に）問題があり。
ということで、
各システム担当で監視設定できて、グラフも簡単に共有できて、設定とかいい感じで横展開しやすいやつないかなー。
となりまして、監視ツールもクラウドへ ってことで、Mackerelを導入してみたわけです。
Mackerel導入して
Organizationをシステム単位で作成するルールにすることで、設定は、そこのシステム担当で。
必要があれば、他システム担当（場合によっては、サービス担当）をリード権限で招待すれば、情報共有OK。
ってところで、Mackerel導入することで、運用管理と監視ツールの問題は、クリア！！
監視レベルが標準化されていないってところは、Mackerel導入導入しただけでは何も解決するわけではないので、
ガイドラインを作って、最低限の監視テンプレ的なのを作って、mkrコマンドで、横展開 ← これは、これからの課題だけど。
というところで、私の話は終了です。
この記事を書いた人
- FootballとBeerを愛するおじさんです。