告警规则逻辑（小白版）
设备上报 → 规则匹配 → 条件判断 → 生成告警 → 通知/转发 · 一句话看懂整条链路
把告警想成一条流水线：先听到数据，再判断要不要报，最后告诉人或推给系统
上报
匹配规则
满足
不满足
落库
1
2
3
4
5
设备上报
属性 / 事件
如：电流=12
规则从哪来？
产品模型规则
设备级规则
通用规则引擎
条件判断
阈值 / 公式 / 时间条件
例：电流 > 11
可选：延迟、持续、区间
不告警，结束
生成告警
写入告警记录
通知人员
站内信 / 渠道
转发系统
HTTP / MQTT…
人收到
系统收到
三种配置入口差在哪？（记住这一段就够）
① 产品模型告警
入口：网关模型 / 子设备模型 / 直连模型
配一次 → 绑定该模型的全部设备都生效
触发节点：产品触发（对象锁定）
适合：同型号统一阈值
② 设备实例告警
入口：设备详情 / 网关详情 → 设备告警
只对这一台生效（可与产品规则并存）
触发节点：设备触发（对象锁定）
适合：单台特殊阈值
③ 通用规则引擎
入口：规则引擎 → 规则列表
自选产品/设备，也可纯转发/定时
与①②列表隔离，组件更自由
适合：数据转发、跨对象编排
核对时看哪里？
执行记录：每一步节点成功/跳过（例如通知因「已有活跃告警合并」被跳过）
告警日志 / 告警记录：真正落库的告警；规则来源会标「产品挂载 / 产品规则 / 设备规则」
生效前提：画布保存后还要「发布」；草稿不会按正式规则命中设备上报
先听数据
• 设备上报属性或事件
• 产品触发 / 设备触发接住
• 可指定监听哪些点位
再判断
• 条件判断：阈值或公式
• 可选时间条件消抖/延时
• 不满足则不告警
再产出
• 报警节点写告警记录
• 通知给人，转发给系统
• 可合并活跃告警防刷屏
入口怎么选
• 同型号统一 → 产品模型
• 单台特殊 → 设备告警
• 转发/定时 → 规则引擎