Beszel vs Netdata vs Uptime Kuma 对比：2026 轻量服务器监控怎么选

Beszel vs Netdata vs Uptime Kuma：轻量服务器监控三选一，2026 年怎么选不踩坑

🇺🇸
Read in English: Beszel vs Netdata vs Uptime Kuma: Picking the Right Lightweight Server Monitor in 2026

去年冬天有个朋友半夜给我发消息，说他的博客挂了六个小时才发现。他很委屈：机器上装着监控啊，面板打开一切正常，CPU 平稳、内存充足、磁盘还有一半空间。

我让他把面板截图发过来。图没问题，机器确实好好活着。问题在于，Nginx 的容器在凌晨两点退出了，宿主机上没人管，剩下的资源指标当然一片祥和。服务器很健康地什么也没干。

这个坑不是他一个人踩的。自建监控这件事，选工具的时候大家看的都是「哪个更轻」「哪个界面好看」「哪个 star 多」，很少有人先想清楚一件事：我到底想知道什么。

Beszel、Netdata、Uptime Kuma 这三个名字，几乎每个自建圈的推荐帖都会同时出现，看着像同类竞品。真装完你会发现它们回答的是三个不同的问题：

Beszel 回答「我这几台机器现在还好吗」。

Netdata 回答「这台机器刚才那一秒到底发生了什么」。

Uptime Kuma 回答「用户能不能打开我的网站」。

我朋友装的是资源类监控，想解决的却是可用性问题。工具没错，配对错了。

为什么「资源监控」和「可用性拨测」根本不是一回事

先把这层拆开，后面的选择才不会糊。

资源监控站在机器内部往外看。它在每台被监控的主机上跑一个采集进程，读 /proc、读 hwmon 传感器、读 Docker socket，报出 CPU、内存、磁盘 I/O、网络流量、温度这些数字。它的视角是「主机的生理指标」。

可用性拨测站在外面往里看。它不关心你机器里发生了什么，只反复敲门：HTTP 请求返回 200 了吗？TCP 端口连上了吗？ping 通了吗？证书还剩几天过期？它的视角是「一个用户能不能用」。

这两个视角有一段重叠，但不能互相替代。机器资源正常而服务不可用，是最常见的一种漏检。进程挂了、端口被防火墙吃了、证书过期、DNS 解析飘了、上游 CDN 出问题，这些在资源图上全都表现为「一切正常」。

反过来也一样。拨测告诉你网站 502 了，但不告诉你为什么。是内存打满被 OOM killer 收了，还是磁盘写满了，还是某个进程在疯狂占 CPU，得靠资源侧的历史曲线回溯。

想清楚这层，三个工具的位置就自然浮现了。

Beszel：给「我有几台机器」的人准备的答案

Beszel 是这三个里最年轻的，仓库 2024 年 7 月才建，现在 25000 星出头，Go 写的，MIT 许可证。作者 henrygd 把定位写得很直白：轻量服务器监控，带历史数据、Docker 统计和告警。

它的结构是 hub 加 agent 两件套。hub 是个基于 PocketBase 的 Web 应用，管着面板和系统列表；agent 装在每台要监控的机器上，把指标推给 hub。数据落在 hub 的 SQLite 里，没有额外的时序数据库要伺候。

这个设计有个很实际的好处：agent 不需要暴露到公网。hub 和 agent 之间用密钥认证，甚至可以走 Unix socket。你不用为了看监控给每台机器都开一个对外端口。

装起来是什么体感？官方文档给的 docker-compose 里 hub 和本机 agent 一起起来，改一个 APP_URL，docker compose up -d，然后浏览器进 8090 端口建管理员账号。加第二台机器就是把 hub 生成的 key 和 token 填到那台机器的 agent 环境变量里。整个过程不需要写配置文件语法，也不需要理解什么 scrape target。

它采集的东西比「轻量」这个词听起来的多一些：宿主机和容器各自的 CPU、内存、网络，磁盘用量和 I/O（支持多分区多设备），负载，温度传感器，风扇转速，Nvidia / AMD / Intel 的 GPU 占用和功耗，电池电量，还有 S.M.A.R.T. 硬盘健康和 ZFS 存储池状态。告警可以按 CPU、内存、磁盘、带宽、温度、风扇、负载和在线状态配置。多用户和 OAuth / OIDC 登录都有，备份能存到磁盘或 S3 兼容存储。这些能力官方特性页列得很清楚。

它不做的事同样清楚：没有秒级采样，没有服务发现，不会自动去扒你的 MySQL 或 Redis 内部指标，也不做外部拨测。它是一块仪表盘，不是显微镜。

我自己的判断是，Beszel 适合那种「机器数量在个位数到二十几台之间、都是自己的 VPS 或者家里的 homelab」的场景。你想要的是打开一页看到所有机器的健康状态，收到一条「某台机器磁盘要满了」的通知，而不是一套能做根因分析的可观测性平台。

Netdata：你需要的是那一秒的现场

Netdata 是另一个量级的东西。80000 星以上，2013 年就在了，GPL-3.0，主体现在是 Go。它的仓库描述已经不提「监控」这个词，改成了全栈可观测性。

它的核心差异不是功能多，而是时间分辨率。Netdata 默认按秒采集，而且历史数据也按秒存。这个差别在排障时候是决定性的。

设想一个场景：你的 API 每隔十几分钟就有几秒响应特别慢，用户偶尔投诉，你自己去点从来点不出来。用一分钟粒度的监控看，那几秒会被平均进整分钟的曲线里，图上是一条毫无异常的平线。秒级采集才能把那个尖刺显出来，然后你会看到它和某个定时任务的 I/O 峰值重合，问题就抓住了。

Netdata 的另一个特点是零配置自动发现。装完之后它会自己去扫这台机器上跑着什么，发现有 Nginx 就采 Nginx 指标，有 PostgreSQL 就采 PostgreSQL，有容器就逐个容器采。你不用手写一堆 exporter 配置。装完打开 http://机器IP:19999，几百张图已经在动了。

代价在两头。

一头是资源。秒级采集加上一台机器上千个指标，进程本身要占的内存和 CPU 比 Beszel 那种分钟级 agent 明显高一档。Netdata 官方一直在做优化，也提供了降低采集频率和裁剪采集模块的开关，但默认配置就是奔着「数据尽量全」去的，不是奔着「占用尽量小」去的。跑在 1GB 内存的小 VPS 上你会感觉到它的存在。

另一头是多机管理。Netdata 的 agent 是各自独立工作的，每台机器一个 dashboard、一套自己的告警配置。三台机器你可以开三个标签页，三十台就受不了了。官方的答案是接 Netdata Cloud。数据仍然留在你的机器上，Cloud 只做实时查询和统一面板，免费额度覆盖到 5 个节点。超过之后 Business 档按节点计费，官方定价页上写的是 $4.50 每节点每月（年付），带 RBAC、SSO、集中配置管理和企业通知集成这些；要完全本地部署的 Enterprise On-Premise 从 200 节点授权起，得联系销售。

这个模式有点意思：agent 完全开源免费不限节点，但「把多台机器合成一块面板」这件事是商业化的切口。你也可以自己用 agent 的 streaming 功能搭父子节点结构做聚合，官方文档里有，只是要自己动手配。

所以 Netdata 的定位我会这么描述：它是你的排障工具，不一定是你的日常看板。一台关键机器上装 Netdata，出事时进去翻那几秒钟的现场，这个用法投入产出比最高。

Uptime Kuma：唯一站在门外敲门的那个

回到我朋友那个 502 的故事。他真正需要的是 Uptime Kuma。

Uptime Kuma 是三个里 star 最多的，九万多，MIT，Node.js 写的，作者 louislam。它做的事很单一：从外部反复检查一个东西是否可用，不可用就通知你。

它能检查的类型比想象中多。README 里列的有 HTTP(s)、TCP 端口、HTTP 关键词匹配、HTTP JSON 查询、WebSocket、Ping、DNS 记录、Push（反向心跳）、Steam 游戏服务器、Docker 容器。最小检查间隔 20 秒。

关键词匹配这个功能值得单独说。只看 HTTP 状态码是不够的。一个 WordPress 站数据库连不上的时候，很可能仍然返回 200，页面上写着「建立数据库连接时出错」。配一条关键词监控，检查页面里是否包含某个只有正常时才出现的字符串，才算真的在检查「这个页面还有用吗」。

通知渠道是它的另一个强项。Telegram、Discord、Gotify、Slack、Pushover、SMTP 邮件，加起来官方仓库里维护着 90 多个通知服务的适配。你几乎不用担心自己那个小众的推送工具不支持。

它还带状态页功能，可以做多个、绑定到不同域名。如果你要给客户或者社区一个「我们的服务现在是否正常」的公开页面，这个开箱就有，不用另外搭。证书到期天数、ping 曲线、代理支持、两步验证也都在。

装法就是一条 docker run 或者一个 compose 文件，数据默认落本地卷。官方文档和仓库 README 里的 compose 配置基本可以直接抄。要注意的是官方明确说了不支持 NFS 这类网络文件系统存数据，得映射本地目录或卷。

它不做的事：不采集任何主机内部指标。没有 CPU 图，没有内存曲线，不知道你的磁盘还剩多少。它就是个不知疲倦的敲门人。

有一个部署细节容易被忽略，而且是原则性的：Uptime Kuma 不应该装在被监控的那台机器上。 装在同一台机器上，机器整体宕掉的时候，拨测程序自己也死了，通知发不出来。你会得到最糟糕的结果：一片安静，什么告警都没有。放在另一台 VPS 上，或者干脆放家里的一台常开小主机上，才有意义。

摆在一起看

三个工具在不同维度上的差异，用表格看一眼更清楚。要提醒的是，资源占用那一行只能给量级判断，实际数字和你机器上跑了多少容器、采了多少指标、留了多长历史强相关，任何一个具体数字脱离配置都没有意义。

维度	Beszel	Netdata	Uptime Kuma
定位	多机资源看板	单机深度可观测性	外部可用性拨测
视角	机器内部	机器内部	机器外部
采集粒度	分钟级	秒级	最小 20 秒检查间隔
部署方式	单二进制或 Docker，hub + agent	一键脚本 / 包管理器 / Docker	Docker 或 Node.js 直跑
部署复杂度	低	低（单机）到中（多机聚合）	低
资源占用量级	最省	三者中最高	低，随监控项数量增长
多机管理	hub 原生聚合	需 Netdata Cloud 或自建父子节点	单实例可监控任意多目标
主机指标	CPU / 内存 / 磁盘 / 网络 / 温度 / 风扇 / GPU / 电池 / S.M.A.R.T. / ZFS	上述加应用与服务自动发现，指标数量级更大	无
服务可用性检查	仅在线状态	有健康检查能力但非主职	HTTP / TCP / 关键词 / JSON / DNS / Ping / WebSocket / Docker / Push
告警条件	CPU / 内存 / 磁盘 / 带宽 / 温度 / 风扇 / 负载 / 状态	内置大量预设告警模板，可自定义	目标不可用 / 关键词缺失 / 证书临期
通知渠道	邮件与 webhook 类	Agent 本地通知，Cloud 侧含企业集成	90+ 种适配
公开状态页	无	无	有，支持多页与自定义域名
数据存储	SQLite（PocketBase）	自带时序库，分层保留	SQLite
许可证	MIT	GPL-3.0	MIT
托管服务	无官方托管	Netdata Cloud，免费至 5 节点，Business 档 $4.50/节点/月（年付）	无官方托管
GitHub 星数	约 2.5 万	约 8 万	约 9.1 万

表里最该注意的不是哪一列数字大，而是「视角」和「公开状态页」这两行。前两个都在机器内部，第三个在外面。这决定了它们能不能互相替代，答案是不能。

那到底装什么

一两台个人 VPS，跑博客或者小工具。 Uptime Kuma 加 Beszel，两个都装，都很省。Uptime Kuma 装在另一台机器或者家里的常开设备上，盯住你的域名和证书；Beszel 的 hub 随便放哪台机器，agent 铺开。这套组合覆盖了「服务挂了要立刻知道」和「资源快满了要提前知道」这两个真实需求，总占用不比单装一个 Netdata 多。

小团队 5 到 20 台机器。 主力还是 Beszel 做统一看板，Uptime Kuma 做对外可用性。额外在最关键的那一两台（数据库、主应用节点）上单独装 Netdata，平时不看，出事时进去翻秒级现场。别在全部机器上铺 Netdata，你会同时得到资源开销和面板碎片两个问题。

需要对外承诺 SLA。 Uptime Kuma 是刚需，它的状态页和历史可用率就是你和客户之间的凭证。但要接受一个限制：单实例 Uptime Kuma 只有一个探测点，你测到的可用性是「从这个网络位置看过去的可用性」。如果 SLA 对地域敏感，得在不同地区各放一个实例，或者认真考虑商业的多地探测服务。这不是 Uptime Kuma 做得不好，是自建单点拨测的固有边界。

已经有 Prometheus 加 Grafana 栈。 资源指标那块基本不需要新工具，node_exporter 已经在做了。但 Prometheus 生态里做外部拨测通常靠 blackbox_exporter，配置写起来比 Uptime Kuma 麻烦不少，而且没有开箱的状态页。很多有 Prometheus 的团队还是会单独跑一个 Uptime Kuma，专门管拨测和对外状态页，这个组合不算重复建设。Netdata 也能把指标暴露成 Prometheus 格式，如果你只是想要秒级数据接进现有栈，这条路是通的。

Netdata 单独用够不够？ 一台机器的话够。它的能力是三者里最全的，秒级数据加自动发现，日常看板和排障都能扛。但它缺外部视角这件事没法自己补，你还是不知道用户能不能打开你的网站。多台机器时，要么接 Cloud 付费，要么花时间自建 streaming 聚合。