我要投稿

Aiops探索：基于 Dify 做一个故障诊断和根因分析的Aiops智能体

发布日期：2025-11-24 18:32:45 浏览次数： 1541

作者：阿铭linux

微信搜一搜，关注“阿铭linux”

↑↑↑ 点击关注，分享IT技术|职场晋升技巧|AI工具

研究Aiops有一段时间了，目前手里有不少可落地的方案了，接下来会把这些方案全部整理到我的大模型课程里。同时，欢迎大家把你遇到的场景在评论区留言。我会在能力范围内给你提供思路和建议。

今天的案例是基于dify做一个专门用来做故障诊断和根因分析的智能体，目前我还没有正式验证，只是有一个大概的思路。等验证完，我会将该案例相关的实操文档和视频放到课程中。

一、核心思路和架构

1. 核心思路

1）感知：统一告警入口

Prometheus 检测异常指标，触发结构化告警
Alertmanager 聚合、去重后，通过 Webhook 推送给智能体

2）上下文增强：不止看告警，更要看现场，自动调用外部系统获取关联信息：

日志：（Loki）→ 错误堆栈、异常模式
运行时状态：（K8s API）→ Pod 事件、重启次数、资源限制
业务元数据: （CMDB）→ 所属服务、最近变更、负责人

3）推理：LLM 驱动的根因分析（RCA）

将告警 + 上下文作为输入，交给 LLM（通过 Dify）进行推理
输出结构化结果：是否真实故障、根因、置信度、修复建议、是否需通知人

4）行动：自动响应 or 人工协同

低风险操作 → 自动执行（如删 Pod、扩容）
高风险或不确定 → 生成诊断报告，推送至 Slack/钉钉/Jira，支持人工追问

2. 架构图

二、落地指南

阶段 1: 基础环境准备

假设已经有了如下环境：

1）Prometheus：指标采集与告警触发

2）Alertmanager：告警路由

3）Dify：LLM 驱动的智能推理与决策引擎

4）辅助系统：Grafana Loki（日志）、Kubernetes API（上下文）、内部 CMDB（资产信息）

阶段 2: 部署相关MCP

1、部署Grafana MCP（用来查询Loki日志）

步骤略，以前的文章里有介绍过

2、部署k8s MCP（用来获取pod信息）

步骤略，以前的文章里有介绍过

3、部署CMDB MCP

这个需要根据自己使用的CMDB工具来开发合适的MCP工具，这里存在一些不确定性因素

阶段 3: 在 Dify 中配置 MCP 工具

参考以前的发文，将以上三个MCP添加到Dify的MCP工具中心

阶段4：Dify中配置智能体

1、创建新 Workflow

触发方式：HTTP 触发器（Webhook）

2、定义输入变量

变量名	类型	示例
`alert_name`	string	"PodCrashLoopBackOff"
`namespace`	string	"prod"
`pod`	string	"api-server-7d5b8f6c9-xk2l1"
`instance`	string	"10.244.2.15:8080"
`severity`	string	"critical"

3、添加「工具调用」节点（增强上下文）

工具 1：查询 Pod 日志（调用Grafana MCP）

提取最近 5 分钟错误日志摘要（可用 LLM 做摘要）。

工具 2：获取 Pod 详情（调用 K8s MCP）

获取：重启次数、事件（Events）、挂载卷、镜像版本等。

工具 3：查询 CMDB（可选，调用CMDB MCP）

返回：所属微服务、负责人、最近变更记录（如 Git commit、发布流水线 ID）

4. LLM 根因分析节点

设置提示词

你是一个资深 SRE，负责对 Kubernetes 故障进行根因分析。当前告警信息：- 告警名称：{{alert_name}}- 命名空间：{{namespace}}- Pod 名称：{{pod}}- 严重等级：{{severity}}相关上下文：1. 最近日志摘要（来自 Loki）：{{log_summary}}2. Pod 事件与状态（来自 K8s API）：{{pod_events}}3. 服务元数据（来自 CMDB）：{{cmdb_info}}请执行以下任务：1. 判断是否为真实故障（排除误报）。2. 推测最可能的根因（如：镜像拉取失败、OOMKilled、配置错误、依赖服务不可用等）。3. 给出 1~3 条可执行的修复建议（如：kubectl delete pod、回滚 Helm release v1.2.3）。4. 是否需要通知值班工程师？请以严格 JSON 格式输出，字段如下：{  "is_real_incident": true/false,  "root_cause": "string",  "confidence_score": 0.0~1.0,  "remediation_steps": ["step1", "step2"],  "notify_oncall": true/false,  "related_components": ["service-a", "redis-cluster"]}

5. 动作执行 & 通知

分支逻辑：

1）如果 notify_oncall == true → 发送消息到 Slack/钉钉/Webhook

2）如果 remediation_steps 非空 → 调用 自动化平台 API（如自研运维平台）

阶段5：对接Alertmanager

1）修改 `alertmanager.yml`

route:  receiver: aiops-Agentreceivers:- name: aiops-agent  webhook_configs:  - url: 'http://dify-workflow-trigger-url'  # 从 Dify Workflow 复制    http_config:      authorization:        credentials: 'your-dify-api-key'        type: Bearer    send_resolved: true

2）在 Prometheus 告警规则中增加标签（便于传递上下文）

- alert: PodCrashLoopBackOff  expr: kube_pod_status_reason{reason="CrashLoopBackOff"} == 1  labels:    severity: critical    namespace: "{{ $labels.namespace }}"    pod: "{{ $labels.pod }}"  annotations:    summary: "Pod {{ $labels.pod }} in {{ $labels.namespace }} is CrashLooping"