CPU 连续飙高怎么自动告警？AI Agent 判断短时波动和持续异常

VPS 运维中，CPU 告警最让人头大。阈值设低了，半夜被备份任务吵醒；设高了，挖矿病毒跑满核心了才发现。主机选今天分享一套实战方案，利用 n8n 搭建自动化工作流，接入 AI Agent 智能判断 CPU 波动，把“短时抖动”和“持续异常”区分开，实现精准告警。

zhujixuan TASK 241

传统监控阈值为何总是误报？

传统监控如 Zabbix 或 Prometheus，核心逻辑是“触发器”。一旦 CPU 使用率超过 80%，立马发消息。这种逻辑很死板，不懂上下文。

比如，WordPress 自动更新、定时备份、凌晨的日志压缩，这些都会导致 CPU 瞬间飙升。如果监控没做“持续 5 分钟”的延迟触发，你的手机就会响个不停。更坑的是，有些恶意进程是“低频持续”占用，平时 30%，偶尔冲到 60%，这种慢刀子割肉的方式往往逃过阈值报警。

我们需要一个能“看懂趋势”的 AI Agent，让它盯着一段时间的负载曲线，而不是盯着某一个点。

基于 n8n 和 AI Agent 的智能监控架构

这套方案的核心是 n8n 作为调度中心，Shell 脚本采集数据，AI Agent（如 OpenAI API 或本地 Ollama 模型）做逻辑判断，最后通过 Telegram 或 Bark 发送通知。

架构流程如下：
1.数据采集：VPS 定时运行 Shell 脚本，获取当前 CPU 负载和 Top 进程信息。
2.推送到 n8n：脚本通过 Webhook 将数据发送给 n8n。
3.AI 分析：AI Agent 接收数据，结合历史上下文，判断是“正常波动”还是“异常持续”。
4.动作执行：只有 AI 判定为异常时，才触发告警。

编写 Shell 脚本获取 CPU 负载

不要安装笨重的 Agent，直接用原生命令。登录 VPS，编写一个简单的采集脚本 `cpu_check.sh`。

#!/bin/bash

LOAD_AVG=$(uptime | awk -F'load average:' '{print $2}' | cut -d, -f1 | xargs)
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *$[0-9.]*$%* id.*/\1/" | awk '{print 100 – $1}')
TOP_PROCESS=$(ps -eo pid,ppid,cmd,%mem,%cpu –sort=-%cpu | head -n 6)

JSON=$(cat <<EOF
{
"hostname": "$(hostname)",
"load_avg": "$LOAD_AVG",
"cpu_usage": "$CPU_USAGE",
"top_process": "$(echo "$TOP_PROCESS" | sed ':a;N;$!ba;s/\n/ | /g')",
"timestamp": "$(date +%s)"
}
EOF
)

curl -X POST -H "Content-Type: application/json" -d "$JSON" https://your-n8n-domain.com/webhook/cpu-monitor

给脚本执行权限 `chmod +x cpu_check.sh`，并加入 Crontab，建议每 3 分钟执行一次。频率太高不仅浪费资源，还会被 API 限流。

配置 n8n 接收数据与 AI Agent 节点

在 n8n 中创建一个 Workflow，第一个节点是Webhook，路径设置为 `/cpu-monitor`，Method 选 `POST`。

紧接着添加AI Agent节点（如果用 OpenAI，则选 HTTP Request 或 OpenAI 节点；如果用本地部署，推荐用 Ollama 节点连接 `llama3` 或 `qwen2.5` 模型）。

这里的关键是Prompt（提示词）。你得教 AI 怎么干活，不能只丢数据给它。

区分抖动与异常的 Prompt 编写技巧

在 AI Agent 的 System Prompt 或 Message 中，输入以下逻辑：

> 你是一个资深 Linux 运维专家。请分析以下 VPS 监控数据。
> 数据包含：主机名、5分钟平均负载、当前 CPU 使用率、Top 进程。
>
>判断标准：
> 1. 如果 CPU 使用率瞬间超过 90%，但 Top 进程显示是 `zip`、`apt`、`mysqldump` 等维护任务，判定为“短时波动”，不告警。
> 2. 如果 CPU 使用率持续（多次数据）高于 75%，且 Top 进程出现陌生名称、大量 `kworker` 或未知用户进程，判定为“持续异常”，需告警。
> 3. 如果负载极高但 CPU 使用率不高，可能是 IO 瓶颈，提示“IO Wait 过高”。
>
>输出要求：
> 严格输出 JSON 格式，不要废话：
> {
> "status": "normal" | "warning" | "critical",
> "reason": "简要说明原因，如：备份任务导致短时飙升"，
> "suggestion": "处理建议，如：无操作或检查进程 PID 1234"
> }

n8n 的后续节点使用JSON Parse解析这个输出。只有当 `status` 为 `critical` 时，才走IF节点连接 Telegram 发送消息。这样就把逻辑判断甩给了 AI，工作流变得极简。

告警动作与消息推送

在 IF 节点的 True 分支，放置 Telegram 或 Slack 节点。消息内容直接引用 AI 返回的 `reason` 和 `suggestion`。

例如发送到 Telegram：

🚨 [异常告警] {{ $json.hostname }}
CPU 状态: {{ $json.cpu_usage }}%
AI 判定: {{ $json.reason }}
建议: {{ $json.suggestion }}
Top 进程: {{ $json.top_process }}

这样你收到消息时，不仅知道 CPU 高了，还知道 AI 觉得是因为什么，甚至可能直接告诉你哪个 PID 可疑。

老鸟叮嘱：AI 监控的稳定性维护

这套方案虽然灵活，但也有坑，踩过才知道疼。

1.n8n 自身别被监控搞死：n8n 比较吃内存，尤其是跑在低配 VPS 上。如果 VPS 只有 1G 内存，建议用 Docker 部署 n8n，并限制内存上限，防止 n8n 把自己 OOM（Out of Memory）杀掉了。
2.API Key 别乱丢：如果你用 OpenAI 或 Claude API，n8n 的 Workflow 文件里会明文存储 Key。务必开启 n8n 的数据加密功能，或者用环境变量存储 Key，别把 Workflow 随便导出分享。
3.采样频率要克制：脚本不要设为每分钟跑一次，不仅费钱（API 调用费），而且 AI 看不出趋势。3-5 分钟一次足够应对大部分异常。
4.本地模型慎用大参数：如果用 Ollama 本地跑模型，VPS 算力不够会导致判断延迟极高。建议用 7B 或更小的量化模型，或者干脆用云端 API，响应速度才是告警的生命线。
5.日志留存：n8n 的执行日志记得开，如果哪天没收到告警，回头查日志看 AI 是不是“摆烂”了，或者网络是不是断了。