Beszel：一台1G内存小机器就能跑起来的服务器监控

手上机器一多，最先出问题的往往不是配置，而是没人发现。磁盘写满了没人知道，某个容器半夜挂了没人知道，等到用户投诉才去看，损失已经发生。商业监控方案按主机数收费，几台机器的小团队用起来总觉得不划算；自己写脚本轮询，又得维护一堆告警逻辑。Beszel 这类工具就是冲着这个空档来的：部署足够轻，功能覆盖常见指标，不逼你上整套平台。

它到底轻到什么程度

Beszel 分成两块：一个中心服务端，负责存数据、出图表、发告警；一个可选的 agent，装在需要监控的机器上。两者都是单个二进制文件，没有一堆依赖要装。

服务端本身很省资源。按我的经验，1 核 1G 的小机器跑服务端完全够，配上 SQLite 存指标，几十台主机的历史数据也压得住。这个体量意味着你可以把它塞进一台最便宜的机器，不用专门为监控开一台大配置。

它有两种采集方式，这个设计值得单独说：

• SSH 模式：服务端用 SSH 连到被监控主机，直接读 /proc 里的数据，被监控端什么都不用装
• Agent 模式：在被监控主机上跑一个几 MB 的小程序，主动上报

我一般优先用 SSH 模式。原因很实际：机器越多，装 agent 这件事越容易漏，尤其是临时加的机器。SSH 只要密钥通了就能加进来，省掉一轮部署。代价是服务端要保存被监控主机的 SSH 凭据，这点要提前想清楚权限怎么隔离。

能看什么，不能看什么

CPU、内存、磁盘占用、网络流量、系统负载，这些基础指标都有，图表按小时粒度展示。跑 Docker 的机器还能看到每个容器的状态和资源消耗，容器重启次数也会记下来，这个对排查「服务半夜自己挂掉」特别有用。

告警走的是阈值判断，CPU 或内存超过设定值、主机失联、容器退出，都能触发通知。通道支持常见的几种，配置不复杂。

但它不是全功能 APM。没有链路追踪，没有日志聚合，也没有复杂的多条件组合告警。想拿它替代专业可观测性平台，会失望。它的定位是把「机器还活着吗、资源够不够」这件事管住，别让基础问题拖到出事。

磁盘容量的告警我建议一定要开。磁盘写满是小团队最常见的翻车点，而且从写满到服务不可用往往只有几分钟。

部署前先定三件事

第一件是数据存哪。默认用 SQLite，单文件，备份就是拷文件，简单可靠。主机规模上到几百台、指标写入频繁时，可以考虑换成外部数据库。多数小团队用 SQLite 就够，别提前给自己加复杂度。

第二件是告警发给谁。别一上来就把所有指标都设成告警，那样一天能收几十条通知，最后没人看。先开磁盘、主机失联、关键容器退出这三类，其余的观察一段时间再决定。

第三件是被监控主机的权限。SSH 模式建议单独建一个只读账号，别直接用 root。这点麻烦一次，后面安心很久。

如果监控的主机本身是海外业务，采集链路和 SSH 稳定性会直接影响告警及时性。香港机房的机器到内地延迟通常更低，管理端放在同一区域更省心，像 香港大带宽服务器 XII 这类配置（E5-2683v4*2 / 64G / 300M）拿来跑监控服务端加上几个内部工具，资源是绰绰有余的。

什么时候该换方案

Beszel 的边界很清楚。主机数量还在几十台以内、只需要看基础资源和容器状态，它完全够用，而且维护成本低到你几乎不用管它。

一旦出现下面这些需求，就该考虑更完整的方案：需要跨服务调用链排查、需要日志集中检索、需要按业务维度做复杂告警分组。这些不是它的设计目标，硬凑只会浪费时间。

我的取舍是：先用它把基础监控立起来，把磁盘和可用性这两条线守住。等业务真的复杂到需要链路追踪，再上更重的平台，那时你也更清楚自己要什么。装一个二进制、配好 SSH 密钥、开三条告警，一个下午能全部搞定。