Beszel 上手记：一台轻量监控工具怎么盯住你的服务器

手里的服务器从一台变成三台、五台之后，问题就不再是「它有没有挂」，而是「它什么时候开始变慢的」。等用户来投诉再登录上去看，CPU 已经跑满半小时了。装一套完整的监控体系当然能解决，但对多数中小站长来说，Prometheus 加 Grafana 加 Alertmanager 这一套下来，光是维护监控本身就得占掉一台机器和不少精力。Beszel 走的是另一条路：一个二进制文件，配几个参数就能起来。

下面说的都是我在小规模环境里的实际取舍，不涉及大集群那套玩法。

它到底解决什么问题，不解决什么问题

Beszel 的核心能力很聚焦：采集宿主机的 CPU、内存、磁盘、网络、温度，以及 Docker 容器的运行状态，然后在网页上画成趋势图，超过阈值就发通知。就这些。

它不做日志聚合，不做链路追踪，也不做复杂的多级告警路由。如果你的需求是「出问题第一时间知道」，它够用；如果你的需求是「事后能还原一次故障的完整调用链」，那它帮不上忙，得另配日志系统。

判断标准很简单。机器数量在 20 台以内、业务以 Web 和数据库为主、没有专职运维，Beszel 的性价比很高。机器上百台、需要按团队分权限、需要对接工单系统，那就老老实实上 Prometheus 那一套，别在这里省时间。

部署成本：一台 1核1G 的机器就够

Beszel 用 Go 写，编译出来是单个可执行文件，没有运行时依赖。监控端（Hub）本身很省资源，我见过的配置里，1 核 1G 的实例跑起来内存常驻通常在 100MB 上下，具体数字跟被监控机器数量和采集频率有关。

被监控端有两种接入方式：

• Agent 模式：在被监控机上跑一个轻量 agent，走 WebSocket 上报，适合能自由装软件的机器。
• SSH 模式：Hub 直接通过 SSH 连过去读系统指标，不用在目标机装任何东西，适合临时纳管或者不方便改环境的机器。

我一般优先用 Agent，因为 SSH 模式在高频采集下会反复建连，被监控机上的 sshd 日志会比较吵。但如果只是临时看一眼某台机器的负载，SSH 模式省事得多，用完删掉就行。

这里有个取舍：监控端放在哪里。放在被监控的同一台业务机上，业务挂了监控也一起挂，等于白装。所以我倾向单独找一台便宜的小机器当 Hub。像 马来西亚裸机云 III 这种 E5-2680 / 32G / 20M 带宽、月付 $119.00 的配置拿来当监控端其实绰绰有余，甚至有点浪费，但它的好处是资源隔离彻底，业务机出问题不影响监控采集。

阈值怎么定，才是真正花时间的地方

装软件只花十分钟，调阈值可能花掉几个晚上。默认的告警规则往往太敏感，磁盘到 80% 就报警，结果你每天收十几条通知，最后全部忽略，监控就失去意义了。

我的做法是分三档：

• 磁盘：85% 发提醒，92% 发告警。中间留出清理缓存和日志的时间窗口。
• 内存：持续 5 分钟超过 90% 才告警，避免瞬时峰值误报。
• CPU：看的是 15 分钟均值，短时飙高通常是正常的业务波动。

通知渠道上，邮件适合留档，但响应慢；Telegram 或企业微信机器人响应快，适合当第一道。我通常两个都配，邮件只收告警级别，机器人收提醒和告警。

还有一个容易忽略的点：采集间隔。默认 60 秒对多数场景够用，但如果你的业务有明显的分钟级抖动，比如定时任务集中触发，那 60 秒可能刚好错过峰值。改成 30 秒会让数据更细，代价是 Hub 的存储和 CPU 开销上升，机器多了要留意。

什么情况下我会劝你别用它

Beszel 的定位是轻量，轻量就意味着功能边界清晰。有几种情况我不会推荐：

需要长期保留历史数据做容量规划的，它的数据保留策略偏短，不适合当数据仓库用。需要多用户分权、审计日志的团队，它没有这套体系。还有一类是已经有一套成熟监控栈的环境，再引入一个工具只会增加认知负担，不如把现有工具用透。

如果只是想给几台海外机器加一层「出事有人喊」的保险，Beszel 是个很合适的起点。先跑一周，看看告警频率是不是在你能接受的范围内，再决定要不要扩到更多机器。