故障根因报告解读之：CPU篇

云观秋毫

已于 2024-01-11 16:54:24 修改

阅读量922

点赞数 16

分类专栏：故障报告解读文章标签：云计算云原生网络

于 2024-01-11 11:02:17 首次发布

本文链接：https://blog.csdn.net/kindlingx/article/details/135508720

版权

故障报告解读专栏收录该内容

2 篇文章 0 订阅

订阅专栏

关于 Kindling-OriginX

Kindling-OriginX 通过其先进的技术，如 eBPF 和 TraceProfiling，不仅能够解决系统级故障，如网络或存储问题，还能有效地处理应用层面的故障。我们来具体看看它在不同层面上的故障定位能力：

系统级故障：Kindling-OriginX利用eBPF技术，可以访问和分析内核级指标。这对于诊断网络或存储等系统级问题至关重要，这些问题通常无法通过传统监控系统捕获。通过提供对内核行为的深入洞察，Kindling-OriginX非常适合识别和解决这类故障。

应用层面故障：Kindling-OriginX中的TraceProfiling技术特别适用于应用层的故障排查。它能精确捕获应用中的每次调用，通过将线程执行与追踪系统连接起来，完整地还原用户请求的执行过程。这一功能对于诊断应用层问题，例如特定请求的问题、性能瓶颈或代码执行错误，至关重要。通过将线程执行细节与应用行为相关联，Kindling-OriginX能够有效地定位应用层面的问题。

指标和日志的整合：Kindling-OriginX将各种来源的数据（包括指标和日志）进行聚合和分析，增强了其解决应用层面故障的能力。这种全面的视角允许进行更全面的分析，使其能够识别跨系统和应用层的复杂问题。

Kindling-OriginX不仅限于解决系统级故障。它采用了先进的方法，利用eBPF获得深入的系统洞察和TraceProfiling进行详细的应用层分析，使其能够有效地识别和解决系统和应用层的问题。通过整合各种数据类型，进一步支持其处理广泛故障的能力，使其成为复杂IT环境中故障诊断和解决的多功能工具。

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

本篇将通过实际案例对故障根因报告进行解读。将会使用开源模拟故障案例集系统 soma-chaos 作为故障注入平台，在 Kindling-OriginX 在线Demo上进行故障报告的解读，可以通过点击https://originx.kindlingx.com/进入 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 故障响应机制提供一条可行之路。