线上网络丢包引起的接口响应时间过慢，快速排查案例

01 问题背景

自建机房，生产环境上某接口耗时超过 2s，接口实现逻辑包含：

• 数据库读写

• 下游 api 调用

• 数据统计

开发本地自测，接口耗时却只有 106ms。

于是开发问运维：“生产环境的网络确定没问题吗？”

运维：“不可能，监控大盘显示网络指标正常，不然为什么就你这个接口慢，其他应用接口都好好的呀？”

02 真的是代码问题吗？

开发再次 review 自己的代码，是否是哪部分代码因为生产环境的不同配置，而影响执行时间呢？

时间一分一秒过去，他也用了 Skywalking 这类工具分析 Trace：但他只能看到接口的执行耗时统计，根本看不出接口在这些时间内做了哪些事情，为什么慢？

开发只好求助 leader，leader 说：“你用 Kindling 程序摄像头查一下这次请求试试，或许能看到更底层原因。”

03 无所谓，Kindling 会出手

Kindling 程序摄像头工具从系统内核级别，以线程事件分析的角度精准的还原程序执行现场，

生产环境这个黑盒子里发生了什么一目了然：

上图是该接口的 Span 分析，我们可以看到接口执行业务的时间只花了 67.11ms，在这之后有 1s 多的异常耗时。

点击 Span，查看该接口的执行线程更详细的事件分析：

可以看到，上图中的标注段，在系统已经开始执行 netwrite(即往客户端写回报文)后，执行线程又执行了很多 lock 事件，这就是 1s 多的异常耗时所在。

既然系统已经开始写回报文，那我们可以推断这部分高耗时就是由于网络传输引起的。

04 根因已定位，这锅开发不背

点击 lock 事件，查看线程锁住时的代码堆栈：

可以看出这是 tomcat 的 nio 阻塞住了，这也再次佐证了是网络传输原因的猜想。

于是，结合查看 tomcat 里负责网络传输的 BlockPoller 线程继续分析：

可以看到，在执行线程 lock 住时，BlockPoller 线程刚好在做 epoll 事件(即线程在查询系统内核文件描述符的读写状态)，通俗点来讲就是，它正在帮执行线程查询系统内核态是否可写，而报文一直传不过去。

于是点击 epoll，查看具体的网络指标：

果然！网络丢包数过大，不断重传，这才是导致接口高耗时的元凶！

05 排查总结

开发拿着这个指标找到运维，运维 ping 这个应用所在的服务器 ip，发现丢包率是 4%。最后检查发现这台机器是新加的，还未完善好网络配置，而 k8s 集群自动调度将其注册运行，导致丢包率过高。

监控大盘上是没有丢包率这个指标的，运维只能看到带宽等指标正常，所以他认为网络正常。

而 Kindling 能捕捉到接口执行时刻的丢包数、重传数等更细粒度的网络指标。

为什么这台机器上别的接口响应正常？

因为该接口需要返回的报文较大，报文越大，传输时间受丢包率的影响接近指数型增长，所以响应时间很慢。

而其他接口因为报文较小，1 个数据包(1.5Kb)以内就可传输完毕，所以命中丢包的几率很小，受到的影响微乎其微。所以运维无法及时感知。

当大家遇到丢包率过高时，可以采取以下可能的解决办法：

1. 检查网络设备的配置：确保设备的配置是正确的，并且没有任何冲突。

2. 更换网络设备：如果现有设备已经不能满足网络需求，可以考虑更换设备。

3. 减少网络中的干扰：其他无线电设备如微波炉、无线路由器等可能会干扰网络信号。

4. 升级网络带宽：如果网络带宽不足，可以考虑升级带宽以提高网络性能。

5. 更换服务提供商：如果当前的网络服务质量不佳，可以考虑更换服务提供商。

06 附录 - Kindling 程序摄像头技术介绍

Kindling 程序摄像头能在分钟级内定位全资源故障根因，比如上文中提到的网络资源类故障，用普通的 Trace 追踪工具只能定位到 Span 级别，很难明确是网络的原因，更无法定位是丢包引起的传输时间异常。

而 Kindling 基于 eBPF 技术融合了 Tracing，logging，metrics，换句话说，它已经把该接口执行时刻的所有数据（比如网络、磁盘、内存等性能指标，mysql、redis 等网络请求的连接信息和报文信息，日志，堆栈，锁信息以及文件 IO 信息等等）都筛选捕捉出来，附着在对应的线程事件上，精准还原程序执行的现场。而以往我们排障时需要依赖的这些数据，都是通过开发和运维协作，借助众多数据库、apm、终端等工具，人工从海量的数据中筛选组织出来的。耗时不说，而且有时候大家都很自信，不相信是自己负责的东西出了问题。

在 Kindling 面前，所有故障的“犯罪证据”一览无余，它是颠覆性的，如果想要了解它的实现原理，可以参考下文链接：

eBPF程序摄像头——力争解决可观测性领域未来最有价值且最有挑战的难题

更多使用 Kindling 程序摄像头快速排障的生产环境案例，请查看：

10分钟黄金期排障案例合集

Kindling 是个开源项目，开源之路道阻且长，希望大家可以给本文点个赞，多多支持，感恩～

有任何问题可以添加小编 wx：Xieyun-kindling

Kindling官网GitHub