基于DeepSeek的故障定位大揭秘

B站影视 韩国电影 2025-04-24 15:32 1

摘要:大模型替代了2大模块:定位模型+算法大模型作为大脑,掌控整个分析定位流程大模型作为算法提供者,可以自主分析各种数据我们需要将数据体系投喂给大模型:大模型根据数据体系来决策分析思路数据源:向大模型提供定位时需要的数据

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

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

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

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

获取该场景下的数据

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

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

编写各种场景的定位逻辑

在每个场景定位逻辑中

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

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

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

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

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

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

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

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

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

大模型替代了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的限制,也能充分发挥大模型的智能化呢?

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

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

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

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

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

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

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

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

3 落地方案

落地方案如下所示:

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

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

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

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

Agent重复上述步骤

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

4 实际效果

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

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

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

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

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

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

5 后续展望

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

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

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

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

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

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

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

来源:孤独难学科技

相关推荐