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

简介​

北极星排障指标体系是一组指向性明确的指标，通过这些标准化的指标体系指出问题根因和结论，在排障过程中给予参与人员明确的方向指导，给出问题的明确界限。通过北极星排障指标体系，可以根据企业业务流程和自身工具情况构建出标准化的排障流程，进而真正能够在实际生产环境中落地1-5-10。

北极星指标​

北极星指标也叫唯一关键指标（OMTM，One metric that matters），产品现阶段最关键的指标，其实简单说来就是公司制定的发展目标，不同阶段会有不同的目标。为什么叫“北极星”指标，其实大概的寓意就是要像北极星一样指引公司前进的方向，目标制定最好是能符合SMART原则，具体指具体(Specific)、可以衡量的(Measurable)、可实现(Attainable)、相关性(Relevant)、有明确的截止期限(Time-bound)。 北极星指标通常具有三个价值，指引未来、团队协同和结果导向。例如电子商务类的商业模式，他们的核心价值通常是用户下单购物，因此常见的北极星指标是GMV或订单量。对于媒体网站或内容类商业框架，企业更关注用户的阅读和创作，那么北极星指标通常为阅读量、停留时长、作品数等。而即时通讯类APP的核心价值是用户间的信息传输，所以企业通常会把消息数、发送消息的用户数等作为北极星指标。

北极星排障指标​

目前问题​

• 传统可观测性工具存在盲区

目前虽然 Tracing、Metrics、Logging 已经成为绝大多数云原生业务的标配，但在实际生产环境中可观测性工具仍旧存在着很多盲区。实际应用过程中，大多数情况下往往仍旧采用填坑的方式，一方面在有可能有问题的部分增加日志及相关追踪信息，另一方面根据历史数据和经验在发生过问题的部分增加指标和相关事件记录信息，导致很容易丢失故障现场信息，同时无法真正发现问题根因。同时，传统可观测工具提供和记录的各类相关指标往往只有专家才能对其进行解读，并将其理解运用解决生产环境中的实际问题，这便使得数据、指标记录了，但是盲区却仍旧存在。

• 排障周期不可预期

排障周期是指从发现问题到最终解决问题的整个过程。在理想情况下，这个周期应该是可预测的，这意味着团队可以估计出从识别问题到解决问题所需的时间。然而，在实际操作中，排障周期往往是不可预期的。主要原因有：排障极大程度上依赖参与排障人员的主观经验，排障知识的积累因人而异，导致其周期没法预估，受当次故障处置参与人员的经验和能力影响大；另一方面排障周期往往取决于故障发生时或发生前先看到什么现象，其会对处置人员的定位思路和处置决策产生影响，存在一定运气成分，进而使得同样的故障，即使是相同的根因，也会由于不同的现象导致排障周期不同。

北极星排障指标体系理论​

基于目前的问题及困境，龙蜥社区与 Kindling 社区联合发布了北极星排障指标体系，通过将传统北极星指标的概念和方法论引入到排障流程中，构建出了一套排障指标体系与标准化的步骤，力求在目前困境中找到一条可操作可落地的标准化排障之道。

北极星排障指标-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

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

实现要点​

• OnCpu时间

进程真正获取cpu的时间，从获取cpu（sched_switch）到失去cpu（sched_switch）的时间。

• Runqueue时间

进程在运行队列中的时间，记录线程从被唤醒（sched_wakeup）到获取cpu（sched_switch）的时 间；如果线程主动让出cpu，则记录失去cpu到重新获取cpu的时间。

• 等待时间

进程从失去cpu（sched_switch）到被唤醒（sched_wakeup）的时间，然后通过sched_switch off 时抓的堆栈，进行阻塞原因分析。

• 等待网络的时间

通过系统调用来辨别：__sys_recvfrom, sendmsg, recvmsg。

• 等待存储的时间

通过系统调用来辨别： vfs_write, vfs_read, do_sys_openat。

• 等待锁时间

futex: futex_wait, mutex_lock lock: mutex_lock, mutex_lock_interruptible

• server端实际执行时间

应用采用同步方式向其他服务器发送请求或者发起新链接，或者进行 DNS，记录发送请求时的四元组： S1=(source_ip, source_port, dest_ip, dest_port)；在 server 端进行监听，若获取的四元组 S2 和 S1 相同，则记录 server 端开始执行的时间戳 T1；当 server 端进行请求响应，获取四元组 S3，若 S3 的四元组与 S1 对应相同，则记录结束执行的时间戳 T2；T2 - T1 则为 server 端实际执行时间。

根因分析（Root Cause Analysis，RCA）是一种问题解决方法，用于识别问题的根本原因，然后通过解决这些原因来防止问题再次发生。它是一种回溯性过程，旨在发现问题的深层原因，而不仅仅是处理表面的症状或后果。

在可观测领域和IT领域内，根因分析是指在软件工程和系统管理中，当服务或应用出现故障时，通过监控和日志数据来识别导致问题的基本原因的过程。可观测性通常涉及三个主要的数据源：日志（记录事件的详细信息）、指标（系统性能的定量数据）和跟踪（记录请求流程的路径）。

不同人眼中的根因分析​

运维工程师眼中的根因分析​

在运维工程师或SRE部门承担着业务稳定的职责，所以出现问题之后，第一职责是确认到底该如何操作才能恢复业务。那么这里面需要根因分析吗？可能会有部分人认为运维不需要对故障做根因分析，只需关注进程是否存在，机器是否正常就好了，如果没有问题，就无脑重启业务就应该恢复业务了。 在一些IT架构不复杂，问题故障原因单一的情况下，很多时候是可以通过重启、回滚等手段恢复，但是IT架构一旦庞大起来，或问题根因比较复杂，特别是以微服务架构运行在云原生环境中时，重启能够恢复业务的几率就大大降低了，往往重启也只是一种无目的的猜测手段了。 在云原生环境中，运维工程师需要通过根因分析来达到恢复业务的目的。所谓根因就是运维工程师在故障发生时能够依据的结论，其后依靠这些结论来指导业务的恢复和故障的处置。 在这里例举下运维工程师可以采取的恢复手段，即使同类故障仍旧会在不久的将来再次发生。

• 识别是代码缺陷，例如内存泄露、GC频率过高等，重启恢复业务。
• 识别是代码缺陷导致CPU飙升、数据库QPS过高，在允许代码回滚的情况下通过回滚恢复业务。
• 识别是流量过大的问题，如果确认是流量过大超过系统设计负载能力，在不变更架构设计的情况下，只能通过扩容或者限流措施来快速恢复业务。
• 识别是共享资源的问题，取得明确的证据，减少跨公司跨团队的协作沟通成本，提交工单提供数据或相关日志，协助公有云或者云供应商更快的解决故障，恢复业务。
• 识别是第三方软件依赖的问题，取得明确的证据，减少跨公司跨团队的协作沟通成本，督促第三方软件依赖快速解决故障，恢复业务。

运维工程师不可能在不了解故障根因的情况下，依靠穷举猜测试验的方式恢复故障，所以运维工程师非常需要了解到底发生了什么故障，该故障的根因是什么，才能真正的快速恢复业务，做到快速止血。所以针对运维工程师，故障根因结论是以下几种：

• 位于哪个微服务节点的内存泄露、代码死锁——重启能够解决，确认是否能够重启还是扩容机器，减少风险。
• 位于哪个服务节点的CPU飙升——确认是否能够回滚，或者扩容机器，减少风险。
• 访问量激增——确认是扩容哪些节点还是限流某些节点来恢复业务。
• 共享资源的问题
  • 如果是网络问题，确定哪个节点与节点之间的网络有问题，还是整个网段都有网络问题，提取证据，提交给公有云或者云供应商。
  • 如果是存储问题，确定是何种存储，提取证据，提交给供应商解决。
  • 如果是节点硬件或者配置故障，迁移机器。
• 第三方依赖的问题，提交证据，交于第三方依赖厂商解决问题。

开发工程师眼中的根因分析​

开发工程师往往承担业务实现的职责，但在系统故障时常需协助运维工程师定位运维中的根本原因。同时，开发工程师还需要承担软件缺陷和架构设计问题所致故障的复盘工作，以避免未来类似故障再次发生，并确保对系统及时进行优化。

因此，开发工程师视角下的根因分析需要有效指导故障复盘，能更好地还原故障现场，帮助开发人员理解故障发生的代码层或配置层原因，并及早发现业务架构设计层面的潜在风险。

常见的开发人员视角下的根因包括：

• 代码死锁现象——开发工程师想知道的根因是锁住的代码块是哪些，代码分别持有锁的时间长度是多久。
• CPU飙升——开发工程师想知道哪段代码导致的CPU飙升。
• 内存泄露——开发工程师想知道哪些函数申请的内存具体多少。
• 网络问题——开发工程师想知道具体访问哪些请求，做了哪些操作从而提取优化思路。
• 存储问题——开发工程师想知道具体访问了什么文件，I/O是多少，访问频度如何，从而提前设计优化方案。

故障根因分析实践中的困境​

虽然在现代IT系统中，各环境参与人员都急需合适的根因分析工具介入来提高效率，优化故障处置流程，但是目前根因分析在真正落地实施时面临多种挑战和困境：

• 复杂性

现代系统的分布式和微服务架构增加了系统的复杂性，特别是云原生环境下资源服务的动态变化和基础设施故障也会对定位造成干扰，这些都使得故障的定位和根因分析难以实现。

• 信噪比

系统可能会产生大量的日志和各类指标数据，特别是发生故障时尤为突出，但并非所有数据都与问题相关。过滤出有用信息并从中识别和定位出故障根因非常具有挑战性。

• 文化和流程

组织文化和相关流程需要能够有所支持，一方面组织内部必须能够切实有效的认识到根因分析对于提高系统可靠性和发生故障时真正快速止血的必要性，另一方面团队内部也需要有适宜的协作机制和流程，促进各团队间能够快速修复问题，并且深入挖掘其根本原因，能够做到快速止血的同时也能够彻底解除隐患，落地实践 1-5-10 等高效的故障处置流程。

开源模拟故障案例集系统soma-chaos是针对train-ticket注入故障，并实时查看故障状态的图形化故障案例模拟系统。 龙蜥社区系统运维联盟由清华大学、复旦大学、浙大大学、信通院、阿里云、浪潮集团、中兴通讯、统信软件，云观秋毫、云杉网络、乘云科技作为首批联盟发起成立，联盟的宗旨是以推动系统运维技术进步、促进产学研合作为⽬的的⾮营利性组织。开源模拟故障案例集项目由龙蜥社区系统运维联盟发起，联合各大运维厂商、平台厂商和科研院校、事业单位共同参与的，旨在通过建立一套故障演练平台，为平台厂商、运维厂商和广大客户建立起沟通的桥梁和纽带，让客户对运维产品拼图有全局认识。 云观秋毫与复旦大学在系统运维联盟中的主要工作是负责构建故障案例集演示系统，提供开源开放的故障案例集合，推动并促成行业面对故障的时候能以统一的案例话术沟通。更多信息可参考：

故障注入平台

故障注入使用指南

[gitee] soma

Chaos Mesh

故障案例集​

故障注入平台中涉及的案例集来源于开源开放的故障案例合集，欢迎各团队和组织共享相关案例集。构建该案例集宗旨是：

• 覆盖主流开发技术
• 开源开放，欢迎所有人一起完善故障案例
• 任何人都可以在私有环境构建部署
• 任何人可以产生一致理解的典型故障
• 绝大多数故障案例可以恢复，案例可以重复实验

关于Train Ticket​

"Train Ticket" 是由复旦大学开源的微服务基准系统，用于教学、研究和实践微服务技术和云原生应用开发。该项目模拟了一个在线火车票预订平台，包含一系列协作的微服务，每个服务都承担着不同的业务职责，如用户认证、票务查询、订单管理等。项目为学生、研究者和开发者提供了一个实际的微服务系统案例，帮助他们学习现代软件工程的实践，尤其是在微服务架构设计和运维方面。更详细的资料可参见该项目 GitHub 主页: Train Ticket：A Benchmark Microservice System

故障注入简介​

故障注入（Fault Injection），也称为错误注入或故障注射，是一种软件测试技术，用于增强系统的鲁棒性和可靠性。这种方法通过人为地在系统中引入故障或异常条件，来模拟软件、硬件或网络的潜在错误，目的是为了验证系统在面对真实世界中可能遇到的故障时的行为。

故障注入的作用​

• 验证系统的错误处理和恢复能力

确保当系统遇到故障时，构建的日志与监控系统能够正确地记录错误信息，响应的容错与恢复机制能够执行必要的回滚操作，并在可能的情况下自动恢复服务。

• 评估系统的容错能力

测试系统在面对故障时是否能够继续运行，即使是以降低的性能或功能。

• 提高系统的可靠性

通过发现和修复在故障注入测试中暴露出的问题，提高系统的整体可靠性，优化系统整体架构和设计。

• 理解系统的行为

在极端情况下，更好地了解系统可能的行为，以便在设计和实施阶段对这些极端情况加以合理的容错和恢复机制，保证在条件允许的情况下尽可能的提高系统的可靠性和稳定性。

火热的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资源不足，应该扩容了，这样开发和运维就能很容易理解。

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

在现代企业的运维管理中，构建高效且可靠的可观测性体系是保障系统稳定性和业务连续性的关键。然而，运维团队成员的技术能力参差不齐往往成为实现这一目标的障碍。尤其在处理复杂系统故障时，高度依赖专业知识和经验的可观测性工具很难被全员有效利用，进而影响到其建设价值的体现。

可观测体系建设的意义​

可观测性是近几年来最热门的话题之一，许多企业和团队都投入了很多人力、物力来进行可观测体系的建设，以期能获得可观测性的核心价值：快速排障（troubleshooting）。可观测性体系是指通过一系列技术手段和方法，对系统的运行状态、性能指标、业务流程等进行实时监控、分析、预警和优化的一种体系。它可以帮助企业及时发现和解决问题，提高运维效率，降低故障风险，为业务发展提供有力支持。

1. 提高运维效率

通过实时监控云原生应用的运行状态，运维人员可以快速发现并解决问题，减少故障排除时间，提高运维效率。

2. 保障系统稳定性

可观测性体系可以帮助开发者及时了解应用在云环境中的表现，发现并修复潜在的性能瓶颈和错误，从而保障系统的稳定性。

3. 优化资源利用率

通过收集应用的性能数据，可以对资源的使用情况进行分析，实现资源的合理分配和优化利用。

4. 持续迭代与优化

可观测性体系建设和数据挖掘是一个持续的过程。企业应不断收集反馈，优化体系架构和数据处理方法，实现体系的持续迭代和提升。同时，关注行业新技术、新理念的发展，将先进经验融入自身建设中，保持体系的竞争力。

可观测体系建设完成后存在的问题和挑战​

很多团队在完成了一定规模的可观测性体系建设后，却在具体落地推广，乃至实际价值体现上都遇到了阻碍，这些问题和挑战主要体现在两方面，管理层面与技术层面：

管理层面的挑战​

技术能力的不均衡​

团队内技能水平的差异导致高级工具和数据的利用率低下。可观测性体系建设完成后，需要将其向各相关团队推广，期望能帮助各团队提效，协助开发团队排查定位问题。

但实际情况下，往往把可观测工具提供给开发团队后，一方面业务开发团队使用工具存在学习使用成本，另一方面不是所有开发都有能力看懂和定位问题。这需要有平台或工具提供整合能力，来解决人员能力差异性。

经验知识难以传递​

缺乏有效的机制将高级用户的经验和知识快速传递给新手或非专家用户。导致仍旧是依靠团队专家和骨干才能完成诸如故障排查等工作，团队内部长期存在差异性。

故障响应的差异性​

在发生故障时，需要快速有效的响应，但技术水平不一致可能导致延迟处置，甚至处置结果不一致，这种差异性也导致不利于故障响应流程的标准化和故障处理手段的规范化。

技术培训和能力提升存在成本​

提升团队整体技术水平需要大量的时间和资源投入，且往往是一项需要长期坚持的工作，只有这样才能逐步对齐各团队间对于可观测性工具和数据的理解和使用水平。但仍旧会存在长时间不使用导致的生疏问题。

技术层面的挑战​

工具使用和指标含义都会生疏遗忘​

对于一些团队来说，可观测性工具并不是需要经常使用，加之其存在一定的学习成本，所以会导致每次使用的时候都得学习或者咨询专家。同理对于一直较深入的指标数据，其具体含义也会遗忘，使用的时候也需要查阅相关文档，这都加大的使用门槛。

使用方式和术语不统一​

对于工具的使用和可观测数据的理解，不同团队都有其各自的使用场景和理解，这也导致了需要团队协作时增大了沟通成本，例如用户中心的团队使用Skywalking，负责消息推送的团队使用了OpenTelemetry。

故障响应的差异性​

在发生故障时，需要快速有效的响应，但技术水平不一致可能导致延迟处置，甚至处置结果不一致，这种差异性也导致不利于故障响应流程的标准化和故障处理手段的规范化。

工具和标准的不统一​

作为当今热门话题之一，各类可观测性工具及产品百花齐放，导致很多团队为了建设可观测性而不停的追热点，忙于工具的更新换代，方法和思路越没有同步进行更迭，更没有能够真正挖掘出可观测数据的价值。

需要更先进的工具和方法挖掘可观测性体系价值​

Kindling-OriginX 通过Trace-profiling关键数据，以专家经验串联起来所有的可观测性数据，并推理成故障结论，最大程度发挥可观测性数据的价值。通过推理分析能力来平衡团队内的技术能力差异，确保每位团队成员都能有效利用可观测性数据，从而提升其建设价值的认可。

很多企业可观测性数据上了很多，但是推广效果不是很好，价值体现不佳。其主要原因是故障并不是经常发生，所以导致用户对于可观性工具使用生疏，加上一些疑难杂症的故障需要看深入的指标，这些指标含义不用就会忘记。这都需要有更先进的工具对数据指标进行提炼分析，直接给出可解释的结论。

• 简化的操作界面

  为所有技术水平的用户提供易于理解和操作的界面，降低使用门槛。直接根据故障结论进行预案执行。

• 自动化智能故障推理

  利用 eBPF 技术与自动化 Tracing 分析将多而杂的链路数据、指标数据、日志数据转化为直观的故障分析报告，无需深入的专业知识即可理解。

• 最大化可观测性数据价值

  自动关联各类可观测性数据，完成可观测性数据价值挖掘。

• 内化的排障知识库

  既是推理引擎，也是一个排障专家经验知识库，借助专家经验知识库平台能力能够迅速提升团队能力。

结语​

本文探讨了可观测性体系的建设的意义及其根本目的，同时随着可观测性体系的建设也遇到了很多问题和挑战，对于这些问题和挑战都需要更先进的工具和方法，这样才能够充分挖掘和发挥可观测性工具和数据的价值。

在实践中，应当持续优化可观测性体系，确保数据的全面性和准确性，同时不断提升数据处理和分析能力。这不仅需要技术的进步，更需要方法的革新，一方面将可观测性融入到我们的开发和运维文化中，另一方面通过使用诸如 Kindling-OriginX 的创新型工具里帮助快速提升对于可观测性数据的使用水平，帮助提高团队综合能力。

云原生常见可观测性工具的用法​

Tracing​

Tracing 可以追踪一次用户的请求，从而大致定位问题节点。如果运气好，是可以直接呈现某段代码的问题，比如问题就是SQL语句慢，或者执行了非常多次的redis操作导致整个请求慢，但是仍然有很多的时候只呈现了 Controller 方法执行时间长。

Logging​

如果请求出现错误，在整个 Logging 体系中搜索错误日志是很快能够定位出错误的原因的，但是如果是请求发生了慢的现象，就得结合 Tracing。Tracing 基本定位到某个Controller 的问题，日志提供进一步的问题，排查到底是为什么慢，能否排查出问题取决于日志记录完备情况，所以经常出现的情况是补充日志进一步排查问题。

Metrics​

通过 Metrics 中的SRE黄金指标能够很快确定业务是否正常，是否需要人为干预。但是一旦到某个业务慢，通过tracing和日志也没有发现直接线索，这个时候就只能通过 Metrics 找到有问题节点资源饱和度指标，看各种指标异常，不断地猜测试错验证了。

这里面存在两个大的问题：工具集成性差和盲区导致排障困难​

集成性差是工程性问题，是次要问题​

根据前文提到 Tracing、Logging、Metrics 工具在不同场景下使用，在不同工具之间跳转很麻烦会导致排查故障效率不高，但这是个工程问题，很多开源项目都在致力于解决这个问题。比如 OpenTelemetry 社区就致力于解决这个问题，会将三者从不同的线头糅合成一个线头，包括很多商业工具也都在界面跳转等易用性上发力，这个问题终将能够解决。

盲区是理论问题，是主要问题​

盲区从理论上分析就存在的，不管是何种可观测性工具都没有办法完全还原程序的执行过程。Tracing 理论上就不可能针对每行代码执行都做插桩，因为会导致程序的执行性能下降很快。 Skywalking 有 trace-profiling 技术，目标就是动态探测某个程序在干什么，这个有一定的价值，能够发现用户代码层面的盲区。

国内使用很广泛的 Arthas 也是起着类似的作用，就是发现用户代码层面的盲区。国外一些在线debug工具，lightingRun 等工具也是往这个目标努力。

用户代码盲区并不意味着真实的程序执行盲区​

程序执行过程是用户代码调用公共库、公共库调用JVM虚拟机代码、然后触发glibc库，最终触发syscall。

现有工具理论上也只是工作在用户代码和公开库之上来帮助用户理解程序执行过程。

打开用户代码盲区之后仍然存在哪些可能的盲区​

• 用户在代码层执行一次带域名的http请求，实际在glibc中会分成两次网络请求，一次是获得dns解析，一次是真实的网络请求。用户代码层面无法理解到底是如何执行的。

• 程序执行过程中，由于CPU时间片使用完，无法获得CPU执行，用户代码层面会将等待CPU时间片执行时间算成代码执行时间

• 隐藏锁的使用，前文介绍了用户代码不可能对每行代码都做插桩，这样就会导致某些代码执行过程中可能在调用过程中使用了锁，但是对于用户而言是完全无意识的。典型就是Java常用的池化技术，连接池、线程池都是用锁来确保逻辑的正确执行。

• 背锅的网络质量，用户代码调用网络发送代码，网络数据真的发送出去了吗？程序这个时候如果执行了GC操作或者CPU时间片用完了呢？从用户代码和日志层面看出应该是发出网络数据了，但是中间可能存在各种原因导致网络数据发送是滞后的，开发人员会倾向于认为网络质量有问题，但是网络运维人员发现不了网络质量问题。

如何才能在理论上真实还原程序执行过程，打开所有盲区​

学习过操作系统的同学稍微回忆下基础知识，从操作系统层面看程序的执行过程，才是程序的真实执行过程，这里面是没有任何遗漏的。重点回忆下图。 程序代码是以线程为载体进行执行，线程执行过程中可能会因为disk、sleep、lock、idle等各种原因放弃CPU上执行转入等待状态。 等待事件完成之后，线程状态变成Runnale等待cpu调度，如果此时CPU资源紧张，就会出现很长的等待时间。 开源项目 Kindling 的 trace-profiling 就是利用eBPF获取各个点位信息，同时结合Trace，真实地还原出程序的执行过程。从 Kindling 的 trace-profiling 去看trace的完整执行过程，每一个毫秒都知道程序在干什么。

Kindling-OriginX 利用trace-profiling理念构建故障推理引擎​

Kindling-OriginX 相比于 Kindling 开源探针而言，使用Rust语言完全重构了eBPF探针。主要目的是获得更好的性能和稳定性。Kindling 开源探针使用go语言，由于go gc的存在，导致内存资源消耗相对而言比较大，而且go gc的时间不可控。 Kindling-OriginX 商业产品定位为故障推理引擎，通过分析各种开源工具的数据，补充 trace-profiling 的指标，比如通过 trace-profiling 已经能够看出网络执行慢了，这个时候通过补充网络质量指标如RTT、重传等进一步确认网络到底为什么慢。

Kindling-OriginX 完美解决集成性问题，同时彻底消除所有盲区​

Kindling-OriginX 的故障报告中，完成了相关指标，日志和tracing的完美集成，只呈现用户需要看的故障传播链路分支和指标，旁路无关分支和故障不相干指标也不会呈现，日志也是故障时刻前后的相关节点日志。同时利用 eBPF 结合 trace-profiling 技术打开程序执行和系统调用盲区，从根本上彻底还原程序执行过程。 故障推理引擎利用智能算法结合 trace-profiling 自动化推导出故障根因，想更多了解 Kindling-OriginX，请点击阅读原文访问 Kindling-OriginX 官方网站。

在线系统的稳定性和可靠性是企业数字化转型成功的关键。然而，由于云环境和系统演进的复杂性，故障的发生几乎不可避免。本系列文章将对在线系统可能遇到的全栈故障进行分类，并结合网上的案例分析，对比常规分析诊断手段与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小时。经过现场工程师的快速响应和临时调度,负载得以重新分配,服务逐步恢复。但由于高峰期直播中断,给平台带来了可观经济损失和品牌声誉影响。事后分析发现,除了流量突发之外,负载均衡器在高压力下表现异常也是导致故障的重要原因。

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

---

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

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

使用难度高​

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

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

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

建设难度高​

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

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

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

每逢假期、周末，总是被各种排障会和线上问题折磨，做什么都做不进去，也没法好好休息……

常听身边的同行们这样描述自己的假期。说实话，这感觉我可太熟悉不过了，因为这状态困扰了我好几年……

不管你是正吃着火锅还是唱着歌，只要服务器有故障，百米冲刺回到电脑前。“我曾经跨过山河大海...”满大街找网吧，只为轻敲那几个命令。格子衫、双肩包，出门时刻背电脑，这样还怎么好好玩耍。

刚刚过去的春节假期是一个难得的休息和充电的机会，然而，由于程序员的工作性质，我们常常会面临一些不一样的挑战，常常由于线上业务稳定性要求和担心出现bug，很难真正度过一个没有烦恼的假日。

经常是好不容易到了假期，工作项目也暂时有所舒缓，想回趟家或者出去走走，一想还要带电脑回，临时都可能要处理报警，买票的欲望就会随理智渐渐消退，依旧选择原环境待上几天。

---

以前和朋友闲聊常常互相调侃到：只要你是名程序员，那么，你的电脑就比女朋友重要。你可以出去玩不带女朋友，但是你不能抛弃电脑！

“男友是程序员，和我出去约会拿着电脑，有紧急情况处理就带我去咖啡馆，他方便处理问题。还有一次，我们去内蒙古旅游，进沙漠他都背电脑，他说你不懂，带着电脑有安全感，长剑在手，谁与争锋！”

---

北上广深通勤时间普遍都要很久，在地铁上写代码这事已经算是比较常见了，尤其是线上如果出了问题，有时候直接在马路上、垃圾桶上开始处理问题。

---

地铁上一大哥正在改bug

---

为了马上处理问题，采取了面向红绿灯编程

---

婚礼上，一样可以加班扩容改bug

---

夜晚的街头，一样可以改bug

---

我想各位同行们看完这些段子在内心哈哈无奈自嘲一笑的同时，回想自己吃着火锅改bug，爬着山被紧急拉进故障处置群里的种种场景，也是有着些许的无奈。每一个项目的上线及平稳运行，是所有人员起早贪黑、披星戴月、夙兴夜寐、通宵达旦、夜以继日、废寝忘食的工作换来的，但这也让大家想到假期总会忐忑不安，难以好好休息，过一个没有烦恼的假期。

随着技术的发展和各种工具的完善，Kindling-OriginX 故障推理引擎通过专家智慧经验精准梳理各类分散监控指标与日志，自动化 Tracing 关联分析生成可解释的故障根因报告，为故障排查提供标准化、可行动、可解释的自动化排障流程。让bug修复、根因定位、团队故障定界、协作排障都将变得简单清晰，不用被休息日的OnCall骚扰，不再为无尽的排障协调小组群而烦恼。希望借此能够将大家解放出来，让之后的每一个假日都没有烦恼，好好恋爱，享受美食，全身心的体验运动后酣畅淋漓。

传统排障方法的局限性​

传统故障排查的痛点​

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

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

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

这些痛点的根源在于我们所使用的指标大多是结果性指标，指向性不明确。例如，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

故障注入使用指南