我们有一个thrift服务，在日志中发现了很多类似于“THeaderException: Unsupported client type”的错误。他的发生频率很固定，大概每分钟一次，我们不知道发生了什么问题。也不知道是否影响了我们的服务。所以开始了故障排查。

未知客户端连上服务：tcpdump 与 eBPF 定位进瞢,
图片素材来自免费商用图库（pixabay），非本站项目实拍。

我们第一步的设想是这样的。我们先用tcpdump抓包。然后用包里面的时间和服务日志的时间对应，这样就可以知道发送请求的IP地址，然后就可以知道是谁发来的请求了。我们才开始只抓了eth0上，发现没有抓到，于是我们加了loopback，终于抓到了。

下一个问题是，抓到的都是local端口的，而且端口号不固定。我们的猜测是这些请求是由一些临时的进程从随机的端口发送过来的，所以我们也没有办法找到具体是谁发送了这个进程。

下一步，我们写了一个简单的ebpf的脚本，这个脚本可以告诉我们哪个进程创建了tcp链接。于是我们就找到了process的名字，叫StatusCheck（）. 然后我们进行了一番推测，觉得这个应该是容器组用来给服务做健康测试的。于是我们就去问了容器组。

最后的结论是：我们用了一个很老的健康测试的协议（framed）。但是在server端只支持新的协议类型了（header）。所以才会有这样的问题。

一、分层排障模型（从物理层到应用层）

网络故障排查最忌”乱试”。按 OSI 自底向上：物理层（网卡/线缆/光模块/端口灯）→ 数据链路层（VLAN、MAC、STP、协商速率）→ 网络层（IP、网关、路由、ARP）→ 传输层（TCP/UDP 端口、ACL）→ 应用层（DNS、代理、证书）。先确认链路通断（网卡 up、协商速率正常），再 ping 网关，再 traceroute 看断点在第几跳，最后查应用端口与日志。

二、排障工具箱

  • ping / pathping / mtr：看连通性与逐跳丢包延迟。
  • traceroute / tracert：定位故障跳点，区分运营商侧还是内网侧。
  • Wireshark：抓包看 TCP 重传、RST、DNS 超时、ARP 风暴，可复现 NAT 穿透与三次握手异常。
  • 交换机端口：err-disable、CRC 错包、双工不匹配、loop guard 是端口故障高频原因，show interface 看 counters 是第一步。
  • 防火墙：iptables/firewalld/nftables/ufw 规则顺序与默认策略决定放行，改前先备份规则、确认 SSH 不会被锁死。

三、工程经验

交换机端口频繁 err-disable 多因 BPDU guard 或线缆接触不良；无线与有线混排时优先固化上联端口；变更防火墙前在测试环境验证并保留回滚命令。运维类故障的闭环是：复现 → 定位 → 临时恢复 → 根因修复 → 复盘沉淀。

相关阅读

本文为转载作品。版权归原作者所有；本站仅作技术学习与方案参考，如涉侵权请联系我们删除。