17 规则、告警与去重

难度：中级｜前置：MQ、状态机、时序数据｜目标：从一次阈值判断升级为完整告警生命周期

规则不等于告警

规则判断：

temperature > 80

告警是有生命周期的业务实体：

normal → pending → firing → acknowledged → resolved

同一设备连续上报高温，不应该每条数据都创建新告警。

去抖和持续时间

瞬时噪声可能越过阈值。常见策略：

• 连续 N 次异常；
• 持续 T 秒异常；
• 滑动窗口平均；
• 迟滞区间。

迟滞例子：

超过 80 触发
低于 75 恢复

避免数值在 79.9/80.1 之间反复触发和恢复。

告警去重键

tenant_id + device_id + rule_id + alarm_dimension

已有 firing 告警时更新最后发生时间和计数，而不是创建新记录。

抑制和聚合

一个网关离线可能让下属 500 台设备都离线。需要根因抑制：

• 先生成网关告警；
• 下属设备告警标记为受影响；
• 不发送 500 条独立通知。

类似告警可以按时间窗口聚合。

通知不是告警本身

告警状态保存在业务系统；短信、邮件、企业微信只是通知渠道。通知失败可以重试，不应因此丢失告警事实。

恢复

告警恢复需要明确条件，并记录：

• 首次发生；
• 最后发生；
• 恢复时间；
• 持续时长；
• 确认人；
• 通知历史；
• 关联工单。

自测

1. 为什么高温每条上报都创建告警是错误设计？
2. 迟滞区间解决什么问题？
3. 告警和通知为什么要分开？
4. 网关离线导致大量设备离线时如何抑制？

完成标准

• 能画出告警状态机
• 能设计去重键和迟滞规则
• 能区分告警事实与通知任务
• 能给出一个根因抑制案例

下一单元：OTA 升级状态机