0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@shofuk9

Cloudflare のデータセンター障害を Slack に自動通知する監視ツールを作った（Workers + KV）

0
Posted at

はじめに

Cloudflare を本番で使っていると、こんな不安がつきまといます。

  • 今、自分たちが依存しているデータセンター（コロ）は正常なのか？
  • 障害が起きたとき、Cloudflare のステータスページを見に行くまで気づけない

Cloudflare は Cloudflare System Status で世界中のデータセンターの状態を公開していますが、人間が定期的に見に行くのは現実的ではありません。障害・復旧・メンテナンスの「変化」だけを、必要なコロに絞って Slack に飛ばしてほしい。

そこで作ったのが cloudflare-dc-checker です。

Cloudflare Workers 上で 5 分おきにデータセンターのステータスを監視し、障害・復旧・メンテナンスの「変化」を検知して Slack に通知するサーバーレスアプリです。サーバー不要・Cloudflare 無料枠内で完結します。

本記事では、このツールの仕組みと導入方法を紹介します。

届く通知はこんなイメージです。

⚠️ Cloudflare データセンター障害検知
Tokyo, Japan - (NRT): partial_outage
検知時刻: 2026-07-18 13:45 JST

何ができるか

機能 内容
定期監視 Cron Trigger で 5 分おきに Cloudflare Status API をチェック
障害検知 partial_outage / major_outage / degraded_performance への遷移を検知
復旧通知 operational に戻ったタイミングで通知
メンテ通知 under_maintenance への遷移／解除（計画メンテの開始・終了）を通知
監視対象の絞り込み IATA コード（NRT,KIX,FUK 等）または ALL で対象コロを指定
Slack 連携 Block Kit で整形されたメッセージを送信
現在状態の確認 GET / で現在のステータスを JSON で返す
自動デプロイ GitHub Actions で main push 時に自動デプロイ

ポイントは、「状態」ではなく「状態の変化」を通知することです。毎回「正常です」と言われても意味がないので、前回と比較して変化があったときだけ Slack に投げます。

アーキテクチャ

┌──────────────┐   5分ごと(Cron)    ┌────────────────────┐
│ Cloudflare   │ ────────────────▶ │ Cloudflare Workers │
│ Status API   │                   │ (cf-status-monitor)│
└──────────────┘                   └─────────┬──────────┘
                                             │ 前回状態と比較
                                    ┌────────▼─────────┐
                                    │ Workers KV       │
                                    │ (前回ステータス) │
                                    └────────┬─────────┘
                                             │ 変化を検知したら
                                    ┌────────▼─────────┐
                                    │ Slack (Webhook)  │
                                    └──────────────────┘

処理の流れはシンプルです。

  1. Cron Trigger（*/5 * * * *）で Worker が起動
  2. Status API から現在のデータセンター状態を取得
  3. Workers KV に保存してある前回の状態と比較
  4. 差分（障害 / 復旧 / メンテ開始 / メンテ終了）があれば Slack に通知
  5. 現在の状態を KV に保存して次回に備える

取得元 API について

「Status API」と書いていますが、これは api.cloudflare.com の Cloudflare API とは別物です。Cloudflare のステータスページは Atlassian Statuspage でホストされており、以下のエンドポイントで各コンポーネント（データセンター）の状態が 認証不要の JSON として取れます。

GET https://www.cloudflarestatus.com/api/v2/components.json

レスポンスの components[] から、コンポーネント名（例：Tokyo, Japan - (NRT)）に含まれる IATA コードを正規表現 /\(([A-Z]{3})\)/ で拾い、status フィールド（operational / degraded_performance / partial_outage / major_outage / under_maintenance）を判定しています。Cloudflare One の DEX fleet-status 系 API とは無関係なので混同しないよう注意してください。

初回実行時は通知しません。 最初の起動では KV が空なので「ベースライン」として現在状態を保存するだけにし、次回以降の変化から通知を始めます。起動直後に大量のアラートが飛ぶのを防ぐためです。

技術スタック

要素 採用技術
実行環境 Cloudflare Workers（サーバーレス）
言語 JavaScript
状態保存 Cloudflare Workers KV
スケジューリング Workers Cron Triggers
CI/CD GitHub Actions
通知 Slack Incoming Webhook（Block Kit）

Cloudflare の監視を Cloudflare 自身の上で動かす構成です。取得元の Status API は Atlassian Statuspage 上にあり Cloudflare 本体とは別基盤ですが、監視 Worker 自体は Cloudflare 上で動くため、Cloudflare 全体規模の障害では Cron・Worker 実行ごと止まり、一番通知が欲しい瞬間に届かないリスクは残ります。個別コロの障害・メンテ検知が目的なら実用上は十分ですが、全面障害への備えとしては外部監視サービスとの併用をおすすめします。

内部構造

Worker はモジュール分割されています。

ファイル 役割
src/index.js エントリポイント。scheduled（Cron）と fetch（HTTP）のハンドラ
status-fetcher.js Cloudflare Status API を叩いて対象コロの状態を取得
state-manager.js KV への前回状態の read / write
slack-notifier.js Block Kit メッセージの生成と送信

index.js の Cron ハンドラは、おおよそ次のような流れです。

export default {
  async scheduled(controller, env, ctx) {
    // 監視対象コロ（未指定なら NRT,KIX）
    const monitoredCodes = (env.MONITORED_DCS || 'NRT,KIX')
      .split(',')
      .map((code) => code.trim().toUpperCase());

    // 現在の状態を取得
    const current = await fetchDataCenterStatuses(monitoredCodes);
    // 前回の状態を KV から取得
    const previous = await getPreviousStatuses(env.STATUS_KV);

    // 差分検知 → 障害 / 復旧 / メンテ開始 / メンテ終了 に分類
    const changes = detectChanges(previous, current);

    // 種類ごとに Slack へ通知
    await notifySlack(env.SLACK_WEBHOOK_URL, changes);

    // 今回の状態を保存
    await saveCurrentStatuses(env.STATUS_KV, current);
  },

  async fetch(request, env) {
    // GET / で現在の監視状態を JSON 返却（手動確認用）
    ...
  },
};

デプロイ後は https://<worker名>.<サブドメイン>.workers.dev/ にアクセスすると、現在の各コロのステータスが JSON で返るので、動作確認に使えます。

状態遷移の分類はこうしています。

分類 遷移条件
障害発生（Incident） operational → partial_outage / major_outage / degraded_performance
復旧（Recovery） 障害系ステータス → operational
メンテ開始 * → under_maintenance
メンテ終了 under_maintenance → operational

導入方法

前提

  • Cloudflare アカウント（API Token / Account ID）
  • Slack Incoming Webhook URL
  • Cloudflare 上に作成済みの KV Namespace

おすすめ：GitHub Actions で自動デプロイ

リポジトリの Secrets に認証情報を登録し、main ブランチに push するだけでデプロイされます。

Secret 内容
CLOUDFLARE_API_TOKEN Workers デプロイ用トークン
CLOUDFLARE_ACCOUNT_ID アカウント ID
KV_NAMESPACE_ID 作成した KV Namespace の ID
SLACK_WEBHOOK_URL Slack の Incoming Webhook

ローカルからデプロイする場合

npm install
npx wrangler login

# KV Namespace を作成し、出力された id を控える
npx wrangler kv:namespace create STATUS_KV

# Slack Webhook はシークレットとして登録
npx wrangler secret put SLACK_WEBHOOK_URL

npm run deploy

監視対象コロの指定

wrangler.toml の vars で指定します。

name = "cf-status-monitor"
main = "src/index.js"
compatibility_date = "2024-01-01"

[triggers]
crons = ["*/5 * * * *"]

[[kv_namespaces]]
binding = "STATUS_KV"
id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  # ← 作成した KV Namespace の id を直書き

[vars]
MONITORED_DCS = "NRT,KIX,FUK"   # IATA コードをカンマ区切り。全コロ監視なら "ALL"

注意： リポジトリの wrangler.toml では id = "${KV_NAMESPACE_ID}" のようにプレースホルダになっています。これは GitHub Actions 側で Secrets の値に置換される前提であり、wrangler は TOML 内の ${...} を自動展開しません。ローカルから直接デプロイする場合は、上記のように wrangler kv:namespace create で払い出された実 id を直書きしてください（同様に MONITORED_DCS も実値に置き換えます）。

日本国内なら NRT（東京）/ KIX（大阪）/ FUK（福岡）あたりを指定しておくのが実用的です。

通知イメージ

Slack には Block Kit で整形されたメッセージが届きます。障害・復旧でそれぞれこんな見た目です。

⚠️ Cloudflare データセンター障害検知
Tokyo, Japan - (NRT): partial_outage
検知時刻: 2026-07-18 13:45 JST

✅ Cloudflare データセンター復旧
Tokyo, Japan - (NRT): operational

ヘッダー（絵文字付き）＋ セクション（コロ名・状態）というシンプルな構成なので、パッと見で「どこで何が起きたか」が分かります。

実際の投稿画面のスクリーンショットをここに貼ると、より伝わりやすくなります（![Slack通知例](画像URL)）。

コスト

Cloudflare の無料枠内で完結します。

  • Workers 無料枠：10 万リクエスト / 日
  • KV 無料枠：読み取り 10 万回 / 日、書き込み 1,000 回 / 日
  • 5 分ごとの Cron は 1 日 288 回。KV 書き込みも 288 回 / 日で枠内

実質 月額 0 円で Cloudflare の障害監視ができます。

注意： この構成で一番タイトな制約は KV の書き込み 1,000 回 / 日です。5 分間隔なら余裕ですが、crons を * * * * *（1 分おき）にすると 1,440 回 / 日で上限を超えます。間隔を詰める際は書き込み回数に注意してください。

工夫したポイント

  • 「変化」だけ通知する：状態そのものではなく前回との差分を KV で管理し、ノイズを排除。
  • 初回はサイレント：起動直後のアラート洪水を防ぐため、初回は状態保存のみ。
  • 対象コロの絞り込み：全世界のコロを見ても意味がないので、自組織が依存するコロだけに限定できるようにした。
  • 完全サーバーレス＆無料：監視基盤の運用コスト（サーバー・保守）をゼロにした。

注意点・制約

導入前に知っておくとよい前提です。

  • partial_outage ＝ 必ずしもユーザー影響あり、ではない：Cloudflare のコロ単位の partial_outage は多くが「Re-routed（トラフィックが他コロへ迂回）」を意味し、エンドユーザーには影響が出ていないことも多いです。通知が来ても即障害と決めつけないのが吉です。
  • 5 分間隔より短いフラップは取りこぼす：チェックは 5 分おきなので、その間に発生→復旧した瞬間的な変化は検知できません。
  • Status API はあくまで「Cloudflare の公表情報」：Cloudflare がステータスページに反映する前の障害は拾えません。一次情報ではなく公式アナウンスのミラーである点に留意してください。
  • 監視 Worker 自体が Cloudflare 上で動く：前述の通り、全面障害時には監視も止まる可能性があります。ミッションクリティカルな用途では外部監視と併用を。

まとめ

  • Cloudflare のデータセンター障害を 人間が見に行かずに Slack で受け取れるようにした。
  • Cloudflare Workers + KV + Cron + GitHub Actions で、サーバーレス・無料枠内で完結。
  • 通知するのは「状態」ではなく 「状態の変化」（障害 / 復旧 / メンテ開始・終了）。
  • 監視対象コロを IATA コードで絞れるので、自組織に必要なアラートだけ届く。

Cloudflare を本番運用しているチームなら、すぐに導入して障害の初動を早められます。今後は通知先の Teams 対応なども考えています。よければリポジトリを覗いて、Star や Issue で反応をもらえると嬉しいです。

リポジトリ

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?