「グリー開発本部 Meetup #3 モニタリング」行ってきました
先日『入門 監視』を読み終えた直後かつ業務的にもモニタリングを設定しているところで、モニタリングが熱いのでこちらの勉強会に行ってきました。
詳細な内容はそれぞれスライドが公開されていますので、雑感を軽く。
アラートを減らしている話
GREE 小林 裕明さん @kobtea
『入門 監視』でもモニタリングを進めたら、その中でやることの一つとして、自動復旧に触れられています。GREEでの実践についての話でした。
所感とよかった質疑応答は以下
- アラート管理のミドルウェアが自前であるのが印象的。羨ましい
- 復旧の手順書から自動復旧手順を考える、という流れは地道で素敵だった
- 自動復旧はあくまで恒久対応ではない。忘れないようにしたい
- 自動復旧の実装はシンプルに。これも重要。つい凝っちゃう気がする
- 質疑応答
質問:自動復旧はどのくらいやったのか
回答:数は多くないが、対処できたアラートの数は非常に多い
自動復旧というちょっと印象的な項目の地に足のついた実践を見せていただきました。
監視の目的とは何か問いかけよう
GitHub 松浦 隼人さん (『入門 監視』訳者) @dblmkt
入門監視を訳すまでの流れと監視に興味を持ったきっかけ、入門監視のポイントを説明でした。
以下、所感。すでに読み込んでいたので少な目ですが。
- 入門監視 すでに4刷。すごい!
- 監視とバックアップは似てる。普段気にしない。いざという時に困る。しかも動かない。わかりすぎる。
- 入門監視の中でも、監視担当を作るな、という提言はやはり刺さる。書籍の中ではインフラ部門の人が担当になるから、アプリケーションの人も見るべき、という流れですが、アプリチームもKibanaなりNewRelicなりで見てても、決まった人が対応してる、というのはあるあるなような
sysloadや監視などの話
GREE 瀬島 貴則さん
社内監視基盤についての思い出話から、独自メトリクスsysloadの話まで。
所感は以下。
- 圧倒されました。低レイヤまで本質的に理解しているエンジニアの強さを思い知りました。メトリクスがおかしかったら、カーネルのコードを追い、メモリ処理の正確な理解から、問題となる処理のあたりをつける。かくありたいものだなあと。
- 本質的に理解をしている人ならば、原因の本質に迫るために数百のメトリクスも必要になる。これは目から鱗。自分ではメトリクスは絞るべきだと考えていたので。ただ、そのために自分含めレベル上げが必須
- 紹介されたsysloadはそういったまだレベルが足りない人のためのメトリクスだった。機会があれば使ってみたい。
それぞれ別のレベルでモニタリングについて話が聞けて面白かったです。GREEの運営の方々もありがとうございました。
うちの会社から自分以外にも二人参加していて、初めて顔を合わせたのでプチオフ会見たいで楽しかったです。次回はちゃんと社外の方とも交流したいところです。