1. 告警规则概述：ThingsBoard 告警规则的作用、核心概念与规则链关系
在 ThingsBoard 物联网平台中，告警规则是连接设备数据与运维响应的核心枢纽。它允许平台根据设备上报的遥测数据、属性变化或生命周期事件，自动判断是否触发告警，并将告警信息路由到后续的规则链节点进行处理与推送。本章将系统梳理告警规则的作用、核心概念以及它与规则链之间的协作关系。
1.1 告警规则的作用
告警规则的主要作用可以归纳为以下四点：
- 实时异常检测：基于设备遥测数据（如温度、电压、振动频率）或属性值，在数据流入平台时即时判断是否超出预设阈值或符合特定条件。
- 状态分级管理：将设备异常按严重程度划分为不同级别（如警告、次要、严重、致命），便于运维人员按优先级处理。
- 自动化响应：触发告警后，可自动执行规则链中的后续动作，如发送邮件、调用 REST API、更新设备属性或创建工单。
- 历史追溯与审计：所有告警事件均被持久化存储，支持按时间、设备、类型、状态等维度进行查询与分析，满足合规与故障复盘需求。
💡 核心价值：告警规则将被动的人工巡检转变为主动的自动化监控，是 ThingsBoard 实现“设备-数据-决策”闭环的关键组件。
1.2 核心概念详解
理解告警规则需要掌握三个基础概念：告警类型、严重级别和状态。下表对三者进行了对比说明：
| 概念 | 定义 | 典型值 | 作用 |
|---|---|---|---|
| 告警类型 | 告警的分类标识，用于区分不同性质的异常 | HighTemperature、LowBattery、ConnectionLost |
便于按类型进行过滤、聚合与差异化处理 |
| 严重级别 | 告警的紧急程度，从低到高排列 | WARNING、MINOR、MAJOR、CRITICAL、FATAL |
决定告警的响应优先级与通知策略 |
| 状态 | 告警当前的生命周期阶段 | ACTIVE、CLEARED、ACKNOWLEDGED |
跟踪告警是否已被确认或解除，避免重复推送 |
1.2.1 告警类型
告警类型是一个字符串标识，由用户在规则节点中自定义。它通常与设备的具体异常场景一一对应。例如，对于温度传感器，可以定义 HighTemperature 和 LowTemperature 两种类型。在规则链中，可以通过告警类型字段进行条件分支，实现不同异常走不同处理逻辑。
1.2.2 严重级别
ThingsBoard 预定义了五个严重级别，从低到高依次为：
- WARNING（警告）：表示潜在风险，如温度接近阈值但未超标。
- MINOR（次要）：表示轻微异常，如短暂的数据抖动。
- MAJOR（严重）：表示明显故障，如设备离线超过 10 分钟。
- CRITICAL（危急）：表示关键功能失效，如核心传感器无数据。
- FATAL（致命）：表示系统级灾难，如设备硬件损坏。
用户可以在规则节点中动态设置严重级别，也可以根据遥测值的偏离程度自动计算。
1.2.3 状态
告警状态用于管理告警的生命周期，主要包括三种：
- ACTIVE（活跃）：告警刚被触发，尚未被处理。
- ACKNOWLEDGED（已确认）：运维人员已查看并确认告警，但异常可能仍未恢复。
- CLEARED（已清除）：异常条件已消失，告警自动或手动解除。
状态转换是告警管理的基础。例如，当设备温度恢复正常时，规则链中的“清除告警”节点会将对应告警从 ACTIVE 转为 CLEARED。
📌 实践建议：在配置告警规则时，建议为每种告警类型设置明确的清除条件，避免告警长期堆积在活跃列表中。
1.3 规则链与告警的关系
规则链是 ThingsBoard 中处理消息与事件的管道，而告警规则是规则链中一类特殊的处理节点。两者之间的关系可以用下图概括：
上图展示了数据在规则链中的典型流转路径：
- 设备数据流入：遥测、属性或事件消息进入 ThingsBoard 消息总线。
- 规则链入口：消息根据设备配置的根规则链或链路规则进入对应的处理管道。
- 告警规则节点：在规则链中，告警节点根据预设条件判断是否创建、更新或清除告警。
- 后续动作节点：告警产生后，可连接推送节点（如邮件、Slack）、转换节点或存储节点。
- 告警数据库：所有告警记录最终持久化到 Cassandra 或 PostgreSQL 中，供查询与展示。
1.4 告警规则在规则链中的位置
告警规则节点通常位于规则链的中游，在数据过滤与转换之后、外部推送之前。一个典型的规则链片段如下：
// 规则链节点顺序示例
1. 消息类型切换节点（仅处理遥测消息）
2. 脚本过滤节点（判断温度 > 50）
3. 创建告警节点（类型: HighTemperature, 级别: MAJOR）
4. 推送节点（发送邮件通知）
5. 保存到数据库节点
⚠️ 常见误区：不要将告警规则节点放在规则链的最前端。建议先通过过滤器或脚本节点进行数据清洗与条件判断，再触发告警，避免因无效数据产生大量误报。