被告警吵醒太多次，我做了个让告警自动修复的监控工具

写给一个人管着好几台服务器、每周至少被叫醒一次的你。

那个熟悉的夜晚

手机震动。

不是闹钟，是告警。

你眯着眼睛看屏幕：CPU 使用率 95%，nginx 响应超时。时间：凌晨 3:17。

你爬起来，打开电脑，ssh 上去，top 一看，几个进程占着资源，但说不清为什么。tail -f /var/log/nginx/error.log，日志刷得飞快，里面有报错，但报错指向另一个服务。你去看那个服务的日志，又发现它在等数据库连接。数据库呢？连接池满了。

二十分钟过去了。你重启了几个服务，告警消了。

你不知道根本原因是什么。你只知道重启有用。

你关上电脑，躺回床上，脑子还是转着。明天还要上班。

这不是意外，这是你的日常。

监控工具的本质局限

我用过 Grafana、Zabbix、Prometheus，这些工具都挺好。Grafana 的图表漂亮，Prometheus 的数据采集稳定，Zabbix 配置灵活。

但它们有一个共同点，也是一个共同的局限：

它们告诉你哪里坏了，不告诉你为什么坏，更不告诉你怎么修。

你盯着 Grafana 的折线图，看到 CPU 在某个时间点突然飙升。然后呢？你打开终端，开始猜。是新部署的代码？是某个定时任务？是内存泄漏触发了 swap？

每次告警处理都是一次侦探游戏。只是这个游戏在深夜玩，没有人帮你，你还睡眠不足。

更糟糕的是告警疲劳。

当你的监控系统足够细致，告警就会变多。CPU 超 80% 告警，磁盘超 70% 告警，请求延迟超 500ms 告警......你开始对告警脱敏。不是因为你不在乎，是因为大部分告警你看完之后只能说"嗯，有问题"，然后手动去查。

久而久之，你开始降低告警阈值，或者把部分告警设成静音。然后真正的问题来了，你没注意到。

我认识几个独立开发者，他们管着自己产品的服务器，都经历过这个阶段：从精心配置监控，到告警轰炸，到逐渐忽略告警，到某天线上出大事才发现早有征兆。

监控工具的问题不是数据不够多，是数据和行动之间的鸿沟太宽。你有一堆指标，但从指标到"我该怎么做"，中间需要你的经验、你的时间、你的精力。

这个鸿沟，在夜里特别宽。

如果告警能自己诊断呢？

有一天我在想：

我处理告警的过程，本质上是有规律的。看指标 → 查日志 → 关联上下文 → 判断原因 → 决定操作。这个过程我做了几百次，很多问题我一眼就能猜到原因。

那这个"经验"能不能让机器来做？

不是简单的规则引擎（那等于又回到了 Zabbix 的老路）。是真正理解上下文、能给出解释、能提出建议的 AI 分析。

这就是我做 VigilOps 的出发点。

VigilOps 是什么

VigilOps 是一个开源的运维监控平台，用 FastAPI + React 写的，部署靠 Docker Compose。核心想法很简单：监控不应该只是看板，它应该帮你解决问题。

有几个功能值得说一说。

AI 根因分析

当告警触发，VigilOps 不只是发通知，它会同时做一件事：把当前的指标、日志、历史模式喂给 AI，让它分析可能的原因，并给出建议。

不是"CPU 使用率 95%，请检查"这种废话。而是：

"过去 30 分钟 CPU 持续上升，与此同时 worker 进程数增加了 3 倍。这个模式在上周三也出现过，当时的根因是某定时任务触发了批量数据处理。建议检查是否有计划任务在此时运行。"

这种分析不保证 100% 准确，但它给了你一个起点。你不用从零开始猜，你有一个方向。

自动修复 Runbook

有些问题的处理方式是固定的。nginx 挂了就重启，磁盘超阈值就清日志，服务无响应就重启并通知。

VigilOps 内置了 6 个常用 Runbook，也支持自定义。当告警触发，系统可以自动执行对应的修复操作，或者提示你"是否自动修复"。

你可以选择全自动，也可以选择"AI 分析 + 人工确认"。后者更适合生产环境------你在睡觉，但你知道如果 nginx 挂了，系统已经在处理了，等你醒来只需要看一眼日志确认结果。

MCP Server

这个功能比较新，但我个人挺喜欢的。

VigilOps 提供了一个 MCP Server，可以接入支持 MCP 协议的 AI 工具（比如 Claude Desktop）。这样你可以直接问：

"我的服务器现在状态怎么样？"

"过去一小时有什么异常吗？"

"帮我看看 nginx 的错误日志里有什么规律。"

不需要打开看板，不需要 ssh，用自然语言问就行。适合在手机上快速确认服务状态的场景。

部署

bash 复制代码

git clone https://github.com/LinChuang2008/vigilops.git
cd vigilops
cp .env.example .env
# 编辑 .env，填入你的配置（主要是 AI API Key 和数据库密码）
docker compose up -d

大概 15 分钟能跑起来。有详细的部署文档，我尽量写得对新人友好。

访问 http://localhost:3001 就能看到界面。

一个真实场景演示

前几天我在测试环境里模拟了一个场景：nginx 内存使用率持续攀升，最终超过 80%。

VigilOps 的告警触发后，AI 分析给出了这样的内容：

问题摘要：nginx worker 进程内存使用率 83%，过去 2 小时持续上升。

可能原因：

内存泄漏（高概率）：这个增长模式与典型的内存泄漏曲线一致，没有明显的峰值后回落。

流量突增导致 worker 扩展：检查了请求量日志，未发现异常流量，排除此原因。

历史对比：同样的模式在 2025-02-23 出现过，当时重启 nginx 后恢复正常，但原因未查明。

建议操作：

短期：重启 nginx worker（nginx -s reload），释放内存

中期：检查 nginx 配置中的 worker_rlimit_nofile 和第三方模块是否有已知内存泄漏问题

是否自动执行 nginx -s reload？ [确认] [跳过]

我点了确认，nginx 重启了，内存回到正常水平。

当然，这是测试环境，而且问题相对简单。整个过程：从告警触发到问题解决，2 分钟。不需要 ssh，不需要查日志，不需要猜原因。

真实的生产问题可能更复杂，AI 的分析不一定准确。但即使只是给你一个方向，缩短了你的排查时间，我觉得就值了。

诚实说一下现状

VigilOps 现在是开源早期阶段，代码在 GitHub 上，完全免费。

有些东西还在建设中：

Agent 采集配置还在完善，目前需要手动配置部分参数
AI 分析的准确率依赖于你的 AI API 配置，DeepSeek 和 OpenAI 都支持
文档还在补充，部分高级功能的说明不够完善
还没有做大规模生产环境的压测

我不想说这是一个多完美的产品，它还早。但它的核心想法是实用的，而且它在跑，你可以去试。

如果你试了发现问题，欢迎提 Issue。如果你觉得某个功能方向有价值，也欢迎讨论。开源项目就是这样长大的。

试试看？

GitHub ：github.com/LinChuang20...
在线 Demo ：http://139.196.210.68:3001（账号：demo@vigilops.io / demo123）

Demo 环境是真实部署的，你可以在上面感受一下 AI 分析的效果。

如果你也是那种一个人管着几台服务器、偶尔被告警打扰睡眠的开发者------这个工具是为你写的。

#运维 #监控 #AI #开源 #DevOps