APO如何快速判断云环境网络质量是否有问题

基于eBPF获取网络指标存在局限

eBPF可以获取到网络rtt以及srtt等指标，这些指标确实能够反应网络质量，但是其实现是有局限性的，在当前绝大多数客户使用场景是不能反映网络质量的。

eBPF在网络质量监控中的局限性主要体现在以下几个方面：

TCP建连时获取srtt指标：eBPF在BCC中的实现是通过在TCP建连时获取内核维护的srtt（smoothed round-trip time）指标。但是，TCP连接建立完成后，内核并不会持续追踪每个网络包的传输时间。这就意味着在长连接场景中，srtt指标并不能反映当前的网络质量变化。不仅仅是BCC，我们自己开源的Kindling也有同样的局限，同时我们也对比了datadog等eBPF探针实现，发现都有这个问题。
长连接场景中的不足：现代微服务架构中普遍使用长连接来减少连接建立和拆除的开销。然而，在这种场景下，内核并不会持续更新srtt指标，从而无法反映长连接期间的网络质量变化。
实验验证：通过在Tomcat配置数据库连接池连接MySQL，然后在两者之间注入网络延时故障的实验。在连接建立后，如果在任意一端注入延迟，BCC的srtt指标将不会变化，因为内核不会追踪这些后续包的传输时间。

文章《孙英男-B站大规模计算负载云原生化实践》是B站建立容器云过程的分享，他们在判断网络质量抖动的时候使用的ping来判断网络是否抖动。

使用ping来判断网络质量是大家常用的一个习惯，而对于ping的延时大家在实践中已经形成了一些认知，比如如果ping的延时超过100ms，那么在线网络游戏估计玩不成了。

误导性结果：有时网络中的 ICMP 数据包优先级较低，可能导致延迟或丢包率看起来比实际情况更严重。
ICMP流量限制：某些网络设备（如防火墙）可能会限制 ICMP 流量，导致 ping 测试结果不准确，甚至ping不通
大规模集群的限制：高频 ping 造成的网络负载：在大规模集群环境中，对大量节点进行频繁 ping 操作，会产生大量 ICMP 流量，从而增加网络负载，影响正常业务流量。虽然一次ping的资源开销很小，但是集群规模大了之后，每个容器两两之间都进行ping，这种消耗将是非常大的，大量的 ping 操作会消耗系统的 CPU 和内存资源，尤其是在需要同时监控许多节点的情况下。

虽然eBPF和ping包的方式都有一定局限性，但是eBPF的局限性受限于内核的实现，该局限没有办法突破的，而ping包的局限是可以突破的。

误导性结果的突破：用户认知的突破，如果发现ping延时很严重了，那真实的网络流量更加严重，这点突破很容易。
ICMP流量限制：防火墙的配置即可允许ping包的发生。
大规模集群的限制：大规模集群中，如果两两相互都需要ping这是非常耗资源的做法，但是我们注意到实际场景中容器通过网络与其他容器交互的范围是有限制的，并不会和所有的容器都进行交互，这点是有优化空间的。

开源项目coroot有一个非常好的思路，他们使用了一个叫做pinger的组件，该组件工作原理如下：

但是coroot的eBPF实现要求内核版本高于4.14，国内还有很多操作系统停留在centos7系列的用户，他们是没有办法用coroot的实现。

我们在coroot的基础之上，针对国内的环境做了优化，主要优化如下：

最终效果图，展示srcip到dstip的ping值

题外话：我们不去修改coroot ebpf代码使其适配低版本内核主要是基于投入产出比，适配低版本内核需要调整代码量较大，我们通过eBPF采集的北极星因果指标是适配了低版本内核的。