1、告警系统概述：ThingsBoard告警机制介绍、告警生命周期、告警与事件的区别
各位同学好，我是老赵。今天咱们来聊聊ThingsBoard里最核心的功能之一——告警系统。
说实话，我在做IoT项目时，最怕的不是设备掉线，而是设备出问题了没人知道。你想想看，一个温湿度传感器坏了，数据一直报正常，等发现时仓库里的货物已经全泡汤了。所以告警系统，说白了就是物联网的「守夜人」。
1.1 ThingsBoard告警机制介绍
ThingsBoard的告警机制，我习惯把它理解成一个「三阶段流水线」：
- 规则引擎触发：设备上报的数据，经过规则引擎的「过滤器」和「处理器」，一旦命中告警条件，就生成一条告警记录。
- 告警实体存储：告警不是凭空消失的，它会被持久化到数据库中。每个告警都关联一个实体（比如设备、资产、租户）。
- 通知分发：告警产生后，可以通过邮件、短信、Webhook等方式通知到人。嗯，这里要注意，通知和告警是两码事，后面会细说。
核心要点：ThingsBoard的告警是基于「实体-属性-阈值」模型的。你给某个设备定义一个告警规则，当它的某个属性（比如温度）超过阈值时，告警就触发了。
我在项目中遇到过最典型的场景：一个冷链物流项目，要求冷柜温度超过8℃就要告警。当时我直接在规则引擎里写了个过滤器，判断温度属性大于8，然后创建告警。看起来简单，但实际跑起来发现——设备偶尔会上报一个瞬时尖峰，导致误报。后来我加了「持续5分钟超过阈值」的条件，才把误报压下去。
1.2 告警生命周期
告警不是一成不变的，它有完整的生命周期。我个人习惯把它分成四个阶段：
| 阶段 | 状态 | 说明 |
|---|---|---|
| 创建 | ACTIVE_UNACK | 告警刚产生，没人处理，也没人确认 |
| 确认 | ACTIVE_ACK | 运维人员看到了，点了个「确认」，但问题还没解决 |
| 清除 | CLEARED_UNACK | 问题恢复了，告警条件不再满足，但还没人确认这个恢复 |
| 完成 | CLEARED_ACK | 问题恢复，且有人确认了，告警正式结束 |
你可能会问：「为什么要有确认和清除两个动作？」
我举个例子你就明白了。有一次半夜两点，系统告警说某个设备离线了。值班人员看到后点了「确认」，表示「我知道了」。但设备实际上是因为网络波动自动恢复了，告警自动「清除」。第二天早上，运维主管一看，告警已经清除了，说明问题已经解决，不需要再跟进。你看，这两个状态把「知道问题」和「解决问题」分开了，非常清晰。
我的建议：在项目初期，很多人只关注告警的创建，忽略了清除逻辑。我曾经吃过这个亏——告警越积越多，最后数据库里几百万条未清除的告警，查询都变慢了。所以一定要设计好告警的清除规则，要么自动清除（条件恢复），要么手动清除（运维操作）。
1.3 告警与事件的区别
这是很多新手容易混淆的地方。我刚开始接触ThingsBoard时，也搞不清楚「告警」和「事件」到底有啥区别。后来在做一个智能楼宇项目时，才彻底想明白。
简单来说：
- 事件：是「发生了什么」。比如「设备上线了」、「温度从25℃变成了26℃」、「用户登录了系统」。事件是客观记录，不带主观判断。
- 告警：是「出了什么问题」。比如「温度超过阈值了」、「设备离线超过10分钟了」。告警是基于事件或数据，经过规则判断后得出的「问题结论」。
用大白话说：事件是「记流水账」，告警是「拉警报」。
避坑指南：我曾经见过一个团队，把所有事件都当成告警来处理。结果系统里每天产生几万条告警，运维人员直接麻木了，真正的严重告警反而被淹没。记住，只有需要人关注和处理的情况，才应该变成告警。普通的状态变化，记录成事件就够了。
在ThingsBoard中，事件通常通过「规则引擎」的日志节点或事件节点来记录，而告警则通过「创建告警」节点来生成。两者的存储位置也不同：事件存在事件表里，告警存在告警表里。
我个人习惯这样设计：
- 设备每次上报数据，都记录一个「数据更新事件」
- 只有当数据超出业务允许范围时，才创建告警
- 告警清除时，再记录一个「告警清除事件」
这样既保留了完整的审计轨迹，又不会让告警泛滥。
小结
好了，这一章我们聊了ThingsBoard告警系统的三个核心概念：告警机制、告警生命周期、告警与事件的区别。说白了，告警就是「发现问题-确认问题-解决问题-确认解决」这样一个闭环。而事件则是这个过程中所有的「脚印」。
下一章，我会带大家手把手配置一个实际的告警规则，从规则引擎到通知分发，走一遍完整的流程。到时候你会看到，这些概念是怎么落地的。