AI 运维自动化方案分析报告

基于现有 Prometheus + Grafana + Node Exporter 监控栈的 AI 接入方案

---

目录

1. 背景与现状

2. 核心思路与目标

3. 三大场景分析

4. 整体架构设计

5. 新增组件清单

6. 可行性分析

7. 实施后效果预期

8. 风险与注意事项

9. 实施建议路线

---

一、背景与现状

1.1 现有监控栈

当前机房运维环境部署了成熟的监控体系：

组件	用途	状态
Node Exporter	采集各服务器硬件/OS 指标	已运行
Prometheus	指标存储与告警规则引擎	已运行
Grafana	指标可视化仪表盘	已运行
Alertmanager	告警路由与通知管理	已运行
wechat_webhook.py	告警推送至企业微信	已运行

1.2 现存痛点

痛点一：告警处于"传统推送"阶段

• 企业微信收到的告警仅为原始文本，如 CPU 使用率超阈值，主机：10.x.x.x

• 不含趋势分析，不含根因推断，不含处置建议

• 运维人员需要自行登录 Grafana 查看上下文，效率低

痛点二：巡检依赖人工，效率极低

• 目前巡检流程：登录 Grafana → 手动翻看各仪表盘 → 逐项对照巡检表 → 手动填写

• 全程人工，无自动化，重复劳动占据大量时间

• 巡检表（日巡检/月巡检）需人工填写约 20~30 个条目

痛点三：无法自然语言交互查询

• 如需查询"今天哪些主机 CPU 超 80%"，必须去 Grafana 拼 PromQL 或翻仪表盘

• 无对话式接口，排查效率受限于运维人员的 PromQL 熟悉程度

---

二、核心思路与目标

2.1 本质思路

不推翻现有监控栈，而是在其上层加一层 AI 理解与执行层。

现有的 Prometheus + Grafana 体系数据采集是完整的，问题在于"数据到人"这一段全靠人工中转。AI 的引入，本质上是把这段中转自动化、智能化：

原来：数据 → Grafana 仪表盘 → 人眼看 → 人工判断 → 人工记录
目标：数据 → AI Agent 分析 → 自然语言结论 → 自动记录/推送

2.2 三个核心目标

目标	当前状态	目标状态
告警质量	推送原始告警文本	推送含根因分析和处置建议的智能告警
巡检效率	人工翻 Grafana 逐项填写	AI 自动查询、自动填写巡检表
数据查询	需要手写 PromQL	自然语言对话即可查询

---

三、三大场景分析

场景一：智能对话巡检

描述

在企业微信或本地 Web 界面中，运维人员用自然语言提问，AI 自动翻译成 PromQL 查询 Prometheus，返回格式化结果。

交互示例

运维：今天 CPU 超过 80% 的主机有哪些？
​
AI：截至当前，以下主机 CPU 使用率超过 80%：
  - h800-gpu-master-13  →  87.3%（持续 23 分钟）
  - 10.10.110.5         →  82.1%（持续 5 分钟）
  建议优先排查 master-13，持续时间较长。
​
运维：master-13 内存和磁盘呢？
​
AI：h800-gpu-master-13 当前状态：
  - 内存使用率：91.2%（15.4 GB / 16 GB）
  - 根分区使用率：73.5%，剩余空间 约 106 GB
  - 内存使用率偏高，建议检查是否有内存泄漏进程。

底层逻辑

1. 用户问题 → AI Agent 接收

2. Agent 理解意图，判断需要调用 Prometheus 查询工具

3. Agent 自动生成 PromQL（如 100 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))*100 > 80）

4. 通过 Prometheus HTTP API GET /api/v1/query 获取结果

5. AI 将 JSON 数据解析为自然语言，返回给用户

价值

• 不需要懂 PromQL，任意运维人员都能查

• 支持多轮追问，不用反复切换页面

• 可在告警发生时快速追查上下文

---

场景二：自动填写巡检表

描述

每天定时（如每天 08:00）自动从 Prometheus 拉取各项巡检指标，按巡检表模板格式写入 xlsx 文件，生成当日巡检记录，异常项自动标红，末尾自动生成巡检总结段落。

巡检条目与数据来源映射

根据现有巡检表（日巡检表 ）分析，线上巡检段共 9 个条目，自动化覆盖率分析如下：

巡检条目	数据来源	自动化可行性
监控系统是否有新增异常数据	Alertmanager API /api/v2/alerts	✅ 完全自动
是否有设备宕机掉线	up{job="node"} == 0	✅ 完全自动
根分区使用率是否高于 80%	node_filesystem_*	✅ 完全自动
控制设备资源（CPU/内存/IO/硬盘）	node_cpu_*/node_memory_*	✅ 完全自动
算力设备资源（GPU 指标）	DCGM_FI_DEV_*（需 DCGM Exporter）	✅ 有 DCGM 则自动
存储设备资源	node_disk_*	✅ 完全自动
是否有掉盘/硬盘异常	node_disk_io_time_seconds_total	✅ 基本自动
设备温度异常（CPU/GPU/硬盘）	node_hwmon_temp_celsius / DCGM	✅ 需 hwmon 采集
是否有掉卡（显卡配置丢失）	DCGM_FI_DEV_COUNT 变化检测	✅ 有 DCGM 则自动

网络巡检段（带宽/延时）：

巡检条目	数据来源	自动化可行性
主线路延时与丢包	Blackbox Exporter（需新增）	⚠️ 需新增组件
备用线路延时与丢包	Blackbox Exporter（需新增）	⚠️ 需新增组件
带宽上下行占用	node_network_transmit/receive_bytes_total	✅ 完全自动

现场巡检段（现场物理巡检，不可自动化）：

巡检条目	说明
服务器设备电源/电压/功耗	需人工现场核查
指示灯状态	需人工现场核查
设备数量与资产表一致性	需人工核对
室内温度/湿度	需温湿度探针（BMC/IPMI 可获取，可选接入）

总结：线上巡检条目约 80% 可完全自动化，剩余 20% 为需人工的现场巡检项。

输出示例

自动生成的巡检表文件（巡检记录表_20260519.xlsx）中：

• 日期、时间、编号自动填入

• □正常 □异常 的选项自动勾选，异常项单元格背景标红

• 有数值的条目（延时、带宽、温度）直接填写具体数字

• 末尾"今日巡检总结"段落由 AI 自动生成一段自然语言描述

---

场景三：智能告警增强

描述

改造现有告警推送链路，在 Alertmanager 触发 webhook 后，不直接推送原始告警，而是先调用 AI Agent 分析告警上下文，再将"增强版告警"推送至企业微信。

告警内容对比

改造前（当前）：

【告警】CPUHighUsage
主机：10.10.110.5
当前值：87.3%
触发时间：2026-05-19 08:32:14

改造后（目标）：

【P1 告警】CPU 持续高负载
主机：10.10.110.5（h800-gpu-node-03）
当前值：87.3%，已持续 38 分钟
​
📊 AI 上下文分析：
  · CPU 使用率自 07:54 开始攀升，当前仍在上升趋势
  · 同期内存使用率为 78.2%，压力也较大
  · 磁盘 I/O 正常，排除磁盘导致 CPU 挂起的可能性
  · 同集群其他节点 CPU 正常（均低于 40%）
​
💡 处置建议：
  1. 优先 SSH 登录该节点，运行 top 查看占用 CPU 的进程
  2. 检查是否有 GPU 训练任务异常占用 CPU
  3. 如进程异常，考虑 kill 或迁移任务

技术实现

告警推送链路改造为：

Alertmanager → webhook → 中间层 Python 服务
  → 调用 Prometheus API 查询上下文指标
  → 调用 AI Agent API 生成分析和建议
  → 格式化消息 → 推送企业微信

改造点仅在 wechat_webhook.py 中新增约 30 行代码，不影响 Alertmanager 配置。

---

四、整体架构设计

4.1 架构层次划分

┌─────────────────────────────────────────────────────────┐
│                     交互入口层                            │
│   企业微信机器人     Web 聊天界面     定时 cron 任务        │
└───────────────────────┬─────────────────────────────────┘
                        │
┌───────────────────────▼─────────────────────────────────┐
│                  AI Agent 中枢层（新增）                   │
│   Dify 平台  ←→  LLM（DeepSeek API）                     │
│   工具调度 / 上下文管理 / 多轮对话 / 结果格式化             │
└────────────┬───────────────────┬────────────────────────┘
             │                   │
┌────────────▼──────┐  ┌─────────▼──────────────────────┐
│  工具层（新增）    │  │     执行层（新增）               │
│ · Prometheus 查询  │  │ · SSH 远程命令执行               │
│ · Alertmanager 查  │  │ · openpyxl 巡检表写入           │
│ · 网络探测工具     │  │ · 企业微信消息推送               │
└────────────┬──────┘  └─────────┬──────────────────────┘
             │                   │
┌────────────▼───────────────────▼──────────────────────┐
│                  现有基础设施层（不改动）                  │
│  Node Exporter → Prometheus → Alertmanager → Grafana   │
│  H800 GPU 集群各节点（Ubuntu）                          │
└────────────────────────────────────────────────────────┘

4.2 数据流向

对话查询流：

用户问题（微信/Web）
  → Dify Agent API
    → 解析意图，生成 PromQL
      → Prometheus HTTP API（:9090）
        → 返回 JSON 指标数据
          → AI 格式化为自然语言
            → 推送/显示给用户

自动巡检流：

cron 触发（每天 08:00）
  → Python 巡检脚本
    → 批量调用 Prometheus API（20+ 条 PromQL）
      → 汇总结果，判断正常/异常
        → （可选）调用 AI 生成巡检总结段落
          → openpyxl 写入巡检表模板
            → 保存为日期命名 xlsx 文件
              → 推送企业微信通知"今日巡检已完成"

告警增强流：

Prometheus 触发告警规则
  → Alertmanager 路由
    → webhook 调用 Python 告警处理服务
      → 查询告警主机最近 15min 上下文指标
        → 调用 AI Agent API 分析
          → 生成增强告警消息
            → 推送企业微信

---

五、新增组件清单

5.1 必选组件（核心功能依赖）

组件	类型	用途	部署方式
Dify	开源 AI Agent 平台	Agent 宿主、工具调度、对话管理	Docker Compose，部署在运维主机
DeepSeek API	云端 LLM 服务	自然语言理解与生成（大脑）	直接调用 API，无需部署
Prometheus 查询中间层	Python 工具服务	封装 PromQL 供 Agent 调用	写入 Dify 自定义工具配置
巡检自动填表脚本	Python 脚本	定时查询指标，写入 xlsx	部署在运维主机，cron 定时运行
告警增强服务	Python 脚本改造	拦截告警，调 AI 增强后推送	改造现有 wechat_webhook.py

5.2 可选组件（增强功能）

组件	用途	新增原因
Blackbox Exporter	网络延时/丢包探测	巡检表中网络延时条目需要此数据
DCGM Exporter	GPU 温度/掉卡监控	H800 GPU 相关巡检条目需要此数据
smartctl_exporter	硬盘 SMART 健康状态	硬盘异常检测更精确
Ollama 本地模型	内网隔离时替代 DeepSeek	如环境无外网或有数据保密要求

5.3 改动组件（现有组件的改造）

组件	改动内容	改动量
wechat_webhook.py	新增 AI 分析调用逻辑，增强告警内容	+30 行代码
Alertmanager 配置	webhook URL 改为指向新的增强服务	改 1 行配置

5.4 无需改动的组件

• Node Exporter（所有已部署节点）

• Prometheus 服务本身

• Grafana 仪表盘

• 现有告警规则（.rules 文件）

---

六、可行性分析

6.1 技术可行性

对话查询（可行性：高）

• Prometheus 具备完整的 HTTP API，/api/v1/query 接口可程序化调用，无需任何额外配置

• Dify 已成熟支持自定义工具（HTTP 工具），直接填写 OpenAPI Schema 即可

• DeepSeek 对中文运维场景理解能力强，PromQL 生成准确率高

• 唯一风险：AI 生成 PromQL 存在偶发错误，需在系统提示词中预置常用查询模板约束输出

自动填表（可行性：高）

• 已验证巡检表 xlsx 结构（3 个 Sheet，28~29 行），openpyxl 库完全支持读写操作

• Prometheus 中已采集了巡检表约 80% 条目所需的指标

• 纯 Python 脚本，无复杂依赖，cron 定时触发成熟可靠

• 唯一风险：如 Prometheus 未采集某些指标（如 GPU 温度），对应条目需降级为"待人工确认"

告警增强（可行性：高）

• 改造量极小，仅改 wechat_webhook.py，不动 Alertmanager 配置

• AI 分析调用可设置超时（如 5 秒），超时则降级回原始告警推送，不影响告警可用性

• 唯一风险：AI API 调用增加了约 1~3 秒延迟，对告警实时性有轻微影响（可接受）

6.2 资源可行性

资源	需求	现状评估
服务器资源	Dify 需 2 核 4G 内存	运维主机或任意管理节点可承载
网络	DeepSeek API 需出口外网	机房需有外网访问（备选内网 Ollama）
费用	DeepSeek API 约 ¥1/百万 Token	巡检和告警场景月费用预计低于 ¥50
人力	脚本开发 + Dify 配置	3~5 天可完成核心功能

6.3 风险评估

风险点	影响程度	应对策略
AI API 调用失败/超时	中	设置超时降级，降级时推送原始告警
LLM 生成 PromQL 有误	低	预置常用查询模板，限制 Agent 行为范围
某些指标未采集	低	对应巡检条目标注"数据缺失，待人工"，不中断流程
外网访问受限	中	备选方案：部署 Ollama + Qwen/DeepSeek 本地模型
巡检表模板变更	低	填表脚本按 Sheet 名 + 行关键字匹配，鲁棒性较强

---

七、实施后效果预期

7.1 效率提升量化

工作内容	现在耗时	AI 接入后耗时	节省
每日巡检（线上部分）	30~45 分钟	0 分钟（全自动）	~35 分钟/天
填写日巡检表	15~20 分钟	0 分钟（全自动）	~18 分钟/天
告警响应（查上下文）	5~10 分钟/次	1 分钟/次（AI 已给分析）	~8 分钟/次
临时查询（如 CPU 异常主机）	3~5 分钟	10 秒	~4 分钟/次

每月累计节省时间预估：

• 每日巡检填表：18 分钟 × 30 天 = 540 分钟（9 小时）

• 告警响应提速：假设每月 30 次告警 × 8 分钟 = 240 分钟（4 小时）

• 临时查询：假设每月 50 次 × 4 分钟 = 200 分钟（3.3 小时）

• 合计：约 16 小时/月的重复性工作被自动化

7.2 质量提升

• 巡检表填写消除人为漏项和填写错误，数值精确到小数点

• 告警消息从信息传递升级为决策辅助，运维人员看到告警就知道该怎么做

• 历史巡检数据格式统一，便于后续做趋势分析

7.3 运维能力升级路径

当前阶段：被动响应（出问题了人去看）
    ↓ 接入 AI 后
第一阶段：主动推送 + 对话查询（AI 告诉你出了什么问题）
    ↓ 后续延伸
第二阶段：异常预测（AI 通过趋势预判将要出问题的节点）
    ↓
第三阶段：自动修复（AI 判断后自动执行修复动作，如重启服务）

本次方案落地第一阶段，为后续演进打好基础。

---

八、风险与注意事项

8.1 数据安全

• DeepSeek API 调用会将指标数据和主机信息发送至外部服务

• 建议：不在提示词中包含完整 IP 段、密码等敏感信息

• 如有严格数据合规要求，使用 Ollama 本地模型替代，数据不出内网

8.2 告警可靠性保障

• AI 增强环节必须设置超时保护（建议 5 秒）

• 超时或 AI 服务不可用时，自动降级为原始告警格式推送，绝不因 AI 故障导致告警丢失

8.3 巡检表的局限性

• 线上巡检条目 AI 自动填写，但现场物理巡检（灰尘、线缆、指示灯）仍需人工

• 自动生成的巡检表建议人工复核后签字，而非完全无人工审查

8.4 LLM 幻觉问题

• AI 回答运维问题时，存在极低概率的"编造数据"风险

• 应对策略：关键数值类回答必须附带原始 PromQL 和数据来源，让运维人员可验证

---

九、实施建议路线

阶段划分

Phase 1（第 1~2 天）：基础设施搭建
  · 部署 Dify（Docker Compose）
  · 配置 DeepSeek API Key
  · 验证 Prometheus HTTP API 可访问
​
Phase 2（第 3~4 天）：自动填表落地
  · 编写 Python 巡检填表脚本
  · 确定各巡检条目的 PromQL 映射
  · 测试并与现有巡检表模板对齐
  · 配置 cron 定时任务
​
Phase 3（第 5~7 天）：对话巡检接入
  · 在 Dify 中创建 Prometheus 查询工具
  · 编写 Agent 系统提示词
  · 发布为 API，接入企业微信机器人
​
Phase 4（第 8~10 天）：告警增强改造
  · 改造 wechat_webhook.py
  · 测试告警增强全链路
  · 上线，观察 1 周效果

优先级建议

优先级	场景	原因
P0（最高）	自动巡检填表	最快落地，不依赖 Dify，直接 Python 脚本，1~2 天可用
P1	智能对话查询	依赖 Dify 部署，但使用频率最高，长期价值最大
P2	告警增强	改造量小，但对运维处置效率提升明显

---

附录：涉及的关键技术接口

Prometheus HTTP API

# 即时查询
GET http://<prometheus>:9090/api/v1/query?query=<PromQL>
​
# 区间查询（用于趋势分析）
GET http://<prometheus>:9090/api/v1/query_range?query=<PromQL>&start=<ts>&end=<ts>&step=<interval>

Alertmanager API

# 获取当前所有活跃告警
GET http://<alertmanager>:9093/api/v2/alerts

Dify Agent API

# 向 Agent 发送对话消息
POST http://<dify>:80/v1/chat-messages
Authorization: Bearer <api-key>
Body: {
  "inputs": {},
  "query": "用户问题",
  "response_mode": "blocking",
  "user": "ops-user"
}

---