物联网平台监控告警体系怎么搭建

整体思路：分层采集 → 统一接入 → 规则引擎 → 告警分发 → 处置闭环 → 统计复盘，覆盖设备侧、网关侧、平台侧、业务侧四层监控，区分物联网特有告警(设备离线、测点超限)和IT运维告警(服务器、数据库)。

一、明确监控对象与告警分类(先定范围)

1)设备层(IoT终端)

- 状态类：设备上下线、心跳中断、信号强度(4G/LoRa/WiFi)、供电断电、电池低电压

- 测点业务类：温度、压力、液位、电流、开关量超限;传感器故障、数值跳变、数据卡死、数值越界

- 设备故障类：模块异常、固件升级失败、硬件报错

2)网关/边缘层

- 网关在线状态、网关CPU/内存/磁盘、边缘采集进程、串口/485总线故障、上行链路断连、本地缓存溢出

3)IoT平台层(云/私有化平台 ThingsBoard、EMQX、OneNET、聚英云等)

- 消息队列：消息堆积、消息丢失、吞吐下降

- 接入服务：连接数超限、MQTT连接失败、鉴权报错

- 数据库：时序库/关系库读写延迟、磁盘满、连接数耗尽

- 平台服务：API接口超时、服务宕机、网关接入端口异常

4)业务应用层

- 业务报表计算失败、数据推送中断、Web页面访问超时、权限异常

> 告警等级划分(通用4级，可按需简化)

> - P0 紧急：大面积设备离线、平台崩溃、现场高危(如超温起火风险)→ 电话+短信+微信，7×24响应

> - P1 重要：单站点断电、关键测点超限、网关离线 → 短信+企业微信，工作时间快速响应

> - P2 一般：单台设备离线、电池低电 → 站内消息、工单，定时处理

> - P3 提示：轻微波动、固件版本提醒 → 日志记录，不主动推送

二、数据采集层：多源指标采集方案

1. 设备测点采集

- 方式：MQTT/Modbus-RTU/TCP/485、CAN、HTTP上报;网关边缘预采集

- 采集优化：心跳机制(设备定时上报心跳包，平台判断离线;建议10~60s心跳，设置离线超时阈值，避免网络抖动误告警)

- 边缘预处理：网关本地做滤波、防抖，抑制瞬时尖峰，减少无效告警上云

2. 平台&服务器指标采集

- 主机指标：Prometheus + node-exporter(CPU、内存、磁盘、网络)

- 中间件：EMQX、Redis、InfluxDB/TimescaleDB、MQ队列 exporter

- 日志采集：Loki / ELK，采集平台日志、设备上行日志，用于异常检索

3. 采集策略要点

1. 高频指标(实时测点)：1~10s;资源指标：30s~1min

2. 采集降级：网络差时边缘缓存，恢复后补传，不丢失告警原始数据

3. 数据质量指标单独监控：空值率、跳变率、上报延迟，识别传感器失效

三、告警规则引擎设计(核心，防误报、风暴)

> 常见坑：单设备网络闪断，一秒几十条告警，造成告警风暴。必须做防抖、抑制、聚合。

1. 规则类型

1. 阈值告警：固定阈值(温度>80℃);动态阈值(基于历史基线，突增突降)

2. 状态告警：心跳超时判定离线、状态变更(开关由正常变故障)

3. 趋势告警：连续5个周期持续上升，不是单次超限就告警

4. 缺失告警：测点长时间不上报数据(数据卡死)

5. 关联告警：同一站点总断电 → 抑制该站点所有子设备离线告警(根因抑制)

2. 告警降噪三板斧

1. 防抖(持续时间)：条件持续满足N个周期才触发。例：温度超限持续30s才告警，瞬时波动忽略

2. 告警抑制：父告警触发时，屏蔽同站点从属告警。例：网关断连 → 网关下所有设备离线告警抑制，只报网关离线

3. 告警聚合：短时间内同类型告警合并为一条(如5分钟内同一区域10台设备离线合并成批量告警)

3. 规则部署位置选择

- 低时延、现场安全类告警：边缘网关本地规则，断网也能本地声光报警;

- 跨设备、大数据基线、业务统计告警：云端IoT平台规则引擎。

四、告警通道分发(多渠道，按等级路由)

支持通道按需对接：

1. 站内：平台告警中心，告警历史、快照(触发时刻测点值)

2. IM：企业微信/钉钉机器人，附带设备名称、位置、测点、时间、地图链接

3. 短信、电话语音：P0/P1高危告警

4. 工单系统：自动创建工单，派单运维人员

5. Webhook：推送至第三方运维平台(如Prometheus Alertmanager)

路由策略示例：

- P0：电话 + 短信 + 企业微信@所有人

- P1：短信 + 企业微信

- P2：仅企业微信，自动生成工单

- P3：仅存入告警日志

五、告警闭环管理(从告警→处置→归档)

完整闭环链路：

`告警触发 → 告警推送 → 认领确认 → 现场处置 → 恢复上报 → 自动校验恢复 → 归档复盘`

1. 自动恢复：指标恢复正常后，自动生成【告警恢复通知】，区分“告警”和“恢复”消息

2. 工单绑定：告警自动生成工单，记录处置人、处置时间、原因、解决方案

3. 告警屏蔽：支持按设备、时间段临时屏蔽(检修期间，避免检修产生大量无效告警)，屏蔽留日志审计

4. 权限控制：不同区域运维人员只能接收自己管辖设备告警

六、存储、可视化与大盘

1. 时序数据库：存储测点历史;告警事件库单独存储(告警时间、设备ID、告警内容、等级、处置状态，保存至少半年)

2. 监控大屏：

- 总览：告警总数、未处理告警、P0/P1数量、在线设备统计

- 告警列表：支持按设备、区域、告警类型、时间筛选，可导出

- 地图视图：设备点位，红点标记告警设备

3. 报表：日/周告警统计，告警TOP设备、告警原因统计，用于优化规则(找出频繁误报测点)

七、运维与迭代优化

1. 告警指标大盘：统计误报率、漏报率、平均响应时间、平均恢复时间MTTR

2. 定期调优：高频误报的规则修改防抖时长、阈值;优化抑制规则

3. 演练：定期P0告警演练，验证电话/短信通道是否可用，人员响应是否到位

4. 权限&审计：所有告警配置修改、屏蔽操作留日志

八、选型参考(两套架构：私有化 / 云IoT)

方案A：轻量化私有化(中小项目)

设备/网关上报 → EMQX消息接入 → ThingsBoard/自研IoT平台做规则告警 + Prometheus监控平台服务 + Alertmanager分发告警，Loki存日志。适合工厂、智慧水务、畜牧大棚。

方案B：云平台方案

设备接入公有IoT云(OneNET/阿里云IoT)，平台自带告警规则，对接钉钉/短信;服务器侧用云监控。快速落地，运维成本低。

九、落地实施步骤(分阶段上线)

阶段1：梳理资产清单，整理测点、设备层级关系(站点-网关-设备-测点)，定义告警等级

阶段2：部署采集链路，基础指标采集上线，先做设备离线、断电等核心告警

阶段3：开发告警规则，配置防抖、抑制、聚合，先试运行，不打开短信电话，观察误报

阶段4：优化降噪，确认误报可控后，开通短信、电话等高优先级通道

阶段5：上线工单闭环、告警大盘，持续迭代规则

十、常见坑总结

1. 只看设备测点，忽略网关/平台本身监控，平台挂了收不到告警

2. 无告警抑制，网关断联触发几百条设备离线，告警风暴

3. 无防抖，网络抖动、传感器噪声导致大量误报，运维麻木，真告警被忽略

4. 告警不带上下文：只报温度超限，没有设备位置、测点原始值，运维无法判断

5. 缺少恢复通知，不知道故障是否自动恢复