间歇性故障怎么查
「偶尔断一下」是最耗人的一类故障：故障窗口只有几秒到几分钟，赶到现场时它已经自愈，没有现场就没有结论。方法论只有一条出路——挂着等。在故障期间让多个工具同时自动取证：带时间戳的长 ping、逐跳长跑统计、分卷抓包、应用与内核日志。等下一次复现后把各来源时间对齐，看失败在时间轴上的分布。分布形态本身就是线索：周期性、与负载相关、随机短促，指向的根因完全不同。
基本信息
| 难点 | 故障窗口短、不可控，拿到现场之前无法复现 |
|---|---|
| 对策 | 长时观测 + 自动记录 + 分卷抓包，等到下一次故障发生 |
| 证据组合 | 长 ping（带时间戳）、逐跳统计、分卷抓包、应用与内核日志 |
| 关键动作 | 把故障发生时间与各来源的时间戳对齐后再判读 |
| 判读落点 | 失败的时间分布：随机 / 周期性 / 与负载相关 |
典型使用场景
- 用户报「偶尔掉线」而现场已恢复，需要先架观测等服务方复现
- 监控出现偶发超时告警（一天几次），需要证据区分网络丢包与服务端抖动
- 无线与移动链路质量评估：只有长时间统计才能看出干扰规律
- 多来源交叉：同一时刻的丢包、重传与业务报错是否对得上
- 向线路供应商举证：把失败时刻与统计结果整理成时间线
- 整改后回归观察：调整参数或换线后再挂一段时间，验证问题是否真的消失
挂着等故障
挂着等故障
ping -D -i 0.2 <目标> >> /tmp/longping.log & # -D 输出时间戳，便于与业务日志对齐
mtr -r -c 3000 -i 0.5 -n <目标> >> /tmp/mtr.log & # 逐跳长跑，看哪一跳开始丢
tcpdump -i any -nn -W 20 -C 10 -w /tmp/wait.pcap 'host <目标>' & # 分卷抓包，上限 200MB
ss -tan | grep -c ESTAB # 定期采样连接数做对照
journalctl -f -k | grep -i 'link\|eth' # 同步记录内核链路事件
tail -f /var/log/app/app.log | grep -Ei 'timeout|reset' # 应用侧失败时间点
date -u # 先记录时区基准，避免多源时间错位失败模式与指向
| 失败模式 | 常见指向 | 验证手段 |
|---|---|---|
| 周期性出现（整点或每 5 分钟） | 定时任务、备份占满带宽、路由协议震荡 | 把失败时刻与定时任务、备份窗口对齐 |
| 与流量高峰相关 | 链路拥塞、队列丢包、上联带宽不足 | 把丢包时间与流量曲线叠加比对 |
| 随机且短促 | 物理层误码、光衰、无线干扰、双工不匹配 | 查接口错误计数与重传统计 |
| 仅特定客户端复现 | 客户端网卡、NAT 与 MTU、无线终端、代理差异 | 在同类客户端上交叉复测 |
| 仅特定方向复现 | 单向链路质量差异或非对称路由 | 两端同时长 ping 并比对丢包方向 |
长期挂观测脚本必须配日志轮转与磁盘告警：带时间戳的长 ping 日志一天就能写到几百兆字节，观测工具把磁盘写满会制造出比原故障更严重的次生问题。抓包务必用分卷与上限参数约束，别让单个文件无限增长。
观测期间尽量不改配置：一边改一边观测，等于同时移动靶子和尺子。确需变更时，在观测日志里追加一行带时间的标记，事后才能把故障与改动区分开。
平台差异：Windows 侧可用 ping -t 配合输出重定向长时间记录，用路径探测类工具代替逐跳统计；抓包用系统自带或图形化工具，同样要限制单个文件大小与数量。