複数のサイトが同時に無応答なら、監視機の接続も疑う
今回やったこと
複数の公開先を監視する処理で、すべてのoriginが同時に無応答になったとき、各サイトの障害と即断しない判定を加えた。監視機自身が閉域ネットワークから切れている可能性も通知文に含める。監視対象が同時に落ちたように見える場合、観測点の故障も同じ観測結果を生むからだ。
監視通知は人を呼び出す。誤った断定を続ければ、通知を受け取る側は内容を信用しなくなる。判定を少し慎重にするのは、障害を見逃すためではなく、観測できた事実と原因の推測を分けて伝えるためである。
応答の有無と障害判定を分ける
scripts/lib/origin_probe.py は各originを一度だけ確認し、HTTPコードを返す。無応答は0として表し、is_down() は無応答か5xxを「落ちた」と判定する。404や422は、ページの内容が正しいことを意味しないが、サーバーから応答があったことは示す。そのためoriginの到達性チェックでは、これらを正常扱いする。
この区別により、監視の目的を「ページの内容検査」ではなく「originが応答できるか」に限定できる。本文や認証後の画面まで保証する監視ではないため、その確認は別の仕組みに任せる必要がある。
全滅と個別障害で通知を変える
scripts/ops/witness_watch.py の assess_origins() は、全originが無応答の場合に、origin側の障害と監視機自身のネットワーク切断の両方を候補として伝える。個別のoriginだけが応答しない場合は、対象を特定した通知になる。通知を見た人が次に確認する場所を誤らないよう、症状のまとまりに応じて説明を変えている。
全originが無応答
→ origin側の障害、または監視機の接続断を疑う
一部だけ無応答
→ 該当originの障害を確認する
HTTP 404 / 422
→ 到達はできている。内容の確認は別途行う
判定ロジックは origin_probe.py に集約され、外部からの監視と各機自身による自己点検の両方で共有される。判定を複数箇所へコピーすると、片方だけ修正されたときに「同じ台帳を見ているのに落ちた判定が違う」状態になる。共通モジュールを使えば、応答コードの意味を一箇所で管理できる。
観測できない状態を正常にしない
監視機から見えないoriginは、各マシンの自己点検結果を別経路で読み取る構造もある。自己点検の記録が取得できなかった場合は、異常なしではなく「点検できていない」と報告する。空の結果と、確認そのものが失敗した状態を区別する考え方は、監視全体に共通する。
この設計でも、すべての障害原因を特定できるわけではない。全originの無応答から分かるのは、監視点から応答がなかったことまでだ。origin群と監視機のどちらが原因かは、通知を受けた後に別の経路から照合する必要がある。だからこそ、通知では可能性を示し、事実として確認できていない原因を断定しない。
実装環境・参照
リポジトリ内の scripts/ops/witness_watch.py、scripts/lib/origin_probe.py を参照した。HTTP応答の判定や自己点検の流れは現行コードの仕様を記述しており、稼働率や検知時間の実測値を示すものではない。
更新履歴
- 2026-10-19: 初稿作成。