告警不轰炸：炬鲸 OBSERVE 的告警降噪与分级分派

告警不是越多越好

先说一个真实场景。某支付团队把「错误率大于 1%」「响应时间超过 200ms」「磁盘使用率大于 80%」全部配成告警，结果一次服务抖动，一分钟内能刷出几十条通知。值班的人很快养成习惯——先把告警群静音，再慢慢看。告警一旦失去信任，真正的事故反而没人点开。

炬鲸 OBSERVE 的告警引擎核心思路只有一条：让每一条告警都值得被点开。围绕这个目标，它分三层实现——规则定义、降噪聚合、分级分派。

规则：用表达式写清楚「什么算异常」

规则支持三类触发条件，可以自由组合：

• 阈值类：cpu_usage > 80 且持续 5 分钟
• 错误率类：5 分钟内 error_rate > 0.5%
• 关键词类：日志中出现 OutOfMemoryError 或 connection reset

一条规则可以同时挂多个条件，命中任意一个即触发。建议给规则加 for 参数，让异常持续一段时间才告警，避免瞬时抖动误报：

alert: 订单服务错误率
expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.005
for: 3m

for: 3m 的意思是：错误率连续 3 分钟超过 0.5% 才触发。这一行能挡掉绝大多数由发布、扩缩容引起的瞬时毛刺。

降噪：把 50 条合并成 1 条

降噪靠三招。

第一招是按维度聚合。同一服务、同一错误类型只发一条，而不是每个实例、每台机器各发一条。第二招是静默窗口。凌晨发版、计划内维护这类例行变更，可以手动或按计划静默，避免操作本身刷屏。第三招是告警分组。把同一根因的告警归到一个组，一次只通知一次，后续新增的相同告警只是往这个组里追加，不再重复打扰。

配合恢复通知，只有「触发到恢复」这个完整生命周期才值得关注，中间的重复提醒一律省略。

分派：谁该收到，多久升级

分派按严重级别走不同通道：

• P0（核心链路不可用）：电话 + 短信 + 企业微信，5 分钟无人确认自动升级到值班经理
• P1（业务受损）：企业微信 + 邮件，30 分钟未确认升级
• P2（预警）：仅企业微信群，不强制确认

每条通道都支持重试与超时升级，解决「消息发出去了但没人看见」的问题。

落地建议

上线第一周建议只开 P0 和 P1，把 P2 当成观察项静默记录。等团队对告警的信噪比满意了，再逐步放开。告警的价值从来不在数量，而在每一次响起都有人行动。