1年ほど積読にしてた「入門監視」を読み終えました。
この本は監視ツール個別の話はほとんどなく、監視をどう設計すべきかが記されています。 私自身、監視を色々見たり設定したりしてきましたが、考え方の答え合わせができて楽しかったです。
まずはアンチパターンをチェックする
この本を買う前に1章だけでもみてもらって、自分がアンチパターンにハマっていないかを是非チェックして欲しいと思います。
流行りのツールにOSメトリクスでとりあえずアラート仕掛けたりしていた自分には胸をえぐられる章でした。 心当たりのある人は目次を見ただけでもグッとくると思います。
1.1 アンチパターン1：ツール依存
1.1.1 監視とは複雑な問題をひとくくりにしたもの
1.1.2 カーゴ・カルトなツールを避ける
1.1.3 自分でツールを作らなければならない時もある
1.1.4 「一目で分かる」は迷信
1.2 アンチパターン2：役割としての監視
1.3 アンチパターン3：チェックボックス監視
1.3.1 「動いている」とはどういう意味か。「動いている」かどうかを監視しよう
1.3.2 アラートに関しては、OSのメトリクスはあまり意味がない
1.3.3 メトリクスをもっと高頻度で取得しよう
1.4 アンチパターン4：監視を支えにする
1.5 アンチパターン5：手動設定
自分の経験を答え合わせをする
自分はこれまでWebシステムを中心に監視の設定を見たり行ったりしてきました。 世の中には色々なシステムがあり、色々な事情もあるとは思いますが、これまで経験してきた監視の経験を本書で答え合わせをしてみました。
所属組織の標準的な監視パッケージに乗っかったこともあれば、自分で1から設計したこともあります。
どこかで見聞きしたものなのかも忘れましたが、自分で監視を設計するときは下記のポリシーを大切にしてきました。
- 利用者より先に気づく事
- ユーザーの実際の不便を監視する事
「動いている」を監視する
サービスが元気に動き続けることがベストではありますが落ちることも必ずあるのがシステムの世界です。そんな時にサービスの不調にいち早く気づくことが監視の一番の役目であると考えています。
なのでURL監視を中心とした監視を組みつつ、可能であればビジネス的に一番熱いユースケースやユーザーの不便に最もつながりそうなユースケース、 つまりユーザーの信頼を失うことにつながりそうなユースケースを実際にトレースするような監視を作ってきました。
また、この監視が動いていればとりあえずシステムとしては健全であるというラインが担保できていると、システム運用にかかるストレスが非常に低減されます。
例えばポイント系のシステムでポイント付与までのユーザーの行動をトレースするようなものを、ユーザー登録が命のようなサービスであれば実際にユーザー登録を行うようなものを外部から実際に自動的に行うような監視を行ったりしました。
なので本書でいう「動いている」を監視できていたと思います。
お手製の監視システムでOSメトリクスを監視
一方で、OSのメトリクスに関してはついついCPU 80%とかロードアベレージ10とかを閾値とした監視を手癖のように設定しがちではありました。振り返ってみてもCPUやロードアベレージなどのメトリクスによるアラートにより実際に行動を起こす事は少なく、 URL監視などの外形監視の補助として使うことが多いです。
そして監視ツールの選定ですが、監視Saasが成熟してきている今日、未だに本格導入を試みたことがありません。AWSだとCloud Watchをベースにした監視などを行ったことはありますが、当時はカスタマイズ性にいまいち満足がいかなかったという記憶があります。 そういった古い記憶から無意識に監視Saasそのものを敬遠しがちになっていたのは否めません。
直近ではPrometheusを導入して、それはそれで満足はしていますが、同じことを監視Saasでやれなかったとはいえません。監視Saasも時が経つにつれ洗練されているはずで、コスト対効果を鑑みてもっと積極的に導入を考えても良かったと反省する部分もあります。
この辺りは本書でいうアンチパターンにハマっていたと思います。
まとめ
自分の経験を本書と照らし合わせて答え合わせのできる楽しい読書でした。
監視は作り手の自由度が高い分野であると思います。下手をするとアラートだらけになってしまう所を本書の指針に沿って設計する事で、みんなが幸せになれる監視を設計できるかと思います