用Beszel把服务器监控做轻：部署、告警与指标取舍的实战笔记

为什么又捡起了Beszel这种轻量监控

手上机器一多，最怕的不是故障本身，而是故障发生时你根本不知道。商业监控方案功能全，但agent吃内存、面板吃CPU，几台小配置机器跑起来本末倒置。Beszel的定位很讨巧：单个二进制、内置SQLite存储、agent常驻内存占用通常在几十MB级别，面板本身也能跑在低配机器上。

它的逻辑不复杂：每台被监控机器跑一个agent，定时把CPU、内存、磁盘、网络、负载等数据推给hub，hub负责存储和展示。对十几台到几十台机器的场景，这套结构足够用。

部署路径：先跑通再谈美化

推荐先把hub部署在一台长期在线的机器上，比如你手里那台香港自营物理服务器(100M)⑤，18核36线程的配置跑监控面板绰绰有余，还能顺带跑点别的轻量服务。agent端用Docker或二进制都行，二进制方式对系统侵入更小。

• hub用Docker Compose起，挂载一个持久化目录，数据别放容器里
• agent用systemd托管，开机自启，日志走journald方便排查
• 首次接入先在面板里确认数据上报正常，再批量铺开

批量接入时建议写个简单脚本，把agent安装、注册token、服务启动串起来，否则手动敲十几台会疯。

指标取舍：不是越多越好

Beszel默认采集的指标已经覆盖大部分运维场景，但真正有用的是那几个：CPU使用率、内存可用量、磁盘剩余空间、网络出入带宽、系统负载。磁盘和内存的告警阈值要按业务调，比如数据库机器内存告警线别设90%，留足缓冲。

网络指标对做站群或大带宽业务的机器尤其关键。如果你的机器跑的是多站点或流量型业务，带宽曲线异常往往比CPU飙高更早暴露问题。像香港大带宽服务器 XXI这类50M起步的机器，监控里重点看的是出带宽是否长期贴着上限跑，贴太久就该考虑扩容或查异常进程了。

告警怎么配才不烦人

告警最怕两件事：该响的时候不响，不该响的时候一直响。建议分两级：警告级只记录不推送，严重级才走邮件或webhook。阈值设置上，CPU和负载可以设持续时间条件，比如连续5分钟超过阈值才告警，避免毛刺误报。

磁盘告警用绝对值比百分比更直观，比如剩余空间低于10GB就提醒，比"使用率超过85%"更贴近实际。最后记得定期清理历史数据，SQLite文件涨起来也不小，保留30到90天足够回溯问题。