【故障定位系列】基于DeepSeek的故障定位大揭秘

简介: 传统故障定位依赖专家经验与固定算法,难以应对复杂场景。引入DeepSeek大模型后,可凭借其强大推理与自适应能力,实现智能故障定位。通过“大模型+Agent”协同架构,大模型负责决策,Agent执行数据分析,既降低Token消耗,又保留智能化分析优势。未来,随着大模型理解与推理能力提升,故障定位将更高效、精准。

1 为什么要引入DeepSeek故障定位

在讨论这个话题之前,需要先聊一聊传统的基于专家经验的故障定位的思路
image.png

  • 数据源:提供可观测中Tracing、Metric、Log、Event、Profiling等各种数据

  • 算法:对上述数据进行异常检测或者下钻分析

  • 定位模型:作为大脑,掌控整个定位流程

    • 编写各种场景的定位逻辑

    • 在每个场景定位逻辑中

      • 获取该场景下的数据

      • 使用算法对数据进行异常检测

      • 综合分析后跳转到下个场景继续定位

这里存在的难点有如下2个:

  • 难点1:每种场景都需要一定的专家经验才能编写出合理的定位逻辑:目前并没有太好的解决方案,还是靠定位专家来编写

  • 难点2:对各种各样的数据的都能进行自适应的异常检测:目前是采用智能的异常检测算法来应对

在各种大模型比如DeepSeek的智能推理出现后,上述2个难点问题就迎来了新的转机

  • 针对难点1:DeepSeek已经具备了非常丰富的各种场景运维经验

  • 针对难点2:自适应的异常检测这种智能化的东西更是DeepSeek的强项

所以是时候重新需要思考下:在大模型的加持下,故障定位到底该如何改进了

2 引入DeepSeek的方案探讨

引入DeepSeek后最初步的设想是:大模型承担更多智能化工作,我们只需要提供数据源即可

整体定位架构就变得非常简单,如下所示:

image.png

  • 大模型替代了2大模块:定位模型+算法

    • 大模型作为大脑,掌控整个分析定位流程

    • 大模型作为算法提供者,可以自主分析各种数据

  • 我们需要将数据体系投喂给大模型:大模型根据数据体系来决策分析思路

  • 数据源:向大模型提供定位时需要的数据

就是把智能化的工作交给大模型去处理,我们的重点就在于将我们的数据体系向大模型描述清楚,举个例子:

比如从Trace中抽取出了http接口的指标信息,如下所示:

  • metric:service.http

  • tags:clientService、clientIp、serverService、serverIp、httpUrl、httpCode、httpMethod

  • fields:cnt、error、duration、requestPayload、responsePayload

这里就是我们需要把我们的指标体系提供给大模型,让大模型理解这个指标是干什么的,有哪些tags和fields,同理Tracing等其他数据也是类似

思路的本质:我们是需要将故障定位这个问题向大模型描述清楚,同时并不限制大模型的分析思路。因为一旦限制大模型的分析思路,那么我们的限制将成为定位的瓶颈,大模型也失去了智能化的意义,变成了一个执行器而已

这看起来才是一个智能化的架构,不过是一个非常理想的架构,存在哪些痛点呢?

以上述service.http指标为例,各种维度组合下,最近10分钟的Metric,这个数据都可能有几M的大小

  • 大模型token还无法支撑

  • token过大时分析速度会很慢

基于以上痛点,业内也有基于DeepSeek的故障定位业的实践者,他们的主要思路如下

  • 针对每个服务的每个指标进行异常检测

  • 将下面3个元素发给大模型

    • 服务拓扑

    • 每个服务的异常检测结果

    • 定位思路

  • 大模型按照给定的定位思路进行解释执行

那在这种方案下,大模型接手的是处理过后大数据,数据量大大减少,确实解决了这个痛点,但是也会有副作用,大模型演变成了一个工作流执行器,失去了智能化的威力

有没有更好的方案:既能解决token的限制,也能充分发挥大模型的智能化呢?

image.png

  • 我们提供数据体系投喂给大模型

  • 大模型根据数据体系来决策整个分析流程:向Agent智能体下发分析命令

  • Agent作为执行体,负责执行大模型下发的分析命令

    • 命令中包含要分析的数据:Agent需要从数据源中获取这部分数据

    • Agent使用异常检测算法对数据进行初步的分析

    • Agent将初步的分析结果发给大模型,让大模型进行下一步的决策

  • 大模型根据Agent的响应,综合性的决策出下一步的分析步骤

该方案的本质:将基础数据分析这种脏活累活交给Agent,不仅大大降低了大模型的token数,还加快了分析速度,同时又能充分发挥大模型的智力

3 落地方案

落地方案如下所示:

image.png

  1. Agent向大模型提供数据体系,解释各种数据作用

  2. 大模型根据数据体系形成分析决策,给出分析命令

  3. Agent接收到分析命令后,获取相应数据,根据算法对数据进行初步分析,并将分析结果发送给大模型

  4. 大模型根据分析结果,继续优化分析决策,并给出下一步的分析命令

  5. Agent重复上述步骤

  6. 直到大模型决策出找到根因,无需再分析则结束

4 实际效果

提前告诉大模型对应的数据体系,以及数据体系中的数据关联和约束

然后当出现告警时,让大模型给出下一步的分析命令

image.png

上述大模型给出了要分析的数据,Agent能够从数据源中获取该数据进行初步分析,然后将分析结果发给大模型

image.png

大模型针对Agent的响应,综合性分析给出下一步的分析指令

就这样如此往复,最终大模型会给出结束指令

image.png

然后让大模型综合分析结论,给出故障树
image.png

5 后续展望

这个方案有3个核心关键点:

  1. 向大模型解释数据体系:解释最基本的数据

  2. 大模型对数据体系的理解能力:尽量自动理解数据之间的关联,不需要人为一个个明确解释

  3. 大模型的推理能力:结合场景和数据进行严谨的推理

第一个关键点是我们需要努力的,合理并且简单的数据体系更容易被理解

第二三个关键点是大模型需要进一步优化的。目前的大模型还是存在幻觉和推理不严谨的问题,还需要加一些约束机制,以及在数据体系上花费大功夫来解释到位

不过大模型还在飞速进步,这些工作也会逐步废弃

相关文章
|
2月前
|
运维 监控 前端开发
基于AI大模型的故障诊断与根因分析落地实现
本项目基于Dify平台构建多智能体协作的AIOps故障诊断系统,融合指标、日志、链路等多源数据,通过ReAct模式实现自动化根因分析(RCA),结合MCP工具调用与分层工作流,在钉钉/企业微信中以交互式报告辅助运维,显著降低MTTD/MTTR。
2381 28
|
4月前
|
人工智能 自然语言处理 测试技术
基于Dify创建可复用测试用例工厂
本文介绍如何利用Dify平台搭建智能测试用例工厂,通过自然语言需求自动生成结构化测试用例。该方法将传统耗时数天的用例编写工作压缩至数小时,显著提升测试覆盖率和维护效率,实现测试开发的智能化转型。
|
4月前
|
消息中间件 人工智能 Apache
阿里云两大 AI 原生实践荣获 2025 年度 OSCAR “开源+”典型案例
恭喜阿里云微服务引擎 MSE、Apache RocketMQ for AI 获权威认可!
318 46
|
4月前
|
数据采集 监控 API
告别手动埋点!Android 无侵入式数据采集方案深度解析
传统的Android应用监控方案需要开发者在代码中手动添加埋点,不仅侵入性强、工作量大,还难以维护。本文深入探讨了基于字节码插桩技术的无侵入式数据采集方案,通过Gradle插件 + AGP API + ASM的技术组合,实现对应用性能、用户行为、网络请求等全方位监控,真正做到零侵入、易集成、高稳定。
640 60
|
4月前
|
机器学习/深度学习 人工智能 缓存
AI运维不再是玄学:教你用AI提前预测系统故障,少熬几次夜!
AI运维不再是玄学:教你用AI提前预测系统故障,少熬几次夜!
543 13
|
4月前
|
运维 监控 数据可视化
从巴比馒头的“洗菜流水线”,来看“telemetry pipeline”工具的火热兴起
以巴比馒头自动化洗菜为喻,探讨运维领域“数据清洗”难题。DataHub作为国产可视化遥测管道工具,支持多源数据接入与低代码编排,实现日志、指标、链路等数据的高效处理与统一管理,助力企业构建高质量可观测体系。(238字)
|
4月前
|
人工智能 搜索推荐 算法
万字长文深度解密!Cursor Codebase实现原理全公开
VoidMuse 是一个开源AI IDE插件,支持 IntelliJ IDEA 与 VS Code,整合20+优秀组件,通过混合搜索架构(Lucene+向量)实现Codebase智能代码检索,助力开发者在真实项目中掌握AI工程化技术。
736 4
|
4月前
|
人工智能 运维 算法
AI来了,运维不慌:教你用人工智能把团队管理提速三倍!
AI来了,运维不慌:教你用人工智能把团队管理提速三倍!
508 8