在线监测平台的告警规则怎么设计

做在线监测平台的厂商，几乎都经历过同一个阶段：阈值设低了，一场雷雨过后告警刷满屏，值班人员干脆不看了；阈值设高了，设备慢慢老化，等告警响起来已经该换了。

问题不在阈值设多少，而在一个阈值根本分不清"短期波动"和"长期劣化"。

我们做过一个避雷器雷冲电流在线监测平台，下面用这个项目说说告警规则怎么拆。完整的项目情况可以看 避雷器在线监测平台案例，平台能力可以对照 电力设备在线监测系统开发。

先理解设备的"正常"长什么样

避雷器的老化是个慢过程。全电流可能一年、几年缓慢上升；雷击之后又会短暂升高，然后回落。如果平台只盯着当前值，这两种情况看起来一模一样。

所以设计规则之前，要先和设备厂商的工程师把几件事说清楚：

• 正常运行时各指标的范围和波动幅度
• 雷击等事件发生后，数值会怎么变化、多久恢复
• 什么情况算"需要关注"，什么情况算"需要更换"
• 同一安装点的 A、B、C 三相之间应该有什么关系

这些判断标准是规则的基础，平台只是把它们自动化。

把规则拆成几类，各管一件事

那个项目最后用了 7 类规则，每一类只负责一种情况：

阈值规则：只负责超过更换线的情况，阈值设得相对保守，一旦触发就是真问题。

趋势规则：看一段时间内的整体走向，用来发现缓慢上升的老化。

变化率规则：看短时间内的变化幅度，发现突然的异常。

雷冲次数增量：雷冲计数增加时记录事件，计数只认设备上报的累计值，只增不减。

雷后恢复异常：雷击后观察数值是否在合理时间内回落，不回落才告警。

三相不平衡：同一安装点的三相放在一起比，某一相明显偏离时提示。

离线检查：设备超过一定时间没有上报就标记离线，由定时任务负责检查。

这样拆开以后，雷击后的短期升高交给"雷后恢复"处理，长期上升交给"趋势"，阈值只管最后一道线。误报和漏报都少了很多。

调阈值之前，先拿历史数据跑一遍

规则上线后最常见的场景是：客户觉得告警太多或太少，要调阈值。直接在生产上改，改完才知道效果，风险很大。

我们在规则管理里做了三个工具：单样本测试，输入一组数据看会不会触发；历史样本预览，看过去一段时间里有哪些数据会命中；复算 dry-run，用新规则把历史数据重新算一遍，但不真正产生告警。

调阈值变成了先看结果、再决定启用，客户心里有底。

同一个问题只告警一次

一台设备出问题，可能每次上报都满足告警条件。如果每次都推一条短信，几个小时就是几十条。

规则引擎会把同一事件自动合并，持续期间只更新状态不重复通知；满足恢复条件后自动恢复，并记录持续时间。值班人员看到的是"一个问题"，而不是"一堆消息"。这一点和 设备远程监控系统怎么落地 里讲的告警闭环是同一个思路。

告警要送到对的人手里

监测设备通常分布在不同线路、不同单位。告警全部发给一个人没有意义，发给所有人又会互相推。

平台的通知策略可以按范围引用设备归属人、成员或联系人组，同一条告警发给对应的联系人组，每条短信和邮件的发送状态都有记录，失败会自动重试。

还有一个容易忽略的细节：通知链路要和设备接入解耦。告警先进入异步队列，再由通知服务发送。短信供应商偶尔慢或者出故障，不会拖住设备数据入库。

参数下发要等设备回报

调整设备的采样周期、上报参数时，平台下发参数模板后要等设备回报确认，才算完成。只看"下发成功"，可能设备根本没收到。

设备侧用的是 Modbus 寄存器定义，4G 模块把 RTU 字节装进 MQTT 报文上报，平台按寄存器表解析。协议层面的做法可以参考 Modbus App开发方案。

常见问题

只有阈值告警，是不是就够了？

如果监测对象变化快、正常范围明确，阈值可能够用。但像避雷器这种慢性老化、又有事件干扰的设备，只靠阈值很难同时避免误报和漏报。

雷冲计数为什么不能清零？

雷冲次数是判断设备寿命的重要依据，平台只认设备上报的累计值并保留计数审计。提供清零入口容易造成数据被误改，后续无法追溯。

这套规则能用在其他监测设备上吗？

规则引擎、历史复算、告警合并和分组通知是通用能力。电缆、开关柜等监测设备，只要能提供协议和判断标准，都可以按同样方式配置规则。

平台能部署在客户内网吗？

可以。平台用 Docker 部署，EMQX、PostgreSQL、Redis 都能部署在客户环境。如果你正在规划监测平台，可以把设备协议和监测指标 发给我们，先一起梳理告警规则。