Part 5. Prometheusの運用の基本 ​

はじめに ​

Part 1～4で、Prometheusの構築から運用基盤まで学んできました。ここからは「本番環境で安定して運用し続ける」実務フェーズに入ります。

導入後の運用では、毎日のリソース監視、定期的なメンテナンス、バージョンアップへの対応が発生します。これらを効率的に進めることが、長期的な安定運用につながります。

このパートでは、リソース監視の方法、ディスク容量を管理するリテンション設定、バージョンアップの基本的なフローを学びます。

運用業務の日常フロー ​

Prometheusの運用では、定期的に確認すべき項目と、異常時の対応フローがあります。典型的な運用の流れを図で示します。

毎日の確認項目としては、以下のようなポイントがあります。

メモリとディスクの状態確認 は最優先です。Prometheusはメモリに時系列データをキャッシュし、定期的にディスクに書き込みます。メモリが満杯になると新しいメトリクスが記録できなくなり、ディスクが満杯になるとプロセスが強制終了される可能性があります。

アラート状態の確認 は、PrometheusのWebUI（localhost:9090/alerts）またはAlertManagerダッシュボード（localhost:9093）で行います。未解決のアラートがある場合は、原因を特定して対応します。

スクレイプ対象の生存確認 は、localhost:9090/targets で実施します。Down状態が多発していないか、新規ターゲットが正常にスクレイプされているかを確認します。

定期的なメンテナンスとしては、週1～2回のログ確認、月1回のデータベース検証（データ破損チェック）、四半期ごとのバージョンアップ検討などが挙げられます。

リソース監視の基本 ​

Prometheusが長期間安定して稼働するためには、メモリ、ディスク、CPU の3つのリソースを継続的に監視することが欠かせません。それぞれの監視方法と目安を見ていきます。

Prometheusのリソース監視は、3つの観点で定期的に確認する必要があります。以下の図は、各リソースの監視ポイントと対応方法を示しています。

メモリ使用量の監視 ​

Prometheusのメモリ使用量は、「スクレイプ対象の数」と「メトリクス数」に大きく左右されます。各ターゲットから100個のメトリクスを取得し、スクレイプ対象が100個あれば、約10,000個のメトリクスをメモリに保持することになります。なお、実際のメモリ使用量には、WAL（Write-Ahead Log）やメモリ内チャンク管理のオーバーヘッドも含まれるため、見積もり時には20～30%の余裕を見積もることをお勧めします。

環境規模ごとの一般的な目安は以下の通りです。

  • 小規模環境（ターゲット数10以下） → 約100MB～500MB
  • 中規模環境（ターゲット数50程度） → 約1GB～5GB
  • 大規模環境（ターゲット数200以上） → 約10GB～50GB

メモリ使用状況を監視するには、Prometheusプロセス自身のメトリクスを活用します。Grafanaで以下をクエリして、グラフ化すれば、メモリ使用量の時間経過での傾向を把握できます。

promql
process_resident_memory_bytes{job="prometheus"}

メモリが徐々に増加している場合は、スクレイプ対象やメトリクス数の増加が原因の可能性があります。

ディスク使用量の監視 ​

Prometheusはメトリクスをディスクに保存しており、ディスク使用量は「リテンション期間」と「スクレイプ量」で決定します。簡易的な計算は以下の通りです。

推定ディスク使用量 = 1日あたりのスクレイプデータ量 × リテンション期間（日）

例えば、1日1GBのデータが記録され、リテンション期間が15日であれば、最大で15GBの容量が必要です。実際には定期的なブロック圧縮があるため、これより少ないことが多いですが、計画時には余裕を見積もることが大切です。

ディスク使用量が上限の70～80%に達したら、リテンション期間の短縮やスクレイプ対象の削減を検討すべき時期です。

CPU負荷の監視 ​

CPU 負荷は、メトリクス取得（スクレイプ処理）とクエリ処理の2つで構成されます。スクレイプは定期的に実行されるため、スクレイプ間隔とスクレイプ対象数に応じて CPU 負荷が変動します。

CPU 負荷が常に高い場合は、スクレイプ間隔を長くしたり、大量のクエリを実行しているクライアント（Grafanaなど）のクエリを最適化したりする対応が必要です。Grafanaで以下をクエリして監視できます。

promql
rate(process_cpu_seconds_total{job="prometheus"}[5m])

リテンション設定の基本 ​

Prometheusのリテンション設定は、「いつまでのデータを保持するか」を制御します。リテンション期間が長いほどディスク容量が必要になり、短いほどディスク使用量が減ります。本番環境での適切な設定が重要です。

Prometheusには、2つのリテンション制御方法があります。

時間ベースのリテンション ​

--storage.tsdb.retention.time フラグで、データの保持期間を指定します。デフォルトは15日です。

※ --storage.tsdb.retention.time と --storage.tsdb.retention.size のフラグは、公式ドキュメントで非推奨（deprecated）とされています。現在は設定ファイル（prometheus.yml）の storage.tsdb.retention で指定することが案内されています（設定例は後述）。

bash
prometheus \
  --storage.tsdb.retention.time=15d

期間の指定は、d（日）、h（時間）、m（分）が使えます。例えば、30d であれば30日間、720h であれば30日間のデータを保持します。

運用の現実では、以下のような設定が一般的です：

  • 開発環境 → 1～3日（ディスク容量限定）
  • 本番環境（標準） → 15～30日
  • 本番環境（長期保存） → 90日～1年以上

容量ベースのリテンション ​

--storage.tsdb.retention.size フラグで、最大ディスク使用量を指定します。

bash
prometheus \
  --storage.tsdb.retention.size=100GB

容量に達すると、古いデータから削除されます。この方法は、ディスク容量が固定されている場合に有効です。

実際の運用では、両方を組み合わせる場合が多いです。以下は、Docker Compose での設定例です（詳細設定は公式リポジトリを参照）。

yaml
services:
  prometheus:
    image: prom/prometheus:v3.13.5
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus

この例では、リテンション（保持期間15日、上限100GB）を、マウントした prometheus.yml の storage.tsdb.retention で指定する想定です（設定例は後述）。

設定ファイルでの指定（推奨）：公式ドキュメントでは、フラグの代わりに prometheus.yml の storage.tsdb.retention を使うよう案内されています。設定ファイルの値は、フラグより優先されます。なお、設定ファイルでのリテンション指定は比較的新しい機能です。3.11 のリリースノートで関連する修正が確認できるため、LTS の 3.13 では利用できますが、これより古い 3.x を使う場合は、利用バージョンの公式ドキュメントで対応を確認してください。

yaml
# prometheus.yml
storage:
  tsdb:
    retention:
      time: 15d
      size: 100GB

詳細は 公式ドキュメント - Storage と 設定リファレンス を参照してください。

バージョンアップの基本フロー ​

新しいバージョンがリリースされた場合、セキュリティ修正や機能追加を取り入れるためにアップグレードする必要があります。計画的で段階的なアップグレードが、運用の安定性を保つ鍵になります。

ステップ1：アップグレード前の確認 ​

まず、現在のバージョンと、利用可能な最新バージョンを確認します。

bash
# 現在のバージョン確認
prometheus --version

# リリースノートを確認
# https://github.com/prometheus/prometheus/releases

重要なのは、リリースノートを詳しく読み、非互換性がないかを確認することです。特に、メジャーバージョン（例：2.x → 3.x）の場合は、互換性の破壊的な変更があります。

2.x から 3.x への主な変更点（詳細は 公式の移行ガイド を参照）：

  • ダウングレード不可：3.x の TSDB は v2.55 以降でしか読めません。v2.55 より前には戻せないため、先に v2.55 へ上げて動作確認する方法もあります
  • Alertmanager v1 API の廃止：Alertmanager 0.16.0 以降が必要で、設定は api_version: v2 にします
  • le / quantile ラベルの正規化：le="1" は le="1.0" として取り込まれます。le="1" を参照しているアラート・ルール・ダッシュボードは修正が必要です
  • スクレイプの Content-Type 検査の厳格化：ヘッダーが無い、または不正なエンドポイントはスクレイプに失敗します（回避策は fallback_scrape_protocol）
  • PromQL の変更：正規表現の . が改行にもマッチします。範囲セレクタの左端が開区間になります。holt_winters は double_exponential_smoothing に改名され、実験的機能の扱いです
  • UTF-8 のメトリクス名・ラベル名：従来の検証を使うには metric_name_validation_scheme: legacy を設定します
  • ログ形式の変更：log/slog 形式になります
  • フィーチャーフラグの整理：agent は --agent、remote-write-receiver は --web.enable-remote-write-receiver に移りました

ステップ2：アップグレード手順 ​

本番環境へのアップグレードの基本的な流れは以下の通りです。

1. バックアップ: ディスク上のデータディレクトリ全体をバックアップします。万が一のトラブルに備えます。

bash
# データディレクトリをバックアップ
cp -r /path/to/prometheus/data /path/to/prometheus/data.backup

2. Prometheusの停止: 実行中の Prometheus プロセスを停止します。

bash
# Prometheusプロセスを確認
ps aux | grep prometheus

# 停止（systemdの場合）
sudo systemctl stop prometheus

# 停止（手動起動の場合）
kill -SIGTERM <PID>

3. バイナリの置き換え: 新しいバージョンのバイナリを配置します。

bash
# 新しいバージョンをダウンロード
cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v3.13.5/prometheus-3.13.5.linux-amd64.tar.gz

# 解凍して新しいバイナリをコピー
tar -xzf prometheus-3.13.5.linux-amd64.tar.gz
cp prometheus-3.13.5.linux-amd64/prometheus /usr/local/bin/prometheus

4. Prometheusの起動: 新しいバージョンで Prometheus を起動します。

bash
# 起動（systemdの場合）
sudo systemctl start prometheus

# ログで異常がないか確認
sudo journalctl -u prometheus -f

ステップ3：アップグレード後の確認 ​

アップグレード直後は、Prometheus が正常に動作しているかを複数の観点から確認します。

Web UI への接続確認:

bash
curl

ステータスコード 200 が返れば、Prometheus が起動しています。

メトリクス取得確認:

bash
curl

スクレイプ対象がすべて Up 状態になっているか確認します。

アラート状態確認:

bash
curl

新しいバージョンで既存のアラートルールが正しく評価されているか確認します。

アップグレード後は、少なくとも数時間は監視チームが待機状態になるなど、トラブル発生時に素早く対応できる体制を取ることをお勧めします。

本番運用での注意点 ​

Prometheusを長期間安定して運用するためのポイントをいくつか挙げます。

定期的な疎通確認 は欠かせません。Web UI、AlertManager、Grafana など、監視スタック全体の疎通を定期的（週1回程度）に確認しましょう。

ディスク満杯の予防 が重要です。リテンション設定を定期的に見直し、ディスク使用量が上限の80%を超えないようにしましょう。

バージョン情報の記録 は、トラブル時の対応に役立ちます。アップグレード日時、バージョン、変更内容をログに記録しておくと、問題が発生した場合の原因特定が早くなります。

段階的な更新 をお勧めします。開発環境でのテスト、ステージング環境での検証、本番環境への本格的な適用というステップを踏むことで、リスクを最小化できます。

次のステップ ​

Part 5では、Prometheus 運用の日常的なタスクを学びました。次のパートでは、さらに深掘りした運用スキルを習得します。

Part 5-1：性能チューニング では、Prometheus のメモリやディスク使用量を最適化し、大規模環境での安定運用を実現するための技術を学びます。

Part 5-2：トラブルシューティング では、障害発生時の原因特定方法と、よくある問題への対応パターンを習得します。

Part 5-3：ベストプラクティス では、エンタープライズ環境での運用ノウハウをまとめて、本当に頼れる監視基盤の構築方法を学びます。

ナビゲーション ​

前のセクション：

次のセクション：Part 5-1 - 性能チューニング