第2章告警规则引擎原理

第二章：告警规则引擎原理

规则引擎这东西，说白了就是一套「如果…就…」的逻辑处理器。我在储能监控项目里摸爬滚打这么多年，见过太多告警要么漏报、要么误报，根源往往就是规则引擎没设计好。今天咱们就把它拆开看看，到底怎么玩。

先看整体架构。我习惯把规则引擎分成三层：

你想想看，这三层要是耦合在一起，改一条规则就得重启系统，那运维得多痛苦？所以核心思路就是——解耦。

核心架构图：规则引擎三层模型

我在项目中遇到过一种情况：规则引擎和业务代码写在一起，每次改告警阈值都要重新编译部署。后来我们改成了规则文件热加载，才算是解脱了。

规则引擎怎么知道什么时候该干活？靠的就是事件驱动。说白了，就是「有事才动，没事歇着」。

常见的驱动方式有两种：

驱动方式	原理	适用场景
定时轮询	每隔固定时间检查一次数据	变化缓慢的指标（如日均SOC）
事件触发	数据变化超过阈值时立即触发	紧急告警（如电池过温）

我个人建议，核心告警用事件触发，统计分析用定时轮询。混着用效果最好。

经验之谈： 我曾经在某个储能站遇到过，所有告警都用定时轮询，结果电池都冒烟了，告警还在等下一个周期才触发。从那以后，温度、电压这类关键参数我全改成了事件触发。

规则匹配，就是判断「当前数据是否满足某条规则的条件」。这里有几个关键点：

最简单的就是阈值比较。比如：

// 伪代码示例
rule "电池过温告警"
when
  BatteryTemp > 60°C
then
  触发告警级别: 严重
  执行动作: 推送告警 + 启动散热
end

但实际项目里，条件往往更复杂。比如「电压异常」可能是：

嗯，这里要注意：组合条件的执行顺序会影响性能。我习惯把计算量小的条件放前面，先过滤掉大部分数据，再处理复杂条件。

当多条规则同时满足时，谁先触发？这就涉及到优先级了。

优先级设计原则：

我曾经踩过一个坑：把「SOC过低」和「电池过放」两条规则设成了相同优先级。结果有一次SOC已经到5%了，系统还在先处理别的告警，等轮到过放告警时，电池已经受损了。后来我强制要求：同一数据源触发的规则，安全类优先级必须高于性能类。

你有没有遇到过这种情况？一个告警刚触发，数据稍微波动一下又恢复了，然后马上又触发。这就是「告警抖动」。

解决办法是加防抖机制：

// 防抖逻辑示例
rule "电压抖动抑制"
when
  Voltage < 3.0V 持续 5秒  // 持续5秒才触发
then
  触发告警
end

另外还有告警抑制：比如「电池过温」已经触发了严重告警，那「电池温度偏高」这个普通告警就没必要再报了。这叫告警收敛。

注意： 防抖时间不能设太长。我记得有个项目把防抖设成了30秒，结果电池都出问题了，告警硬是延迟了半分钟才报出来。一般来说，紧急告警防抖1-3秒，普通告警5-10秒比较合理。

规则多了以后，匹配效率会下降。我分享几个实战经验：

说白了，规则引擎的设计核心就四个字：快、准、稳、活。快是响应快，准是告警准，稳是系统稳，活是规则活。把这四点拿捏住，告警系统基本就靠谱了。