ToB企服应用市场:ToB评测及商务社交产业平台

标题: 利用DeepFlow解决APISIX故障诊断中的方向毛病题目 [打印本页]
作者: 愛在花開的季節    时间: 2024-11-22 00:09
标题: 利用DeepFlow解决APISIX故障诊断中的方向毛病题目
概要：随着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，但在对部门业务请求的相应时延劣化的故障进行诊断时，却发现这两种工具组合起来无法回答故障的边界题目：

此时，团队无法在 APISIX、后端应用实例、K8s、公有云之间确定故障边界 ，陷入了 " 到处都有大概 " 的困境。
2）插桩 ------ 数据迷雾重重！

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

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


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

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

最终经过连续多周的抓包读包分析，团队发现 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 应用拓扑图中差别通讯对端、差别位置的应用相应「最大时延」指标，我们可以快速发现相应速度最差的应用请求在全链路中差别位置的时延表现：



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

至此，我们便在打开 APISIX 拓扑后的 1 分钟内明确清除 APISIX 的故障嫌疑，并将故障源锁定到 APISIX 的后方（包罗公有云、K8s、后端应用）。
   注：测试环境复现的相应时延与生产环境的实时业务相应时延会有肯定差别，但不影响 DeepFlow 故障诊断的分析过程和定界方法。
  3）调用链追踪，一分钟锁定后端应用

如安在公有云、K8s、后端应用之间找到故障的根源呢？我们在 DeepFlow 中选择一部门相应时延最大的应用调用进行调用链追踪，发现有两类差别的时延征象。
征象 1------ 后端应用实例「网络 Span」与「系统 Span」差值显着
从第一种时延严峻劣化的应用调用链追踪火焰图中（见下图），我们可以看到 pctr 的「网络 Span」时延为 477.48ms，pctr 的「系统 Span」时延为 121.48ms，两者中间出现了约 356ms 的差值，这阐明：



   注：「网络 Span」------ 即 DeepFlow Agent 收罗的网卡位置的数据，Span 长度表示某次请求在该网络接口的相应时延； 「系统 Span」------ 即 DeepFlow Agent 收罗的应用进程系统调用位置的数据，Span 长度表示某次请求在应用进程出入口位置的相应时延。
  征象 2------ 后端应用实例「系统 Span」时延大
从第二种时延严峻劣化的应用调用链追踪火焰图中（见下图），我们可以看到 pctr 的「系统 Span」时延达到 451.55ms，这阐明：pctr 应用实例收到请求后，内部代码处理惩罚及其他后端调用消耗 451.55ms 方才复兴应用相应，可以判断 Work 线程处于繁忙状态。


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

复盘此次相应时延劣化的定位过程，我们发现快速、准确定界能力的缺失是云原生 IT 系统可靠性保障的最大障碍。
定界能力缺失每每导致 "瞽者摸象"、"南辕北辙" 环境的产生，导致故障诊断团队的资源和时间消耗在无效的工作中，导致故障常常在差别团队之间流转、循环、甩锅，导致故障定位率低、定位周期长。而定界能力缺失的重要原因包罗：

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

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

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4