从阈值到智能收敛：炬鲸 OBSERVE 告警引擎能力拆解

告警引擎先解决“没人看”的问题

监控系统最常被吐槽的不是“抓不到问题”，而是“半夜三点连发几十条短信”。阈值配松了漏报，配紧了误报，运维最后要么关掉告警，要么麻木地点“已读”，真故障反而被淹没在噪声里。一个典型例子：某服务错误率白天稳定在 0.1%，但凌晨流量低谷偶发超时，如果阈值按全天平均值来设，这个时段的问题永远触达不到，值班的人睡一觉就错过了一次真实劣化。炬鲸 OBSERVE 的告警引擎围绕三个目标设计：漏报可控、误报可收敛、处置可追踪。

四种告警类型，覆盖大多数场景

第一种是阈值告警：CPU、内存、错误率、P99 延迟等指标超过设定值即触发，适合资源类问题。第二种是关键字告警：日志流里出现指定 pattern（如 OutOfMemoryError、连接池耗尽、支付回调持续失败）就触发，适合无法用指标表达的业务异常。第三种是同比/环比告警：和上周同期或上一时段对比，波动超过一定幅度才告警，能抓住“没到阈值但明显异常”的隐性故障，比如周末流量曲线悄悄偏移。第四种是复合告警：多个条件用 AND/OR 组合，例如“错误率大于 5% 且 QPS 未下降”才触发，减少单指标抖动带来的误报。四种类型都支持按严重程度分级（提示、警告、严重、致命），不同级别走不同通知渠道。

抑制、去重、升级：让告警安静下来

告警的真正问题在于“风暴”——数据库一挂，下游几十个服务同时报“连接超时”，运维被刷屏。炬鲸 OBSERVE 用三层机制收敛：

• 抑制：配置抑制链后，根因告警（如 mysql-down）会压制所有下游告警，只保留一条
• 去重：同一条告警在窗口期内只通知一次，重复触发只更新计数
• 升级：告警 N 分钟未被确认，自动升级到更高优先级或电话渠道

计划内发布、维护窗口可以用静默规则整体跳过，避免发布时被自己的告警轰炸。一条规则配置长这样：

alerts:
  - name: order-service-error-rate
    metric: http_error_rate
    condition: "> 0.05"
    window: 5m
    dedup: 10m
    suppress_by: [mysql-down]
    escalate_after: 15m
    notify: [dingtalk, webhook]

通知闭环，别让告警石沉大海

告警支持企业微信、钉钉、飞书、邮件、Webhook、短信等渠道。每条告警都带 trace id 和日志快照，点开链接直接跳到对应调用链，不用再手动搜日志。处理人、处理时长、处理结果全部记录，形成可追溯的处置闭环，也为后续复盘和 SLO 统计提供数据。告警与 SLO 打通后，能直观看到错误预算的消耗速度，“到底该不该叫醒这个人”从拍脑袋变成看数据。

三个常见误区

• 给所有指标都配告警：结果就是告警疲劳，建议只告警“需要人行动”的事
• 只看平均值：延迟的平均值会掩盖长尾，告警应基于分位数（P95/P99）
• 告警只发不跟踪：没有确认、没有升级、没有复盘，告警等于没发

上手建议

先别急着配一堆阈值。建议先只对“用户可见的错误率”和“核心依赖可用性”配告警，跑一周观察误报率，再逐步收紧。告警的价值不在于数量，而在于每一条都能让人做出动作。