Contents
Prometheus と Alertmanager の全体像
Prometheus がメトリクスを収集し、設定したアラートルールに基づいて評価結果を生成します。その結果は HTTP 経由で Alertmanager に送られ、ラベル情報を元に通知先へ振り分けられます。本セクションでは、全体構成図とデータフローを俯瞰しながら、両コンポーネントの役割分担と連携ポイントを整理します。
概要
Prometheus は「取得・評価」までを高速に処理し、通知ロジックはすべて Alertmanager に委譲する設計です。これにより、監視対象のスケールが大きくなっても通知設定だけを柔軟に変えることが可能になります。
データフロー
以下の手順でメトリクスから最終通知までが流れます。
- 取得 –
scrape_intervalに従い、Prometheus が対象エンドポイントから最新のメトリクスを pull します。 - 評価 – 設定された
alerting_rules.ymlを一定間隔で評価し、条件が成立したベクトル要素（アラート）を生成します。 - 送信 – 生成されたアラートは HTTP POST (
/api/v2/alerts) により Alertmanager に転送されます。 - ルーティング – Alertmanager は受信したアラートの
labels（例:severity,team）を基にalertmanager.ymlのrouteセクションで宛先を決定し、Slack・メール・PagerDuty など複数のチャネルへ同時送信します。
構成図（概略）
|
1 2 3 4 5 6 7 8 9 10 |
+----------------+ scrape +--------------+ | Prometheus | ----------------> | Targets | +--------+-------+ +------+-------+ | | evaluate|alerting_rules.yml | v v +--------+-------+ POST /api/v2/alerts +-----------------+ | Alertmanager | -------------------------------------> | Notification | +----------------+ route (labels) -> Slack / Email +-----------------+ |
再提示
Prometheus が評価したアラートはすべて Alertmanager に委譲され、ラベルベースのルーティングで安全かつ柔軟に通知先へ配信されます。
詳細は「Prometheus と Alertmanager の完全ガイド」をご参照ください。
アラートルールの基本：YAML 構造と配置場所
この章では、アラート定義ファイル alerting_rules.yml の必須構造と、Prometheus が正しく認識できる配置パスについて解説します。誤ったインデントやキー名の揺れは起動エラーの原因になるため、正確な記述が重要です。
ファイル構造のポイント
alerting_rules.yml はトップレベルに groups: を持ち、その下に複数の rules: を列挙します。各ルールは必ず alert, expr, for（任意）、labels, annotations の要素を備える必要があります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# /etc/prometheus/rules/alerting_rules.yml groups: - name: cpu_alerts # グループ名は一意にすることが推奨 interval: 30s # 評価間隔（省略時は global の scrape_interval が使用される） rules: - alert: HighCPUUsage expr: rate(node_cpu_seconds_total{mode="user"}[5m]) > 0.8 for: 2m # 条件が連続して満たされた場合に発火 labels: severity: critical team: platform annotations: summary: "CPU 使用率が高すぎます" description: | {{ $labels.instance }} の CPU 使用率が {{ printf "%.2f" ($value*100) }}% です。 詳細は Grafana ダッシュボードをご確認ください。 |
配置場所と読み込み設定
| 推奨パス | 説明 |
|---|---|
/etc/prometheus/rules/ |
Docker イメージや公式 Helm Chart のデフォルトディレクトリ。複数ファイルをまとめて管理しやすい。 |
rule_files: セクション |
prometheus.yml に以下のように記述して、上記ディレクトリ内の全 .yml／.yaml を自動的に読み込む。 |
|
1 2 3 4 |
# prometheus.yml（抜粋） rule_files: - "rules/*.yml" |
実務で役立つ追加ポイント
- 拡張子統一 –
.ymlと.yamlが混在するとエディタの自動補完が効きにくくなるため、プロジェクト内ではどちらかに統一します。 - コメント活用 – ルールファイルはチーム全員で閲覧することが前提です。目的や閾値の根拠を
#コメントで残すとレビューが楽になります。 - バリデーション –
promtool check rules <path>による構文チェックは必須です。CI パイプラインに組み込んで、プッシュ時に自動検証させることを推奨します。
再提示
alerting_rules.yml は groups → rules の階層構造で記述し、prometheus.yml の rule_files: から正しく参照させることで、Prometheus が期待通りにアラートを評価できるようになります。
作成手順は「Prometheus アラートルール作成実践例」でも詳しく解説されています。
実践的な expr 記述と for 句の活用
この節では、実務で頻出する PromQL の書き方と、スパイク誤検知を抑えるために有効な for: 句の使いどころを具体例とともに示します。適切な式設計はアラートの信頼性向上に直結します。
式作成の基本方針
- ローパスフィルタ –
rate()やincrease()で瞬間的なバーストを平均化し、ノイズを除去します。 - 単位意識 – メトリクスが秒単位かカウント単位かを把握した上で、比較対象の閾値も同じ単位に揃える必要があります。
- 集計レベル –
by/withoutを適切に使用し、ラベル次元で過度に細分化しすぎないよう注意します。
代表的な式例と解説
| 目的 | 推奨式 | 解説 |
|---|---|---|
| CPU 使用率が 80 % 超過 | rate(node_cpu_seconds_total{mode="system"}[5m]) * 100 > 80 |
node_cpu_seconds_total は累積秒数。rate() の結果をパーセンテージに変換して閾値と比較します。 |
| エラーレートが 1 分間に 5 件以上 | increase(http_requests_total{status=~"5.."}[1m]) > 5 |
5xx 系ステータスコードの増分を測定し、閾値と比較します。 |
| p95 レイテンシが 300 ms 超過 | histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.3 |
バケット別にレートを集計し、p95 を算出。単位は秒なので 0.3 秒＝300 msです。 |
for: 句の実装例
|
1 2 3 4 5 6 7 8 9 10 11 |
- alert: HighErrorRate expr: increase(http_requests_total{status=~"5.."}[2m]) > 10 for: 5m # 条件が 5 分間継続したら発火 labels: severity: warning team: backend annotations: summary: "エラーレートが急上昇しています" description: | {{ $labels.instance }} の 5xx エラーが過去 2 分で {{ $value }} 件検出されました。 |
保留 (pending) と発火 (firing) の違い
for:が無い場合 → 条件が満たされた瞬間に firing 状態になる。for:を設定した場合 → 条件が検出されてもまずは pending 状態になり、指定時間経過後に firing へ遷移する。これにより、一時的なトラフィックバーストやリソースの瞬間ピークでの誤報を防げます。
再提示
実務では rate, increase, histogram_quantile を組み合わせ、for: で保留期間を設けることで信頼性の高いアラートが作成できます。
詳細な式例は「Prometheus アラートルール設定・管理ガイド」でも多数紹介されています。
ラベル・アノテーション設計と Alertmanager でのルーティング
Alertmanager が通知先を決定する際に参照するのは ラベル です。本節では、衝突しにくいラベル設計の指針と、通知本文へ埋め込むための annotations の活用方法を解説します。
ラベル設計の基本方針
- 共通キーは統一 –
severity,team,serviceといったキーはプロジェクト全体で同じ意味になるよう定義します。 - プレフィックス利用 – 既存のメトリクスラベルと衝突しないよう、独自ラベルには
alert_やteam_などのプレフィックスを付与すると管理が楽です。 - 一意性の確保 – 同一アラート内で同じキーを複数回設定しないこと。重複した場合、Alertmanager のマッチングが曖昧になります。
アノテーション活用ポイント
| 用途 | 例 | メリット |
|---|---|---|
| 概要表示 | summary: "ディスク容量が不足しています" |
UI やチャットで一目で内容把握可能 |
| 詳細説明 | description: "{{ $labels.instance }} の / パーティションの残り容量は {{ printf \"%.2f\" ($value*100) }}% です。" |
テンプレート変数により動的情報を埋め込める |
| ランブックリンク | runbook_url: "https://runbooks.example.com/disk-space-low" |
アラート受信者が即座に対処手順へ遷移できる |
実装例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
- alert: DiskSpaceLow expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.15 for: 3m labels: severity: critical # Alertmanager の route で critical 用 Slack に送信 team: storage # ストレージチームが担当 service: webapp # サービス名でフィルタリング可能 annotations: summary: "ディスク容量が 15% 以下です" description: | {{ $labels.instance }} の / パーティションの空き容量が残り {{ printf \"%.2f\" ($value*100) }}% になっています。 詳細は https://monitoring.example.com/dashboards/disk をご確認ください。 runbook_url: "https://runbooks.example.com/disk-space-low" |
Alertmanager 側のルーティング例（抜粋）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
route: group_by: ['alertname', 'service'] receiver: 'default' routes: - match: severity: critical receiver: 'slack-critical' - match_re: team: ^(storage|db)$ receiver: 'pagerduty-team' receivers: - name: slack-critical slack_configs: - channel: '#alerts-critical' send_resolved: true - name: pagerduty-team pagerduty_configs: - service_key: '<PD_SERVICE_KEY>' |
注意点
- ラベル名の衝突回避 – Prometheus が自動付与する
instanceやjobと同じ名前は使用しない。 - マッチング優先度 –
route.routesの順序は上から下へ評価されるため、特定チーム向けのルートは広範囲のseverity: critical以前に配置してください。
再提示
統一されたラベル設計と有益なアノテーションを併用すれば、Alertmanager のルーティングがシンプルになるだけでなく、通知本文も実務に即した情報を提供でき、インシデント対応のスピード向上につながります。
ラベル設計のベストプラクティスは「Prometheus Alertmanager 完全ガイド」をご参照ください。
デプロイ・検証フロー：Docker Compose / Kubernetes と promtool 活用
本章では、実際にアラートルールを稼働させるためのデプロイ手順と、事前に構文エラーを防止する promtool の使い方を解説します。ローカル環境での検証から本番クラスタへの適用まで、一連の流れを網羅しています。
Docker Compose での構築手順
Docker Compose は数行の定義だけで Prometheus と Alertmanager の連携環境が作れるため、開発・デモに最適です。以下は最小構成例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
# docker-compose.yml version: "3.8" services: prometheus: image: prom/prometheus:v2.53.0 volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro - ./rules/:/etc/prometheus/rules/:ro # alerting_rules.yml をマウント command: - '--config.file=/etc/prometheus/prometheus.yml' ports: - "9090:9090" alertmanager: image: prom/alertmanager:v0.27.0 volumes: - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro command: - '--config.file=/etc/alertmanager/alertmanager.yml' ports: - "9093:9093" |
ポイント解説
- ボリュームマウント – ローカルの YAML をコンテナに read‑only でマウントすることで、ファイル変更後はコンテナ再起動だけですぐに反映できます。
- 相互参照 – Docker ネットワーク上ではサービス名 (
prometheus,alertmanager) が DNS 名になるため、prometheus.ymlのalerting:セクションでは以下のように記述します。
|
1 2 3 4 5 6 |
# prometheus.yml（抜粋） alerting: alertmanagers: - static_configs: - targets: ['alertmanager:9093'] |
Kubernetes での配布方法
本番環境では ConfigMap と Secret を組み合わせて設定情報を安全に提供します。
1. ルールファイル用 ConfigMap
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: v1 kind: ConfigMap metadata: name: prometheus-rules data: alerting_rules.yml: | groups: - name: cpu_alerts rules: - alert: HighCPUUsage expr: rate(node_cpu_seconds_total{mode="system"}[5m]) * 100 > 80 for: 2m labels: severity: critical annotations: summary: "CPU 使用率が高すぎます" |
2. 機密情報（例：Slack Webhook）用 Secret
|
1 2 3 4 5 6 7 8 |
apiVersion: v1 kind: Secret metadata: name: alertmanager-secret type: Opaque stringData: slack_webhook_url: https://hooks.slack.com/services/XXXXX/XXXXX/XXXXXXXX |
3. Deployment のマウント例
|
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 |
apiVersion: apps/v1 kind: Deployment metadata: name: prometheus spec: replicas: 1 selector: matchLabels: app: prometheus template: metadata: labels: app: prometheus spec: containers: - name: prometheus image: prom/prometheus:v2.53.0 args: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' volumeMounts: - name: config mountPath: /etc/prometheus/ - name: rules mountPath: /etc/prometheus/rules/ volumes: - name: config configMap: name: prometheus-config # 事前に作成した ConfigMap - name: rules configMap: name: prometheus-rules |
Alertmanager 側も同様に
alertmanager.ymlを ConfigMap、Webhook URL を Secret としてマウントすれば完了です。
promtool でのローカル検証手順
構文エラーはデプロイ直後の障害原因になることが多いため、必ず以下コマンドで事前チェックを行います。
|
1 2 3 4 5 6 |
# 1. ルールファイル単体のバリデーション promtool check rules ./rules/alerting_rules.yml # 2. prometheus 全体設定（prometheus.yml 含む）の整合性確認 promtool check config ./prometheus.yml |
エラーが出なければ、docker compose up -d または kubectl apply -f <manifest> でデプロイできます。
UI での動作確認
| コンポーネント | URL | 主な確認項目 |
|---|---|---|
| Prometheus | http://localhost:9090/alerts |
アラート一覧、状態（pending / firing） |
| Alertmanager | http://localhost:9093/#/alerts |
アラート詳細、Silence 設定、受信履歴 |
テストアラートの送信例
一時的に以下のテストルールを alerting_rules.yml に追記し、promtool check rules 後に再ロードすると即座に Slack へ通知が届きます。
|
1 2 3 4 5 6 7 8 9 |
- alert: TestAlert expr: vector(1) for: 0s labels: severity: info annotations: summary: "テスト通知" description: "このアラートは手動テスト用です。" |
まとめ
| 項目 | メリット |
|---|---|
| Docker Compose | ローカル開発・デモに最適、構成がシンプル |
| Kubernetes | 本番環境でのスケーラビリティと機密情報管理が可能 |
promtool |
デプロイ前に構文エラーを検出し、運用トラブルを未然に防止 |
詳細手順は「Prometheus アラートルール実装例」でも同様に解説されています。
まとめ
本稿では、2026 年版の最新機能を踏まえた Prometheus と Alertmanager の連携 を体系的に整理しました。
- 全体構成 – Prometheus がメトリクス取得と評価、Alertmanager が通知・ルーティングを担う分離設計が基本です。
- YAML 設定 –
groups → rulesの階層で記述し、prometheus.ymlのrule_files:から正しく参照させることが成功の鍵です。 - 式と保留時間 –
rate(),increase(),histogram_quantile()を組み合わせ、for:でスパイク誤検知を抑制します。 - ラベル設計 –
severity,team,serviceといった共通キーを統一し、annotationsにランブックや概要情報を入れることで通知内容が充実します。 - デプロイと検証 – Docker Compose はローカル・デモ向け、Kubernetes は本番向けにそれぞれ最適化されており、
promtoolによる事前バリデーションで構成ミスを防げます。
これらのベストプラクティスを踏まえて実装すれば、信頼性の高いアラート基盤 を短期間で構築でき、インシデント対応のスピードと正確性が大幅に向上します。ぜひ自環境へ適用し、継続的な改善サイクルを回してください。