Beszel 上手体验：比重量级方案轻得多的服务器监控选择

手头有三五台机器的人大多经历过这个阶段：一开始靠 SSH 上去 top 一下，后来机器多了，出问题总是最后一个知道。想装 Zabbix 或 Prometheus，光看部署文档就得花一个下午，配完 Grafana 面板已经不想再看第二眼。Beszel 就是冲着这个人群来的——单二进制、内置 Web 界面、默认就带告警，装完十分钟内能看到第一张图。

它到底轻到什么程度，值不值得占用一个端口

Beszel 的 hub 端是一个 Go 编译出来的单文件，数据库用的是内嵌的 pocketbase，落在磁盘上就是一个 .db 文件。官方给出的常驻内存在 20~30MB 区间，实际跑在一台 1 核 1G 的小机器上基本感觉不到存在。被监控的机器需要跑一个 agent，同样也是单个二进制，通常占用不到 10MB。

这个量级意味着什么？你完全可以把 hub 塞进一台本来就在跑网站的边缘节点，不用单独开一台监控机。对比之下，Prometheus 加 Grafana 加 Alertmanager 这套组合，光 Prometheus 自身在中小规模下就要吃掉 200MB 到 500MB 内存，还得额外配存储保留策略。

我一般会建议先把 hub 放在一台长期在线的机器上，agent 按需铺开。如果你的机器本身是香港或美国机房的独立服务器，带宽和配置都够，直接在同机上跑 hub 也不会影响业务。

能看什么、不能看什么，先划清楚

Beszel 采集的指标偏向「够用就好」：CPU 使用率、内存、磁盘占用、磁盘 IO、网络上下行、系统负载、运行时长。容器层面它接 Docker 的 stats 接口，能看到每个容器的 CPU 和内存曲线，这一点对跑着一堆 Docker 服务的站长很实用。

它不做的事也很明确：

• 没有分布式追踪，也没有日志聚合，想看 nginx access log 得另找工具
• 告警只支持 Webhook、邮件和几种常见通知渠道，规则是阈值式的，写不了 PromQL 那种复杂表达式
• 历史数据默认保留周期短，长期趋势分析不是它的强项

所以判断标准很简单：你要的是「机器挂了第一时间知道、平时能瞄一眼负载」，Beszel 够用；你要的是容量规划、SLO 报表、跨集群聚合，直接上 Prometheus，别在轻量工具上硬撑。

部署时最容易卡住的几个点

真正上手时，问题通常不在安装，而在网络和权限。agent 默认通过 WebSocket 连回 hub，hub 需要暴露一个端口给 agent，如果机器在 NAT 后面或者安全组只开了 80/443，就得先把这个端口放通。反过来，agent 主动外连的模式更省事，适合被监控机器没有公网入口的情况。

另一个坑是磁盘监控的挂载点。默认只盯根分区，如果你的数据盘是单独挂的 /data，不在配置里加进去，盘写满了它也不会告警。

告警阈值我一般会先按保守值设：CPU 持续 5 分钟超过 85%、内存超过 90%、磁盘超过 85% 触发。跑一两周再根据真实负载调整，比一上来就抄别人的模板靠谱。

什么规模该换方案，什么规模可以一直用

我的经验是，20 台以内 Beszel 完全撑得住，界面响应也不会慢。超过这个数量，agent 管理和告警去重会开始变得麻烦，这时候分水岭就出现了：要么接受它的简单，要么迁移到带服务发现和标签体系的方案。

如果你的机器是托管在机房的物理服务器，比如 香港高防服务器 XI 这类 E5-2650*2 / 32G 配置，本身资源充裕，跑一套 Beszel 加几个业务容器几乎无感。预算有限、机器数量不多的阶段，省下的那笔监控软件授权费和一台监控机的租用费，够你多续一个月服务器了。

一句话结论：个人站长和 10 台以内的小团队，装 Beszel，花半小时配好告警就收工；已经上到几十台、需要跨机房统一视图的，直接选 Prometheus 生态，别在轻量工具上反复打补丁。