5个eBPF观测点定位连接超时：从套接字到进程调用链

线上API服务偶尔出现连接超时，应用日志却只有“upstream timeout”，重试、扩容和抓包都难以解释：故障可能发生在DNS解析、套接字创建、TCP握手、内核发送队列或进程阻塞任一层。若在故障机器上临时安装eBPF探针，就能在不修改业务代码的前提下，把套接字、TCP状态与进程调用链按同一时间轴关联，直接缩小异常范围。

如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：zgovps（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。

一、探针如何把连接过程串起来

定位不能只看“连接失败”这一结果。eBPF探针运行在内核事件路径上，可在connect、sendmsg、recvfrom等系统调用进入和退出时记录返回码、文件描述符与进程标识；通过套接字inode和地址四元组找到具体socket，再关联TCP建立、关闭、重传及拥塞等内核事件。由此可区分请求尚未发出、连接未建立、已连接但数据未返回等阶段。

五个关键观测点分别是系统调用返回值、套接字状态、TCP生命周期、进程调用链和统一时间线。进程侧需要补上调用栈：系统调用探针给出内核执行位置，用户态栈采样或运行库插桩可还原线程在DNS解析、TLS握手及日志等待中的调用路径。ServLlama可用于整理探针事件与进程维度数据，但必须统一PID/TID、cgroup、命名空间和时间戳，避免把容器线程误判为宿主机进程。

二、从超时现象反推异常层级

判断时按“系统调用套接字TCP进程”顺序核对。若connect立即返回EADDRNOTAVAIL、EACCES或ENOMEM，问题已落在套接字创建及权限层；若返回EINPROGRESS，随后长期没有建立事件，应检查对端可达性、网络策略和重传情况。若连接已经进入ESTABLISHED，但应用线程一直停在recvfrom或TLS读取，则更可能是响应缺失、接收队列为空或上游处理阻塞。

调用链用于解释线程为何没有继续推进。栈顶停在域名解析时，应检查解析器、搜索域和容器DNS；停在TLS握手时，要区分证书、密钥协商与对端无响应；停在业务函数或日志写入时，连接超时可能只是被慢调用放大的结果。内核事件与用户态时间戳还要使用同一时钟源，否则高并发下容易把相邻请求错误拼接。

实践中常见的坑包括：事件采样遗漏短时错误、栈深度被截断、PID复用、容器命名空间映射错误，以及探针队列拥塞导致事件丢失。应优先采集错误返回、重传和阻塞退出等低频关键事件，并记录丢失计数。完成归因后及时停用高频探针，避免观测工具本身增加系统负载。

从事件到根因：还原连接异常的完整调用链

仅凭一次连接失败无法直接确定责任边界。实际排查时，应将eBPF 探针捕获的时间戳、进程标识、文件描述符和地址族，与内核事件中的套接字状态变化进行关联，再结合用户态调用链判断异常发生在哪个阶段。首先记录连接发起进程、线程和目标地址，随后确认套接字是否成功创建，以及是否进入 connect、重试或异步完成流程。如果在系统调用入口就失败，重点检查参数、地址格式和权限；如果在调用过程中阻塞，则需要结合超时配置、发送队列长度以及目标端响应情况分析。最后，还要验证失败后资源是否正确释放，避免异常被重复上报或被错误归因。

需要特别注意，探针看到的是某个瞬间的上下文，而不一定是导致错误的唯一因素。例如，应用主动取消连接、超时回收和内核返回错误可能发生在不同线程；如果只按进程名聚合，很容易把正常的重试误判为持续故障。因此，异常归因应至少结合调用链、返回值、套接字状态和事件顺序，必要时保留原始参数及上下文，以支持后续复核。

从内核事件到用户态：避免证据链断裂

内核事件适合说明系统层面发生了什么，用户态日志则能解释应用为什么执行了相关操作。二者之间可能存在缓冲刷新延迟、异步回调延迟以及日志丢失等问题，所以不能简单按照日志出现顺序拼接证据。比较稳妥的做法是使用统一时间基准，记录事件发生时间、采集时间和用户态输出时间，并根据线程标识、请求标识或连接标识进行关联。

另一个容易踩的坑，是只依赖事件类型名称，而忽略事件携带的状态字段。套接字状态可能经历创建、连接中、可连接、已连接、关闭中等多个阶段，短暂状态不应直接视为最终结果。排查时应检查状态持续时间、是否存在反复切换，以及事件是否与实际返回值一致。对于高频场景，还需要限制事件量，避免日志洪泛掩盖关键事件。

建立可执行的 eBPF 检查清单

开始前先确认内核版本、BTF 信息、调试符号以及所需探针权限，随后用一个最小连接场景验证采集链路。

1. 用 ss -tanp 或等价工具确认套接字当前状态、进程归属、发送队列、重传计数及本地与远端地址。
2. 检查 /proc/net/tcp、/proc/net/tcp6 和相关网络命名空间中的表项，比较套接字 inode、状态与进程持有的文件描述符是否一致。
3. 核对连接发起进程的线程栈、系统调用返回值和 errno，确认失败发生在 DNS、路由、连接建立、TLS 握手还是应用层超时阶段。
4. 结合 dmesg、网络设备统计、丢包与重传统计、内核事件及防火墙日志，判断是否存在邻居不可达、MTU 问题、连接跟踪异常或链路抖动。
5. 检查探针是否因参数截断、上下文丢失、事件丢失、版本不兼容或权限不足而产生盲区，并对关键连接补充用户态日志和抓包证据。
6. 记录复现时间、进程号、线程号、目标地址、套接字状态变化和完整调用链，先形成可复现样本，再决定是否修改内核、驱动或应用逻辑。

最终输出一份异常归因表，至少包含时间线、证据来源、候选原因、排除依据和结论。明确区分“已观测事实”“合理推断”和“仍待验证项”，对于缺乏用户态日志、存在并发访问或探针覆盖不完整的情况，应保留不确定性，避免仅凭单条内核事件就下结论。