Prometheus仅负责发现异常并推送告警至Alertmanager，后者执行分发、去重、合并、路由和静音；告警规则在Prometheus侧用YAML定义，含ALERT、expr、for、labels、annotations字段，Alertmanager依据标签通过route和receivers配置实现分级路由与通知。
Prometheus 本身不直接发通知，它只负责“发现异常”并把告警推给 Alertmanager；真正做分发、去重、合并、路由和静音的，是 Alertmanager。要让报警规则有效落地，必须把 Prometheus 的规则定义和 Alertmanager 的分发逻辑打通——不是配完 rule_files 就完事，关键在两者的协同。
告警规则写在 Prometheus 侧
规则文件（如 alert.rules）用 YAML 定义，核心结构是 ALERT + expr + for + labels + annotations：
-
expr 是 PromQL 表达式，比如
avg by(instance)(rate(http_requests_total[5m])) ，表示某实例连续 5 分钟请求量归零 - for 指持续满足条件的时间，避免瞬时抖动误报；建议至少设为 2–5 分钟
-
labels 不只是打标记，更是 Alertmanager 路由和分组的依据，比如加
team: "backend"或severity: "critical" -
annotations 用于生成通知正文，支持模板变量如
{{ $labels.instance }}和{{ $value }}
Alertmanager 负责智能分发
它不看指标，只看 Prometheus 推过来的告警携带的标签。分发行为由 alertmanager.yml 中的 route 和 receivers 决定：
-
group_by 指定按哪些标签聚合成一条通知，常见组合是
['alertname', 'severity', 'cluster']；同一组内多条告警，等 group_wait（如 30s）后合并发送 - receiver 对应具体通知方式，比如邮件、钉钉 Webhook 或 Slack；一个 receiver 可配多个 webhook_configs 或 email_configs
- 可通过嵌套 routes 实现分级路由，例如 severity=critical → 发给 oncall；severity=warning → 只发企业微信
避免告警泛滥的三个关键控制点
光有规则和路由还不够，得靠参数压住节奏：
-
group_interval：同一组告警再次通知的最小间隔，比如设为
4h，防止故障未恢复时每分钟都刷屏 - repeat_interval：即使告警状态没变，也按此周期重发通知（适用于需要定期提醒的场景），一般比 group_interval 短
- inhibit_rules：配置抑制关系，例如主机 down 了，就自动屏蔽它上面所有服务的告警，避免次要告警淹没主因
静默和调试建议
上线前建议用 Alertmanager Web UI（默认端口 9093）验证：
- 点开 “Alerts” 页面，确认告警是否进入 Pending 或 Firing 状态
- 点 “Silences” 手动加一条静默，测试维护窗口屏蔽效果
- 在 “Status” → “Routing tree” 查看当前路由匹配逻辑，确认标签是否被正确识别和分流
- 临时把 receiver 的 webhook 地址换成 http://httpbin.org/post，观察实际推送的 JSON 结构，核对 labels 和 annotations 是否完整传入
