Contents
1. Prometheus と Alertmanager の全体像
Prometheus がメトリクスを収集・保存し、Alertmanager がそのメトリクスに基づくアラートを受信・ルーティング・通知します。この二つのプロセスは 独立したサービス ですが、alerting セクションで相互にエンドポイントを指定するだけでシームレスに連携できます。
なぜ重要か
アーキテクチャを正しく理解しておくと、障害時の原因切り分けやスケールアウト時の設定ミスを防げます。特にコンテナ環境（Docker Compose / Kubernetes）では名前解決だけで通信できる点がデプロイ作業をシンプルにします。
1.1 コンポーネント構成
| コンポーネント | 主な役割 | デフォルトポート |
|---|---|---|
| Prometheus | メトリクスのスクレイプ、時系列DBへの保存、アラートルール評価 | 9090 |
| Alertmanager | アラート受信、ラベルベースでのルーティング・抑制・通知 | 9093 |
- Prometheus の設定ファイル
prometheus.ymlにalertingセクションを追加し、Alertmanager のエンドポイント（例:http://alertmanager:9093）を指定します。 - 公式ドキュメントは Prometheus Docs – Alerting Configuration に掲載されています。
2. 設定ファイルのディレクトリ構造
公式リポジトリ（https://github.com/prometheus/prometheus/tree/main/documentation/examples）が推奨する配置は次の通りです。Docker や Kubernetes の ConfigMap / Volume としてマウントしやすいように階層化しています。
|
1 2 3 4 5 6 7 |
/etc/prometheus/ ├─ prometheus.yml # Prometheus 本体設定 ├─ rules/ │ └─ *.rules.yml # アラートルール（複数可） └─ alertmanager/ └─ alertmanager.yml # Alertmanager 設定 |
prometheus.ymlの rule_files ディレクティブでrules/*.rules.ymlを一括読み込み。alertmanager/alertmanager.ymlは Alertmanager のみが参照するため、別ディレクトリに分離しておくと権限管理が楽です。
ポイント：コンテナイメージ内部でも同様のパスでマウントできるので、Docker Compose では
volumesオプションだけで完結します。
3. Alerting ルールファイル（rule_files）と実装例
3.1 rule_files ディレクティブの設定例
以下は prometheus.yml に追記する最小構成です。2026 年版でも書式は変わっていません。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# prometheus.yml の抜粋（2026 年版） global: scrape_interval: 15s rule_files: - 'rules/*.rules.yml' # rules ディレクトリ配下の全ファイルをロード alerting: alertmanagers: - static_configs: - targets: ['alertmanager:9093'] |
3.2 アラートルール（*.rules.yml）の基本構造
cpu-usage.rules.yml の例では、CPU 使用率が一定時間以上高い場合に Critical なアラートを発火させます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# rules/cpu-usage.rules.yml groups: - name: cpu_alerts interval: 1m # 評価間隔（省略可：デフォルトは 1 分） rules: - alert: HighCPUUsage expr: rate(node_cpu_seconds_total{mode!="idle"}[5m]) > 0.85 for: 2m labels: severity: critical team: platform annotations: summary: "CPU 使用率が高すぎます ({{ $value }})" description: | ホスト {{ $labels.instance }} の CPU 使用率が 85% を超えました。 |
ベストプラクティス
- ファイル分割：機能別（CPU、メモリ、ネットワーク）にディレクトリを切り、Git の PR 単位で管理。
- ラベル統一：
severity,team,instanceは必ず付与し、Alertmanager 側のルーティングと抑制ロジックを簡潔に保つ。 - コメント・ドキュメント：各ルール冒頭に「対象システム」「閾値根拠」などを記述し、チーム全体で共有できるようにする。
4. PromQL の最新関数と予測アラート
2026 年リリースノート（https://github.com/prometheus/prometheus/releases/tag/v2.50.0）によれば、predict_linear と histogram_quantile_over_time は v2.45 以降 の公式関数として実装されています。promtool version が 2.45+ であれば利用可能です。
4.1 基本的なレート系関数
| 関数 | 用途 | 推奨ウィンドウ |
|---|---|---|
rate() |
秒単位の平均レート | [5m] |
irate() |
最近の瞬間レート（急変検知） | [1m] |
increase() |
カウンタ増加量取得 | [10m] |
例：エラーレートが 0.05 を超えたらアラート
|
1 2 |
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05 |
4.2 予測アラート（predict_linear）
predict_linear(v range-vector, seconds) は過去データから線形回帰を行い、指定秒数後の予測値 を返します。CPU 使用率やディスク使用量の「将来超過」シナリオで有効です。
|
1 2 3 |
# 1 時間先に CPU 使用率が 90% 超えると予測されたらアラート expr: predict_linear(rate(node_cpu_seconds_total{mode!="idle"}[5m])[1h], 3600) > 0.9 |
検証手順
promtool query instantでローカルにクエリを走らせ、predict_linearが期待通りの数値を返すか確認してください。
4.3 ヒストグラムベース SLA 監視（histogram_quantile_over_time）
この関数は ヒストグラムの分位点 を時間窓で評価でき、レイテンシやレスポンスタイムの SLO 管理に適しています。
|
1 2 3 |
# 99 パーセンタイルが 2 秒を超えたらアラート expr: histogram_quantile_over_time(0.99, request_duration_seconds_bucket[10m]) > 2 |
注意点
- ヒストグラムは *_bucket 系メトリクスが必須です。
- 関数のサポート有無は promtool version と公式リリースノートで必ず確認してください。
5. Alertmanager 設定と通知先実装例
Alertmanager の設定ファイルは 3 層構造（global → receivers → route）で記述します。以下は Slack、Discord、汎用 Webhook を併用した典型的な構成です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
# alertmanager/alertmanager.yml global: resolve_timeout: 5m receivers: - name: slack-notify slack_configs: - api_url: '{{ env "SLACK_WEBHOOK_URL" }}' channel: '#alerts' send_resolved: true title: '[{{ .Status }}] {{ .CommonLabels.alertname }}' - name: discord-notify webhook_configs: - url: '{{ env "DISCORD_WEBHOOK_URL" }}' send_resolved: true - name: generic-webhook webhook_configs: - url: 'https://example.com/alert-receiver' http_config: bearer_token: '{{ env "WEBHOOK_TOKEN" }}' route: receiver: slack-notify # デフォルト受信先 group_by: ['alertname', 'severity'] group_wait: 30s group_interval: 5m repeat_interval: 1h routes: - match: severity: critical receiver: discord-notify - match_re: team: ^platform$ receiver: generic-webhook inhibit_rules: - source_match: severity: critical target_match: severity: warning equal: ['alertname', 'instance'] |
5.1 設定上のポイント
| 項目 | 推奨設定・根拠 |
|---|---|
| 環境変数でシークレット管理 | Docker / Kubernetes の env または Secret マウントを利用し、リポジトリに平文を書かない。 |
| group_wait | デフォルト 30 秒は「緊急度が高い」アラートでも過剰遅延にならず、ノイズ削減に効果的。 |
| inhibit_rules | Critical が出たときに同一 alertname の Warning を抑制し、通知量を最小化。 |
6. ローカル環境でのテスト・デバッグ手順
設定ミスは本番障害につながります。以下の公式ツール promtool と amtool（https://prometheus.io/docs/prometheus/latest/querying/tools/）を用いて、ローカルで検証します。
6.1 promtool でルール構文チェック
|
1 2 3 |
docker run --rm -v $(pwd)/rules:/etc/prometheus/rules \ prom/prometheus:v2.53.0 promtool check rules /etc/prometheus/rules/*.rules.yml |
- 出力例：
checking /etc/prometheus/rules/cpu-usage.rules.yml SUCCESS
6.2 amtool で Alertmanager 設定検証
|
1 2 3 |
docker run --rm -v $(pwd)/alertmanager/alertmanager.yml:/etc/alertmanager/config.yml \ prom/alertmanager:v0.27.0 amtool check-config /etc/alertmanager/config.yml |
- 成功時：
Checking configuration... SUCCESS
6.3 アラートのクエリ・サイレンス操作
|
1 2 3 4 5 6 7 8 |
# 発火中アラート一覧（Docker コンテナ内で実行） docker exec -it prometheus amtool alert query # 手動サイレンス作成例（30 分間無効化） docker exec -it alertmanager \ amtool silence add --alertname=HighCPUUsage --duration=30m \ --comment="メンテナンス中" |
6.4 Docker Compose での一括起動
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
# docker-compose.yml（2026 年版でも互換性あり） version: '3.8' services: prometheus: image: prom/prometheus:v2.53.0 # 必要に応じて最新タグへ置き換える volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro - ./rules/:/etc/prometheus/rules/:ro command: - '--config.file=/etc/prometheus/prometheus.yml' ports: - "9090:9090" depends_on: - alertmanager alertmanager: image: prom/alertmanager:v0.27.0 volumes: - ./alertmanager/alertmanager.yml:/etc/alertmanager/config.yml:ro command: - '--config.file=/etc/alertmanager/config.yml' ports: - "9093:9093" dummy-metrics: image: quay.io/prometheus/example-app:v0.5.0 # 疎通確認用サンプルアプリ ports: - "8080:8080" |
起動手順
|
1 2 3 |
docker compose up -d # バックグラウンドで全コンテナ起動 docker compose logs -f prometheus # 起動ログを確認 |
ブラウザで http://localhost:9090/graph にアクセスし、先ほどの PromQL クエリが期待通りに評価できるか確かめてください。
7. まとめと次のステップ
- アーキテクチャ：Prometheus がメトリクス収集・評価、Alertmanager が通知を担うシンプルな分離構造。
- ディレクトリ構造は公式推奨に沿い、コンテナのボリュームマウントで容易に管理。
- アラートルールは
rule_filesで一括ロードし、ラベル・コメントで可読性と保守性を確保。 - 2026 年版関数（
predict_linear,histogram_quantile_over_time）は公式リリースノートで確認済みなので、予測アラートや SLA 監視に積極活用。 - Alertmanager 設定は環境変数でシークレット管理し、
inhibit_rulesとgroup_*パラメータで通知量を最適化。 - ローカルテストは
promtool/amtoolと Docker Compose で完結でき、CI パイプラインへの組み込みも容易です。
次にやるべきこと
1. 本リポジトリを自組織の Git にクローンし、上記構成でローカル起動。
2. 実運用環境（Kubernetes 等）へは同様の ConfigMap / Secret を作成し、helm upgrade --installなどでデプロイ。
3. 定期的にpromtool versionと公式リリースノートをチェックし、関数追加や非推奨変更に追従する。
参考リンク（すべて公式ドキュメント）
- Prometheus アラート設定: https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
- Alertmanager 設定ガイド: https://prometheus.io/docs/alerting/latest/alertmanager/
- 新関数リリースノート（v2.45 以降）: https://github.com/prometheus/prometheus/releases/tag/v2.45.0
- PromQL クエリツール: https://prometheus.io/docs/prometheus/latest/querying/tools/
本稿は執筆時点（2026 年 5 月）における公式情報を元に作成しています。バージョンや関数の追加・削除は随時公式リポジトリで確認してください。