eBPF 技术如何提升故障排查效率实战
6 月 22 日，由开源中国主办，华为、上海浦东软件园联合主办的【云技术专场】OSC源创会 · 上海站 · 104期线下沙龙成功举办。来自云杉网络的 DeepFlow 高级产品经理李倩发表了《DeepFlow 实战：eBPF 技术如何提升故障排查效率》主题演讲，展示通过零侵扰数据采集、应用性能指标监控、分布式追踪和持续性能剖析等技术实现零侵扰的高效故障排查。
以下为李倩的演讲回顾，内容由活动现场参会嘉宾@阿维同学贡献。
整理：阿维同学（ WeChat：AWTX550W）
随着云原生应用的发展，IT 系统的复杂度呈指数级增加。连接微服务的基础设施越发复杂，路径数量随之增长，导致系统的可观测性变得至关重要。
-
服务数量增加：服务数量不断增长，单个服务变得越来越简洁，发布频率加快。通用逻辑逐渐卸载到基础设施，开发语言和框架变得更加多样化和自由。
-
路径数量增加：服务间的路径数量随着服务数量的增加而迅速扩展，导致系统之间的交互变得极其复杂。
现有的监控组件也遇到一系列瓶颈
-
插桩困难: 随着系统复杂度增加，传统的插桩方法难以满足需求。
-
追踪盲点: 多样化的服务和复杂的路径使得追踪问题变得困难。
-
标签不足: 缺乏统一的标签管理，导致数据之间难以关联。
-
数据孤岛: 数据分散在不同的服务和系统中，难以综合分析。
-
容量焦虑: 随着服务和路径的增加，容量管理变得更加困难。
-
资源消耗: 复杂的系统导致资源消耗增加，难以优化。
为了应对上述挑战，全栈可观测性成为必备能力。它提供了从应用代码、系统进程、网络存储到基础设施的全面监控和分析能力。通过全栈可观测性，运维和开发人员能够实时了解系统的运行状态，快速定位和解决问题，确保系统的稳定性和高效运行。
其中深入剖析了微服务架构中应用程序性能监控（APM）所面临的两大核心挑战—— 插桩困难和定界困难。
-
第一，探针侵扰性导致难以落地。插桩的过程需要对应用程序的源代码进行修改，重新发布上线。即使例如 Java Agent 这类字节码增强技术，也需要修改应用程序的启动参数并重新发版。然而，对应用代码的改造还只是第一道关卡，通常落地过程中还会碰到很多其他方面的问题，例如代码冲突、维护困难、边界模糊等。
-
第二，观测盲点导致无法定界。即使 APM 已经在企业内落地，我们还是会发现排障边界依然难以界定，特别是在云原生基础设施中。这是因为开发和运维往往使用不同的语言在对话，例如当调用时延过高时开发会怀疑网络慢、网关慢、数据库慢、服务端慢，但由于全栈可观测性的缺乏，网络、网关、数据库给出的应答通常是网卡没丢包、进程 CPU 不高、DB 没有慢日志、服务端时延很低等一大堆毫无关联的指标，仍然解决不了问题。定界是整个故障处理流程中最关键的一环，它的效率至关重要。
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 技术的做到了零侵扰的可观测性数据采集，其提供的任意服务的全景拓扑、任意调用的分布式追踪、任意函数的性能剖析三大核心产品能力也真正的实现了分钟级定位问题，显著提供了故障排障的效率。
