Beszel 是一个自托管的服务器监控项目，采用 hub 加 agent 的结构：hub 提供 Web 面板，agent 装在每台被监控的机器上采集指标。它把 CPU、内存、磁盘、网络与 Docker 容器数据收进一个界面，并按阈值发出告警。项目以 MIT 许可开源，适合管理几台到二十几台服务器的个人或小团队。
Beszel 是什么：hub 与 agent 分工
hub 是一个基于 PocketBase 的 Web 应用，负责账号、系统列表、图表和告警配置。agent 是独立的采集进程，读取主机指标与 Docker、Podman 容器数据，再推送给 hub。官方文档把分工写得很直白：hub 管看板，agent 干活。
两者之间用密钥认证，agent 不必暴露到公网，本地机器还可以走 Unix socket，省掉一个监听端口。官方GitHub 仓库在 2026-10-29 抓取时显示 26.6k stars、1.1k forks，许可为 MIT。
版本节奏偏快。GitHub Releases 页面列出的当前版本是 v0.21.1，发布于 2026-10-22，Linux amd64 的 agent 安装包约 4.28MB。
hub 还带多用户、OAuth 与 OIDC 登录、REST API 和自动备份，备份可写本地磁盘或 S3 兼容存储。小团队可以让每人管自己的机器，管理员再按需共享系统，账号体系不用另搭。
Docker 部署：hub 与 agent 两份 compose
官方快速开始提供单二进制与 Docker、Podman 两条路径。下面按 Docker 方式整理，hub 和被监控机器各一份 compose 文件。
- 在放面板的机器上建目录，写 hub 的 compose：镜像 henrygd/beszel，把 ./beszel_data 挂到 /beszel_data，映射 8090 端口。
- 把 APP_URL 改成实际访问地址，执行 docker compose up -d，浏览器打开 8090 创建管理员账号。
- 在被监控机器上按 Add System 对话框给出的配置启动 agent，填入 KEY；要容器指标就只读挂载 /var/run/docker.sock。
- 回到面板填主机地址，状态转绿后曲线开始入库。
0.12.0 起，hub 多了通用令牌：在 /settings/tokens 生成后，agent 可以先启动再配对，不用提前把公钥写进环境变量。批量铺 agent 时这一步省事不少。同类自托管项目的目录与卷组织，可以参照站内Karakeep 的 Docker 部署记录。
| 变量 | 位置 | 作用 |
|---|---|---|
| APP_URL | hub | 面板对外访问地址，套反向代理后要改成实际域名 |
| KEY | agent | hub 生成的公钥，用于配对 |
| TOKEN | agent | 通用令牌，0.12.0 起可替代预先配置 |
| HUB_URL | agent | agent 回连 hub 的地址，要带协议头 |
| LISTEN | agent | 监听端口或 Unix socket 路径 |
hub 与 agent 在同一台机器时，官方示例用 /beszel_socket/beszel.sock 作为 Host/IP，容器数据也能取到。跨机部署的示例里 agent 使用 45876 端口，防火墙只需放行 hub 到 agent 的这个端口，不必反向开放。
套反向代理时要记得转发 WebSocket。面板能打开、数据却一直转圈，多半是 Nginx 少了 Upgrade 与 Connection 两个头，实时指标走的就是这条长连接。
监控指标与告警怎么配
官方指标清单覆盖主机与容器两层，范围比“轻量”这个词给人的印象宽一些。
| 类别 | 内容 |
|---|---|
| CPU 与内存 | 主机与容器；内存含 swap 与 ZFS ARC |
| 磁盘 | 使用率与 I/O，支持多分区、多设备 |
| 网络 | 主机与容器流量；agent 侧还能做 ICMP、TCP、HTTP、DNS 探测 |
| 硬件 | 温度、风扇转速、GPU 占用与功耗、电池电量 |
| 存储健康 | S.M.A.R.T.（含 eMMC 磨损）、ZFS 池状态 |
| 容器 | Docker、Podman 容器状态与单容器资源 |
告警在系统列表里逐台开启，阈值可按 CPU、内存、磁盘、带宽、温度、负载和在线状态设置。通知走 Shoutrrr URL，在 Settings 的 Notifications 页填一条地址即可。官方通知文档的表格列出 24 种渠道，Telegram、Slack、Discord、Gotify、ntfy、Bark、企业微信、飞书都在其中。
告警逻辑是阈值触发，不是基线学习。好处是行为可预期，坏处是阈值要自己调。起步可以把磁盘 80%、内存 90% 当起点，跑一周再看误报多不多。
和 Netdata、Uptime Kuma 的差异
三者常被放进同一张推荐清单，但回答的问题不同。Beszel 看“我这几台机器现在怎么样”，Netdata 看“这一秒这台机器发生了什么”，Uptime Kuma 看“用户能不能打开我的网站”。
| 维度 | Beszel | Netdata | Uptime Kuma |
|---|---|---|---|
| 定位 | 多机资源看板 | 单机实时排障 | 外部可用性拨测 |
| 采集方式 | hub 加 agent | 每台一个 agent | 无 agent，从外部探测 |
| 时间粒度 | 以趋势观察为主，第三方对比称其无秒级采样 | 默认每秒 | 默认 20 秒 |
| 容器数据 | 单容器 CPU、内存、网络 | 容器与应用自动发现 | 容器存活状态 |
| 告警通知 | 阈值告警，24 种渠道 | 内置规则，多渠道 | 90 多个通知服务 |
| 许可 | MIT | Agent GPLv3+，UI 与 Cloud 闭源 | MIT |
Netdata 的强项是分辨率与自动发现。官方仓库说明写明默认按秒采集、内置 800 多个集成，还带异常检测。代价是每台机器一套面板与告警，多机统一视图通常要接 Netdata Cloud 或自建父子节点。
Uptime Kuma 从外部敲门，支持 HTTP、TCP、Ping、DNS、关键词与 JSON 查询，默认 20 秒一次，带公开状态页和 90 多个通知服务。它不采集主机资源，所以与 Beszel 是互补关系，而非替代关系。
Beszel 处在中间：有容器级资源和历史曲线，也有 agent 侧的网络探测，但功能清单里没有秒级采样，也没有公开状态页。按一篇第三方对比的说法，它是仪表盘，不是显微镜。
实际选型时不必三选一。两三台 VPS 可以 Beszel 加 Uptime Kuma：前者盯资源和容器，后者盯域名、证书与对外可用性。关键数据库节点再单独放一个 Netdata，出事时进去翻秒级现场。
局限与适用场景
先说清楚它不做什么，选型时更省事。
- 指标以主机和容器为主，数据库、Nginx 这类应用内部指标不在清单里，需要另配 exporter 或 APM。
- hub 基于 PocketBase，数据落在内置数据库，没有独立时序库，也没有 PromQL 式的跨数据源查询。
- 功能清单里没有公开状态页，面向客户的可用性页面要另找工具。
- agent 要读 Docker socket 才能看容器，等于把容器信息读取权限交给它，多租户环境需评估。
- hub 自己宕机时没人告警，建议在另一台机器放第二个实例，或加一条外部心跳。
适合个人 VPS、家里的小集群、几台到二十几台的开发或预发环境：想要一块统一看板加阈值通知，不想维护 Prometheus 那一套。需要秒级根因分析、应用指标或大规模多租户场景时，Netdata 与 Prometheus 更合适。习惯用面板管站的读者，站内宝塔面板建站指南里反向代理与端口放行的部分同样适用。
上手建议是先在单机跑 hub 加本地 agent，确认 Unix socket 能通，再铺第二台。告警先配磁盘和离线两类，等曲线跑出基线，再补 CPU 与内存阈值。
需要把 agent 端口暴露到公网吗
不需要。连接方向是 hub 主动连 agent，公网侧只暴露 hub 的 8090。跨机时把 45876 限制为只允许 hub 的 IP 访问即可。
数据存在哪里，怎么备份
数据在 hub 挂载的 beszel_data 目录里，底层是 PocketBase 的数据库文件。打包这个目录就能迁移；也可以在面板里配置定时备份到本地磁盘或 S3 兼容存储。
安装脚本支持哪些系统
安装脚本只覆盖 Linux，Windows、macOS 等系统要手动下载对应二进制，再注册成服务运行。官方文档的 Agent Installation 页列出了各平台的做法。
© 版权声明
文章版权归作者所有，转载需注明出处。未声明原创的皆为网络收集，如有侵权请邮箱lishiwenhuagx@sina.com联系下架处理。
相关文章
