利用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,但在对部分业务请求的响应时延劣化的故障进行诊断时,却发现这两种工具组合起来无法回答故障的边界问题:

  • 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 之间。

时延分段结果-1

3)抓包 ------ 历尽千辛万苦!

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

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

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

时延分段结果-2

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)的响应时延等指标数据:

DeepFlow 全栈、全链路采集

2)应用拓扑,一分钟排除 APISIX 嫌疑

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

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 方才回复应用响应。

调用链追踪火焰图 1 及解读

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

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

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

调用链追踪火焰图 2 及解读

通过以上两种调用链追踪的结果,我们便可以排除公有云、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 团队提供从代码到基础设施的监控及诊断能力。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/368029.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

网站显示不安全怎么解决

网站显示不安全通常表现为浏览器地址栏中出现“不安全”字样或红色感叹号,这意味着用户的个人信息、登录凭证和其他敏感数据可能面临风险。以下是一些步骤和建议: 1、检查URL是否以HTTPS开头: 确保你访问的网址是以https://开头,而…

go-redis源码解析:cluster模式如何选择节点

1. 如何选择节点 1.1. 确定slot 1.1.1. 通过cmdSlot方法确定在哪个槽上, 这一步只是本地计算 首先入口方法_process,先通过cmdSlot方法用key计算此次应该落在哪个槽上 通过crc16sum算法计算key应该属于哪个槽,slotNumber为16384 func Slot(key strin…

ctfshow-web入门-命令执行(web118详解)Linux 内置变量与Bash切片

输入数字和小写字母,回显 evil input 查看源码,发现这里会将提交的参数 code 传给 system 函数 使用 burpsuite 抓包进行单个字符的模糊测试 fuzz: 发现过滤掉了数字和小写字母以及一些符号,下面框起来的部分是可用的 结合题目提…

h5兼容table ,如何实现h5在app内使用h5渲染table表格而且实现横屏预览?

压图地址 横屏div 通过css 实现 transform: rotate(90deg); transformOrigin: 50vw 50vw ; height: 100vw; width: 100vh;<divclass"popup-box":style"{transform: originSet 0 ? rotate(90deg) : ,transformOrigin: originSet 0 ? 50vw 50vw : ,height…

Facebook:数字社交的引领者与创新者

自2004年诞生以来&#xff0c;Facebook从一个校园网络项目迅速成长为全球最大的社交媒体平台&#xff0c;彻底改变了我们与世界互动的方式。作为数字社交的引领者和创新者&#xff0c;Facebook不仅在技术层面上不断突破&#xff0c;也在社会和文化领域留下了深刻的印记。本文将…

如何对GD32 MCU进行加密?

GD32 MCU有哪些加密方法呢&#xff1f;大家在平时项目开发的过程中&#xff0c;最后都可能会面临如何对出厂产品的MCU代码进行加密&#xff0c;避免产品流向市场被别人读取复制。 下面为大家介绍GD32 MCU所支持的几种常用的加密方法&#xff1a; 首先GD32 MCU本身支持防硬开盖…

Flutter第十五弹 Flutter插件

目标&#xff1a; 1.Flutter插件是什么&#xff1f;有什么作用&#xff1f; 插件 (plugin) 是 package 的一种&#xff0c;全称是 plugin package&#xff0c;我们简称为 plugin&#xff0c;中文叫插件。 2.怎么创建Flutter插件&#xff1f; 一、什么是插件 在flutter中&am…

mysql逗号分割字符串“1,2,3”实现in查询

数据示例 前台单值参数实现in查询 主要函数FIND_IN_SET 该函数的作用是查询字段(strlist) 中是否包含(str)的结果&#xff0c;返回结果为 null或记录 select id,recommend_position_id from t_stk_task where FIND_IN_SET(359919,recommend_position_id)查询效果 前台集…

vue3单个页面进行防抖节流

防抖 <template><button id"submitButton" ref"submitButton">GET</button> </template><script lang"ts" setup> import { ref, onMounted } from vue;// 防抖函数 function debounce(func: () > void, dela…

Python从入门到放弃——浮点型变量

浮点型变量 前言 上一篇文章我们研究了整数类型变量&#xff0c;本次我们来开始研究一下浮点类型变量。 浮点类型 浮点数在计算机编程中扮演着重要的角色。它们是一种特殊的数据类型&#xff0c;用于存储和处理小数或实数。在Python中&#xff0c;浮点数是由小数点分隔的…

[数据结构] --- 树

1 树的基本概念 1.1 树的定义 树是n(n>0)个结点的有限集。当 n 0 时&#xff0c;称为空树。在任意一棵树非空树中应满足&#xff1a; (1) 有且仅有一个特定的称为根 (root) 的结点&#xff1b; (2) 当 n > 1 时&#xff0c;其余结点可分为m(m>0)个互不相交的有限集…

【Unity 3D角色移动】

【Unity 3D角色移动】 在Unity 3D中实现角色移动通常涉及到几个关键步骤&#xff0c;包括设置角色的物理属性、处理输入、更新角色的位置以及动画同步。下面是实现基本3D角色移动的步骤和示例代码&#xff1a; 步骤1&#xff1a;设置角色的物理属性 角色通常使用Character Co…

单目相机减速带检测以及测距

单目相机减速带检测以及测距项目是一个计算机视觉领域的应用&#xff0c;旨在使用一个摄像头&#xff08;单目相机&#xff09;来识别道路上的减速带&#xff0c;并进一步估计车辆与减速带之间的距离。这样的系统对于智能驾驶辅助系统&#xff08;ADAS&#xff09;特别有用&…

【JavaWeb】利用IntelliJ IDEA 2024.1.4 +Tomcat10 搭建Java Web项目开发环境(图文超详细)

1、启动IntelliJ idea 2024.1.4 在欢迎页面&#xff0c;请确认好版本。因为不同的版本&#xff0c;搭建项目过程不太一样。 点击&#xff0c;新建项目。如图&#xff1a; 2、新建项目 在新建项目界面&#xff0c;选择java&#xff0c;在右侧信息模块内&#xff0c;根据个人情…

关于ant design vue 使用Modal无法关闭弹窗的解决思路

文章目录 1: 出现问题的版本2.出现问题&#xff08;1&#xff09;ant design 的问题&#xff08;2&#xff09;poina的提示报错 3.正确版本总结 1: 出现问题的版本 "ant-design-vue": "^3.2.20", "pinia": "^2.1.7", "vue"…

Ubuntu18.04新安装--无网络连接、重启黑屏解决教程

一、安装Ubuntu Ubuntu安装需要U盘作为启动盘&#xff0c;在目前教新的电脑中选中GPT作为分区&#xff0c;制作启动盘&#xff0c;其中在安装双系统Ubuntu时&#xff0c;以自定义格式作为存储空间。详细安装过程以以及如何分区请参考下列链接&#xff1a;内含详细安装过程&…

如何在Lazada平台快速出单?测评助力商家突破销量瓶颈

Lazada在短短的几年里已经发展成了东南亚地区最大的在线购物网站之一 &#xff0c;很多商家也想要在这样一个大的跨境平台上发展。那么&#xff0c;对于希望在Lazada平台上大展拳脚的商家而言&#xff0c;出单是否容易呢? ​一、Lazada出单容易吗? Lazada出单的难易程度并非…

Simulink 模型生成 C 代码(四):比较模型仿真和生成代码的结果

接下来将验证生成的代码执行时在数值上等效于 Simulink 中建模的算法。您使用测试框架模型在普通模式下对 RollAxisAutopilot 进行仿真&#xff0c;并在 SIL 模式下进行仿真&#xff0c;然后使用仿真数据检查器比较这两个仿真。 要测试生成的代码&#xff0c;您可以运行软件在…

Kubernetes基于helm安装 harbor

Kubernetes基于helm安装 harbor 之前harbor的安装都是借助docker完成一键安装部署&#xff0c;安装完成之后harbor组件均运行到一台机器上面&#xff0c;本文实践harbor在k8s环境中的部署。 准备工作 根据harbor官方要求&#xff1a; Kubernetes cluster 1.20Helm v3.2.0 …

SpringMVC基础详解

文章目录 一、SpringMVC简介1、什么是MVC2、MVC架构模式与三层模型的区别3、什么是SpringMVC 二、HelloWorld程序1、pom文件2、springmvc.xml3、配置web.xml文件4、html文件5、执行Controller 三、RequestMapping注解1、value属性1.1、基础使用1.2、Ant风格&#xff08;模糊匹配…