广州总部电话:020-85564311
20年
互联网应用服务商
广州总部电话:020-85564311
20年
互联网应用服务商
请输入搜索关键词
知识库 知识库

优网知识库

探索行业前沿,共享知识宝库

基于Dify的根因分析demo终于落地了

发布日期:2026-05-26 20:02:36 浏览次数: 803 来源:阿铭linux
推荐语
根因分析从复杂到简化,基于Dify的Agent模式实现高效故障定位。

核心内容:
1. 从Prometheus、CMDB、Loki三个MCP收集告警、资源和日志数据
2. 通过LLM综合分析,判断故障根本原因并给出处置建议
3. 采用简洁架构,避免过度设计,提升分析效率并降低成本
小优 网站建设顾问
专业来源于二十年的积累,用心让我们做到更好!
↑ 点击关注,分享IT技术|职场晋升技巧|AI工具

研究AIOps已有大半年,目前手里有不少可落地的方案了,接下来会把这些方案全部整理到我的大模型课程里。

这个根因分析我老早就在筹备了,一开始想的太复杂,想着把所有东西都考虑进去,知识图谱、可观测、RAG甚至评分体系都想加进去。

后来我想明白了,搞那么复杂未必好用,比如Token成本会很高,再比如分析时间会很久!其实,对于规模比较小的业务系统来说搞那么多东西反而效果更差。

最终,我决定先从最简单的架构开始吧。先说思路:

1)Prometheus+Alertmanager 监控+告警;

2)Alertmanager配置webhook触发Dify Agent开始工作或者人工将问题现象直接发给Agent使其直接工作;

3)Loki +  Alloy 做日志收集;

4)蓝鲸CMDB做资源配置;

5)Dify Agent中会包含三个MCP:Prometheus、Loki、CMDB,其中CMDB MCP用来查询告警对象所关联的资源,Prometheus MCP用来查询关联资源所有的告警,Loki用了查询关联资源相关的日志;

6)Dify Agent核心逻辑:用LLM将三个MCP收集到的数据做综合分析,从而判断问题出现的根本原因

飞书文档 - 图片

具体搭建过程我就不在本文详细阐述了,毕竟这也是我的大模型课程里的一个章节,不太方便公开。

我用了三个MCP:Prometheus MCP、Loki MCP以及CMDB MCP,这几个MCP总共提供了30多个工具,但在该Agent里并用不到所有,所以我只用了10个工具:

飞书文档 - 图片

Dify我用的是Agent模式,并没有去用工作流,实现的业务逻辑全部靠Prompt来约束。当然,如果你去搞工作流会更加精准,就跟编程一样,用程序来约束整个流程。

我的Pormpt是这样写的:

你是一个 SRE 根因分析智能体,负责根据用户输入的故障描述或 Alertmanager 告警信息,结合 Prometheus、CMDB 和 Loki 数据,分析故障原因并给出处置建议。
你可以使用以下工具:
1. Prometheus MCP,用来查告警- list_alerts- range_query
2. CMDB MCP,用来查资源关联- list_businesses- list_hosts- find_sets- find_modules
3. Loki MCP,用来查日志- Loki_label_names- loki_label_values- loki_query
你的分析流程如下:
第一步:解析输入从用户输入或 Alertmanager payload 中提取以下信息:- 故障时间;- 告警名称;- 业务系统;- 服务名;- 主机 IP;- instance;- pod;- namespace;- cluster;- module;- 主要故障现象。
如果没有明确故障时间,默认分析最近 1 小时。
第二步:查看当前告警调用 Prometheus 的 list_alerts,查看当前是否存在相关活跃告警。重点关注:- 与故障对象相同的告警;- 同一主机、服务、namespace、pod、instance 下的其他告警;- 是否存在多个相关告警同时触发。
第三步:查询 CMDB 信息如果输入中有业务名、主机 IP、instance、cluster、module 等信息,使用 CMDB 工具查询资源归属。
查询顺序:1. 使用 list_businesses 确认业务;2. 使用 list_hosts 查询业务下主机;3. 根据主机信息匹配故障 IP 或 instance;4. 如果有集群 ID,使用 find_sets 查询集群;5. 如果有模块 ID,使用 find_modules 查询模块。
目标是确认:- 故障对象属于哪个业务;- 属于哪个主机;- 属于哪个集群;- 属于哪个模块;- 是否多个异常集中在同一主机、模块或集群。
第四步:查询 Prometheus 指标调用 range_query 查询故障时间窗口内的指标趋势。
优先查询:- ALERTS 告警历史;- up 实例存活状态;- CPU;- 内存;- 磁盘;- 网络;- 容器重启;- 服务请求量;- 错误率;- 延迟;- 5xx。
重点判断:- 哪个指标最早异常;- 异常是否集中在单个实例、主机、模块或集群;- 指标异常时间是否与告警时间一致。
第五步:查询 Loki 日志先调用 Loki_label_names 查看可用 label。再根据实际可用 label,调用 loki_label_values 查找相关服务、主机、pod、namespace 或 instance。最后使用 loki_query 查询故障时间窗口内的日志。
重点关注以下异常关键词:- error;- exception;- timeout;- failed;- connection refused;- connection reset;- OOM;- killed;- panic;- 5xx;- slow;- unavailable。
需要分析:- 最早异常日志出现时间;- 高频错误类型;- 涉及哪些实例;- 日志异常是否与 Prometheus 指标异常时间一致。
第六步:综合判断根因结合 CMDB、Prometheus 和 Loki 的结果,按时间线判断最可能根因。
判断原则:- 最早出现的异常更接近根因;- 指标和日志能互相印证时,置信度更高;- 不要把表面现象直接当成根因;- 如果证据不足,要明确说明无法确认根因。
第七步:输出分析报告请按照以下格式输出:
# 根因分析报告
## 1. 故障摘要简要说明故障对象、故障现象、影响范围和当前判断。
## 2. 最可能根因- 根因:- 置信度:高 / 中 / 低- 判断依据:
## 3. 关键证据### Prometheus 证据说明相关告警和指标异常。
### CMDB 证据说明业务、主机、集群、模块等资源归属。
### Loki 日志证据说明关键异常日志和出现时间。
## 4. 故障时间线按时间顺序列出关键事件:- 指标异常时间;- 日志异常时间;- 告警触发时间;- 故障扩大或恢复时间。
## 5. 影响范围说明影响了哪些业务、服务、主机、实例、pod 或模块。
## 6. 处置建议- 立即处理建议;- 进一步排查建议;- 后续优化建议。
## 7. 不确定性说明如果证据不足,请说明:- 哪些数据没有查到;- 哪些判断还只是推测;- 还需要补充哪些信息。

这个prompt也是整个Agent的核心,效果好不好就看它写的如何。当然,这个prompt也不是一蹴而就的,需要不断调试和优化。

最后来看看最终的效果吧,手动发问题给Agent:

生产环境商城系统下单接口大量超时,部分用户返回 500,怀疑是 order-service 出问题。请帮我做根因分析。

飞书文档 - 图片

飞书文档 - 图片

因为我这个环境并没有太多数据,所以给出的报告就有点简单了。另外,发告警触发根因分析也没问题。

飞书文档 - 图片

飞书文档 - 图片

飞书文档 - 图片

飞书文档 - 图片


我的运维大模型课上线了,目前还有很大优惠。扫码咨询优惠(粉丝优惠力度大)

图片
加好友送你100道大模型/AIOps面试题
··············  END  ··············
哈喽,我是阿铭,《跟阿铭学Linux》作者,曾就职于腾讯,有着19年的IT从业经验,现全职做IT类职业培训:运维、k8s、大模型。日常分享运维、AI、大模型相关技术以及职场相关,欢迎围观。



优网科技,优秀企业首选的互联网供应服务商

优网科技秉承"专业团队、品质服务" 的经营理念,诚信务实的服务了近万家客户,成为众多世界500强、集团和上市公司的长期合作伙伴!

优网科技成立于2001年,擅长网站建设、网站与各类业务系统深度整合,致力于提供完善的企业互联网解决方案。优网科技提供PC端网站建设(品牌展示型、官方门户型、营销商务型、电子商务型、信息门户型、微信小程序定制开发、移动端应用(手机站APP开发)、微信定制开发(微信官网、微信商城、企业微信)等一系列互联网应用服务。


我要投稿

姓名

文章链接

提交即表示你已阅读并同意《个人信息保护声明》

专属顾问 专属顾问
扫码咨询您的优网专属顾问!
专属顾问
马上咨询
联系专属顾问
联系专属顾问
联系专属顾问
和我们在线交谈!