4. 告警降噪核心思想：告警风暴成因、降噪三原则

在误差预算台账体系中，告警降噪不是简单的“把告警关掉”，而是通过系统性设计，在减少重复、减少误报、减少噪音三个维度上建立规则，使每一条告警都具备可操作性与业务关联性。本节从告警风暴的成因入手，推导出降噪三原则，并给出对应的 Prometheus 实现策略。

4.1 告警风暴的典型成因

告警风暴（Alert Storm）是指短时间内大量告警同时触发，导致值班人员无法有效响应、关键告警被淹没的现象。在误差预算场景中，告警风暴通常由以下四种模式引发：

4.2 降噪三原则

基于告警风暴的成因，我们提炼出三条核心降噪原则。每条原则都对应具体的 Prometheus 配置策略。

原则一：减少重复（Deduplication）

同一故障事件只产生一条告警，避免多维度、多路径的重复触发。

• 聚合维度归一： 在 alerting.rules 中固定使用 service + slo_name 作为告警标签，禁止同时按 instance、pod、node 分别告警。
• 抑制规则（Inhibition）： 当高等级告警（如 Critical）触发时，自动抑制同源的 Warning 告警。
• 分组（Grouping）： 在 Alertmanager 中按 service 和 severity 分组，同一组内的告警合并为一条通知。

# Alertmanager 分组配置示例
group_by: ['service', 'severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h

原则二：减少误报（False Positive Reduction）

提升告警触发条件的准确性，避免因瞬时抖动、数据缺失或配置错误导致的无效告警。

• 多窗口确认： 使用 for 子句设置持续时间，要求条件持续满足至少 5 分钟才触发告警。
• 误差预算消耗率联动： 告警阈值不应是固定值，而应基于剩余预算的动态消耗速率计算。
• 数据质量检查： 在告警规则中加入 count(...) by (service) 检查，确保指标数据源正常，避免因采集中断产生误报。

# 多窗口确认 + 数据质量检查示例
- alert: ErrorBudgetBurnRateHigh
  expr: |
    (
      (1 - (rate(sli_requests_total{status="success"}[1h]) / rate(sli_requests_total[1h])))
      * 100
    ) > 5
    and
    count(sli_requests_total[5m]) > 0
  for: 5m
  labels:
    severity: warning

原则三：减少噪音（Noise Reduction）

过滤掉对值班人员无实际指导意义的告警，包括恢复通知、低优先级重复提醒、以及业务低峰期的非关键告警。

• 恢复通知静默： 对于自动恢复的告警，不发送 resolved 通知，仅在告警详情页记录。
• 时间窗口过滤： 在业务低峰期（如凌晨 2:00-6:00），将部分 Warning 告警降级为 Info 日志。
• 告警疲劳控制： 设置 repeat_interval 为 4 小时以上，避免同一告警频繁重复提醒。

4.3 降噪三原则与告警风暴的对应关系

下图展示了告警风暴的四种成因与降噪三原则之间的映射关系，以及每条原则在 Prometheus 生态中的具体实现组件。

4.4 降噪效果的量化评估

降噪不是一次性配置，而是持续优化的过程。建议使用以下指标评估降噪效果：