告别拍脑袋设阈值：炬鲸 OBSERVE 的动态基线告警

固定阈值为什么总在“狼来了”

设告警阈值是运维里最尴尬的活。设高了，真出问题收不到通知；设低了，凌晨三点被误报叫醒。更麻烦的是，很多业务指标天生随时间波动——白天 QPS 高、凌晨低，工作日高、周末低，大促期间直接翻几倍。一个固定阈值，永远只能覆盖真实曲线里的一小段。

举个真实例子：某订单服务的 QPS 平时在 500 上下，大促当天冲到 3000。如果你把阈值设成 800，平时没问题，但大促一开场就“告警刷屏”；如果设成 5000，大促是安静了，可平时服务挂掉一半你都收不到通知。这就是固定阈值的结构性缺陷：它假设指标是平的，而业务指标从来不是平的。

后果通常有两条：要么告警疲劳，团队把告警群静音，真故障也看不见；要么干脆不设告警，靠用户投诉才发现问题。

炬鲸 OBSERVE 的做法是用动态基线代替固定阈值：系统根据指标的历史分布自动学习“正常区间”，只有当前值明显偏离正常时才触发告警。

动态基线怎么算

动态基线不是简单的滑动平均——滑动平均只能平滑曲线，学不会“什么算正常”。我们把一条指标拆成三层来学：

• 趋势层：取过去 30 天同一时刻的中位数，捕捉“凌晨低、白天高”这类周期规律
• 周规律层：区分工作日与周末/节假日，避免周末流量低被误判为异常
• 波动层：用历史波动幅度计算上下界，比如“过去 7 天同时刻 95 分位 ± 2 倍标准差”

三层叠加，得到的是一个随时间和星期变化的“带宽”，而不是一条死线。回到上面的订单服务：大促当天，系统会参考“去年同期大促”和“最近流量爬坡”自动抬高带宽上界，QPS 冲到 3000 也算正常，不会误报；而如果某个凌晨 QPS 突然比历史同时刻高出三倍，即使绝对值不高，也会触发告警——因为“凌晨不该这么忙”本身就是异常信号。

只有当前值连续 N 个采样点都越界，才会触发告警——这个 N 可以配置，用来过滤瞬时毛刺。

alert:
  name: "订单服务 QPS 异常"
  metric: order_service_qps
  type: dynamic_baseline
  sensitivity: medium        # low/medium/high
  consecutive: 3             # 连续越界次数
  cooldown: 30m              # 冷却时间，避免告警风暴
  notify: ["email", "wecom"]

灵敏度决定带宽的松紧：high 意味着带宽更窄，对小幅偏离更敏感，适合延迟这类本身噪声小的指标；low 则更宽容，适合 QPS 这类天然抖动大的指标。拿不准就先 medium，观察一周再调。

什么时候不该用动态基线

动态基线不是万能药，有几种情况更适合保留固定阈值：

• 硬性容量上限：比如“数据库连接数不能超过 2000”，这是资源天花板，超了就是超了，用基线反而会掩盖问题
• 二进制指标：服务存活、端口探测，0 就是挂、1 就是好，没有“正常波动”可言
• 样本太少的新服务：上线不足一周，历史数据不足以建立可靠基线，系统会自动回退到固定阈值并提示你补充数据

我们的建议：容量类指标用固定上限，流量、延迟、错误率这类“会呼吸”的指标用动态基线，两者可以叠加在同一个服务上——比如“连接数超过 2000 立即告警”和“QPS 偏离基线 3 个采样点告警”同时生效，各管各的。

落地建议

从最容易误报的指标开始迁移。按我们的经验，RPC 延迟、消息队列积压、GC 次数这三类指标是固定阈值误报的重灾区，先把它们切到动态基线，告警量通常能降一半以上。

切换后留一周观察期：如果某天告警明显偏多，先确认是不是真有异常（比如一次灰度发布），而不是急着调灵敏度。等团队对“这个平台懂我的业务曲线”建立信任后，再逐步把更多指标迁过来。

动态基线的价值不在于少几条告警，而在于让剩下的每条告警都值得点开看。当团队不再半夜被“狼来了”叫醒，白天的真故障才不会被淹没在静音里。