Beszel 装完就忘：一台轻量监控怎么盯住十几台海外机器

机器从三台涨到十几台之后，最烦的不是配置，是心里没底。香港一台、日本一台、美国两台，平时跑得好好的，某天早上发现某个站打不开，登上去才知道是磁盘写满或者内存被吃光。装一套完整的监控系统吧，光 Prometheus 加 Grafana 就要占掉一台小机器，还要维护一堆 exporter；不装吧，每次出事都靠猜。Beszel 就是冲着这个缝隙来的——单节点 agent 内存占用通常只有十几 MB，主控端也是一个二进制文件，数据走 SSH 拉取，不需要在每台机器上开额外端口。

它到底省掉了哪部分工作

传统监控的部署路径是：每台机器装 exporter，再配一个中心端去抓指标，中间还要处理网络可达性和鉴权。Beszel 把这件事压成了两步：主控端跑起来，然后填 IP、端口、SSH 凭据。它会通过 SSH 连上去读 /proc 下的数据，CPU、内存、磁盘占用、网络流量这几项都是现成的。

我一般会先拿一台非核心机器试。装完之后最直观的感受是启动快——主控端启动到页面能打开，通常几秒钟。页面上每台机器的卡片直接显示当前负载，不用点进去翻三层菜单。对于只想回答「这台机器现在活着吗、资源还剩多少」的场景，这个信息密度刚好。

取舍也很明显。它不做长期存储，默认保留的数据窗口有限，想查三个月前的趋势基本没戏。省下的磁盘和内存，换来的是历史数据的缺失。

哪些指标它默认不给你

这是最容易踩的坑。Beszel 采集的是系统层面的基础指标，下面这几类默认看不到：

• 磁盘 IO 的具体读写延迟，只能看到磁盘使用率和大致活动
• TCP 连接数、TIME_WAIT 堆积这类网络层细节
• 带宽峰值的历史曲线，只有当前速率
• 应用层面的指标，比如 MySQL 慢查询、Nginx 5xx 比例

如果你的业务是跑网站或者 API，连接数堆积往往是故障的前兆，而这一项恰好不在默认视野里。我的处理办法是在 Beszel 里设一个内存阈值告警，同时在业务侧单独挂一个探针脚本，两边互补。

还有一点：它靠 SSH 拉数据，意味着主控端必须能稳定连上被监控机器。海外机器如果 SSH 端口改过或者用了密钥轮换，每次调整都要同步改配置。这点我没实测过大规模场景，机器数量上去之后 SSH 连接本身的开销值得留意。

选海外机器的时候，监控数据回传走的是 SSH，对线路质量有一定要求。像 美国西雅图高防服务器9 这种 100M 带宽的配置，E5-2620 加 32G 内存，跑监控主控端加上几个被监控节点绰绰有余，月付 $129.00 这个档位对个人和小团队来说压力不大。

告警配置要克制

Beszel 支持把告警推到常用渠道，配置项不多，这是优点也是陷阱。刚上手的时候容易把阈值设得很敏感，结果半夜被内存告警吵醒，登上去发现只是缓存占用高，实际可用内存充足。

我的做法是分两级：内存使用率超过 90% 且持续一段时间才告警，磁盘使用率超过 85% 直接告警。CPU 负载反而不太需要设，短时飙高是正常的，长期偏高才说明配置不够。这里的具体数值按你的业务调，但原则是宁可漏报一次，也别让告警变成噪音——被吵多了之后，真出事的那条反而会被忽略。

还有个小细节：告警通道建议单独用一个不常用的邮箱或者群，别和业务通知混在一起。混在一起的结果就是所有通知都被静音。

什么时候该换更重的方案

Beszel 的边界很清楚。机器数量在十几台以内、只需要看基础资源、不需要精细的历史分析，它足够用。一旦出现下面这些需求，就该考虑 Prometheus 那套体系了：

• 需要按分钟级精度回溯一个月以上的资源曲线
• 要监控应用内部指标，比如队列长度、缓存命中率
• 多团队协作，需要细粒度的权限和仪表盘共享

换的代价是维护成本，大概要多花一台 2 核 4G 的机器专门跑监控栈，加上持续投入的配置时间。所以我的判断是：先上 Beszel，等它真的不够用了再迁移，别一上来就按大集群的标准铺摊子。

如果你现在的机器分散在香港、日本、美国几个机房，想找一台稳定的主控端长期跑着，日本东京服务器2 的 E5-2630L 配 16G 内存、20M 带宽，月付 $119.00，作为监控中心节点延迟和成本都还算平衡。真正要盯的还是被监控的那些业务机，主控端本身不需要多强。

结论直接给：机器少于十五台、只想看资源水位，装 Beszel，十分钟搞定；需要应用级指标和长期趋势，直接上 Prometheus 加 Grafana，别在轻量工具上做二次开发；告警阈值先从宽设起，跑一周再收紧。