サイト監視は、決めた間隔でWebサイトへアクセスし、利用者がページを開ける状態かを自動で確認する仕組みです。サーバー会社の障害情報や顧客からの連絡を待たず、表示停止を担当者へ知らせる入口になります。
トップページがHTTP 200を返すだけでは、サイト全体が正常とは判断できません。エラーメッセージを含むページが200になることもあります。重要なURL・期待する本文・連続失敗の回数・通知後に確認する人を一組で決めることが、役に立つ監視の基本です。
監視対象は利用者が使う入口から選ぶ
外部の監視サービスからURLへアクセスする方法は、ブラックボックス監視や外形監視と呼ばれます。サーバー内部のCPUや容量ではなく、利用者と同じように応答を受け取れるかを確認します。内部の数値が正常でも、DNSやTLS証明書の問題で外部から開けない障害を見つけられます。
最初の対象はトップページと、事業上重要なページです。会社案内サイトなら問い合わせフォームの入力画面、採用中なら応募ページを含めます。ECや予約サイトでは、商品詳細や予約入口など、トップページとは別の処理を使うURLも選びます。
すべてのページを同じ頻度で監視する必要はありません。停止すると問い合わせや売上へ直接影響する経路を優先します。管理画面や非公開URLを外部監視へ登録する場合は、認証情報の保管とアクセス制限を確認します。
状態コードと期待する本文を一緒に確認する
HTTP監視では、200など期待する状態コードを成功条件にできます。ただし、WordPressやプロキシの設定によっては、エラー画面にも200を返すことがあります。会社名やページ固有の短い文字列が本文に含まれることも条件にすると、誤った画面を正常と判定しにくくなります。
反対に、毎回変わる日時や在庫数を条件へ入れると、ページが正常でも失敗扱いになります。更新しても残る見出しやサービス名を選びます。Google SREのトラブルシューティング例でも、HTTP 200だけでなく期待する応答内容まで照合するブラックボックス確認が使われています。
フォームの送信完了まで監視したい場合は、本番の問い合わせを定期的に増やさない設計が必要です。監視専用のテスト経路を用意できなければ、入力画面の表示監視と、担当者による定期的なテスト送信を分けます。メール配送の成功も、ページ監視だけでは確認できません。
一度の失敗ではなく連続失敗で異常を判定する
通信経路の一時的な揺らぎによって、一回だけタイムアウトすることがあります。すべてを緊急通知すると誤報が増え、担当者が通知を見なくなります。確認間隔と、何回連続で失敗したら異常とするかを組み合わせます。
Amazon Route 53のヘルスチェックの説明でも、指定間隔で要求を送り、連続失敗が閾値へ達したときに異常と判断します。具体的な間隔は、停止が業務へ影響するまでの時間と利用サービスの仕様から決めます。
間隔を短くしても、すべての停止を記録できるとは限りません。確認と確認の間に起きて復旧した短い障害は見逃します。監視結果の稼働率を見るときは、確認間隔・監視地点・計画停止を含むかを一緒に記録します。
複数地点の結果からサイト側か経路側かを分ける
一つの監視地点だけが失敗した場合は、その地点からサイトまでの通信経路に問題があるかもしれません。複数地域から同時に失敗していれば、サイトやDNS側の可能性が高まります。利用する監視サービスが確認地点を選べるかを調べます。
CDNを使うサイトでは、外形監視がCDNのキャッシュを見ている場合があります。利用者視点の停止検知には有効ですが、背後のサーバーが停止してもキャッシュ済みページだけは正常に見えます。必要に応じて、キャッシュされない軽量な確認URLやサーバー内部の監視を組み合わせます。
監視元のIPアドレスをWAFが遮断すると、利用者は正常でも監視だけが失敗します。固定IPの許可が必要か、サービスの公式案内で確認します。監視を通すためにWAF全体を無効にせず、必要な送信元とURLだけを調整します。
通知には担当者が判断できる情報を含める
通知先を一人の個人メールだけにすると、休暇や退職時に見落とします。主担当と代替担当を決め、必要に応じて制作会社やサーバー保守先への連絡条件も定めます。サイトと同じドメインのメールだけを通知先にすると、DNS障害で両方使えない可能性があります。
通知には、失敗したURL・検知時刻・監視地点・状態コード・応答時間を含めます。担当者が行う必要のない情報だけを大量に送らないようにします。Prometheusのアラート設計でも、原因候補をすべて通知するより、利用者へ見える症状と対応可能な通知へ絞る考え方が示されています。
夜間に即時対応しない会社サイトなら、通知方法も業務体制に合わせます。深夜の一回の失敗を全員へ電話する設定は長続きしません。緊急度を決め、即時連絡・営業時間内の確認・記録だけに分けます。
通知を受けたら変更前に事実を確認する
障害通知が届いたら、すぐサーバー設定を変更するのではなく、別の回線や端末から対象URLを開きます。監視サービスの詳細とサーバー会社の障害情報を確認します。問題が続いていれば、発生時刻を基準にアクセスログとエラーログを調べます。
初動は次の順番にすると、誤報と実障害を分けやすくなります。
- 通知のURL・時刻・監視地点・状態コードを確認する
- 別回線から同じURLと代表ページを開く
- DNS、TLS証明書、サーバー会社、CDNの障害情報を確認する
- 同じ時刻のアクセスログとエラーログを保全する
- 直前の更新や設定変更を確認し、復旧または連絡先を判断する
復旧通知が来ても、業務機能まで直ったとは限りません。フォームや予約など影響を受けた機能を手動で確認します。障害時刻・原因・対応・復旧確認者を記録し、次回はどの監視条件を追加すべきかを見直します。
監視そのものが通知できるか定期的に試す
監視を設定した直後は、テスト通知を主担当と代替担当が受け取れるか確認します。通知用メールが迷惑メールへ入ることや、チャット連携の権限が切れることもあります。計画停止を使って、異常と復旧の両方が届くかを定期的に試します。
サーバーメンテナンス中は、既知の停止を一時停止または保守時間として扱います。通知を完全に削除すると再開を忘れるため、終了時刻を設定できる機能を使います。メンテナンス後は監視が再開し、正常判定へ戻ったことを確認します。
権限台帳とは別に、監視URL・成功条件・間隔・連続失敗数・通知先・最終テスト日を運用資料へ残します。担当者が変わっても通知を受けるだけで終わらず、同じ初動を再現できる状態にしておくことが重要です。
