技能介绍

有多少条告警其实从未送达

当 Prometheus 集群规模上来后，rules/ 目录往往由多人维护，经历过多次拆分与合并。一条 recording rule 的指标名写错、一条 alerting rule 的 for 时长与 label 覆盖范围不匹配，静态检查未必能立刻发现。更隐蔽的问题在 Alertmanager 一侧：route tree 中某个子树的 group_by 和 continue 配置不一致，或者某个 receiver 的 mute_time_intervals 恰好覆盖了关键时段，结果故障发生了却没有任何通知到达值班群。这类「告警静默失败」通常要到真实故障或演练时才会暴露，代价已经产生。

审计分成三层

规则层：调用 promtool check rules 对 recording rule 与 alerting rule 做静态校验，覆盖语法错误、非法 PromQL、重复定义的 series 等基础问题。

路由层：解析 Alertmanager 的 routing tree，追踪每条告警最终能否落到一个 receiver，识别因标签不匹配而被静默丢弃的分支，以及被静默时段意外屏蔽的通知路径。

数据层：通过 Prometheus HTTP API 把告警表达式拉到实时 TSDB 数据上实际执行一次，验证规则在真实数据下确实会触发，并观察触发边界是否符合预期。

适用边界

它需要能访问 Prometheus 的 HTTP API 与 Alertmanager 的路由配置，输出是审计结论而非修复补丁，不会替你改写配置文件。它检查的是规则与路由的完整性，不替代容量规划、SLO 设定或告警文案本身的治理。另外 promtool 版本与目标 Prometheus 版本不一致时可能出现误报，第三方仓库的规则格式差异也需要人工确认。