运维的挑战与责任​

在数字化时代，运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能，还要快速响应并解决故障，以减少对业务的影响。在这种背景下，运维团队急需工具和技术，能够帮助他们提高效率，减轻负担。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 等关键网络事件及数据，提供证据证明网络确实有问题。

基于 eBPF 获取网络指标存在局限​

eBPF 可以获取到网络 rtt 以及 srtt 等指标，这些指标确实能够反应网络质量，但是其实现是有局限性的，在当前绝大多数客户使用场景是不能反映网络质量的。

eBPF 在网络质量监控中的局限性主要体现在以下几个方面：

1. TCP 建连时获取 srtt 指标： eBPF 在 BCC 中的实现是通过在 TCP 建连时获取内核维护的 srtt（smoothed round-trip time）指标。但是，TCP 连接建立完成后，内核并不会持续追踪每个网络包的传输时间。这就意味着在长连接场景中，srtt 指标并不能反映当前的网络质量变化。不仅仅是 BCC，我们自己开源的 Kindling 也有同样的局限，同时我们也对比了 datadog 等 eBPF 探针实现，发现都有这个问题。
2. 长连接场景中的不足： 现代微服务架构中普遍使用长连接来减少连接建立和拆除的开销。然而，在这种场景下，内核并不会持续更新 srtt 指标，从而无法反映长连接期间的网络质量变化。
3. 实验验证： 通过在 Tomcat 配置数据库连接池连接 MySQL，然后在两者之间注入网络延时故障的实验。在连接建立后，如果在任意一端注入延迟，BCC 的 srtt 指标将不会变化，因为内核不会追踪这些后续包的传输时间。

有没有其他方式判断网络质量​

文章《孙英男-B 站大规模计算负载云原生化实践》是 B 站建立容器云过程的分享，他们在判断网络质量抖动的时候使用的 ping 来判断网络是否抖动。

使用 ping 来判断网络质量是大家常用的一个习惯，而对于 ping 的延时大家在实践中已经形成了一些认知，比如如果 ping 的延时超过 100ms，那么在线网络游戏估计玩不成了。

使用 Ping 来判断网络质量的优点​

1. 简单易用： ping 命令几乎可以在所有操作系统中使用，无需复杂的配置。
2. 实时监控： 可以实时地检测网络延迟和丢包率。
3. 网络连通性： 可以快速判断两个节点之间的连通性。
4. 低开销： 相比其他方法，ping 对系统和网络资源的消耗较低。

使用 Ping 来判断网络质量局限性​

1. 误导性结果： 有时网络中的 ICMP 数据包优先级较低，可能导致延迟或丢包率看起来比实际情况更严重。
2. ICMP 流量限制： 某些网络设备（如防火墙）可能会限制 ICMP 流量，导致 ping 测试结果不准确，甚至 ping 不通
3. 大规模集群的限制： 高频 ping 造成的网络负载：在大规模集群环境中，对大量节点进行频繁 ping 操作，会产生大量 ICMP 流量，从而增加网络负载，影响正常业务流量。虽然一次 ping 的资源开销很小，但是集群规模大了之后，每个容器两两之间都进行 ping，这种消耗将是非常大的，大量的 ping 操作会消耗系统的 CPU 和内存资源，尤其是在需要同时监控许多节点的情况下。

如何才能低开销的完成网络质量的快速判断​

虽然 eBPF 和 ping 包的方式都有一定局限性，但是 eBPF 的局限性受限于内核的实现，该局限没有办法突破的，而 ping 包的局限是可以突破的。

• 误导性结果的突破：用户认知的突破，如果发现 ping 延时很严重了，那真实的网络流量更加严重，这点突破很容易。
• ICMP 流量限制：防火墙的配置即可允许 ping 包的发生。
• 大规模集群的限制：大规模集群中，如果两两相互都需要 ping 这是非常耗资源的做法，但是我们注意到实际场景中容器通过网络与其他容器交互的范围是有限制的，并不会和所有的容器都进行交互，这点是有优化空间的。

大规模集群适用低开销基于 ping 包的网络质量评估方案​

开源项目 coroot 有一个非常好的思路，他们使用了一个叫做 pinger 的组件，该组件工作原理如下：

• 基于 eBPF 获取容器之间的关系图，并不是获取 SRTT 等指标
• 根据节点关系图来发送 ping 包，上游节点对下游节点进行 ping，这样能够极大的降低任意两两 pod 互相 ping 的开销

但是 coroot 的 eBPF 实现要求内核版本高于 4.14，国内还有很多操作系统停留在 centos7 系列的用户，他们是没有办法用 coroot 的实现。

我们在 coroot 的基础之上，针对国内的环境做了优化，主要优化如下：

• 通过读取 proc 目录下来获取关系图，而不是通过 eBPF 获取关系图，这样就降低了对内核版本的依赖
• 沿用了 coroot 原有 pinger 组件的思路，上游节点对下游节点进行 ping，极大降低任意两两 pod 互相 ping 的开销
• 数据最后通过 exporter 暴露到 prometheus 或者 victoria metrics 中

最终效果图，展示 srcip 到 dstip 的 ping 值

题外话：我们不去修改 coroot ebpf 代码使其适配低版本内核主要是基于投入产出比，适配低版本内核需要调整代码量较大，我们通过 eBPF 采集的北极星因果指标是适配了低版本内核的。

自APO开源以来，社区成员询问APO是否支持Skywalking Agent，以避免已使用Skywalking的应用在测试发版过程中需要重新部署探针。APO利用OpenTelemetry生态，通过skywalkingreceiver实现Skywalking Trace到OTEL Trace的转换，为已经使用Skywalking的用户提供无缝体验。

有公司通过将Skywalking转换为OpenTelemetry+ClickHouse，成功降低了资源开销三分之一。APO如何实现这一功能？

使用ClickHouse存储Trace​

APO迁移了Jaeger-remotestorage至Jaeger 1.58，使用Jaeger-clickhouse项目表结构存储Trace，并集成JaegerUI展示Trace。APO在设计上简化了Trace的细节，使得在Jaeger 2.0改版以更好支持Clickhouse时，APO的集成也变得简单。

OneAgentBuilder：构建适用已有环境的OneAgent​

为了快速接入APO，特别是对于已经使用Skywalking和OpenTelemetry的用户，APO提供了OneAgentBuilder。

使用方法​

1. 下载OneAgentBuilder
2. 将模板中的skywalking Agent探针或OpenTelemetry探针替换为已使用的版本
3. 使用docker builder生成APO-OneAgent镜像，该镜像称之为定制化OneAgent镜像
4. 按照安装文档安装APO-OneAgent，安装过程中替换OneAgent官方镜像为定制化的OneAgent

定制化OneAgent镜像使用​

生成APO-OneAgent镜像后，您可以：

• 将镜像导入至目标机器
• 或者导入到Harbor中

然后，根据APO 官方文档安装 OneAgent，注意替换 OneAgent 官方镜像为您定制化 OneAagent。

结构示例​

以下是OneAgentBuilder中模板的结构示例：

preload-builder
├── opentelemetry-java
│   ├── Dockerfile
│   ├── libapoinstrument.conf
│   └── opentelemetry
│       └── opentelemetry-javaagent.jar
└── skywalking-java
    ├── Dockerfile
    ├── libapoinstrument.conf
    └── skywalking-agent
        ├── activations
        ├── bootstrap-plugins
        ├── config
        ├── expired-plugins
        ├── LICENSE
        ├── licenses
        ├── logs
        ├── NOTICE
        ├── optional-plugins
        ├── optional-reporter-plugins
        ├── plugins
        └── skywalking-agent.jar

APO v0.2.0 更新记录

新增功能​

• APO 支持接入 SkyWalking Agent
• 支持在安装 OneAgent 时替换默认的 Opentelemetry v2.5.0Agent，例如其他版本或SkyWalking 等
• 新增查看服务的“更多下游依赖”拓扑，加快定位故障原因
• 新增配置页面，支持修改数据保留周期
• eBPF 探针适配更多内核版本，支持自动适配内核版本

功能优化​

• 优化安装体验，支持独立部署 APO 服务端，支持监控 Kubernetes 环境以及传统服务器中的应用
• 优化告警规则页面展示效果
• 优化 APO 接口查询效率，提高页面响应速度
• 优化 Java 网关类型服务的监控数据准确度

缺陷修复​

• 修复部分场景下 ebpf-agent
• 修复部分服务端点无法查询出实例信息的问
• 修复日志/链路列表中不同实例包含了相同列表的问题
• 修复日志/链路检索页选择器的问题

其他​

• APO页面汉化

在 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时间才有可能超过一半。

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

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

在GitHub上，国内外的 eBPF 主流开源软件是打开网络黑盒提高可观测性，另外一部分就是Continues Profiling，其中Continues Profiling最有名的就是Pyroscope项目，并被Grafana收购。

什么是Continues Profiling？​

以下内容来自于GPT4的回答：​

持续剖析（Continuous Profiling）是一种软件性能优化技术，旨在实时收集程序运行时的性能数据，如CPU使用率、内存分配、线程锁等待时间等。这些数据通常通过在代码中嵌入剖析器（Profiler）来收集，剖析器能够监测和记录应用程序在执行过程中的各种性能指标。

持续剖析的目标是帮助开发者理解应用程序在生产环境中的实际运行性能，从而发现性能瓶颈和优化机会。与传统的剖析（通常在开发或测试阶段进行）不同，持续剖析强调在应用程序的整个生命周期内，尤其是在生产环境中不断进行性能监控和优化。

持续剖析的好处包括：

• 实时性能监控：通过持续收集性能数据，开发者可以实时监控应用性能，及时发现和解决问题。
• 发现隐蔽的性能问题：某些性能问题可能只在特定条件下或在生产环境中出现，持续剖析帮助发现这些难以在测试阶段发现的问题。
• 优化资源使用：分析性能数据可以帮助开发者优化代码，减少资源浪费，提升应用效率和响应速度。
• 提升用户体验：通过优化应用性能，可以直接提升最终用户的体验。

持续剖析通过集成到CI/CD流程、自动化工具和监控系统中，成为现代软件开发和运维的重要组成部分。它使得性能优化成为一个持续的过程，而不是一次性的任务，有助于构建更高效、更稳定的软件系统。

最原始的Continues Profiling概念主要停留在CPU代码上的采集，形成火焰图帮助大家理解代码在CPU上是如何运行的。但是这点对于分析清楚线上的性能问题是不够的，因为线上代码是复杂的，程序依赖的条件不仅仅有CPU，还有锁、网络IO、磁盘iO等各种事件, 所以可观测性巨头如Datadog在他们的Continues Profiling理解中已经增加了很多。

代码视角下的持续剖析​

Datadog对Continues Profiling的理解，可观测性的终极大杀器​

Datadog其官网对Continues Profiling的能力定义：​

• Never miss production issues originating from your code by continuously profiling every line across all hosts and containers.
• Enable engineers of all levels to swiftly spot and resolve problems using Watchdog AI's insights and suggested fixes.
• Pinpoint methods and code lines that are inefficient under production load, despite having performed well in pre-production environments.
• Find the root cause of slow requests by correlating spans with profiling data.
• Gain thread-level visibility into your requests to investigate parallelization, deadlocks, inefficient garbage collection, locks, and more.
• Determine exactly what your slow methods are spending time on — CPU, locks, I/O, garbage collection, and more.

从能力角度来看，Datadog的Continues Profiling能力像银弹一样，成为了可观测性的终极方案，无论什么问题，CPU, locks, I/O, garbage collection等各种问题，Datadog的Continues profiling都能够给轻松给出答案。

开源项目对Continues Profiling的理解，像Datadog学习​

以Pyroscope为例，最开始的Pyroscope提供了eBPF为内核的OnCPU数据采集和内存相关数据采集能力，主要的分析的能力是CPU、内存分配对象、内存分配空间、在用对象、在用空间、Goroutines等多种类型。

最近去Pyroscope的官方Demo上看，发现其演进思路也基本上往Datadog的方向靠近了，出现了对于lock的持续剖析功能。

国内同行业专家也是非常认可Datadog的思路​

某公有云可观测性软件发版了其持续剖析的功能，虽然没有实际使用过，从功能列表来看，已经很接近Datadog的能力了。

国内其他的可观测性公司也在致敬Datadog的方法论，提供类似的数据。

Datadog的Continues Profiling核心设计哲学​

• 内核是稳定的

• 代码是业务开发的，开发者只关心代码要如何修改才能解决问题

• 火焰图长时间执行的代码块能帮助用户理解问题，并启发用户产生解决思路

• 正因为Datadog是沿着这个思路设计产品的，其持续剖析功能的实现就是从代码层面上去剖析问题，但是这样的设计哲学有一定局限性。

Datadog代码层面的持续剖析局限性​

为了让大家更好的理解问题，举例说明，如果大家看到了这张火焰图能够得出什么结论：

从代码层面的持续剖析数据来看，代码是由于记录日志时间很长，那为什么呢？可能有常见的排查思路继续深入排查：

• 日志由于并行写，产生了锁

• 磁盘可能出现了问题，导致日志写变慢了

• 长时间的GC

如果上述的排查思路都没有结果，方向就比较迷茫了。

从内核视角的持续剖析​

基于TSA的性能定位问题方法论​

有兴趣的朋友可以深入理解大神brendan的文章The TSA Method，或者参阅TSA方法：基于线程时间分布分析性能瓶颈。

对于没有耐心的朋友，这里做个快速简介：就是将线程在不同状态下切换过程，按照下图所示对程序执行过程进行分析，从而理解线程在执行程序的时候到底卡在哪个环节。

从内核视角的持续剖析有什么优势和劣势​

优势​

• 真实反应程序正卡在什么地方

• 准确与精准没有任何其他可能性

• 内核反应出来的卡住的问题比代码卡住的问题场景少很多，线程只可能卡在以下几个方面：CPU执行，CPU调度，网络IO，磁盘IO，锁。这个为后续的智能化分析提供很好的基础

劣势​

• 内核视角缺少业务属性，不知道哪个线程在哪个时间段为哪个业务服务，除非在性能压测场景，URL访问单一，可以在线程行为中找到模式匹配业务开始与结束，否则人很难分析

• 内核系统调用和相关知识对于普通业务开发人员而言太陌生，导致即便看到了内核相关系统调用比如说futex执行时间很长，不能理解这在代码层面上意味着什么

TSA的方法论结合Trace带来不一样的视角​

开源项目Kindling的Trace-Profiling解决了单独TSA的持续剖析方法的劣势之一：内核视角缺少业务属性。Trace-Profiling通过TSA的方法论产生的数据与Trace打通，做到了与业务关联，这样在生产环境就可以做到某个业务因为什么原因卡住了。

还是以这个火焰图为例，代码剖析反应程序卡住在了日志代码之上。

如果使用Trace-Profiling，应该能够明确给出当时业务是卡住下列事件之一

• RunQ

• Futex

• CPU

• DISKIO

代表代码执行的线程卡在什么地方知道了，那接下来就是如何理解和翻译了。

开发人员对内核的理解是推广TSA方法论的阻碍​

云原生环境内核由于资源竞争带来的问题​

绝大多数开发人员在正常业务开发当中较少接触内核，而且也会认为内核是不会产生问题。也许从单机而言，出现任何问题都极少的可能是内核调度产生的。但是一旦涉及到云原生环境，要提高资源利用率的场景，就需要多业务都在竞争对内核的使用，这个时候产生的竞争就超出了普通开发人员的常规认识，也就意味着云原生产生的问题比以往问题更多。

开发者对于内核理解有限​

CPU调度产生的RunQ对于绝大多数开发而言太遥远，上述例子可能事件中也就DISKIO是开发人员能够快速理解的，其它都需要花费更多的精力去学习。学习成本带来了推广难度，所以业界几乎没有看到基于TSA方法论的工业化产品在推广。

问题总结​

1. 基于代码的持续剖析虽然对于开发而言足够友好，开发能看懂哪段代码带来的问题，但是由于代码的丰富多样性，看到代码卡住了，很多时候仍然不知道代码为什么卡住，并且现象可能有一定随机性。

2. 基于TSA内核持续剖析的方法虽然能够精准定位业务卡在了什么内核事件之上，但是对于开发者不友好，不利于推广。

智能运维中的决策树结合TSA实现对内核事件的自动化翻译，完美解决当前持续剖析存在的问题​

对于可观测性领域，AIOPS已经推广了很久，但是由于缺少一锤定音的数据特征，从而难以高准确率方式判定故障根因。

基于TSA的线程模型机制给出了程序的精准内核事件，相比于代码或者日志的N种场景，内核事件要精简得多。

举例说明：

一旦线程出现上内核事件RunQ，这说明线程在执行代码的时候，由于内核CPU调度的原因卡住了，这个时候在代码层面上可能在做一些做普通业务操作，比如前文例子觉得记录日志的代码卡住了，在代码层面上也可能是做了个网络操作卡住，从代码层面分析非常复杂，可能性非常多。但是从RunQ事件分析，就非常精准，只有这一个事件特征，不存在其他事件特征。

为了帮助用户理解，这个RunQ的事件就可以翻译成为当前CPU资源不足，应该扩容了，这样开发和运维就能很容易理解。

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

传统排障方法的局限性​

传统故障排查的痛点​

在复杂的分布式系统中，故障排查一直是一个让人头疼的问题，其中机器宕机、进程存活、程序异常报错等故障相对而言比较好排查，有直接的指标能够反应出问题，难排查的问题是流量突增，时延变化等故障，特别是在分布式系统中，这类故障更难排查。传统的方法往往需要工程师逐一排查各种可能性，耗费大量时间和精力，效率低下且盲目。

传统故障排查方法的低效性主要源于以下几点：

• 时间消耗巨大： 需要逐一检查系统中的各个组件和指标，排查流程繁琐，耗时长。
• 盲目性： 没有明确的线索指引，排查过程中往往需要凭借经验和直觉，试错成本高。
• 数据分散： 各类监控指标彼此独立，缺乏统一的视图，导致难以全面了解系统状态。

这些痛点的根源在于我们所使用的指标大多是结果性指标，指向性不明确。例如，CPU利用率、内存使用率等指标只能反映系统的当前状态，却无法直接指出问题的根源，给故障排查带来了巨大的挑战。

常规的指标局限​

在实际应用中，工程师们常常依赖于各种常规的性能指标，例如：

• CPU指标： 反映系统的计算资源使用情况。高CPU使用率可能是由于多个原因导致的，例如某个服务在进行高计算密集型操作。但是，CPU指标并不能告诉我们具体是哪个请求导致了高CPU使用率，通过人为分析才能知道是哪个进程的CPU使用率高，然后借助更多的工具才能知道可能是哪一段代码导致的，但是业界还缺少业务视角关联，没有办法知道哪个URL导致了CPU升高。
• 网络指标： 反映网络传输的性能。无法明确是哪一个具体请求导致的带宽占用，例如一个文件服务器在处理多个文件上传和下载请求。网络指标只能显示整体的网络带宽使用情况上升，却不能确定是哪个具体请求导致的带宽占用增加，也缺少业务视角关联。
• 文件指标： 反映磁盘I/O操作的效率。高磁盘IO使用可能是因为某些请求涉及大量的文件读写操作。然而无法具体指明是哪一个请求导致的磁盘IO高使用，缺少业务关联视角。
• 内存指标： 反映系统的内存使用情况，同理缺少业务关联视角。
• GC指标： 反映垃圾回收的频率和时间，同理缺少业务关联视角。

虽然这些指标在一定程度上帮助我们了解系统的运行状态，但它们彼此独立，无法构建出一个完整的故障图景。这种独立性导致了以下问题：

• 无法关联： 各个指标之间缺乏关联，难以看出它们之间的因果关系。
• 片面视角： 只能看到单个指标的表现，无法形成整体视图。
• 低效排查： 无法通过单一指标判断问题的根源，需要逐一排除各种可能性，效率低下。

常规指标的这种局限性导致在排障过程中，我们常常需要逐一排查每一个可能的原因，耗费大量时间和精力，难以快速定位问题。

北极星指标带来的革命性变化​

业界提供因果性的工具​

为了应对复杂系统中的故障排查问题，业界提出了一些具有间接因果性的工具。然而，这些工具和方法也有其局限性：

• 分布式追踪（Distributed Tracing）：

○优点： 提供请求的完整路径信息，详细展示每个服务调用的耗时，帮助识别系统中的延迟和瓶颈。

○局限性： 在稍微复杂的场景下，因噪音和故障级联的存在，瓶颈点经常会被误判。需要结合业务逻辑和经验分析，才能推断因果关系，找到真正的瓶颈点。

• 依赖图（Dependency Graph）：

○优点： 展示系统组件之间的依赖关系，便于理解系统架构，帮助识别关键路径和潜在的瓶颈。

○局限性： 依赖图是静态分析工具，无法实时反映系统运行状态。随着系统规模的增加，依赖图的复杂性也增加，难以管理和维护。

• 日志（Logging）：

○优点： 详细记录系统运行状态和事件，便于追踪和分析，具有高度的定制性，可以记录各种所需的信息。

○局限性： 需要精心设计和管理日志记录策略，否则会产生大量无用数据。分析日志数据需要强大的工具和技术，如ELK栈。日志数据分散，难以直接构建因果关系，需要结合其他数据进行综合分析。

• 事件监控（Event Monitoring）：

○优点： 可以实时监控系统中的各种事件，如错误、警告等，帮助快速响应和处理异常事件。

○局限性： 事件监控通常是离散的，难以直接构建事件之间的因果关系。需要结合历史数据和上下文信息进行分析和推断。

利用eBPF技术获取北极星指标​

北极星因果指标的获取依赖于先进的分布式追踪技术和内核级数据关联。具体过程如下：

1. 分布式追踪： 首先，通过分布式追踪技术，捕获每个请求的完整路径信息。这包括请求在不同服务节点之间的传递和处理时间。
2. eBPF在内核追踪线程信号： 在系统内核中，追踪执行请求的线程信号。这些信号反映了线程在处理请求过程中的各个状态变化和资源使用情况。
3. eBPF在内核实现系统调用信号关联： 将分布式追踪数据与系统调用信号关联起来，形成对请求处理全过程的详细分解。这一步骤涉及将应用层的请求数据与内核层的系统调用数据进行关联，确保每个请求的所有资源使用情况都被捕获和分析。

通过这种方法，我们能够生成北极星因果指标。该指标不仅提供了各个性能指标的详细数据，还展示了它们之间的因果关系，从而帮助工程师快速定位故障根源，提升排障效率。

北极星因果指标的组成: 一次业务视角的请求耗时被完美且完整拆解成以下指标​

CPU耗时​

• 定义和意义

○指请求在CPU上消耗的时间。

• 如何影响请求处理

○高CPU耗时可能指向计算密集型任务比如循环和递归。

网络耗时​

• 定义和意义

○指请求在网络传输中消耗的时间。

• 如何影响请求处理

○高网络耗时可能指向网络延迟、带宽不足或下游节点代码执行异常，典型的就是SQL语句执行慢。

文件读写耗时​

• 定义和意义

○指请求在文件系统读写操作中消耗的时间。

• 如何影响请求处理

○高文件读写耗时可能指向磁盘I/O瓶颈或文件系统问题。

内存消耗耗时​

• 定义和意义

○指请求在内存分配和管理中消耗的时间。

• 如何影响请求处理

○高内存耗时可能指向内存泄漏、内存分配不当或频繁触发Pagefault。

锁耗时​

• 定义和意义

○指请求在等待锁资源中消耗的时间。

• 如何影响请求处理

○高锁耗时可能指向锁争用、死锁或锁机制设计不合理, 绝大多数都是代码类库使用了隐藏锁而开发人员不自知，比如数据库连接池锁等。

GC耗时​

• 定义和意义

○指请求在垃圾回收过程中消耗的时间。

• 如何影响请求处理

○高GC耗时可能指向内存管理不当或垃圾回收频繁触发。

CPU调度耗时​

• 定义和意义

○指请求在执行过程中，由于CPU调度而产生的延时

• 如何影响请求处理

○高CPU调度耗时，意味着容器的CPU资源不充分。

为什么北极星因果指标是排障的最关键指标​

基于北极星因果指标排障，立刻获得了多个性能指标的关联分析结果，有了系统的整体视图。

北极星因果指标具有以下独特优势：

• 因果性：

○北极星指标通过数据关联和因果关系分析，提供了请求处理过程中的详细分解。各个指标之间的因果关系明确，能够帮助工程师快速定位问题根源。

• 全面性且无盲区遗漏：

○北极星指标覆盖了请求处理的全过程，从CPU耗时、网络耗时、文件读写耗时，到内存消耗耗时、锁耗时和GC耗时，确保了指标的全面性并且没有盲区。

• 高效性：

○通过提供因果关系视图，北极星指标可以快速定位故障根源，减少排障时间和降低排障复杂性。工程师无需逐一排查每一个可能的原因，而是能够通过整体视图快速确定问题所在。

• 一体化视图：

○北极星指标将多个独立的性能指标整合为一体化视图，便于综合分析和决策。这样，工程师在查看指标时，不再需要切换不同的监控工具，而是可以在一个视图中看到所有关键性能指标及其关联关系。

总结​

北极星因果指标的引入，彻底改变了故障排查的方式。通过提供因果关系和全面视图，它不仅提升了排障效率，还显著减少了排障过程中的盲目性和试错成本，真正实现了高效、精准的故障排查。

●永久免费

●多语言支持：Java、Python、Nodejs、一键安装

●标准PQL语句查询数据

随着云原生、微服务等技术给企业带来竞争力的同时，也使得系统更加的复杂。日趋复杂的系统让故障根因难以排查，导致处理故障的大部分时间都用在了对问题的定位上。能够明确知道系统发生了什么是进行问题定位的前提之一，所以如何对系统进行监控，如何获取到规模庞大的系统的运行状态，也都成为了新的挑战，这种挑战反过来也促进了可观测性领域的发展。

可观测性的目标​

对于很多成熟企业，很多已经构建了APM、NPM等监控体系，以及Trace、Log分析系统等。而对于一些起步不久的企业，可能还处于可观测性建设的初期阶段。

那么对于不同阶段的企业和技术团队，是否对可观测性的要求有所差异呢？

总体上来说，可观测性代表了当前对系统形成洞察的能力，可观测性成熟度越高，对系统的洞察能力就越深入越完整，即系统的可观测性成熟度越高，就能越迅速、越准确地从发现的问题中找到根本原因。因此无论企业目前处于什么阶段，当前可观测能力的建设水平如何，其对于可观测性能力建设的目标应当都是一致的。

目标具体包括：

• 更全面的数据采集
• 更有效的关联各种类型数据
• 更快速与自动化的确认问题根因

各个企业在观测性建设成熟度上的差异，也主要体现在对这些目标的达成程度的差异。

可观测性成熟度​

为了能够更好的帮助与指导企业进行可观测性的建设，衡量及评估自身当前可观测性建设水平，有很多机构与公司都发布过对可观测性成熟度模型的定义，本文以龙蜥社区与信通院稳定性保障实验室联合发布的《2023年可观测性成熟度模型白皮书》为例进行说明。该模型是一种用于衡量和评估企业软件系统内部可观测性的框架或方法，同时也是一种用于反馈企业可观测性体系建设成熟度水平的框架或方法。

该模型包含五个级别，分别是：

• Level 1：监控。确定系统组件是否按预期正常工作。

• Level 2：基础可观测性。确定系统为什么不工作。

• Level 3：因果可观测性。找到问题的根本性原因，并确定它的影响面，避免再次发生。

• Level 4：主动可观测性。自动化的找到问题根本性原因，自动化的响应处置，智能化的预测预防，阻止异常风险发展成为问题故障。

• Level 5：业务可观测性。确定对业务的影响，如何降低成本、增加业务营收、提升转化率、辅助商业决策。

可观测性建设成熟度越高，团队越能够通过合适的数据自动发现和修复问题，甚至主动识别和预防问题。可以简单理解为越多的故障能够通过可观测性工具发现，甚至主动预防，说明其成熟度越高，如果仍旧有较多问题通过客服侧或其他渠道上报而来发现，那么说明其成熟度还不够。

使用故障注入对可观测性成熟度进行检验​

什么是故障注入​

混沌工程是一种方法论，而混沌工程的核心就是注入故障。通俗理解，以应用为出发点，在各种环境和条件下，给应用系统注入各种可预测的故障，以此来验证应用在面对各种故障发生的时候，它的服务质量和稳定性等能力。

故障注入是衡量可观测性建设质量的有效标准​

在实际生产环境中，对可观测性建设成熟度及质量的最直接的衡量方式就是评估有多少故障是通过可观测性工具发现甚至预防的。

这是一个最直观的标准，如果花了很多精力、物力、人力做了完备的可观测体系建设，但是仍旧有大量的故障没有能够被观测到，甚至仍旧出现P0级别的故障，是没有人能够认同这个体系的建设是成熟的、是高质量的，只是单纯的可观测性数据和工具的堆砌。

而故障注入作为真实故障的模拟，与真实场景最为接近，也最能够有效地评估系统在面对实际故障时的响应和恢复能力，也最能够有效的反映出可观测性体系在实际问题场景中是否能够真实有效的发挥作用，为解决问题提供最切实有效的价值。业内技术领先的公司，也经常采用故障注入演练的方式对自身系统的健壮性进行检验，查漏补缺不断提高可观测性工具对问题发现和预防的比例。

故障注入虽不能涵盖全部的故障问题，但目前主流工具已能将大部分常见的网络、系统、代码、容器问题进行模拟，能够有效帮助组织评估、改进和发展其可观测性能力。Kindling-OriginX 在产品设计与开发过程中也使用这种方式进行能力的检验和产品的迭代。

总结​

如果想要对自身可观测能力进行检验，也可与Kindling-OriginX Demo采用类似方式，在目标环境中部署soma-chaos。

soma-chaos 目前已支持的故障类型有：

• 网络类故障案例。例如丢包率较高、重传率较高、带宽限制打满、DNS故障、TCP建连延时高

• 存储类故障案例。例如IO延时高

• CPU类故障案例。代码自身CPU使用率高、共享环境其它进程抢占CPU

• 内存类故障案例。FULL GC频率很高、共享环境其他进程抢占Memory

• 代码类故障。代码抛出异常导致错误码返回、HTTP请求返回错误码

soma-chaos 是一个开源模拟故障案例集系统。该项目开源在龙蜥社区系统运维联盟之下，其中包括复旦大学SELab开源的业务模拟系统Train-Ticket、Chaos-Mesh开源云原生混沌工程平台、收集整理的真实故障案例集。欢迎任何单位和个人提交贡献故障案例，一起讨论故障注入实践或在使用过程中产生的任何想法和问题。

参考资料​

Train Ticket：A Benchmark Microservice System

gitee-soma

Chaos Mesh

故障注入使用指南