Beszel 部署与选型：一台轻监控怎么省下整台服务器的开销

为什么我先把监控压在 10MB 这个量级上

手上机器一多，最先崩的不是业务，是监控本身。Prometheus 加 Grafana 那套东西功能确实全，但一台采集端跑起来几百 MB 内存是常态，再配个时序库，小机器直接被吃掉一半资源。

Beszel 走的是另一条路。它由 hub 和 agent 两部分组成，agent 是单个二进制文件，跑在每台被监控的机器上，常驻内存通常在 10MB 上下，CPU 占用基本可以忽略。

我第一次看这个数字的时候是有点怀疑的，后来想明白了：它不做复杂的指标聚合，采集的是 CPU、内存、磁盘、网络、温度这类基础项，历史数据默认存在 hub 端的 SQLite 里，整套架构就简单到没什么可吃资源的地方。

对只有几台到几十台机器的场景，这个取舍很划算。代价是它给不了 Prometheus 那种任意维度查询和复杂告警规则，指标保留时长也受本地磁盘限制，默认只留很短一段。

hub 放哪、agent 怎么铺，这一步决定后面省不省心

hub 是整个系统的中心，负责接收数据、存历史、发告警。它需要长期在线，所以我不建议和业务挤在同一台机器上——业务一重启，监控跟着断，数据就出现空洞。

我一般会把 hub 单独放在一台低配机器上，1 核 1G 都够用，磁盘给到 20G 以上，因为历史数据虽然不大，但攒久了也会占地方。如果机器本身在海外机房，hub 最好和被监控机器在同一个区域，跨区域拉数据延迟高、还容易被网络抖动影响。

agent 的部署就简单多了，官方提供一键脚本，装完注册到 hub 上就行。几点经验：

• agent 只需要能主动连到 hub 的端口，不需要 hub 反向连进来，防火墙策略会好写很多
• 如果被监控机器在 NAT 后面，走主动上报模式，不用额外做端口映射
• 每台机器的 agent 名称建议和业务对应，比如按机房加用途命名，后面告警一眼能看出是哪台

这里有个容易被忽略的点：agent 本身几乎不占资源，但 hub 的告警推送如果走邮件，频繁触发会拖慢查询。我会把阈值设得宽一点，只在真的异常时发通知。

告警阈值怎么定，别让通知变成噪音

监控最大的失败不是没装，是装了之后没人看。原因多半是告警太吵。

CPU 我一般不看瞬时值，看持续 5 分钟以上的高负载。磁盘按剩余百分比告警，比按绝对容量更合理，因为不同机器盘大小差很多。内存要看是否包含缓存，否则 Linux 上内存看起来永远快满了。网络流量告警主要防被打，如果一台机器平时跑 20M，突然冲到 100M 以上，多半有问题。

按我的经验，一套阈值定下来之后要放两周，统计一下误报次数，再把触发条件往上调。宁可漏报一次小的，也别让运维对通知麻木。

这里说个取舍：Beszel 的告警规则不复杂，做不了多条件组合。如果你的业务需要「CPU 高且磁盘 IO 同时异常才告警」这种逻辑，它做不到，得换别的方案。对多数中小业务来说，单条件够用。

什么情况下它顶不住，什么时候该换

机器数量是第一个分水岭。几十台以内，hub 用 SQLite 完全撑得住。上百台之后，写入频率上来，SQLite 的并发写会成为瓶颈，查询也会变慢。

第二个是保留时长。想留半年以上的历史做容量规划，本地磁盘存不下，得接外部存储，这时候 Beszel 的简单架构反而变成限制。

第三个是自定义指标。业务层面的埋点、QPS、队列长度这些，它采集不了。

所以我的判断是：单机或小集群、只关心基础资源、想快速上线，选 Beszel；需要业务指标、长期趋势、多条件告警，老老实实上 Prometheus。

另外，监控 hub 本身也得有地方放。如果只是给几台业务机做监控，找一台便宜的独立服务器或者低配机器专门跑 hub 就够了。像 东京独立服务器 这种 E5-2660V2 / 32G 的配置，跑 hub 加几个小服务绰绰有余，月付 $151.00，比让监控和业务抢资源要稳。机器在东京机房，监控亚洲区域的业务延迟也低。

最后给个能直接执行的结论：机器在 5 台以下，Beszel 装在一台独立小机上，阈值放宽，两周调一次；超过 50 台或者要看业务指标，别再折腾了，直接上完整监控栈。省下的那点内存，不值得后面反复补课。