ウェブサイトを監視する方法

全体で約5分の3ステップです。サイトの主要URLにモニターを作成し、アラートの送信先を選び、アラートが実際に発火することを確認します。初日にすべてのURLを監視することが目的ではありません。顧客が最初に気づく障害をカバーし、アラートが実在の担当者に届くことを証明するのが目的です。

1. 1

   最初に監視すべきもの

   実際の訪問者が最初に開くURLにモニターを向けます。ホームページ、または本当の入口がログインページならログインページです。これは外部からのチェックです。自社サーバーの外からスケジュール実行されるため、インフラ内部では正常に見えていても、サイトに到達できないことを知らせられます。本番の最終URLを使い、httpsを含め、モニターが認証できる設計でない限りログイン済みセッションが必要なパスは避けます。

2. 2

   ノイズを減らすアラート

   チェックが失敗したときにアラートをどこへ届けるかを選びます。メールが最もシンプルな既定値で、チームではSlack、Discord、自社システムへのWebhookもよく使われます。誰かが実際に見ているチャネルを選び、送信前にどれだけの確認を要求するか決めます。多くの公開サイトでは、一度の一時的な失敗で通知するより、2回連続で失敗したら通知するルールから始める方が適しています。

3. 3

   Holter の使い方

   アラートが動くと決めつけず、確認します。必ず失敗するURLにモニターを向けるか、一時的に必ず通らないアサーションを使い、次のチェックサイクルを待ちます。モニターの状態が変わること、アラートが正しい担当者に届くことの両方を確認してください。届かなければ、実際の停止より前に壊れた設定を見つけられたということです。

   curl -I https://yoursite.com/this-path-does-not-exist
   # expect: HTTP/1.1 404 Not Found
   # then wait for the next scheduled check and confirm the alert arrives

スキャンは一時点の状態です

基本チェックとアラートの動作を確認できたら、次にTLS証明書の期限切れを追加します。サーバー停止は少なくとも訪問者にすぐ見えますが、証明書は期限当日まで警告なく静かに失敗します。ドメイン期限切れも同じリスクです。登録が失効するとサイトとメールが使えなくなり、数日続くこともあります。支払い問題やレジストラ側の問題は見落としやすいものです。

3番目に、最も重要な顧客導線のモニターを追加します。チェックアウト、ログイン、ダッシュボードURL、予約フロー、または別サービスが依存するAPIエンドポイントです。ホームページだけの設定では、サイトの他の部分が正常に見える一方で、これらの導線だけが壊れても気づけません。その後、cronジョブ、キュー、インポート、バックアップにはheartbeatモニターを追加します。外部チェックでは見えない、静かに動く仕事です。

避けるべき設定ミス

避けるべき設定ミスでは、アラートが実際に対応できる人へ届き、誤検知で無視されないようにするための考え方を説明します。一度の失敗だけで騒がず、連続失敗や明確な閾値を使うことが重要です。

ホームページだけをチェックする。チェックアウトやAPIパスが単独で失敗しても、ホームページのチェックでは見えません。最初のモニターはサイトが存在することを証明します。2番目か3番目のモニターは、顧客が本当に必要とする部分がまだ動いていることを証明すべきです。

アラートを一度もテストしない。設定しただけで発火を確認していないモニターは、偽の安心感を生みます。ステップ3のように一度失敗を強制し、問題が直った後にモニターが緑へ戻る回復経路も確認します。