Prometheus Federationの限界を突き破れ：マルチクラスター監視のアーキテクチャ解体新書
現場のテックリードとして言わせてもらう。君たちが今、教科書通りに組んでいるPrometheus Federationは、「スケールしない地雷」だ。
「とりあえずFederationで親Prometheusに集約すればいい」――その考えが、数ヶ月後のメトリクスのカーディナリティ爆発と、ネットワーク帯域の飽和、そして「なぜかクエリがタイムアウトする」という深夜の悲劇を招く。
今日は、マルチクラスター環境で「真に戦える」オブザーバビリティ基盤を築くための、一段上の設計論とテクニックを共有する。
—
1. なぜ「伝統的なFederation」は破綻するのか
Prometheusの`federation`エンドポイント（`/federate`）は、「重い」。
親Prometheusが子Prometheusからデータをプルする際、単なるデータ転送ではなく、内部的な計算とメモリ消費が発生する。
- カーディナリティの罠: 数千のPodが動く環境で全メトリクスをFederationすると、親Prometheusのメモリは一瞬で食い尽くされる。
- 単一障害点のリスク: 親Prometheusがダウンすれば、全クラスタの可観測性が死ぬ。
- ネットワークの浪費: 圧縮効率の悪い大量のデータを、リージョンを跨いでダラダラと送り続けるのは、クラウドコストの無駄遣いだ。
結論：Federationは「集約」ではなく「境界」として使うべきだ。
—
2. 突破口：階層型収集設計と「Thanos/Cortex」への橋渡し
現代のマルチクラスター監視における解は、単純なFederationではなく、「サイドカー・リレー方式」への移行だ。
推奨アーキテクチャ
1. Local Prometheus: 各クラスター内で、短期保存（数日分）を担う。高解像度のメトリクスはここで完結させる。
2. Global Aggregator: Federationではなく、[Thanos](https://thanos.io/) の `Querier` または `Prometheus Agent Mode` を活用する。
もし、今すぐThanosを導入できないなら、Federationの設定で以下を徹底しろ。
【ベストプラクティス】federation_configの書き方
`match[]` を使って、必要なメトリクスだけを厳選（Drop）する。「全部取ってくる」は悪だ。
prometheus.yml (Global Aggregator側の設定)
scrape_configs:
- job_name: ‘federate-cluster-a’
scrape_interval: 1m # 頻繁に叩くな、負荷になる
honor_labels: true
metrics_path: ‘/federate’
params:
‘match[]’:
# 必要なメトリクスのみをホワイトリスト化する
- ‘{job=”kube-state-metrics”}’
- ‘{__name__=~”node_cpu_.”}’
- ‘{__name__=~”http_requests_total”}’
static_configs:
- targets: [‘prometheus-cluster-a.monitoring.svc:9090’]
—
3. 生産性を加速させる「現場の神」テクニック
① プロのキーボードショートカット（Prometheus UI）
意外と知られていないが、UIでのクエリ発行を劇的に速くする。
- `Ctrl + Enter`: クエリ実行。マウスに手を伸ばすな。
- `Shift + Up/Down`: クエリ履歴の遡行。
- `Esc`: 入力フィールドからの即時離脱。
② 絶対入れるべき「神プラグイン」: PromLens
Prometheusのクエリ（PromQL）は、複雑になると「なぜその値になったのか」がブラックボックス化する。[PromLens](https://promlens.com/) を導入してくれ。PromQLの実行計画を可視化し、どこでカーディナリティが爆発しているか、どのラベルが重いかを秒で特定できる。
③ 設定共有のルール（GitOpsの極意）
設定ファイルは「手動でいじったら負け」だ。以下のディレクトリ構成を徹底せよ。
/monitoring-base
├── /rules # アラートルールは共通化する
├── /scrape-configs # クラスターごとの差異は環境変数で埋め込む
└── /values.yaml # Helmでのデプロイを前提にする
ルール: `alerts.rules` には、必ず `severity` ラベルを入れろ。「警告」と「即時対応」をコードベースで分離しておくことが、アラート疲弊を防ぐ唯一の手段だ。
—
4. 最後に：エンジニアへのメッセージ
Prometheusは「監視ツール」ではない。「システムの健康状態をコードとして扱うプラットフォーム」だ。
Federationの限界を感じているなら、それは君のシステムが成長した証だ。次に目指すべきは、Prometheusの背後にオブジェクトストレージ（S3/GCS）を控える「Thanos」や「Cortex」といった、ロングタームストレージを備えたアーキテクチャへの進化だ。
監視の設計は、コードの設計と同じくらい論理的で、美しいものであるべきだ。
さあ、今すぐ設定ファイルを開き、不要なメトリクスの収集を止めることから始めてくれ。その一行が、将来の「障害時の焦り」を減らす投資になる。
君の監視が、夜中に鳴り響く不必要なアラートから解放されることを願っている。