10 posts tagged with "排障实战"

业务可用性问题的快速诊断，历来是行业互联网公司面临的重大挑战，快手也不外如是。Kindling-OriginX的体系化设计理念快速打动了我们的工程师。快手随即开始了内部真实业务的验证落地；落地过程中，Kindling-OriginX能高效覆盖大部分线上问题的快速定界，其中20%可直接给出根因，缩短业务影响时长。未来，我们希望与Kindling-OriginX在异常场景和诊断效率上继续深度合作，进一步缩短业务异常的恢复时长，以及提升工程师研发幸福感。

---周辉，容器云稳定性团队负责人

Originx注：快手团队对根因的要求比较高，比如一般团队遇到请求被锁住，得到锁的代码堆栈就够了，但是快手团队要求更高，更希望知道为什么代码发生了锁住originx目前还只能给出哪段代码堆栈导致锁住。

目的​

愿景：缩短对线上稳定性问题的定位时长，帮助业务快速止损，减轻日常问题排查的人力成本。

1.是否能在在公司落地，给实际的问题诊断带来帮助；

2.为问题诊断提供借鉴思路：通过ebpf采集系统层面指标，打通业务请求链路。

结论​

OriginX 诊断能力​

结论：能够进行问题的定界。

延时耗时示意图

初步分支定界​

可以对问题起到初步分支定界的作用，能初步判断出是问题哪个或哪些类别，即 :

1.CPU 执行（onCPU）

• 是否能够下钻
• 对 frequency 问题的判定效果？可以设置 frequency 吗【Originx 目前支持各种频率 CPU 采样，但是需要重启探针】

2.等待调度到 CPU（RUNQ）

• 较少发生，主机有较高的负载的场景

3.读写文件（VFS 的直接读写关联存储相关问题）

• 如何确定拿到的文件和请求是相关
• Originx 通过与请求过程中的系统调用关联，按照时间能精准匹配到请求时的系统调用

4.请求下游节点耗时长（网络调用）

5.锁等待或内存 GC 类型（futex 等）

• 如何确定拿到的这个锁和这个请求有关
• Originx 通过与请求过程中的系统调用关联，按照时间能精准匹配到请求时的系统调用

Originx 不擅长的故障种类：

1.对 CPU 算力分层类、夯机类、硬件类等问题的分析 Kindling-OriginX 诊断相对比较薄弱；

2.对Java 类服务的支持友好，接入 Kindling-OriginX 需要适配公司的 “全链路追踪系统”。

Originx 存在优化空间​

快手使用的 Originx 版本在确定故障报告时存在多种可能性，需要人为排除噪音干扰因素。

1.由于一个采样报告只能得出一种结论，故障发生所在的时间段内若干采样点产生的多个报告，可能结论不一致，需要自己来判断具体是哪方面原 因占主导，排除干扰因素； 有时会出现----未发现明显异常的结论，如

2.故障分为慢故障和故障两大类。对于慢故障，请求调用时长与历史数据相对比，发现其大于 24h 内历史 P90（或 p99,p95） 数据，将其判定为慢故障。假设极端情况，存在故障的实例的请求时延在 24h 内一直都很高，那么后续的请求也会被判断为正常请求，产生漏判。

3.下钻诊断能力不足，当前除了对网络故障具备更细粒度的诊断（需接入 DeepFlow，在根因报告中对于对外调用网络耗时长的问题，根 因推导能够回答网络耗时分布的根因，例如是客户端网络问题还是服务端网络问题，是 RTT 问题还是丢包重传问题），其他类型问题 有待关联更多数据提供更多的下转能力。

---

原理​

请求故障评估标准​

业务请求时延指标大于 P90（或者 P95,P99 阈值），就会判定为慢请求故障。

线程状态分析方法（TSA）​

有别于从资源视角的 USE 方法是从整理上找破绽来缩小异常的范围，给出可能性的方向，TSA 是从主体（线程）角度出发进一步明确线程时间消耗在哪里的方式。

http://u6v.cn/5VZWML

TSA 与 Trace 结合​

内核视角缺少业务属性，Trace-Profiling 通过 TSA 的方法论产生的数据与 Trace 打通，做到了与业务关联，这样在生产环境就可以做到某个业务因为什么原因卡住了。

skywalking 会给请求打一个 trace id，利用 ebpf 的能力将 trace 通过 PID 和 TID 底层的 syscall 相关联利用

eBPF 技术能够深入内核，拦截线程执行用户代码的关键点位获取信息，在获得线程执行关键信息之后能够还原线程的执行过程。如 果只从线程维度看程序执行过程是很难分析出故障的，因为开发和运维的谈的故障都是 URL 维度的用户请求调用，所以光有线程维度程序 执行过程是不够的，需要和 Tracing 系统关联。当线程执行过程与 Tracing 系统关联之后，即可完整还原用户一次请求的执行过程。TraceProfiling 中关联了可观测性所需要的数据。

指标说明

Kindling-OriginX 并不直接提供 Trace 能力，而是采用接入 Trace 数据的形式，即通过接入目前成熟的 Trace 产品与提供标准接入 SDK 方 式，例如 Skywalking、OpenTelemetry、ARMS 等，利用 eBPF 能力将 Trace 数据进行扩展，将其与底层的系统调用相关联，进而实现整 的可观测性，消除程序执行与 Trace 数据中的盲区。

用决策树结合 TSA 实现对内核事件的自动化翻译​

基于内核事件统计分析，可以形成这样的决策树，最终给出故障的根因。

北极星排障指标-CPU 时间程序

在 CPU 资源上所消耗的时间

• OnCPU

  程序代码执行所消耗的 CPU cycles，可以通过程序火焰图确认代码在 CPU 上执行消耗的时间与代码堆栈。

• Runqueue

  线程的状态是 Ready，如果 CPU 资源是充分，线程应该被调度到 CPU 上执行，但是由于各种原因，线程并未调度到 CPU 执行，从而产生的等待时间。

北极星排障指标-网络时间

网络时间属于两次 OnCPU 时间之间的 OffCPU 时间

• 网络时间打标过程

  第一次 OnCPU 最后一个系统调用执行为 sock write 与第二次 OnCPU 第一个系统调用为 sock read，也可以理解为网络包出网卡至网络包从网卡收回的时间。

• 网络时间分类

  DNS，TCP 建连，常规网络调用。

北极星排障指标-存储时间

属于两次 OnCPU 时间之间的 OffCPU 时间

• 存储时间打标过程

  第一次 OnCPU 最后一个系统调用执行为 VFS read/write 与第二次 OnCPU 第一个系统调用为 VFS read/wirte。

• 存储时间真实情况

  存储真实执行情况，由于内核的 pagecache 存在，所以绝大多数 VFS read/write 从程序视 角看：执行时间不超过 1 毫秒。

北极星排障指标-等待时间

• futex

  通常指的是一个线程在尝试获取一个 futex 锁时因为锁已经被其他线程占用而进入等待状态的时间。在这段时间内，线程不会执行任何操 作，它会被内核挂起。

• mutex_lock

  线程在尝试获取互斥锁时，因为锁已经被其他线程持有而进入等待状态的时间长度。这段时间对于程序的性能至关重要，因为在等待期 间，线程不能执行任何有用的工作。

---

实际使用效果​

历史稳定性分布问题​

效果汇总​

故障类型	故障案例	人工时长	使用Oirignx预计定界时长	召回率	准确率
OnCPU(CPU执行)时间过长	代码缺陷，直播服务故障	16min（5+位领域专业同学投入）	10min	80%	80%
	极高的中断负载	4h	10min	90%	80%
等待调度到CPU时间过长	宿主机CPU负载过高	1h	5min	90%	70%
读写文件耗时长（IO）	P2P拉镜像卡死	2天（需基础平台多位高级同学参与分析，链路长）	8min	90%	70%
	高磁盘读取负载	1h	5min	90%	60%
请求下游节点耗时长（网络调用耗时长）	网卡时延过长(网卡上tc注入时延)	4h	5min	90%	80%
	epoll耗时异常	4h	5min	90%	70%
	调用中间件耗时长	4h	5min	80%	70%
锁等待或GC	内核osq_lock锁竞争问题	1周（基础平台累计10+位领域专业同学投入，蹲守凌晨业务高峰得以查明）	10min	80%	80%
	服务异常（内核死锁问题）	1周（基础平台累计10+位领域专业同学投入）	10min	80%	80%
	Java锁耗时长	4h	5min	80%	90%
内存问题	虚拟内存压力	1h	5min	70%	70%
	用户页错误	3h	5min	80%	80%

依赖故障指应用运行所依赖的环境包括网络、中间件、缓存故障导致应用出现故障。这部分故障的根因并不是应用代码的问题，但是其最终表现形式和应用代码故障表现形式类似，很难区分。本文重点呈现Originx如何针对应用环境所依赖的故障进行根因分析，之前的系列文章请参考：

之前的系列文章： 在线业务的常见全栈故障种类与定位手段

文章中对常见的全栈故障的传统定位方法进行了阐述。

Originx的创新解法之：应用程序故障篇

文章中呈现了如何利用Originx的功能对应用程序故障的根因定位。

网络故障​

网络连接中断、延迟或丢包​

○ 案例：2023年4月,某互联网金融云平台因内部容器云平台的COREDNS服务器群集发生异常,导致整个私有云内的核心交易系统无法正常解析内部服务地址。在接下来的3个小时内,平台的放贷、风控等多个交易系统出现大面积延迟和连接中断,账户查询、委托下单等关键业务无法正常使用。据初步统计,这次故障给金融机构带来的直接经济损失高达数亿元人民币。最终通过手动配置绕过DNS解析,临时恢复关键系统连接,但整体恢复所需时间超过10个小时。事后分析发现,DNS集群全军覆没是由于COREDNS升级之后的bug导致，但是没有完善的监控导致故障发现严重滞后。

如果出现案例描述中的网络故障，需要安装专业的网络流量监控工具，并配备相关专业网络专家才能很好分析出问题。此外，网络监控的基线是非常难建立的，以丢包为例，出现丢包就应该告警吗？那会产生非常多的错误告警

Originx轻松能够帮助用户分析出根因：

Originx的解决之道：​

1、在Originx首页，Originx的SLO告警就会针对SLO违约告警

2、同时会分析出可能的故障根因节点，当点击详情之后，每个节点的故障初因列表会被呈现出来

3、根据依赖关系，在疑似的故障根因节点中找到最下游疑似故障节点的故障初因列表，故障初因为“请求下游节点耗时长”，其上游节点多半初因也是这个初因特征，但是上游节点更大概率是由于故障节点级联影响导致，所以应该先验证下游节点的故障根因之后，再排查上游节点的故障根因

4、在故障报告的报告头部呈现的是故障概览，这里关联了TraceId以及发生的时间，如果有必要可以使用TraceId去关联分析Tracing数据

5、在故障报告左边栏中，确认故障传播链路，近似于下图，通过这个数据可以确认在此次报告中故障节点判定是否正确

6、在故障根因中，能够看到根因结论，在多份报告中看到同样的根因报告，这个时候其实可以采取应急手段来恢复业务了，针对本案例的情况: 应急手段就是迁移应用或者切流量了，具体应急措施要看企业之前应急措施准备了哪些条件，如果什么应急手段都没有准备，而且又在云上，可以向云厂商提交工单请求协助处理

7、在故障报告中，以下的数据都是为了提供证据链条来确认故障报告的准确性

北极星指标（通过北极星指标，Originx给出了异常幅度最大的异常方向，本截图的方向就是网络方向，反映出问题有两种可能，是网络真实有问题也可能是下游执行程序缓慢，网络可能存在真实问题，或者下游执行程序运行缓慢。在后续的分析中，我们将通过评估网络质量来确定是否确实存在网络问题）

接下来会列出所有程序在此次请求中执行过的所有网络请求（某些APM产品可能没有实现插裝就发现不了一些隐藏的网络调用，而Originx从内核判断网络，所有的网络调用一定会出现在这里）

接下来，将深入分析网络请求中耗时最长的部分，以精准定位网络层面的时间损耗原因。（此截图反映网络故障出现在容器网络pod，也就是容器网络有问题）

之后就是通过网络质量指标丢包和延时来进一步证实

同时还会判断网络拥塞指标，如果当时节点的CPU快耗尽的时候，虚拟网络也会出现丢包，重传的现象

网络配置错误​

○ 案例:2022年12月,世界杯决赛期间,某大型视频直播平台由于网络设备配置问题，导致导致网络丢包比例较大,数百万在线用户观看比赛直播受到严重影响,画面频频卡顿中断。该故障持续近2小时,给平台带来了广告收益损失,也影响了品牌声誉。经过紧急处理和优化,网络质量逐步恢复,但已错过了决赛最关键时段。

如果出现案例描述中的网络故障，是交换机的配置错误导致丢包增加，排障流程和之前所说的网络故障是一样的，唯一的区别就是交换机等物理设备导致网络出现重传和丢包之时，故障耗时是在物理网络段，而不是在虚拟网络段。（由于没法用TC模拟出物理网络出现问题，所以没有办法贴出物理网络有延时的截图，如果真实物理网络有问题应该反映在下图中标红的位置）

---

缓存故障​

缓存命中率下降​

○ 案例:2023年6月8日早高峰,某知名新闻平台首页及文章详情页出现加载延迟、频繁超时。原因是缓存服务配置错误导致数据过早过期,高流量下未能及时刷新,与数据库产生数据不一致。经紧急调整缓存策略,禁用部分过期机制并扩容缓存集群,系统逐步恢复。但此次事故影响约200万访问,广告收益损失近百万元。

如果出现案例描述中的缓存命中率下降故障，Originx暂时没有直接给出根因结论。但是Originx仍然能够助力用户更高效的排查出故障根因。缓存命中率下降，意味着程序执行需要额外执行数据查询操作，还有更新缓存操作，这些额外的操作会导致程序执行时的网络时间相较于正常情况有所增加，所以在表现形式上和网络故障很像

Originx的解决之道：​

1、在Originx首页，Originx的SLO告警就会针对SLO违约告警

2、同时会分析出可能的故障根因节点，当点击详情之后，每个节点的故障初因列表会被呈现出来

3、根据依赖关系在疑似的故障根因节点中找到最下游疑似故障节点的故障初因列表，故障初因应该都是“请求下游节点耗时长”，其上游节点多半初因也是这个故障初因特征，考虑级联影响，应该先验证下游节点的故障

4、在故障报告的报告头部呈现的是故障概览，这里关联了TraceId以及发生的时间，如果有必要可以使用TraceId去关联分析Tracing数据（具体截图可以参考之前的案例）

5、在故障报告左边栏中，确认故障传播链路，通过这个数据可以确认在此次报告中故障节点判定是否正确（具体截图可以参考之前的案例）

6、在故障根因报告中，由于Originx现在推理流程还未覆盖缓存对比，现在能看到的报告很可能是未分析出故障根因，如下图所示。故障初因是下游调用耗时长，点击故障报告分析并没有直接给出故障结论，但是初因的结论是准确的，因为实际上网络指标没有任何异常，而且下游节点也没有线程被打满。Originx的推理流程还未覆盖此场景，在不久将来会覆盖此种场景，该场景主要会对比异常网络调用次数和正常网络调用次数，从而判断缓存失效的场景。该故障报告仍然是有用的，可以看出很多问题

7、通过对比北极星指标和具体网络调用次数，可以发现所有的网络调用的执行过程，从中可以发现比正常调用多出了数据库的调用，和缓存调用

---

消息队列故障​

消息堆积或消费者延迟​

○案例:2023年5月15日,某知名电商平台消息中间件所在一台服务器磁盘出现坏道,导致消息写入延迟超10秒。高峰期部分订单消息阻塞,下游服务处理速度骤降80%,造成大量订单挤压及库存操作失败。由于该故障出现较少，SRE专家没有经验，排查期很长，长达1小时才排查出有问题的消息中间件实例，最后经磁盘热插拔修复坏道、调大消息队列容量等应急措施,系统逐步恢复。

如果出现案例描述中消息中间件交互延时下降的场景，不管中间件是由于案例中磁盘坏道导致，还是其它原因导致的，都应该会出现和网络时延类似的场景，故障初因表现为“请求下游节点耗时长”

Originx正在努力支持各种中间件，力争能够针对各种中间件直接给出原因，在还没有覆盖的场景中，仍然可以通过类似于缓存分析的方法，通过分析网络调用细节，从而得到故障根因。具体使用方式和缓存命中率下降是一样的

---

外部依赖故障​

下游第三方服务调用延迟或失败​

○案例:2023年7月6日,某金融科技公司接入第三方支付平台时,遭遇DNS故障导致解析异常,支付请求被调度至香港远程服务节点,网络延时高达200毫秒。当日下午2点开始,订单高峰期大量请求超时失败,支付接入率仅30%。经过一天的排查，终于确定了是第三方支付的DNS解析出现问题，临时固定域名，调用国内支付接口。但仍损失千万元订单手续费收入。

常规公司一般都会对第三方调用做监控，比如利用一些程序做周期访问来判断第三方服务是否正常，如果不正常即告警报错。这种方法固然能够起到一定作用，但是遇到案例中的问题还是比较麻烦，会先入为主的判断第三方服务是没有问题，但是实际业务程序在执行第三方调用和监控程序执行第三方调用并不是按照同一套DNS解析结果执行，这样带来的后果实际两者执行效果不一致。这种问题隐藏很深，很难发现

Originx的排障逻辑其实是一致的，就是当成下游调用去判断，并且得到真实的网络调用IP去判断，如果发现客户端调用异常的数据，然后还会同时判断网络质量是不是正常，最终给出结论，本质上和消息队列故障是一样的判断逻辑

用户仍然是从调用下游耗时长的故障初因切入，然后分析报告得到结论

Originx 并不期望做一个完整覆盖全栈的监控体系，而是利用北极星指标体系标准化找出故障方向，然后联动各种成熟的监控数据形成证据链条，并将各种数据融合在一个故障报告之中。更多信息请参考文章 Log | Metrics | Trace 的联动方式探讨

Oringinx 智能化实现全栈故障定位​

Originx 的设计目标是力争实现全栈故障种类的定位，自身的 eBPF 探针采集北极星排障指标，然后北极星排障指标引导到故障根因，Originx 的核心工作原理请参考下方网址或者或者扫描下方二维码 http://u6v.cn/6wIL7w

在已经识别出故障方向之后，利用各种成熟的开源监控作为数据来源，形成完整的证据链条，最终形成用户能够直接使用的故障根因报告。

下面我们将呈现如何利用 Originx 的功能实现应用程序故障的根因定位。

---

应用程序故障​

代码缺陷导致应用崩溃或错误​

○ 案例:2023 年双 11 期间,某汽车在线订单平台的 Tomcat 服务节点出现了严重的线程池耗尽问题。事发当天上午 10 点多,随着大促活动的用户流量激增,结算服务的响应时间明显下降。到中午时,大量来自北京地区的用户反馈在提交订单结算时,页面卡顿严重,部分直接超时失败。经过一天的紧张排查,最终发现是 Java 结算模块存在循环等待的死锁问题。该模块中存在太多的锁粒度,再加上连接池等配置不合理,并发压力下更容易发生死锁。临时解决方案是扩容结算服务的资源,并重启 Tomcat 释放线程。次日即行修复死锁代码,并持续优化相关模块的并发能力。这次事故虽然只持续了一天,但给用户造成了极差的下订体验

如果出现案例描述中 Tomcat 服务节点由于代码锁粒度太大出现了严重的线程池耗尽问题， Originx 轻松能够帮助用户分析出根因：

Originx 的解决之道：​

1、在 Originx 首页，Originx 的 SLO 告警就会针对 SLO 违约告警

2、同时会分析出可能的故障根因节点，当点击详情之后，每个节点的故障初因列表会被呈现出来

大概率是真实故障原因的疑似故障根因节点效果如下：（因为真正故障点的初因应该是一致的，或者有极少数的初因不一致的情况）

被级联影响的疑似故障根因节点效果如下：（Originx 会将 Trace 数据中突变变化前 3 的节点当成疑似根因节点，所以被级联影响的节点由于突变较大大概率会被当成疑似节点，而被级联影响的故障根因点大部分初因应该是下游节点耗时长，同时也可能存在因为采用池化调用框架导致出现隐藏锁而得到初因为锁的情况）

Originx 下个版本会呈现所有疑似根因的依赖关系，这样就能让人更好的理解谁是根因节点了，大概率是被依赖最深的节点，但是其他节点的根因报告不能完全忽略，最好能够也随机花几秒钟查看下其他根因报告

3、在确认故障根因节点之后，可以从故障根因节点的任意根因报告中查看根因报告详情

4、在故障报告的报告头部呈现的是故障概览，这里关联了 TraceId 以及发生的时间，如果有必要可以使用 TraceId 去关联分析 Tracing 数据

5、在故障报告左边栏中，确认故障传播链路，近似于下图，通过这个数据可以确认在此次报告中故障节点判定是否正确

6、在故障根因中，能够看到根因结论，在多份报告中看到同样的根因报告，这个时候其实可以采取应急手段来恢复业务了，针对本案例的情况：比如重启应用或者扩容，具体的应急策略需要根据公司的政策来确定，有些企业的业务是不能重启的，那就只能扩容，有些企业的资源是有限的，那就只能在对业务影响最小的时候重启

7、在故障报告中，以下的数据都是为了提供证据链条来确认故障报告的准确性

日志数据，关联了 Trace 在节点执行（也就是故障概览呈现的故障发生时间）时间段的日志数据

北极星指标（通过北极星指标，Originx 给出了异常幅度最大的异常方向，本案例的方向就是 Futex 也就是锁的方向）

由于北极星指标已经明确了异常方向是锁的方向，所以以下的证据链条会重点分析锁的方向。在 JVM 实现中，GC 也会采用内核 Futex 机制来实现线程等待，所以当分析 Futex 异常之时，Originx 会先确认此时是否发生了 GC，如果有 GC 发生，就会关联 GC 相关的数据

接下来 Originx 会关联程序锁的相关数据

在锁具体相关信息中，可以看到锁的执行堆栈

8、总结：通过锁的堆栈分析，可以确认程序出现了长时间的锁，这个时候可以进行 patch 快速修复，或者回滚代码至之前的版本规避锁的问题，或者扩容来人为提高并发

---

资源不足(CPU、内存、磁盘)​

○  案例: 2023 年 5 月 12 日，一家大型商业银行的新版网上银行系统在上线后不久遭遇了某些业务场景执行超时的错误。由于代码中存在一个未被发现的逻辑错误，导致在特定参数组合场景下，系统会重复执行某项业务逻辑，造成 CPU 使用率异常飙升。这种情况在测试环境中难以复现，因此未被及时发现。故障发生后，客户在进行转账和查询等操作时遇到了明显的延迟，严重时甚至导致服务不可用。银行紧急协调开发团队进行排查，在生产环境中利用 jstack 等工具查找 CPU 飙升的原因，最终在 4 小时内定位到了问题源头。通过快速发布补丁修复了 BUG，并重新部署了服务。此次事件导致银行损失了大量客户交易，并对其声誉造成了一定影响

如果出现案例描述中代码在某些参数特定组合场景下，导致代码会递归执行导致 CPU 飙高，人为分析是比较困难的，只能等待场景复现才能去故障现场使用 jstack 等命令分析 CPU 高的线程在干什么，Originx 轻松帮助用户分析出根因：

Originx 的解决之道：​

1、在 Originx 首页，Originx 的 SLO 告警就会针对 SLO 违约告警

2、同时会分析出可能的故障根因节点，当点击详情之后，每个节点的故障初因列表会被呈现出来

3、根据不同节点的初因情况来确认根因节点，在这种案例中根因节点会是以下几种情况：

根因节点的表现形式应该有“初因 CPU 耗时长”的报告，同时根据容器或者虚拟机的资源规格，如果资源规格较小，CPU 资源不足，就会出现很多请求“等待调度 CPU 耗时长”的初因表现

注意过滤掉其他受影响的级联节点，如果不确定节点是否是被级联影响，可以查看根因报告，稍微花个一分钟确认下

4 、在故障报告的报告头部呈现的是故障概览，这里关联了 TraceId 以及发生的时间，如果有必要可以使用 TraceId 去关联分析 Tracing 数据（具体截图可以参考之前的案例）

5、在故障报告左边栏中，确认故障传播链路，近似于下图，通过这个数据可以确认在此次报告中故障节点判定是否正确（具体截图可以参考之前的案例）

6、在故障根因中，能够看到根因结论，在多份报告中看到同样的根因报告，这个时候其实可以采取应急手段来恢复业务了，针对本案例的情况:

比如回滚或者扩容，具体的应急策略需要根据公司的政策来确定，有些企业的业务是不能回滚的，那就只能扩容

7、在故障报告中，以下的数据都是为了提供证据链条来确认故障报告的准确性

日志数据这里不再截图和之前案例类似

北极星指标（通过北极星指标，Originx 给出了异常幅度最大的异常方向，本截图的方向就是 CPU）

北极星指标（通过北极星指标，Originx 给出了异常幅度最大的异常方向，本截图方向就是 RunQ 方向，如果是 RunQ 方向，Originx 会同时查看 CPU 是否也突变了很大幅度， 如果 CPU 也突变了很大幅度，那说明 RunQ 的产生就是由于 CPU 消耗过高导致线程等待调度所致，如果 CPU 没有太大突变，说明是由于其它进程抢占 CPU 导致的调度等待）

如果是 RunQ 突变较大，还会关联 cpu_throuttled 相关指标来证明程序存在此问题

在 CPU 火焰图中可以看到哪些代码在循环执行

---

应用配置问题​

○  案例: 2023 年 3 月 15 日，一家领先的金融支付服务公司遭遇了支付处理延迟的问题。由于对高峰时段的实例数扩缩容配置人为操作错误，导致在线支付服务的实例数量未能满足既定需求。在随后的高峰交易时段，支付系统出现了严重的延迟，部分交易无法完成，影响了客户的支付体验，并导致公司损失了数百万的潜在交易额。经过紧急扩展服务实例并重新配置负载均衡策略，服务在 2 小时内逐步恢复。此次事件突显了容量规划在金融服务中的重要性，并促使公司加强了对服务容量和性能监控的投资

如果出现案例描述中实例数配置出错导致不足以应对高峰流量时， Originx 轻松能够帮助用户分析出根因：

Originx 的解决之道：​

1、在 Originx 首页，Originx 的 SLO 告警就会针对 SLO 违约告警

2、同时会分析出可能的故障根因节点，当点击详情之后，每个节点的故障初因列表会被呈现出来

3、根据不同节点的初因情况来确认根因节点，在这种案例中根因节点会是以下几种情况：

• 此种情况并不常见，但是应用如果是CPU密集型的，产生以下这个现象还是非常有可能的。由于实例配置错误，扛不住流量高峰，表现为整个微服务链路上的容量瓶颈节点的出现CPU资源不足的初因，因为每个请求都需要消耗较多的CPU，流量高峰导致其CPU不足，从而产生以下这种根因节点。排查思路和资源不足思路基本类似。

  

• 接下来讲的情况比较常见，对于绝大多数在线业务而言是IO密集型，所以当实例配置错误，扛不住流量高峰，表现和第一种情况不一致。表现出来是故障根因节点的上游节点出现很多调用下游的故障初因。主要原因是由于非CPU密集型不会消耗很多的CPU，但是其线程数量有限，每个线程都会被消耗在某些网络IO等待上，这里和锁场景又不一样，并不会产生很多代码锁。如果从APM视角来看就是发现客户端执行时间很长，服务端执行时间完全不匹配客户端执行时间的APM经典问题。如果从网络监控来看，能够看出故障节点有问题，但是并不清楚为什么有问题，也不知道该如何应急和复盘。本质的原因是故障节点由于配置错误，导致在流量高峰时所有的业务线程都被耗尽，但是由于Accept线程和IO线程仍然能够读取请求，只是找不到可用线程来处理业务，所以看到的现象是server端网络时间比Trace开始时间早一段时间。在Originx未来规划中，会接入线程满指标，这样结合线程满指标和下游节点耗时长更容易确认故障根因节点。

  

4、  在故障报告的报告头部呈现的是故障概览，这里关联了 TraceId 以及发生的时间，如果有必要可以使用 TraceId 去关联分析 Tracing 数据（具体截图可以参考之前案例）

5、在故障报告左边栏中，确认故障传播链路，近似于下图，通过这个数据可以确认在此次报告中故障节点判定是否正确（具体截图可以参考之前案例）

6、在故障根因中，能够看到根因结论，在多份报告中看到同样的根因报告，这个时候其实可以采取应急手段来恢复业务了，针对此种故障，恢复业务最好的手段就是扩容。这个故障其实还有其他几个可能，就是故障执行了长时间的 GC 导致线程不能执行，产生同样的现象。如何区分 GC 和线程慢？就是 GC 一般不会分布超过一分多钟，如果同样故障根因的故障报告分布在不同的时间段，那就明确了故障就是线程满

7、在故障报告中，以下的数据都是为了提供证据链条来确认故障报告的准确性

北极星指标（通过北极星指标，Originx 给出了异常幅度最大的异常方向，本截图的方向就是网络）

然后列出来所有的对外网络调用，这个网络调用是从内核层获取，可能会比 APM 看到的数据要多

针对最长的网络层面耗时，会对耗时进行分析，判断网络到底消耗在哪个网卡，我们可以看到标红的时间段说明了这段时间就是由于没有业务线程处理业务请求导致请求被 io 读取之后，而产生的额外时延

为了进一步证实不是由于网络导致的故障，会关联网络重传和丢包指标以证明网络没有问题

在开发过程中，经常会依赖各种库，可能是公共的、可能是公司内部的。这些依赖给我们开发带来了很多便利，避免了重复造轮子。但是这也导致程序中的很多部分彻底变成了黑盒，出现问题时更加难以定位和确定根因，使得很多时候既没有明确的排查方向，又要面对程序执行的黑盒，根本无从下手。

常常会遇到通过日志发现底层依赖库抛出了异常，例如依赖的某个库中抛出了网路连接的错误，通过日志看到产生了Connection Refused或着响应发生了超时，但通过 APM 工具发现网络和其他依赖服务都没有问题，只能看着错误信息干着急。

要不先求助依赖库的开发同学看看​

再求助负责基础设施的同事帮帮忙​

最后只能重新想办法，可办法又是什么呢？​

通过查看日志，我们定位到抛出异常的库。但是，我们并没有对这个库进行过任何变更，那么该如何进行接下来的排查呢？又需要哪些数据来佐证内心对问题的各种推测和猜想呢？这些推测和猜想又真的是正确的方向么？

需要明确方向，打开盲区​

一方面需要对 Trace 数据做更加深入和全面的分析及数据关联来明确排查方向，另一方面需要真正能够彻底消除盲区，真实还原程序执行过程。

Kindling-OriginX 通过分析和关联 Trace 、Log、Metrics 数据，补充并细化 trace-profiling 的指标，深入并明确问题方向；另一方面利用 eBPF 结合 trace-profiling 技术打开程序执行和系统调用盲区，从根本上彻底还原程序执行过程，不再有黑盒存在。

定位关键指标，关联相关数据​

依赖的相关代码中确实存在bug。

智能化给出可解释性的根因报告​

根据报告和数据发现网络设施确实存在波动，提供相关交接数据。

自动化 Tracing 关联分析异常数据，彻底打开全部盲区​

消除传统 Trace、Log、Metrics 数据中的盲区，找到盲区中的问题点，发现存在DNS耗时异常。 对于难以明确排查方向，无法定界的故障，Kindling-OriginX 快速组织和分析故障线索，通过自动化 Tracing 关联分析，以给出可解释的根因报告的方式，为这类故障提供可操作的排查方法。

在线系统的稳定性和可靠性是企业数字化转型成功的关键。然而，由于云环境和系统演进的复杂性，故障的发生几乎不可避免。本系列文章将对在线系统可能遇到的全栈故障进行分类，并结合网上的案例分析，对比常规分析诊断手段与Originx推理引擎是如何能够轻松找到全栈故障的根因。

本文为该系列的第一篇，主要介绍常见故障以及全栈故障定位的难点，后续系列文章将重点介绍如何使用Orginx高效定位故障。

常见故障分类与常规的分析定位手段​

应用程序故障​

代码缺陷导致应用崩溃或错误​

○ 案例:2023年双11期间,某汽车在线订单平台的Tomcat服务节点出现了严重的线程池耗尽问题。事发当天上午10点多,随着大促活动的用户流量激增,结算服务的响应时间明显下降。到中午时,大量来自北京地区的用户反馈在提交订单结算时,页面卡顿严重,部分直接超时失败。经过一天的紧张排查,最终发现是Java结算模块存在循环等待的死锁问题。该模块中存在太多的锁粒度,再加上连接池等配置不合理,并发压力下更容易发生死锁。临时解决方案是扩容结算服务的资源,并重启Tomcat释放线程。次日即行修复死锁代码,并持续优化相关模块的并发能力。这次事故虽然只持续了一天,但给用户造成了极差的下订体验。

○ 定位方法：人为分析日志，分析代码，对线程池进行监控，对代码定制化锁的监控（很难实现，没有办法覆盖所有场景）

资源不足(CPU、内存、磁盘)​

○ 案例:2023年5月12日，一家大型商业银行的新版网上银行系统在上线后不久遭遇了某些业务场景执行超时的错误。由于代码中存在一个未被发现的逻辑错误，导致在特定参数组合场景下，系统会重复执行某项业务逻辑，造成CPU使用率异常飙升。这种情况在测试环境中难以复现，因此未被及时发现。故障发生后，客户在进行转账和查询等操作时遇到了明显的延迟，严重时甚至导致服务不可用。银行紧急协调开发团队进行排查，在生产环境中利用jstack等工具查找CPU飙升的原因，最终在4小时内定位到了问题源头。通过快速发布补丁修复了BUG，并重新部署了服务。此次事件导致银行损失了大量客户交易，并对其声誉造成了一定影响。

○ 定位方法：借助java分析工具，在故障能复现的时机，人为分析问题

应用配置问题​

○ 案例: 2023年3月15日，一家领先的金融支付服务公司遭遇了支付处理延迟的问题。由于对高峰时段的实例数扩缩容配置人为操作错误，导致在线支付服务的实例数量未能满足既定需求。在随后的高峰交易时段，支付系统出现了严重的延迟，部分交易无法完成，影响了客户的支付体验，并导致公司损失了数百万的潜在交易额。经过紧急扩展服务实例并重新配置负载均衡策略，服务在2小时内逐步恢复。此次事件突显了容量规划在金融服务中的重要性，并促使公司加强了对服务容量和性能监控的投资。

○ 定位方法：人为分析日志，分析代码，结合资源使用指标（单纯依赖CPU、内存、磁盘指标很难发现实例不够）

---

数据库故障​

数据库连接问题​

○ 案例:2022年春节假期前最后一个工作日,某大型在线商城的数据库连接池曾出现被耗尽的严重故障。当天上午10点前后,随着流量的激增,商城首页以及各大类目页的查询请求突然出现大量超时和失败。SRE在慌乱中排查了30分钟，最终确定是数据库连接池的问题，由于促销引起了流量波动，而数据库连接池配置仍是原来配置并不足以支撑大流量,可用连接资源在高峰时段几乎被同时耗尽所致。

○ 定位方法：建立数据库连接池监控关键指标

性能瓶颈(锁、查询等)​

○ 2022年8月20日,某知名在线旅游预订平台出现数据库死锁导致机票预订业务中断数小时。高峰期时大量并发订单涌入,引发系统内部事务互相等待访问同一资源,造成死锁并耗尽连接池。经过大面积业务重启，瘫痪2小时之后才恢复。事后,该平台对业务代码进行重构优化, 从根本解决死锁风险。此次事故造成约2000万元订单收入损失。

○ 定位方法：建立数据库监控，建立死锁监控找到初始SQL语句的应用实例

网络故障​

网络连接中断、延迟或丢包​

○ 案例：2023年4月,某互联网金融云平台因内部容器云平台的COREDNS服务器群集发生异常,导致整个私有云内的核心交易系统无法正常解析内部服务地址。在接下来的3个小时内,平台的放贷、风控等多个交易系统出现大面积延迟和连接中断,账户查询、委托下单等关键业务无法正常使用。据初步统计,这次故障给金融机构带来的直接经济损失高达数亿元人民币。最终通过手动配置绕过DNS解析,临时恢复关键系统连接,但整体恢复所需时间超过10个小时。事后分析发现,DNS集群全军覆没是由于COREDNS升级之后的bug导致，但是没有完善的监控导致故障发现严重滞后。

○ 定位方法：对应用日志和网络流量做监控，单独定制DNS解析关键指标

网络配置错误​

○ 案例:2022年12月,世界杯决赛期间,某大型视频直播平台由于网络设备配置问题，导致导致网络丢包比例较大,数百万在线用户观看比赛直播受到严重影响,画面频频卡顿中断。该故障持续近2小时,给平台带来了广告收益损失,也影响了品牌声誉。经过紧急处理和优化,网络质量逐步恢复,但已错过了决赛最关键时段。

○ 定位方法：网络流量监控，对网络交换机、路由器建立监控体系

---

缓存故障​

缓存命中率下降​

○ 案例:2023年6月8日早高峰,某知名新闻平台首页及文章详情页出现加载延迟、频繁超时。原因是缓存服务配置错误导致数据过早过期,高流量下未能及时刷新,与数据库产生数据不一致。经紧急调整缓存策略,禁用部分过期机制并扩容缓存集群,系统逐步恢复。但此次事故影响约200万访问,广告收益损失近百万元。

○ 定位方法：建立APM监控体系，检查Trace的缓存访问次数和延时数据

消息队列故障​

消息堆积或消费者延迟​

○案例:2023年5月15日,某知名电商平台消息中间件所在一台服务器磁盘出现坏道,导致消息写入延迟超10秒。高峰期部分订单消息阻塞,下游服务处理速度骤降80%,造成大量订单挤压及库存操作失败。由于该故障出现较少，SRE专家没有经验，排查期很长，长达1小时才排查出有问题的消息中间件实例，最后经磁盘热插拔修复坏道、调大消息队列容量等应急措施,系统逐步恢复。

○ 定位方法:建立APM监控体系 队列监控、人为分析日志

外部依赖故障​

下游第三方服务调用延迟或失败​

○案例:2023年7月6日,某金融科技公司接入第三方支付平台时,遭遇DNS故障导致解析异常,支付请求被调度至香港远程服务节点,网络延时高达200毫秒。当日下午2点开始,订单高峰期大量请求超时失败,支付接入率仅30%。经过一天的排查，终于确定了是第三方支付的DNS解析出现问题，临时固定域名，调用国内支付接口。但仍损失千万元订单手续费收入。

○ 定位方法: 建立APM监控体系，同时在日志中建立关键指标

基础架构故障​

硬件故障(服务器、存储、网络设备)​

○案例:2022年6月18日,618购物节期间, 某电商北京西单数据中心两台机架服务器主板同时发生故障,导致一个重要的订单系统服务中断。受影响的约6000名用户在下单支付环节遭遇失败,由于这个服务与商品库存管理直接相连,错过这个高峰期将可能导致损失数亿元营收。经过5小时的故障排查和系统切换,终于恢复正常。此次事故再次凸显了硬件冗余以及容灾能力对于电商业务的重要性。

○ 定位方法：硬件监控体系的建设

系统软件故障(操作系统、虚拟化层、软负载)​

○案例：2023年3月,某热门视频直播平台在一场体育赛事直播过程中,由于负载均衡器组件发生故障,无法正确分发流量至下游转码服务器集群,导致部分转码节点超负荷宕机。此次事故造成大量用户无法观看直播画面,持续约2小时。经过现场工程师的快速响应和临时调度,负载得以重新分配,服务逐步恢复。但由于高峰期直播中断,给平台带来了可观经济损失和品牌声誉影响。事后分析发现,除了流量突发之外,负载均衡器在高压力下表现异常也是导致故障的重要原因。

○ 定位方法：研究中间件负载均衡器的指标体系，构建软负载的监控指标体系

---

覆盖全栈的监控体系建设和使用难度都很高​

假设我们有能力建设一套统一的全栈监控体系和运维大数据平台，但对使用者而言，全栈系统仍存在以下两个主要难点：

使用难度高​

数据量与信息过载： 在云环境下，监控系统的数据生成速度和体量是巨大的。这不仅涉及到数据的海量收集，更在于如何从这些数据中迅速提取出真正有价值的信息。用户面临的挑战是，要在不断涌入的数据流中，识别哪些是关键性能指标的异常，哪些是日常波动的“噪声”。信息过载不仅仅是技术问题，它还可能导致决策迟滞，增加操作复杂性，甚至可能掩盖真正的系统问题。

人员技能与知识要求： 全栈监控体系要求使用者不仅要对单一技术有深入了解，还要对整个技术栈有全面的认识。在技术迭代迅速的今天，要求团队成员不断学习新技术、新工具，并能够将这些知识应用于问题的诊断和解决中。这种跨领域的知识要求对人才的选拔和培养提出了更高的标准，同时也增加了团队管理的难度。

团队协作难： 在故障排查的时候，全栈的监控体系不同模块可能由不同团队或个人管理维护，比如网络团队、硬件团队、应用团队等。但是，由于噪声的存在，不同人对故障可能有不同理解，容易出现相互推诿的情况，导致故障排查难以找到真凶。

建设难度高​

实际上，建设统一的全栈监控体系也是很难的，主要难点体现在：

数据存储与管理的现实性： 期望一个单一的存储系统能够无缝地处理所有类型的可观测性数据（如日志、指标、追踪等）是不现实的。每种数据类型都有其特定的存储需求和访问模式，这就要求存储解决方案必须具备高度的可扩展性和灵活性。同时，数据的生命周期管理、安全性和合规性也是需要重点考虑的因素。

技术整合的持续性： 技术的不断演进要求监控系统能够适应新的工具和服务。这不仅仅是一个技术问题，更涉及到组织的战略规划和资源分配。随着新组件的引入，现有的监控架构可能需要不断地调整和优化，以保持其有效性和相关性。这个过程需要持续的投入，包括时间、资金以及专业知识。

经常听大家讲到在业务平峰期间一切正常，但当并发上升时用户端延时上升，体验急剧下降，往往这时候是由于应用锁导致。例如用户端访问时延是3s，数据库访问耗时500ms，而数据库索引和慢请求也都已优化，那么其他的2.5s到底是消耗在哪里？如果这其中的体验差距是由锁导致，那么又该如何快速定位这些锁，并将他们消除呢？

一方面受制于现有可观测性工具能力的限制，我们并不能有效地发现然后将其解决，另一方面传统的压测方法也并不能完美复刻生产环境的全部真实情。对于这些并发上升导致的问题，以及应用中看不见的锁，Kindling-OriginX 提出新的解决方法。

历史经验不准​

实际工作中往往习惯于使用个人历史经验判断是哪些服务出现故障，哪些应用容易出现锁，微服务架构下，应用缩容扩容，应用实例数的不同，相同的问题常常表现出不同的现象。这就导致使用历史经验判断并不能有效的找到问题。

Kindling-OriginX 能够快速给出全部异常节点的根因报告，同时报告已给出分析结论，不论问题表现的现象如何，用户都能够快速简单的进行统一分析。例如下图的拓扑结构中，同样的性能问题，因为每个节点的实例数的不同，都会导致表现出不同的现象。Kindling-OriginX 已经分别对报告做了聚合，对数据做了分析，用户只需要简单查阅报告即可。

无法找到锁在哪里​

实际生产环境中，一方面不可能事无巨细将应用所有变化都记录在日志中，另一方面很多数据也无法直接进行观测得到。往往知道应用里有锁，但是根本没有有效手段去找到锁在哪里。

Kindling-OriginX 通过实时监控和深度分析，快速识别性能瓶颈的同时，对每一个慢请求从系统调用级别进行拆解分析，究竟是GC、CPU等待、或是代码质量问题一目了然。

例如在下图示例中，futex耗时远大于历史基线值(futex是一种用于用户空间应用程序的通用同步机制，这里简单起见可以将其理解为一种锁机制)，再结合自动化GC关联分析，得出故障根因是有锁，且该锁是由于系统发生GC导致

人工分析不可行​

实际生产环境中，时时刻刻产生大量的 Trace 数据，要从这些大量的低价值数据中找出问题的根源，需要耗费大量时间进行人工分析，几乎不可能通过人工的方式找到关键数据。这不仅增加了工作负担，而且没有任何时效性可言。

Kindling-OriginX 通过异常占比与报告收敛的方式进行数据聚合，即使在大量 Trace 数据的情况下，也能对数据情况一目了然，快速找到所关心的数据。

干扰数据导致无法找到锁​

系统整体性能急剧下降时，所有机器往往都处于高负载状态，越多的连接也会导致CPU需要处理的上下文切换越多，内存对象频繁的创建和释放也可能会导致出现因垃圾收集（GC）造成的延迟。这些干扰信号都可能会导致真正的问题被掩盖。

Kindling-OriginX 针对干扰数据多的问题，一方面将报告数据收敛聚合，避免数据过多造成的干扰，另一方面报告中直接给出根因结论，只需快速查阅就能得到结论，无需再进行人工分析和有效性判别。

传统的可观测性工具在面对并发请求中的锁时无法提供有效的定位方式和解决方案，个人历史经验的误判，海量数据的分析、噪声信号的干扰，以及在动态复杂环境下的有效诊断，都要求更先进的技术和方法。Kindling-OriginX 提供全新的自动化、智能化关联分析 Log、Metrics、Trace 数据解决方案，通过 eBPF 和TraceProfiling 技术还原每一次请求过程，精准定位分析并发上升时应用中的各类问题。

DeepFlow 是基于 eBPF 的可观测性开源项目，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 采集了精细的链路追踪数据和网络、应用性能指标，其在网络路径上的全链路覆盖能力和丰富的 TCP 性能指标能够为专业用户和网络领域专家提供充足的排障定界支撑。

Kindling-OriginX 是一款故障根因推导产品，目标是提供给用户一个可解释的故障根因报告，让用户能够直接了解故障根因，并附有根因的推理过程以便验证根因的准确性。网络故障是故障当中比较难以简单解释的，仅仅告知用户哪段网络有问题是不够的，用户需要更多指标以及图解，才能帮助用户更好的理解网络到底发生了什么故障，以及发生在哪个环节。

本文介绍 Kindling-OriginX 通过结合 DeepFlow 完备的网络数据能力，自动化生成可解释的故障根因报告。

soma-chaos模拟网络故障​

• 针对seat-service注入200ms延时的网络模拟故障。
• 接下来我们先使用 DeepFlow 来识别200ms的网络故障，并做出相应的action。

人工最简化排障过程​

步骤一：利用Trace系统缩小范围​

在微服务场景中，某个接口突然慢了，排障的第一步骤应该是看Tracing系统，找到Trace慢在哪个环节，以及慢的具体表现是什么。

用户通过Tracing系统能够找到具体的Trace，通过分析Trace能够发现seat-service执行时间很长，同时出现了一条非常长的config-service调用，但是config-service执行不慢。这个时候需要联动网络指标，来定位网络问题。

步骤二：利用DeepFlow火焰图确定故障发生在哪段网络​

将故障代表traceid的输入DeepFlow在火焰图中，找到Trace在网络层面上的表现，然后深入分析这个火焰图，如果对火焰图比较了解，同时有具备网络知识的专家经验，是能够根据火焰图人为分析出：这个故障应该是发生在调用者也就是seat-service上，而且问题是发生了syscall到网卡的时间段，也就是容器网络时段出了问题（和故障注入是吻合的）。

步骤三：确定容器网络到底什么网络指标异常​

根据故障排查经验，用户需要查看seat-service与config-service的pod的网络指标。这个时候用户需要跳转至DeepFlow的Pod级别的网络指标页面。通过该页面，用户能够查看出建连有200ms的延时突变以及RTT指标有突变。

步骤四：排除可能的干扰因素​

根据经验，宿主机的CPU被打满和带宽被占满之时，虚拟网络也会出现丢包和时延，所以要排查当时seat-service与config-service所在node的CPU以及node级别的带宽，确保Node级别资源没有饱和。

通过k8s命令确认了两个pod所在的node节点，然后去DeepFlow的node指标监控页面查看相应指标，发现node的bps,pps等指标均在合理范围内。

由于node级别的网络指标没有出现明显异常，最终确定是seat-service的pod级别rtt指标异常。

人工排障总结​

经过一系列的排查过程，最终用户是能够排查出故障的，但是对用户有以下要求：

• 网络知识非常丰富
• 深入理解网络火焰图
• 熟练使用相关工具

---

Kindling-OriginX 如何结合 DeepFlow 指标，生产可解释的故障报告​

Kindling-OriginX 针对不同的用户需求和使用场景，Kindling-OriginX 对 DeepFlow 的数据进行了加工呈现。

类比人工最简化排障过程，利用 Kindling-OriginX 的排障过程如下：

针对每一条 Tracing 自动化分析​

针对此时的故障，自动化分析每条Trace，并按照故障节点对所列的Trace进行归集。Travel-service是由于级联故障导致的，本文不重点论述级联故障，如果有兴趣可以参考微服务级联故障该如何处理。

Review故障节点为seat-service的故障根报告​

故障根因结论：对于子请求10.244.1.254:50332->10.244.5.79:15679 rtt指标出现200ms左右的延时

故障的推理验证​

由于Kindling-OriginX 已经识别出是seat-service调用config-service的网络有问题，所以不用完全把 DeepFlow 的火焰图所有数据呈现给用户，只需要与 DeepFlow 对接，仅仅拿到seat-service调用config-service那段网络调用的相关数据即可。

利用 DeepFlow 的seat-service调用config-service数据自动分析出了客户端pod的容器网络出现了201ms的延时

Kindling-OriginX 会模拟专家分析经验，进一步关联DeepFlow的重传指标与RTT指标，从而确定到底是什么原因导致了seat-service调用config-service出现了延时的现象。

Kindling-OriginX 还会集成node的CPU利用率以及带宽指标，排除干扰因素。

Kindling-OriginX 将整个故障推理都在一页报告中完成，并且每个数据来源都是可信可查的。

---

总结​

Kindling-OriginX 与 DeepFlow 都使用了 eBPF 技术，立求在不同的场景中为不同需求的用户提供灵活高效解决方案，也期待未来能看到国内有更多能力互补产品的出现。

DeepFlow 能提供非常完备的全链路网络基础数据，能够让云原生应用具有深度可观测性，对于排查网络问题非常有用。

Kindling-OriginX 是利用eBPF采集排障北极星指标、AI算法和专家经验构建故障推理引擎，给用户提供可解释的根因报告。

本系列文章将以云原生环境下分布式系统的不同类型故障入手，从真实系统出发，分别以不同类型的故障为例，对故障根因报告进行介绍和解读。

本篇将通过实际案例对故障根因报告进行解读。将会使用开源模拟故障案例集系统 soma-chaos 作为故障注入平台，在 Kindling-OriginX 在线Demo上进行故障报告的解读，可以通过点击阅读全文进入 Kindling-OriginX 官方网站，实际体验故障注入和 Kindling-OriginX 的故障根因推理能力。

报告解读​

• 在 ts-order-service 中注入故障：运行额外任务抢占Pod可用的CPU资源。

  注入完成后稍等片刻，进入 Kindling-OriginX 的「服务健康检测诊断」页面，在「SLO实时异常检测」Tab页下我们可以看到 ts-order-service 涉及的服务入口出现 SLO 告警。

• 在这里可以看到目前异常根因节点占比 ts-order-service 和 ts-seat-service 各占一半，他们都处于报警服务入口调用链路中。具体情况我们通过诊断报告详细展开。

  进入故障列表后也可以看到，这里分别有ts-seat-service和ts-order-service两个节点的多份故障报告，同时已经做了聚合。 点击ts-seat-service的TraceID后进入该节点最新的故障报告。一份故障根因诊断报告有部分内容及多种相关Log、Trace、Metrics数据聚合分析而成，这里分别简单介绍。

• 诊断报告概要。包括TraceID、故障发生时间、请求耗时、耗时对比信息等基本信息。

• 单次调用链路信息。故障链路的调用详细信息及耗时信息。

• 故障根因。即该故障报告的最终结论信息及建议处置方法。该报告显示故障根因并不在 ts-seat-service 处，判定根因节点在下游服务处。接下来在对报告中关联的各类指标介绍过程中简要说明为什么会得到这个故障根因结论。

• 故障节点分析。报告中会对响应时间与历史基线进行比对，同时自动关联异常时间段的日志信息，无需再去通过其他手段查找。

• 接口执行耗时分析。这部分报告会对本次调用的北极星排障指标与历史基线值进行比对。主要包括CPU时间、网络时间、等待时间、其他时间（主要为存储时间等）。这里可以看到本次调用耗时最长的是网络时间 183.35ms，而且远超历史基线值。分析到这里往往会认为该服务可能存在网络问题。接下来我们对该指标继续下钻，对网络层面的指标进行更加深入地钻取。

• 对外调用具体信息。

• 请求网络耗时详细分析。这部分报告针对网络指标进行了更加详细的拆分和数据钻取，对广义上的网络耗时进行的更细致的分析，为判定网络是否出现问题提供更有说服力的证据。

• 网络质量指标。同时 Kindling-OriginX 会对整体的网络质量进行分析，即结合分段的网络时间和网络质量来综合判定网络耗时长是由于网络问题还是由于其他问题导致。所以在本例中分析后得出的故障根因结论为下游服务可能出现问题

• 接下来继续分析ts-order-service的故障根因报告。同样打开一份ts-order-service的诊断报告。故障根因显示：Runq耗时高，存在CPU抢占。从接口执行耗时分析中也可以看到，runq耗时占比最大，耗时180.27ms。根据这份报告，先来解释下什么是runq。

  runq(Run Queue Latency) 是一项描述操作系统性能、稳定性的重要指标，它描述了线程从进入就绪态到运行态的等待时间。CPU runqueue是一个表示等待CPU时间的概念。它是一个系统的活动队列，用于存储正在等待CPU资源的进程。当一个进程请求CPU资源时，它会被添加runqueue，等待CPU分配时间片。

  

• 结合runq的定义和 Kindling-OriginX 给出的根因报告，我们可以得到的结论是ts-order-service节点 CPU资源不足。

  到目前为止，报告解读完成，目前根据得到故障报告可以得到两个结论，分别是：

  1. ts-seat-service 网络指标正常，但网络耗时高，可能为下游节点故障。

  2. ts-order-service CPU资源不足。

级联故障处理​

• 在微服务系统中，任何单一故障往往都会以级联故障的形式表现出来，在该例子中即为ts-seat-service 和 ts-order-service 都发生了故障。从调用链路图中可以看到，ts-seat-service 是ts-order-service的上游节点。结合目前的结论和调用链路图，可以判定出ts-seat-service的调用慢非常有可能是由于ts-order-service慢导致的，根据级联故障处置优先级原则，应当优先解决被依赖节点的故障及ts-order-service。

  

• 在 ts-order-service 的故障根因报告中显示「Runq耗时高，存在CPU抢占」即表明该节点CPU资源不足，执行业务过程中耗费了大量的时间等待CPU资源。即CPU资源被我们注入的故障「运行额外任务抢占Pod可用的CPU资源」所抢占，导致链路中的请求在此处产生大量的等待，所以同时也会看到ts-seat-service的网络调用变慢，因为ts-seat-service的下游服务有锁。

小结​

故障根因报告在 Kindling-OriginX 中扮演着重要的角色，它综合分析和展示了各种分散的Log、Trace、Metrics数据，结合专家经验自动完成关联聚合，避免了可能的信息断片和数据交叉误解，真正做到了从表面现象到深层次原因的逐步剖析。通过直观的报告展示方式，以全新的思路为故障排查定位以及故障根因的确定提供更加高效和便捷的解决方案，为实现分钟级定位级联故障，落地 1-5-10 故障响应机制提供一条可行之路。

已经使用很多可观测性工具，排障为什么仍然难？​

在 Google 提出的SRE理念中，依据运维黄金指标是容易判断业务正常与否的，但是业务异常了，如何找到根因却是当前比较艰难的任务。

对于为什么排障难，不同角度能够得到不同的结论。本文主要从技术角度来谈谈为什么排障这么难？

各种可观测性工具 Traces、Metrics、Logging 的使用对于排查简单的问题确实比较有用，依据专家经验是能够做到快速排除故障的。

现在比较棘手的难题是出现一些级联的故障，也就是当业务出现异常的时候，各种异于平常的指标告警很多，即便在专家在场的情况下，依次排查每个告警仍然需要消耗非常多的时间。特别是在现代服务系统架构中，拓扑结构复杂，各服务间互相依赖，同时系统中存在着各类中间件，这些都使得大型业务系统中的故障往往都表现为级联故障，而且更加难以快速定位排障，在这种情况下，想要落地 1-5-10 是非常难的。

传统运维观念中为什么要设置不同种类的告警？​

很多告警都是在踩坑中得到的经验教训，当业务异常之时，如果没有告警也就没有线索，不知道该往哪个方向排查。所以在传统排障理念中，告警提供了排障线索。

随着业务复杂化，踩得坑越来越多，告警规则以及各种类型的告警也变得越来越多。 在这种前提发展之下，实际生产中就会陷入左右为难的困境，不设置告警就没有了线索，或者缺失线索。但是告警过多又会带来很多干扰，产生告警风暴、埋没根因等问题，同时在一定程度上也会导致 OnCall 人员麻痹大意。那么这种困境该如何解决呢，是不是存在更加科学有效的方法？

Kindling-OriginX 创新提出仅仅依赖API SLO违约告警​

SLO 违约告警其本质是依赖于 Google 提出的运维黄金指标来判断业务是否正常，如果业务不正常了，SLO 也就产生违约了。 Kindling-OriginX 能够不依赖于其它的告警，是因为 Kindling-OriginX 认为不管何种故障，最终都会影响到业务体验上，例如用户的访问请求等。如果任何业务都没有受有影响，即任意访问请求都没有变慢也没有出现任何错误和异常，那这个故障为什么能称之为故障呢？Kindling-OriginX 的核心能力是针对每次请求的故障trace，能够直接给出故障根因报告，在这种能力加持下，也就可以不用配置种类繁多的告警了。

面对棘手的级联故障，Kindling-OriginX 如何处理​

面对棘手的级联故障，从本质来讲其实有两种优化手段

• 通过算法判断出故障线索之间的潜在依赖关系，从而找到故障的根因，这也是传统 AIOps 的思路。
• 重新组织故障线索，加快每个故障线索的分析，一分钟将所有故障线索都分析出结论。

Kindling-OriginX 选择了第二种方式来解决棘手的级联故障，通过trace来组织故障线索，每个故障trace都直接给出当前故障trace根因报告。

为了能够说明问题，这里以 soma-chaos 案例为例，通过注入一个网络故障后整个业务系统的变化分步作一具体说明。

1. 对 routes service 注入网络故障。
2. routes service 响应变慢。
3. travel service 响应变慢，且比 routes service 更慢
4. 初步走查发现大量请求在 travel service 处等待。

通过对故障现场的初步分析，我们可以得到两个线索

1. travel service 响应变慢，同时大部分请求在等待
2. routes service 响应变慢

通过对故障现场的数据观察和简单分析，得到了两个线索，但仍旧处于无从下手的阶段，往往需要更多的数据进行分析，或者需要有更丰富排障经验的专家来提供思路和排查方向。下面再看看 Kindling-OriginX 的解决方法。

对于这个故障，Kindling-OriginX 对于 travel service 的慢请求和 routes service 的慢请求都会分别直接给出根因报告，travel service 慢的根因是锁的时间很长，routes service 慢的根因是网络故障。

接下来不用再花费精力分析为什么 travel service 慢以及 routes service 慢，因为每个线索都已经快速的拿到了结论。接下来只需要根据结论来进行方案的研判或启动对应的应急预案即可以最快的速度进行业务的恢复。

在传统的排障方法中，很可能处置人员的注意力会被 travel service 的锁故障分散，甚至认为可能是根因，从而花费大量的时间和精力来分析和处理 travel service 的故障，但是却又不能精准快速定位，只能通过重启扩容等方案来进行穷举，浪费大量人力物力却也没能使业务快速回复。

Kindling-OriginX 通过对每个故障节点都直接快速给出结论，在排查级联故障之时，只需要遵循以下原则即可：

• 被依赖的故障根因节点和基础设施故障（CPU、网络、存储）优先解决

单个服务发生故障，有可能导致故障沿着调用链路，扩散至多个上游服务，进而可能会导致多个服务均产生不同的故障现象，这就是典型的级联故障。在级联故障中，常常会被复杂多变的故障现象所误导，进而选择了错误的排查方向导致不可能及时完成排障。面对棘手的级联故障，究竟该怎么办？

什么是级联故障​

这里以一个例子来展示级联故障。在如下所示的服务调用结构中，对 ts-route-service 服务注入故障。之后受多种因素的影响，在 ts-route-service 的上游节点甚至旁路节点都出现不同的程度的故障现象，这就是典型的级联故障在实际系统中的现象。

为什么级联故障难以处置​

这里继续以前文的系统为例，试试看能否找到故障。

该如何开始？​

打开 Skywalking，筛选持续时间在 500ms - 10000ms 之间的近10分钟的请求数据，可以看到有667页近 10,000 条数据，这还是在并发量不大的情况下，如果稍有并发量这个数字更是难以想象，这么多 Trace 数据中究竟哪些有问题？哪些又能对我们定位帮助有帮助？该从哪些 Trace 数据着手开始分析？还没开始解决问题，就已经又得到了一堆的问题。

既然看似都有问题，那就先随机选择几条 Trace 数据，抓紧时间开始排障。

下面这条数据看上去是 ts-travel-service 有问题。

接下来这条看上去也是 ts-travel-service 出现了故障。

再打开一条显示 ts-travel-service 和 ts-basic-service 调用时间很长。

看到这里一头雾水就暂且认为故障发生在 ts-travel-service 或 ts-basic-service 。

该如何选择，选择是否完备？​

通过对 Trace 数据的分析，大致定位问题原因是 ts-travel-service 或 ts-basic-service 出现故障，导致链路在 ts-route-plan-service 调用下游服务时候出现问题。那么这两个服务该如何选择先处理哪个？系统中当前只有这两个服务出现了故障？是不是有可能两个服务都出现了故障？分析到这里我们得到的是更多的疑问。可事实上，在这里我们无论选择哪一个开始排查，都并不能找到造成问题的根因所在。实际情况中那只能重头来过，听天由命各凭本事了。

级联故障中一旦选错了排查方向就会导致做无用功，浪费了大量时间得到的是更多的疑问。传统工具的告警或 Trace 数据往往以单体应用的视角为出发点，更加容易分散注意力。大量的 Trace 数据反而会成为选择错误排查方向的诱因。在实际故障处置过程中往往变成无从下手，无法抉择。要不凭经验拍脑袋，要不就在所有人焦急的催促中不停地重启、穷举，希望能够撞个大运。

是否有更好的方法处理棘手的级联故障​

面对棘手的级联故障，从本质来讲其实有两种优化手段

• 通过算法判断出故障线索之间的潜在依赖关系，从而找到故障的根因，这也是传统 AIOps 的思路。
• 重新组织故障线索，加快每个故障线索的分析，一分钟将所有故障线索都分析出结论。

Kindling-OriginX 选择了第二种方式，通过 Trace 来组织故障线索，每个故障 Trace 都直接给出当前故障 Trace 根因报告。

重新组织故障线索​

Kindling-OriginX 以全局视角切入，一方面将出现 SLO 违约服务入口的故障节点全部列出，以节点比例进行统计根因占比，另一方面聚合故障报告数据。能够在排障开始阶段就能够对全局状态有所掌控，不再盲目查找数据。

直接给出故障根因​

Kindling-OriginX 在报告中已直接给出了故障根因，无需人工分析，即使像上图所示有多个节点的报告，也只需逐个打开查阅即可，而无需逐节点查找数据再进行人工分析。只需将全部故障节点报告逐个阅读后，统一判定即可，不用再苦于如何选择 Trace 数据进行排障。

标准化级联故障排障方式​

在复杂的级联故障中，通过 Kindling-OriginX 逐个查询全部故障报告后，结合排障优先级原则进行故障处置（被依赖的故障根因节点和基础设施故障「CPU、网络、存储」优先解决）即可。同时关联的各类 Trace、Log、Metrics 数据也为各职能团队进行定界与任务交接提供标准化的数据，这也能够使多团队协作排障有标准化的流程与依据。

Kindling-OriginX 提供了一种新的处理级联故障的思路和方法，快速组织和分析故障线索，给出根因报告，并根据优先级原则进行故障处理。这种方法可以加速故障定位，避免级联故障中排查方向错误，同时能够以标准化的流程进行级联故障的排查，真正的有机会去在实践中落地 1-5-10 故障响应机制。