はじめに
「入門 監視」を読んだ個人的な感想と、大体3年前に２４時間３６５日稼働の映像配信システムに対して雰囲気で監視設計した時の振り返りを各章ごとにつらつらと書きます。
本書のアンチパターンが監視を始めてから徐々に改善していった部分に見事に当たっていたので読んでて色々痛い。
１章 監視のアンチパターン
観察者効果は気にしない
監視設計する際に監視ツールの負荷を気にしてエージェントを入れたくないという人がいたが、エージェントレスどうやって必要な情報を取得するか考えるよりは素直にエージェントを入れて必要十分な情報をとった方が良いというのが結論だった（検討コストもかかるしね）
素晴らしい監視とはチェックボックスに「これを監視しています」とチェックを入れるだけで済むものではありません
上位レイヤーからコンプラ遵守などの理由で監視設定をすることになり、監視設定初期に原因不明でエンジニアが叩き起こされるがしばらくしたら勝手に解決する系のやつです。
そもそも本当にそのパラメータを監視する必要かあるか、設定の閾値が適切か等いろいろ考えるところはあるが最終的にその判断をするために長期でちゃんとメトリクスは保存しましょうというのが教訓となる。
そして本に書いてあったCPU使用率が上がっていることをエンジニアに相談した時のやりとりは身に覚えがありすぎた。
システム管理者「CPU使用率が最近上がってるんだけど」
エンジニア「そのサーバはやるべき処理はしてるんだろう？」
システム管理者 「そうだ」
エンジニア「それなら何も問題ないじゃないか」
2章 監視のデザインパターン
ユーザー視点優先の監視によって、個別のノードを気にすることから解放されます。
ユーザー視点の監視のみで良いということではないが、本書に書いてある「DBサーバのCPU使用率が急上昇しても、ユーザが影響を受けていないなら、それは本当に問題でしょうか」「このメトリクスはユーザへの影響をどう教えてくれるのだろうか」という問いかけは覚えておこう。
3章 アラート、オンコール、インシデント管理
アラートにメールを使うのをやめよう
即応が必要な場合メールでは気づかない上に、事故るとアラートで重要なメールが埋もれて邪魔になるやつ
まずは自動復旧を試そう
常態化していると当たり前だと思いがちだがアラート検知時に行う作業が手順書としてまとまっているならその手順を自動で実施するべき。
インシデント発生後の対応が誰かを非難するものになるなら、内部に潜む本当の問題を改善することは絶対にできません
非難というわけではないがインシデント発生時のレポートラインが多く煩雑だったため、レポートが上がりにくくなっていたのでレポートラインの整理とできる部分は自動化してできるだけ早く整備するべき。
５章 ビジネスを監視する
ビジネスKPIを技術指標に結びつける
監視設計をする際にエンジニア畑の人間だとビジネス観点が抜けがちになる。
監視項目作成時にサービスのKPIを確認し、各監視項目がどのKPIと関連するか意識する必要がある。
一般的なサービスのKPIは大体の場合ユーザ行動に紐づくため、ユーザ行動とアプリケーション観点の監視項目（DB接続のレイテンシ等）が紐づけることができればサービス改善について話す際に非常に役に立つ。
6章 フロントエンド監視
Aberdeen Researchの2010年の研究(リンク切れにつきTOPへのリンク）によると、ページロード時間が１秒遅くなると、平均でページビューが11%、コンバージョンが7%、顧客満足度が16%下がると言われています。
監視の話の話から逸れるが開発コストの話をする際に本書で参考事例として挙がっているShopzilla、Amazon、Pinterestのデータを出すと話がしやすそう。
ページのロード時間をCIシステムから計測し続け、ロード時間が許容時間内に収まるようにしましょう
CIシステムとWebpageTestを連動させることで機能追加、修正とパフォーマンスの影響を関連付けできる。
データは継続して取得しないと意味がないため、初期からパフォーマンスをとれるよう設計する必要がある。
7章 アプリケーション監視
StatsDはモダンな監視スタックには不可欠な存在となりました。
全てをツールで賄うことは難しいが、便利なツールは有効に活用すべき
相当大規模にデプロイしているのでない限り、サーバレスあるいはマイクロサービスの監視は、他のアプリケーションと大きく違いません。分散トレーシングを始めるには時間と労力をかけなければならないでしょう
マイクロサービス化しても必要な数値を押さえておけば必ずしも分散トレーシングは必要ない。パフォーマンスが把握できるかトラブルシューティングできるかという観点で何を監視するか考える。
8章 サーバ監視
OSの標準的メトリクス(CPU、メモリ、ロードアベレージ、ネットワーク、ディスク）のオススメの使い方は、全システムで自動的に記録するようにしておきつつ、アラートは設定しないでおくことです。
しっかりユーザ視点での監視ができていればOSの標準的メトリクスが起因となるアラートが必要になるケースはないはずなのでアラートは確かに必要ない。もしOSの標準的メトリクス起因のアラートがあるのであれば、それはアラート設定を見直すべきだと思う。
この本を読んでいる人は、気づかないうちにSSL証明書が有効期限切れになった経験があるでしょう。
はい、SSL証明書もDRMの期限切れも経験ありまぁす！（白目
期限切れを通知するメールは来るが、メールは本当に見逃されがちというか通知先をMLにしなければ属人化してしまうので、本書にあるようにチケット管理システムで周知するべき。
9章 ネットワーク監視
パケットのドロップとオーバーランはネットワークの帯域がいっぱいになっている可能性を表します。もちろん物理的な問題もパフォーマンスに影響を及ぼすので、それも確認するのを忘れないようにして下さい。
同程度のドラフィックを流しているサーバ群の一部区間のみパケットのドロップが発生したが調査しても原因不明な時に、非常に面倒だがLANケーブルを張り替えたら正常になったことがあった。見た目圧着に失敗してる感じもなかったが困った時は物理的なものも疑うことは重要。
もう一つ特に監視すべき重要なことは、使用しているコーデックです。
コーデックについては監視の観点として想定していなかった。
基本的に一回設定すれば変わらないがほとんどの製品はSNMPでチェックできるようなので、万一にそなえてチェックしておく方が良さそう。
さいごに
全体を通して一番頭に残った一言。
監視とは役割ではなくスキルであり、チーム内全員がある程度のレベルに至っておくべきです。
認識していないもの、そもそも知らないものを監視することはできないため、監視業務についている人だけでなく何かのサービスに関わる人であれば一度読んでおくと良い一冊だと思います。
最後に注釈として「オススメとしてツール名を出したわけではない」とあるが、本書中で名前の出てきたツール群を簡単にまとめておきます。
| ツール名 | 用途 |
|---|---|
| Collectd | メトリクスコレクタ |
| Diamond | メトリクスコレクタ |
| Telegraf | メトリクスコレクタ |
| Graphite | 収集したメトリクスの保存 |
| Grafana | ログ・データ可視化 |
| Smashing | ログ・データ可視化 |
| Splunk | ログ・データ可視化 |
| PagerDuty | インシデント管理 |
| rkhunter | ルートキット検出ツール |
| Snort | ネットワーク侵入検知システム |
| Zeek(Bro) | ネットワークトラフィック解析 |