Prometheus 告警规则降噪实战：SLO 错误预算驱动的告警分级框架 + 可落地 Alertmanager 配置模板

背景

SRE 团队在 Prometheus 2.40 + Alertmanager 0.25 体系下，告警规则膨胀到 300+ 条后，平均每周收到 200+ 条告警，其中约 70% 是噪音（重复、低优先级、无明确行动项）。值班同学逐渐对告警脱敏，真正的 P0 故障反而被淹没。

我复盘过两次因告警疲劳导致的响应延迟事故（一次是磁盘 80% 告警每天 3 次 → 真正 95% 时没人看；一次是 Pod 重启告警未分组 → 一次 OOM 风暴产生 47 条告警刷屏）。核心问题不是规则写得少，而是没有分级 + 没有预算意识。

最终要什么

请交付以下四件套（均 Markdown / YAML 格式）：

1. 告警分级框架文档（Markdown，≥1500 字）

• P0（立即响应）/ P1（30 分钟内响应）/ P2（工作时间内响应）/ P3（次日处理）四级定义
• 每级包含：触发条件（什么指标越什么阈值）、响应时限、升级路径（谁→谁→多久未响应自动升级）、是否触发 OnCall 电话
• 明确「什么不该告警」的反面清单（≥5 条）

2. SLO 错误预算驱动的告警规则重写方案（Markdown，含代码块）

• 基于三个 SLO（可用性 99.9%、P99 延迟 <500ms、错误率 <0.1%）推导告警阈值
• 至少 5 个指标的 before/after 对比（建议覆盖：CPU 使用率、内存 OOM、API P99 延迟、5xx 错误率、Pod 重启次数）
• 每个对比含：原始 PromQL（有问题的）→ 重写后 PromQL（含注释说明改了什么、为什么）
• 解释 burn rate 双窗口（快窗口 5m / 慢窗口 1h）的取舍

3. Alertmanager 路由配置模板（YAML）

• 可直接 kubectl apply 的完整配置（语法校验通过）
• 包含：路由分组（按服务 / 按严重级别）、抑制规则（P0 抑制 P1/P2/P3 同类）、沉默规则示例
• 至少 3 个 receiver（P0 电话 + webhook、P1 钉钉/企微、P2/P3 邮件）
• 注释关键参数（group_wait、repeat_interval 等）

4. 告警规则审计 Checklist（Markdown）

• 不少于 10 项检查，每项含：检查项描述、判定标准（通过/不通过）、常见反例
• 覆盖维度：阈值合理性、标签一致性、分组正确性、重复检测、无行动项检测、过期规则清理

输入与上下文

• 监控栈：Prometheus 2.40+ / Alertmanager 0.25+ / Grafana 9+
• 监控对象：K8s 1.27 集群（node + pod + service 三层）+ 3 个核心业务 API
• 已有 SLO 定义：可用性 99.9%（月度）、P99 延迟 <500ms（5 分钟窗口）、5xx 错误率 <0.1%（5 分钟窗口）
• 团队规模：5 名 SRE，两班倒值班
• 不需要对接具体 IM 工具，receiver 用 webhook 占位即可

交付格式

• 一个目录，含：
  • framework.md（分级框架 + 反面清单）
  • rules-rewrite.md（before/after 对比 + burn rate 说明）
  • alertmanager.yml（路由配置模板）
  • checklist.md（审计 Checklist）
  • README.md（部署步骤 ≥5 步 + 验证命令 + 常见问题 FAQ ≥3 条）
• 所有 PromQL 需在 Prometheus 2.40 语法下可执行
• alertmanager.yml 需通过 amtool check-config 校验