概要 ​

Part 4-1で Prometheus がアラート条件を評価し alert を生成する仕組みを学びました。次のステップは「生成されたアラートを誰に、どのように通知するか」を管理することです。それを担当するのが AlertManager です。

AlertManager は Prometheus からアラートを受け取り、定義した rules に基づいてルーティング、グループ化し、Slack・メール・PagerDuty などの複数の通知先に配信します。Part 4-1 で定義した labels（severity など）を活用して、柔軟な通知配信を実現するわけです。

AlertManager の役割 ​

AlertManager と Prometheus の役割分担は明確です。Prometheus は「何が問題か」を判定し、AlertManager は「それを誰に知らせるか」を決めます。

Prometheus が alert を Firing 状態と判定すると、HTTP POST で AlertManager に送信します。AlertManager はそのアラートを受け取り、ルーティングルール（route）に基づいて通知先（receiver）を決定し、配信前に同じ条件のアラートを集約・グループ化して重複を排除します。

複数の Prometheus インスタンスがある場合、AlertManager を 1 つの集約ポイントとして配置し、すべての Prometheus から alert を受け取る構成も一般的です。

alertmanager.yml の基本構造 ​

AlertManager の設定ファイルは YAML 形式で、3つの主要セクション（global・route・receivers）で構成されています。

yaml
global:
  resolve_timeout: 5m

route:
  receiver: 'default'
  group_by: ['severity']

receivers:
  - name: 'default'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'

global セクションは AlertManager 全体の共通設定です。resolve_timeout はアラートが未解決状態をどのくらい保持するかを指定します。この値を超えても Prometheus からの更新がなければ、AlertManager はそのアラートを解決済みと判定します。

route セクションはアラートのルーティングツリーです。条件に応じてアラートをどの receiver に送るか、またはサブルート（routes）で条件分岐させるかを定義します。

receivers セクションは通知先の定義です。各 receiver に名前を付け、Slack webhook や メール設定などを記述します。

ルーティングルールの実装 ​

ルーティングはマッチャーを用いて条件指定します。Part 4-1 で定義した labels の値に基づいて、「このラベル値を持つアラートはこの receiver へ」という分岐を作成します。

yaml
route:
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
    - match:
        service: api
      receiver: 'slack-api-team'

match で条件を指定することで、条件に合致したアラートはそのルートに流れます。複数の match を並べると OR の関係になり、いずれかの条件に該当するアラートがそのルートに流れるというわけです。

グループ化による通知削減 ​

同じアラートが複数発火した場合、それぞれを個別に通知するのではなく「同じ条件のアラートはひとまとめに通知する」がグループ化です。

group_by に ['severity', 'service'] と指定した場合、severity と service の値の組み合わせごとにアラートがグループ化されます。例えば 3 台のサーバーから「severity: critical, service: web-api」というアラートが同時に発火しても、「Web API で critical アラートが 3件」という 1 つの通知にまとめられます。これにより通知数を大幅に削減でき、運用チームの負荷を軽減できます。

グループタイムアウト設定 ​

グループタイムアウトは、同じグループに属するアラートをどのくらいまとめるかを制御する 3 つのパラメータです。

group_wait は、最初のアラートを受け取ってから通知を送信するまで待機する時間です（デフォルト 10 秒）。この間に同じグループの後続アラートが到着すればまとめて 1 つの通知として送信します。例えば group_wait: 30s に設定すれば、最初のアラートから 30 秒間、後続アラートを待ってからまとめて通知します。

group_interval は、既存グループへの後続アラート到着時に、再度通知を送信するまでの間隔です。これにより「新しいアラートが追加された」という情報を運用チームに伝えられます。group_interval: 5m に設定すれば、既存グループに新しいアラートが追加されても前回の通知から 5 分経つまで通知しません。

repeat_interval は、グループの状態が変わらない場合に定期的に通知を再送信する間隔です（デフォルト 12 時間）。これにより通知を見落とした運用チームにも問題を認識させられます。

通知先設定 ​

通知先は receivers セクションで定義します。name で通知先に名前を付け、その下に通知方法ごとの設定を記述します。

Slack 統合 ​

Slack 統合は webhook URL を使います。Slack ワークスペースの設定で Incoming Webhook を有効化し、webhook URL を取得して設定します。

yaml
receivers:
  - name: 'slack-alerts'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'
        channel: '#alerts'
        title: 'Prometheus Alert'
        text: 'Service: {{ .GroupLabels.service }} | Severity: {{ .GroupLabels.severity }}'

channel で通知先チャネルを指定できます。title と text はメッセージのフォーマットです。内部ではグループラベルを参照する変数展開が使えますが、本文はまず概要説明に絞り、詳細は Slack チャネルのスレッドで確認する運用が一般的です。

メール設定 ​

メール通知は SMTP サーバー設定を使います。global セクションで SMTP サーバーを指定し、receivers で送信先メールアドレスを定義します。

yaml
global:
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: '[email protected]'

receivers:
  - name: 'email-ops'
    email_configs:
      - to: '[email protected]'
        headers:
          Subject: 'AlertManager Notification'

smtp_smarthost で SMTP サーバーアドレスとポートを指定します。smtp_from は送信元メールアドレスです。receivers で個別の receiver ごとに to で受信者メールアドレスを指定します。

ルーティング設計パターン ​

実務で使う 3 つの基本パターンを紹介します。

パターン1：単純ルーティング ​

すべてのアラートを 1 つの receiver に送信する最もシンプルな構成です。組織が小さい場合や初期段階ではこれで十分です。

yaml
route:
  receiver: 'slack-all'
  group_by: ['severity']

receivers:
  - name: 'slack-all'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'

すべてのアラートを slack-all という 1 つの receiver に送信します。group_by で severity により分類されることで、通知は「critical」「warning」というように整理されます。

パターン2：階層ルーティング ​

チーム・サービスごとに異なる通知先に振り分けるパターンです。組織が複数チームに分かれている場合に有効です。

yaml
route:
  receiver: 'default'
  routes:
    - match:
        service: api
      receiver: 'slack-api-team'
    - match:
        service: db
      receiver: 'slack-db-team'

Part 4-1 で service ラベルを定義していれば、service の値に基づいて分岐できます。API サービスのアラートは API チーム向けの Slack チャネル、データベース関連は DB チーム向けというように振り分けることができます。

パターン3：優先度ベースルーティング ​

severity に基づいて通知方法を変え、critical は即座に、warning は非同期という使い分けです。オンコール体制がある組織に適しています。

yaml
route:
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      repeat_interval: 5m
    - match:
        severity: warning
      receiver: 'slack-warnings'
      repeat_interval: 1h

severity: critical は PagerDuty で即座に対応者に通知、severity: warning は Slack で柔軟に対応という 2 段階の振り分けです。repeat_interval も異なり、critical は 5 分ごとに再通知、warning は 1 時間ごとというように、対応の急切度に応じた設定ができます。

ベストプラクティス ​

グループタイムアウト設定指針 ​

group_wait は 5～30 秒の間が実務的な目安です。critical アラートが多い組織では group_wait: 0s に設定し、個別通知とすることもあります。

group_interval は 5 分～1 時間の間が多いです。短めに設定すれば「新しい問題が発生した」という情報をリアルタイムに伝えられますが、通知が多くなります。

repeat_interval は 12 時間がデフォルトですが、オンコール体制がある場合は 30 分～1 時間に短くすることがあります。見落とし防止の観点から、短めに設定する傾向があります。

ラベル戦略 ​

ルーティングの効率は Part 4-1 で定義したラベルの質に左右されます。severity・service・alert_type などを計画的に定義していれば、ここで柔軟なルーティングが実現できます。最初からこの 2 つを連携させて設計することが重要です。

設定検証 ​

alertmanager.yml の構文をチェックするには amtool というコマンドを使えます。本番環境に deploy する前に、事前に検証しておくことで意図しない配信を防げます。

前のセクション：Part 4-1 - アラートルール基礎

次のセクション：Part 4-3 - Prometheus + AlertManager + Grafana統合運用