1章 監視のアンチパターン

アンチパターン1 ツール依存

監視とは単一の問題ではない
つまり、一つのツールで解決できる問題ではないということ
以下のような汎用的あるいは専門化されたツールが必要になる

• コードレベルでアプリケーションをプロファイリングしたり、監視するなら、APMツールやアプリケーション自身による計測(StatsDなど)
• クラウドインフラを監視するなら、モダンなサーバ監視ツールソリューション
• スパニングツリーのトポロジ変更やルーティングの更新を監視するなら、ネットワークに焦点を当てたツール

成熟された環境では、汎用的なツールと専門化されたツールを組み合わせればいい

ツールは賢く注意深く選ぶべきで、かつツールが必要なら増やすのを怖がらなくてもよい

ツールの知名度が高いだけという理由で採用してはいけない
誰かが使っている、使ったことある理由だけで選ぶのではなく、評価し、試す
ツールで実現できることと、チームが苦痛なく実現できることが一致しうまく動くようにすることが重要

やりたいことを実現するツールがない場合は自分たちで作る場合がある

アンチパターン2 役割としての監視

監視の責任を一人に押し付けてしまうのはアンチパターン
チームのみんなが監視について責任を持つことを主張する

アンチパターン3 チェックボックス監視

チェックボックス監視とは、「これを監視しています」と言うための監視システム
監視の仕組みは非効率で、うるさく、信用できず、監視の仕組みがないよりもひどいものになる

このアンチパターンを直すには以下の方法がある

• 「動いている」とはどういう意味か。「動いている」かどうかを監視する
  • 200が返ってきているか
  • レイテンシが小さいか
  • ページに特定の文字列があるか
• アラートに関しては、OSのメトリクスはあまり意味ない
  • CPUの使用率が高いからといって、レスポンスタイムが許容範囲に収まっていれば問題ない
• メトリクスをもっと高頻度で取得する
  • 最低でも60秒に一回はメトリクスを取得する
    • トラフィックが多いシステムならもっと高頻度に取得する

アンチパターン4 監視を支えにする

壊れやすいアプリケーションを運用していて、何かが壊れたらそれに関する監視を追加するのはだめ
監視を増やして行くのではなく、アプリケーションの安定化などに時間を使うべき

アンチパターン5 手動設定

監視設定は100%自動化するべき
各サービスに誰かが設定を追加するのではなく、勝手に追加されるようにする