前言

这个项目是我的实验项目，可能有很多问题，欢迎对我提出意见。

不知道你有没有遇到过这样的情况：服务器突然报警了，但是打开监控一看，几十条告警刷屏，CPU、内存、磁盘全都在报，根本分不清哪个是根因、哪个是连锁反应。运维手忙脚乱地在各个系统之间切来切去，翻日志、查监控、看调用链，半小时过去了，问题还没定位到。这就是典型的运维困境。真正出问题的时候，还是靠人肉排查。

所以我们做一件事：把AI能力揉进运维里，让机器帮我们做告警降噪、异常检测、根因分析。

这个平台能做什么

全景监控：仪表盘上展示在线节点数、平均响应时间、系统可用率这些关键指标。CPU、内存的趋势图用折线图展示，AI检测到的异常点会用红点高亮标记出来。时间范围可以切换1小时、6小时、24小时、7天，想看短期波动还是长期趋势都行。

智能告警：原始告警进来之后，AI会做聚类去重，把同一故障引发的多条告警聚合到一个事件里。然后自动打上标签——是资源问题、网络问题还是应用问题？同时生成初步的处置建议，比如“建议清理日志”或者“检查进程”。这样一来，运维人员直接看聚合后的事件就行。

资源预测：基于Prophet时序预测模型，对CPU、内存、磁盘这些资源做趋势预测。比如“磁盘预计4天后写满”，提前预警，给扩容留出时间窗口。

数据报告：自动生成运维数据报告，方便复盘存档。

技术架构长什么样

前端：React 18 + TypeScript + Vite + Ant Design。用TypeScript主要是为了类型安全，Vite的构建速度确实快，开发体验很好。UI用的是Ant Design，这些无所谓，前端根据自己需求来就好

后端：Python 3.8 + FastAPI。选FastAPI是因为它性能不错，而且自动生成API文档这个功能非常好用，开发和调试都省事。用Python主要是为了方便集成AI模型，毕竟Python的AI生态太成熟了。

数据层：MySQL存历史数据、用户信息、告警记录，毕竟是最常用的一个数据库，Redis存实时监控数据，毫秒级的读写速度，满足仪表盘实时刷新的需求。冷热分离，性能上能做到平衡。

AI引擎：Ollama + TinyLlama做日志分析和异常检测。Prophet做时序预测。这些模型在中小规模场景下够用了，部署成本也低，但是如果有api我建议还是用api，毕竟部署了本地模型就不够轻量化了，再小的模型都得要几个G往上

监控采集：Zabbix Agent负责采集CPU、内存、磁盘这些基础指标，写入Redis缓存。

部署架构也挺清晰的，Nginx托管前端静态文件，同时反向代理后端API请求。后端服务通过systemd管理，监听127.0.0.1:8000，只让Nginx访问，不对外暴露。MySQL和Redis也是本地监听

核心功能的实现思路

实时数据流：Zabbix Agent采集的数据直接写入Redis，键名设计得很直观，比如metric:cpu存CPU使用率。前端请求实时数据时，后端直接从Redis读，毫秒级响应。同时有一个常驻服务从Redis读最新数据，写入MySQL的metrics_history表做持久化。

历史数据聚合：原始数据是每5秒一条，存久了量太大。所以写了一个定时任务，每小时做一次聚合，算出这一小时的CPU平均、最大、最小值，存到metrics_hourly表。前端展示历史趋势图的时候，查这张聚合表就够了，速度快很多。

规则引擎：告警触发不只是靠AI，也支持配置规则（yaml文件）比如“CPU使用率超过90%持续5分钟就发告警”。规则引擎每10秒读一次Redis里的最新指标，和阈值比对，触发告警就写入alert_history表。做了去重逻辑，同一个告警30分钟内不会重复触发

AI日志分析：前端输入一段日志，后端调用Ollama的API，把日志文本和提示词一起发给TinyLlama模型，让它分析原因并给出建议。模型返回的结果直接展示在界面上。

部署的时候需要注意什么

数据库初始化：创建数据库和用户，给专门的用户只授权给业务数据库，别用root连。建表语句和执行脚本都在项目里准备好了，跑一遍就行。

后端服务管理：生产环境用systemd管理进程，这样服务挂了会自动重启。配置文件里指定WorkingDirectory和EnvironmentFile，把环境变量和启动命令分开。

Nginx配置：核心是两段location。location /托管静态文件，try_files $uri $uri/ /index.html确保前端路由正常工作。location /api/做反向代理，把请求转发到后端8000端口。静态资源那一堆js、css、图片可以单独配置缓存，加个expires 1y，浏览器会缓存一年。

验证和运维

部署完了怎么验证？浏览器能打开登录页算第一步。然后用curl测一下健康检查接口，curl http://localhost/api/health，返回{"status":"ok"}说明后端通了。登录测试一下，能进仪表盘算基本成功。

日常运维主要是这几件事：服务启停用systemctl命令；日志查看用journalctl；数据备份每天凌晨自动跑mysqldump，保留7天；日志轮转用logrotate配置，避免日志把磁盘撑爆。

心得

告警去重很重要。一开始没做去重，CPU一波动能触发十几条告警，页面根本看不过来。后来加了去重逻辑，同一类告警30分钟内只发一次，效果好很多。

Redis连不上怎么办。之前Redis挂了，前端页面直接报错，体验很差。后来代码里加了异常处理，Redis读不到数据就返回空，页面至少还能展示，不会白屏。

模型下载慢。TinyLlama虽然小，但国内网络有时候也慢。其实如果你有大模型的API，完全不需要本地部署，倒不如说，我根本不建议本地docker部署。

前后端联调的坑。前端开发时用Vite的proxy代理，生产用Nginx代理，路径保持一致很重要。我们约定/api前缀，前端所有请求都带这个前缀，Nginx统一转发到后端8000端口，这样开发和生产环境配置基本一致。

项目结构参考

zhiwei/
├── backend/ # 后端代码
│ ├── app/
│ │ ├── core/ # 核心配置
│ │ │ ├── config.py # 应用配置
│ │ │ └── database.py # 数据库连接
│ │ ├── models/ # 数据模型
│ │ │ └── user.py # 用户表模型
│ │ ├── routers/ # API路由
│ │ │ ├── auth.py # 认证接口
│ │ │ ├── metrics.py # 监控指标接口
│ │ │ ├── alerts.py # 告警接口
│ │ │ └── ai.py # AI分析接口
│ │ └── services/ # 服务层
│ │ ├── redis_client.py # Redis客户端
│ │ └── mysql_client.py # MySQL客户端
│ ├── main.py # 应用入口
│ └── requirements.txt # Python依赖
│
├── frontend/ # 前端代码
│ ├── src/
│ │ ├── api/ # API调用
│ │ │ └── index.ts # 接口封装
│ │ ├── components/ # 公共组件
│ │ │ └── RightNav.tsx # 右侧导航
│ │ ├── contexts/ # 上下文
│ │ │ └── AuthContext.tsx # 认证状态管理
│ │ ├── pages/ # 页面
│ │ │ ├── Login.tsx # 登录页
│ │ │ ├── Register.tsx # 注册页
│ │ │ ├── Dashboard.tsx # 仪表盘主页
│ │ │ └── Details.tsx # 详情页
│ │ ├── router/ # 路由配置
│ │ │ └── index.tsx
│ │ ├── styles/ # 样式文件
│ │ │ └── global.css
│ │ ├── App.tsx # 根组件
│ │ ├── main.tsx # 入口文件
│ │ └── vite-env.d.ts # 类型声明
│ ├── index.html # HTML模板
│ ├── package.json # 前端依赖
│ ├── tsconfig.json # TypeScript配置
│ └── vite.config.ts # Vite配置
│
└── scripts/ # 辅助脚本
├── rule_engine.py # 规则引擎（告警触发）
├── aggregate.py # 数据聚合（小时任务）
├── maintain.py # 数据维护（清理+备份）
├── save_to_mysql.py # Redis→MySQL数据同步
├── prepare.py # 数据预处理
├── get_from_redis.py # Redis数据采集
└── deploy_model.py # AI模型部署

最后

这个项目从设计到开发再到测试，前后花了一个月时间。代码量不算大，但涉及的技术栈挺全，前端、后端、数据库、缓存、AI模型，基本把一套完整系统的各个层面都走了一遍。

如果你想学习借鉴，这个项目可以当个参考。如果你开发监控系统，代码里的一些实现思路可能对你有帮助。