Beszel 部署与实战：轻量服务器监控到底能省下多少排查时间

2026-09-28 07:34 1002 次浏览

手里管着三五台机器的人，多半经历过这种场面：网站突然变慢，登上去敲 top 看一眼，CPU 正常，内存也正常，然后开始一台一台翻日志。等到问题定位出来，半小时已经没了。监控这件事不是大厂才需要，机器少反而更容易被忽略，因为「感觉还行」的错觉能撑很久。

Beszel 解决的正是这个阶段的问题。它把监控压到一个很轻的体积里，一台 1 核 1G 的小机器就能当服务端，被监控的机器上只跑一个 Agent。我关心的不是它功能有多少，而是它能不能让我在出问题的前几分钟就收到信号，而不是事后翻日志。

为什么小规模场景用不上 Prometheus

Prometheus 加 Grafana 是一套成熟的方案，问题在于它的重量和你的机器数量不匹配。Prometheus 自身抓取、存储、查询就要吃掉几百 MB 到 1GB 内存，Grafana 再叠一层，加上各种 exporter，一套下来对一台 2G 内存的机器是实打实的负担。

更麻烦的是维护成本。配置文件、告警规则、数据保留策略，每一样都要人盯着。机器只有几台的时候，你花在维护监控系统上的时间，可能比它帮你省下的排查时间还多。

Beszel 走的是另一条路。服务端用 Go 写，内置一个基于 SQLite 的时序存储，不需要额外数据库。Agent 是单个二进制文件，复制过去执行就行。整套东西的内存占用通常在几十 MB 级别，磁盘增长也慢，因为默认只保留近期数据。

省下的这笔钱不只是内存。少一个组件就少一处会挂的地方，对没有专职运维的团队来说，这是最实际的价值。

接入流程分两步：先在服务端生成一个密钥，再到目标机器上跑 Agent 并带上这个密钥和 Hub 地址。Agent 会主动向服务端上报，所以被监控的机器不需要开放任何入站端口，这一点对内网机器特别友好。

服务端放哪里，我一般按两个条件判断：

如果被监控的机器主要在香港，服务端也放在香港最省事，延迟低、链路短。像香港裸机云 III 这种 E5-2680 / 32G / 20M 的配置，跑一个监控服务端属于严重过剩，但好处是它同时还能承担别的轻量任务，不会为了监控单独开一台机器。

Agent 那边几乎不用配置。默认采集 CPU、内存、磁盘、网络这些基础指标，如果要看容器状态，把 Docker 的 socket 挂进去就行。

Beszel 的界面按机器列出实时曲线，历史数据可以按时间段回看。告警支持阈值触发，比如 CPU 持续超过 90%、磁盘用满 85%、机器失联超过几分钟，可以推到邮件或 webhook。

下面这些它能做：

它做不了的事情也要说清楚。它不做日志聚合，不做链路追踪，不做复杂的多维查询，也没有 PromQL 那种表达能力。如果你需要按业务维度做聚合分析，或者要看单次请求的耗时分布，那还是得上更重的一套。

我的判断是这样的：机器在 10 台以内、没有专职 SRE、核心诉求是「别等用户投诉才知道挂了」，Beszel 完全够用。超过这个规模，或者业务本身对可观测性有硬要求，就该考虑分层，Beszel 管基础资源，业务指标交给别的工具。

有一点要提醒：告警阈值别照抄别人的。磁盘 85% 对日志型业务可能已经很危险，对纯静态站还能撑很久。先跑一周看正常水位，再定阈值。

服务端和被监控机器在同一台物理机上，是最省成本的做法，代价是机器本身挂掉时你收不到告警。这种单点问题在小规模里很难完全避免，除非你愿意为监控单独付一份机器的钱。

折中办法是让告警走外部通道。服务端挂了，外部的心跳检测会发现它失联，至少能告诉你「监控系统本身出问题了」。

如果被监控的机器数量在增长，服务端要预留一点余量。几百台机器的上报数据量对 SQLite 来说仍在可控范围，但内存和磁盘要相应上调。用香港自营国际物理服务器这类 64G 内存的配置来承载监控服务端，能撑很久不用换，1G 带宽也方便对外提供访问。

结论可以给得很直接：机器少于 10 台、预算有限、希望今天就能看到曲线的人，直接上 Beszel，服务端用一台 32G 内存的机器就够，月成本控制在几百元级别。需要日志检索、调用链、复杂告警编排的团队别选它，那套需求它接不住，硬上只会浪费时间。