Mackerel Meetup #9に登壇させて頂きました!(これまでの課題とMackerelを導入して)

Mackerel, イベントレポート

この記事は最終更新日から1年以上が経過しています。

はじめに

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を愛するおじさんです。

Mackerel, イベントレポート