Alertmanager の通知設計 – ルーティング、抑制、沈黙、責任分界を分ける

Prometheus で alert rule を定義すると、条件に一致したアラートが発火します。しかし、アラートが発火したことと、誰へ、いつ、どの単位で通知すべきかは別の問題です。

Alertmanager は、この後段を扱うコンポーネントです。Prometheus から受け取ったアラートを束ね、重複を減らし、宛先を決め、条件によって抑制し、作業中の通知を一時的に止めます。つまり、Alertmanager はアラート条件を作る場所ではなく、通知として運用に流す前の制御点です。

この記事では、Alertmanager を単なる通知転送ツールとしてではなく、監視設計の中でどの責任を持つのかという観点から整理します。Prometheus の alert rule、Alertmanager のルーティング、Grafana の表示、Runbook やオンコール運用の境界を分けて考えることが重要です。

Alertmanager はアラートを作る場所ではない

まず分けるべきなのは、アラート条件と通知制御です。Prometheus の alert rule は、どのメトリクスがどの状態になったら異常とみなすかを定義します。一方、Alertmanager は、その異常をどの通知として扱うかを決めます。

要素	主な役割	混同した場合の問題
Prometheus alert rule	アラートが成立する条件を定義する	通知先や運用都合まで式に埋め込みやすい
Alertmanager	通知の束ね方、宛先、抑制、沈黙を制御する	閾値調整の代わりに通知抑制でごまかしやすい
Grafana	状況確認の画面と調査導線を提供する	画面で見えるものをすべて通知対象にしやすい
Runbook	通知後に確認する内容と対応手順を定義する	通知を受けても行動に移せない

通知が多すぎる場合、alert rule の条件が悪いのか、Alertmanager の束ね方が悪いのか、オンコールの責任分界が曖昧なのかを分けて確認する必要があります。すべてを「アラートがうるさい」とまとめると、原因を見誤ります。

通知は発火単位ではなく対応単位で束ねる

Alertmanager の重要な役割の一つは、複数のアラートを一つの通知にまとめることです。Prometheus では、インスタンス単位、Pod 単位、ディスク単位、エンドポイント単位でアラートが発火することがあります。しかし、通知をそのまま発火単位で送ると、障害時に同じ原因から大量の通知が発生します。

通知は、対応する人が一つの事象として扱える単位で束ねる必要があります。サービス単位で見るべきもの、クラスタ単位で見るべきもの、インスタンス単位で見るべきものを分けます。

発火しやすい単位	通知で考える単位	理由
Pod 単位	サービス単位	同じ Deployment の複数 Pod 障害は一つのサービス影響として扱う場合がある
ディスク単位	ホストまたはボリューム単位	対応者が容量を増やす対象に合わせる
HTTP handler 単位	利用者影響単位	個別 API の異常かサービス全体の異常かを分ける
インスタンス単位	冗長構成全体	片系障害とサービス停止では緊急度が異なる

通知を束ねすぎると原因が見えにくくなります。反対に、束ねなさすぎると通知が洪水になります。必要なのは、アラートの発火単位と対応単位を一致させることではなく、対応者が判断できる単位へ変換することです。

ルーティングは通知先の分岐ではなく責任分界である

Alertmanager の route は、アラートのラベルに基づいて receiver を選びます。ここで重要なのは、通知先を機械的に分岐することではなく、責任分界を通知経路として表すことです。

例えば、同じ高レイテンシのアラートでも、アプリケーションの処理遅延、データベースの応答遅延、ネットワーク経路の問題では、見る人も初動も異なります。チーム名、サービス名、環境、重要度、利用者影響などのラベルが、運用上の責任分界と対応していなければ、route は複雑になるだけです。

ルーティング軸	設計で確認すること
severity	緊急度、通知時間帯、エスカレーション条件と対応しているか
team	実際に対応できる責任者またはチームと一致しているか
service	サービス単位の Runbook、ダッシュボード、依存関係があるか
environment	本番、検証、開発で通知先や時間帯を分ける必要があるか
region / cluster	障害範囲の切り分けや担当範囲と一致しているか

通知先を増やすだけでは、運用は強くなりません。誰が受けるべきか、受けた人が何を確認できるか、判断に必要な情報へ移動できるかを含めて route を設計します。

抑制は通知を消す機能ではない

Alertmanager の inhibit は、あるアラートが発生している間、別のアラート通知を抑制するための機能です。代表的には、サービス全体が停止しているときに、その配下の個別エラー通知を抑えるような使い方です。

ただし、抑制は通知を見えなくするための機能ではありません。上位の障害で説明できる下位の通知を減らし、対応者が根本原因に集中できるようにするための機能です。

抑制したい状況	注意点
クラスタ全体の障害中に個別 Pod の通知を抑える	クラスタ障害が本当に個別 Pod 障害を説明できるか確認する
依存先停止中にアプリケーションエラー通知を抑える	依存先復旧後もアプリケーション側に問題が残る場合を考える
ネットワーク到達不可中に監視対象の個別死活通知を抑える	監視経路の障害と監視対象の障害を区別する

抑制条件が強すぎると、重要な二次障害を隠します。弱すぎると、障害時の通知量を減らせません。抑制は静かにするためではなく、原因と結果の関係が説明できる範囲で使います。

silence は恒久対策ではない

silence は、特定条件に一致するアラート通知を一時的に止める機能です。計画メンテナンス、既知障害、検証作業、対応中の重複通知を抑える用途では有効です。

しかし、silence はアラート条件の修正や恒久対策の代替ではありません。期限のない silence、理由のない silence、対象が広すぎる silence は、監視を無効化しているのと同じ状態になります。

silence に必要な情報	理由
対象条件	どのアラートを止めるのかを限定する
開始時刻と終了時刻	作業終了後に通知が戻る状態を保証する
理由	後から監査や振り返りができる
作成者	誰が判断したかを追える
関連チケット	作業、障害、変更管理と接続できる

silence は運用上必要な機能ですが、使いやすいほど危険にもなります。通知を止める操作は、アラートを作る操作と同じくらい設計対象として扱うべきです。

通知先ごとに必要な情報は違う

Alertmanager は、メール、チャット、PagerDuty、Webhook など、複数の通知先へアラートを送れます。ここで考えるべきなのは、どの連携が使えるかではなく、その通知先で何を判断するのかです。

通知先	向いている用途	注意点
チャット	チーム内の共有、状況認識、軽微な確認	重要通知が会話に埋もれやすい
オンコール通知	即時対応が必要な障害	条件が曖昧だと疲弊しやすい
メール	記録性のある通知、非即時の確認	初動対応には遅い場合がある
Webhook	ITSM、チケット、独自ワークフローとの連携	自動処理の責任範囲を明確にする必要がある

同じアラートをすべての通知先へ送ると、情報が増えたように見えて責任が曖昧になります。緊急通知、共有通知、記録通知、自動連携を分け、通知先ごとに期待する行動を固定します。

通知設計はラベル設計に依存する

Alertmanager の設計は、Prometheus のラベル設計に強く依存します。route、group_by、inhibit、silence は、いずれもラベルを条件として扱います。アラートに必要なラベルがなければ、通知制御は後から複雑になります。

一方で、通知制御のためにラベルを増やしすぎると、Prometheus 側のカーディナリティや alert rule の複雑化につながります。ラベルは、検索性、集計、責任分界、通知制御のすべてに影響するため、メトリクス設計と Alertmanager 設計を別々に決めることはできません。

ラベル	通知設計での意味
alertname	どの種類の異常かを識別する
severity	緊急度や通知経路を決める
team	責任チームへ通知する
service	影響範囲や Runbook を選ぶ
cluster	障害範囲や運用担当を分ける

Alertmanager だけでは通知疲れは解決しない

通知疲れは、Alertmanager の設定だけで解決する問題ではありません。通知が多すぎる背景には、アラート条件の粗さ、メトリクス設計の不足、サービスの責任分界の曖昧さ、Runbook の不在、対応不要な状態まで通知している設計などが含まれます。

Alertmanager は通知量を制御できますが、対応不要なアラートを価値あるアラートに変えるわけではありません。発火条件、通知条件、対応条件を分けて見直す必要があります。

問題	見直す場所
一時的な揺れで通知される	alert rule の条件、評価時間、SLO との関係
同じ原因で大量通知される	group_by、inhibit、アラート粒度
誰も対応しない通知がある	severity、receiver、責任分界、Runbook
メンテナンス中も通知される	silence、変更管理、作業予定との連携
通知後に原因へ進めない	annotation、Grafana、Loki、Runbook へのリンク

まとめ

Alertmanager は、Prometheus で発火したアラートを通知として運用に流す前の制御点です。アラート条件を作る場所ではなく、通知の束ね方、宛先、抑制、沈黙、エスカレーションを設計する場所です。

通知は、発火した時系列の単位ではなく、対応者が判断できる単位でまとめます。route は通知先の分岐ではなく責任分界を表し、inhibit は原因と結果の関係が説明できる範囲で使います。silence は一時的な作業や既知事象に使うものであり、恒久対策の代替にはなりません。

Alertmanager の設計は、Prometheus のラベル設計、Grafana の調査画面、Loki のログ確認、Runbook、オンコール運用と接続して初めて成立します。通知を減らすことが目的ではありません。対応に必要な通知だけを、必要な相手へ、必要な情報とともに届けることが目的です。

参考書籍

参考資料

• Prometheus: Alertmanager
• Prometheus: Alertmanager configuration
• Prometheus: Notification template examples

関連する記事