eBPF 技术如何提升故障排查效率实战

6 月 22 日，由开源中国主办，华为、上海浦东软件园联合主办的【云技术专场】OSC源创会 · 上海站 · 104期线下沙龙成功举办。来自云杉网络的 DeepFlow 高级产品经理李倩发表了《DeepFlow 实战：eBPF 技术如何提升故障排查效率》主题演讲，展示通过零侵扰数据采集、应用性能指标监控、分布式追踪和持续性能剖析等技术实现零侵扰的高效故障排查。

以下为李倩的演讲回顾，内容由活动现场参会嘉宾@阿维同学贡献。

整理：阿维同学（ WeChat：AWTX550W）

---

随着云原生应用的发展，IT 系统的复杂度呈指数级增加。连接微服务的基础设施越发复杂，路径数量随之增长，导致系统的可观测性变得至关重要。

现有的监控组件也遇到一系列瓶颈

为了应对上述挑战，全栈可观测性成为必备能力。它提供了从应用代码、系统进程、网络存储到基础设施的全面监控和分析能力。通过全栈可观测性，运维和开发人员能够实时了解系统的运行状态，快速定位和解决问题，确保系统的稳定性和高效运行。

其中深入剖析了微服务架构中应用程序性能监控（APM）所面临的两大核心挑战—— 插桩困难和定界困难。

DeepFlow 对外提供三大核心产品能力，任意服务的全景拓扑、任意调用的分布式追踪、任意函数的性能剖析。DeepFlow 可以做对业务零侵扰，基于的核心技术能力是基于 eBPF/Wasm 采集数据。同时，DeepFlow 对于整个数据生态都非常包容，即可接入各种组件产生的追踪、指标及日志的数据也支持将数据吐出到各种平台，例如作为 Grafana 数据源、Prometheus 数据源等等。

DeepFlow技术框架以其全栈（Full Stack）和零侵扰（Zero Code）的特性，展示了其技术制高点。DeepFlow 通过采集从操作系统、容器平台、虚拟化平台、各种中间的数据来做到全栈，其中即可利用 eBPF 在操作系统进程层面采集应用及网络数据，也可利用 cBPF 在网卡层面捕获应用请求的网络数据，从而做到对应用零侵扰。

零侵扰的服务全景图，可观测包含任意自研服务、第三方服务（图中 APIGW/consul 等）及基础设施服务（图中 DNS/Redis 等）。对于任意服务与服务的访问路径，都可进程、POD、虚拟机、宿主机到网关粒度追踪全栈路径。

DeepFlow 利用基于 eBPF 的零侵扰方式获取分布式调用链，相较 APM 插码形式来说追踪更全栈更自动，可以追踪任意请求经过的 SLB、API 网关、服务网格、业务服务、基础设施服务、网络节点等 Span。

DeepFlow 利用 eBPF 技术以低于 1% 的开销零侵扰采集生产环境进程的性能剖析数据，绘制函数粒度的 On-CPU、Off-CPU、Memory 火焰图，快速定位应用函数、库函数、内核函数的全栈性能瓶颈。

访问某个业务时，直接返回了 404 错误。直接在调用日志中过滤请求的前端服务的 404 异常，就轻松的找到了报错的 URL 的 404 是 x.x.200.19 IP 返回的。此 IP 并不能通过前端访问到。因此怀疑是不是域名解析出了问题，又查看了 DNS 解析日志，域名解析没有问题。对比以往的办法和 DeepFlow 引入后的表现，我们发现要快速准确地定位出错的服务，仅仅依靠传统的日志查询和抓包方式是不够的，是需要通过业务零侵扰的方式补齐平台级别的应用性能监控能力。

监控中心偶现访问异常（ 503 Service Unavailable），运维团队并未主动挂过 503。业务服务调用关系复杂，分析日志多日也并未找到具体的原因，测试环境也一直未复现，问题悬住。最后利用 DeepFlow，分钟级定位到了问题服务，通过 HTTP 调用日志过滤监控中心的 503 异常，快速得到存在异常的调用，对异常调用发起追踪，快速锁定路径上存在异常的服务。最终定位到根因整个运营运维业务一直在快速迭代发布，还未来得及分析整个链路的瓶颈点，因此生产部署的微服务 Pod 的副本数都一样，通过早上高峰的数据，结合 eBPF 的 RED 指标和调用链追踪功能，快速的找到了整个运营运维业务的服务瓶颈点（因调用处理不过来，会导致偶现的返回 503 异常）。

此案例是通过 DeepFlow 的 RED 指标能主动暴露服务异常，发现隐藏 Bug，变被动查找问题为主动修复问题。发现 -cr-服务 Redis 协议统计到大量的服务端错误，通过 DeepFlow 调用日志可看到详细的响应异常信息-WRONGPASS invalid username-password pair or user is disabled.。从异常信息可知是因为 Redis 的密码修改了，但是业务代码中的密码没有修改导致业务服务无法与 Redis 通信。因为 Redis 存放的是配置信息，而这些配置信息还在配置中心也存了一份，业务服务每次启动都会先去和配置中心做配置同步，后续才会持续与 Redis 同步配置信息。一系列连锁反应，导致最终掩盖了问题的根源。

以往，基础设施 CPU 指标的异常通常会到此无疾而终，时不时会有同学尝试去分析升级阶段的应用日志，但由于体量实在太大，也没有明显的进展，只能姑且认为程序启动时确实处理了更多业务逻辑从而消耗了更多 CPU，上线 DeepFlow 后，这类问题一下变得简单直接了。利用 DeepFlow 的 Request Rate 快速的确定集群 QPS 突增，再利用调用详情精准的定位 URI 异常，利用业务标签，找到根因：因为客户端/服务端版本不一致，导致客户端频繁重试。

新版服务上线后经常超时，通过日志告警发现是因为需要调用第三方服务接口经常超时。但业务日志只能知道是第三方服务存在超时情况，但却没办法更进一步分析是网络抖动还是第三方服务存在问题，上线 DeepFlow 后可分钟级定界网络抖动还是第三方服务问题。利用网络指标发现 TCP 建连时延很低且 TCP 重传比例也非常低，这里说明网络整个情况是没问题的，分析网络流日志，发现超时时网络传输存在异常，这个异常原因都是服务端重置，说明是第三方服务存在异常。

DeepFlow 基于 eBPF 技术的做到了零侵扰的可观测性数据采集，其提供的任意服务的全景拓扑、任意调用的分布式追踪、任意函数的性能剖析三大核心产品能力也真正的实现了分钟级定位问题，显著提供了故障排障的效率。