一个老运维的现场手记：让设备“假在线”无处遁形的网关

干工业物联网运维的人，最怕遇到平台上的“假在线”。

后台大屏上，绿色的节点显示设备在线，但数据曲线早就不更新了。打电话给现场，现场说设备正常运转。远程登录网关，系统也确实没死机。重启一下网关，数据恢复正常，但过几天老毛病又犯了。

这就是典型的“假在线”。平台看到的是心跳还在，但采集或转发早就卡死了。今天分享一个真实排查现场“假在线”的案例，聊聊怎么从网关和应用端彻底解决这个问题。

一、问题现象：心跳正常，数据停滞

现场是一个水务泵站的改造项目。网关接入了现场的几台水泵控制器，通过4G网络把数据传到水务云平台。运行了大概一个月，调度中心反馈说，某个泵站的数据偶尔会断更几个小时，但平台显示该设备一直在线。

去现场排查，网关电源灯、网络灯都亮着。用笔记本连上现场网络，远程登录网关，系统没死机，CPU占用也不高。查看采集日志，发现当天上午9点到11点，采集任务全部超时，没有成功读取任何一台水泵的数据。但同一时间段的系统日志，心跳任务却一直是正常的。

二、原因分析：业务任务被阻塞

问题定位到了：网关的“系统心跳”和“业务采集”是两个独立的任务。心跳任务负责告诉平台“我还活着”，它每隔30秒发一个空包。这个任务负载很低，所以一直在正常跑。

但采集任务卡死了。日志显示，当天上午9点，总线上有一台老旧水泵的控制器出现了故障，不再回复数据。网关的采集程序在等待这台设备回复时，超时时间设置得太长（默认是5秒），导致采集任务一直卡在这台设备上。后面的设备排着队，全部被堵住了。

三、解决方案：看门狗与超时优化

针对这个问题，现场做了三处调整：

1. 缩短通信超时时间。 把采集程序的超时时间从5秒改成了1秒。如果设备1秒内不回复，直接跳过，轮询下一台。避免了单台故障设备拖垮整条总线的通信。

2. 引入任务级看门狗。 原来的看门狗只监控系统主程序。现在配置了任务级看门狗，业务采集任务每次成功轮询完一圈，必须去“喂”一次看门狗。如果连续超过3个周期没有喂狗，硬件看门狗会强制重启网关，并在重启后把复位原因上报给平台。

3. 平台端增加数据新鲜度告警。 平台不再只看心跳包。现在配置了数据超时告警，如果某个设备的数据连续10分钟没有更新，即使心跳正常，也判定为“数据滞后”，并推送告警通知。

调整之后，这套网关在现场跑了大半年，再也没有出现过“假在线”的情况。即使那台老旧的水泵再次卡死，网关也能在1秒内跳过它，继续采集其他设备的数据。

“假在线”的本质是心跳和数据走了两条路。要彻底解决，网关侧得有任务级看门狗，保证业务卡死后能自动重启；采集程序得有合理的超时时间，避免被单台设备拖死；平台侧不能只信心跳，必须加上数据新鲜度的判断。

你被平台的“假在线”报警坑过吗？最后查出来是网络问题还是程序死机？评论区聊聊。