跳到主要内容

2 篇博文 含有标签「DeepSeek」

查看所有标签

重新认识APO——DeepSeek带来可观性领域革命

· 阅读需 14 分钟

cover 图

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

AI驱动的可观测性革命

APO致力于将AI自治Agents打造为可观测性领域的智能核心,彻底颠覆故障排查、性能调优和根因分析的传统方式。在自治Agents的加持下,可观测性系统不再是被动工具,而是主动解决问题的智能伙伴。当告警触发时,智能体立即接管,自动分析根因并提供解决方案。想象一下,当某个微服务的数据库查询效率低下,自治智能体不仅会立刻通知您,还会奉上详细的故障报告和精准修复建议。您甚至可以用自然语言与它对话,只需问一句:"为什么我的应用变慢了?" AI Agents 就会清晰地回答:"服务 A 的数据库查询触发了全表扫描,导致延迟激增,建议优化索引。"

1 图 未来完全自治的智能体

AI自治智能体是APO的终极愿景,而在这条革命之路上,Agentic workflow是关键一环,也是APO新发布的核心功能,它让可观测性实现了第一步质的飞跃。


Agentic workflow(工作流):你的经验,Agents的灵魂

通用LLM虽然强大,但它们缺乏IT领域的垂直专业知识。IT系统错综复杂且千差万别,不同系统间差异巨大,仅靠通用知识难以应对实际运维挑战。

APO的突破性创新在于将"专有经验知识"——也就是你的运维智慧——注入智能体的核心。普通智能体只会按照自己预设的逻辑行事,完全忽视你多年积累的宝贵经验。而APO彻底改变了这一点,让你通过构建Agentic workflow,将专业知识直接输入系统,成为智能体决策的核心驱动力。

想象您团队中有位经验丰富的老运维李工,每次系统出现问题,他总能快速找到根因—因为他积累了丰富的经验。但当李工休假时,其他人却要花上数倍时间处理同样的问题。APO Agentic workflow就像把李工的经验数字化,让每个人都能像他一样高效解决问题。

APO已经预定义了多种场景的工作流,让您立即体验智能运维的威力:

  • 告警智能分析:当数据库CPU突然飙升时,传统告警只会发出"CPU使用率超过90%"的简单通知。而APO会立即启动分析工作流,自动收集关联的SQL查询、连接数、I/O等信息,识别出"这是因为新上线的用户注册接口缺少索引导致的全表扫描",甚至直接给出优化SQL的建议
  • 自动化运维巡检:周一早上,您不再需要一个个检查周末系统运行状况。APO会自动执行巡检工作流,检查所有服务的健康状态、资源使用趋势、异常日志,生成一份简明扼要的周末系统报告:"发现用户服务在周日凌晨出现三次短暂CPU峰值,但未影响用户体验;预测存储空间将在14天内达到警戒值,建议本周四前扩容。"
  • 复杂故障快速诊断:面对"用户偶发性登录失败"这类复杂问题,传统方法需要团队协作、逐个排查可能原因。而APO工作流会系统性地收集证据:先检查用户服务本身,发现无异常;接着检查依赖服务,发现认证服务有偶发超时;继续追踪发现是特定网络路径在高峰期丢包率增高。整个诊断过程从原本的数小时缩短至数分钟

2 图 开箱即用的面向问题解决的Agentic workflow

每个系统环境都有其独特性,预设工作流无法覆盖所有场景。因此,APO专为可观测性领域打造了工作流编排平台。该平台基于最流行和最易用的通用AI工具Dify打造,APO基于可观测性领域存在大量多模型数据的特点,为用户提供了一系列可直接拖拽使用的数据查询和异常检测工具,任何人都能够轻松地在这个平台上将自己的经验固化为工作流,为后续实现自治Agents奠定基础。

3 图 基于Dify专为可观测性领域打造的平台

例如,您有一套自己总结的"数据库性能问题排查十步法",只需通过直观的可视化界面将这些步骤拖拽组合,添加判断条件“如果慢查询超过10条,则收集索引使用情况",再让大模型根据实际情况决策下一步执行流程,这样就能将您的专业知识转化为自动化工作流。

APO预设的工作流同样基于该平台构建,每个工作流都能够根据实际的场景进行修改,让工作流真正融入到工作的流程中。

有了工作流,李工的年底休假计划再也不会引起团队恐慌,因为他的经验已经被编排成工作流,成为了APO智能体的一部分,24x7为团队服务。随着工作流的不断积累和优化,您实际上是在培养一个越来越了解您系统的AI助手,它会成为您团队中最可靠的"成员"。


数据基石:为智能体提供坚实支撑

Agentic workflow的核心能力依赖于对数据的有效利用。当前,可观测性数据主要包括指标、日志和链路追踪三大支柱,持续剖析火焰图等新兴数据也逐渐成为主流。然而,这些数据结构多样、体量庞大,直接输入通用LLM既低效又受限于上下文窗口,难以发挥最佳效果。因此,APO设计了专为LLM优化的数据平面,从以下两个维度构建:

  • 横向视角:就像一张智能地图,直观展示整个系统的服务关系和健康状态。例如,当订单服务出现延迟,您能立即看到是哪个依赖服务出现问题——支付服务响应时间异常,上面标红提示
  • 纵向关联:系统自动将不同层面的数据关联起来。当您点击异常的支付服务,能一目了然地看到它运行在哪个容器、哪个节点、使用了哪些资源、有哪些日志异常、哪些API调用超时——所有信息一键可得,不再需要在多个系统间来回切换

数据基石的横向设计让AI Agents能够迅速获取系统全貌,立即锁定异常组件;纵向设计则使其能够沿着问题线索深入挖掘,追溯到根本原因。例如,当检测到服务延迟时,AI Agents可通过横向视图确定问题服务,再利用纵向数据追踪具体原因,从容器到主机,从应用到中间件,层层剖析,直达问题核心。

APO提供内置采集工具,能够通过一键安装部署构建以上数据平面。对于已经使用了其他采集工具的用户,APO同样支持无缝对接现有数据源,用户无需改造系统即可使用这一革命性数据平面。这一创新设计为智能体提供了高效、结构化的数据基础,让AI能够真正理解系统行为并做出精准决策。

4 图


生态建设:让智能体持续进化

在融合大语言模型、数据基石和专有知识后,APO迈出了实现其愿景的关键一步。APO深知,系统的可观测性越丰富,智能体的能力就越强。然而,现有数据往往无法覆盖所有盲区,预设的工作流也难以应对复杂的运维场景。为此,APO打造了一个开放协作的生态系统,聚焦于数据生态工作流生态两大核心,助力AI Agents适应多样化环境并持续进化。

数据生态:多元数据协同

作为一个开源项目,APO构建了一个开放平台。故障排查需要有很多维度的数据、这个平台支持厂商或者专家无缝提供各类新数据,丰富智能体的可观测资源。这些数据会被整合成自然语言描述的查询工具,为智能体提供故障排查和性能优化的有力支持。

对于专有数据,厂商或者专家还可将其领域知识嵌入特定工作流中。用户使用这些工作流时,能直接体验数据的价值,无需额外学习或积累经验。例如厂商云观秋毫提供了基于eBPF实现的北极星指标和故障排查工作流,龙蜥社区系统运维SIG提供SysOM的CPU& GPU持续剖析大规模数据、AI火焰图分析。

5 图

Agentic workflow工作流生态:群智共享

APO的Agentic workflow工作流生态可以方便汇聚群体智慧:

  • 工作流的本质:专家的独有智慧与经验,通过workflow和LLM节点变成可以重复执行的智能体
  • 经验共享:专家可以分享其智慧与经验,以供其他人使用,比通过博客文章分享更有利于其他用户使用
  • 群体智慧逼近AI自治智能体:随着不同场景的工作流越来越多,当各种故障场景都能有工作流覆盖,完全自治的智能体就不远了

分享与协作,每个用户都能享受到最先进的可观测性智能体。


携手共创智能运维未来

APO以AI之力、社区之能,致力于彻底革新可观测性领域。我们坚信,开放协作将加速智能体的实现,让运维工作彻底摆脱繁琐和低效,进入全新的智能时代。无论您是数据提供者、运维专家还是技术爱好者,APO诚邀您加入这场变革,共同塑造可观测性智能体的未来!

现在,就从体验APO的Agentic workflow开始,迈出智能运维的第一步吧!


6 图

基于DeepSeek的可观测性智能体实践

· 阅读需 14 分钟

cover 图

背景

云观秋毫是一家在可观测性领域帮助用户落地IT故障根因分析的初创企业。产品最开始使用传统的规则引擎来实现分析规则的执行,但是存在可解释性和定制化差等问题,所以2024年我们探索引入了大语言模型,不仅取得了效果上的提升,同时也获得了更好的解释性和可扩展性。2025年,云观秋毫将会把实践经验融入到平台中,研发可观测性智能体编排平台,让用户也能够快速构建可观测性领域的智能体,覆盖更多可观测性数据分析垂直场景。

早在2024年11月,通过多方位实验和测试,团队就已经选型DeepSeek作为智能体背后默认的大语言模型,当时我们已经发现DeepSeek在性能和成本上的优势,但没有料到DeepSeek会如此火爆,下图是我们在社区中介绍功能的聊天记录:

1 图


实践效果

先上结论,我们基于大语言模型实现了一个可持续演进的故障定位智能体,该智能体能够执行告警分析和故障定位的能力,该智能体在使用DeepSeek时综合表现优于其他模型(2025年2月结论)。DeepSeek在理解和处理可观测性的各类数据上有着较高的准确率,能够较好地理解专家规则并按照规则分析数据,且具有高性价比的价格,尽管偶尔出现数据幻觉,但经过设计能够达到较高的准确率。

该智能体分析问题的整体流程为:以告警通知作为智能体分析的入口,以告警和异常检测事件作为数据基础,让大模型利用预设的思维链规则分析拓扑和事件数据,以此识别疑似根因节点,最终通过北极星指标确认根因。

使用该智能体,能够显著提高用户在复杂服务依赖场景中进行故障定位的效率,同时智能体在分析问题时提供了更好的解释性和可扩展性。

下图是该智能体分析问题的真实案例:

2 图

这里不再赘述细节,如果大家对该智能体感兴趣,欢迎关注和试用“云观秋毫”的“APO”产品,我们在官网提供了更多详细信息。此外,我们正在研发可观测性智能体编排平台,未来用户能够方便地在平台上构建自己的智能体,覆盖除了根因分析以外的更多场景。


为什么选择DeepSeek

大模型选型的考量

在当今的可观测性领域中,运维人员在处理异常问题时,常常需要处理海量的数据进行查询、分析和处理任务。排障过程通常具有流程化、规范化以及经验化的特性,这意味着对于经验不足的运维人员而言,这一过程既耗时又费力。因此,利用大模型的推理能力来简化这一过程显得尤为重要——只需提供自然语言描述的规则和数据,大模型便能像专家一样快速识别问题所在。

1.JSON格式数据的理解

由于大模型存在上下文Token限制,为了确保其能够有效理解可观测性数据,首先必须解决的是数据输入格式的问题。

JSON作为一种结构化数据格式,因其便于从原始数据中提取信息,并结合提示工程(描述JSON数据格式键值对含义)易于被大模型解析而成为首选。

如微服务场景下,服务调用的上下游关系复杂且数据量庞大,通过精简数据并使用嵌套的JSON格式记录这些关系,可以大大简化层级结构,帮助大模型更好地理解和分析数据。

然而,并非所有大模型都能完美解析这种数据形式。经过实际验证发现,如文言一心和参数低于14b的模型等在理解JSON数据时存在障碍,容易出现逻辑错误,如无法正确理解上下游调用关系,或着将调用关系弄反。而豆包、智谱GLM-4 Plus、Qwen2.5-32B及以上版本和DeepSeek则表现出了良好的理解能力。

模型理解JSON数据
文言一心
参数14b以下的模型
豆包1.5-Pro-256K
智谱GLM-4-Plus
Qwen2.5-32b及以上
DeepSeek

2.自然语言规则执行效果

当大模型能够准确理解可观测性数据后,其还需要具备根据用户提供的自然语言规则进行推理的能力,以定位可能的故障点。然而,部分大模型在执行规则时可能会出现偏离指令的情况。

例如,在APO平台节点中,业务拓扑需通过服务名和端点组合唯一标识,但某些模型在处理过程中会忽略端点数据,造成业务拓扑服务名称不完整导致结果偏差。推理结果中,不同的模型对规则的执行准确率也不同。

对比不同模型的表现,DeepSeek在规则执行准确性方面达到了100%,显著优于其他选项如豆包1.5-Pro-256k(70%)、智谱GLM-4 Plus(90%)以及Qwen的不同版本。

模型规则执行准确率
豆包1.5-Pro-256K70%
智谱GLM-4-Plus90%
Qwen2.5-32b70%
Qwen2.5-72b90%
DeepSeek100%

3.大模型使用成本

除了考虑模型的推理能力和准确性外,实际业务场景中的使用成本也是不可忽视的因素之一。

尽管像Qwen2.5-72B和智谱GLM-4 Plus这样的模型在推理效果上表现出色,但它们的调用费用相对较高。相比之下,DeepSeek不仅在性能上领先,而且其调用成本相比其他旗舰级模型低至十分之一乃至百分之一(尤其是当命中缓存时),提供了更高的性价比。

虽然像豆包1.5-Pro-256k这样的低价替代品看似经济实惠,但其较低的推理准确率也意味着潜在的效率损失。

每千 Token价格 (输入)每千 Token价格 (输出)
Qwen2.5-32b0.0020.006
Qwen2.5-72b0.0040.012
智普GLM-4-Plus0.050.05
豆包1.5-Pro-256k0.0050.009
DeepSeek0.0005(命中缓存)/0.002(未命中缓存)0.008

大模型选型的结论

  1. 从准确率的角度考虑,需要大模型能正确识别JSON数据,同时按照用户指令来执行自然语言的规则。国内符合条件且效果较好的大模型有DeepSeek, Qwen2.5-72b, GLM4-Plus等。
  2. 同时还需要考虑调用成本DeepSeek费用远低于其他大模型且缓存机制使得成本进一步下降。

DeepSeek存在的缺陷

尽管DeepSeek在处理可观测性数据、执行自然语言规则方面展现了极高的准确率和卓越的性价比,但它也并非毫无瑕疵。与所有大模型一样,DeepSeek面临着一个较为突出的问题——模型幻觉现象(hallucination)。

这种现象在分析微服务拓扑结构时尤为明显,例如在基于“train-ticket”场景的测试中,简化了复杂的微服务调用关系,仅保留最基本的业务节点进行测试,DeepSeek有时仍会输出一些如“ts-payment-service”这样实际上并不存在于真实数据中的服务名,但这些名称又似乎与“train-ticket”有关。

如何克服这些缺陷

  1. 调整大模型参数:通过精细调节DeepSeek的生成参数,比如top_p(核采样)和temperature(温度),可以有效控制输出内容的多样性和稳定性。降低temperature值可以让模型倾向于选择概率更高的词汇,从而减少输出的随机性;而适当调整top_p值,则有助于限制词汇的选择范围,进一步确保输出内容的精确度和一致性。
  2. 优化数据组织方式:为了避免大模型由于数据相似性而产生联想,导致出现不准确的服务名,可以通过改进数据的组织形式来缓解这一问题。具体而言,APO平台使用服务名加端点的方式代替单纯使用服务名标识节点的方法,不仅可以增加数据的独特性,还能显著降低模型因混淆不同数据而产生错误的可能性。

采取上述措施,可以在一定程度上缓解DeepSeek及其他大模型中存在的幻觉问题,提升其在实际应用中的可靠性和准确性。不过值得注意的是,完全消除此类问题可能需要持续的技术进步和对模型架构的深入优化。


展望未来

目前我们实现的智能体主要解决基于拓扑的故障定位场景,在该场景下已经取得了不错的效果。在实践过程中,我们积累了大量开发大语言模型应用的经验,特别是在可观测性领域中如何分析大量异构数据。我们希望这些经验不止停留在团队内部,而是能够与业界一起讨论交流,一同推动大语言模型在可观测性领域的落地。

基于上述实践和经验,我们已经意识到AI Agent可能给可观测性领域带来的颠覆性改变,为了能够让这些经验能够惠及更多人和企业,我们正在研发可观测性智能体编排平台,并将会作为开源项目开源。在该平台中,所有人都能够方便地构建自己的可观测性智能体,覆盖可观测性领域中的更多场景,最终释放人的时间,让智能体替人工作。


3 图