研究Aiops有一段时间了，目前手里有不少可落地的方案了，接下来会把这些方案全部整理到我的大模型课程里。同时，欢迎大家把你遇到的场景在评论区留言。我会在能力范围内给你提供思路和建议。
今天的案例是基于dify做一个专门用来做故障诊断和根因分析的智能体，目前我还没有正式验证，只是有一个大概的思路。等验证完，我会将该案例相关的实操文档和视频放到课程中。
一、核心思路和架构
1）感知：统一告警入口
- Prometheus 检测异常指标，触发结构化告警
- Alertmanager 聚合、去重后，通过 Webhook 推送给智能体
2）上下文增强：不止看告警，更要看现场，自动调用外部系统获取关联信息：
- 运行时状态：（K8s API）→ Pod 事件、重启次数、资源限制
- 业务元数据: （CMDB）→ 所属服务、最近变更、负责人
3）推理：LLM 驱动的根因分析（RCA）
- 将告警 + 上下文作为输入，交给 LLM（通过 Dify）进行推理
- 输出结构化结果：是否真实故障、根因、置信度、修复建议、是否需通知人
4）行动：自动响应 or 人工协同
- 高风险或不确定 → 生成诊断报告，推送至 Slack/钉钉/Jira，支持人工追问
2. 架构图
二、落地指南
阶段 1: 基础环境准备
假设已经有了如下环境：
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
2、定义输入变量
| | |
|---|
alert_name | | |
namespace | | |
pod | | "api-server-7d5b8f6c9-xk2l1" |
instance | | |
severity | | |
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/钉钉/Webhook2）如果 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"
粤ICP备14082021号
免费POC，
零成本试错
