外部ステータス ページ モニター

外部ステータス ページ モニターは、あなたが依存しているサービス (AWS、GCP、Azure、GitHub、OpenAI、Anthropic など多数) の公開ステータスページを監視し、そのプロバイダーが障害やパフォーマンスの低下を報告したときにアラートを出します。依存先の問題をプロバイダーが報告した時点ですぐに知り、自分たちの問題と区別するために使います。

Status200 で作られたステータスページもリソースごとに読み取り、計画メンテナンスと障害を区別します。別のチームのプロジェクトや、ステータスページを Status200 で運用しているベンダーを監視できます。

仕組み#

チェックのたびに、プローブはステータスページを取得し、その形式を判定して、全体のステータス、コンポーネント、アクティブなインシデントを読み取ります。モニターをコンポーネントグループやコンポーネントに絞っている場合は、それらだけが対象になります。そのうえで、条件がモニターをオンラインかオフラインかに決めます。

次の用途に使えます。

• アプリケーションが依存するサードパーティのサービスの可用性の監視
• 依存先のプロバイダーで障害が起きたときのアラート
• 個々のコンポーネントのステータスの追跡
• 1 つのコンポーネントグループ (たとえば OpenAI の "APIs" だけ) への監視の絞り込み。ページのほかの場所にある無関係なインシデントでモニターが発火しなくなります
• ユーザーに影響が出る前のパフォーマンス低下の検出
• 自分たちのインシデントと依存先のプロバイダーの問題の関連付け

サポートされているプロバイダー#

自動判定#

自動 に設定すると、Status200 は次の順序でステータスページの形式を自動で判定します。

1. まず incident.io のステータスページ API (/proxy/<host>) を試します。
2. 次に Atlassian Statuspage の JSON API (/api/v2/status.json、/api/v2/components.json、/api/v2/incidents/unresolved.json) を試します。
3. 次に、Status200 のステータスページのサマリー (/status-page-api/summary/<page>) を要求します。
4. それらが失敗した場合は、ページを RSS または Atom のフィードとして解析しようとします。
5. 最後の手段として、HTTP で到達できるかどうかの基本的なチェックを行います。

到達可能性のチェックは、明示的に選んだプロバイダーが失敗したときのフォールバックでもあります。これはページが応答するかどうか (2xx または 3xx の応答ならオンライン) だけを伝え、コンポーネントやインシデントは報告しません。

外部ステータス ページ モニターを作成する#

1. 新しいモニターを始める#

   モニター に移動し、モニターを作成 をクリックします。モニターの種類 で その他のモニターの種類 をクリックし、Basic Monitoring の下の 外部ステータスページ を選ぶか、検索ボックスに statuspage と入力します。名前 を入力し、次へ をクリックします。

2. ステータスページの URL を入力する#

   ステータスページ URL を入力します。形式がわかっている場合を除き、プロバイダー は 自動 のままにします。

3. 必要なら範囲を絞る#

   その他の項目 を開いて コンポーネントグループのフィルター (たとえば APIs) を入力し、1 つのコンポーネントだけを監視するには コンポーネント名フィルター を入力します (グループを設定している場合はそのグループ内で絞り込みます)。

4. テストする#

   モニターをテスト をクリックしてページを 1 回取得し、見つかったプロバイダー、コンポーネント、インシデントを確認します。

5. 条件を確認する#

   条件のステップは デフォルトの条件 から始まります。これは、プロバイダーが範囲内のアクティブなインシデントや障害を報告したときにモニターをオフラインにします。必要なら変更し、次へ をクリックします。

6. プローブを選んで作成する#

   プローブ と 監視間隔 (最初は 5 分ごと) を選び、モニターを作成 をクリックします。

構成オプション#

コンポーネントグループのフィルター#

ステータスページがコンポーネントをグループに分けている場合は、モニターを 1 つのグループに絞れます。たとえば https://status.openai.com で APIs と入力すると、モニターは OpenAI の API サービスに絞られます。

コンポーネントグループを設定すると、アクティブなインシデントの数 と 全体のステータス は、そのグループのコンポーネントだけを使って計算されます。無関係なグループ (たとえば ChatGPT) に影響するインシデントでは、"APIs" グループに絞ったモニターは発火しません。

コンポーネントグループによる絞り込みは、Atlassian Statuspage、incident.io、Status200 Status Page のプロバイダーでサポートされています。RSS と Atom のフィードはコンポーネントグループを公開していません。

コンポーネント名フィルター#

ステータスページが複数のコンポーネントを報告している場合は、コンポーネント名を指定してそのコンポーネントだけを監視できます。フィルターは、入力した文字列を名前に含むコンポーネントに、大文字と小文字を区別せずに一致します。actions は "Actions" という名前のコンポーネントに一致します。

コンポーネントグループも設定している場合、コンポーネント名フィルターはそのグループ 内 で適用されるので、大きなグループの中の 1 つのコンポーネントだけを対象にできます。どちらのフィルターも指定しない場合は、範囲内のすべてのコンポーネントを監視します。RSS や Atom のフィードでは、名前のフィルターはフィードの項目のタイトルと照合されます。

監視条件#

外部サービスをオンラインとオフラインのどちらと見なすかを決める条件を、次に基づいて設定できます。

全体のステータスはページに書かれているそのままなので、値はプロバイダーによって異なります。Atlassian Statuspage は All Systems Operational のような独自の説明を、Status200 のステータスページは under_maintenance のような対象範囲内のコンポーネントのうち最も悪いステータスを、フィードは operational や degraded_performance を、到達可能性のチェックは reachable や unreachable を報告します。これらの比較は大文字と小文字を区別します。障害でアラートを出すには、通常は External Status Page Active Incidents と External Status Page Component Status のほうが信頼できます。

RSS や Atom のフィードでは、直近 24 時間の項目がアクティブなインシデントとして数えられます。RSS の項目は公開日で、Atom のエントリーは更新日で判断します。日付が未来の項目は、その日付になるまで数えられません。

デフォルトの条件#

デフォルトでは、Status200 はステータスページにとって本当に重要なもの、つまり単に到達できるかどうかではなく、アクティブなインシデントとコンポーネントの状態に基づいて条件を作成します。

アクティブなインシデントの数とコンポーネントのステータスはコンポーネントグループ / コンポーネント名のフィルターを反映するので、これらのデフォルトの条件は自動的に、関心のあるコンポーネントだけを対象にします。

Status200 のステータスページ#

Status200 で作られたステータスページ (別のチームのプロジェクトや、Status200 Cloud またはセルフホストの Status200 上にあるベンダーのページ) を監視するには、プロバイダーに Status200 Status Page を選ぶか、自動 のままにします。 ステータスページ URL には、ページ自体のアドレスを入力します。ドメインがあれば https://status.example.com のようなドメインを、なければ https://status200.ru/status-page/<status-page-id> を入力します。

モニターはページのサマリー /status-page-api/summary/<page> を読み取ります (サマリーを読む を参照)。ページが訪問者に見せているものだけを読み、もう一方のプロジェクトのそれ以外のものは読みません。ページ上の各リソース (モニターまたはモニターグループ) は、ページが付けた名前で、ページのグループに入ったコンポーネントになります。グループの中のグループは Core / Databases と表されます。1 つのリソースを監視するには コンポーネント名フィルター を、1 つのグループを監視するには コンポーネントグループのフィルター を使います。

コンポーネントのステータスは、ページ上のステータスが表す値なので、コンポーネントのステータスの条件はどのステータスページとも同じように機能します。

進行中の計画メンテナンスのイベントがリソースに影響している間 (イベントがそのリソースのモニターか、そのモニターグループ内のモニターを指定している間) は、モニターのステータスにかかわらず、コンポーネントは under_maintenance になります。イベントがモニターを保持している間、そのモニターはチェックされないためです。まだ始まっていないイベントや終わったイベントは何も変えません。ページのアクティブなインシデントは、影響を受けるリソースについて数えられます。

デフォルトの条件 がメンテナンスを障害と取り違えることはありません。もう一方のプロジェクトの計画作業の間も、モニターはオンラインのままです。

上流のメンテナンスを自分のモニターに表示する#

1. 条件を追加する#

   モニターの条件で 条件を追加 をクリックします。フィルターに External Status Page Component Status、 等しい、 メンテナンス中 を設定し、 モニターのステータスを次に変更 でメンテナンス用のステータスを選びます。

2. いちばん上に移動する#

   新しい条件をほかの条件の上にドラッグします。最初に一致した条件が優先されます。

3. モニターをテストで確かめる#

   もう一方のプロジェクトでメンテナンスが進行中のときに モニターをテスト をクリックします。影響を受けるコンポーネントは メンテナンス中 と表示されます。

Status200 のステータスページがモニターに読ませるもの#

誰でも開けるページは、訪問者が見るとおりに読み取られます。サインイン、SSO、パスワードのいずれかを求める非公開のページは読み取れません。 Status200 Status Page を選んでいれば、チェックは失敗し、その理由を示します。IP 許可リストのあるページは、プローブのアドレスを許可している必要があります。そのネットワーク内のプローブから監視してください。

テンプレート変数#

外部ステータス ページ モニターからインシデントやアラートを作成するときは、タイトル、説明、対処メモで次の変数を使えます (インシデント & アラート テンプレート を参照)。

よく使われるステータスページの URL#

よく使われるサービスのステータスページの一覧です。その多くは Atlassian Statuspage か incident.io を使っているので、自動 のプロバイダーが自動で判定します。どちらでも作られておらず、フィードでもないページは到達可能性のチェックしか受けられません。そうしたページでは、プロバイダーが RSS や Atom のフィードを公開していれば、代わりにそれを監視してください。

ベストプラクティス#

• 自動プロバイダーを使う — 正確な形式がわかっている場合を除き、自動判定はほとんどのステータスページでうまく機能します。
• コンポーネントグループに絞る — プロバイダーの一部だけに依存している場合 (たとえば OpenAI の "APIs" だけ)、無関係なインシデントによるノイズを防げます。
• 特定のコンポーネントを監視する — 特定のサービスだけに依存している場合に有効です。
• 自分のモニターと組み合わせる — 外部ステータス ページ モニターを、自分たちの API モニターや Web サイトのモニターと組み合わせます。両方が同時にダウンしたとき、依存先のステータスページが根本原因をより早く示してくれます。

トラブルシューティング#

次のステップ#