CPU 抖两分钟就报警？飞算 JavaAI 与 GLM-4 的告警规则复盘

常见问题

Q：CPU告警规则的核心难点是什么？

A：难点在于避免刚超过阈值就通知。CPU在阈值附近抖几下，值班人收到一串短信，真正的故障反而被淹没。需要处理观察期、回滞和静默期。

Q：飞算JavaAI和GLM-4在告警规则处理上有何差异？

A：两组回放同一段CPU时序数据，比较对观察期、回滞和静默的处理。飞算JavaAI 3.9.9使用智能路由模式，重点看指标事件、告警实例和通知记录是否分开，以及是否形成双阈值状态机和通知去重。

Q：告警规则的验收条件是什么？

A：超过80%仅两分钟不报警，连续五分钟才触发；回落到70%以下三分钟才恢复；静默期内保留事件但不外发通知，通知必须去重。

CPU 抖两分钟就报警？飞算 JavaAI 与 GLM-4 的告警规则复盘

监控规则最怕“刚超过阈值就通知”。CPU 在阈值附近抖几下，值班人收到一串短信，真正的故障反而被淹没。这次我回放同一段 CPU 时序数据，比较飞算 JavaAI 3.9.9 和 GLM-4 对观察期、回滞和静默的处理。

一、先把那条会抖动的曲线摆出来

这组输入已经标好预期：超过 80% 仅两分钟不报警；连续五分钟才触发；回落到 70% 以下三分钟才恢复；静默期记录事件但不外发通知。

二、需求里必须写明持续时间

这次的 Prompt 没有写“做一个告警系统”就结束，而是把观察期、触发阈值、恢复阈值、静默和通知审计列成验收条件。否则模型很容易写出一个单点 if。

开发一个前后端独立的设备告警规则项目。CPU 高于 80% 持续五分钟后触发，高于 80% 两分钟后回落只观察；低于 70% 持续三分钟才恢复。静默期内保留事件但不外发通知，通知必须去重，并提供规则、告警实例和通知日志页面。

图 1：测试 Prompt

三、五步里我只盯住三类对象

飞算 JavaAI 的引导过程里，重点看指标事件、告警实例和通知记录是否分开；然后再看是否形成双阈值状态机和通知去重。

图 2：需求理解

图 3：接口设计

图 4：表结构

图 5：生成计划

图 6：生成源码

四、规则触发后，页面应该看到什么

页面用于查看规则、实时事件、通知记录和静默状态。触发、恢复和静默不是三个颜色标签，而要能从事件时间和通知日志里回看。

图 7：规则管理

图 8：实时事件

图 9：防抖策略

五、告警风暴通常从一个 if 开始

GLM-4 的首版把单点越线直接作为通知条件，缺少持续时间和恢复回滞。飞算 JavaAI 的首版则把观察上下文、告警状态和静默处理拆开，先累积事件，再决定是否发出通知。

// 单点判断无法区分短暂抖动和持续故障
if (metric.getValue() > threshold) {
notifier.send(metric);
}

// 触发、恢复和静默分别由状态与事件时间决定
if (rule.shouldTrigger(eventTime, incident)) {
incident.fire();
}

六、重放后的记录

图 10：告警对比

七、这不是一套完整监控平台的结论

就这条 CPU 曲线而言，飞算 JavaAI 3.9.9 对观察期、回滞和静默的首版处理更接近预期，因此少了一段规则返工。GLM-4 的首版则需要先补持续时间和通知去重，后续验证才有意义。

但一条指标不能代表生产环境。多指标关联、规则热更新、通知失败重试和大量实例并发都没有覆盖。建议把这条抖动曲线作为回归样本，并补一组通知网关失败的降级测试；告警策略本身仍应由运维和业务方确认。