从告警风暴到精准治理：SagooIoT告警系统的设计演进之路

凌晨三点的电话

做物联网平台这几年，我接过不少凌晨三点的电话。但印象最深的，不是服务器宕机，不是数据库崩溃——而是告警。

对，就是告警。

那天晚上，一个工厂客户的产线突然报了一堆异常。我们的告警系统忠实地把每一条异常都推送给了运维负责人老张：温度偏高、震动异常、电流波动……前后不到三分钟，老张的手机收到了47条告警短信、23通语音电话、以及99+条企业微信消息。

老张彻底不知所措了。

他后来跟我说：“我当时根本分不清哪些是真正的紧急问题，哪些只是波动。结果我花了二十分钟排查，发现核心问题就一个——冷却水泵的继电器接触不良。”

有没有一种感觉扑面而来？这就是典型的"告警风暴"——系统忠实地发出每一条告警，但它们淹没了真正有价值的信息。

后来我们复盘这件事的时候，团队达成了一个共识：一个好的物联网告警系统，不是告得越多越好，而是告得越准越好。 正是这次事件，促使我们在SagooIoT中重新设计了一整套告警治理体系。

今天这篇文章，我就来聊聊这背后的设计思路。

告警不是通知，是决策辅助

很多物联网平台把告警等同于"消息推送"——设备异常 → 发条消息 → 完事。但事实上，告警的本质应该是辅助运维决策。

打个比方：你去医院体检，检验科不会把每项指标的原始数据都塞给你，而是给你一份经过整理的报告——异常项高亮、参考范围对比、医生建议。告警系统也应该做类似的事情。

在SagooIoT中，我们把告警体系拆成了四个层次：

┌──────────────────────────────────────┐
│  第四层：告警治理（抑制/合并/降噪）   │
├──────────────────────────────────────┤
│  第三层：通知分发（多渠道/模板/分级） │
├──────────────────────────────────────┤
│  第二层：告警判定（规则引擎/条件组合）│
├──────────────────────────────────────┤
│  第一层：数据采集（时序数据/设备状态）│
└──────────────────────────────────────┘

每一层都有自己的设计考量。下面我逐层拆解。

第一层：数据采集——你要审什么案子，得先有证据

告警的前提是有数据。SagooIoT在这块的底子还是不错的：深度集成了TDengine时序数据库，支持百万级数据点秒级写入。设备上报的温度、湿度、电流、振动频率等数据，都会先进入TDengine做持久化存储。

但采集不是目的，采集什么、怎么组织才是关键。我们通过物模型来标准化设备数据——每种产品类型定义一套属性模板，设备接入后自动按模板组织数据。这就好比法院审案子，你得先有统一的证据格式，不能一会儿手写一会儿打印一会儿PDF。

举个例子，一个水泵的物模型可能包含：

{
  "properties": [{
    "identifier": "temperature",
    "name": "温度",
    "dataType": "float",
    "unit": "℃",
    "range": { "min": -40, "max": 150 }
  }, {
    "identifier": "vibration",
    "name": "振动",
    "dataType": "float",
    "unit": "mm/s"
  }, {
    "identifier": "current",
    "name": "电流",
    "dataType": "float",
    "unit": "A"
  }]
}

有了统一的物模型，后续的规则判定就有了标准化的数据输入。

第二层：告警判定——让规则引擎干活

有了数据，下一步就是定义"什么情况算异常"。这里我们复用了SagooIoT内置的可视化规则引擎。

规则引擎的玩法之前有篇文章详细聊过（《从if-else到拖拽连线：可视化规则引擎如何重塑物联网业务开发》），核心思路是通过拖拽节点、配置条件来定义数据处理流程。在告警场景下，典型的规则链路大概是这样的：

设备数据输入 → 条件过滤 → 聚合计算 → 阈值比较 → 触发告警

支持的条件类型也很丰富：

• 阈值告警：温度 > 85℃，触发告警
• 变化率告警：温度在1分钟内上升超过10℃/min
• 窗口聚合告警：过去5分钟振动平均值 > 5.0 mm/s
• 状态告警：设备离线超过30秒
• 组合条件告警：温度 > 80℃ 且 电流 > 额定值1.2倍

这里有个设计细节值得说一下：我们支持JavaScript表达式。也就是说，你可以在规则条件里写：

// 自定义告警逻辑：温度突升且伴随振动异常
data.temperature > data.baseline_temperature * 1.3 
  && data.vibration > 6.0
  && data.temperature_trend === 'rising'

这个表达能力开放出来，基本上能覆盖90%以上的工业告警场景。剩下的10%，可以通过插件系统自定义扩展。

第三层：通知分发——别让告警变成骚扰

这一层是最容易做但也最容易被滥用的。很多系统一上来就是短信+电话+App推送+邮件全渠道轰炸，管你紧急不紧急，先发了再说。

我们的设计原则是八个字：分级通知，按需触达。

告警级别

SagooIoT支持自定义告警级别，默认提供了四档：

级别	颜色	通知策略	典型场景
严重	🔴 红色	电话+短信+企微+App推送，全部渠道同时通知	核心设备宕机、安全事件
重要	🟠 橙色	短信+企微+App推送	关键指标超标、产线停工
普通	🟡 黄色	企微+App推送	温湿度偏离、性能下降
提示	🔵 蓝色	仅App推送/站内信	设备即将离线、维护提醒

每个级别可以配置独立的通知模板、通知渠道、以及通知时间窗口。比如"普通"级别的告警，晚上10点到早上7点不推送，避免打扰运维人员休息。

多渠道通知

说到通知渠道，SagooIoT支持的种类算是比较全的：

• 企业微信：支持群机器人、应用消息
• 钉钉：Webhook机器人，支持Markdown格式
• 短信：支持阿里云、腾讯云短信服务
• 语音电话：通过第三方语音服务对接
• WebHook：自定义HTTP回调，可以对接任意第三方系统
• 邮件：支持SMTP，可配置HTML模板
• WebSocket实时推送：前端页面实时弹出告警提醒

每个渠道都可以独立配置通知模板。比如同一条"温度过高"告警，短信模板可能是：

[SagooIoT告警] {设备名称}温度{当前值}℃，超过阈值{阈值}℃，请及时处理。

而企业微信消息可能是：

## 🚨 严重告警
**设备**: {设备名称}  
**指标**: 温度  
**当前值**: {当前值}℃  
**阈值**: {阈值}℃  
**时间**: {告警时间}  
[查看详情]({详情链接})

模板化的好处是，运营人员可以自行调整文案，不需要改代码。

第四层：告警治理——这是核心，也是差异化所在

这一层是整个告警体系的灵魂，也是我们投入精力最多的地方。回到开头老张的故事：47条告警，核心问题就一个。如果系统在发出第一条告警之后，能智能地抑制后续的关联告警，老张就不会被轰炸。

告警抑制

告警抑制的核心逻辑是：如果告警A已经触发，那么由告警A引起的告警B、C、D就不需要再通知了。

举个实际场景：冷却水泵停机 → 触发"设备离线"告警 → 连锁触发"产线温度升高"告警 → 再触发"产品不合格率上升"告警。如果这三条都推送给运维人员，他只会觉得烦躁。

SagooIoT的告警抑制支持配置抑制规则：

• 按设备层级抑制：网关离线 → 自动抑制该网关下所有子设备的告警
• 按依赖关系抑制：A设备故障导致B设备异常 → B的告警被A抑制
• 按时间窗口抑制：同一设备30秒内的同类告警只发一次

告告警合并要解决的问题是"反复震荡"式的告警"式的告警——一条波动反复触发告警，比如温度在85.1℃和84.9℃之间来回震荡，每次过阈值就告一条，五分钟能告几十条。

合并策略很简单：同一设备、同一指标、同一告警级别，在一个时间窗口内合并为一条，通过聚合信息展示：

[SagooIoT告警-合并]
设备: 3号反应釜
指标: 温度
告警级别: 重要
首次触发: 2026-07-28 14:03:21
最近触发: 2026-07-28 14:08:45
触发次数: 23次
当前值: 89.2℃
阈值: 85℃

运维人员收到这一条就够了——他知道温度确实有问题，也知道持续多久了、波动多频繁了。

告警升级

有些告警不能一直停留在低级别。如果一条"普通"告警持续了30分钟还没人处理，它很可能已经演变成了更严重的问题。

告警升级就是解决这个问题的：

普通告警 → 持续30分钟未处理 → 自动升级为"重要" → 通知级别提高
重要告警 → 持续60分钟未处理 → 自动升级为"严重" → 电话通知值班经理

这套机制确保真正重要的问题不会被淹没在一堆"普通"告警里。

告警降噪

告警降噪更多是从统计和模式识别的角度做文章。比如：

• 周期性波动排除：某台空压机每天下午2点温度都会短暂升高（因为阳光直射），这种规律的波动不应该每次都告警
• 计划性维护排除：设备处于维护状态时，自动静默该设备的所有告警
• 批量操作静默：固件升级期间的告警自动忽略

这些规则可以通过系统参数灵活配置，不需要改代码。

实时可视化和统计报表

光有告警治理还不够，你还需要能看到全局。SagooIoT提供了一套完整的告警可视化能力：

• 告警仪表盘：实时展示当前告警数量、各级别告警分布、告警趋势图
• 告警日志：可查询、可筛选、可导出的告警历史记录
• 告警统计报表：按时间、设备、告警类型等维度生成统计分析
• 告警热力图：直观展示哪些设备、哪些时段告警最频繁

这些数据不仅能帮助运维团队快速定位问题，还能为设备维护策略提供数据支撑——比如某台设备最近3个月告警频率明显上升，可能就是你该安排预防性维护的信号。

实际效果

回到文章开头的故事。在我们部署了告警治理体系之后，老张的感受变化很大。以前他每晚睡觉都要把手机音量开到最大，生怕漏掉告警；现在他敢把手机调成震动，因为他知道：重要的告警会自己找到他，不重要的告警不会来烦他。

从数据上看，效果也比较直观：

• 告警消息总量减少了约72%（主要是合并和抑制的效果）
• 告警平均响应时间从8分钟降到了3分钟（因为不会迷失在告警海洋里了）
• 误告警率下降了约60%（周期性波动和计划性维护被有效过滤）

写在最后

告警治理不是一个一蹴而就的事情。每个客户的业务场景不同、设备类型不同、运维习惯不同，需要在实践中不断调优。SagooIoT提供的是一套灵活可配的基础设施，但真正的"治理智慧"，还是需要结合具体场景来沉淀。

如果你也在做物联网平台，或者正在被告警风暴困扰，希望这篇文章能给你一些启发。SagooIoT作为一个开源项目（GitHub: sagoo-cloud/sagoo告警治理相关的能力都是即开即用的开箱即用的。欢迎到项目主页看看一起交流。

---

参考链接：

• SagooIoT 官方文档：https://iotdoc.sagoo.cn
• SagooIoT GitHub：https://github.com/sagoo-cloud/sagooiot
• SagooIoT 前端工程：https://github.com/sagoo-cloud/sagooiot-ui

---

本文为原创文章，如需转载请联系作者。SagooIoT 遵循 GPL-3.0 开源协议，个人学习和使用完全免费。