跳到主要内容

Syncause 智能体推理视图:让根因分析可验证、可信任

· 阅读需 7 分钟

cover 图

我们的 AI SRE 智能体 Syncause 致力于通过AI技术提升故障诊断效率。前几天,我们发布了根因分析场景的准确率测试结果。在Train Ticket微服务系统的根因定位任务中,Syncause的AC@3准确率(前3候选根因命中真实故障的概率)达到96.67%,成为目前公开可复现的最高水平。

那么,准确率高就足够了吗?几年前AIOps也承诺较高的根因分析准确率,但在实际落地中因缺少可解释性而不被信任。所以,高准确率仅是起点,在实践中,AI结论的可信度与可验证性同样关键。准确率再高,没有可见的证据,也难以建立真正的信任。

准确率之外的信任困境

生产环境故障的决策成本极高,工程师无法将关键判断权交给一个“不可解释”的系统。即使AI输出正确结果,若无法追溯其推理路径,仍可能导致以下问题:

  • 信任缺失:结论缺乏证据支撑,难以形成团队共识;
  • 重复验证成本:工程师需独立复核AI结论,抵消效率优势;
  • 风险控制失效:无法复盘错误推理逻辑,阻碍系统迭代优化。

为此,Syncause推出推理视图功能,通过结构化、可视化的推理链路,实现AI诊断过程的全透明化。

推理视图详解

树状结构化证据展示推理路径

在 AI 根因分析中,如果工程师只能看到最终结论,就很难判断其背后的验证路径。而复杂系统的诊断往往涉及多层级、多假设的推演过程。

推理视图通过 树状结构 展示 AI 的推理步骤,包括:

  • 假设生成:基于故障上下文提出初步假设,如基础设施资源问题、依赖服务问题、数据库问题等;
  • 验证步骤:通过指标、日志、链路或事件验证假设的合理性;
  • 状态标记:节点状态(正常/异常)直观反映诊断进展。

异常路径通过高亮标记快速定位关键问题,从而帮助工程师快速锁定关键路径。

1 图

可视化证据:即时验证上下文

推理链条的可信度依赖证据质量。因此,我们将每个推理节点都设计为可展开查看证据来源和内容,包括指标曲线(如CPU利用率、请求延迟)、错误日志、上下游调用链、数据库慢查询日志等。

所有数据来自实际监控系统或日志源,在这里可以快速判断 AI 的推理是否符合事实,而不必跳转回原有的监控系统中进行验证。

2 图

防幻觉:算法与大模型的协同

在故障诊断中,避免幻觉比生成答案更重要。为实现这一点,我们采用了混合式的推理架构:

  • 由确定性算法执行异常检测:采用统计方法、规则、特定模型,确保不会“编造”异常
  • 大模型负责抽象理解、上下文串联与推理方向选择:负责抽象推理与上下文关联分析,生成可解释的诊断路径。

两者的结合既保证了诊断的严谨性,又保留了大模型对复杂场景的泛化能力。

延伸价值:从可信验证到效率提升

推理视图不仅解决信任问题,更通过降低重复验证成本提升整体故障排查效率:

  • 减少人工复核:AI已验证的路径可直接作为诊断参考;
  • 支持流程自动化:未来将支持自定义检查流程的集成,AI自动执行标准验证步骤。

演示

当用户抱怨访问速度变得很慢,我们可以第一时间向Syncause提问:“用户抱怨系统访问很慢,帮我做根因分析”,Syncause会马上响应并开始查询数据进行分析。

3 图

AI通过检查指标、链路等数据执行多步骤分析,得出结论,是由于ts-price-service的CPU使用率异常升高,导致延时影响了整体,在“结构化证据”中可以查看推理路径:

4 图

AI针对服务检查了依赖服务、依赖数据库、基础设施和自身代码执行情况,发现CPU资源升高是罪魁祸首。

共建AI运维新范式

我们相信,AI在运维领域的终极形态不是"替代工程师",而是成为可信赖的智能协作者。它的每一步操作都要有记录,每一个结论都要有依据,每一次失败都可以复盘。

而这,才是人类与AI协作最该有的样子。

Syncause 目前已经开放注册,如果你希望在真实场景中试用,欢迎通过微信联系我们或通过官网注册使用。

我们期待与先进团队一起验证、改进并推动这项能力在实际生产环境中的落地。


比论文更准:Syncause 在根因分析准确率上实现突破

· 阅读需 8 分钟

cover 图

在最新的 Train Ticket 微服务系统根因分析测试中,Syncause 根因分析准确率(AC@3)达到 96.67% —— 在同类测试场景中,这一数字是目前能公开复现的最高水平。

AC@k (Accuracy@k) 是学术研究中衡量算法准确度的指标。  含义是:当系统推荐前 k 个最可能的根因时,真实根因出现在这前 k 个结果中的概率。

换句话说,当其他算法仍在“猜”,Syncause 已经能在前三个候选根因服务中准确命中真实故障原因

根因分析难上加难

在微服务与云原生体系中,根因分析(Root Cause Analysis, RCA)被称为运维自动化的“圣杯”。

系统出现异常时,你需要在数十个微服务、数千个指标和海量日志中找出真正的罪魁祸首。

过去几年,学术界与业界都在尝试利用机器学习、图分析、时间序列建模等方法自动化这一过程,但现实问题依然突出:

  • 模型需要在真实生产环境中长时间训练与调优;
  • 算法泛化能力差,新环境迁移困难;
  • 机器学习算法的分析结果缺乏可解释性;
  • 离线算法无法适应实时运维场景。

因此,虽然已有不少论文成果,但“真正能在线落地的 RCA 系统”仍然凤毛麟角。随着大语言模型(LLM)推理能力的提升,这一问题出现了新的突破口。  Syncause 基于 LLM 构建了智能 RCA Agent,让根因分析变得“即装即用、实时可解释、可验证”。、

学术论文指标 vs Syncause 实测结果

我们研究了 RCA 领域中最具代表性的几篇论文结果:

研究 / 方法数据集指标最佳准确率
ONLINE MULTI-MODAL ROOT CAUSE ANALYSIS[1]Train TicketPR@5 (≈AC@5)~40%
RCAEval[2]Train TicketAC@370~88%
OPENRCA[3] (LLM-based)独有数据集AC@1~15%
GALA[4] (Graph-Augmented LLM)OnlineBoutiqueAC@360~78%

以上所有对比数据均来源于各论文公开结果或复现实验。

Syncause 分别在 OnlineBoutique 和 Train Ticket 两个测试场景上进行复现,在我们特有的 eBPF 数据的辅助下,AC@3 准确率均达到 96.67%

模型 / 方法案例数AC@1 准确度AC@3 准确度
grok-4-fast-non-reasoning3086.67% (20/30)96.67% (29/30)
qwen-plus3090% (27/30)96.67% (29/30)

同时,当我们关闭 eBPF 辅助数据,仅使用传统指标与日志时,AC@1 下降至 60%,AC@3 下降至 90%——这体现了 eBPF 数据在提升根因分析准确率中的关键作用

在这些结果中可以看到一个明显对比:Syncause RCA 在保持在线、无需训练的前提下,准确率超越当前主流研究方法

测试案例中主要包含高CPU使用率、高内存占用、网络延时、网络丢包等故障,我们仍然在不断扩充案例场景,后续将持续公开测试结果。


为什么 Syncause 能做到?

eBPF 驱动的底层观测能力

Syncause 基于 eBPF(Extended Berkeley Packet Filter) 技术实现实时捕获内核级事件,如系统调用延迟、锁等待、IO 阻塞等,形成比传统指标更直接的因果线索。  

当 LLM 接入这些“真实执行路径”信息后,能更精准地判断问题根因所在的服务与资源。

LLM + 可观测数据的因果推理架构

Syncause 不依赖固定训练模型,而是通过 LLM 的语义理解能力,对多模态数据(Metrics、Logs、Traces、eBPF)进行因果推理:

  1. LLM 生成可能的根因假设;
  2. Syncause 验证这些假设与观测数据是否一致;
  3. 将推理路径可视化展示给用户。

即使分析结果不是百分百准确,Syncause 仍然展示推理链条,让用户理解“系统为什么这样判断”。

这种“解释性推理”让 RCA 不再是一个“黑盒模型”,而是一场透明的推理过程。

可复现、实时、无需模型训练

与传统机器学习方法需要长时间训练不同,Syncause 在任何环境下即装即用

在基准测试中,Syncause RCA 能够直接在线推理,单故障分析案例平均延迟 < 3 分钟,成本低于0.06美元。

向更智能、更透明的 AI SRE 迈进

我们相信 RCA 领域下一步的发展方向,不是单纯提升准确率,而是让分析过程变得可验证、可比较、可重现

Syncause Benchmark 结果已在 GitHub 上开源,搜索syncause-benchmark即可找到。

我们的愿景不仅是打造一款产品,而是推动整个行业走向透明、可验证的 AI SRE Agent 生态。

欢迎关注!未来版本将持续加入更多内容:

  • 更多 LLM 模型性能对比(Claude, GPT, Gemini 等)
  • 新的数据集与更复杂的分布式系统场景
  • 因果验证与信任度量化指标

结语:AI正让根因分析重新发生

系统问题总会发生,但分析方式正在改变。AI 让我们离“智能运维系统”更近了一步。

Syncause 的核心不是取代工程师,而是让每一次故障分析都有迹可循。

即使结论不完美,过程仍然可验证、可学习、可改进。

如果你希望亲自验证这些结果、或在你的系统中体验智能 RCA,欢迎联系我们或访问官网进行试用: 👉 https://syn-cause.com


参考文献:

[1] Lecheng Zheng, Zhengzhang Chen, Haifeng Chen, Jingrui He. 2024. Online Multi-modal Root Cause Analysis. arXiv preprint arXiv:2410.10021.

[2] Luan Pham, Hongyu Zhang, Huong Ha, Flora Salim, and Xiuzhen Zhang. 2025. RCAEval: A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data. In The 2025 ACM Web Conference (WWW). 777–780.

[3] Junjielong Xu, Qinan Zhang, Zhiqing Zhong, Shilin He, Chaoyun Zhang, Qingwei Lin, Dan Pei, Pinjia He, Dongmei Zhang, and Qi Zhang. 2025. OpenRCA: Can Large Language Models Locate the Root Cause of Software Failures?. In The Thirteenth International Conference on Learning Representations.

[4] Yifang Tian, Yaming Liu, Zichun Chong, Zihang Huang, Hans-Arno Jacobsen. 2025. GALA: Can Graph-Augmented Large Language Model Agentic Workflows Elevate Root Cause Analysis?. arXiv preprint arXiv:2508.12472.

LLM + 可观测性根因分析:方法、真实效果与数据鸿沟

· 阅读需 9 分钟

cover 图

近两年,大模型(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技术优势
容器CPU throttleMetrics 平均值被平滑,Trace 无法感知捕捉每次调度延迟和 throttle 时间
数据库锁等待应用 Trace 仅显示“慢查询”捕获内核锁等待与线程阻塞
内核TCP重传仅见请求超时捕获重传计数与网络抖动
JVM GC暂停需应用层埋点直接检测内核调度停顿

技术体验途径

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

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


1 图

我们这样做「故障分析AI智能体」,邀请你来试试

· 阅读需 6 分钟

cover 图

在可观测性领域,我们始终在追问一个问题:当系统出故障时,为什么定位和恢复还要这么复杂、这么慢?

我们从一开始就在做一件事——降低产品使用门槛,让你在最紧急的时刻,能用最快的方式找到根因、恢复业务。

我们不断琢磨,不断实验:到底怎样才能真正做到?

渐渐地我们发现,如果继续沿用传统的可观测性思路,终究会撞到瓶颈。因为人力去关联、比对、排查的方式,已经跟不上复杂系统的节奏。

而这正是 AI Agent 能够改变的地方。

AI 的价值,不只是“帮你分析链路数据”,而是彻底改写人与可观测性工具的关系。它可以主动思考、串联不同来源的线索,把人从一堆碎片化的数据里解放出来,直接对话式地给出分析和方向。

这就是为什么我们坚信:未来的可观测性,一定会被 AI Agent 重塑。

基于这个想法,我们开发了故障分析智能体:Syncause


故障发生时,AI Agent 能做什么?

让我们先理清楚故障处理的本质。当故障发生时,我们的处理过程通常是:

发现 → 响应 → 诊断 → 恢复 → 复盘。

但在实际的故障诊断和解决过程中,我们发现可以分为三个关键阶段:

第一阶段:快速定向。 故障发生了,但到底是什么类型的问题?是应用层的bug?数据库压力过大?网络连接异常?还是外部依赖服务挂了?这个阶段的目标是缩小排查范围,找到大致方向。

第二阶段:紧急止血。 知道了问题方向后,如何最快恢复业务?回滚代码?切换流量?扩容资源?还是重启服务?这个阶段的核心是快速止损,让用户能够正常使用。

第三阶段:深度追因。 业务恢复后,找到导致故障的根本原因。是哪一行代码?哪个配置项?哪次变更?这个阶段是为了彻底解决问题,避免再次发生。

当然,现实往往没有这么理想化。简单的问题可能在第一阶段就找到了根本原因,复杂的问题可能需要多个轮次的循环。但这个框架帮助我们更清晰地思考 AI Agent 应该解决什么问题。

Syncause 目前主要聚焦解决前两个阶段的问题:

  • 它会先帮你快速缩小范围,告诉你问题出现在应用或主机上;
  • 它会自动把指标、日志、链路,甚至 eBPF 收集到的内核层面信号,串在一起;
  • 它会判断出问题是 CPU、磁盘、网络,还是更高层的调用;
  • 然后,它还会给出切实可行的恢复建议,让你在压力最大的时刻,能快一步止损。

1 图

另外,Syncause 被设计成一个开放的平台,能够集成各类可观测产品的数据。无论你用的是Prometheus、Jaeger、Grafana、ELK,还是商业化的APM工具,Syncause 都能帮你把这些分散的数据整合起来,统一分析。


我们准备了问答环境,你可以亲手试试

Syncause 还在内测阶段,但我们搭建了一个 Sandbox 环境可以直接测试效果。

Sandbox 里面跑着一组测试应用,这些应用会“故意”出现各种问题。你只需要直接跟 Syncause 对话,让它来帮你分析原因、提出方案。

甚至,你也可以自己重新部署一个应用,然后注入不同的故障,看看 Syncause 如何一步步陪你走过排查的过程。

我们想把 Syncause 打造成一个真正对你有用的产品。所以特别欢迎你来试用,甭管是建议还是批评,都尽管告诉我们。

如果你感兴趣可以加入 Waitlist,成为早期用户与我们共创,和我们一起把这个 Agent 打磨到极致,我们会提供永久免费使用

点击链接:https://sandbox.syn-cause.com 即可进入Sandbox环境。


APO v1.12更新:日志采集兼容containerd v2;数据采集优化;多项问题修复

· 阅读需 2 分钟

cover 图

本次 APO v1.12 版本更新带来了以下功能优化和问题修复:

更新日志

⚠️ 兼容性提示

本次 apo-one-agent 的版本更新中对 ilogtail进行了升级,升级后支持在 containerd v2 环境下采集容器日志。如您手动修改过日志采集配置,需要在更新后重新配置;如您使用默认配置,则无需修改,升级探针后会自动适配。

需手动调整的变更内容:

  1. 日志采集配置文件中,所有流水线均需要添加配置: global.UsingOldContentTag = true
  2. 日志采集配置文件中,原文件采集器 file_log 已弃用,改为使用 input_file,具体配置参考loongcollector的官方配置文档: https://observability.cn/project/loongcollector/input-file

功能优化

  • 告警分析工作流中优化分析下游依赖问题,识别下游服务于应用
  • 通过全量日志查询故障现场日志;开启全量日志时,无需重复采集故障现场日志
  • 日志采集兼容 containerd v2 容器运行时
  • 链路追踪探针自动注入兼容 alpine-linux 基础镜像 (兼容musl库)

缺陷修复

  • 修复时间选择器可能无法刷新的问题
  • 修复新增用户时数据组权限未分配问题
  • 修复服务概览告警状态未基于 namespace 过滤器过滤的问题
  • 修复故障报告中数据展示异常的问题
  • 修复 profile-agent 在低版本Linux 上存在 Slice Out of Bound 错误

1 图

APO v1.10.0更新:自动生成故障方向和报告;内存泄漏识别;多集群支持

· 阅读需 3 分钟

cover 图

本次 APO v1.10.0 版本更新带来了以下新功能和问题修复:

更新日志

⚠️ 兼容性提示

本版本新增了集群标识,用于支持按集群隔离采集数据。升级后:

  • 旧数据将归属到“空集群”
  • 新数据将归属到您设置的集群

大部分功能已做好兼容,数据展示不受影响。但部分依赖历史数据的功能,可能因数据分属不同集群,出现数据不连续的问题。可能受影响的功能:

  • 依赖历史数据的告警规则
  • AI 智能根因分析

新增功能

  • AI告警故障方向识别:基于大模型能力自动分析告警潜在原因,智能生成故障方向,提升故障定位效率。

1 图

  • 根因分析报告生成:在完成告警根因定位后,系统将自动生成结构化分析报告,帮助用户更直观地理解告警产生的背景与原因。

2 图

  • 告警分析工作流扩展:新增支持识别内存泄漏场景,并进一步增强对主机高 CPU、内存占用及网络延迟问题的分析能力。
  • 多集群支持:支持集群级别的数据隔离与筛选。安装时可配置数据所属集群,便于在多集群环境中进行精准查询与管理。

功能优化

  • 日志查询性能提升:显著优化全量日志检索性能,加快数据访问速度。
  • 数据组增强:支持嵌套子数据组,提升企业多层级管理能力;同时支持按集群、命名空间、服务名等多维度配置与筛选。
  • 告警分析效果优化:优化 AI 工作流分析策略,进一步提高诊断准确率与覆盖面。

缺陷修复

  • 修复在传统服务器无命名空间场景下,数据无法正确筛选的问题。
  • 修复运行一段时间后可能导致北极星指标丢失的问题。
  • 修复服务端点名称中含特殊字符时,查询接口报错的问题。
  • 修复时区不一致导致历史基线异常的问题,确保故障报告数据一致性。

3 图

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

· 阅读需 8 分钟
Kindling-OriginX
故障根因推理引擎

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

运维的挑战与责任

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

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

AIOps当前技术与输出

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

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

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

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

Dynatrace 效果

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

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

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

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

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

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

Datadog 效果

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

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

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

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

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

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

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

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

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

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

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

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

APO OneAgent 设计思路

· 阅读需 12 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

之前的文章介绍过APO是如何使用Grafana Alloy采集prometheus生态的指标体系。这篇文章介绍APO是如何采集Trace和log的,这两项数据的采集存在以下问题:

  • 日志需要配置采集的日志目录,并不是每个应用的日志目录都非常规范,这就导致配置工作量的增加
  • Trace需要配置针对语言的Agent完成数据采集
  • 在容器环境不管是修改镜像或者使用init Container方式,都有挺多配置的工作

OneAgent的设计目标

OneAgent的设计目标是尽量减少用户的配置工作,尽快的完成数据的采集。在设计过程中,参考了很多的业界先进的技术实现,比如datadog的onestep agent的实现机制,另外重要的就是Odigos这家公司的实现。Datadog不用做更多的介绍,这里简单介绍下Odigos这家公司:Odigos的口号是“Instant Distributed Tracing”,有兴趣可以访问其官网:https://odigos.io/ ,OpenTelmetry 的 GO auto instrument 项目:https://github.com/open-telemetry/opentelemetry-go-instrumentation 就是由该公司捐献的。

Odigos开源的https://github.com/odigos-io/odigos 实现中能够实现以下功能:

  • 基于应用当前已经启动的POD进行语言识别
  • 基于K8s manifest挂载对应语言的探针文件和配置到对应的应用
  • 通过更新K8s manifest触发应用重启以应用探针

为了实现OneAgent的设计目标,我们调整了Odigos的执行流程,使用Webhook将'更新K8s manifest'和'应用重启'两个步骤进行了分离:

  1. 更新内容以patch形式存储到应用的Annotations中
  2. 用户手动重启pod时,通过webhook拦截pod创建请求,应用Annotations中保存的patch

这样可以避免用户对整个Namespace装载探针时,集群所有应用同时重启,造成资源紧张;而是预先设置好探针配置,在应用下次更新时,自动完成探针的添加。

Odigos中没有包含非K8s应用的实现,我们采用了Linux的Preload机制来完成下面的工作:

  • 通过LD_PRELOAD加载Preload库,在应用启动前拦截启动命令,完成语言识别和后续工作
  • 基于识别到的语言设置探针配置,通常以特定的环境变量加入到启动命令
  • 将改造后的启动命令交给Linux继续执行,完成应用的启动和探针的应用

为了实现OneAgent的设计目标,我们调整了Odigos的执行流程,使用Webhook将'更新K8s manifest'和'应用重启'两个步骤进行了分离:

  1. 更新内容以patch形式存储到应用的Annotations中
  2. 用户手动重启pod时,通过webhook拦截pod创建请求,应用Annotations中保存的patch

这样可以避免用户对整个Namespace装载探针时,集群所有应用同时重启,造成资源紧张;而是预先设置好探针配置,在应用下次更新时,自动完成探针的添加。

Odigos中没有包含非K8s应用的实现,我们采用了Linux的Preload机制来完成下面的工作:

  1. 通过LD_PRELOAD加载Preload库,在应用启动前拦截启动命令,完成语言识别和后续工作
  2. 基于识别到的语言设置探针配置,通常以特定的环境变量加入到启动命令
  3. 将改造后的启动命令交给Linux继续执行,完成应用的启动和探针的应用

针对日志数据的采集,我们采用了阿里开源的 https://github.com/alibaba/ilogtail 工具,它有下面一些优点:

  1. 基于Linux的inotify机制,相较于轮询读取文件,消耗更低
  2. 内置一套设计良好的插件系统,性能开销较大的采集阶段使用C语言实现,确保高效;后续处理采用Go实现,可以快速的进行数据完善和处理
  3. 内置的采集插件支持了对父级目录下日志文件检索,避免用户手动配置每个应用日志地址

在ilogtail基础上,我们实现了功能增强插件,用于统计需要的日志指标,填充日志进程信息和日志数据采样。


程序语言的自动识别

目前的程序语言识别均基于启动命令特征和启动文件信息:

  1. JAVA: 检查启动命令是否满足 java [-options] class [args。。。] 或 java [-options] -jar jarfile [args。。。] 格式
  2. PYTHON: 检查启动命令中是否包含python
  3. Golang: 读取启动文件的内容,检查是否有可识别的buildInfo信息
  4. NodeJS: 检查启动命令中和启动文件路径中是否包含node
  5. Dotnet: 检查启动环境变量中的环境变量名中是否包含DOTNET和ASPNET

探针配置的注入

在完成应用语言类型的识别后,开始准备探针的配置信息。

1.OTEL体系下的APM探针均原生支持基于环境变量来设置探针,我们目前主要预设了下面的配置:

  • OTEL_EXPORTER_OTLP_ENDPOINT 设置探针数据的发送地址
  • OTEL_SERVICE_NAME 设置应用名称
  • OTEL_METRICS_EXPORTER/OTEL_LOGS_EXPORTER 设置为 none,关闭指标/日志采集

2.Skywalking当前以内置的配置文件作为中转,也支持使用环境变量进行配置,主要设置:

  • SW_AGENT_COLLECTOR_BACKEND_SERVICES 设置探针数据发送地址
  • SW_AGENT_NAME 设置应用名称

对于K8s应用,大部分的环境变量会由Odigos通过k8s提供的Device Plugins加入到容器内;

用户已经在K8s Manifest定义了的环境变量,会在K8sManifest显式的合并到用户定义的Envs部分。

对于非K8s应用,环境变量会直接被添加到启动命令中,如果和用户定义变量发生冲突,始终使用用户定义变量。


探针的拷贝

在K8s环境中,由于容器的文件隔离特性,应用无法直接获取到需要的探针文件。Odigos通过将宿主机路径挂载到应用容器内部来向应用提供探针文件,默认将探针文件放到应用的/var/odigos 目录下。

在非K8s环境中,由于应用可以直接获取到宿主机上的探针文件,所以当前没有进行探针文件的拷贝。

日志和进程信息关联

在K8s环境下,采集器通过日志的文件路径可以直接关联到容器,再由容器可以直接关联到所属的应用。这使得在查询日志时,可以通过应用来过滤日志,对于查找关键信息有很大帮助。

非K8s环境中,采集器获得的日志的文件路径就不再像K8s环境中那么规范。不论是ilogtail所使用的inotify机制,或者其他基于文件轮询的日志采集工具,都无法获取到日志是由哪个进程产生的。常规的处理方式是整个项目推行日志文件路径规范,从而可以解析日志文件路径来获取应用信息,这是一种成本较高的解决方案。

APO使用了Linux的Fanotify接口来关联文件和应用信息,它是一个在linux内核2.6.37引入的系统接口,利用Fanotify可以自动关联进程所产生日志文件。

为了降低监听Fanotify事件的资源开销,APO遵循下面这套方案进行文件到应用关联关系的维护:

  1. 通过inotify获取到日志文件更新信息
  2. 将日志文件路径添加fanotify监控标记,监控该文件的修改和关闭事件
  3. 日志文件下次被修改时,获取到修改该文件的进程信息。缓存该日志文件路径对应的进程信息,并关闭对该文件修改事件的监控
  4. 直到接收到该日志文件的关闭事件,这意味着之前获取的进程停止了对该文件的写入;此时重新开始监控该文件的修改事件,以更新该日志文件路径对应的进程信息

通常仅应用进程会对日志文件进行修改,因此上面这套方案可以以极低的消耗完成较为可靠的日志文件路径到进程信息的关联。


总结

APO通过OneAgent中的集成修改的Odigos机制,实现了不同语言的应用程序自动完成OTEL trace探针的安装和环境变量配置,同时通过集成ilogtail采集了日志,并能够实现日志和应用的关联。

OneAgent能够在容器环境和传统虚拟机上同样工作。

APO介绍:

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

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO v0.3.0 发布:关联告警事件;提升数据筛选效率;优化安装体验

· 阅读需 5 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

APO 软件的新版本 v0.3.0 已经正式发布了!这次的更新不仅带来了功能上的改进,还有用户体验上的重大升级。以下是此次更新的主要亮点:

关联告警事件,快速发现故障

在 v0.3.0 版本中,我们引入了全新的告警事件关联功能。这一特性可以帮助您更高效地识别和定位服务相关的潜在问题。通过将相关的告警事件聚合在一起,您可以更容易地追踪到问题的根本原因,从而加快故障排除的速度。 1 图

此外,我们还将告警状态灯关联到了具体的告警原因,只需要将鼠标悬浮到状态灯上即可查看,再也不需要问“为啥这里红”了! 2 图

提升数据筛选效率

为了帮助用户更好地从海量数据中获取有价值的信息,我们在新版本中加强了“服务概览”页面数据筛选的功能。现在,您可以基于“服务名”、“服务端点”或“命名空间”来精确定位期望查看的数据,这将极大地提高数据分析的效率。 3 图

更顺滑的安装流程,优化安装体验

我们一直致力于简化软件的安装步骤,以减少用户的前期投入时间和精力。在本次更新中,我们重新设计了安装流程,尤其减少了探针无法启动的情况,使得整个过程更加流畅。

我们衷心感谢所有参与测试和支持 APO 社区的用户们。正是因为有了你们的反馈和支持,APO 才能不断进步。我们期待着您的宝贵意见,也欢迎您继续参与到 APO 的成长旅程中来!


更多变化请查看下述更新列表。

新增功能

  • “服务概览”页面新增筛选条件,可模糊查询服务名、服务端点和命名空间
  • “服务详情”页面新增告警事件列表
  • 告警状态灯支持鼠标悬浮显示告警原因
  • 指标曲线图支持鼠标悬浮放大,便于查看具体时间的指标
  • “服务详情”页面指标曲线图支持通过选择时间范围修改查询时间
  • 新增中间件指标监控大盘

功能优化

  • 在 Kubernetes 环境安装 OneAgent 时,支持对所有命名空间进行监控
  • 服务概览页面展示服务所属的命名空间,在传统服务器环境中显示N/A
  • 优化“应用基础设施大盘”指标显示效果,兼容各类监控环境
  • 接入 SkyWalking 后,“链路追踪”页面支持按照 SkyWalking 的 TraceID 进行检索

缺陷修复

  • 修复时间选择器在切换页面时可能被重置的问题
  • 修复容器环境可能无法获取到容器启动时间的问题
  • 修复 node-agent 部分情况下会内存溢出的问题

其他

  • 首次进入服务详情页时,展示功能引导
  • 增加功能与术语的解释说明

APO v0.4.0 发布:新增影响面分析;新增调用数据库指标;优化告警事件关联展示

· 阅读需 4 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

APO 新版本 v0.4.0 正式发布!本次更新主要包含以下内容:

新增影响面分析,识别服务端点对服务入口的影响

服务入口是指业务被访问时调用的第一个服务端点,在调用拓扑图中处于最上游。服务入口直接反映了系统对外提供服务的状态,因此了解服务入口的状态对于保证系统服务的稳定性至关重要。

APO 实现了服务端点粒度的拓扑图,还原了每一个服务端点的调用路径,能够准确定位其调用路径上的服务入口。我们在服务详情页中关联了服务入口,便于用户及时了解当前服务对服务入口的影响情况,对影响面进行分析。 1 图

新增服务调用的数据库指标

应用的RED指标(请求次数、错误率、响应延时)反映了应用提供的服务质量,而服务质量受到多种因素影响,其中应用对外部服务的依赖是重要的一部分。本次更新 APO 优先引入了数据库调用指标,当服务质量发生问题时,能在第一时间了解是否是外部数据库导致的。 2 图

优化告警事件关联展示

本次更新中,如果服务端点关联到告警事件,将优先展示告警详情,同时优化了告警列表的展示效果。 3 图

我们衷心感谢所有参与测试和支持 APO 社区的用户们。正是因为有了你们的反馈和支持,APO 才能不断进步。我们期待着您的宝贵意见,也欢迎您继续参与到 APO 的成长旅程中来!


更多变化请查看下述更新列表。

新增功能

  • 服务详情页新增针对服务入口的影响面分析
  • 服务详情页新增数据库调用指标(服务粒度)
  • 调整架构提高适配性,基础功能支持全部内核版本

功能优化

  • 查询故障现场链路增加更多筛选条件
  • Kubernetes 事件统计将警告事件标记为红色
  • 优化 OneAgent 中 Alloy 的内存占用

缺陷修复

  • 修复重启 OneAgent 导致 JS、Python 语言 Instrument 探针丢失的问题
  • 修复服务概览页无法通过指标曲线图切换时间范围的问题