摘要：APISIX 被越来越多的用户选择作为 IT 应用系统的入口，由于故障定界能力的缺失，在 IT 业务故障诊断过程中，APISIX 经常成为重点"怀疑对象"，一方面"劳师动众 "投入大量运维人力定位，另一方面诊断方向"南辕北辙 "，因而业务故障"久拖不决 "。通过本篇文章复盘重现某全球领先的智能终端提供商 近期对核心业务响应时延劣化故障的处理过程，您将直观了解到"南辕北辙"现象对诊断效率的决定性影响，以及 DeepFlow 可观测性平台如何用数分钟时间 、几步简单操作 ，消除 APISIX 故障诊断中的"南辕北辙 "，解决长达两个月悬而未决的问题，为故障处置效率带来飞跃提升。

01 业务故障的定界困境

作为一款云原生时代极受关注的 API 网关产品，Apache APISIX 被越来越多的用户选择作为 IT 应用系统的入口，在网运行的 APISIX 承载着重要等级各有差异的不同业务，但在运维过程中，普遍存在着故障诊断定位的困难。当业务出现异常需要诊断定位时，运维团队无法快速、清晰地确定故障边界，因而 APISIX 经常成为重点"怀疑对象"，一方面投入大量运维人力消耗在无效的读日志、抓包、追踪等诊断工作中，另一方面诊断方向经常"南辕北辙"，业务故障长期得不到解决。

近期某全球领先的智能终端提供商 就在运维工作中陷入了这样的困境，核心业务系统出现明显的响应时延劣化之后，在长达两个月的定位过程中无法确定故障边界，网关、应用、公有云服务商等多个团队在错误的方向投入大量人力但仍无头绪。

故障诊断陷入困境后，故障诊断团队以零基础在两小时内完成 DeepFlow 企业版的部署，数分钟内点亮业务链路拓扑及多个关键位置的性能指标，迅速排除 APISIX 的故障嫌疑，并将故障锁定到后端应用。

从本文的整个定位过程您可以看到 DeepFlow 可观测性平台在实战中，如何用数分钟时间、几步简单的操作解决数名工程师两个月未能完成的故障诊断工作，为包括 APISIX 在内的云原生应用、网关、基础组件、基础设施提供分钟级的故障定界能力，为云原生业务提供端到端的可靠性运维保障能力。

02 警报响起

该智能终端提供商的 IT 业务系统构建在公有云之上，业务部署跨多个可用区，架构复杂，组件众多，运维保障和故障诊断涉及应用、平台、公有云服务商等企业内及企业间不同团队之间的沟通协作。

某段时间，该企业 IT 业务系统中的"手机收入系统"的应用服务，在高压力情况下一部分业务请求出现明显的响应时延劣化，直接影响 ToC 客户业务服务过程的交易流畅度，线上用户的业务体验受到影响，企业对此高度重视，组织多个技术团队的技术人员组成故障诊断团队，联合专项定位并每日汇报定位进展。

03 持续 2 个月的鏖战

1）谁是问题的根源？

团队对业务路径进行梳理，确定该业务服务的访问过程经过了 Client、APISIX、公有云、K8s、后端应用等诸多内、外部组件。

到底谁是问题的根源呢？------现在首要的问题便是故障定界。

当前可用的运维工具包括 Prometheus 和 Pinpoint，但在对部分业务请求的响应时延劣化的故障进行诊断时，却发现这两种工具组合起来无法回答故障的边界问题：

• Pinpoint 的局限性：Pinpoint 覆盖了后端应用实例（pctr）的内部关键应用函数，但插桩范围之外的代码、K8s 网络、公有云、APISIX 等位置的响应时延均无从了解；
• Prometheus的局限性：通过 Prometheus 观测的指标是粗粒度的 APISIX 性能指标统计结果，经过 APISIX 的统计计算后已经失去许多关键信息，无法将性能指标细化到 Ingress 方向、Egress 方向，细化到每一个通信对端，细化到每一次业务请求；
• 关联的困难：Prometheus 的粗粒度统计指标与 Pinpoint 的细粒度追踪记录中的时延指标无直接对应关系。

此时，团队无法在 APISIX、后端应用实例、K8s、公有云之间确定故障边界 ，陷入了"处处都有可能"的困境。

2）插桩------数据迷雾重重！

当发现 APISIX 的 Prometheus 指标过粗，无法对此次响应时延劣化的故障进行定界后， 团队迫不得已开始对 APISIX 代码进行追踪插桩的改造并上线新的版本，尝试追踪单条请求在 APISIX、Pinpoint 中的响应时延表现，这时抽样分析（人工分析无法对比每一次请求量，仅能做少量抽样）发现：

• 应用请求在后端应用（pctr） 位置的时延约 48ms（源自 Pinpoint 追踪数据）；
• 应用请求在 APISIX 插桩位置的响应时延约 88ms（源自 APISIX 的追踪打印日志）。

问题"看起来"出现在 APISIX、公有云和 K8s 之间。

3）抓包------历尽千辛万苦！

为了彻底弄清楚 APISIX 是否是问题真正的根源，团队开始投入人力在 APISIX 所在的近百个 CVM 上对接口网卡进行人工抓包、读包，比对应用请求在网卡位置的时延表现，但依然面临两个方面的困难：

• 人力投入巨大 ：每一轮的抓包均会包含数十万次业务请求，产生数 GB 数据包，需要投入大量的人力进行分析，工程师只能全力以赴以 7*15 小时的工作节奏投入到抓包读包的工作中；
• 容易陷入"盲人摸象"：人工读包只能解读少量业务请求的交互过程，无法分析每一次业务请求的端到端时延，分析样本量有限，得出的结论容易出现"盲人摸象"，结论可信度容易被质疑。

最终经过连续多周的抓包读包分析，团队发现 CVM 网卡位置的应用响应时延约为 50ms，结合 APISIX 追踪打印日志中的 88ms，因而得到一个阶段性结论：APISIX 对应用响应时延贡献了约 38ms，所以 APISIX 是问题的根源（事后分析这是一个"南辕北辙"的结论）。

4）怀疑------插桩数据准确吗？

当抓包数据和插桩数据让我们将所有注意力放到 APISIX 身上后，开发人员开始对 APISIX 的程序代码进行诊断定位，但再次历经连续多天的努力，仍然无法在 APISIX 的代码中找到任何会引入 "38ms " 时延的可疑点，而且 "38ms" 对于网关产品基本属于天量且难以置信的时延。

团队开始怀疑：APISIX 插桩日志输出的 "88ms" 时延真实、可靠吗？

由于不同开发语言、插桩数量、插桩代码质量均会带来不同程度的「插桩时延 」，而且插桩代码会引入多少「插桩时延」无法得到准确的评估和测量， "88ms" 有多少是由 APISIX 的插桩代码引入，有多少是由 APISIX 自身引入，变成了一个无解的问题。

至此，时间已经过去两个月 ，但 Pinpoint 追踪数据、APISIX 插桩追踪数据、抓包数据让响应时延劣化故障的定界变得更加扑朔迷离，故障诊断定位工作回到原点。

注：「插桩时延」------在应用程序中启用追踪插桩后，插桩代码的执行动作会增加服务响应时延，这一部分额外增加的时延可以将其称之为「插桩时延」。

04 使用 DeepFlow 快速排障

团队了解到 DeepFlow 可观测性平台的 Agent 通过 eBPF 技术实现观测数据采集能力，具有应用零侵扰 、随时热加载的特点，无需对 APISIX 网关和后端应用实例进行重启操作即可开启从网关到应用的端到端观测能力，因此开始尝试使用 DeepFlow 进行故障诊断。由于初次使用 eBPF 技术，团队决定先在测试环境部署 DeepFlow 对此次故障复现定位。

1）快速部署 DeepFlow

DeepFlow 支持容器化部署，极大降低了部署难度，工程师以零基础在 2 个小时内即完成了 DeepFlow 企业版的部署工作，并将 DeepFlow Agent 覆盖到 APISIX 网关所在的数十个 CVM 和上百个后端应用实例所在的 K8s 容器集群。

随着 Agent 的运行，DeepFlow 随即开始实时采集每一次应用调用在全链路多个位置（如下图中 1、2、3、4、5、6）的响应时延等指标数据：

2）应用拓扑，一分钟排除 APISIX 嫌疑

DeepFlow 运行后的数分钟内即可开始进行诊断定位，输入 APISIX 实例的 CVM 名称后，调阅出 APISIX 实例的应用访问拓扑，以及前后端互访的应用性能指标数据：

与 Prometheus 指标数据相比，DeepFlow 的应用性能指标数据可以细化区分 Ingress 方向、Egress 方向，细化区分每一个通信对端，细化区分不同采集位置，因此通过 APISIX 应用拓扑图中不同通信对端、不同位置的应用响应「最大时延」指标，我们可以快速发现响应速度最差的应用请求在全链路中不同位置的时延表现：

• （观测点 1 ）APISIX Ingress 方向的网卡位置的最大响应时延------506.72ms
• （观测点 2 ）APISIX Ingress 方向的系统 Syscall 位置的最大响应时延------506.69ms
• （观测点 3 ）APISIX Egress 方向的系统 Syscall 位置的最大响应时延------506.56ms
• （观测点 4 ）APISIX Egress 方向的网卡位置的最大响应时延------506.5ms

通过以上数据可直观发现如下信息：

• APISIX （含 CVM）对最大响应时延的贡献仅为 [506.72ms - 506.5ms] =0.22ms
• 后端（含公有云、K8s、后端应用实例）贡献了 506.5ms

至此，我们便在打开 APISIX 拓扑后的 1 分钟内明确排除 APISIX 的故障嫌疑，并将故障源锁定到 APISIX 的后方（包括公有云、K8s、后端应用）。

注：测试环境复现的响应时延与生产环境的实时业务响应时延会有一定差异，但不影响 DeepFlow 故障诊断的分析过程和定界方法。

3）调用链追踪，一分钟锁定后端应用

如何在公有云、K8s、后端应用之间找到故障的根源呢？我们在 DeepFlow 中选择一部分响应时延最大的应用调用进行调用链追踪，发现有两类不同的时延现象。

现象 1------后端应用实例「网络 Span」与「系统 Span」差值明显

从第一种时延严重劣化的应用调用链追踪火焰图中（见下图），我们可以看到 pctr 的「网络 Span」时延为 477.48ms，pctr 的「系统 Span」时延为 121.48ms，两者中间出现了约 356ms 的差值，这说明：

• pctr 应用实例的 IO 线程调度处于繁忙状态，网卡收到请求之后延迟约 356ms 方才触发 IO 线程的 Syscall 进行数据读取，导致响应时延劣化。
• pctr 应用实例收到请求后，内部代码处理及其他后端调用消耗 121.48ms 方才回复应用响应。

注：「网络 Span」------即 DeepFlow Agent 采集的网卡位置的数据，Span 长度表示某次请求在该网络接口的响应时延； 「系统 Span」------即 DeepFlow Agent 采集的应用进程系统调用位置的数据，Span 长度表示某次请求在应用进程出入口位置的响应时延。

现象 2------后端应用实例「系统 Span」时延大

从第二种时延严重劣化的应用调用链追踪火焰图中（见下图），我们可以看到 pctr 的「系统 Span」时延达到 451.55ms，这说明：pctr 应用实例收到请求后，内部代码处理及其他后端调用消耗 451.55ms 方才回复应用响应，可以判断 Work 线程处于繁忙状态。

通过以上两种调用链追踪的结果，我们便可以排除公有云、K8s 的故障嫌疑，明确后端应用是此次响应时延劣化故障的问题根源，APISIX 运维和开发、K8s 运维、公有云服务商便可以从故障诊断团队中释放，由应用开发团队独立定位应用代码的根因。

05 复盘

复盘此次响应时延劣化的定位过程，我们发现快速、准确定界能力的缺失是云原生 IT 系统可靠性保障的最大障碍。

定界能力缺失往往导致"盲人摸象"、"南辕北辙"情况的产生，导致故障诊断团队的资源和时间消耗在无效的工作中，导致故障经常在不同团队之间流转、循环、甩锅，导致故障定位率低、定位周期长。而定界能力缺失的主要原因包括：

• APM 追踪的盲区：应用的 APM 追踪能力能够观测应用内部的关键位置，但应用外部仍存在大量盲区；
• Prometheus 指标的粗糙：多数故障的诊断定位需要精细到单次应用调用，而 Prometheus 的粗粒度统计指标数据对此类应用响应时延劣化的追踪诊断无法发挥作用；
• 「插桩时延」的干扰：为诊断故障而临时在 APISIX 中进行追踪插桩，但同时引入的「插桩时延」反而影响诊断结论的准确性，甚至误导故障定位方向；
• 人工分析的"盲人摸象"：人工无法完成海量数据的采集、解析、分析工作，因此人工抓包、读包、读日志、关联比对等操作只能对少量样本抽样分析，分析结论只能"盲人摸象"，很难得出全面、准确的结论。

而对比发现，DeepFlow 的零侵扰调用链追踪能力则全面解决了上述关键难题，从而能够在故障诊断过程中通过客观数据快速确定故障边界：

• 无盲区追踪 ：DeepFlow 通过 eBPF 技术实现的零侵扰调用链追踪，将任意一次应用调用的追踪能力覆盖到应用、转发网卡、APISIX，还包括其他各类中间件、负载均衡、消息队列、数据库、DNS 等基础服务，因而可以在各个组件间快速定界；
• 细粒度指标 ：DeepFlow 采集分析的应用调用指标可以细化到 Ingress 方向、Egress 方向，细化到每一个通信对端，细化到不同采集位置，快速比对不同位置、不同通信对、出/入向的指标数据，因而可以在不同采集位置间快速定界；
• 客观数据 ：DeepFlow 通过 eBPF 技术实现了在 Linux 内核中观测数据的旁路采集能力，采集过程不影响应用程序的处理过程，做到对应用响应时延的零影响，因而可以获取各个位置的客观数据，得出更准确、更客观的诊断结论；
• 业务全貌 ：DeepFlow 实时采集全链路数据并自动关联分析，因而可以在无需投入大量人工的情况下快速观测业务全貌，得出全面、准确结论。

正是由于以上技术的加持，DeepFlow 能够帮助运维工程师在数分钟内明确故障是否与 APISIX 有关，用几步检索操作替代数名工程师两个月的繁琐抓包读包，并且在故障诊断过程中用精细的数据得出准确的结论。

06 什么是 DeepFlow

DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云原生 及 AI 应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰 （Zero Code）采集，并结合智能标签 （SmartEncoding）技术实现了所有观测信号的全栈 （Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生及 AI 应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

GitHub 地址：https://github.com/deepflowio/deepflow

访问 DeepFlow Demo，体验零侵扰、全栈的可观测性。