本文目录导读：
我为你整理了一份关于 Prometheus Alertmanager 的详细实战案例解析，Alertmanager 是整个监控体系中负责“告警通知”的核心组件，它的核心能力包括：分组（Grouping）、抑制（Inhibition）、静默（Silence）。
下面我将通过 3 个典型场景案例，从配置到排障，逐步拆解。
业务系统宕机与恢复（基础告警 + 路由分发）
场景描述：监控所有核心业务服务器，当 node_exporter 上报的 up 指标为 0（即服务器宕机或服务停止）时，需要立即通知运维团队（发邮件给运维组），并且应用恢复后要发送恢复邮件。
告警规则配置 (Prometheus rules.yml)
需要在 Prometheus 中定义触发条件。
groups:
- name: node_alerts
rules:
- alert: "InstanceDown"
expr: up == 0
for: 1m # 持续1分钟才触发，防止抖动
labels:
severity: critical
annotations:
summary: "实例 {{ $labels.instance }} 已停止"
description: "{{ $labels.instance }} 已宕机超过1分钟，Job: {{ $labels.job }}"
Alertmanager 核心配置 (alertmanager.yml)
global:
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: 'alert@qq.com'
smtp_auth_username: 'alert@qq.com'
smtp_auth_password: '授权码'
smtp_require_tls: false
route:
# 顶级路由：根据标签 severity 进行分发
group_by: ['alertname'] # 按告警名称分组
group_wait: 10s # 组内首次等待时间
group_interval: 5m # 组内新告警发送间隔
repeat_interval: 4h # 重复告警间隔
receiver: 'default-receiver'
routes:
- match:
severity: critical
receiver: 'critical-email' # 严重告警走邮件
continue: false
receivers:
- name: 'default-receiver'
email_configs:
- to: 'ops@company.com'
send_resolved: true # 发送恢复通知
- name: 'critical-email'
email_configs:
- to: 'oncall@company.com'
send_resolved: true
效果与演进
- 效果：
node_exporter挂了 -> Prometheus 产生InstanceDown-> Alertmanager 收到后匹配severity: critical-> 发送邮件到oncall@company.com，恢复后，由于send_resolved: true，会收到“恢复”邮件。 - 进阶：如果只想在夜间让“值班人员”收到，可以结合
inhibit_rules抑制非关键告警，或者通过 webhook 接入钉钉/企业微信机器人（替代email_configs）。
大规模集群下的告警风暴抑制（分组与抑制）
场景描述：K8s 集群中某个节点宕机，导致该节点上的 50 个 Pod 全部变为 Pending，如果每个 Pod 都发一条告警，将会造成告警轰炸，我们期望只发出“节点宕机”的告警，抑制掉该节点上所有 Pod 的告警。
告警规则设计（Prometheus）
- 规则 A：
NodeDown(node 节点挂了) - 规则 B：
PodPending(Pod 无法调度，通常伴随节点异常)
Alertmanager 抑制配置（关键）
inhibit_rules:
# 高级别告警抑制低级别告警
- source_match: # 源告警（触发抑制的）
severity: 'critical'
target_match_re: # 目标告警（被抑制的），使用正则
severity: 'warning|info'
equal: ['namespace'] # 当 namespace 相同时生效
# 场景：节点宕机时，抑制该节点上所有 Pod 的告警
- source_match:
alertname: 'NodeDown'
target_match:
alertname: 'PodPending'
equal: ['node'] # 当 node 标签一致时，Pod 告警被抑制
分组配置（防止轰炸）
在 route 上增加分组策略，将同一资源（例如同一集群）的告警合并到一条通知中。
route: group_by: ['cluster', 'alertname'] # 按集群和告警名分组
实际效果
- 节点
node01挂了 -> 生成NodeDown告警。 node01上 50 个 Pod 状态异常 -> 生成 50 条PodPending告警。- Alertmanager 通过
inhibit_rules检测到NodeDown存在，且equal: ['node']匹配，直接丢弃（抑制）这 50 条PodPending告警。 - 最终运维只收到 1 条 NodeDown 通知，以及后续新出现的、非该节点问题的告警。
业务发布时的告警静默（Silence）
场景描述：应用每周五凌晨 2 点进行版本发布，发布期间重启服务会导致请求延迟升高（触发 APILatencyHigh 告警）或实例重启（触发 InstanceDown），为了避免误报打扰，需要在发布窗口内静默这些告警。
创建静默规则（UI 或 Yaml）
在 Alertmanager UI 界面（/#/silences）点击“New Silence”，或者通过 API 创建。
通过 amtool 命令行创建：
amtool silence add \ --alertmanager.url=http://localhost:9093 \ --author="Deploy-Bot" \ --comment="Scheduled maintenance: v2.3 release" \ --duration=2h \ --starts-at="2023-10-27 01:55:00" \ 'alertname=APILatencyHigh' \ 'app=my-service'
静默匹配规则（Matchers）：
- 精确匹配：
alertname="APILatencyHigh" - 正则匹配：
instance=~"web-.*" - 组合：
severity="warning"且env="production"
静默与抑制的区别（重点理解）
- Silence（静默）：基于未来时间的计划任务，在部署前手动配置，告诉 Alertmanager“未来这 2 小时，如果有匹配的告警，请闭嘴”。
- Inhibit（抑制）：基于当前状态的关联关系，系统自动判断“既然根因是这个，其他相关的小问题就别报了”。
验证静默是否生效
在 Alertmanager UI 的“Status”页面，可以看到被静默的告警显示为 Muted 状态（灰色/黄色），虽然它们仍然在 Alertmanager 中，但不会触发通知。
实战排障排查手册（附加）
当告警没有按预期发送时,可以按以下步骤排查：
- 检查 Alertmanager 是否收到告警：Prometheus UI -> Status -> Targets 查看 Alertmanager 是否在线；Alertmanager UI -> Status 查看红色告警列表。
- 检查路由树：Alertmanager UI -> Status -> Text 或 UI 中的
Route Tester工具，输入标签（如severity="critical"），测试数据会走哪个 Route，匹配哪个 Receiver。 - 告警被抑制了吗？：在 Alertmanager 首页看告警是否有
Inhibited标签（通常显示为 ⛔）。 - 告警被静默了吗？：查看是否有锁🔒标志。
- 查看 Logs：
docker logs <alertmanager_container>查看并搜索dispatch、notification关键词，确认是发送失败还是未触发。
这份案例涵盖了监控告警最核心的三大痛点：触达（邮件/IM）、防打扰（抑制/静默）、降噪（分组），如果你的需求偏向于与钉钉/飞书/企业微信机器人集成，我可以为你补充对应的 webhook_configs 使用示例。
