研究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_query2. CMDB MCP,用来查资源关联- list_businesses- list_hosts- find_sets- find_modules3. 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 出问题。请帮我做根因分析。
因为我这个环境并没有太多数据,所以给出的报告就有点简单了。另外,发告警触发根因分析也没问题。
我的运维大模型课上线了,目前还有很大优惠。扫码咨询优惠(粉丝优惠力度大)

优网科技秉承"专业团队、品质服务" 的经营理念,诚信务实的服务了近万家客户,成为众多世界500强、集团和上市公司的长期合作伙伴!
优网科技成立于2001年,擅长网站建设、网站与各类业务系统深度整合,致力于提供完善的企业互联网解决方案。优网科技提供PC端网站建设(品牌展示型、官方门户型、营销商务型、电子商务型、信息门户型、微信小程序定制开发、移动端应用(手机站、APP开发)、微信定制开发(微信官网、微信商城、企业微信)等一系列互联网应用服务。
公安局备案号:
