Prometheus 告警管理器配置器

解决什么问题

AlertManager 的配置文件看起来不长，真正写起来却很容易踩坑。一次告警风暴里，同一个问题的多个告警会同时触发，通知渠道被重复消息淹没；而手工维护 route、inhibit_rules 和 receivers 三层结构时，缩进错位、label 写错、静默规则与抑制规则打架这类问题往往要到线上出事才被发现。更现实的问题是：团队用了 PagerDuty 做值班、Slack 做频道广播、OpsGenie 做分派，但配置文件里常常只有其中一个渠道，其余靠事后补写，慢慢变成无人敢改的巨石 YAML。

它如何工作

这个技能负责生成 AlertManager 配置，而不是替代 AlertManager 本身。核心工作分三层：

• 路由树（routing trees）：根据你给的告警 label 设计 route 层级，让告警按服务、集群或严重程度分流到不同的 receiver，避免所有消息挤在同一条通道。
• 抑制规则（inhibition rules）：为高优告警压制其下游衍生告警，比如节点宕机时抑制该节点上所有服务告警，直接减少通知噪音。
• Receiver 集成：把 PagerDuty、Slack、OpsGenie 的 API 接入点写成对应 receiver 的配置，三者可以并存，也可以按路由分别启用。

在此基础上，它支持 模板化通知定制：用模板控制消息内容，把告警名、摘要、标签等字段塞进通知正文，而不是只发一条默认文本。你只需要描述拓扑和诉求，它输出一份结构完整、可以审核的配置草稿。

适用边界与注意点

• 这个技能产出的是配置文件，部署、热加载（/-/reload）以及与 Prometheus 的对接仍要按你环境里的标准方式完成。
• 生成的路由和抑制规则是否合理，取决于你提供的 label 结构和告警依赖关系；信息不足时建议先给一个保守的基础配置，再逐步收紧。
• 模板语法需与你的 AlertManager 版本兼容，接入前最好用官方工具做一次配置校验，避免上线才发现解析错误。
• 多渠道配置下，注意各 API 的 rate limit 与静默窗口行为差异，避免抑制规则把合法告警一并吞掉。