拆解 OBSERVE 告警引擎：多级阈值、静默期与告警风暴抑制

为什么告警会被当成噪音

值班的人最怕的不是没有告警，而是告警太多。一个服务抖动，几十台实例同时超时，如果每个实例都发一条告警，手机能被打爆。更糟的是，告警一旦被证明是误报，下次真故障来的时候，人会本能地选择忽略。这种「狼来了」效应会累积：每一条噪音告警都在透支整条通知渠道的可信度，直到真正的故障被划过去没人看。

告警系统的价值不在于「能发多少条」，而在于「该发的那条有没有发对、有没有发出去」。OBSERVE 的告警引擎围绕这一条设计：规则可配置、触发有依据、发送有收敛。

规则的三层结构

一条告警规则由三部分组成：

1. 数据源：选日志、指标还是链路。日志按关键词或错误率，指标按阈值，链路按耗时或错误 span 占比。
2. 条件：比较符（大于/小于/等于/百分比）+ 阈值 + 时间窗口。比如「5 分钟内 5xx 错误率大于 1%」。
3. 动作：通知渠道（邮件、Webhook、企业微信）+ 告警级别（P1/P2/P3）+ 是否自动升级。

一条 YAML 规则长这样：

alert:
  name: order-service-5xx
  source: metrics
  query: 'sum(rate(http_5xx{service="order-service"}[5m])) / sum(rate(http_total{service="order-service"}[5m]))'
  condition: "> 0.01"
  for: 5m
  labels: { severity: P2, team: order }
  notify: [wecom, webhook]

for: 5m 是关键：条件持续满足 5 分钟才触发，短时间抖动会被自动过滤，避免毛刺误报。

静默期与重复抑制

两个容易忽略但极有用的配置：

• 静默期（silence）：发布窗口、计划内维护时，把相关告警静默一段时间，恢复后自动继续。避免「发版时告警刷屏，发完没人看」。
• 重复抑制（dedup）：同一告警在恢复前不重复发送，只在状态变化时通知一次（触发一次、恢复一次），而不是每 5 分钟重发一次。

阈值怎么选：绝对值、分位还是错误预算

阈值类型直接决定告警有多吵，常见三种：

• 绝对计数（「5 分钟内错误超过 50 条」）：简单，但流量一涨就误报——流量翻倍，错误自然翻倍，阈值却没跟上。
• 分位延迟（「P99 > 800ms」）：直接反映用户体验，但需要先有基线，低流量时也要小心。
• 错误预算（「一小时烧掉本月 20% 预算」）：SRE 的玩法，把告警绑到真正要紧的东西上，避免为无谓的抖动打扰人。

流量稳定的服务，用比率（错误率）作默认值通常最稳；只有「出现一次就是事故」的场景（比如结算任务失败）才用绝对计数。

告警风暴抑制

这是告警引擎最值钱的部分。当一个故障影响 50 个实例时，引擎会：

1. 分组：按 team/service/region 等标签把告警聚成一组。
2. 收敛：只发一条汇总告警，列出受影响实例数量和 Top 3 实例，而不是 50 条。
3. 关联：把同一时间窗口内同根因的告警标记为主告警 + 从属告警，解决主告警后从属告警自动关闭。

结果是：一条可行动的告警，而不是五十条一模一样的。

落地建议

• 告警阈值别一上来就设得很严，先按两周的正常波动定基线，再设阈值。
• 每个告警规则都写清楚 owner 和 runbook（处理手册链接），接到告警的人知道该找谁、该做什么。
• 定期回看告警数据：哪些规则触发多但没人处理，就删掉或降级，别让噪音堆着。没人响应的规则，只是对值班排班收的税。