サイトが落ちていることにお客さんからの連絡で気づく——これを避けるのが死活監視です。仕組み自体は「定期的にアクセスして応答を見る」だけですが、誤検知をどう減らすかで実用性が大きく変わります。
何をもって「落ちている」とするか
監視の判定基準にはいくつか段階があります。下にいくほど厳密ですが、そのぶん誤検知も増えます。
- Pingが返る — サーバーは生きている。ただしICMPを遮断していると使えない
- ポートが開いている — Webサーバーのプロセスは動いている
- HTTPで200が返る — 実用上もっとも標準的な基準
- 特定のキーワードが含まれる — 「200は返るが中身が真っ白」を検出できる
意外と見落とされるのが最後のケースです。データベース接続に失敗していても、エラーページがステータス200で返ってしまう実装は珍しくありません。ステータスコードだけを見ていると「正常」と判定されてしまいます。
誤検知を減らす3つの工夫
1. 1回の失敗で通知しない
ネットワークは瞬間的に失敗します。監視元の一時的な問題かもしれません。2回以上連続して失敗したときに初めてダウンと判定すると、誤報が大幅に減ります。
この考え方は遅延（応答が遅い）の通知にも当てはまります。実際の計測データを見ると、「普段の2倍以上遅い」と判定されるケースの9割は1回で解消する瞬間的なスパイクでした。1回ごとに通知していると、対処のしようがないメールで受信箱が埋まります。
2. 復旧も通知する
ダウン通知だけだと「まだ落ちているのか」がわかりません。復旧時に「何分間ダウンしていたか」を知らせると、影響範囲の把握と事後報告がそのまま書けます。
3. 監視間隔は5分前後が現実的
短くすれば早く気づけますが、監視先への負荷とコストが増えます。個人サイトから中小規模のサービスであれば5分間隔で十分です。1分間隔が必要なのは、数分の停止が実損に直結する場合に限られます。
「遅い」は落ちる予兆になる
ダウンする前には、たいてい応答が遅くなる期間があります。ディスクの空き容量、メモリ不足、DBのスロークエリ——いずれもいきなり落ちるのではなく、じわじわ遅くなってから落ちます。
そのため、平常時の応答時間を記録しておき、普段との比較で異常を捉えることに価値があります。ただし前述のとおり、一時的なスパイクで鳴らすと通知が形骸化するため、継続している場合だけ知らせる設計にします。
使ってみる
サイト死活監視は、登録したURLを5分ごとにチェックし、ダウンを検知するとメールで通知します（無料・アカウント登録制）。
- ダウン判定は2回連続で失敗したとき
- 遅延の通知は3回連続（約10分以上）遅い状態が続いたときのみ
- 復旧時にはダウンしていた時間を添えて通知
つながらない原因の切り分けにはPing・Traceroute・ポート開放チェックの使い分けもあわせてご覧ください。
まとめ
- ステータス200だけでは「中身が空」を見逃すことがある
- 1回の失敗では通知しない。連続回数で判定すると誤報が激減する
- 復旧通知にダウン時間を含めると、そのまま報告に使える
- 遅延は落ちる予兆。ただし瞬間的なスパイクでは鳴らさない
