こんにちは。オブザーバビリティの世界へようこそ。
「アラートが鳴り止まなくて、結局みんな通知を無視するようになってしまった……」
「夜中に100通のメールが届いたけれど、原因はすべて同じシステムの瞬断だった……」
もしあなたが運用監視の現場に足を踏み入れたばかりなら、こうした「アラート地獄」の話を一度は耳にしたことがあるかもしれません。でも、安心してください。PrometheusとAlertmanagerを正しく理解し、その「設計思想」を味方につければ、監視はあなたを苦しめるものではなく、システムを守る最強の武器になります。
今日は、Prometheusのエコシステムにおける「通知の司令塔」、Alertmanagerの世界を案内します。これをマスターすれば、あなたの運用は劇的に楽になり、チームからの信頼も一気に高まるはずです。
—
1. 「検知」と「通知」を分ける。これがPrometheusの美学
まず最初に、最も大切な概念をお話しします。Prometheus単体では、実は「メールを送る」ことも「Slackに投稿」することもできません。
- Prometheus（検知の脳）: メトリクスを監視し、「閾値を超えた！」という状態（Alerting Rule）を判断する。
- Alertmanager（通知の心臓）: Prometheusから送られてきたアラートを受け取り、「誰に・いつ・どのように」伝えるかを制御する。
なぜ分かれているのか？ それは、大規模なシステムでは「1つの障害で100個のアラートが発生する」からです。Prometheusが愚直に100通のメールを送ったら、現場はパニックになります。Alertmanagerは、それらを「グルーピング（集約）」し、「インヒビション（抑制）」し、適切なルートへ流す役割を担っているのです。
—
2. Alertmanagerの心臓部：`alertmanager.yml` を読み解く
Alertmanagerの設定は、非常に論理的です。まずは基本となる設定ファイルの構造を見てみましょう。
global:
# 外部URLなどの共通設定
resolve_timeout: 5m # アラートが解消したと判断するまでの猶予期間
通知先（Receiver）の定義
receivers:
- name: ‘slack-notifications’
slack_config:
- api_url: ‘https://hooks.slack.com/services/Txxx/Bxxx/Xxxx’ # 後述するWebhook URL
channel: ‘#monitoring-alerts’
title: ‘{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}’
text: ‘{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}’
アラートをどう振り分けるか（Route）の定義
route:
group_by: [‘alertname’, ‘cluster’, ‘service’] # どのアラートをひとまとめにするか
group_wait: 30s # 最初のアラートが鳴ってから、他を待つ時間（集約の肝！）
group_interval: 5m # 次のバッチを送るまでの間隔
repeat_interval: 4h # 同じアラートが続く場合、再送するまでの間隔
receiver: ‘slack-notifications’ # デフォルトの通知先
ここがプロの視点：
`group_wait: 30s` の設定に注目してください。これがあるおかげで、0.1秒差で次々と発生する関連アラートを、Alertmanagerは「おっ、まとめて1通の通知にしよう」と待ってくれるのです。
—
3. Slack Webhookを使った「最初の疎通確認」
まずは動かしてみることが一番の近道です。Slackへの通知テストを成功させましょう。
1. Slack Appの作成: Slack APIのサイトから `Incoming Webhooks` を有効にし、通知したいチャンネルを選んでWebhook URLを取得します。
2. 設定の反映: 上記の `alertmanager.yml` の `api_url` に取得したURLを貼り付けます。
3. Prometheus側の設定: `prometheus.yml` にAlertmanagerの場所を教えてあげます。
prometheus.yml
alerting:
alertmanagers:
- static_configs:
- targets:
- localhost:9093 # Alertmanagerが動いているアドレス
4. テスト用のアラートを投げる:
まだPrometheusのルールを書いていなくても、AlertmanagerのAPIを直接叩いて通知テストができます。
curl -H “Content-Type: application/json” -d ‘[
{
“labels”: {
“alertname”: “TestAlert”,
“severity”: “critical”,
“instance”: “localhost”
},
“annotations”: {
“summary”: “テストアラートです”,
“description”: “AlertmanagerからSlackへの疎通確認に成功しました！”
}
}
]’ http://localhost:9093/api/v2/alerts
Slackに通知が届きましたか？ 届いたなら、あなたは「通知のパイプライン」を構築する第一歩を完璧に踏み出しました。
—
4. 現場で震えるほど役立つ「鳴りすぎ防止」の極意
初心者が陥る罠、それは「全アラートを即座に通知する」設定です。これを避けるための3つの知恵を授けます。
① グルーピングの魔法 (`group_by`)
例えば、1つのDBサーバーがダウンしたとき、そのDBを使っている10個のマイクロサービスが同時に「接続エラー」を吐きます。
`group_by: [‘cluster’]` と設定していれば、通知は「10通」ではなく「クラスターAで異常発生」という「1通」にまとまります。
② PagerDutyとの連携（エスカレーション）
重大な障害（Severity: critical）だけはPagerDutyで電話を鳴らし、それ以外（Severity: warning）はSlackに流す。これがプロのルーティングです。
route:
receiver: ‘slack-notifications’ # 基本はSlack
routes:
- match:
severity: ‘critical’
receiver: ‘pagerduty-urgent’ # 重大なものだけPagerDutyへ
③ インヒビション（抑制設定）
「データセンター全体がダウンしているなら、その中の個別のサーバーダウン通知はいらない」という設定が可能です。
inhibit_rules:
- source_match:
severity: ‘critical’
target_match:
severity: ‘warning’
equal: [‘alertname’, ‘cluster’]
これで、重大なアラート（source）が出ている間は、同じ場所の軽微なアラート（target）を黙らせることができます。
—
おわりに：オブザーバビリティの旅はここから
PrometheusとAlertmanagerの設定は、一度作って終わりではありません。
「この通知は本当に必要だったか？」「もっと早く気づくためのラベルはないか？」と、チームで話し合いながら育てていくものです。
今回紹介した設定は、あくまで基礎。しかし、この「グルーピング」と「ルーティング」の思想さえ持っていれば、あなたはもうアラートの海で溺れることはありません。
これをマスターすれば、毎日の運用作業が劇的に楽になり、本当に価値のある開発の時間を取り戻せるはずですよ。
さあ、次はあなたのシステムの「心拍数」をSlackに繋いでみましょう。何か困ったことがあれば、いつでも聞いてくださいね。応援しています！