# カーディナリティ ## 定義 カーディナリティとは、あるメトリクスにおける全ラベルの一意な組み合わせ(=時系列)の数である。ラベルの数が増えるほど、また各ラベルが取りうる値のバリエーションが増えるほど、生成される時系列数は組み合わせ的に増加する。([[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale|How Cloudflare Runs Prometheus at Scale]]) ## カーディナリティ爆発のリスク要因 - リクエストパスや URL など、外部からの入力に由来する値をラベルに使う - 生の例外オブジェクトやスタックトレースをラベル値に使う(ファイルパスや接続先アドレスが混入し、意図せず高カーディナリティ化する) - 信頼できない外部データ全般をラベル値に使う 1,000件のランダムなリクエストを送るだけで1,000本の新規時系列が生成されうる。カーディナリティ爆発が起きると、時系列が短時間で急増し Prometheus のメモリを枯渇させてサーバーをクラッシュさせ、observability そのものを失う。([[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale|How Cloudflare Runs Prometheus at Scale]]) ## メモリコストの構造的な理由 [[Prometheus]] は時系列を `memSeries` としてメモリ上の `Head` に保持し、2時間の壁時計スロットで chunk を作る。1回しかスクレイプされなかった時系列でも、chunk のブロック書き込みとガベージコレクションのタイミング上、1〜3時間はメモリに残り続けることが保証される。つまり短命な時系列は、保持する情報量に対して不釣り合いにコストが高い。([[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale|How Cloudflare Runs Prometheus at Scale]]) ## 緩和策の2系統 ### 収集元での抑制(Cloudflare の scrape limits + 独自パッチ) - ラベル数上限64、ラベル名128文字・ラベル値512文字上限、`sample_limit` 既定200を全スクレイプに適用 - PR マージ前に CI で全 Prometheus サーバーの空き容量を検証 - 標準 Prometheus は `sample_limit` 超過時にスクレイプ全体を失敗させるが、Cloudflare は独自パッチで TSDB 全体の時系列数上限を設け、上限超過時も既存系列への追記は許可しつつ新規系列の作成のみを間引く graceful degradation を実装した(既存系列への追記は安価、新規系列作成は高価という原則に基づく)。([[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale|How Cloudflare Runs Prometheus at Scale]]) ### 集約による抑制(Flipkart の階層フェデレーション) - ローカル Prometheus で recording rule により instance ラベルなど不安定な高カーディナリティ次元を除去し、クラスタレベルのデータのみ保持する - p95/p99 のようなインスタンス単位のパーセンタイルを平均・最大・最小の要約統計に置き換える - 集約済み系列だけを `/federate` 経由で上位へスクレイプし、8000万系列を数万のクラスタレベルメトリクスへ圧縮した([[@2025__InfoQ__Flipkart-Prometheus-80-Million-Time-Series|Flipkart Prometheus 80M]]) 両者は対症療法として補完関係にある: Cloudflare の方式は個々のスクレイプ・インスタンス単位でメモリ枯渇を防ぐランタイム防御、Flipkart の方式はメトリクス設計・パイプライン段階でそもそも高カーディナリティ次元を上位に伝播させないアーキテクチャ的抑制である。 ## 未解決の問い - Cloudflare の TSDB 総数上限パッチと sample_limit の graceful degradation パッチ(prometheus/prometheus#11124)は、Prometheus 本家にどこまで取り込まれたか。 - 階層フェデレーションによる集約とサンプリング(集約済み値のみ保持)は、Cloudflare 方式が防ぐ「個々のノイズの多いスクレイプによるメモリ枯渇」と同じ障害モードにどこまで対処できるか、あるいは異なる障害モード(クラスタ横断のインスタンス単位障害箇所特定の喪失)を新たに生むか。 ## 未編纂の観察 - コスト抑制のためにカーディナリティを削る運用側の文献とは逆に、Honeycomb は高カーディナリティ・高次元で任意の次元を切れることを、人間と AI の双方が本番を理解するための前提条件として掲げる(Source: [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]]) ## 関連 - エンティティ: [[Prometheus]] / [[Cloudflare]] / [[Flipkart]] - コンセプト: [[時系列データベース]] - ソース: [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]] ## 出典 - [[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale|How Cloudflare Runs Prometheus at Scale]](カーディナリティの定義・Prometheus 内部構造・Cloudflare の3層防御) - [[@2025__InfoQ__Flipkart-Prometheus-80-Million-Time-Series|Flipkart Prometheus 80M]](階層フェデレーションによる集約でのカーディナリティ削減) - [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]](高カーディナリティ擁護の立場)