Beszel 监控实战：轻量部署与服务器选型搭配

手里管着三五台机器的时候，靠 SSH 挨个敲 top 是常态。等服务器涨到十几台，问题就来了：磁盘写满没人知道，内存泄漏到 OOM 才被发现，半夜被业务方电话叫醒才想起去看负载。这时候需要一套监控，但不少人卡在同一个地方——Prometheus 那一套 Grafana、Exporter、Alertmanager 加起来，光配置文件就够折腾一个周末，服务器少的场景根本不划算。Beszel 就是冲着这个空档来的：一个二进制文件，配几条 SSH 信息，半小时内能看到图表。这篇聊的是它适合什么样的规模、部署时注意什么，以及监控主机本身该怎么选。

Beszel 靠 SSH 抓数据，省掉了装 Agent 这一步

多数监控系统走的是 Agent 路线，被监控机器上要跑一个常驻进程，版本升级、端口开放、防火墙规则都得跟着维护。Beszel 换了个思路，主控端通过 SSH 连到被监控机器，定期读取 /proc 下的数据。这意味着被监控端几乎零改动，只要有 SSH 账号和读取权限就行。

代价也很明确。SSH 轮询有间隔，默认抓取频率比 Agent 模式粗，做秒级告警不合适。而且被监控机器必须允许主控端登录，安全组和密钥管理要做扎实。我一般会单独建一个只读账号，密钥单独生成，不复用运维常用的那把。

部署本身不复杂，Docker 一条命令能起来，也可以直接跑二进制。数据默认存在本地 SQLite 里，没有外部依赖。对十几台以内的规模，这套组合够用。

1 核 1G 就能跑，但别把它塞进业务机

Beszel 主控端资源占用很低，官方给的参考是空闲时内存占用不到 100MB，1 核 1G 的机器跑起来没压力。真正的问题不是它吃多少资源，而是你把它放在哪。

我见过把监控和业务混在同一台机器上的做法，省了一台机器的钱，代价是业务一崩监控也跟着断，出事的时候恰好什么都看不到。监控主机应该独立，哪怕配置低一点。

如果监控的机器分散在不同地区，主控端的网络位置就有讲究了。放在香港这类到内地和东南亚延迟都还行的节点，SSH 轮询的稳定性会比放在单一偏远地区好一些。需要长期跑、又不想和业务抢资源的话，香港宿主机(大母鸡)⑥这类独立资源可以拿来单独承载监控和内部工具，金牌6152*2 配 256G 内存，跑一套 Beszel 加几个内部服务绰绰有余。

告警配置是分水岭，配不好等于没监控

Beszel 支持把告警推到 Discord、Slack、邮件等渠道，配置项不多。这里是最容易出问题的地方，也是我认为最值得花时间的一节。

阈值定得太松，磁盘用到 95% 才响，留给你的处理时间可能只有几小时；定得太紧，CPU 一到 70% 就推消息，一周下来没人再看通知。按我的经验，磁盘和内存这类不会突变的指标，阈值可以设在 85% 左右；CPU 这类波动大的，看持续 5 分钟以上的均值更有意义。

还有一点常被忽略：告警渠道本身要能触达真人。推到没人看的群，和没配是一样的。我会把关键告警同时走两个渠道，一个即时通讯，一个邮件兜底。

它做不到的地方也要说清楚。Beszel 不做日志采集，没有链路追踪，复杂的多条件告警规则也不支持。业务规模上去之后，该上 Prometheus 还是得上，Beszel 更适合作为过渡或者轻量补充。

哪些场景值得上，哪些直接跳过

判断标准其实简单，看机器数量和团队人数。

• 机器在 20 台以内、没有专职运维，Beszel 的投入产出比最高，半天能上线。
• 机器超过 50 台，或者需要按业务维度做复杂告警，直接上 Prometheus 加 Grafana，别在轻量工具上反复打补丁。
• 只是想知道机器活没活着，Uptime Kuma 这类探活工具就够，不用上完整监控。

成本上，Beszel 本身免费，省下的是人力时间。多花的钱主要在监控主机上，一台独立的小配置机器，月付通常几十到一百多块，比起出事之后排查几小时的代价，这笔账算得过来。换我我会先把监控独立出来，再谈监控工具选哪个。