この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
こんにちは、協栄情報のきおかです。
最近は監視に関して勉強していまして、備忘録的に監視のアンチパターンについて書こうと思います。
アンチパターンとは
『一見よいアイディアだが、実装すると手痛いしっぺ返しを食らうもの』
監視アンチパターン
1. ツールに依存する
何をやるか>>>>ツール選定
何をやるか>>>>課題に人員を配置
リソースベースの、特にツールベースでの対応は、そのリソースやツールの特性に縛られるために、本質的な課題解決にはならない。
「監視」とは複雑な問題を一括りに呼称するものである。それぞれのレイヤー・レベルで汎用的あるいは専門的なツールが必要。
必要であれば自分でツールを作る。ただし、これは全く新しい監視プラットフォームを作るわけではなく、小さく、何かに特化したツールを作るということ。
⇒ツール駆動ではなくミッション駆動
何をやるか？→Aレベルでは何をやるか？Bレベルでは何をやるか？…→Aレベルではどのツールを使うべきか？…
2. 監視を「専門」とする
ログ収集の専門家、Solarisサーバ管理の専門家、その他監視の仕組みを構成・管理する人、、、
これらは効率的な仕組みではない。
構成管理ツールやDBサーバーの管理方法に専門家がいないように、監視もチームメンバー皆がある程度のレベルに至っておくべき。
監視は全員がやるべき仕事。
監視は専門家ではなく分散されるべき。監視ツールの作成や提供に責任を持つ人やチームは作っていいが、監視の全責任を一人の肩に置くのはアンチパターン。
3. チェックボックス的に監視する
１と似てる。やることリストは課題に本質的に効果的か？
例えばCPU使用率が高かったとして、それは「アラート」であるべきか？MySQLが継続的にCPUを全部使っていたとして、レスポンスタイムが許容範囲に収まっているのなら何も問題はない。
CPUやメモリ使用率のような低レベルなメトリクスよりも「動いているか」が重要。
メトリクスを高頻度で収集することも大事。30秒毎にレイテンシが跳ね上がっていたとして、5分に1回の取得では見逃してしまう。
多少の追加は負荷にならないので気にせず高頻度で取得する。ただしディスクの圧迫は十分にあるので、データの間引き設定(roll-up)を行う。
4. 監視を支えにする
監視はあくまで問題通知が仕事であり、本質はその後の問題解決・状態修正である。
監視を増やしても問題が解決するわけではないことに留意する。
5. 手動設定
監視設定は100%自動化すべき。
筆者がコンサルするケースでよくあるのは、監視そのものよりも監視の設定にコストがかかっているケースらしい。
まとめ
以上、監視のアンチパターンでした。監視は特にケースバイケースで様態が変わるでしょうから、初学者には捉えがたいと感じますね。
次回は監視のデザインパターンについてまとめます。
それでは。
参考書籍
M. Julian, Practical Monitoring: Effective Strategies for the Real World. Translated by 松浦隼人, Tokyo, Japan: オライリー・ジャパン, 2019. (Original work published 2017)