设备运维系统的告警模块有个特点：上线之后永远在改。
夏天来了，温度阈值要调；客户换了工艺，某个测点的高峰时段要豁免；出了一次事故，客户要求"温度连续超 10 分钟才算告警，瞬时超不算"……第一版我们把规则写死在代码里，半年改了 17 次，每次都要发版。第 18 次需求来的时候，我们决定重做这块——本文就是那次重做的完整复盘。
先回答选型问题：为什么不用 Drools？ Drools 当然强大，但对我们的场景它有三宗"罪"：学习曲线陡（DRL 语法要培训）、规则文件由开发维护（客户想要的恰恰是"自己能改"）、依赖重（私有化环境的客户机器跑不动太重的栈）。而设备告警规则的形态高度收敛——无非是"什么指标、超过什么阈值、持续多久、通知谁、多久静默"——这种收敛场景，自研一个轻量引擎是划算的。
设计 DSL 之前，先跟运营/设备人员聊清楚他们脑子里的"一条告警规则"长什么样。最终抽象出五个要素：
# 告警规则 DSL 示例：排气温度过高告警
rule_id: ALARM_EXHAUST_TEMP_HIGH
tenant: t1002
target:
device_type: COMPRESSOR # 适用的设备型号
metric: exhaust_temp # 监测的测点
condition:
operator: ">" # GT / LT / GTE / LTE / BETWEEN
threshold: 85
unit: "℃"
duration: 10m # 持续超过 10 分钟才触发（防瞬时毛刺）
level: WARN # INFO / WARN / CRITICAL
silence: 2h # 触发后 2 小时内不重复告警（静默期）
action:
- notify: [DEVICE_SUPERVISOR] # 通知对象（角色）
- create_order: # 自动创建维修工单
template: FAULT_TEMP_HIGH
priority: HIGH
escalate: # 升级链
- after: 30m
to: [EQUIPMENT_MANAGER]
这份 DSL 设计里最重要的两个字段是 duration 和 silence，它们直接决定了告警系统的口碑：
持续时间的判断需要一个滑动窗口："条件是否连续成立 10 分钟"。全量重算太浪费，我们用增量状态机的方式：每个"设备 × 测点 × 规则"维护一个轻量的窗口状态。
public class RuleWindow {
private long conditionStart = -1; // 条件首次成立的时间戳
/**
* 每来一条数据调用一次。返回 true 表示满足"持续 duration"可触发。
*/
public boolean feed(DataPoint point, RuleRule rule, long now) {
boolean hit = rule.getCondition().matches(point.getValue());
if (!hit) {
conditionStart = -1; // 条件中断，窗口清零
return false;
}
if (conditionStart < 0) {
conditionStart = now; // 条件首次成立
}
return now - conditionStart >= rule.getDurationMs();
}
}
整体数据流：
MQTT 数据 → 归一化 → 按(设备,测点)路由到匹配的规则集 → 逐条 feed 窗口
→ 满足持续条件 → 查静默期 → 发布告警事件 → 通知/建单/升级
三个工程要点：
(device_type, metric) → List<Rule> 的路由表，每次数据只评估命中的三五条规则。规则存数据库，带版本号，服务端通过两种方式感知变更：
@Scheduled(fixedDelay = 30_000)
public void reloadRules() {
long latest = ruleMapper.getMaxVersion();
if (latest > loadedVersion) {
List<AlarmRule> fresh = ruleMapper.selectByVersionAfter(loadedVersion);
Map<String, List<AlarmRule>> newRoutes = buildRouteTable(fresh);
// 原子替换路由表；受影响的窗口状态清空重建
routeTable = newRoutes;
rebuildWindows(fresh);
loadedVersion = latest;
}
}
规则编辑界面给运营/设备主管用，表单化的条件配置，保存后 30 秒内全网生效。上线后我们统计了一下：告警相关的发版次数从月均 2~3 次降到接近零，所有调整都在界面完成，且每次变更留有操作日志，改坏了可以一键回滚到历史版本。
规则引擎解决"怎么触发"，风暴治理解决"别把人淹死"。我们踩过一次事故：某车间网络闪断 5 分钟，恢复后 300 台设备的断网补传数据瞬间涌入，加上恢复触发的状态变化，10 分钟内产生了 2000 多条告警，推送通道直接被打爆。之后的防线分三层：
第一层：源头收敛。同一设备同一规则处于静默期内不重复触发；设备离线告警在设备恢复后自动关闭，不残留。
第二层：空间合并。同一车间 10 台设备同时离线，大概率是车间交换机断了——按"设备组"聚合，合并成一条"3 号车间 10 台设备离线"的组告警，而不是 10 条独立告警。合并规则本身也是可配置的（按组织、按网关、按物理位置）。
第三层：通道限流与摘要。推送通道设置每用户每分钟上限，超出的部分折叠成一条摘要："过去 10 分钟还有 23 条告警，点击查看全部"。
数据洪峰 → 源头静默 → 组合并 → 通道限流摘要
这套防线做完备之后，再也没有出现过"告警把客户惹毛"的投诉——告警系统的成败，一半在触发准不准，一半在打扰少不少。
坑一：规则交叉冲突没检测。两条规则"A 温度 > 85 告警""A 温度 BETWEEN 60~90 正常"同时存在且都启用，行为变成玄学。后来在规则保存时做冲突检测：同设备同测点的区间规则要求互斥，检测不过不让保存。
坑二：阈值边界。">85" 到底含不含 85？不同运营人员理解不同。我们在 DSL 里强制用 GT/GTE 显式操作符，界面上也用文字写明"高于 85（不含 85）"，消灭口头歧义。
坑三：规则导出没有环境隔离。测试环境调好的规则被误同步到生产，阈值是测试时临时放宽的 150℃。之后规则同步只能走"导出包 + 目标环境确认"流程，且导入时强制展示所有改动差异。
自研规则引擎听起来像"重复造轮子"，但当你的规则形态收敛、需要业务人员自助维护、还要跑在客户的低配私有化环境里时，一个几百行的轻量引擎往往比引入 Drools 更快更稳。判断标准就一条：你的规则 DSL 五年之内会不会长成另一个通用编程语言——如果不会，就大胆收敛、大胆自研。
至此，从采集（03）、评分（04）到告警（05），"数据侧"的链路讲完了。下一篇回到一线作业场景：巡检模块的扫码打卡、离线缓存与防作弊设计——那是收集真实数据的第一道关卡。
系列目录（持续更新）
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。