# Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus PromCon 2017 (Munich, 2017-08-17) | [[Matt Bostock]] ([[Cloudflare]]) ## 概要 Cloudflare が運用するグローバルエニーキャストエッジネットワーク（全世界115+拠点データセンター、600万以上のウェブサイト・API配信、毎秒500万HTTPリクエスト・120万DNSリクエスト）において、従来の Nagios 集中監視から [[Prometheus]] による自律分散監視基盤へと移行した設計と運用知見を解説したスライド資料である。各拠点（PoP）内での完全ローカル監視と高可用性冗長ペア、階層型フェデレーションによるコア集約、Alertmanager を用いたラベル駆動アラートルーティング、ならびにカーディナリティ爆発やストレージ圧迫といった実運用上の課題（Pain Points）への対処法が体系的に示されている。 ## 主要メッセージ - **監視対象と同じ障害ドメイン内に Prometheus を配置する**: 外部ネットワーク障害時にも各拠点の自己完結した死活監視とアラート送出を継続するため、各 PoP 内に 2 台の Prometheus を独立稼働させる（p.21–23）。 - **階層型フェデレーション（Hierarchical Federation）の徹底**: 中央のコア Prometheus は生メトリクスを直接スクレイプせず、各拠点内で記録ルール（Recording Rules）により事前集約されたコロ集約メトリクス（`colo:*`、`colo_job:*`）および死活メトリクス（`up`）のみを 30 秒間隔でプルする（p.24–27）。 - **監視基盤自体の相互監視（Monitoring your monitoring）**: データセンター内の Prometheus 同士がメッシュ状に相互監視し、さらにコアのトップレベル Prometheus が各拠点を階層監視する。Alertmanager の障害検知には Grafana のアラートルールを用いてデッドマン監視を行う（p.44–47）。 - **アラート設計の厳格化とアクショナブル化**: アラートルール作成時には過去データで発火頻度を検証し、Runbook リンクとグラファナダッシュボードを注記に義務づけ、原因（RAID）ではなく症状（`RAID_Health_Degraded`）として命名する（p.36–43）。 - **初期段階でのラベル標準化の重要性**: プローブの送信元・送信先、環境、クラスタ等のラベル命名規則を早期に統一しないと、後からのクエリやルーティングの破綻を招く（p.64）。 ## 視覚的に重要な図表 **p.6 Cloudflare の Prometheus デプロイ規模** ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-006.png]] 本番稼働中の Prometheus サーバー 185 台、コアのトップレベルサーバー 4 台。サーバーあたり最大 72k サンプル/秒の取り込み、最大 460 万時系列、ディスク使用量最大 250GB。 **p.23 各 PoP 内の高可用性構成** ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-023.png]] 同一 PoP 内の全サーバーを 2 台の独立した Prometheus サーバーが並行してスクレイプし、クラスタリングや状態共有を行わずに高可用性を担保する。 **p.25 フェデレーション設定（Federation Configuration）** ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-025.png]] コアの Prometheus から拠点へ `/federate` エンドポイント経由で取得する際、`{__name__="up"}` と `{__name__=~"colo(?:_.+)?:.+"}` のみに厳密にマッチングを限定する。 **p.28 高可用性フェデレーション構成** ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-028.png]] コアデータセンター側にも 2 台の Prometheus を配置し、各拠点（San Jose、Frankfurt、Santiago など）の拠点 Prometheus から集約メトリクスを並行して引き出す。 **p.43 アラートルールの記述例** ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-043.png]] `ALERT RAID_Health_Degraded` の具体例。`labels` に `notify="jira-sre"` を付与し、`annotations` には障害ディスク数・インスタンス名を含むサマリー、Grafana ダッシュボード URL、内部 Wiki の Runbook リンクを必須記載している。 **p.46 Prometheus の相互監視メッシュ** ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-046.png]] 同一データセンター内の各 Prometheus が互いをスクレイプするメッシュ監視と、上位のトップレベル Prometheus が下位 Prometheus をスクレイプするトップダウン監視の2重構造。 **p.52 ラベル正規表現マッチによるアラートルーティング** ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-052.png]] `notify` ラベル内の単語を正規表現 `(?:.*\s+)?hipchat-sre(?:\s+.*)?` でマッチさせ、`continue: true` により HipChat と Jira、PagerDuty への多重ファンアウトルーティングを実現する。 **p.63 カーディナリティ爆発の調査** ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-063.png]] `storagetool dump-heads` を用いてメモリ内ヘッドブロックをダンプし、単一メトリクス名で数百万時系列（最大299万系列）に膨れ上がったカーディナリティの急増箇所を特定する解析フロー。 ## 口頭説明・補足（Transcript より） - **メトリクスの保持期間を 15 日に絞る理由**: Prometheus を長期のビジネス・アプリケーション分析ストレージとして使わず、あくまでインシデント検知・対応・ポストモーテムのための監視専用基盤と割り切ることで、単一サーバーのディスク消費を 250GB 以内に抑えている。 - **Nagios 時代からの脱却動機**: 中央集権の Nagios では単一マシンで数十万件のチェックを行っており、障害時に監視自体がボトルネックとなっていた。Prometheus の多次元ラベルモデルとプル方式により、柔軟な集約と分散配置が可能になった。 - **アラートルーティングの分離**: SRE を直接ページング（深夜呼び出し）するものと、日中の Jira チケット起票にとどめるもの、チャット（HipChat）通知で済ませるものを `notify` ラベルのタグ付けで制御し、開発チームへのエスカレーションと SRE の負担軽減を両立させている。 ## Q&A（Transcript より） - **デッドマンズスイッチ（Dead Man's Switch）**: 質問者からの「アラートパイプライン全体の疎通確認はどうしているか」に対し、常に発火し続ける合成アラート（Synthetic Alert）を Prometheus から Alertmanager 経由で PagerDuty に流し、通知が途絶えた場合に PagerDuty 側が異常を検知するインテグレーションの有効性を議論した。 - **フェデレーション環境での集約計算の難しさ**: 全データセンターから多数のメトリクスセットをフェデレーションすると中央の計算が複雑化するため、できる限り拠点側で事前集約（pre-aggregation）を完結させるべきであると回答している。 ## 概念・実体への接続 - **人物・組織**: [[Matt Bostock]]、[[Cloudflare]] - **プロダクト**: [[Prometheus]]、[[Alertmanager]]、[[Nagios]] - **概念**: [[アラート疲労]]、[[エニキャストルーティング]] ## 限界・不確実点 - 発表時点（2017年8月）は Prometheus 1.x 時代（ストレージエンジン V2）であり、ローカルストレージのメモリ圧迫対策（`-storage.local.target-heap-size`）や `storagetool` による解析は Prometheus 2.0（V3ストレージ）以降では内部実装が異なる。 - 当時のチャット通知ツールとして HipChat が使用されているが、現代の Slack 等への置き換えとして一般化して解釈可能である。