网站做程序员,西安网站制作顶尖公,重庆公司注册核名查询系统,wordpress 死链检测概要#xff1a;随着APISIX作为IT应用系统入口的普及#xff0c;其故障定位能力的不足导致了在业务故障诊断中#xff0c;APISIX常常成为首要的“嫌疑对象”。这不仅导致了“兴师动众”式的资源投入#xff0c;还可能使诊断方向“背道而驰”#xff0c;从而导致业务故障“…概要随着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.48mspctr 的「系统 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 团队提供从代码到基础设施的监控及诊断能力。
