# Monitoring Cloudflare's Planet-Scale Edge Network SREcon17 Europe/Middle East/Africa (Dublin, 2017-09-01) | [[Matt Bostock]] ([[Cloudflare]]) ## 概要 Cloudflare が運用するグローバルエニーキャストエッジネットワーク（当時 116 拠点、600 万以上のウェブサイトを配信）の監視体制を、Nagios から [[Prometheus]] へ移行した 18 か月の経験を報告する講演である。移行の技術的アーキテクチャ、組織的な変更推進の難しさ、アラートノイズ削減のアプローチを包括的に扱う。 ## 主要メッセージ - **Prometheus は監視の新しいゴールドスタンダードである**: 単一バイナリ・クラスタリング不要・プルモデル・多次元ラベルという設計が、監視対象と同じ障害ドメイン内に配置する信頼性設計を可能にする。 - **監視対象と同じ障害ドメインに配置する**: メトリクスパイプラインを経由するのではなく、各 PoP 内に Prometheus を配置し、同一障害ドメインで動作させることで、ネットワーク障害時にも監視が生き残る。 - **良い監視は無料では実現しない**: トレーニング、投資、組織変革が必要であり、時間がかかる。 - **監視は人間とのやり取りである**: アラートを受け取るエンジニアのユーザー体験を設計する必要がある。 ## 映像で確認できる重要点 - ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-002.jpg]] frame-002: Cloudflare のエニーキャストエッジネットワークの規模。毎日のインターネットリクエストの 10%、HTTP 500 万リクエスト/秒、DNS 120 万リクエスト/秒、世界 116 データセンター、150 か国で 600 万以上のウェブサイト・アプリ・API を配信。 - ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-006.jpg]] frame-006: 各 PoP 内部の Prometheus アーキテクチャ。1 つの Prometheus インスタンスが PoP 内の複数サーバーをスクレイプする構成。高可用性のため複数の独立した Prometheus インスタンスが同一サーバー群から並行してメトリクスを収集する。 - ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-007.jpg]] frame-007: フェデレーション構成。コアデータセンターの Prometheus が San Jose、Frankfurt、Santiago など各 PoP の Prometheus からメトリクスのサブセットを集約する。全メトリクスでなく、サービスレベルの概観に十分なサブセットのみをフェデレーションする。 - ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-008.jpg]] frame-008: 使用しているエクスポータ一覧。Node exporter（システムメトリクス: CPU、メモリ、TCP、RAID 等）、Blackbox exporter（ネットワークプローブ: HTTP、TCP、ICMP ping）、mtail（ログマッチ: ハングタスク、コントローラーエラー）、cadvisor（コンテナ/ネームスペースのリソースメトリクス）。 - ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-009.jpg]] frame-009: アラーティングの高可用性構成（計画中）。San Jose、Frankfurt、Santiago の各 PoP から CORE US と CORE EU の 2 つの Alertmanager へクロス接続でアラートを送信。ゴシッププロトコルで通知の重複排除を行い、ゴシップ失敗時はアラートを重複送信する（通知漏れより重複を選択する設計）。 - ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-010.jpg]] frame-010: 「監視 == 人間とのやり取り」。(1) ユーザージャーニーを理解する、(2) すべてが critical ではない、(3) 適切なチャネルを選ぶ、(4) 原因でなく症状にアラートする、(5) マシンでなくサービスにアラートする。 - ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-011.jpg]] frame-011: PagerDuty エスカレーションのドリルテスト。`ALERT SRE_Escalation_Drill` を Prometheus のアラートルールとして定義し、8 時間ごとに自動発火させてエスカレーションが正しく機能しているかを検証する。Prometheus のアノテーションにダッシュボード URL、Wiki リンク、サマリーを含める。 - ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-012.jpg]] frame-012: 経験した課題。Alertmanager の初期バージョンの不安定性、ヒストグラムでのパーセンタイル計算によるファントムスパイク、self-inhibiting alert（自分自身を抑制してしまうアラート）、ストレージのチューニングとカーディナリティ爆発。 ## 口頭説明・補足 ### Nagios からの移行の動機 以前は Nagios にカスタムメトリクスパイプラインを接続してアラートを運用していた。長期間それで機能していたが、新しいアラートの構成が複雑で、アラート定義のバージョン管理がなく、製品チームが独自のアラートを追加しにくい状況だった。アラートのグループ化機能もなくノイズが多かった。 ### 組織変革の難しさ Wiki に仕様書を公開し、複数チームにレビューを依頼した。監視は非常に重要で誰も壊したくないため、大規模な変更への抵抗が強い。プッシュモデルからプルモデルへの移行は「既に動いているものをなぜ変える必要があるのか」という反発があった。 ### アラート設計の原則 - 症状にアラートすれば、個別マシンの負荷ではなくサービスレベルの影響が見え、アラートノイズが大幅に減る。 - すぐに対応不要な問題は JIRA チケットに送信し、チームがバックログとしてトリアージする。 - 各 Prometheus サーバーが他の全 Prometheus サービスを相互監視するメッシュ構成を採用。Alertmanager の稼働状況は `up` メトリクスと「アラートを受信しているが送信していないか」の 2 メトリクスで監視する。 ### エクスポータの運用原則 - サービスインスタンスごとに 1 つのエクスポータを配置する。全メトリクスを 1 プロセスに集中させるのは Prometheus のアンチパターンで、単一障害点になる。 - エクスポータは監視対象と同じ障害ドメインに配置する。Postgres サーバーを監視するなら、同じベアメタルサーバーでエクスポータを実行する。 ## 概念・実体への接続 - [[Cloudflare]]: エニーキャストエッジネットワーク運用。2017 年時点で 116 PoP。 - [[Prometheus]]: 各 PoP にローカル Prometheus を配置し、コアデータセンターへフェデレーションで集約。 - [[Matt Bostock]]: プラットフォームオペレーションチーム所属。ロンドン Prometheus ミートアップ主催者。 - [[アラート管理]]: 症状ベースアラーティング・Alertmanager によるグループ化・JIRA トリアージの組合せ。 - [[アクショナブルアラート]]: アラートのアノテーションにダッシュボード URL、Wiki リンク、サマリーを含める設計。 - [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]]: 本講演の 5 年後に公開された記事。Prometheus ルールの静かな失敗を [[pint]] で解決する後続の取り組み。 ## 限界・不確実点 - transcript は YouTube の自動字幕（日本語翻訳）であり、固有名詞の認識精度が低い（Nagios → "na jaws"、Alertmanager → "LOT マネージャ" 等）。映像フレームと公式ページで裏取りできた固有名はそちらを正とした。 - スライドの一部（frame-004 "Metrics for alerting"、frame-005 "Specification / Comments"）は解像度が低く、詳細なテキストを完全に読み取れていない。