linux系统巡检架构

 一、采集层：Agent + psutil

这是整个监控体系的数据源头，部署在每一台被监控的 Linux 服务器上。

psutil：一个 Python 第三方库，提供跨平台的系统信息采集能力。Agent 通过它定时（如每 5 秒）采集以下数据：

- CPU 使用率、负载、各核心状态
- 内存使用量、Swap 使用情况
- 磁盘分区使用率、读写 I/O
- 网络接口的收发流量
- 进程列表及资源占用

• 自动发现与注册：Agent 启动时自动获取本机主机名、IP、操作系统版本等信息，向业务后端注册，无需手动录入主机信息

• 数据上报：采集到的数据通过 HTTP POST 或 gRPC 协议发送给上层的 Collector。上报格式通常为 JSON，包含时间戳、主机标识、指标类型和指标值

这一层的核心要求是轻量、稳定、低开销。Agent 本身的 CPU 占用应控制在 1% 以内，内存占用不超过 50MB，避免对被监控主机造成负担。

 二、数据处理与收集层：Collector

Collector 是整个架构的数据枢纽，独立部署，不依赖业务后端。

• 数据接收：提供 HTTP/gRPC 接口，同时接收来自上百台 Agent 的数据上报。支持批量接收，减少网络开销

• 数据清洗：

• • 过滤：丢弃无效数据或测试主机的数据

  • 标准化：统一不同主机上报的数据格式

  • 打标：自动附加元数据，如环境标签（prod/staging）、机房位置、业务线归属

• 数据聚合：对高频上报的数据进行降采样（如将每秒数据聚合为每分钟平均值），减少存储压力

• 路由分发：将不同类型的数据发送到不同的下游：

• • 时序指标 → 写入 Kafka 或直接写入 InfluxDB

  • 告警事件 → 发送到消息队列供告警引擎消费

  • 主机元数据 → 同步到 MySQL

Collector 的核心价值是解耦。Agent 不需要知道后端数据库的地址和结构，后端存储更换时也不需要改动 Agent，只需调整 Collector 的配置即可。　

 三、消息中间件层：Kafka / RabbitMQ

 消息中间件层是时序指标数据和告警事件的缓冲区与数据总线，位于 Collector 和 InfluxDB/告警引擎之间。而 MySQL 存储的元数据由 Collector 直接写入，不经过消息队列。

• 削峰填谷：监控数据存在明显的波峰波谷（如业务高峰期指标上报量激增）。消息队列将突发流量平滑为稳定流速，防止数据库被瞬间压垮

• 解耦：Collector 只负责把数据送进队列，不关心谁消费；存储层只从队列拉数据，不关心数据从哪来。两者可以独立扩缩容

• 数据持久化：消息在队列中保留一定时间（如 24 小时），即使存储层短暂宕机，数据也不会丢失

• 多方消费：同一份监控数据可以被多个消费者同时使用

• • InfluxDB 消费 → 用于时序存储和图表展示

  • 告警引擎消费 → 用于实时阈值判断

  • 大数据分析平台消费 → 用于容量规划和趋势预测

对于 100 台主机的规模，Kafka更适合（吞吐量高、持久化能力强）；如果规模较小（10 台以内），RabbitMQ 更轻量、运维更简单。

四、数据持久化层

这一层包含两种不同类型的数据库，各司其职：

MySQL

存储关系型元数据，数据量小但查询频繁：

• 主机信息表：主机名、IP、操作系统、所属业务线、负责人

• 用户表：用户名、密码（加密）、角色权限

• 告警规则表：告警名称、监控指标、阈值、通知方式、通知对象

• 告警历史表：每次告警的触发时间、恢复时间、处理状态

InfluxDB / Prometheus

存储时序监控指标，数据量大、写入频繁、查询以时间范围为主：

• InfluxDB：基于时间序列的数据库，写入性能极高，支持数据保留策略（如自动删除 90 天前的数据）和连续查询（预聚合降采样）

• Prometheus：另一种主流时序数据库，采用拉取（Pull）模式采集数据，内置强大的 PromQL 查询语言

两者选其一即可。如果你的 Agent 是主动推送（Push）模式，InfluxDB 更匹配；如果你愿意改为 Prometheus 主动拉取（Pull）模式，则选 Prometheus。

五、业务后端：FastAPI

这是整个监控平台的业务逻辑中枢，基于 Python 的 FastAPI 框架开发。

• 用户鉴权与权限管理：处理用户登录、JWT 令牌签发、RBAC 权限控制（如普通用户只能查看，管理员可以配置告警）

• 主机资产管理：提供主机的增删改查接口，管理主机组、标签、业务线归属

• 告警规则配置：提供 RESTful API，供前端配置和管理告警规则（如"CPU 使用率 > 80% 持续 5 分钟则告警"）

• 告警通知分发：当告警引擎触发告警后，FastAPI 负责调用第三方接口发送通知（邮件、钉钉、企业微信、短信等）

• 数据查询接口：从 InfluxDB/MySQL 查询历史数据，返回给前端用于图表渲染

FastAPI 的优势是高性能 + 自动生成 API 文档（Swagger UI），开发效率高，异步支持好。　

六、实时推送网关：WebSocket Server

这是一个独立部署的服务，专门负责向前端推送实时数据。

• 为什么需要独立：如果让 FastAPI 同时处理业务请求和实时推送，当连接数达到上千时，FastAPI 的事件循环会被大量 WebSocket 连接阻塞，导致业务接口响应变慢。独立部署后，两者互不干扰

• 数据来源：从 Kafka 或 Redis 订阅最新的监控数据

• 推送机制：

  • 前端建立 WebSocket 长连接后，网关将实时数据主动推送给前端

  • 支持按主机、按指标类型进行订阅过滤（前端只接收自己关心的数据）

  • 支持心跳检测和断线重连

七、前端展示层：Vue + ECharts

 

这是运维人员直接交互的界面。

 

• Vue：负责页面结构、路由管理、状态管理（Vuex/Pinia）、与后端 API 交互

• ECharts：负责数据可视化，渲染各种图表：

  • 折线图：CPU 使用率随时间变化趋势

  • 饼图：各主机内存占用占比

  • 热力图：集群整体健康状态

  • 仪表盘：关键指标的实时数值

• 两大交互模式：

  • HTTP 请求：用于获取历史数据、加载主机列表、配置告警规则等

  • WebSocket 连接：用于接收实时数据推送，实现监控大屏的秒级刷新

 

 八、完整数据流向

 

 

总结

这套架构的核心设计思想是分层解耦：

• 采集层只管采集，不管存储

• Collector只管接收和转发，不管业务

• 消息队列负责缓冲和解耦

• 存储层只管存和查

• 业务后端只管业务逻辑

• WebSocket 网关只管实时推送

• 前端只管展示

每一层都可以独立扩缩容、独立升级，任何一层的故障不会直接导致整个系统崩溃。这就是一个生产级监控系统应有的架构形态。