概要：随着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企服之家，中国第一个企服评测及商务社交产业平台。 |
