Prometheus Alertmanager で通知ルーティングを本番設計する｜抑制・グルーピング・テスト手順

Alertmanagerのルーティング設計が本番で難しい理由

Prometheusのアラートはルールファイルに定義したしきい値を超えた瞬間に発火しますが、その通知をどこへ・どのように届けるかを制御するのがAlertmanagerです。開発環境では1つのreceiver（SlackやPagerDutyなど）に全件投げるだけで事足りますが、本番環境ではサービスや重大度ごとに宛先を分けたり、関連アラートをまとめて1通にしたり、障害連鎖による通知嵐を抑制したりと、複雑な要件が重なります。

よくあるつまずきとして、group_waitとrepeat_intervalの使い分けを誤ったまま本番適用してしまい、同一アラートが数分おきに大量送信される事態が挙げられます。Alertmanagerの設定ファイルは宣言的なYAMLですが、ルーティングツリーの評価順や継承ルールが直感に反しやすく、事前のテストが欠かせません。本記事では設定構造の読み方から、inhibit_rulesによる抑制設計、amtoolを使った検証手順まで順に整理します。

基本構造：route ツリーの読み方と継承ルール

Alertmanagerの設定は大きくglobal・route・receivers・inhibit_rulesの4ブロックで構成されます。中心となるrouteブロックはツリー構造になっており、ルートノードから子ノードへ順にマッチングします。

route:
  receiver: default-receiver
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  routes:
    - matchers:
        - severity=~"critical|page"
      receiver: pagerduty-critical
      continue: false
    - matchers:
        - team="infra"
      receiver: slack-infra
      group_by: ['alertname', 'instance']

評価は上から順に行われ、最初にマッチしたルートが適用されます。continue: trueを指定しない限り、マッチした時点で評価は停止します。子ノードはルートノードの設定を継承しますが、明示的に上書きしたキーだけが子ノードの値に置き換わります。上記のslack-infraルートはgroup_byを上書きしていますが、group_waitやrepeat_intervalはルートの値（30s・12h）を引き継ぎます。

group_wait・group_interval・repeat_interval の使い分け

• group_wait：同じグループの最初のアラートが届いてから通知を送信するまでの待機時間です。短すぎると個別通知が頻発し、長すぎると即時通知が遅れます。一般的には30秒〜2分が適切とされています。
• group_interval：グループが既に通知済みの状態で新しいアラートが追加されたとき、次の通知を送るまでの間隔です。本番では5分〜10分が目安になります。
• repeat_interval：アラートが解消されないまま継続しているとき、何時間ごとに再送するかの間隔です。勤務時間外の監視体制に合わせて4h〜24hの範囲で設定することが多いです。

inhibit_rules で通知嵐を防ぐ

inhibit_rulesは「上位のアラートが発火している間、下位の関連アラートを抑制する」仕組みです。ホスト全体がダウンしているときに、そのホスト上で動くサービスの個別アラートを大量に受け取っても対応できません。inhibit_rulesはこうした障害連鎖による通知の増幅を防ぐために使います。

inhibit_rules:
  - source_matchers:
      - alertname="NodeDown"
      - severity="critical"
    target_matchers:
      - severity=~"warning|info"
    equal:
      - cluster
      - instance

上記の設定では、NodeDownかつseverity=criticalのアラートが発火しているとき、同じclusterとinstanceラベルを持つwarning・infoレベルのアラートを抑制します。equalフィールドに指定したラベルが一致することが条件であるため、別ノードのアラートには影響しません。

設計上の注意点として、inhibit_rulesはReceiverへの通知を止めるだけであり、Alertmanager内部の発火状態（Firing/Resolved）には影響しません。アラートのResolvedイベントは引き続き処理されます。また、source_matchersとtarget_matchersの両方を満たすアラートが存在しない場合、抑制は適用されないため、ラベル設計との整合性を確認することが重要です。

Silence との使い分け

Silenceはメンテナンス時間帯など一時的に通知を止めたい場合に使います。AlertmanagerのWeb UIまたはamtool silence addコマンドで作成でき、有効期限を設定できます。inhibit_rulesが「あるアラートの発火中」という条件に紐付くのに対し、Silenceは時間範囲とマッチャーで制御します。計画メンテ時はSilence、障害連鎖の抑制にはinhibit_rulesと役割を分けて運用するのが基本的なアプローチです。

amtool でルーティングをテストする

設定変更を本番に適用する前に、amtoolでルーティングの動作を確認できます。amtoolはAlertmanagerに同梱されているCLIツールで、設定ファイルの検証・ルーティングのシミュレーション・アラートの手動投入が可能です。

設定ファイルの構文チェック

amtool check-config /etc/alertmanager/alertmanager.yml

このコマンドはYAMLの構文エラーや必須フィールドの欠落を検出しますが、ルーティングロジックの妥当性（意図したreceiverに届くか）までは検証しません。構文チェックの通過はあくまでスタート地点です。

ルーティングのシミュレーション

# 特定ラベルセットがどのreceiverに届くかを確認
amtool config routes test \
  --config.file=/etc/alertmanager/alertmanager.yml \
  alertname=NodeDown severity=critical cluster=prod-tokyo

上記のコマンドを実行すると、指定したラベルセットがどのルートにマッチし、どのreceiverに送信されるかが標準出力に表示されます。設定変更後は必ずこのシミュレーションを実行し、想定通りのreceiverにルーティングされることを確認してください。特にcontinue: trueを使って複数のreceiverに送る設定をしている場合は、意図しない二重通知が発生していないかも合わせて確認します。

アラートの手動投入と動作確認

# テスト用アラートをAlertmanagerに投入（--duration でアクティブ期間を指定）
amtool alert add \
  --alertmanager.url=http://localhost:9093 \
  alertname=TestAlert \
  severity=warning \
  team=infra \
  --annotation summary="テスト通知" \
  --duration 5m

このコマンドは実際にAlertmanagerへ通知を投入するため、receiverが本番のSlackやPagerDutyに接続されている場合は実際に通知が飛びます。テスト環境での実行か、事前にSilenceを設定した状態での実行を徹底してください。--durationを指定することでテスト後に自動的に解消状態になります。

切り戻しと設定適用の安全な手順

Alertmanagerは設定ファイルをホットリロードできます。SIGHUPシグナルを送るか、HTTPエンドポイントにPOSTすることで、プロセスを再起動せずに設定を反映できます。

# SIGHUPによるホットリロード
kill -HUP $(pgrep alertmanager)

# HTTPエンドポイント経由
curl -X POST http://localhost:9093/-/reload

設定変更前にはYAMLファイルをGitなどのバージョン管理システムにコミットしておき、問題が発生した場合は直前のコミットに戻して再ロードできるようにしておくことが重要です。

systemdで管理している場合は次のコマンドで対応します。

sudo systemctl reload alertmanager
# または
sudo systemctl restart alertmanager

なお、systemctl reloadが有効になるのは、UnitファイルのExecReloadにSIGHUPまたは/-/reloadへのリクエストが設定されている場合に限ります。Prometheus公式のパッケージではこの設定が含まれていますが、自前でインストールした場合はsystemctl cat alertmanagerでUnitファイルを確認してください。

2026年現行環境での注意点

Alertmanager 0.27（2024年リリース）以降、いくつかの変更が本番設計に影響します。

matchers の記法変更

従来のmatch・match_reフィールドはAlertmanager 0.25以降で非推奨となり、0.27では削除警告が出ます。2026年時点ではmatchersフィールドを使うことが標準です。

# 旧記法（非推奨）
match:
  severity: critical
match_re:
  service: "^(foo|bar)$"

# 現行記法
matchers:
  - severity="critical"
  - service=~"^(foo|bar)$"

社内に長く運用してきた設定ファイルや古いドキュメントを参照している場合、旧記法が混在しているケースがあります。amtool check-configを実行すると非推奨フィールドへの警告が出るため、これを手がかりに棚卸しするとよいでしょう。

Kubernetes オペレーター環境での考慮点

kube-prometheus-stackやPrometheus Operatorを使っている環境では、AlertmanagerConfigカスタムリソース（CR）で名前空間ごとにルーティングを分割できます。ただし、AlertmanagerConfigはルートノードへの設定ではなく、サブルートとして挿入される仕組みです。グローバルなデフォルト設定やinhibit_rules全体は引き続きメインのalertmanager.yaml Secretで管理する必要があります。マルチテナント的な運用を検討している場合は、この設計上の制約を理解した上で構成を決めてください。

UTF-8 ラベル値と matchers

Alertmanager 0.27からUTF-8ラベル値のサポートが強化されています。ラベル値に日本語や特殊文字を使っている環境では、matchersの文字列比較が正しく機能するかを確認してください。特に正規表現マッチャー（=~）では、マルチバイト文字を含むパターンの動作をシミュレーションコマンドで事前に検証することが推奨されます。