Contents
1. アラートルーティング
1‑1. ルーティングの概要
route セクションはアラートがどの受信先（receiver）へ送られるかを決定する核です。ラベルマッチや正規表現で絞り込んだ上で、continue フラグにより「マッチしたルートだけで処理を完了させる」か「下位のルートも評価し続ける」かを制御できます。
1‑2. 設定例
|
1 2 3 4 5 6 7 8 9 10 |
route: receiver: default-receiver # デフォルト受信先 routes: - match_severity: critical # severity=critical のアラートだけが対象 receiver: pagerduty-crit continue: false # マッチしたらここで終了 - match_severity: warning receiver: slack-devops continue: true # 以降のルートも評価（必要に応じて追加通知） |
上記例では critical アラートは PagerDuty に直接送信し、warning は Slack の devops チャンネルへ転送されます。
2. 抑制とサイレンシング
2‑1. 用語の整理
- 抑制（Inhibit）: あるアラートが発生している場合に、別の条件に合致したアラートを自動的に送信しないようにする仕組みです。主に「上位レベルの障害が既に通知済み」なときに下位レベルのノイズを削減します。
- サイレンシング: ユーザーが任意の期間・対象ラベルでアラート出力を手動で無効化する機能です。Web UI や API から作成できます。
2‑2. 抑制ルール例
|
1 2 3 4 5 6 7 |
inhibit_rules: - source_match: severity: critical # 上位（source）となるアラートの条件 target_match: severity: warning # 下位（target）になるアラートの条件 equal: [alertname, instance] # 同一 alertname と instance の組み合わせで抑制 |
この設定により、同じインスタンス上で critical が発生している間は同一 alertname の warning は送信されません。
2‑3. サイレンシングの作成例（API）
|
1 2 3 4 5 6 7 8 9 10 11 |
curl -XPOST -d '{ "matchers": [ {"name":"severity","value":"warning","isRegex":false}, {"name":"team","value":"devops","isRegex":false} ], "startsAt":"2024-10-01T00:00:00Z", "endsAt":"2024-10-02T06:00:00Z", "createdBy":"alice@example.com", "comment":"夜間は warning を抑制" }' http://alertmanager.example.com/api/v2/silences |
ポイント
- 抑制は「自動的に」適用されるのに対し、サイレンシングは「手動で」期間や対象を指定して無効化します。
3. アラートのグループ化とテンプレート
3‑1. グループ化の目的
同種アラートが大量に発生した場合、group_by, group_wait, group_interval を調整することで「まとめて通知」し、チャネルへの負荷を軽減できます。
3‑2. テンプレートエンジンの基本
Alertmanager は Go のテンプレートエンジンを採用しており、.CommonLabels, .Alerts などの組み込み変数を利用してメッセージ本文や件名を動的に生成できます。2024 年時点でサポートされている構文は公式ドキュメント（[Prometheus Alertmanager Templates][2]）に記載されています。
3‑3. Slack 用テンプレート例
|
1 2 3 4 5 6 7 8 9 10 11 12 |
receivers: - name: slack-devops slack_configs: - channel: "#devops-alerts" title: "{{ .CommonAnnotations.summary }}" text: | {{ range .Alerts }} *Alert:* {{ .Labels.alertname }} ({{ .Labels.severity }}) *Instance:* {{ .Labels.instance }} *Description:* {{ .Annotations.description }} {{ end }} |
このテンプレートは複数のアラートを 1 件にまとめ、重要情報だけを抜き出して Slack に送ります。
4. ベストプラクティス：優先度別ルーティングとアラート疲労防止策
4‑1. 背景
組織が大規模になるほど同一インシデントに対する重複通知が増え、Alert Fatigue が顕在化しやすくなります。適切な優先度設計と抑制戦略を組み合わせることで、重要度の高いアラートだけが確実に届くようになります。
4‑2. 優先度別ルーティング設計
| 階層 | severity ラベル | 受信先（receiver） | continue の有無 |
|---|---|---|---|
| 1 | critical | pagerduty-crit | false （上位だけで完了） |
| 2 | high | service-now-high | true （下位にも通知） |
| 3 | warning | slack-warn | true |
| 4 | info | slack-summary | - |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
route: receiver: slack-summary routes: - match: severity: critical receiver: pagerduty-crit continue: false - match: severity: high receiver: service-now-high continue: true - match: severity: warning receiver: slack-warn continue: true |
効果：Critical な障害は即時対応チームへ直送し、同時に全体共有用のサマリも Slack に流すことで情報格差を防ぎます。
4‑3. インシデント管理ツール連携
- PagerDuty Events API v2:
routing_keyを設定するだけで自動的にインシデントが生成されます。 - ServiceNow Table API: アラート情報を JSON 化して POST すると、障害チケットが自動作成・ステータス更新できます。
参考：Sysdig が公開した「Prometheus + Alertmanager を用いた RBAC 活用事例」では同様の連携が実装されており、具体的な API 呼び出し例が示されています[1]。
|
1 2 3 4 5 6 7 8 9 10 11 |
receivers: - name: pagerduty-crit pagerduty_configs: - routing_key: "<PD_ROUTING_KEY>" severity: "critical" - name: service-now-high webhook_configs: - url: "https://instance.service-now.com/api/now/table/incident" http_config: bearer_token_file: "/etc/sn-token/token" |
4‑4. アラート抑制戦略
| 手法 | 設定ポイント | 主な効果 |
|---|---|---|
| 時間帯ベースのサイレンス | silence API で夜間は warning 系を停止 |
夜間ノイズ削減 |
| インシデント抑制ルール | inhibit_rules に source_match.severity=critical を設定 |
同一障害で冗長通知防止 |
| チーム別サイレンス | UI/CLI で team=<name> ラベルを対象に作成 |
チーム単位の集中対応 |
5. RBAC とマルチテナンシーによる安全な運用
5‑1. なぜ RBAC が必要か
大規模組織では「誰がどのアラートを閲覧・操作できるか」を明確にしないと、情報漏洩や誤操作リスクが高まります。Alertmanager は外部 OIDC プロバイダーとの連携で細粒度のアクセス制御が可能です。
5‑2. RBAC 設定例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
auth: type: oauth2 client_id: "<client-id>" client_secret: "<client-secret>" provider_url: "https://sso.example.com" authorization: role_map: - role: admin permissions: ["*"] - role: devops permissions: ["read", "silence"] - role: viewer permissions: ["read"] |
- admin：全権限（設定変更、サイレンス作成）
- devops：閲覧＋サイレンス操作のみ
- viewer：読み取り専用
GitOps パイプラインで alertmanager.yml をコード管理し、シークレットは Kubernetes Secret に格納すれば安全に運用できます。
5‑3. マルチテナンシー構成（実例）
Sysdig のブログ[1]では次のようなパターンが紹介されています。
- Namespace ごとに独立した Alertmanager インスタンス をデプロイし、
--cluster.peerで相互連携 - 共通テンプレート・ポリシーは ConfigMap 経由で共有
- OIDC クライアントをテナントごとに分離 してロールを個別適用
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# alertmanager-tenant-a.yaml global: resolve_timeout: 5m route: receiver: slack-a routes: - match: team: a receiver: slack-a receivers: - name: slack-a slack_configs: - channel: "#team-a-alerts" |
テナント B は match.team: b とし、別チャンネルへ振り分けます。
6. CI/CD・GitOps による Alertmanager の自動デプロイ
6‑1. リポジトリ構成例
|
1 2 3 4 5 6 7 8 9 |
infra/ ├─ prometheus/ │ ├─ values.yaml # Helm values │ └─ alerts/ # PrometheusRule CRD (*.yaml) └─ alertmanager/ ├─ config/ │ └─ alertmanager.yml └─ templates/ # Go テンプレート |
infra/prometheus/alerts/に置いたPrometheusRuleは Prometheus が自動でロードinfra/alertmanager/config/alertmanager.ymlを単一ソースとして管理し、Argo CD が差分検知・適用
6‑2. Argo CD デプロイフロー
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
# argocd-app-alertmanager.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: alertmanager spec: project: default source: repoURL: https://github.com/your-org/infra.git targetRevision: HEAD path: alertmanager helm: valueFiles: - values.yaml destination: server: https://kubernetes.default.svc namespace: monitoring syncPolicy: automated: prune: true selfHeal: true |
PR 作成時に kube-score と helm lint を CI で実行し、設定エラーがあればデプロイをブロックします。これにより「コード → PR → 自動テスト → 本番適用」の一貫したフローが確立できます。
7. 外部ツール統合と最新テンプレート構文例
7‑1. Grafana 連携（Webhook）
|
1 2 3 4 5 6 |
receivers: - name: grafana-webhook webhook_configs: - url: "https://grafana.example.com/api/alertmanager" send_resolved: true |
Grafana 側で Alerting → Notification channels → Alertmanager を有効化し、受信 URL と API トークンを設定すると、Grafana のパネルから直接アラートが流れます。
7‑2. Slack / Microsoft Teams 向けブロック形式
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
receivers: - name: slack-prod slack_configs: - channel: "#prod-alerts" send_resolved: true title: "{{ .CommonAnnotations.summary }}" text: | {{ range .Alerts }} *Alert:* {{ .Labels.alertname }} ({{ .Labels.severity }}) *Instance:* {{ .Labels.instance }} *Description:* {{ .Annotations.description }} {{ end }} |
Teams 用は msteams_configs（Argo Rollouts が提供）を利用し、同様に JSON で sections を組み立てます。
7‑3. JSON 化テンプレートの実装例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
receivers: - name: webhook-generic webhook_configs: - url: "https://hooks.example.com/alert" http_config: bearer_token_file: "/var/run/secrets/kubernetes.io/serviceaccount/token" send_resolved: true text: | { "alerts": [ {{ range $i, $a := .Alerts }} {{ if $i }},{{ end }} { "name": "{{ $a.Labels.alertname }}", "severity": "{{ $a.Labels.severity }}", "labels": {{ $a.CommonLabels | toJson }}, "annotations": {{ $a.CommonAnnotations | toJson }} } {{ end }} ] } |
.CommonLabels | toJson によりラベル全体を JSON 化でき、外部システムがパースしやすくなります（公式ドキュメント参照[2]）。
参考文献
- Sysdig Blog – “Alertmanager + Prometheus: RBAC & Multi‑Tenant Design” (2024)
https://sysdig.com/blog/alertmanager-rbac-multi-tenant/ - Prometheus Alertmanager Documentation – Templates (最新版)
https://prometheus.io/docs/alerting/latest/template/
以上で、Alertmanager の基本構成・主要機能からベストプラクティス、RBAC／マルチテナンシー、GitOps による自動デプロイまでを網羅的に解説しました。適切な優先度設計と抑制戦略でアラート疲労を防止し、RBAC とマルチテナンシーで安全かつスケーラブルな運用基盤を構築できるはずです。