Contents
全体構成とデータフロー
Prometheus と Alertmanager の連携は、取得 → 評価 → 通知というシンプルな流れで実装されます。このセクションでは、各コンポーネントがどのように役割分担し、全体としてスケーラブルな監視基盤を構築できるかを概観します。まずはデータ取得から通知までの主要ステップと、その設計上のメリットを簡潔に説明します。
Prometheus は対象サービスからメトリクスをスクレイプし、設定されたアラートルール（alerting.rules）を PromQL で評価します。条件が成立した瞬間に Alert オブジェクトを生成し、HTTP POST により Alertmanager へ送信します。Alertmanager は受信したラベル情報を基に receiver, routing, inhibit_rules を適用し、最終的な通知先（Slack, Email など）へ転送します。この分離により、Prometheus は評価ロジックだけに集中でき、監視対象が増えても通知設定のみの変更で対応可能です【1】。
Prometheus がメトリクスを取得・評価する流れ
このサブセクションでは、スクレイプからアラート生成までの具体的な手順とポイントを解説します。
- スクレイプ対象の設定：Kubernetes の
ServiceMonitorや static_config で定期的にメトリクスを取得します。 - ルールファイルの読み込み：
rules/*.yamlに記述されたアラートルールは、Prometheus 起動時にロードされます。 - PromQL 評価：各ルールは
exprフィールドの PromQL 式で評価され、結果が true になると内部で Alert オブジェクトを生成します。
Alertmanager へのアラート転送プロセス
Alertmanager に渡す際の設定項目と、受信側で行われる処理を整理します。
- 宛先の指定：Prometheus の
--alertmanager.urlまたはalerting.alertmanagersで Alertmanager エンドポイントを設定します。 - HTTP POST：
/api/v2/alertsに対して JSON 形式でアラート情報を送信します。 - 受信後の処理：Alertmanager はラベルに基づき
receiver,routing,inhibit_rulesを適用し、外部サービスへ通知します【2】。
アラートルールファイル（YAML）の基本構造と必須フィールド
この章では、実際に記述する YAML の書式と、運用上欠かせないフィールドについて詳しく説明します。公式ドキュメントの最新仕様に沿いながら、実務で頻繁に利用されるベストプラクティスも併せて紹介します。
alert, expr, for の意味
アラートルールは最低でも以下 3 つのフィールドが必要です。
- alert：アラート名。通知時に自動的に
alertnameラベルとして付与されます。 - expr：評価対象となる PromQL 式。1 つ以上のベクトル要素が非ゼロになると真 (true) とみなします。
- for：条件が連続して成立する時間幅。短期間のスパイクを除外し、誤検知を防止します。
ポイント：
forを適切に設定すると、一時的な遅延やノイズによる不要アラートを大幅に削減できます【3】。
labels と annotations のベストプラクティス
ラベルとアノテーションは、Alertmanager でのルーティング・抑制ロジックと、人間が読む通知内容という二つの役割を担います。
- labels：主に自動処理用です。
severity,team,serviceなど運用単位のラベルを必ず付与し、Alertmanager のroute.matchと整合させます。 - annotations：通知本文に表示される情報です。
summaryとdescriptionはほぼ必須で、対象サービスへのリンクや対処手順を記載すると対応が迅速になります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
groups: - name: example.rules rules: - alert: HighRequestLatency # アラート名 expr: job:request_latency_seconds:mean5m{job="myservice"} > 0.5 for: 10m # 条件が連続 10 分成立したら発火 labels: severity: critical team: backend service: myservice annotations: summary: "リクエスト遅延が高い" description: | {{ $labels.job }} の平均レイテンシが 0.5 秒を超えました。 詳細は Grafana ダッシュボード https://grafana.example.com/d/latency を参照してください。 |
実装例：HighRequestLatency ルール
実務で最も利用頻度の高い「リクエスト遅延」監視を具体例として示します。ここでは Recording rule の活用と for 条件による誤検知防止、さらにラベル設計のポイントを解説します。
PromQL 式の書き方と注意点
以下の式は 5 分間移動平均（recording rule）を利用した例です。
- Recording rule の利点：同一計算結果を複数ルールで再利用でき、Prometheus の評価負荷が軽減します。
- 浮動小数点リテラル：秒単位の比較は
0.5のように float で記述し、整数と混在させないよう注意します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
- alert: HighRequestLatency expr: job:request_latency_seconds:mean5m{job="myservice"} > 0.5 for: 10m labels: severity: critical team: backend service: myservice annotations: summary: "バックエンドサービスの遅延が高止まり" description: | {{ $labels.service }} の平均レイテンシが {{ printf "%.2f" $value }} 秒です。 今すぐ対象ポッドのリソース使用率を確認し、必要に応じてスケールアウトしてください。 |
ポイント：
serviceラベルを追加すると、Alertmanager のroute.group_byでサービス単位にまとめて通知でき、運用負荷が低減します【4】。
Alertmanager の受信設定と通知先構成
この章では、Alertmanager における receiver, route, inhibit_rules の定義方法を実装例とともに解説します。Slack と Email の併用が標準的なパターンであり、実際の運用現場で広く採用されています。
receiver 定義（Slack / Email）
receiver は通知先ごとの設定ブロックです。以下は代表的な Slack と Email の構成例です。
- send_resolved：
trueにするとアラートが解消したときにも通知が送られ、インシデントの開始・終了を一目で把握できます。 - テンプレート変数：
.CommonAnnotations.summaryや.CommonAnnotations.descriptionを利用して、共通情報を簡潔に表示します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
receivers: - name: 'slack-team' slack_configs: - api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX' channel: '#alerts-backend' send_resolved: true title: '{{ .CommonAnnotations.summary }}' text: | {{ .CommonAnnotations.description }} - name: 'email-team' email_configs: - to: 'ops@example.com' from: 'alertmanager@example.com' smarthost: 'smtp.example.com:587' auth_username: 'alertmanager@example.com' auth_password: '********' # 実運用では secret 管理ツールを利用 send_resolved: true |
routing と inhibit_rules の設計指針
routing はラベルに基づく振り分けロジック、inhibit_rules は重複通知防止のための抑制条件です。
- group_by：
serviceを含めると同一サービス内のアラートがまとめて送信され、ノイズが減ります。 - inhibit_rules：重大度が
criticalのアラートが発生した場合に、同名・同サービスのwarningを抑制します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
route: receiver: 'slack-team' group_by: ['alertname', 'service'] group_wait: 30s group_interval: 5m repeat_interval: 3h routes: - match: severity: critical receiver: 'email-team' # 重大度が critical のみ Email に転送 - match_re: service: ^frontend|backend$ receiver: 'slack-team' inhibit_rules: - source_match: severity: critical target_match: severity: warning equal: ['alertname', 'service'] |
この構成により、重要度別・サービス別の通知が整理され、運用担当者は必要な情報だけを受け取ることができます【5】。
デプロイ手順・ベストプラクティス
実運用で安全かつ継続的にアラートルールを追加・更新するための手順と推奨ツールチェーンをまとめます。GitOps と Kubernetes の ConfigMap を組み合わせたパターンが主流です。
ルールファイル配置と ConfigMap の例
Kubernetes 上で Prometheus が参照できるよう、ConfigMap に YAML を格納しマウントします。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
apiVersion: v1 kind: ConfigMap metadata: name: prometheus-rules namespace: monitoring data: high_latency.yaml: | groups: - name: latency.rules rules: - alert: HighRequestLatency expr: job:request_latency_seconds:mean5m{job="myservice"} > 0.5 for: 10m labels: severity: critical team: backend service: myservice annotations: summary: "リクエスト遅延が高い" description: | {{ $labels.job }} の平均レイテンシが {{ printf \"%.2f\" $value }} 秒です。 |
prometheus.yml の rule_files に以下を追記すれば、ConfigMap が自動的にロードされます。
|
1 2 3 |
rule_files: - "/etc/prometheus/rules/*.yaml" |
Prometheus のリロード手順とオプション
設定変更後にプロセスを再起動せずにルールを反映させる方法です。
- 起動オプション（Pod 定義の例）
bash
prometheus \
--config.file=/etc/prometheus/prometheus.yml \
--web.enable-lifecycle \
--storage.tsdb.path=/prometheus
- 設定リロード
bash
curl -X POST http://localhost:9090/-/reload
--web.enable-lifecycle が有効だと、HTTP API で即座に再読み込みできるため、Pod のローテーションが不要になります【6】。
promtool による構文チェック・テスト実行
本番環境へ投入する前に必ず以下のコマンドで検証しましょう。
|
1 2 3 4 5 6 |
# 構文と型チェック promtool check rules high_latency.yaml # テストシナリオによる評価結果シミュレーション promtool test rules tests.yaml |
- 構文エラー：YAML のインデントやフィールド名のタイプミスを事前に検出します。
- テスト実行：期待するラベル・値を
tests.yamlに記述し、ローカルで評価結果を確認できるため、誤ったアラートが本番に流れるリスクを低減できます【7】。
トラブルシューティングと補足情報
実装後によく遭遇する問題と、その対処法をまとめます。公式ドキュメントや信頼できる外部ガイドの要点も併せて示すので、障害発生時の迅速な復旧に役立ちます。
ラベル不一致・for 条件が期待通りに機能しないケース
- 症状：Alertmanager にアラートが届かない、または意図したルーティングにならない。
- 原因：
labelsのキー名や値がroute.matchと微妙に異なる（例:severity: Criticalvscritical）。 - 対策：
promtool test rulesで生成されたラベルセットを確認し、Alertmanager 側のmatch条件と完全一致させます。また、forが短すぎるとスパイクが通知されやすくなるため、対象サービスの特性に合わせて調整してください【8】。
Alertmanager の silences（サイレンス）競合対策
- 症状：一度サイレンスしたはずのアラートが再度通知される。
- 原因：
inhibit_rulesが未設定、またはequalフィールドで抑制対象ラベルを除外している。 - 対策：Silence 作成時にマッチャーを正確に指定し、同一
alertname・serviceに対する抑制ルール（inhibit_rules）を明示的に定義します。さらに、サイレンス期間が終了したら手動で削除する運用フローも併せて検討してください【9】。
公式ドキュメントと外部リソースのまとめ
| No. | 出典 | 内容 |
|---|---|---|
| [1] | https://prometheus.io/docs/introduction/overview/ | Prometheus の全体像と基本コンポーネント |
| [2] | https://prometheus.io/docs/alerting/latest/alertmanager/ | Alertmanager の API と設定方法 |
| [3] | https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/ | アラートルールの必須フィールドと書式 |
| [4] | https://github.com/prometheus/alertmanager/blob/main/doc/examples/simple.yml | 実践的な receiver / route 設定例 |
| [5] | https://prometheus.io/docs/practices/rules/ | Recording rule の活用ガイド |
| [6] | https://prometheus.io/docs/prometheus/latest/command_line/ | --web.enable-lifecycle オプション解説 |
| [7] | https://github.com/prometheus/promtool | promtool の使用例とベストプラクティス |
| [8] | https://www.robustperception.io/how-to-test-alerting-rules-with-promtool | promtool test rules によるシミュレーション手順 |
| [9] | https://github.com/prometheus/alertmanager/blob/main/doc/silence.md | Silences と inhibit_rules の詳細 |
まとめ
- 役割分担が鍵：Prometheus はメトリクス取得とアラート評価、Alertmanager が通知ロジックを担当することで、システム全体の可観測性と拡張性が向上します。
- ルール記述は必須フィールド＋運用ラベル：
alert,expr,forに加えて、severity,team,serviceなどのラベルを統一的に付与し、Alertmanager の routing と抑制をシンプルに保ちます。 - Recording rule の活用で負荷削減：共通計算式は事前に記録しておくと、複数アラートが同じ計算結果を参照でき、評価コストが大幅に低減します。
- Alertmanager 設定は receiver / route / inhibit_rules の三層構造：Slack と Email を組み合わせ、
group_byとinhibit_rulesでノイズと重複通知を抑えます。 - デプロイは ConfigMap + GitOps + lifecyle リロード：設定変更はコードレビューを通じて管理し、
--web.enable-lifecycleによる即時リロードでダウンタイムなしに反映させます。 - 検証は必須：
promtool check rulesとpromtool test rulesで構文・ロジックの事前チェックを徹底し、ラベル不一致やサイレンス競合といった運用トラブルを未然に防ぎます。
本稿で紹介した手順とベストプラクティスを踏襲すれば、Prometheus と Alertmanager を組み合わせた堅牢な監視基盤が構築でき、インシデント対応の迅速化と運用コスト削減につながります。ぜひ実務に取り入れて、継続的な可観測性向上を図ってください。