介绍炬鲸 OBSERVE 告警引擎：阈值、动态基线与复合表达式三种规则，聚合去重与静默降噪，告警升级与值班排班。用一条 CPU 告警串起完整处理链路，帮运维把告警信噪比提上来。
告警系统的目标不是把异常都发出来，而是让值班的人在正确的时间、只收到需要他处理的告警。现实中大多数告警系统恰恰相反：一个数据库抖动，能连锁触发几十条告警，真正需要处理的根因反而被刷屏淹没。炬鲸 OBSERVE 的告警引擎从三个环节解决这个问题：规则怎么写、告警怎么降噪、通知怎么送达。
最基础的是阈值规则，比如 cpu_usage > 90% 持续 5 分钟。它简单直接，但有两个硬伤：固定阈值在业务低峰期的正常波动里频繁误报，在缓慢泄漏型故障里又迟迟不触发。所以炬鲸提供了动态基线：系统用最近 7 天的历史数据拟合出每个指标的波动带，实际值偏离基线超过一定倍数才触发，凌晨的小幅异常、节假日流量形态变化都能抓得住。
第三种是复合表达式，把多个条件用逻辑组合起来：
avg(cpu_usage) > 80 and (error_rate > 0.05 or queue_depth > 1000)这类规则适合描述"多个症状同时出现才需要干预"的场景，能显著减少单指标抖动带来的误报。写规则时有个实用原则：先问"这条告警发出去，值班的人能做什么动作"，答不上来的规则就别建。
告警风暴是值班的头号噩梦。炬鲸做了三层降噪。一是去重：同一告警在冷却窗口内只发一次，后续触发只累计次数，不重复轰炸。二是聚合：把同一集群、同一服务的多条告警合并成一条通知，附上受影响实例列表，让"服务 X 挂了"只到一条而不是每个 Pod 一条。三是静默：支持按时间段（发布窗口）、按标签（env=staging）临时屏蔽，定时生效、手动解除。
这三层默认开启前两层，静默规则在「告警中心 → 静默管理」里配置。落地后值班群消息量通常能砍掉一半以上。
降噪之后是"送达给谁"。炬鲸支持告警升级：一条告警在 N 分钟内无人确认，自动升级给上一级——先发值班工程师，10 分钟没确认升级到值班组长，再 30 分钟没确认升级到技术负责人，避免"告警发了但没人看"。同时内置值班排班：按周排好 on-call 轮转，系统自动把告警路由给当前值班人，不用每次手动改通知人。
通知渠道覆盖邮件、短信、企业微信/钉钉/飞书和 Webhook，Webhook 可以把告警打进自建的工单系统或 IM 机器人。建议给每条规则显式指定响应级别（P1/P2/P3），升级链和通知方式按级别走：P1 直接电话加短信，P3 只进群消息。
以"订单服务 CPU 持续 90%"为例：动态基线检测到偏离，生成告警，与同服务的其他告警聚合，按 P1 级别进入升级链，路由到本周值班人，值班人在控制台一键确认并跳转到关联的链路追踪和日志。从触发到送达全程留痕，事后可按告警反查当时的指标快照、关联 trace 和日志，复盘有据可依。