AlertmanagerでSlack通知を設定する方法（Webhook作成からテスト送信まで）

Alertmanager から Slack に通知するには、Slack 側で Incoming Webhook の URL を発行し、alertmanager.yml の受信先（receiver）に slack_configs として書き、Prometheus のアラートルールが Alertmanager に届くようにします。この記事では、Webhook URL の発行と安全な保管、最小構成の設定、読みやすいメッセージのテンプレート、amtool を使ったテスト送信、届かないときの切り分けまでを順に説明します。

通知が届くまでの流れ

設定を始める前に、どこで何が起きるかを押さえておくと、届かないときの切り分けが楽になります。

1. Prometheus がアラートルールの条件（expr）を定期的に評価する。条件が for の時間だけ続くと、アラートは pending から firing になる
2. firing になったアラートを Prometheus が Alertmanager に送る
3. Alertmanager がルーティング（route）に従って受信先を決め、似たアラートをまとめ（group）、Slack の Webhook に送信する

つまり「Prometheus 側のルール」「Prometheus から Alertmanager への接続」「Alertmanager から Slack への送信」の3か所が正しくないと通知は届きません。

Slack で Incoming Webhook の URL を発行する

Slack では、ワークスペースに Slack アプリを作成し、その機能の一つである Incoming Webhooks を有効にして、投稿先のチャンネルを選ぶと Webhook URL が発行されます。手順の画面や名称は Slack 側の更新で変わることがあるため（2026年10月現在）、詳しくは Slack の開発者向けドキュメント（api.slack.com）を確認してください。ワークスペースの設定によっては、アプリの追加に管理者の承認が必要です。

発行された URL は https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX のような形をしています。この URL を知っている人は誰でもそのチャンネルに投稿できるため、パスワードと同じように扱います。

• Git リポジトリにコミットしない（設定ファイルを Git 管理するなら、URL は別ファイルにして除外する）
• ファイルに保存する場合は、Alertmanager の実行ユーザーだけが読める権限にする
• 漏れた疑いがあれば、Slack 側で Webhook を削除して再発行する

# Webhook URL を別ファイルに保存（ユーザー名はインストール方法に合わせる）
sudo install -o root -g alertmanager -m 0640 /dev/null /etc/alertmanager/slack_webhook_url
sudoedit /etc/alertmanager/slack_webhook_url   # URL を1行だけ書いて保存

まず Slack 側だけで動くかを確かめておくと、後の切り分けが楽になります。

curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"Webhook のテストです"}' \
  "$(sudo cat /etc/alertmanager/slack_webhook_url)"

ok と返り、チャンネルに投稿されれば Slack 側の準備は完了です。

alertmanager.yml に Slack の受信先を書く

最小構成の例です。設定ファイルの場所はインストール方法によって異なります（公式バイナリなら任意、Debian/Ubuntu のパッケージでは /etc/prometheus/alertmanager.yml の場合があります）。変更前に今のファイルをバックアップしておいてください。

global:
  resolve_timeout: 5m

route:
  receiver: slack-default
  group_by: ['alertname', 'instance']
  group_wait: 30s        # 最初の通知までまとめて待つ時間
  group_interval: 5m     # 同じグループに新しいアラートが加わったときの再通知間隔
  repeat_interval: 4h    # 状況が変わらないときに同じ通知を繰り返す間隔

receivers:
  - name: slack-default
    slack_configs:
      - api_url_file: /etc/alertmanager/slack_webhook_url
        send_resolved: true
        title: '[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }}'
        text: >-
          {{ range .Alerts }}
          *{{ .Annotations.summary }}*
          {{ .Annotations.description }}
          対象: {{ .Labels.instance }}
          {{ end }}

ポイントは次のとおりです。

• api_url_file：Webhook URL を設定ファイルに直接書かず、別ファイルから読みます。api_url に直接書くこともできますが、設定ファイルを共有・バックアップするときに URL が一緒に広まってしまいます。古いバージョンでは api_url_file に対応していない場合があるため、alertmanager --version で版を確認してください。
• send_resolved: true：問題が解消したときにも通知します。解消の連絡が無いと、Slack を見た人が「まだ続いているのか」を判断できません。
• channel：Incoming Webhook は発行時に選んだチャンネルに投稿するため、通常は指定不要です。チャンネルごとに分けたい場合は、チャンネルごとに Webhook を発行して receiver を分けるのが分かりやすい方法です。
• title / text：Go のテンプレート構文で書きます。アラートルールの annotations に書いた summary と description を表示する形にしておくと、ルール側で文面を管理できます。

書いたら、文法を確認してから再読み込みします。

amtool check-config /etc/alertmanager/alertmanager.yml
sudo systemctl reload alertmanager   # 対応していなければ restart

重要度でチャンネルを分ける

すべてのアラートを1つのチャンネルに流すと、重要な通知が埋もれます。severity ラベルで振り分ける例です。

route:
  receiver: slack-default
  group_by: ['alertname', 'instance']
  routes:
    - matchers:
        - severity="critical"
      receiver: slack-critical
      repeat_interval: 1h

receivers:
  - name: slack-default
    slack_configs:
      - api_url_file: /etc/alertmanager/slack_webhook_url
        send_resolved: true
  - name: slack-critical
    slack_configs:
      - api_url_file: /etc/alertmanager/slack_webhook_url_critical
        send_resolved: true

matchers は比較的新しい書き方で、古い設定例で見かける match / match_re は非推奨になっています。どちらが使えるかは版で異なるため、手元の版のドキュメントに合わせてください。

Prometheus 側のアラートルールと接続設定

Prometheus の設定（prometheus.yml）に、Alertmanager の場所とルールファイルを書きます。

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["localhost:9093"]

rule_files:
  - /etc/prometheus/rules/*.yml

ルールの例として、監視対象が応答しなくなったときのアラートを作ります。

# /etc/prometheus/rules/node.yml
groups:
  - name: node
    rules:
      - alert: InstanceDown
        expr: up{job="node"} == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} から応答がありません"
          description: "5分以上メトリクスを取得できていません。サーバーとnode_exporterの状態を確認してください。"

promtool check rules /etc/prometheus/rules/node.yml
sudo systemctl reload prometheus

for: 5m は、条件が5分続いて初めて通知するという意味です。一瞬の取りこぼしで通知が飛ぶのを防げますが、そのぶん通知は遅れます。

テスト送信する

障害を起こさなくても、amtool で Alertmanager に直接テスト用のアラートを送れます。

amtool alert add alertname=SlackTest severity=warning instance=test \
  --annotation=summary="Slack通知のテストです" \
  --alertmanager.url=http://localhost:9093

group_wait（例では30秒）が過ぎると Slack に届きます。テスト用のアラートは既定では一定時間で自動的に解消扱いになり、send_resolved を有効にしていれば解消の通知も届きます。

届かないときの切り分け

上の3か所のどこで止まっているかを順に確認します。

1. Alertmanager のログに送信エラーが出ていないか：journalctl -u alertmanager -n 100 を見ます。Slack への送信に失敗すると、通知の失敗やリトライのメッセージが出ます。Webhook が削除・無効化されていると、Slack からエラーの応答（no_service など）が返ります。URL ファイルの末尾の余分な空白や改行にも注意します。
2. Alertmanager にアラートが届いているか：Alertmanager の Web 画面（既定は 9093 番）か amtool alert query --alertmanager.url=http://localhost:9093 で一覧を確認します。ここに無ければ Prometheus 側の問題です。
3. Prometheus でアラートが firing になっているか：Prometheus の Alerts 画面で状態を見ます。pending のままなら for の時間が経っていないか、条件が満たされていません。Status の画面で Alertmanager が認識されているかも確認します。
4. サイレンスや抑制（inhibit_rules）に引っかかっていないか：メンテナンス時に作ったサイレンスが残っていると、通知は送られません。

サーバーから Slack への外向き通信がファイアウォールやプロキシで止められているケースもあります。先ほどの curl によるテストがサーバー上で成功するかで確認できます。

まとめ

• 通知は「Prometheus のルール → Alertmanager → Slack の Webhook」の順に流れ、どこか1か所でも誤りがあると届きません。
• Webhook URL は秘密情報として扱い、api_url_file で別ファイルから読み、Git には入れません。
• send_resolved: true で解消も通知し、severity ラベルで重要度ごとにチャンネルを分けると見落としが減ります。
• 設定は amtool と promtool で文法を確認し、amtool alert add でテスト送信してから本番の運用に入ります。

• node_exporterでLinuxのメトリクスを収集する方法
• Alertmanagerのルーティングとサイレンスの設定方法