2 篇博文 含有标签「LLM」

近两年，大模型（LLM)逐步进入可观测性领域。无论是ITBench SRE Agent还是OpenDerisk，都在尝试用大模型自动化根因分析（RCA）：通过向模型输入来自分布式系统的指标（metrics）、调用链（traces）和日志（logs），由模型推断“哪个主机、哪个服务、哪条调用链”最可能是故障根源。

常见的分析流程模式​

尽管技术路径存在差异，多数方案遵循类似的三阶段流程：

01指标异常检测​

从Prometheus提取RED指标或业务KPI，通过阈值或基线模型识别持续异常的 “组件–指标” 组合，从而缩小可疑范围

02调用链踪拓扑分析​

基于Jaeger获取调用关系，沿调用链查找“异常最靠下游的节点”，避免将下游的连带效应误判为上游根因。

03日志语义验证​

从Loki/Elasticsearch提取相关时间窗口的日志记录，利用 LLM 解析错误码、堆栈信息和上下文，生成自然语言报告并提出修复建议

ITBench将该工作流应用于实时告警，告警触发后自动拉取多维数据，生成根因链路并可直接触发修复命令。

OpenDerisk则采用多智能体协作：在一次 RCA 任务中，由不同 Agent 分别处理指标、调用链、日志，再汇总证据生成最终报告。

对用户而言，这两种方案体验相似：提供三类遥测数据，由AI综合分析，最终输出易于理解的结论。

现实检验：准确率远未达标​

这两个开源项目目前没有对外公布准确率，但论文 OpenRCA 的实验数据表明，这种方法的实际准确率并不理想：

• OpenRCA论文中报告其根因准确率低不足15%
• ITBench虽优化了数据采集与算法，但提升幅度有限
• OpenDerisk虽引入多源交叉验证，仍难以达到生产环境可用标准

即使针对历史故障进行定向训练，性能提升依然有限。

问题题不在模型和算法，而在可观测性数据本身的鸿沟。

可观测性中的“两层数据缺口”​

01生产环境采样限制​

• Prometheus指标常通常以分钟级采样，短时抖动被平滑掉
• Trace受采样率限制，关键调用链可能根本未被记录
• Log依赖开发人员埋点，关键路径常存在覆盖盲区

02分析过程的二次采样​

• 即使原始数据完整，将所有metrics、trace、log输入LLM亦不现实——延迟与成本将急剧上升
• OpenRCA 的论文方案就是典型例子：每分钟仅取第一条 trace 和 log 进行分析，这种策略必然会漏掉关键证据，例如某个瞬间的峰值 trace 或罕见错误日志

这两层采样叠加，使得大模型得到的输入天然是不完整的“拼图”，最终输出的结论更多是相关性推理而非可验证的因果。

可观测性数据的固有盲区​

即使能实现数据完美采集，metrics、traces、logs 也各有盲区：

• Metrics仅显示现象而非根源——Prometheus 只可揭示服务"缓慢"或"错误"，但无法解释原因
• Traces存在盲区——调用链只能反映应用层方法埋点路径，任何未埋点的系统调用、GC 停顿、三方库锁竞争都不会出现在 span 中
• Logs 日志依赖开发者意识——关键路径没打日志，或多个组件同时报错，时间戳精度不足都会让因果关系模糊

这些限制意味着：LLM或许能"理解"所有可用数据，最终仍可能给出的仅是合理的症状解释，而非真正的根因。

实际场景验证​

案例1：数据盲区击败 LLM​

Kubernetes 容器 CPU 限速事故：

• 现象：QPS下降40%，平均延迟上升
• Metrics：Pod CPU 使用率偏低，看起来“系统很闲”，但未采集 throttle 指标
• Traces：数据库、缓存及外部API均正常，应用 span 只是整体变长
• Logs：无错误堆栈

案例2：三方类库内部锁竞争​

• SDK封装了连接池与重试机制
• Trace仅覆盖外层业务调用
• Log 未记录内部锁相关细节

传统Metrics+Trace+Log三件套无法暴露此类隐藏问题。

提高准确度的做法：叠加eBPF数据​

我们的实践表明：模型规模≠ 根因准确率

真正突破来自更深层次的数据采集。

我们利用eBPF技术捕获内核级信号——调度器事件、系统调用、锁竞争与网络重传——针对当前故障现象给出直接的根因，例如“慢了”进一步细化为：

• CPU资源被 throttle
• 网络重传率激增
• 存储I/O等待
• 内核锁竞争

最终给用户的结论是：“应用慢” → “容器 CPU 被 throttle 350ms”这样的确切原因。

我们的架构与集成​

为了帮助团队快速落地，我们在设计上保持了兼容与易用：

• 数据采集：eBPF DaemonSet收集内核级信号，与Prometheus/Jaeger/Loki无缝集成
• 分析流程：BPF 指标筛选 → 调用链推理 → 日志语义确认 → LLM 生成自然语言报告
• 部署模式：支持自托管与 SaaS，两者均可在现有 Kubernetes 集群中无侵入部署

典型场景对比​

技术体验途径​

欢迎体验我们的沙箱演示环境，体验如何将故障排查从数小时的推测转化为分钟级的精准定位。

同时欢迎加入我们的技术社区，共同探讨eBPF与LLM融合的最佳实践。

业界目前使用LLM做根因定位的思路​

基于LLM构建智能体，比如日志智能体、网络数据智能体、Trace智能体。每种智能体负责两个事情：异常检测和自身范围内异常根因数据的推荐。目前很多公司的实际效果还处于实验阶段，还未达到实际生产效果。

目前做法太复杂，复杂体现在以下几个方面：

第一：可观测性的数据属于海量低价值的数据，要针对这些数据依赖AI寻找人能理解的异常太复杂。多数情况是噪音大于实际收益。

第二：多智能体的交互太复杂，而且是建立在第一步异常检测的基础上分析出根因。

我们的思路：

1. 依赖人为经验的基于规则告警和异常检测体系。告警和异常检测是可以对接已有告警体系，实现快速接入落地。
2. 依赖思维链在完成疑似根因节点的识别，这里面专家经验可以调整进化。
3. 依赖北极星指标，利用报告快速确认疑似节点的根因。

用户需求​

从用户需求侧而言，故障根因辅助定位才是需要的。

异常检测的价值太缥缈：​

绝大多数公司内部告警体系已经完善，虽然可能并没有办法覆盖所有的情况，但是基本上都认为已经做到相当充分。

那异常检测的价值就是发现未知的未知问题，就未知的未知问题而言，用户是没有认知的。用户要从未知的未知真实问题中和噪音问题中，区分哪个问题有价值，还是噪音，这个对用户要求太高。

基于规则的异常或者告警已经能实现绝大多数异常检测的目标，而且具有充分的可解释性。所有的规则都可以梳理，并确认，所以这一步我们认为还是基于规则的效果较好。

根因辅助定位是绝大多数用户的需求：​

这块我们交流下来是用户最有需求的，因为排障的标准化流程缺失，导致严重依赖专家，排障的时间周期并不能如预期完成，也就很难完成业界的1-5-10目标。

如何才能实现基于LLM和思维链实现根因辅助定位​

大模型的限制​

可观测性数据是属于海量低价值的数据，而大模型而言是有上下文限制的，目前主流的大模型也只能支持128K的数据。

一条Trace的数据大概2K，也就是几十条的Trace的数据量就将大模型的上下文撑满了，大模型也就没有办法更好的解释数据了。

业界领先者做法​

受限于大模型的限制，所以目前很常见的大模型用法是将某个具体的数据提交给大模型，并请大模型帮忙分析出相应的结论。

• 比如将火焰图数据提交给大模型，请大模型帮忙分析出最长的代码段
• 比如将单次Trace数据提交给大模型，请大模型帮忙分析哪个Span最有问题
• 比如将指标曲线给大模型，请大模型帮忙分析异常时间点

用户期望的需求​

从告警初始就开始使用大模型，而不是人为先筛选出具体的Trace或者具体火焰图数据，然后交给大模型。诚然，基于大模型帮忙解释部分数据是有价值，但是还有很多用户问题是：

“告警啦，我该如何从告警分析着手，在海量数据中找到最能反映故障的Trace然后深入分析这条Trace或者日志、指标，最终确定故障根因”

标准化数据​

标准化，有价值的数据。我们认为将海量低价值的可观测性数据全都丢给LLM，让LLM去算出结论是不现实的。所以我们需要提前从海量低价值的可观测性数据中，先抽象出一套数据，这套数据能够被用来高效故障定位：

第一、能够反应程序调用关系的精准拓扑关系（没有此类数据，故障传播过程无法确定）

第二、成体系的告警，能将所有的告警和异常都关联至程序调用关系中（相互割裂的异常告警，很难综合起来分析）

第三、北极星指标体系 利用前两个数据，确认疑似的根因服务、利用第三个数据实现最终指标级根因的确定

精准拓扑关系 VS 传统拓扑结构​

故障传播在传统拓扑结构存在不确定性，导致思维链规则很难编写。

程序精准的调用关系如下：

程序的每一种URL调用，都能在拓扑中反映出来，这也是Dynatrace 的service-flow功能，目前可观测性相关产品中，也只有Dynatrace与APO实现了这种精准调用关系的拓扑。

传统的拓扑的调用关系如下：

ts-travel2-service->ts-basic-service->ts-route-service

ts-travel2-service->ts-route-service

故障的传播链路只要有ts-route-service有告警，就需要往上排查ts-travel2-service的告警情况。而真实的情况故障传播链路在basic-service这里就可能不再往上传递，ts-travel2-service的告警和ts-route-service是没有关系的，但是传统基于应用服务的拓扑结构是无法区分此种情况。

拓扑成环的问题​

如果一旦拓扑出现成环的问题，就会导致告警的根源很难查找，因为整个环上的所有节点都互相依赖，都可能成为根因节点，就得将所有节点都列为潜在根因节点排查。

传统拓扑结构更大概率成环，因为是按照节点维度，但是实际调用过程业务是不可能成环，因为一旦成环之后，业务就无法正常执行了，只是拓扑结构再生产的时候舍去了某些关键信息才导致拓扑成环。

精准拓扑反应调用关系，虽然理论上无法100%避免成环，但是相比传统拓扑结构而言，绝大部分在传统拓扑结构成环的现象，在精准拓扑结构都不会成环。

拓扑数据太大的处理​

大家都知道大模型对上下文的长度是有限制的，拓扑数据太大了会占据大量上下文，最终导致大模型在推理过程中不能很好的记住拓扑结构，推理工作也就进展不下去。我们采用相似性，对一个大的拓扑进行收缩，确保只有关键的拓扑结构与大模型交互，并不是所有结构都与大模型交互。

利用延时曲线或者错误曲线相似性，将大拓扑结构收缩。

原始拓扑结构

利用相似性收缩之后的拓扑结构：

相似性原理：

只有曲线相似的节点才被考虑进拓扑结构，曲线不相似的节点会被收缩。举例如下图：比如黄线所代表的节点一直很平稳，所以不应该作为疑似节点考虑，可以收缩起来。

告警的数据模型：​

告警的关联方式：

• 应用层告警（URL接口延时异常和错误异常）
• 网络层告警（节点之间连接的网络周期性Ping值异常）
• 基础设施主机层告警（主机的CPU、 内存、磁盘、网卡吞吐量异常）
• 容器告警（k8s事件比如容器killed， 容器重启等异常）
• 错误告警（Java程序使用java Exception，非Java程序，使用日志错误数异常。解决微服务场景中会识别不了错误的场景、将错误封装到error code中，导致http status code永远是200）
• 应用层的告警是直接关联至拓扑结构
• 基础设施层告警，间接关联至拓扑结构，比如主机的CPU高，可能潜在的影响主机上的所有业务，但是并不是主机上所有的业务就会一定受到影响，所以说基础设施告警是间接影响应用层的告警
• 网络层告警，间接关联至拓扑结构，只要TCP四元组出现ping延时异常，即认为应用延时和错误可能受到网络的潜在影响，同理也是间接影响，并不能认为网络一旦出现抖动，应用延时就一定有问题
• 容器告警，k8s相关事件也间接影响应用的执行
• 错误告警，为了能更好识别应用错误，因为微服务框架导致错误识别不了，http statuscode永远为200，所以需要额外错误告警的弥补错误场景识别不精准的问题

基于LangChain的思维链，利用大模型完成根因推理。

我们的目标是提供一个可以不断完善的根因推理思维链条，所以每个规则其实都可以修改，规则一定要符合当下人员排障的惯性思路。

可进化的规则​

目前我们提取了符合用户习惯的常规规则，这些规则可以根据不同的专家经验不断完善。

规则：

从应用接口层告警（如 URL 接口延时异常、错误异常）出发。沿着业务入口的拓扑结构，从上游向下游每个节点依次追踪（使用拓扑图数据，不要搞错上下游）。 请输出推理过程
    在追踪过程中分析每个节点： 如果存在接口层告警，继续向其依赖的下游节点追踪，该节点在两种情况下作为疑似根因节点，第一该节点存在其它类型的告警，第二其下游所有节点没有1类型接口告警，其它情况该节点都不是疑似根因节点。
    如果没有接口层告警，停止追踪，返回上一级节点，当前节点排除。 
    在追踪过程中，对于每个有1类型接口告警的节点： 
      检查是否存在其他类型的告警（如应用层、容器层、基础设施层告警），如果存在，则该节点是疑似根因，记录并继续分析下游节点追踪。 
      如果不存在其他告警，同时该节点所有下游节点都不存在1类型接口的告警，则该节点是疑似根因节点。
      如果节点就是是最下游的节点，同时节点也存在1类型接口告警，该节点也是疑似根因节点。 
      最下游节点定义：依赖链路上没有进一步下游依赖的节点。 最下游节点如果有告警，是疑似根因的优先候选。
    回答格式要求给当前规则推理过程，不用附带完整数据，需要给出精简数据。

解释：

上游节点的应用告警是由下游传递导致的，所以上游节点不是疑似根因节点

示例中应用告警传递过程 ts-route-service -> ts-travel-service -> ts-route-plan-service -> ts-gateway-servcie

规则：

上游节点的应用告警是由下游传递导致的，所以上游节点不是疑似根因节点
 示例中应用告警传递过程 ts-route-service -> ts-travel-service -> ts-route-plan-service -> ts-gateway-servcie。

新增发生在：11：19：35秒

已解决发生在：11：20：35秒

规则：

如果某个节点发生异常，但是上游节点未发生应用异常告警事件，可以将这个节点及其分支全部排除

解释：说明这些告警都是干扰项，可以排查

基于北极星的闭环确认根因​

当我们基于规则疑似故障根因节点之后，根据北极星指标可以确认疑似根因节点到底发生了什么情况，导致的问题。

北极星指标曲线是利用eBPF技术，将请求延时完整的拆解成了主要的几个故障方向，当延时变化之时，可以根据哪个分项的变化曲线最相似，从而判断疑似故障节点的故障方向。

从这张图中，可以很快确认程序后期的延时上升主要的原因就是lock_gc_time的上升导致的,但是在最开始程序波动的原因是由于net-workTime导致的。

如果这个时候有CPU-IO wait高，说明这些IO异常对程序的执行过程其实没有任何影响。

最终的证据报告​

最终通过关联可观测性数据，形成最终的证据报告，说明该问题。

点击下方链接观看演示视频：通过大模型对话来分析告警事件

(https://www.ixigua.com/7441033779788907046?utm_source=xiguastudio)

APO介绍：

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo