Beszel 部署实战：给几台小机器装上轻量监控面板

手里管着两三台服务器的人，最容易卡在同一个问题上：机器不多，但总想知道它们还活着、磁盘有没有快满、内存是不是被某个进程吃光了。上重型监控吧，光是一个面板加时序数据库就要占掉一台 1核2G 的机器，对只有几台业务机的人来说，监控本身的成本快赶上被监控的机器了。不上吧，出问题只能靠 SSH 进去看，往往是被用户投诉才知道挂了。

Beszel 这类工具就是冲着这个缝隙来的。它把监控拆成两部分：每台被监控的机器跑一个 agent，负责采集并把数据推给中心端；中心端只负责存和展示。这个设计决定了它的资源占用天然就低，因为重活分散到了各个节点上。下面我按「什么样的规模值得上」到「装完怎么判断够用」的顺序讲，最后给一条适合小规模业务的落地路线。

它省下来的到底是什么钱

先把账算清楚。传统方案里，中心端要跑数据库、要跑 Web 服务，磁盘还得留出足够空间存历史数据，一台 2核4G 的机器是起步配置。Beszel 的中心端在多数情况下 1核1G 就能跑，实测内存占用通常在几十 MB 的区间，具体数字跟接入的节点数和采集频率有关。

省下的不只是机器钱。历史数据的清理策略、数据库备份、升级时的兼容问题，这些维护动作在小团队里往往是没人专职负责的，一旦出事就是半夜爬起来处理。轻量方案把这块复杂度压到了最低。

代价也很清楚：它能给的图表和告警维度比专业监控少。想要精细到某个 JVM 内部指标的，或者需要复杂告警联动规则的，它撑不起来。

部署流程里真正花时间的两步

整套东西装下来，快的话半小时能跑通。真正卡人的不是安装命令，而是两件事。

• 中心端的访问方式：直接暴露在公网还是走内网或隧道。暴露在公网就得认真配反向代理和证书，这一步省不掉。
• agent 到中心端的连通性：跨机房的情况下，端口放行和延迟都得先确认，否则你会以为是 agent 装错了，其实只是网络不通。

采集频率一般默认值就够用。调得太密，节点上 agent 的 CPU 占用会上来，中心端的存储增长也快，对只有几台机器的人来说没有意义。

还有一点：agent 的权限要控制好。它能读到容器的运行状态，等于能看到不少系统信息，别图省事给它开过大的权限。

什么规模该用它，什么规模该换

按我的经验，机器数量在十台以内、没有专职运维、只需要知道「谁挂了、谁快满了」的场景，这类轻量面板的性价比最高。十几台以上开始出现多机房、多角色、需要值班轮询的需求时，它的告警能力就会变成瓶颈。

判断标准可以简化成一条：你要的是「看一眼心里有数」，还是要「半夜自动打电话叫醒人」。前者够用，后者得换重型方案。

被监控的机器如果本身就是独立服务器或者物理机，agent 的资源开销更是可以忽略不计。像 香港自营国际物理服务器⑪ 这种金牌6138*2、64G 内存、100M 带宽的配置，跑业务的同时挂一个 agent，几乎感觉不到影响；对带宽更敏感的业务，美国洛杉矶大带宽服务器 XVII 的 G 口线路也适合把监控数据集中回传。

落地建议

如果是第一次上监控，我的建议是先只接一台机器跑一周，看看数据量和告警噪音能不能接受，再决定要不要铺开。很多人的问题不是没有监控，而是告警太多最后全部忽略。

预算方面，中心端用一台最便宜的香港云服务器，1H1G 月付几美元的量级就能起步，被监控的节点按台数增加 agent 即可。机器超过十五台、或者业务对可用性有明确 SLA 要求的，直接上成熟的重型方案，别在轻量工具上硬撑。