Skip to content
Published on

Prometheus 実運用ガイド: TSDB、カーディナリティ、Recording Rules、Federation、Remote Write

🇰🇷KO🇺🇸EN🇯🇵JA
Split View✨Start Quiz
Authors
Prometheus 実運用ガイド

はじめに

Prometheusは導入自体は簡単ですが、上手に運用するのは簡単ではありません。exporterを少し増やしGrafanaを接続した段階では順調でも、時間が経つとほぼ必ず次の問題が出てきます。

  • TSDBのディスク使用量が急増する
  • ラベル設計が崩れてhigh-cardinality問題が発生する
  • ダッシュボードとアラートが同じ重いPromQLを何度も実行する
  • 複数クラスタや複数リージョンでの集約が必要になる
  • 長期保持のためにfederationかremote writeかを選ぶ必要が出る

Prometheus運用の本質は、単に「もっと多くのメトリクスを集めること」ではありません。どのメトリクスを、どの保持期間で、どのコスト範囲で維持するのかを設計することです。

TSDB運用の基本: retentionは保存設定ではなくコスト方針

Prometheusの内蔵TSDBは扱いやすい一方で、retention設計が曖昧だとすぐにディスク圧迫や再起動時間の増大に繋がります。

最初に決めるべきことは二つです。

  • ローカルPrometheusが何日分のデータを保持するべきか
  • 長期保持が必要ならどこへ出すのか

多くの本番環境では、ローカルPrometheusは短期保持の高性能運用ストアとして扱い、長期履歴は外部へ逃がす方が安全です。

storage:
  tsdb:
    retention.time: 15d

運用時の確認ポイントは次の通りです。

  • retention timeかretention sizeのどちらが実際の制約になっているか
  • WALとblock compactionがディスク予算と合っているか
  • 再起動後のreplay時間が長すぎないか
  • 現在のingest量に対してディスクIOPSが足りているか

TSDBディスク問題は単なる保存容量不足ではなく、メトリクス設計が既に高コストになっている合図であることが多いです。

カーディナリティは設計品質の問題

なぜhigh cardinalityが危険なのか

Prometheusではmetric nameだけでなく、すべてのlabel組み合わせが時系列数を増やします。user_id、session_id、request_idのような一意性の高い値をlabelに入れると、運用はすぐに不安定になります。

カーディナリティが上がると、次の全てが悪化します。

  • メモリ使用量
  • クエリ遅延
  • ディスク使用量
  • compaction時間
  • rule evaluationコスト

実務で守るべき基準

  • unbounded identifierをlabelに入れない
  • アラートとダッシュボードに本当に必要なlabelだけ残す
  • exporterのデフォルトメトリクスを無条件で全部取らない
  • 新規サービス追加時にlabel reviewを必須にする

Prometheusで最も効果の高いコスト最適化の一つは、新しいサーバを増やすことではなく、意味のないlabelを消すことです。

Recording RulesとAlerting Rulesは分けて設計する

Recording Rulesは計算コスト削減の層

重いPromQLをダッシュボードとアラートが毎回直接実行すると、利用者数と評価回数に比例してコストが増えます。繰り返し使う式はrecording ruleで事前計算しておくのが有効です。

groups:
  - name: service-latency
    interval: 30s
    rules:
      - record: job:http_request_duration_seconds:rate5m
        expr: sum by (job) (rate(http_request_duration_seconds_count[5m]))

recording ruleが有効なのは次のような場面です。

  • 複数ダッシュボードが同じ重い式を共有するとき
  • SLI計算を標準化したいとき
  • federationや下流システムに軽い集約済み系列を渡したいとき

Alerting Rulesは運用契約として設計する

良いアラートは複雑なPromQLではなく、意味の明確さと反応手順で決まります。

groups:
  - name: service-alerts
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (job)
          / sum(rate(http_requests_total[5m])) by (job) > 0.05
        for: 10m

実運用で重要なのは次です。

  • 意味が安定していること
  • for で一時的なノイズを抑えること
  • annotationに文脈を入れること
  • runbookと結び付けること
  • label fanoutを増やしすぎないこと

FederationとRemote Writeは目的が違う

Federationが向く場面

federationは、上位Prometheusが下位Prometheusから選択された集約メトリクスだけをscrapeするモデルです。

向いているケースは次の通りです。

  • 複数クラスタの要約メトリクスだけを上位で見たい
  • 地域別またはクラスタ別Prometheusを独立運用したい
  • 中央側にはraw series全体ではなくrollupだけ必要

Remote Writeが向く場面

remote writeは、外部ストレージや長期保存基盤へメトリクスを送る仕組みです。

向いているケースは次の通りです。

  • 長期保持が必要
  • 中央multi-tenantストレージが必要
  • 全体横断の分析や長期傾向を見たい
  • ローカルPrometheusの保持期間を短くしたい

両者は似て見えますが、federationは階層集約、remote writeは外部保存とスケールに近い設計です。

必ず文書化したい項目

Prometheusは設定ファイルだけのツールではなく、運用システムです。次の項目は明示的に文書化した方がよいです。

1. メトリクス追加基準

  • どのmetricとlabelを許可するか
  • label reviewを誰が行うか
  • exporterデフォルトのどこまで残すか

2. ルール管理基準

  • recording ruleとalert ruleのownerは誰か
  • rule evaluation intervalの基準は何か
  • すべてのalert annotationにrunbook URLを入れるか

3. 保存戦略

  • ローカルretentionは何日か
  • remote write先は何か
  • 障害時にどの範囲のメトリクス欠損を許容するか

4. 運用SLO

  • query latency SLO
  • target scrape success rate
  • rule evaluation success rate
  • TSDB disk usage upper bound

実運用チェックリスト

継続的に確認したいのは次の項目です。

  1. scrape failureが増えていないか
  2. 直近のデプロイ後に時系列数が急増していないか
  3. 最も高価なdashboard queryとalert queryは何か
  4. recording ruleへ置き換えられないか
  5. ローカルretentionがディスクや再起動時間を圧迫していないか
  6. federationとremote writeの目的が混ざっていないか

Prometheusは無制限の観測バケツではなく、メトリクス経済を管理するシステムとして扱う方が長く安定します。

まとめ

Prometheus運用の軸は、高カーディナリティを抑え、recording ruleで計算コストを下げ、保存戦略を分離し、運用基準を文書化することです。

特に次の四つは早い段階で決めておく価値があります。

  • high-cardinality label禁止原則
  • recording rule優先設計
  • alert ruleの for とrunbook接続
  • federationとremote writeの役割分離

うまく運用されるPrometheusは、より多くのメトリクスを集めるシステムではなく、より良いメトリクスをより低いコストで保つシステムです。

References

Discuss on Twitter • View on GitHub