数据库巡检报告怎么写？AI Agent 自动输出容量、性能和风险建议

写数据库巡检报告通常是运维最头疼的重复劳动，对着 Excel 表格复制粘贴 SQL 结果，不仅枯燥，还容易漏掉隐藏的性能瓶颈。在主机选的实战经验中，利用 AI Agent 结合 n8n 和 Ollama，完全可以把这套流程自动化。AI 不只是搬运数据，还能像资深 DBA 一样分析容量趋势、异常指标，并直接给出可执行的风险建议。

数据库巡检的痛点与 AI Agent 优势

传统的巡检脚本只能输出数字，比如“磁盘使用了 80%”，但不会告诉你“按照每天增长 1% 的速度，下周三就会写满”。AI Agent 的核心优势在于推理能力。通过将数据库的运行指标（QPS、慢查询数量、连接数、表空间大小）喂给本地运行的 LLM，大模型能结合上下文判断这是否属于“异常”，并生成一份接近自然语言的巡检日报。

VPS 部署 Ollama 与 n8n 基础环境

要实现这套自动化，首先得有个能跑 Docker 的环境。考虑到数据库敏感性和响应速度，建议在内网 VPS 或具备较高配置的本地服务器上部署。

Docker 部署 Ollama

Ollama 负责运行本地模型，推荐使用 Qwen2.5 或 Llama3.1 这类在逻辑推理和代码分析上表现较好的模型。拉取镜像并运行：

docker run -d -v ollama_data:/root/.ollama -p 11434:11434 –name ollama ollama/ollama

运行后拉取模型，以 7B 版本为例，平衡推理速度和效果：

docker exec -it ollama ollama pull qwen2.5:7b

Docker 部署 n8n

n8n 是工作流引擎，负责定时触发任务、查询数据库和调用 AI。

docker run -it –rm \
–name n8n \
-p 5678:5678 \
-v ~/.n8n:/home/node/.n8n \
n8nio/n8n

安全提示：生产环境请勿将 5678 端口直接暴露在公网，务必配置 Nginx 反向代理并添加 Basic Auth 或 IP 白名单。

搭建数据库巡检 AI Agent 工作流

进入 n8n 界面后，新建一个 Workflow。整个流程逻辑很简单：定时触发 -> 获取数据库指标 -> 调用 Ollama 分析 -> 发送报告。

关键指标采集脚本设计

不要把所有数据库数据都丢给 AI，Token 是钱（即使是本地模型，Context Window 也有限）。我们需要精选关键指标。在 n8n 中添加 MySQL 或 Postgres 节点，执行以下 SQL（以 MySQL 为例）：

1. 基础与连接状态
sql
SHOW GLOBAL STATUS WHERE Variable_name IN ('Threads_connected', 'Threads_running', 'Max_used_connections', 'Aborted_connects');

2. 核心性能指标
sql
SHOW GLOBAL STATUS WHERE Variable_name IN ('Questions', 'Slow_queries', 'Com_select', 'Com_insert', 'Com_update', 'Com_delete');

3. 容量与表空间
sql
SELECT table_schema, ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Size (MB)"
FROM information_schema.tables GROUP BY table_schema;

除了 SQL，还需要系统层面的数据。在 n8n 中添加“Execute Command”节点（SSH 到服务器）执行：

df -h | grep -vE '^Filesystem|tmpfs|cdrom' # 磁盘使用率
free -m # 内存剩余
uptime # 负载

n8n 节点配置与 Prompt 编写

将上述节点输出的数据汇聚，通过“Code”节点整理成一段 JSON 或清晰的文本格式，然后接入“Agent”节点（或直接调用 OpenAI Model 节点，Base URL 填写 `http://localhost:11434/v1`，Model Name 填写 `qwen2.5:7b`）。

System Prompt 是关键，直接决定了报告的质量：

> 你是一名拥有 10 年经验的 MySQL 运维专家。请根据以下数据库和系统指标，生成一份巡检报告。
> 要求：
> 1. 识别异常：连接数是否接近 Max、慢查询是否突增、磁盘空间是否不足。
> 2. 容量分析：根据当前库表大小，预测未来 7 天的容量风险。
> 3. 给出建议：针对发现的问题，给出具体的 SQL 优化建议或运维操作命令。
> 4. 输出格式：Markdown，包含“总体评分”、“风险列表”、“优化建议”三个板块。

将整理好的指标数据放入 User Message 中发送给 Ollama。

报告自动推送与归档

AI 返回 Markdown 内容后，使用 n8n 的“Read Binary Files”或“Edit Fields (Set)”节点将内容格式化。最后添加“Slack”、“Telegram”或“Email”节点，直接把报告推送到运维群。

如果需要留底，可以添加一个节点将报告内容写入本地文件，或插入到专门的“巡检记录表”中，方便后续复盘。

老鸟叮嘱：生产环境避坑指南

这个方案虽然好用，但坑也不少，千万别直接拿核心生产库练手。

1. 别让巡检本身成为瓶颈
获取 `information_schema` 数据在某些大库上会锁表或引发高 IO。尽量在业务低峰期（比如凌晨 3 点）触发 n8n 的 Cron 任务。如果表特别多，只查 Top 10 的大表，而不是全量扫描。

2. 敏感数据脱敏
把数据喂给 AI 前，务必检查是否包含真实用户名、库名中的敏感信息。虽然用的是本地 Ollama，数据不出机器，但养成良好的脱敏习惯是运维的基本素养。

3. AI 的幻觉风险
LLM 有时会一本正经地胡说八道。如果 AI 建议“删除所有 binlog 日志释放空间”，千万别直接执行。报告只能作为辅助参考，关键操作必须人工二次确认。

4. 资源争抢
Ollama 比较吃内存和 CPU。如果 VPS 配置不高（比如低于 2C4G），运行 7B 模型可能会导致数据库卡顿。建议将 Ollama 部署在独立的空闲机器上，通过内网 API 调用。

FAQ

Q：本地跑的 Ollama 模型分析能力够用吗？
A：对于常规的巡检分析，Qwen2.5 或 Llama3 的 7B/14B 版本完全够用。它们能准确识别“连接数满”、“磁盘快满”等逻辑问题，且不需要联网，安全性高。

Q：除了 MySQL，支持 PostgreSQL 或 Redis 吗？
A：完全支持。n8n 有对应的 Redis 和 Postgres 节点，只需把采集到的指标数据整理成 LLM 能读懂的文本格式即可，原理是一样的。

Q：AI Agent 能直接执行修复 SQL 吗？
A：技术上可以通过 n8n 的 MySQL 节点实现，但强烈不建议开启“自动执行”。让 AI 输出 SQL 语句，经人工审核后再手动执行是最稳妥的流程。

Q：生成报告速度慢怎么办？
A：如果觉得 7B 模型慢，可以尝试量化版（如 q4_0），或者换用更小的模型（如 3B）。另外，减少输入给 AI 的数据量也能显著提升速度。

Q：这套方案能监控云数据库吗？
A：可以。只要你的 VPS 能通过公网或 VPN 连接到云数据库（RDS），并且在安全组里放行了出站 IP，n8n 就能像操作本地库一样操作云库。

通过这套组合拳，我们将原本需要半小时的手动 Excel 汇总工作，转化为了几秒钟的自动化 AI 分析。不仅效率提升，更重要的是 AI 能发现人眼容易忽略的趋势性风险，让数据库运维更加主动。