はじめに

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コマンドで、横展開　←　これは、これからの課題だけど。

というところで、私の話は終了です。