最难查的一类故障
间歇性故障指通信时好时坏、能自行恢复、不在固定条件下必现。它比彻底断线难查：故障窗口短，证据容易被覆盖，而且手上试探时偏偏是好的，容易把排查人引向错误方向。定位思路归结为两件事：把随机现象变成可长期记录的数据，以及找出“好”与“坏”两种状态之间的差异条件——温度、振动、负荷、时段、是否有设备同时动作。
基本信息
| 典型表现 | 周期性掉站后自愈、数据点偶发变灰、报警反复弹出又消失 |
|---|---|
| 难点 | 故障窗口短、现场没有记录、发生时人不在场 |
| 关键手段 | 长期日志与循环抓包、状态量记录、触发式采集 |
| 优先排除 | 接头接触不良、供电与接地异常、随负荷出现的干扰源 |
典型使用场景
- 白天正常夜班偶发中断，怀疑与负荷或环境变化相关时
- 设备振动或温度升高后才出问题，怀疑接触不良或元件老化时
- 新增某台设备后开始偶发，怀疑带宽或广播流量上升时
- 日志只留下一行“通信中断”，需要判断是设备侧还是网络侧时
- 把“偶发”升级为可管理指标，做趋势观察而非被动救火时
复现条件矩阵
| 观察维度 | 记录什么 | 判读价值 |
|---|---|---|
| 时间维度 | 故障时刻、持续时长与发生间隔 | 等间隔指向定时任务叠加，无规律指向干扰或接触 |
| 状态维度 | 当时设备启停、负荷、是否有人作业 | 建立故障与外部动作的先后关系 |
| 物理维度 | 温度、振动、湿度与接地状况 | 判断是否属于机械或环境诱因 |
| 拓扑维度 | 相关设备是否共用同一交换机或同一电源 | 把范围收缩到共同节点上 |
长期记录与触发采集
长期记录与触发采集
# 后台长期记录链路状态，故障后回看时间点
while true; do printf '%s %s\n' "$(date '+%F %T')" "$(ping -c 1 -W 1 192.168.1.10 >/dev/null 2>&1 && echo up || echo down)" >> /var/log/link_monitor.log; sleep 5; done &
# 循环抓包并按时间滚动，避免长期抓包写满磁盘
tcpdump -i eth0 -nn -G 300 -W 48 -w /tmp/cap_%Y%m%d_%H%M%S.pcap 'host 192.168.1.10'
# 定时采样端口错误计数，便于与故障时刻对齐
for i in $(seq 1 60); do date '+%T'; ethtool -S eth0 | grep -iE 'err|drop|discard'; sleep 60; done | tee /tmp/port_counter.log对付间歇性故障最有效的办法通常不是守在设备旁等，而是先部署长期记录再等它复现。没有历史数据时，任何结论都只是猜测，也无法证明问题已被解决。
时间同步是前提：控制器、交换机与采集主机时钟不一致，日志时间戳就对齐不了，偶发故障永远拼不出时间线。先确保各设备时间同源，再谈相关性分析。
怀疑接触不良时不要为了验证而反复插拔：插拔本身可能让接触恢复，故障随之消失，现场证据被破坏，只能再等下一次复现。先拍照与记录状态，再在计划窗口内处理。