告警引擎详解：从阈值判断到告警风暴治理

告警不是“超过阈值就叫”

静态阈值是最常见的告警来源，也是误报最多的来源。CPU 到 90% 就叫，凌晨备份任务一跑就响，值了三个月班的人最后把这些告警都静音了——告警一旦失去可信度，整个监控体系就废了。

OBSERVE 告警引擎要解决的核心问题是：把一个异常信号翻译成“在正确的时间、用正确的方式、通知正确的人”，并且不要淹没对方。这中间有几层：规则怎么表达、重复怎么压掉、通知怎么升级。

规则模型：多条件 + 持续时长 + 相对基线

一条规则远不止“指标 > 阈值”。完整表达式支持四类能力：

• 多条件组合：error_rate > 0.02 AND qps < 100，AND/OR 任意嵌套；
• 持续时长：for: 3m，指标连续 3 分钟越界才触发，过滤瞬时毛刺；
• 相对基线：同比上周同时段、环比前 5 分钟，而不是写死绝对值；
• 多指标关联：一个规则里同时看错误率和延迟，两者同时异常才算数。

一个典型规则长这样：

rules:
  - name: order-api-degraded
    expr: error_rate{service="order"} > 0.02 AND p99{api="/order/create"} > 800ms
    for: 3m
    labels: { severity: P1, team: order, runbook: "runbook/order-degraded" }

for 是误报的第一道闸门。生产环境建议 P0 用 1-2 分钟、P1 用 3-5 分钟，太短容易被毛刺触发，太长又延误响应。

降噪三件套：分组、抑制、静默

告警风暴是压垮值班的第一杀手。一个上游服务挂了，几十个下游一起报警，手机瞬间被打爆。引擎内置三种手段：

• 分组：相同标签（service、cluster）的告警合并成一条通知，只发一次；
• 抑制：P0 触发时自动抑制同一来源的 P1/P2，比如“网关不可用”抑制“网关延迟高”；
• 静默：发布窗口、计划维护时段预先设静默，这段时间的告警不通知但留审计记录。

三者叠加后，一次真实故障通常只产生一条 P0 通知加一条汇总，而不是几十条。

通知路由与升级链路

通知渠道支持短信、电话、企业微信、钉钉、邮件。核心是升级链路：P0 通知值班人后若 5 分钟未确认，自动升级到二线负责人，再未确认升级到团队负责人，逐级上溯。值班表按周轮转，引擎自动找当前值班人，不用手工改联系人。

通知内容里直接带上告警图、关联的 trace 链接和 runbook 地址——值班人收到通知就能下钻，不用再问“现场在哪、怎么处理”。

落地建议

• 每条规则必须挂 runbook 链接，没有处理手册的告警先别上线；
• 阈值优先用相对基线，绝对值只用于有明确 SLO 的指标；
• 每月做一次告警复盘，删掉连续一个月没触发过的规则——没用的告警是噪音，不是安全网。