概要：随着APISIX作为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 团队提供从代码到基础设施的监控及诊断本领。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
