4、告警清除与确认：告警清除规则配置、告警确认机制、自动清除与手动清除
告警发出来只是第一步，怎么把它「收回去」才是真正的闭环。我见过不少团队，告警规则配得挺全，但告警永远挂在那里没人管，最后变成了「狼来了」——谁都不看。说白了，告警清除和确认机制，就是给告警系统装上「刹车」和「方向盘」。
这一章，我们聊聊告警的生命周期管理。怎么让告警自动消失？怎么让人工确认？什么时候该手动干预？嗯，这里面的门道不少。
4.1 告警清除规则配置
告警清除，不是简单地把告警删掉。它背后有一套逻辑：条件满足 → 状态变更 → 触发清除。在 ThingsBoard 里，清除规则是通过「清除告警节点」来配置的。
4.1.1 清除条件怎么写
我个人习惯把清除条件分成两类：
- 基于阈值恢复：比如温度从 80°C 降回 50°C 以下
- 基于时间窗口：比如连续 5 个采样点都正常
举个例子，你配置了一个高温告警（>75°C），清除规则可以这样写：
// 清除条件：温度低于 60°C 且持续 3 个周期
var temperature = msg.temperature;
if (temperature < 60) {
return { clearAlarm: true };
}
return { clearAlarm: false };
这里有个坑——清除阈值和告警阈值之间要留死区。我曾经见过一个项目，告警阈值设 75°C，清除阈值也设 75°C，结果设备在 74.8°C 和 75.2°C 之间来回跳，告警刚清除又触发，整个系统都在「抽风」。后来我改成告警 75°C、清除 65°C，世界清净了。
4.1.2 清除规则的优先级
ThingsBoard 的规则链里，清除告警节点和创建告警节点是平级的。但执行顺序有讲究：
- 先判断是否满足清除条件
- 再判断是否满足告警条件
- 如果同时满足，清除优先
为什么会这样？你想想看，如果设备刚恢复又马上超限，系统应该先清除旧的告警，再创建新的。否则告警记录里会残留一条「未清除」的历史记录，查起来很麻烦。
4.2 告警确认机制
告警确认，说白了就是「我看到了，我来处理」。这个机制在运维场景里特别重要。我记得有一次，一个核心设备温度告警响了，值班人员没确认，另一个同事以为没人处理，结果两个人同时去修——反而搞出了故障。
4.2.1 确认的三种方式
| 方式 | 适用场景 | 我的建议 |
|---|---|---|
| 仪表盘手动确认 | 日常运维、值班 | 最常用，点一下按钮就行 |
| API 确认 | 自动化脚本、第三方集成 | 适合批量确认，比如凌晨的告警 |
| 规则链自动确认 | 低优先级告警、已知问题 | 慎用，容易掩盖真实问题 |
API 确认的代码示例：
// 通过 REST API 确认告警
POST /api/alarm/{alarmId}/ack
Content-Type: application/json
{
"ackTs": 1700000000000,
"status": "ACK"
}
4.2.2 确认后的状态流转
告警确认后，状态会从 ACTIVE_UNACK 变成 ACTIVE_ACK。注意，确认不等于清除。确认只是表示有人知道了，告警还在。只有清除操作才会让告警变成 CLEARED 状态。
这个设计很巧妙。你想想看，如果确认就等于清除，那运维人员点一下确认，告警就没了——谁还会去修设备？所以 ThingsBoard 把「确认」和「清除」分开，就是为了保证告警的完整生命周期。
4.3 自动清除与手动清除
清除方式的选择，直接决定了你的运维效率。我见过两种极端：
- 全自动清除：设备一恢复，告警就没了。但问题来了——谁去复盘？
- 全手动清除：设备恢复了，告警还挂着，运维人员得一个个点。累不累？
我的做法是：分场景、分级别。
4.3.1 自动清除的配置
自动清除适合那些「恢复即解决」的场景。比如：
- 网络抖动导致的丢包告警
- 瞬时峰值导致的 CPU 高负载
- 设备重启后的临时故障
配置方式很简单，在规则链的「清除告警」节点里，设置条件即可。我一般会加一个延迟：
// 延迟 30 秒后清除，防止抖动
var cleared = false;
if (msg.temperature < 60) {
cleared = true;
}
return {
clearAlarm: cleared,
delay: 30000 // 30 秒延迟
};
4.3.2 手动清除的场景
有些告警，必须人工确认后才能清除。比如：
- 设备硬件故障（换了备件才能恢复）
- 安全告警（需要排查原因）
- 业务影响类告警（需要业务方确认）
手动清除的操作路径：
- 在仪表盘找到告警列表
- 点击告警行，查看详情
- 确认问题已解决后，点击「清除」按钮
- （可选）填写清除备注
我记得有一次，一个客户坚持所有告警都要手动清除。我问为什么？他说：「自动清除的话，运维人员就不知道设备曾经出过问题。手动清除，至少要点一下，点的时候就会看一眼。」嗯，这个逻辑其实挺有道理的。
4.3.3 混合模式：自动清除 + 人工确认
这是我最推荐的模式。具体做法：
- 设备恢复后，告警自动清除（状态变
CLEARED） - 但清除前，要求有人工确认（状态变
ACTIVE_ACK） - 如果 24 小时内无人确认，自动清除并记录「未确认」
配置思路：
// 规则链逻辑
if (设备恢复正常) {
if (告警已被确认) {
立即清除
} else {
等待人工确认，超时 24 小时后自动清除
}
}
4.4 避坑指南
最后，分享几个我踩过的坑：
- 坑一：清除条件写反了。我曾经把清除条件写成
temperature > 60，结果温度越高越清除——闹了个大笑话。写完后一定要用模拟数据测试。 - 坑二：忘记配置清除通知。告警清除了，但没人知道。我建议在清除时也发一条通知，比如「设备已恢复，告警已清除」。
- 坑三：清除规则和告警规则不在同一条规则链。ThingsBoard 的规则链是独立的，清除规则必须和告警规则在同一个规则链里，否则不生效。
嗯，告警清除与确认，看似简单，其实藏着不少细节。配好了，运维效率翻倍；配不好，告警系统就是个摆设。下一章，我们聊聊告警的升级机制——告警没人处理怎么办？