kindlingx的博客

过去两年间，大语言模型已逐步进入可观测性领域。ITBench SRE Agent与OpenDerisk等项目正在探索自动化根因分析的技术路径：通过向模型输入来自分布式系统的metrics、trace、log，由模型推断“哪个主机、哪个服务、哪条调用链”最可能是故障根源。

AI Agent重塑可观测性：Syncause智能故障分析平台 在复杂系统故障处理中，传统人工排查方式已面临瓶颈。Syncause作为AI驱动的故障分析智能体，通过三个关键阶段重构故障处理流程：快速定向锁定问题范围、紧急止血提供恢复方案、深度追因定位根本原因。该平台能自动关联多源数据（指标/日志/链路等），集成主流可观测工具，并以对话形式输出分析结果。目前提供沙盒环境供测试，支持故障模拟与交互式排查体验，旨在通过AI技术显著提升故障处理效率，简化运维复杂度。

摘要： eBPF技术为AIOps根因分析提供了新思路。最新论文《eBPF-Based Instrumentation for Generalisable Diagnosis of Performance Degradation》验证了通过eBPF采集线程级内核资源交互数据（如调度、锁竞争、IO等待等16类指标），能够实现跨语言、跨系统的性能瓶颈诊断，无需依赖应用日志或Trace。该方法通过追踪线程依赖链与资源交互路径，精准识别CPU争用、磁盘瓶颈等问题，且解释性强、开销低。这一研究为基于系统行为观测（而非数

LLM 友好的数据结构：精心设计拓扑和指标结构，提升 AI 理解准确性。eBPF 驱动的数据关联：自动关联 Trace, Log, Metrics 及系统上下文。预处理与模式提取：将原始数据转化为包含统计意义的指标和模式。API 级业务拓扑：细化服务调用图至 API 级别，并按业务入口分组。因果性北极星指标：基于 eBPF 实现请求耗时精确分解，直击性能瓶颈。

APO 1.5.0版本全新推出的智能体工作流功能，让运维经验不再零散！只需将日常的运维操作和故障排查经验转化为标准化流程，就能一键复用，效率翻倍，从此告别重复劳动，把时间留给更有价值的创新工作。更贴心的是，APO无需改造现有监控系统，轻松对接即可使用，真正实现“开箱即用”。下面带大家快速上手这一功能，先从官方内置的实用工作流开始体验！

Docker通过封装程序执行类库引爆了云原生技术革命，我们相信在人工智能时代，数据结合经验知识封装而成的Agentic workflow将引爆可观测性革命。

DeepSeek在理解和处理可观测性的各类数据上有着较高的准确率，能够较好地理解专家规则并按照规则分析数据，且具有高性价比的价格，尽管偶尔出现数据幻觉，但经过设计能够达到较高的准确率。这种现象在分析微服务拓扑结构时尤为明显，例如在基于“train-ticket”场景的测试中，简化了复杂的微服务调用关系，仅保留最基本的业务节点进行测试，DeepSeek有时仍会输出一些如“ts-payment-service”这样实际上并不存在于真实数据中的服务名，但这些名称又似乎与“train-ticket”有关。

可观测性数据关联是指将系统中不同来源和维度的可观测性数据（如日志、指标、Trace）关联起来，形成一个完整的监控视图。通过这种关联，我们能够更全面地理解系统的行为和性能，尤其在故障排查时，能够实现更加精准的定位。数据关联方式的选择直接影响故障排查的效率、准确性以及可视化效果。随着分布式系统的复杂性增加，合理的数据关联方式在可观测性中变得尤为重要。通过将不同来源和维度的可观测性数据（如日志、指标、链路等）进行有效关联，我们能够更全面地诊断系统故障、提高问题定位的准确性，并减少噪声带来的干扰。

而真实的情况故障传播链路在basic-service这里就可能不再往上传递，ts-travel2-service的告警和ts-route-service是没有关系的，但是传统基于应用服务的拓扑结构是无法区分此种情况。标准化，有价值的数据。这块我们交流下来是用户最有需求的，因为排障的标准化流程缺失，导致严重依赖专家，排障的时间周期并不能如预期完成，也就很难完成业界的1-5-10目标。一条Trace的数据大概2K，也就是几十条的Trace的数据量就将大模型的上下文撑满了，大模型也就没有办法更好的解释数据了。

Kindling-OriginX 并不直接提供 Trace 能力，而是采用接入 Trace 数据的形式，即通过接入目前成熟的 Trace 产品与提供标准接入 SDK 方 式，例如 Skywalking、OpenTelemetry、ARMS 等，利用 eBPF 能力将 Trace 数据进行扩展，将其与底层的系统调用相关联，进而实现整 的可观测性，消除程序执行与 Trace 数据中的盲区。假设极端情况，存在故障的实例的请求时延在 24h 内一直都很高，那么后续的请求也会被判断为正常请求，产生漏判。

当前人为定位故障主要依赖于指标告警，但是现在绝大多数指标反映的程序执行结果，并未对程序执行过程提供更多的信息。举例说明，CPU利用率是程序执行完代码之后的CPU的被使用的反映，内存利用率是程序已经使用内存的执行结果，

Kindling-OriginX 的故障报告中，完成了相关指标，日志和tracing的完美集成，只呈现用户需要看的故障传播链路分支和指标，旁路无关分支和故障不相干指标也不会呈现，日志也是故障时刻前后的相关节点日志。如果运气好，是可以直接呈现某段代码的问题，比如问题就是SQL语句慢，或者执行了非常多次的redis操作导致整个请求慢，但是仍然有很多的时候只呈现了 Controller 方法执行时间长。等待事件完成之后，线程状态变成Runnale等待cpu调度，如果此时CPU资源紧张，就会出现很长的等待时间。

可观测性三大支柱联动性不好曾经询问已经使用可观测性相关软件的用户群体，对于他们来说最需什么功能的时候，很多用户的反馈都是Trace、Metrics、Log三者的联动性不好，是未来想完善可观测性的重要方向。业界有很多专家都在研究这个问题，但是体验效果似乎仍然不好，这里谈下我们的理解，抛砖引玉，欢迎更多的探讨。Log、Metrics、Trace三者集成难题可观测性三大支柱集成难题主要因为以下几点1.缺乏标准与协议在opentelemetry没有成熟的2021之前，很多公司至少已经完成

持续剖析（Continuous Profiling）是一种软件性能优化技术，旨在实时收集程序运行时的性能数据，如CPU使用率、内存分配、线程锁等待时间等。这些数据通常通过在代码中嵌入剖析器（Profiler）来收集，剖析器能够监测和记录应用程序在执行过程中的各种性能指标。持续剖析的目标是帮助开发者理解应用程序在生产环境中的实际运行性能，从而发现性能瓶颈和优化机会。与传统的剖析（通常在开发或测试阶段进行）不同，持续剖析强调在应用程序的整个生命周期内，尤其是在生产环境中不断进行性能监控和优化。

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

另外如果从client角度来看，调用就是rpc封装的函数，这个函数的实现绝大多数是没有问题的，但是也可能出现以下这种情况：client端出现GC，或者DNS寻址出现问题，也就是问题出现在了认知盲区，不知道client可能会出现问题。因为RPC的函数调用被封装成了本地函数调用，有些开发可能都不知道自己调用的函数其实是远程RPC调用，所以他们印象中的程序执行是这样的：client端执行RPC之后，Server端立马响应。在一切正常的时候，图中紫色部分消耗的时间是非常少的，基本可以忽略。

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