大きなビルには管理室があり、エレベーターの停止や火災報知器の異常をすぐに見つけられるようになっています。サーバーやWebサイトの監視も、役目はこの管理室と同じです。状態を見張り続け、決めた値（閾値）を超えたら担当者へ知らせる。人がずっと画面を見ているのではなく、仕組みに異常を拾わせます。
壊れてから利用者に教えられるのではなく、自分たちが先に気づく。稼働率を高く保ちたいなら、まずここから整えます。
何を見張るか
見張る項目は、多ければよいわけではありません。異常が起きたときに担当者が動ける項目を選びます。よく対象になるのは次のようなものです。
- Webサイトが応答しているか（落ちたらすぐ気づきたい）
- 応答にかかる時間
- CPU の使用率、ディスクの残り容量
- TLS証明書やドメインの更新期限
最後の項目は見落とされがちです。証明書やドメインの期限切れは、サーバーが元気でもサイトを止めます。日付で来ると分かっている事故こそ、監視で先に拾っておきます。
「生きているか」を確かめる単純な確認と、「そろそろ壊れそう」という兆候を見る監視は、分けて考えます。ディスクが満杯になってから知らせても遅いので、8割を超えたら知らせる、といった形で兆候を拾います。
通知は多ければいいわけではない
何でもかんでも通知を飛ばすと、人は慣れて見なくなるものです。毎日何十件も届く警告の中に、本当に危ない1件が埋もれる。重要度を分けて、すぐ動くべきものだけが目立つように設計します。
通知を受けた人が動けるか
ディスクの使用率が80%を超えました。
TLS証明書の有効期限まで、あと14日です。
……この通知、いつも誰が見てるんだっけ？
監視は、異常を知らせてくれる仕組みであって、自動で直してくれるわけではありません。通知が届いたあと、誰が、何分以内に、何をするのか。そこまで決めておかないと、通知だけが鳴って障害は続きます。
ロードバランサーの配下で不調のサーバーを自動で外す仕組みはヘルスチェックと呼ばれ、こちらは機械が経路を切り替えるための確認です。監視は人へ知らせる役、と分けて考えると整理しやすくなります。