Prometheus Federationの限界を突破せよ：マルチクラスター監視の「最適解」を設計する
こんにちは。オブザーバビリティの世界へようこそ。
Prometheusを触り始めると、誰もが一度は「単一のPrometheusですべてのメトリクスを回収する」という限界にぶつかります。特に、マルチクラスター環境で全ての情報を中央に集約しようとすると、ネットワーク帯域の枯渇とクエリの遅延という「地獄」が待っています。
今日は、そんな皆さんのために、Prometheus Federation（連合）の真の設計パターンと、それを超えるための実践的な知見を伝授します。これをマスターすれば、毎朝の監視アラートに追われる生活から解放され、より本質的な開発に集中できるようになりますよ。
—
1. なぜ「全収集」が失敗するのか？：Federationの落とし穴
多くの初心者は、全クラスターのメトリクスを一つのPrometheusに「まるごと」収集しようとします。しかし、これは以下の理由で破綻します。
- メモリの爆発（Cardinality Explosion）： 全メトリクスを集約すると、TSDB（時系列データベース）のインデックスが巨大化し、OOM（Out of Memory）を頻発させます。
- ネットワークのボトルネック： 数千のターゲットから毎分データを引き抜けば、インタークラスター通信の帯域を食いつぶします。
- 「単一障害点」のリスク： 中央のPrometheusがダウンすると、全クラスターの可視性が失われます。
「全てを把握しようとしないこと」。これが大規模監視の第一歩です。
—
2. 階層型メトリクス収集の設計パターン
効率的な設計の極意は、「生のデータはローカルに、分析データはグローバルへ」という階層化です。
基本構成：
1. Local Prometheus（エッジ）： 各クラスターに配置。詳細なメトリクスを保持。
2. Global Prometheus（センター）： 集約された「要約データ」のみを収集。
実践的な設定例：`scrape_configs`
Global Prometheus側で、必要なメトリクスのみを絞り込んで収集します。
scrape_configs:
- job_name: ‘federate-cluster-a’
scrape_interval: 1m
honor_labels: true # ローカルのラベルを保持する
metrics_path: ‘/federate’
params:
# 重要なメトリクスだけに絞ることで帯域を節約
‘match[]’:
- ‘{__name__=~”job:.”}’ # 集約済みのルール結果のみ
- ‘{__name__=”up”}’ # 各ノードの死活監視
static_configs:
- targets: [‘prometheus-local-a.example.com:9090’]
—
3. 精度を高めるための「現場のテクニック」
① Recording Rulesの活用（必須）
ローカルのPrometheusで事前に`recording rules`を使い、重い計算を済ませておきましょう。Globalには「計算結果」だけを送るのです。
ローカル側の設定例
groups:
- name: aggregation.rules
rules:
# サービス単位の平均リクエスト数を計算して送る
- record: job:http_requests:rate5m
expr: sum by (job) (rate(http_requests_total[5m]))
② ネットワーク負荷を抑える設定
- scrape_intervalの分離： ローカルは15秒、グローバルは1分〜5分にするだけで、帯域は劇的に改善します。
- remote_writeの検討： 最近は標準的なFederationよりも、`remote_write`を使ってPrometheus互換のストレージ（ThanosやVictoriaMetricsなど）に流し込む手法が主流です。Federationに固執せず、適材適所でツールを選びましょう。
—
4. 最初の一歩：HelloWorld的な動作確認
まずは、手元のPCで「2つのPrometheus」を連携させてみましょう。
1. ローカル用Prometheusを起動： `prometheus –config.file=local.yml`
2. グローバル用Prometheusを起動： 上記の`scrape_configs`を設定し、`prometheus –config.file=global.yml`で起動。
3. 確認： グローバル側のWeb UI（`http://localhost:9090`）の「Status > Targets」を開き、ローカルのターゲットが`UP`になっていることを確認してください。
—
先輩からのアドバイス
「監視システムそのものを監視する」ことを忘れないでください。Prometheusが落ちていれば、その背後のサービスが正常かどうかも分かりません。
- まずは最小限のメトリクスから： いきなり全てを統合しようとせず、`up`メトリクスだけを集めることから始めましょう。
- アラートの階層化： ローカルでは詳細な障害を、グローバルでは「サービス全体が死んでいるか」という高次元な障害のみを検知するように設計すると、夜中に叩き起こされる回数が激減します。
オブザーバビリティは、ツールを入れることではなく、「何が起きているかを解像度高く理解する」ためのプロセスです。焦らず、一歩ずつシステムの解像度を上げていきましょう。
何か詰まったら、いつでも聞いてください。応援していますよ。