Beszel 部署与选型：轻量监控到底适合什么规模
手里管着几台机器的人，多半都经历过这个阶段：一开始靠 SSH 上去敲 top 看负载，机器少的时候没问题，等机器数量过了五六台，就变成每天挨个登录一遍。想上 Prometheus 加 Grafana，光是把 exporter、存储和告警规则配齐，就得先搭一套环境。对只有几台机器的人来说，这套东西的维护成本比被监控的机器本身还高。
Beszel 解决的就是这个夹缝里的需求。它用 Go 写的，被控端不需要装 agent，主控端通过 SSH 去拉数据。判断它适不适合你，关键看两件事：你现在管多少台机器，以及你愿意为监控花多少精力维护。下面把部署方式和取舍讲清楚。
为什么它不需要在被控机上装 agent
多数监控方案走的是 agent 路线：被控机跑一个采集进程，把指标推给服务端。好处是能穿透网络限制，坏处是每台机器都得装、都得升级，机器一多版本就容易乱。
Beszel 换了个思路，主控端通过 SSH 连上被控机，直接读 /proc 和系统命令拿数据。对被控机来说，你只需要给它一个能登录的账号和密钥。这点对临时接管的机器特别省事——不用改对方的系统环境，配好密钥就能纳管。
代价也在这里。SSH 不通的机器监控就断，所以网络策略得提前放行。另外采集频率受限于 SSH 会话开销，通常设成 60 秒一次比较稳，想做到秒级采集就不合适了。
部署路径和资源占用
主控端本身是个单二进制程序，用 Docker 跑最省事。一台 1 核 512M 的机器带十几台被控端没什么压力，这点我实际用下来是成立的。
- 主控端：Docker 镜像拉起，映射一个端口，数据落本地 SQLite
- 被控端：不需要装东西，在主控面板里填 IP、端口和 SSH 密钥即可
- 告警：支持邮件和 webhook，阈值按 CPU、内存、磁盘、网络分别设
数据存 SQLite 这点要想清楚。好处是零依赖，坏处是历史数据攒久了文件会变大，磁盘得留余量。它默认的保留周期不长，需要长周期趋势的话得自己调。
如果你打算把主控端放在一台长期在线的机器上，机房的稳定性比配置更重要。香港自营物理服务器(100M)⑤ 这类配置跑监控主控是绰绰有余的，E5-2695V4 加 32G 内存，月付 ¥3750.00，适合已经有机房资源、顺手把监控也放上去的情况。单为监控买这台机器不划算，这点我一般会先跟人说明白。
它做不了什么，以及什么时候该换
轻量工具的价值在于覆盖八成日常场景，剩下两成得靠别的方案补。Beszel 的短板主要有三块。
- 告警收敛弱：机器批量抖动时容易连发通知，没有成熟的分组和静默机制
- 指标维度浅：应用层指标、链路追踪这类它不管，只能看系统层
- 多租户和权限：团队协作场景下细粒度权限基本没有
所以规模到了几十台以上，或者需要给不同团队分权，还是得回到 Prometheus 那套体系。反过来说，如果你管的是十台以内的机器、主要想看 CPU 内存磁盘和网络，Beszel 省下的维护时间是真金白银。
换我我会这么选：个人项目和小团队先用它，把监控这件事从零做到有；等机器数量和协作需求真的上来了，再迁移。迁移成本也不高，因为被控端本来就没装东西。
最后给个直接结论。管十台以内、想五分钟把监控跑起来、能接受 60 秒采集间隔的，直接上 Beszel，主控端用一台 1 核 512M 的机器就够。需要秒级采集、复杂告警或者多团队分权的，别在这上面耗时间，直接上 Prometheus 加 Grafana。介于两者之间的，可以先用 Beszel 顶着，同时留意告警噪音是不是已经影响到你。