# How Cloudflare Runs Prometheus at Scale **Cloudflare Blog, 2023-03-03**(著者: Lukasz Mierzwa) | [[Cloudflare]] が [[Prometheus]] を大規模運用する上での**カーディナリティ**問題と、それを支える TSDB 内部構造・独自パッチを詳解する記事。前作 [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]](pint によるルールリント)の続編にあたる。 ## 規模 執筆時点で916の Prometheus インスタンス、合計約49億時系列。平均約500万系列/インスタンス、最大級のインスタンスは約3000万系列を保持する。 ## カーディナリティの定義とリスク カーディナリティとは、あるメトリクスの全ラベルの一意な組み合わせ数である。ラベル値が外部入力(リクエストパス、生の例外オブジェクト・スタックトレース等)に由来する場合、悪意の有無を問わず時系列数が爆発的に増加しうる(1,000件のランダムリクエストで1,000本の新規系列)。詳細な定義とメカニズムは [[カーディナリティ]] に集約する。 ## Prometheus のメモリモデル(時系列のライフサイクル) 1. **HTTP スクレイプ**: 設定された間隔でターゲットへリクエストし、スクレイプ時刻を記録する。 2. **新規系列か更新か**: 全ラベル(暗黙の `__name__` を含む)を SHA256 でハッシュし TSDB の主キーとする。 3. **TSDB への追記**: `Head` というマップ(キー=ラベルハッシュ、値=`memSeries`)に格納する。`memSeries` はラベルのコピーと chunk(varbit 圧縮されたサンプル列)を保持する。chunk は2時間の壁時計スロットごとに作られ、最大120サンプル/chunkで、追記可能なのは直近の "Head Chunk" のみ。 4. **古い chunk のメモリマップ化**: 非 Head の chunk はディスクへ書き込みメモリマップされ、クエリで参照されない限り RAM を消費しない。 5. **ブロック書き込み**: 2時間ごと(chunk 作成から1時間ずらして)chunk がブロックとしてディスクへ永続化されメモリから外れる。Cloudflare の最大級インスタンスは毎秒55万サンプルを追記している。 6. **ガベージコレクション**: ブロック書き込み後、chunk を失った(=スクレイプが止まった)`memSeries` を Head から除去する。 **要点**: 1回しかスクレイプされなかった時系列でも、上記のブロック書き込み・GCタイミングにより1〜3時間はメモリに残り続けることが保証される。短命な時系列は保持する情報量に対して不釣り合いにコストが高い。 ## Prometheus 標準の防御と限界 `sample_limit` 等のスクレイプ設定上限は存在するが、**上限を超えると当該スクレイプ全体が失敗する**設計になっている(部分的スクレイプの扱いが難しく、失敗として扱う方が安全という設計判断)。 ## Cloudflare の3層防御 1. **基本制限(全スクレイプ既定)**: ラベル数上限64、ラベル名128文字・ラベル値512文字上限、`sample_limit` 既定200。必要なチームは明示的に緩和できる。 2. **CI 検証**: スクレイプ設定を変更する PR について、増加する時系列数に対して全 Prometheus サーバーに十分な空き容量があるかを事前検証し、なければマージをブロックする。 3. **独自パッチ(PR [prometheus/prometheus#11124](https://github.com/prometheus/prometheus/pull/11124)、未マージ)**: - **TSDB 総数上限パッチ**: TSDB が保持できる時系列の総数に上限を設け、上限到達後は既存系列への追記(安価)は許可しつつ、新規系列の作成(高価)だけを間引く。標準 Prometheus にはこの概念自体が存在しない。 - **sample_limit の graceful degradation**: 上限超過時にスクレイプ全体を失敗させるのではなく、既存系列のみ受理し新規系列作成だけを間引く。同じ「既存系列への追記は安価、新規系列作成は高価」という原則をスクレイプ単位に適用したもの。 - 両パッチにより、上限超過を示すメトリクスから責任チームへアラートが飛び、承認者不要のセルフサーブ容量管理が可能になる。 ## 設計思想 Cloudflare はハードな失敗より優雅な劣化(graceful degradation)を優先し、Prometheus の専門知識がなくてもエンジニアが自信を持ってメトリクスを出荷できることを重視する。「起こりうる全ラベル組み合わせ数」と「実際に観測される組み合わせ数」は大きく異なることが多く、静的な事前検証だけに頼らずランタイムでの保護と内部ドキュメント整備を組み合わせる。 ## 関連 - エンティティ: [[Cloudflare]] / [[Prometheus]] - コンセプト: [[カーディナリティ]] / [[時系列データベース]]