APO 如何快速判断云环境网络质量是否有问题
· 阅读需 8 分钟
基于 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 指标将不会变化,因为内核不会追踪这些后续包的传输时间。