27 篇博文 含有标签「了解Kindling-OriginX」

运维的挑战与责任​

在数字化时代，运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能，还要快速响应并解决故障，以减少对业务的影响。在这种背景下，运维团队急需工具和技术，能够帮助他们提高效率，减轻负担。AIOps（人工智能运维）应运而生，旨在通过应用人工智能和机器学习技术来自动化监控、预测、优化和故障排除过程。

AIOps当前技术与输出​

AIOps核心功能包括事件聚合、异常检测、自动化根因分析等。这些技术能够帮助运维团队从海量的监控数据中快速识别问题，预测潜在故障，并自动化常见问题的解决过程。通过AIOps，许多组织已经显著提高了故障响应时间，减少了误报，优化了运维流程，提升了IT系统的整体可靠性和性能。

AIOps仍然存在挑战：故障根因与可观测性数据割裂​

尽管AIOps技术取得了显著进步，但在故障根因分析方面仍面临一个重大挑战：故障根因与可观测性数据（如日志、指标、追踪）之间的割裂。AIOps系统虽然能够推荐可能的故障根因，但往往难以直接将这些推荐与具体的可观测性数据紧密关联。这就要求运维人员依靠自己的经验和知识，在海量的数据中寻找证据来验证这些推荐，这一过程既耗时又容易出错。

Gartner 魔力象限中领先象限做到的效果​

Dynatrace 效果​

Dynatrace 的AI故障推理效果和介绍详情可参见 Dynatrace 官方网站。

从 Dynatrace 的视频中，如果发生了故障之后，AI推荐出AI根因之后，用户仍然需要使用根据 Visual resolution path 去从众多的Trace以及各种可观测性数据中筛选出证据来证明这个AI的推断。

Dynatrace 做到全球最牛的地方，就是能够将各种可观测性数据融为一体，并以时间线为维度还原故障现场，这个本质上还是人为分析，所谓的AI推荐，给出的是关键节点。

如果没有这个故障根因推荐，用户使用 Dynatrace 怎么做呢？仍然是围绕着故障时间点，利用 Dynatrace 的 Visual resolution path 人为分析故障根因。

结论：故障根因的推荐聊胜于无，还是需要人为在可观测性数据中分析找证据。

Datadog 效果​

Datadog 的 Watchdog RCA给出仍然是可能性，具体从可观测性中找证据来证明这点，仍然需要用户自己来做。

结论：故障根因的推荐聊胜于无，还是需要人为在可观测性数据中分析找证据。

可观测性盲区的存在导致AIOps的根因结论与可观测性数据存在割裂​

举例说明：Dynatrace 的根因例子为节点CPU利用率达到100%，其实绝大多数运维人员都能识别出100% CPU利用率是有问题的。但是如果CPU利用率是50%，这个时候人是很难判断程序是否会受到CPU供给瓶颈，需要额外提供更多的数据去判断CPU利用50%的时候，程序的执行是否会受到调度器的影响，这取决于很多因素，比如机器上需要调度的程序多少，CPU调度器排队的长度等，总而言之，可观测性数据存在盲区。

可观性数据由于存在盲区，导致人都很难根据可观测性数据推理出故障，只能根据事后的结论去关联出CPU利用率50%在某些场景下也是存在可能性导致故障根因的（资深运维人员在判断这两点的时候CPU利用率为50%，是故障根因也是需要非常深厚的经验）。

可观测性数据盲区更详细的介绍，请参考之前的文章。

• 可观测性工具的盲区与故障排查困局
• Log、Metrics、Trace的联动方式探讨

内核视角持续剖析解决AIOps的故障根因结论与可观测性的割裂问题​

在之前的文章介绍了可以使用内核视角下持续剖析，能够形成基于北极星指标的排障体系。可参见：内核视角下持续剖析 VS 代码视角下的持续剖析

基于这个标准化排障体系进行故障根因推导的时候，就能够同时自动化关联相关指标。比如如果发现网络时间很长，这个时候就可以关联网络相关性指标，必要时还可以同步 DeepFlow 等关键网络事件及数据，提供证据证明网络确实有问题。

业务可用性问题的快速诊断，历来是行业互联网公司面临的重大挑战，快手也不外如是。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

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

实际使用效果​

历史稳定性分布问题​

效果汇总​

在 Kubernetes 容量规划中，追求的是集群的稳定性和资源使用效率之间的平衡：

• 资源分配过多会造成浪费。
• 资源分配过少则会导致用户请求时延上升，影响集群的稳定性。

背景​

公众号之前翻译了一篇 Sysdig 的文章，Kubernetes 容量规划：如何合理设置集群资源介绍了如何设置合理的资源参数。

虽然按照那篇文章设置可以有一定的帮助，但仍然可能存在风险。本文将详细说明这些风险，并介绍如何通过北极星指标对 POD 的规格进行调整，以达到时延和资源的完美平衡。

Kubernetes 中的 POD CPU 规格参数​

在 Kubernetes 中，POD 的 CPU 规格主要包括以下两个参数：

• requests： POD 启动时请求的 CPU 资源量。Kubernetes 调度器会根据这个参数将 POD 调度到能够满足资源需求的节点上。

• limits： POD 运行时能够使用的最大 CPU 资源量。如果 POD 尝试使用超过这个限制的 CPU 资源，会被限制在定义的 limit 值内。

Kubernetes 中的现存指标​

要判断 POD 规格是否合适，需通过合适的指标来评估。当前 Kubernetes 中常见的 CPU 指标包括：

• CPU 利用率（container_cpu_usage_seconds_total）： 通过类似 PQL 语句获得：

irate(container_cpu_usage_seconds_total{namespace="XXXX", container="XXXX"}[5m])

该指标反映了 CPU 利用率。

• 系统负载：node_load1、node_load5、node_load15 表示系统在 1 分钟、5 分钟和 15 分钟内的平均负载。一般认为负载与 CPU 核数相当即可。

• CPU 节流（throttle）：container_cpu_cfs_throttled_seconds_total， 通过类似 PQL 语句获得：

irate(container_cpu_cfs_throttled_seconds_total{namespace="XXXX", container="XXXX"}[5m])

该指标表示容器由于 CPU 配额不足而被节流的 CPU 核心时间总量。

尽管这些指标对了解 CPU 资源使用情况有帮助，但各自存在局限性，难以单独作为唯一且关键的指标。

北极星指标的应用​

所谓北极星指标，是指唯一且最关键的指标。在 Kubernetes 中，该用哪个指标来衡量容器的 CPU 资源是否充足呢？

CPU 利用率指标的局限性​

CPU 利用率指标的主要局限性在于：

• 单一性： CPU 利用率反映了容器对 CPU 资源的需求和使用情况。如果利用率持续高企，可能表明容器需要更多的 CPU 资源。然而，仅凭这一指标无法全面反映系统的性能状态。
• 响应时间和性能： 需要考虑容器内应用的响应时间和性能。如果响应时间变长或性能下降，即使 CPU 利用率不高，也可能意味着 CPU 资源不足。
• 并发负载： 在高并发场景下，瞬时的负载高峰可能导致性能问题。CPU 利用率可能无法及时反映这些短期高峰负载的影响。

Load指标的局限性​

Load 指标代表有多少执行单元等待调度器执行，但它无法单独衡量 CPU 资源是否充足。

CPU节流指标的局限性​

container_cpu_cfs_throttled_seconds_total 指标用于衡量容器因 CPU 资源不足而遭受的 CPU 节流（throttling）。如果该指标的值不为零并且持续增加，通常意味着：

1. CPU 资源不足： 容器的 CPU 使用需求超出了为其分配的 CPU 配额，导致它无法获得足够的 CPU 时间来执行其任务。

2. 性能影响： CPU 节流可能会导致容器内应用的性能下降，因为它们没有足够的 CPU 时间来及时完成任务。

虽然该指标能够直接反映容器是否遭受 CPU 节流，但仅凭它来判断资源是否充足可能会忽略其他重要的性能指标和系统状态。即使 container_cpu_cfs_throttled_seconds_total 不增长，但如果 CPU 调度器队列很长，仍然可能出现 CPU 资源不足的情况。

北极星因果指标中的 CPU 调度耗时​

北极星因果指标中的 CPU 调度耗时能够反映出 CPU 节流和高负载下的 CPU 调度延时，包括以下几种情况：

• CPU 调度队列长： 当程序执行完数据库等网络操作后，如果CPU充分，应该被立马执行，但是当调度队列长时，就会产生等待被调度到 CPU 上的时间。

• CPU 节流： 代码执行时间片被执行完后，等待下一个调度周期才能被调度到 CPU 上执行的时间。

北极星因果指标中的 CPU 调度耗时能够反映出 CPU 节流和高负载下的 CPU 调度延时。只要该指标不高，即可说明容器的 CPU 资源是充分的；如果该指标高，则说明容器的 CPU 资源是不充分的。

通过准确监控和调整这些指标，可以实现 Kubernetes 集群的稳定可靠性和资源使用效率之间的最佳平衡。

北极星因果指标的CPU调度耗时实际用法举例​

Demo环境的route-service的CPU调度耗时异常修复过程​

在云观秋毫的Demo环境中，通过北极星因果指标巡检，发现route-service的CPU调度耗时较长，其90分位线经常超过10ms，甚至达到20ms左右。 此时指标已经说明了route-service的CPU资源不充分。

怎么解决呢？是不是直接去增加POD limit的设置呢？

POD规格调整原则一：如果发现CPU节流（throttling）时间高，才需要增加POD limit的配置​

通过查询route-service的CPU节流（throttling）指标，发现其CPU节流时间很少，几乎没有波动。这与route-service北极星因果指标中每次请求都有10ms左右情况不符合，说明北极星因果指标中的CPU调度耗时并不是由于CPU节流导致的，也就意味着提高POD limit无法解决问题。

那这种情况只能说明当时的CPU队列很长，当一次任务如数据库调用完成之后，程序需要重新调度到CPU上而产生了调度耗时。为了验证这点，我们继续查看下其CPU利用率指标和节点的Load指标。

CPU利用率显示其CPU资源是非常充足的，因为route-service所在机器的节点CPU核数为8核，load指标最高位7.13，也是符合预期的。 此时如果没有北极星因果指标，也不知道每次请求有这么高的CPU调度耗时，但是要优化性能，提高容量也就无从谈起了。

为了证明北极星因果指标的正确性，我们将route-service调度到另外一台机器上，在调度之前其load如下：

当调度完成之后，我们再次查看北极星因果指标，发现每次请求CPU调度耗时已经降低了很多，此时调度耗时在90分位线最高也只有8ms，绝大多数请求CPU调度耗时在4ms以下。

此时我们再去查看rout-service的相应延时，发现延时也有了显著的优化：可以看到平均延时在重新调度之前延时是普遍大于20ms的，而调整之后rout-service的延时已经没有高于20ms的了。

Demo环境的order-service的CPU调度耗时异常修复过程​

在云观秋毫的Demo环境中，通过北极星因果指标巡检，发现order-service的CPU调度耗时较长，其90分位线经常超过80ms，甚至达到90ms左右。 此时指标已经说明了order-service的CPU资源不充分。

根据POD规格调整原则一，先去查看容器的CPU节流指标，发现其节流时间确实很大，说明POD的规格Limit设置过小了。

如果只看CPU 利用率，其实还好，并不是一直很高，而是周期性飙高。

POD规格调整原则二：调整POD Limit设置之时，不需要翻倍的增加CPU核数，而是一个核增加完之后，观察数据，确保最省资源的方式满足业务需求​

当对order-service的limit增加之后，再看节流指标，此时节流已经很少发生了。

然后我们再看北极星因果指标中的每次请求CPU调度耗时指标，数据从原来的80-90ms 降到了1~2ms左右，甚至90分线最高值才5ms，说明其CPU现在是充分供应了。

最后我们再看看调整前后的时延对比，从调整之前的90分位线100ms降到了调整之后不到10ms左右。

利用北极星因果指标轻松识别POD运行的应用是CPU密集型还是IO密集型，并完成调度，保证应用的健康状态是最佳的​

在计算机知识中，大家都知道不同应用有着不同特征，典型的分类就是CPU密集型和IO密集型，但是我们怎么判断应用是IO密集型还是CPU密集型呢？绝大多数情况下大家是通过主观经验判断，缺少证据证明。

POD调度原则：根据POD应用类型来实现调度​

如果根据北极星因果指标中每次请求CPU执行时间超过了响应时间的一半，一般认为其应用为CPU密集型。 根据这个原则发现绝大多数在线业务都不属于CPU密集型，只有那些执行时间非常短的应用不到20ms的应用，其cpu时间才有可能超过一半。

所以调度原则简化成可以把响应时间短的应用和响应时间长的应用混合调度在一台机器上能够保证应用健康状态是最佳的。

可观测性三大支柱联动性不好​

曾经询问已经使用可观测性相关软件的用户群体，对于他们来说最需什么功能的时候，很多用户的反馈都是Trace、Metrics、Log三者的联动性不好，是未来想完善可观测性的重要方向。

业界有很多专家都在研究这个问题，但是体验效果似乎仍然不好，这里谈下我们的理解，抛砖引玉，欢迎更多的探讨。

Log、Metrics、Trace三者集成难题​

可观测性三大支柱集成难题主要因为以下几点​

缺乏标准与协议​

在opentelemetry没有成熟的2021之前，很多公司至少已经完成了统一日志的建立，Metrics的建立，Trace可能在最近两年逐步覆盖至所有业务系统，所以三大支柱在不同时期建设导致了三者没有办法按照日后成熟的opentelemetry协议进行很好的集成。

已有系统改造的成本大​

将三者打通的工程工作量比较大，有些公司是因为不同供应商配合起来比较困难，有些公司是则因为之前建设系统的人员流动，导致系统被动陷入维护状态。

三大支柱的互动逻辑复杂​

即便业务系统是新建立的，这个时候完全可以使用opentelmentry规范将三者数据在理论上做好集成的准备，但是三者的流畅的集成，仍然面临着不少的问题。

• 完美用户体验设计界面非常难：用户排障过程是没有标准化的，也就意味着用户在看到某现象的时候，比如某个指标异常，可能接下来想看当时节点的日志，也可能想看当时的trace数据，这就导致界面要灵活的设计非常复杂。国外datadog的解决方案就是将页面设计成了可观测性数据搜索平台，用户可以添加很多的过滤条件对数据进行过滤，从而快速找到相关数据。国内如果也这样做会导致用户一上来看到如此复杂的界面，不知道该如何着手去排查问题，很难落地。

• 不同背景用户述求不一样：可观测性数据是海量低价值的数据，界面上应该先呈现什么样有价值的数据很难权衡。不同的部门用户有自己的习惯，开发者最习惯看的是日志，不管是bug，还是系统故障，第一诉求就是看日志，因为这是开发者长期职业过程中形成的习惯，SRE可能会想先了解指标，并且根据自己的经验，配置不同的大盘，然后能够根据不同大盘一层层剖析。那能不能干脆分不同页面进行设计，比如有日志首页，指标首页，追踪首页等，现在很多公司确实就是这么做的，但是导致的问题也就是三者虽然在技术上能打通，但是使用体验上仍是割裂的。

• 在一定规模下，可观测性数据查询性能差：可观测性数据的海量低价值特性，导致查询数据很慢，大家一定碰到过查询ELK的日志转个几秒才出来，追踪也是转个几秒出来，Prometheus server还可能由于维度问题，不断重启等现象。在这种场景下，用户在探索三者数据的时候是非常崩溃的，体验非常不好。即便有天才的设计师完成了三大支柱很好的界面交互，但是这缓慢的查询体验会让完美界面交互的价值降到无。

Kindling-Originx提供了不一样的思路​

一种思路是加大资源投入，如果任何查询慢，就通过分布式扩资源的方式解决，然后期望业界有天才的设计师能够设计完美符合大部分用户习惯的界面交互设计。

Kindling-Originx认为可能还有另外一种方式可以解决此三者难以集成的问题。

Kindling-OriginX 提供了标准化的排障方式简化了用户体验设计​

在排障过程中，什么时候该看什么数据，已经根据专家经验在界面流程当中设计好了，排障的特异化需求就能被固化并同步下来。

Kindling-OriginX 提供了自动化智能化查询分析功能​

如果只有文档化的标准排障理论，没有通过机器自动化智能化分析故障，并将标准化排障过程当中所需的数据自动化关联查询出来，完全依赖人去落地标准化排障是非常难的。

Kindling-OrginX 智能化给出结论​

Kindling-Originx报告给出了故障根因结论，但并不是仅仅给出了故障根因而已，而是将故障的完整推导过程所需的log、metrics、trace都查询好了，并集成至故障报告当中，这样就不是临时再去查询log、metrics、trace。用户如果怀疑故障根因分析得不对，可以一次性针对故障所需数据做出结论性判断，再也不用因为某些数据查询慢而打断思路。

Kindling-OriginX 联动方式实例​

在 Kindling-OriginX 的故障根因报告中，已将 Log、Metrics、Trace 数据相关联后进行集成，并完成了故障根因的推导分析，具体可参见下面各类数据的实例。

链路数据Trace​

Trace数据中给出了本地调用的链路相关数据，以及各种耗时信息与历史基线的对比情况。

故障根因结论​

故障根因是故障报告的结论，是结合报告各类数据综合分析后得到的最终结果。

故障节点分析及相关日志​

Kindling-OriginX 会抽取出相关联时间段内的关键日志数据，以供查阅。

各类关联指标数据​

Kindling-OriginX 自动化关联了与故障相关的各类指标数据，如接口具体的执行耗时情况，runq、网络质量指标等数据， 既是推导的过程依据，又可方便进行统一的二次分析。

依赖故障指应用运行所依赖的环境包括网络、中间件、缓存故障导致应用出现故障。这部分故障的根因并不是应用代码的问题，但是其最终表现形式和应用代码故障表现形式类似，很难区分。本文重点呈现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 的核心工作原理请参考网址

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

下面我们将呈现如何利用 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 读取之后，而产生的额外时延

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

背景​

在现代应用开发中，链路追踪技术（Trace）扮演着至关重要的角色。它不仅帮助开发者监控和调试应用程序，还对性能优化提供了极大的支持。然而，在实际操作中，客户端与服务器端的数据时延不一致问题经常出现，这对业务流程和技术实施造成了显著的影响。本文将探讨这一问题的具体表现、根源以及它带来的挑战，并讨论如何有效地解决这些问题。

Trace 技术概述​

Trace 技术是一种监控和记录应用程序运行状态的方法，它可以帮助开发者了解程序在特定时间点的行为。通过 Trace，开发者可以获得请求路径、执行时间、关键代码函数执行细节等详细信息，这对于定位问题、监控系统性能以及进行后续的优化至关重要。Trace 技术在多种场景下都有应用，包括但不限于性能监控、故障诊断和系统调试。

Trace深入使用的挑战：客户端与服务器端时间不一致的表现​

只要深入使用过Trace的用户，一定会有这样的体验，Trace反映出客户端调用时间很长，但是Server端的执行很短。这会带来以下的问题

1. 归因错误

时间不一致会导致误导性的性能指标，使得开发和运维团队难以准确评估系统的真实性能表现。例如，如果客户端时间显著长于服务器端处理时间，可能错误地将问题归咎于服务器的处理能力，而实际上问题可能出在网络延迟或客户端处理上。

2. 浪费更多的人力成本

准确地定位问题源头变得更加困难。时间不一致可能掩盖了真正的性能瓶颈或错误所在，导致团队花费大量时间在错误的方向上进行调试和优化。

3. 数据准确性和信任度下降

长期的时间不一致问题可能会损害团队对 Trace 数据的信任度。如果分析和报告经常基于不准确的时间数据，团队可能会对使用这些数据做出的决策持怀疑态度，从而影响到决策制定的质量和速度。

造成数据不一致的原因​

为了能让Cient调用时间和Server执行时间不一致原因更容易理解，我们先理解下Trace数据是如何来的：Trace数据来源是通过拦截某些函数而获得，Trace数据本质上反映的是函数执行时间。

接下来让我们细化一次RPC函数调用的细节，从而分析可能造成故障的原因：

因为RPC的函数调用被封装成了本地函数调用，有些开发可能都不知道自己调用的函数其实是远程RPC调用，所以他们印象中的程序执行是这样的：client端执行RPC之后，Server端立马响应。

对网络有一定概念的开发，会认为rpc调用应该包含部分网络时间是如下图所示，server端开始时间比client端开始时间要晚，server端结束时间比client端结束要早。在这部分人的认知当中，一旦时延不一致，那就是网络的问题，但是网络很可能其实没有问题，请读者接着往下看。

另外如果从client角度来看，调用就是rpc封装的函数，这个函数的实现绝大多数是没有问题的，但是也可能出现以下这种情况：client端出现GC，或者DNS寻址出现问题，也就是问题出现在了认知盲区，不知道client可能会出现问题。

Server端实际执行过程如下图：

在一切正常的时候，图中紫色部分消耗的时间是非常少的，基本可以忽略。但是一旦可能出现故障，每个紫色框都可能是个故障原因。

可能原因如下：

• 内核处理网络连接： 半连接，全连接队列满，导致连接建立很长，通常在大并发流量的场景下出现。

• Tomcat容器耗尽可用业务线程： server端业务线程耗尽，通常在server端可能在雪崩中受到级联影响。

• 读网络请求： 如果网络质量出现问题，这段时间也会变长，还有网络带宽被打满的场景也会出现。

• 写网络请求： 如果网络质量出现问题，这段时间也会变长。还有网络带宽被打满也会出现。因为通常resposne是比较大的，这个时候如果client 与 server端的网络缓存配置不合理，出现网络full窗口或者0窗口也会出现问题。

• 任何在网络IO之前或者网络IO之后（Trace的拦截点位）可能的耗时操作。

挑战与问题​

希望以上的说明帮助大家理解了client 和 server端执行时间不一致的可能根因。要能分析这个client与server端的时延不一致问题，要具备以下条件

• 深入理解程序执行过程的专家

• 深入理解网络执行原理

• 构建了非常丰富的可观测性数据

这些能力的积累可不是短期就能积累起来的，但是Kindling-OriginX 自带专家经验，自动对接Trace、DeepFlow、Prometheus等可观测性数据，在需要看什么指标数据之时，提供故障相关指标帮助用户深入理解故障根因。

资深团队与前沿技术，携手云观秋毫迈向智能排障新篇章

云观秋毫 —— 开源创新引领eBPF技术，智能运维新纪元​

云观秋毫，汇聚了国内eBPF技术领域的顶尖人才，致力于将创新的Trace-profiling技术应用于IT运维，为企业带来革命性的全故障域综合排障解决方案，最终企业能够成功实现1-5-10落地。

技术专精，开源创新​

• 开源贡献：云观秋毫团队是国内知名eBPF开源项目Kindling的核心贡献者，展现了团队在eBPF技术领域的领导地位和专业实力。
• Trace-profiling技术：我们基于大神Brendan的TSA方法论独创的Trace-profiling技术，利用eBPF技术捕获程序执行的关键数据，为性能优化和故障诊断提供深度洞察。
• 北极星排障指标：通过对Trace-profiling数据分析，我们提炼出关键的北极星排障指标，为企业标准化、高效的故障排除提供指导。
• 智能排障流程：结合实时监控和智能算法，云观秋毫自动化诊断过程，极大提升运维效率和准确性。

开放合作，互补共赢​

• 技术社区：龙蜥社区系统运维联盟由清华、复旦、浙大、信通院、阿里云、浪潮、中兴、统信，云观秋毫、云杉网络、乘云科技作为首批联盟发起，联盟的宗旨是以推动系统运维技术进步、促进产学研合作为⽬的的⾮营利性组织。云观秋毫与复旦大学在联盟主要工作是构建故障案例集演示系统，这个故障案例集的主要目的是提供开源开放的故障案例集合，促成行业面对故障的时候能以统一的案例话术沟通，当前故障案例离真实环境还有一定距离，欢迎任何单位来贡献故障案例。
• 集成方案：我们秉承不重复造轮子的理念，积极使用成熟的开源社区方案，形成了覆盖全域故障综合排障解决方案。

资深团队，实战经验​

• eBPF落地经验丰富：云观秋毫团队凭借在eBPF技术领域的深厚积累，已成功助力网易、好未来等领先企业及工商银行、浦发银行、兴业银行、国泰君安、华泰证券等金融巨头实现eBPF技术落地，获得业界广泛认可与赞誉。
• 行业认可：团队的专业能力和创新技术在IT运维领域树立了良好的口碑，为云观秋毫的技术和服务提供了坚实的基础。

行动号召：​

选择云观秋毫，让我们的资深团队和创新技术助力您的IT运维，共同开启智能排障的新篇章。

• 故障推理引擎加持下的告警理念转变
• 什么是eBPF
• 什么是根因分析
• 什么是 Trace Profiling
• 什么是北极星排障指标体系
• 关于故障注入平台
• Kindling-OriginX工作原理
• 可观测性工具的盲区与故障排查困局
• 故障根因报告解读之：CPU篇
• 磁盘故障！Demo环境全部宕机！

Skywalking 和 Kindling-OriginX 都对Trace Profiling做了定义，两者想要实现的目标是一致的，都是想看清楚Trace在某个环节到底是如何执行的，只是工作在不同层次，能够反应不同的问题。

Skywalking 的 Trace Profiling 工作原理是在代码层次上，看出每个线程周期性时间节点在代码上干什么，同时与Trace关联。

Kindling-OriginX 的 Trace Profiling 工作原理是在内核层次上，看出每个线程从资源上在干什么（在CPU上执行，网络等待、IO操作等），同时与Trace关联。

Trace Profiling 目标​

在现代软件系统架构中，性能不仅仅是一个指标，它直接关系到用户体验和系统的可靠性。技术团队经常需要回答这样的问题：应用为什么这么慢？为什么会在这个时间点出现延迟？出现故障的原因到底是什么？故障时刻到底发生了什么？而Trace Profiling 就是一种可帮助我们找到这些问题答案的性能分析方法之一。

Trace Profiling 是一种详尽的性能分析方法，它通过记录软件运行时的具体事件来创建一个执行的时间线。这些事件可以包括函数调用、线程切换、I/O操作等。与传统的Sampling Profiling相比，Trace Profiling 提供了更细粒度的数据，使开发者能够精确地看到程序在任何给定时间点正在做什么。

Skywalking：Trace Profiling的工作原理​

当你启用Trace Profiling时，分析器会跟踪程序的所有或特定部分的执行细节。通常，这涉及到插入额外的监控代码或使用特定的监控工具来捕获事件和时间戳。一旦数据被捕获，它就可以被用来生成报告，这些报告描绘了程序的行为，揭示了性能瓶颈和潜在的问题区域。更多信息可以参考 Trace Profiling - Skywalking

Kindling-OriginX：Trace Profiling的工作原理​

用户开发的代码都是以线程形式运行在操作系统之上，即便Go语言有协程的概念，go协程在执行过程中仍然绑定在操作系统内核线程上执行。操作系统内核线程的完整运行周期如下图所示。

利用eBPF技术能够深入内核，拦截线程执行用户代码的关键点位获取信息，在获得线程执行关键信息之后能够还原线程的执行过程。

如果只从线程维度看程序执行过程是很难分析出故障的，因为开发和运维的谈的故障都是URL维度的用户请求调用，所以光有线程维度程序执行过程是不够的，需要和tracing系统关联。

当线程执行过程与tracing系统关联之后，即可完整还原用户一次请求的执行过程。

Trace Profiling中关联了可观测性所需要的数据：

• 指标
• 日志

Kindling-OriginX ： Trace Profiling能够实现的效果​

Kindling-OriginX 的Trace Profiling工作在内核中，所以能够反应程序的所有执行情况，比如程序执行过程当中，出现了CPU时间片用完，排队等待调度都可以被Kindling Trace Profiling所发现，这些数据从代码层面是获取不到的。

1. 所有线程的执行情况都被记录下来，并可以被重放。
2. 执行跟踪跨度的确切线程被突出显示。
3. 每个线程打印的日志被收集并与相应线程的时间戳相关联。
4. 代码执行火焰图与 CPU 繁忙时间序列相关联。
5. 与网络系统调用执行相关的网络相关指标与时间序列相关联。
6. 与文件系统调用执行相关的文件相关指标与时间序列相关联。

正是因为Trace Profiling完整的记录了请求是如何被执行的，所以可以被用来构建排障北极星指标，用以标准化排障。

参考资料：

The TSA Method - Brendan Gregg

Trace Profiling - Skywalking

Trace profiling: Scalable event tracing on high-end parallel systems

Profiling and Tracing in Linux

eBPF 技术​

eBPF（extended Berkeley Packet Filter）是一种先进的系统内核技术，最初源自于 Berkeley Packet Filter（BPF）。它是一种在 Linux 内核中执行高度优化的程序的框架，允许用户编写并插入小型程序（称为 eBPF 程序）来对系统内核的行为进行扩展和控制。 eBPF 允许用户在不更改内核源代码或重新编译的情况下，通过加载在内核中运行的小型程序来扩展内核功能。这些程序可以捕获和分析系统运行时的事件、执行网络分析、实现安全策略、执行性能调优等操作。 eBPF 的一些关键特性和优势包括：

• 安全性：eBPF 程序在一个受限的虚拟机中运行，不会影响系统稳定性和安全性。
• 灵活性：可以动态加载、卸载和更新eBPF程序，无需重新启动系统。
• 性能：eBPF 程序经过优化，能够在内核中高效执行。
• 可观察性：能够捕获和分析系统运行时的各种事件，有助于故障排除和性能分析。

eBPF 技术在多个领域得到应用，包括网络编程（例如网络包过滤、路由）、性能分析、安全监控、容器技术等。它已经成为许多现代系统中实现高级功能和控制的重要工具之一。 这里可以简单概括为 eBPF 是一套通用执行引擎，提供了可基于系统或程序事件高效安全执行特定代码的通用能力，通用能力的使用者不再局限于内核开发者；eBPF 可由执行字节码指令、存储对象和 Helper 帮助函数组成，字节码指令在内核执行前必须通过 BPF 验证器 Verfier 的验证，同时在启用 BPF JIT 模式的内核中，会直接将字节码指令转成内核可执行的本地指令运行。