3. 数据掉线故障分类与现象映射

在矿山物联网现场，"掉线"往往只是一个笼统的告警词：平台侧看到某台设备离线，运维人员第一反应是"网络不好"，但真正的原因可能埋在物理链路、供电、协议栈或平台服务里。如果只凭经验猜测，排查就会变成反复试错。本节要建立的核心能力是：把"掉线"这一结果，拆解为若干可区分的故障类型，并为每一类绑定一组可观测现象，让现象成为判断故障类型的证据链。

五类掉线故障的本质差异

从数据链路的角度看，一条矿山物联网数据通路可以抽象为：现场传感器/执行器 → 采集网关或DTU → 井下环网/无线链路 → 井上核心网络 → 平台接入服务 → 业务处理与存储。掉线发生在不同环节，其"断"的性质完全不同，因此需要按机理分类，而不是按设备分类。

• 物理链路中断：光纤被采掘设备拉断、网线接头松动、交换机端口损坏、无线基站断电导致覆盖消失。特征是链路层直接断开，数据完全停止，且往往成片出现（同一交换机或同一基站下的设备同时掉线）。
• 网络抖动：链路物理上通，但时延、丢包、乱序剧烈波动，常见于井下无线、电力载波、跨环网链路拥塞。特征是数据"断续到达"，心跳时有时无，重传率上升，但设备并未真正离线。
• 设备掉电：本安电源故障、电池耗尽、供电线路被误断。特征是设备侧无任何响应，且同一供电支路下的设备同时消失；恢复供电后设备通常自动重连。
• 协议超时：链路和供电都正常，但应用层交互失败，如Modbus从站响应超时、MQTT心跳未在keepalive周期内到达、TCP连接被中间设备静默回收。特征是"能ping通但业务不通"，或连接反复建立又断开。
• 平台过载：接入服务线程池耗尽、数据库写入阻塞、消息队列积压，导致平台无法及时处理心跳或数据。特征是大量设备"同时"掉线又"同时"恢复，且平台侧CPU、连接数、队列长度等指标异常。

现象到类型的映射逻辑

分类的价值在于映射。判断故障类型时，不应只看单一指标，而应组合"掉线范围、时间特征、链路层状态、应用层状态、平台侧指标"五个维度。例如：单台设备掉线且能ping通，优先怀疑协议超时或设备自身应用崩溃；同一交换机下多台设备同时掉线且ping不通，优先怀疑物理链路或供电；全网大面积设备周期性掉线而平台CPU飙高，优先怀疑平台过载。

用组合判据替代单点猜测

上图把五类故障、典型现象和排查入口串成一条映射链。实际排障时，建议按"先定范围、再定层次"的顺序操作。第一步看掉线范围：单台、同一接入设备下成片、还是全网大面积。第二步看时间特征：突发一次性、周期性反复、还是持续不恢复。第三步做分层验证：从设备侧ping网关、从网关ping平台、在平台侧看连接状态，逐层缩小断点位置。

举一个教学示例（参数为合理假设，非实测）：某矿10台井下分站通过一台环网交换机接入，平台在14:32同时收到10台设备离线告警。运维先ping该交换机管理地址，不通；查看交换机端口，发现上联光口无光；同交换机下其他业务也中断。由此可判定为物理链路中断，而非平台过载——因为平台侧其他区域设备仍在线，且平台CPU正常。若换一种情形：10台设备离线但交换机端口正常、能ping通网关，平台CPU升至95%、接入线程池满，则优先判定平台过载，需检查消息队列积压与数据库慢查询。

易混淆情形的区分要点

网络抖动与协议超时最容易混淆。二者都会表现为"偶发超时告警"，但抖动是链路层指标恶化（时延、丢包、重传），协议超时则是链路正常而应用层交互失败。区分方法是：在设备与平台之间做分段ping和抓包，若ping时延稳定、丢包为零，但应用层请求无响应，则属于协议超时；若ping本身抖动明显，则先解决链路质量问题。

设备掉电与物理链路中断也需区分。二者都表现为"完全无响应"，但掉电通常只影响同一供电支路，且设备上电后无需人工干预即自动重连；链路中断则影响同一网络端口或基站覆盖范围，恢复后可能因路由收敛出现短暂重连风暴。现场可通过核对供电拓扑与网络拓扑的重叠关系来快速区分。

把分类结果落到处置动作

分类不是终点，而是处置的起点。物理链路中断应优先安排现场巡线、检查光功率与接头；网络抖动应调整无线信道、优化环网拥塞或增加重传策略；设备掉电应核查本安电源容量与电池健康度；协议超时应核对keepalive周期、响应超时阈值与中间设备连接老化时间；平台过载则应扩容接入服务、优化写入批量与队列消费能力。每一类故障对应的处置方向不同，若分类错误，后续动作就会南辕北辙。

建议在平台告警规则中直接嵌入上述判据组合：例如"同一接入设备下离线数≥3且持续>60秒"触发链路类告警，"单设备离线但网关可达"触发协议类告警，"全网离线率>30%且平台CPU>85%"触发平台类告警。这样，告警本身就能携带初步分类信息，缩短从"看到掉线"到"判断类型"的时间。