Prometheus Federationの亡霊を葬る：マルチクラスター監視の「死線」を越える設計論
Prometheus Federation。この言葉を耳にして「便利だ」と感じる段階は、君たちがまだ初心者である証拠だ。
確かに、公式ドキュメントにある「階層型アーキテクチャ」は美しい。しかし、プロダクション環境で数百万時系列（TSDB）を抱えた瞬間にその美学は崩壊する。Federationは、単なるクエリの転送プロトコルではない。それは、メモリを食らい、ネットワークを飽和させ、最終的にはグローバル側のPrometheusを死に至らしめる「自爆装置」になり得る。
今日は、Federationの限界を認め、その先にある「真のマルチクラスター・スケーリング」をどう実装するか、現場の血と汗が染み込んだ知見を共有する。
—
1. Federationが抱える「避けられない死」のメカニズム
なぜ、安易なFederationは失敗するのか。理由は3つある。
1. スクレイピングの線形コスト増: グローバルPrometheusが各リージョンのPrometheusをポーリングする際、TSDBのインデックスを再構築し、膨大な`/federate`エンドポイントへのリクエストがメモリを圧迫する。
2. クエリの直列化ボトルネック: ネットワークの揺らぎが、グローバル側のクエリ処理全体をストールさせる。
3. データ欠損（Gaps）の連鎖: ネットワーク分断時、Federationは単純なPull型であるため、データ復旧（バックフィル）のコストが異常に高い。
これらを解決するには、「収集」と「保存」を切り離す（Decoupling）という発想の転換が必要だ。
—
2. 推奨設計：Prometheusを「エッジ」と「ストア」に分離せよ
もはやPrometheus単体で全データを抱えるのは愚策だ。我々が取るべきは、「Prometheus Agentモード + Thanos/Cortex/Mimir」の構成である。
階層型収集のアーキテクチャ設計
- エッジ（Local）: Prometheusを`Agentモード`で起動。長期保存を放棄し、スクレイピングと一時的なバッファリングに特化させる。
- ストア（Global）: `Thanos Sidecar`または`Remote Write`を活用し、オブジェクトストレージ（S3/GCS）へデータをオフロードする。
これにより、グローバル側のPrometheusは「データを保持し続ける」という呪縛から解放される。
—
3. 極限の最適化ハック：設定と運用の極意
A. Agentモードへの切り替え（メモリ削減の決定打）
通常のPrometheusから余分なメモリ消費を取り除くため、`–enable-feature=agent`を有効にしろ。これにより、TSDBのインデックス管理コストがほぼゼロになる。
Prometheus Agent用設定例 (prometheus.yml)
global:
scrape_interval: 15s # 密度の高い監視を維持
remote_write:
- url: “http://thanos-receive.monitoring.svc:19291/api/v1/receive”
queue_config:
# メモリ消費を抑制するための「極限」設定
capacity: 2500
max_shards: 200
min_shards: 10
max_samples_per_send: 2000
batch_send_deadline: 5s
B. 高密度環境での「スクレイピング効率化」
マルチクラスター環境では、ターゲットの動的検出（Service Discovery）がネットワークを食いつぶす。
- Relabelingの徹底: 不要なメトリクスを収集段階で捨てる（Drop）。特に`kube-state-metrics`の不要なラベル（`pod_template_hash`など）は、時系列数を爆発させる原因だ。
不要なメトリクスの破棄（メモリ/帯域節約）
metric_relabel_configs:
- source_labels: [__name__]
regex: ‘kube_pod_container_status_ready|kube_pod_container_status_waiting’
action: drop
—
4. 自動化：APIを叩いて構成を「正」に保つ
マルチクラスター監視の最大の敵は「設定のドリフト」だ。クラスターが増えるたびに手動で設定を追加するなど論外だ。
Pythonによる動的レジストリ登録スクリプト（概念）
Kubernetes APIから各リージョンのPrometheusエンドポイントを自動検出し、グローバル側のサービスディスカバリ設定を更新する仕組みを作れ。
import requests
def update_global_prometheus_target(cluster_id, endpoint):
“””
動的にPrometheusのスクレイプ設定を更新するハック。
ConsulやK8sのConfigMapをバックエンドに持つのが定石。
“””
payload = {“cluster”: cluster_id, “targets”: [endpoint]}
# 実際にはここでK8s CRD (PrometheusRule等) を更新してConfigReloaderを叩く
response = requests.post(“http://global-prom/api/v1/reload”)
return response.status_code
—
5. アーキテクトからの「最後の一言」
君たちが目指すべきは、「メトリクスがネットワークを越える時のコスト」を物理的に理解することだ。
1. Federationは捨てろ：単一のPrometheusにデータを集めるな。Object Storageを真のデータストアにせよ。
2. Remote Writeのバックプレッシャーを監視せよ：`prometheus_remote_storage_samples_failed_total`が1でも上がったら、それは設計の敗北だ。
3. カーディナリティ（時系列数）の暴走を許すな：メトリクス名は「インフラの資産」だ。開発者に「ラベルの切り方」を教育することこそ、真のオブザーバビリティの第一歩だ。
ツールはただの道具だ。しかし、その道具を「どう使い倒すか」に、エンジニアとしての魂が宿る。マルチクラスター監視の深淵へようこそ。健闘を祈る。