· 斩杀评测 · 9 min read
轻量级监控新秀:Beszel vs Uptime Kuma vs Netdata 实测
手头有几台廉价 VPS 和本地 NAS,到底用什么监控最省心?实测对比 Beszel、Uptime Kuma 与 Netdata 在资源开销、容器指标与多节点探针上的“斩杀线”。
每一个喜欢折腾 VPS 探险 或自建 N100 家庭数据中心 的玩家,随着手里机器逐渐变多(2 台香港、1 台美国、1 台本地 NAS),必然会遇到一个经典焦虑:
“我的小鸡还活着吗?CPU 有没有被挖矿程序占满?Docker 容器有没有半夜悄悄 OOM 崩溃?512MB 内存的小鸡装监控会不会把机器直接撑爆?”
过去,我们在 《Uptime Kuma 监控实战》 中讲过如何搭建高颜值的状态页。但 Uptime Kuma 本质上只是**“黑盒探测(从外部 Ping/HTTP 请求)”**,它根本无法告诉你这台机器内部的 CPU 负载、温度、磁盘 I/O 和单个 Docker 容器的内存消耗。
为了搞定白盒监控,以前大家要么用老旧的 ServerStatus(界面停留在上个世纪),要么硬上 Netdata / Prometheus + Grafana(内存直接吃掉 300MB+,小鸡苦不堪言)。
直到开源监控黑马 Beszel 的横空出世,彻底击穿了轻量级服务器性能探针的**“资源斩杀线”**。今天,我结合手头 7 台异构节点的长期实测数据,采用 EEAT(亲历实操/底层架构解剖/权威横评/避坑指南) 标准,带你理清 2026 监控选型的终极方案。
一、 为什么监控体系需要“黑白分明”?
在进入具体工具对比前,先厘清两大监控流派的职责边界:
flowchart TD
subgraph 外部视角: 黑盒探测 (Blackbox)
A[Uptime Kuma / 状态页] --> B[外部 HTTP 状态码 200/502]
A --> C[TCP 端口连通性 / SSL 证书过期预警]
B --> D[回答: 别人能不能访问我的服务?]
end
subgraph 内部视角: 白盒探针 (Whitebox)
E[Beszel / Netdata Agent] --> F[CPU / 内存 / 磁盘 I/O / 网络吞吐]
E --> G[单个 Docker 容器资源排行与崩溃感知]
F --> H[回答: 我的服务器内部健不健康?]
end- Uptime Kuma 是守门人,负责从公网向内打探;
- Beszel / Netdata 是体内听诊器,负责常驻系统内部抓取运行指标。
二、 选手档案与核心架构对比
1. Beszel —— 2026 年极客圈的最爱(超轻白盒探针)
- 架构:服务端 Hub(基于 Go + PocketBase)+ 客户端 Agent(纯 Go 编写)。
- 杀手特性:Agent 极其轻巧,常驻内存仅 10MB~15MB,CPU 占用
< 0.1%;自动读取 Docker Socket 呈现每个容器的资源曲线;支持多节点一键集中管理。
2. Uptime Kuma —— 颜值天花板(黑盒可用性监控)
- 架构:Node.js / Vue 3 单体容器。
- 杀手特性:无需在被监控机安装任何 Agent,直接远程定时 Ping/curl;公开 Status Page 颜值极高,报警通道极其丰富。
3. Netdata —— 工业级性能显微镜(秒级实时监控)
- 架构:C/C++ 深度系统集成。
- 杀手特性:提供每秒级别的极致微观指标(包含内核中断、PCIe 总线、每个系统调用的追踪)。
- 软肋:内存常驻 150MB~300MB,对 512MB/1GB 低配 VPS 极不友好,多节点云端联动配置繁琐。
三、 极限横评:五大核心维度实测比拼
以下基于 1 台 512MB 内存入门 VPS 与 1 台 N100 本地主机下的实测数据对比:
| 评测维度 | Beszel (2026 最新版) | Uptime Kuma | Netdata | 斩杀评级 |
|---|---|---|---|---|
| 定位与侧重 | 轻量多节点性能探针 | 外部服务可用性探测 | 单机秒级工业级显微镜 | 互补而非替代 |
| 客户端 Agent 内存消耗 | 12MB (几乎无感) | 0MB (无客户端) | 180MB - 320MB | Beszel / Kuma 胜 |
| Docker 容器指标支持 | 原生支持 (CPU/内存折线图) | 仅能探测容器存活 | 极度详尽但界面过于繁杂 | Beszel 胜 |
| 多节点聚合看板 | 原生中心化 Hub | 支持,但需逐个配置探针 | 需接入 Netdata Cloud | Beszel 完胜 |
| 告警灵敏度与通道 | 支持 Telegram/Discord 等常用通知 | 通道极多 (支持国内微信/飞书/钉钉) | 丰富但报警规则编写复杂 | Uptime Kuma 胜 |
| 部署与上手门槛 | 极简(Docker 一行命令) | 极简(Docker 一行命令) | 中等 | Beszel / Kuma 胜 |
四、 实战部署:5分钟搭建 Beszel 全套探针体系
1. 服务端(Hub)部署 —— 部署在你主力 VPS 或 NAS 上
创建一个 docker-compose.yml 文件:
services:
beszel:
image: 'henrygd/beszel:latest'
container_name: 'beszel'
restart: unless-stopped
ports:
- '8090:8090'
volumes:
- ./beszel_data:/beszel_data启动后访问 http://IP:8090,注册管理员账号,并获取系统的公钥(Public Key)。
2. 被监控端(Agent)部署 —— 部署在所有你想监控的 VPS 和小主机上
在任何一台需要监控的 Linux 机器上运行(内存仅占 12MB):
docker run -d --name beszel-agent --restart unless-stopped --network host -v /var/run/docker.sock:/var/run/docker.sock:ro -e PORT=45876 -e KEY="你的Beszel服务端生成的Public_Key" henrygd/beszel-agent:latest刷新服务端 Web 界面,你瞬间就能在一个干净优雅的深色看板里,实时查看所有机器的 CPU 负载、磁盘消耗与各个 Docker 容器的运行曲线。
五、 ZSX 的“神仙组合”监控斩杀线
在 2026 年,不要试图用一个工具解决所有问题。我的生产级“双保险”监控架构如下:
graph TD
subgraph 监控中枢 (放高可用独立节点/NAS)
Hub1[Uptime Kuma: 监控网站状态 & 域名SSL]
Hub2[Beszel Hub: 聚合所有服务器性能探针]
end
subgraph 被监控节点群
NodeA[香港 VPS 512MB] -->|轻量 Agent 12MB| Hub2
NodeB[美国 VPS 1GB] -->|轻量 Agent 12MB| Hub2
NodeC[N100 家庭 NAS] -->|轻量 Agent 12MB| Hub2
Hub1 -.->|定时外网 HTTP GET| NodeA
Hub1 -.->|定时外网 HTTP GET| NodeB
end
Hub1 --> Notify[📢 统一 Telegram 告警机器人]
Hub2 --> Notify- 可用性与对外状态页:交给 Uptime Kuma。负责对外展示 99.9% 在线率,并在网站发生 502 时第一时间通过 Telegram 报警。
- 多节点内部性能探针:交给 Beszel。负责在机器被刷爆、内存泄漏、磁盘用量超过 85% 时发出预警,且完全不消耗小鸡宝贵的算力。
- 彻底淘汰 Netdata:除非你在做内核级性能调优,否则不要在 2GB 内存以下的机器上跑 Netdata。
六、 总结
监控的本质是**“减少心智负担”**,而不是给自己多养几个吃内存的“监控大爷”。
将 Uptime Kuma(外防可用性) 与 Beszel(内查性能指标) 组合起来,你就能以接近 0 的资源消耗,搭建起一套媲美企业级 SRE 的立体监控防线。
延伸阅读: