Beszel 介绍与选型指南

‍‍​​‌​> 目标：说清 Beszel 这一轻量自托管服务器监控平台的定位、Hub+Agent 架构、功能边界与同类产品差异，帮助你判断它是否适合你的监控场景——全文结论均已在 Ubuntu 22.04 服务器（Beszel Hub/Agent 0.21.0）实测验证。

一、环境信息

本文所有结论来自以下真实环境实测（数据采集时间 2026-10-17）：

• 操作系统：Ubuntu 22.04.4 LTS（x86_64）
• Beszel Hub：0.21.0（Hub 页面 HUB_VERSION 与信息接口双重确认）
• Beszel Agent：0.21.0（Hub 系统详情 info.v 字段回报确认）
• 监控端口：Hub 8090、Agent 45876
• 数据目录：/opt/data/beszel（Hub 数据落盘位置）
• 软件许可：MIT（开源免费）
• 代码语言：Go（Agent 单一静态二进制，无运行时依赖）
• 社区规模：GitHub 26,280 stars / 1,094 forks（2026-10-17 实查）
• 最近版本节奏：v0.18.7（2026-04-05）→ v0.18.8（2026-08-17）→ v0.19.0（2026-09-03）→ v0.20.0（2026-09-19）→ v0.21.0（2026-10-02），平均 2~6 周一个功能版本

版本号获取与确认方法（可随时复查）：

# Hub 侧：调用信息接口，key 为 SSH 公钥、v 为版本号
# （$TOKEN 为管理员登录接口返回的认证 Token，获取方式见第五章第二步）
curl -s http://localhost:8090/api/beszel/info -H "Authorization: $TOKEN"

实测输出：

{"key":"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIPLUxo4t9n4W86eZ4QBzKgtWQhl3namsh5kaWcBHD8j","v":"0.21.0","cu":false}

# Agent 侧：查询已接入系统记录的 info 字段，v 即 Agent 版本
# （记录 ID 为添加 System 时接口返回的 id，实测 u3q4gtml3pv3us0）
curl -s "http://localhost:8090/api/collections/systems/records/u3q4gtml3pv3us0?fields=info.v,status" -H "Authorization: $TOKEN"

实测输出：

{"info":{"v":"0.21.0"},"status":"up"}

💡 说明：/api/beszel/info 是 Hub 的元信息接口，0.21.0 实测必须携带认证 Token 访问，未带 Token 直接请求会返回 401：

{"data":{},"message":"The request requires valid record authorization token.","status":401}

该接口返回值含 SSH 公钥与版本号，是部署后核对版本的第一入口。

二、软件概述

Beszel 是一个轻量级的自托管服务器监控平台，官方定位一句话：Lightweight server monitoring with historical data, docker stats, and alerts（带历史数据、Docker 统计与告警的轻量服务器监控）。它解决的核心痛点是：当你有几台到几十台服务器，想看到「每台机器现在 CPU/内存/磁盘/网络怎么样、过去一小时/一天趋势如何、某台挂了能不能马上知道」，又不想为部署监控平台本身付出过多资源与运维成本。

它的「轻量」体现在三个实测数字上：

1. 资源占用极低：在同一台 Ubuntu 22.04 机器上实测的资源快照（该机同时运行 30 个被统计对象）：

NAME          CPU %   MEM USAGE / LIMIT    NET I/O
beszel-hub    0.00%   13.19MiB / 31.3GiB   482kB / 145kB
beszel-agent  0.00%   9.449MiB / 31.3GiB   215kB / 562kB

Hub 常驻内存约 13 MiB，Agent 约 9 MiB，CPU 占用接近于零。作为对照，主流自托管监控平台常驻内存普遍在百 MiB 量级（见第七章选型对比）。

2. 部署极简：一个 Hub 进程 + 每台机器一个 Agent 进程，无外部数据库、无消息队列、无依赖服务。数据直接落在一个 SQLite 文件中。
3. 接入零成本：Agent 与 Hub 之间只开一条出站方向的 SSH 加密通道（Agent 端 45876 监听、Hub 主动发起连接，公钥互信），不需要在 Agent 机器上开入站管理面。

Beszel 由 henrygd 个人开发者发起（仓库创建于 2024-07-07），MIT 协议，两年来保持高频迭代（平均 2~6 周一个功能版本，v0.21.0 发布于 2026-10-02），是近两年自托管社区（r/selfhosted、Awesome-Selfhosted）增长最快的监控类项目之一。

三、核心架构

3.1 Hub + Agent 双组件架构

Beszel 由两个组件构成，职责清晰分离：

数据流方向：Hub 主动 SSH 连到 Agent（出站），Agent 把指标推回 Hub。这意味着被监控节点只需放行入站 45876 给 Hub 的来源 IP，不需要任何其他入站端口，也不需要在 Agent 机器上存放任何凭据——Agent 只配置 Hub 生成的 ed25519 公钥。

连接建立与认证的实测过程（真实日志）：

# Agent 启动日志
2026/10/17 08:05:13 INFO Data directory path=/var/lib/beszel-agent
2026/10/17 08:05:13 INFO Detected disk name=sda3 device=sda3 mount=/etc/hostname io=sda3 root=true
2026/10/17 08:05:13 INFO Detected network interface name=eth0 sent=42 recv=110
2026/10/17 08:05:13 INFO Starting SSH server addr=:45876 network=tcp
# Hub 添加 System 后 Agent 侧看到连接建立
2026/10/17 08:05:45 INFO SSH connected addr=172.31.0.2:57022
2026/10/17 08:05:45 INFO SSH connection established

Hub 侧在添加 System（被监控节点）后约 8 秒内完成首次握手与首条数据上报，系统状态从 pending 变为 up：

{"name":"beszel-agent-node1","host":"agent","port":"45876","status":"up",
 "info":{"cpu":3.22,"mp":27.63,"dp":20.29,"v":"0.21.0",
         "la":[1.47,0.86,0.49],"t":12,"u":30799,"ct":1}}

💡 技术拓展：Agent 接入 Hub 的通道不止 SSH 一种。Beszel 支持的连接方式对比——

连接方式	方向	认证机制	适用场景
SSH（默认）	Hub→Agent 出站	Hub 持私钥、Agent 配公钥（ed25519）	标准方案，密钥隔离最清晰
WebSocket	Agent→Hub 出站	Hub URL + Token	Agent 在 NAT 后、Hub 无法反向可达时
Unix Socket	本机进程间	文件权限	Hub 与 Agent 同机部署，免网络栈
通用 Token（0.12.0+）	混合	Hub 生成统一 Token	批量接入多节点，免逐台配公钥

本文实测采用默认 SSH 方式：公钥由 Hub 自动生成、存放于数据目录，认证失败会被 Agent 明确拒绝（实测日志见《Beszel 运维手册》故障排查章节）。

3.2 数据存储：内嵌 PocketBase + SQLite 单文件

Hub 内嵌 PocketBase（一个 Go 实现的嵌入式后端框架）作为存储与 API 层，底层数据落在 SQLite 数据库文件中。数据目录实测文件清单（/opt/data/beszel）：

-rw-r--r-- 1 root root  491520 Oct 17 08:35 data.db        # 主库：系统、指标、告警、用户
-rw------- 1 root root     387 Oct 17 08:03 id_ed25519      # Hub 的 SSH 私钥（ed25519，无口令）
drwxr-xr-x 2 root root    4096 Oct 17 08:03 .notify         # 通知相关内部数据

运行中还会有 data.db-wal、data.db-shm、auxiliary.db* 等 SQLite WAL 伴生文件；Hub 正常停止时 WAL 会合并回主库（实测停服务后 -wal 文件消失、data.db 从 4096 字节增长到 491520 字节），这也是备份策略的依据之一（详见《Beszel 运维手册》备份章节）。

历史数据按 5 级粒度自动聚合，这是 Beszel「低资源也能存历史趋势」的关键设计——从源码迁移定义中实测确认，system_stats 的 type 字段枚举为：

1m → 10m → 20m → 120m → 480m

细粒度记录按周期降采样，长期趋势用粗粒度记录表达，避免时序数据无限膨胀。实测运行约 35 分钟后主库约 480 KiB（1 台机器、1 分钟粒度），磁盘压力可忽略。

💡 技术拓展：监控指标的存储选型不止「内嵌 SQLite 单文件」一种，常见方案对比——

存储方案	代表产品	特点	代价
内嵌 SQLite 单文件	Beszel、Uptime Kuma	零依赖、备份即拷文件	不适合超大规模高频写入
时序数据库 TSDB	Prometheus（自研 TSDB）、VictoriaMetrics	高压缩比、支持 PromQL 级查询	独立进程、内存与运维成本高
RRD 环形库	Netdata、Munin	固定窗口自动过期、磁盘恒定	历史精度随时间降低、不易导出
外部文档/关系库	Zabbix（MySQL/PG）	生态成熟、可复杂关联查询	需维护数据库实例

Beszel 实际采用内嵌 SQLite：对「几台到几十台节点、分钟级粒度」的目标场景，零依赖带来的部署/备份简单性远比超大规模写入能力重要。

3.3 指标采集范围

Agent 采集并在 Hub 中可见的指标（均在实测中确认上报）：

• CPU：整体使用率、每核心使用率（实测上报 12 核）、CPU 拆解（user/system/iowait/steal/idle，实测 cpub: [1.61,1.21,0.01,0,96.79]）、负载均值 la（1/5/15 分钟）
• 内存：总量、已用、使用率、buffer/cache、Swap（实测 m:31.3, mu:8.77, mp:28.02, s:2, su:0.43）
• 磁盘：容量/使用率（实测 d:785.88, du:152.4, dp:20.3）、读写速率、IOPS、IO 利用率
• 网络：按接口的收发速率与累计流量（实测 ni: {"eth0":[191,62,14127,9102]}）
• 温度：来自宿主机 hwmon 传感器（虚拟机/云主机无传感器时无此项，实测确认；受限环境可通过 Agent 的 SYS_SENSORS 环境变量指定传感器目录，实测链路可通，见《Beszel 运维手册》）
• Docker 指标：Agent 挂载 /var/run/docker.sock 只读后，上报本机全部 Docker 统计对象的 CPU%、内存 MB、网络 IO，实测一次上报 30 个统计对象：

[{"n":"onedev-16.9.3-restore","c":0.05,"m":618.24},
 {"n":"umami-16-db","c":0.06,"m":30.78,"b":[1,3]},
 {"n":"beszel-0.21.0-agent","c":0,"m":9.42,"b":[78,18]}]

（输出节选，实测原文共 30 项、此处取首尾；n 名称 / c CPU% / m 内存 MB / b 网络 KB/s 收发。）

• 扩展项：GPU（NVML）、ZFS 池状态、SMART 磁盘健康、systemd 服务状态、电池、系统更新数——按环境自动探测，有则显示

3.4 实时推送通道

Hub 的实时图表不依赖轮询：前端通过 PocketBase realtime 通道（SSE 协议，端点 /api/realtime）订阅 system_stats、systems、alerts 等主题，数据一到即推送。实测订阅链路：连接 → 获得 PB_CONNECT → 携带认证 Token 订阅（响应 204）→ 收到事件：

PB_CONNECT clientId: Ux01Kesv9ddxSeBW7vL6uQA1QPZ3tBcdYRY1WMHM
subscribe resp code: 204
total events: 3  event_names: ['PB_CONNECT', 'system_stats', 'systems']

== system_stats event ==
record created: 2026-10-17 08:21:45.617Z  type: 1m
cpu: 3.78  mp: 28.73  dp: 20.31  b: [59, 20]  la: [1.07, 0.67, 0.53]

新指标记录产生（1 分钟粒度）即刻推送到所有在线仪表盘，实测延迟在秒级内。

四、功能特性

以下特性均在 0.21.0 实测或经官方源码核对（标注实测的条目附验证方式）：

1. 多节点总览 + 单节点详情：首页表格列出全部系统的状态/CPU/内存/磁盘/网络/负载，点击进入单节点图表页（实时 + 历史多粒度）。
2. 历史图表与数据聚合：1m/10m/20m/120m/480m 五级聚合（实测枚举见 3.2），小时/天级趋势查看不丢精度。
3. Docker 统计：每节点 Docker 统计对象的 CPU/内存/网络排行（实测 JSON 见 3.3），支持按名称过滤。
4. 告警引擎：对 CPU、内存、磁盘、带宽、温度、GPU、负载（1/5/15 分钟）、电池、ContainerHealth（Docker 对象健康）、systemd 失败服务、CPU IO 等待/窃取、网络丢包（枚举值实测自源码迁移定义）设置阈值告警；支持「持续 N 分钟才触发」的防抖。实测创建 CPU > 1% 规则后 13 秒触发、并写入告警历史：

{"id":"codc4wkykg9ekvg","name":"CPU","value":1,"min":0,"triggered":true}
{"alert_id":"codc4wkykg9ekvg","name":"CPU","value":1,"created":"2026-10-17 08:14:45.637Z"}

5. 通知渠道：内置 Webhook 与邮件；Webhook 兼容 shoutrrr 生态（Telegram、Discord、Slack、Gotify、ntfy、Lark/飞书等三十余种目标，源码 supportsTitle 表核对）。
6. 多用户与权限：每个用户只看到被授权的系统（alerts/systems 集合均有 user 关系字段，实测）；支持 OIDC 单点登录（官方文档）。
7. 温度与传感器：读取 hwmon；支持 SENSORS 白/黑名单、PRIMARY_SENSOR 指定主传感器、SYS_SENSORS 指定传感器目录（环境变量名实测自源码）。
8. 连通性即监控：Agent 掉线即系统 down——实测停止 Agent 后 30 秒内状态翻转，配合 Status 告警即「宕机告警」。
9. 零依赖部署：Hub/Agent 均为单一静态二进制（Go 编写），官方提供 Compose 编排与二进制安装两种形态。
10. 自动升级检查：页面提示新版本，支持检查版本更新（updatable 字段，源码核对）。

五、快速开始（最小可用示例）

本章给出「从零到看见指标」的最小闭环，采用官方推荐的 Compose 形态部署（完整参数与逐项说明见《Beszel Docker Compose 部署指南》，此处只保留最小可执行主线；下述所有 API 命令均已实测，可独立执行）。

第一步：部署 Hub 与 Agent（Compose 双服务，网络互通，Agent 注入 Hub 公钥）——操作步骤与完整 compose.yml 见《Beszel Docker Compose 部署指南》第四章。

第二步：初始化管理员。首次访问 Hub 会要求创建账号；用 API 等价操作：

curl -s -X POST http://localhost:8090/api/beszel/create-user \
  -H 'Content-Type: application/json' \
  -d '{"email":"admin@quzuo.net","password":"q1w2e3r4","name":"admin"}'

实测输出：

{"msg":"User created"}

验证登录并获取 Token：

curl -s -X POST http://localhost:8090/api/collections/users/auth-with-password \
  -H 'Content-Type: application/json' \
  -d '{"identity":"admin@quzuo.net","password":"q1w2e3r4"}'

实测输出（节选首尾）：

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ...","record":{"id":"egb5322xmdbhc47","email":"admin@quzuo.net","role":"admin","verified":true}}

把返回 JSON 中的 token 字段取到变量，供后续接口命令统一使用（Token 为运行期凭据，实测长度 224 字符，不落明文）：

TOKEN=$(curl -s -X POST http://localhost:8090/api/collections/users/auth-with-password \
  -H 'Content-Type: application/json' \
  -d '{"identity":"admin@quzuo.net","password":"q1w2e3r4"}' \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['token'])")

第三步：添加被监控节点（System）。在页面点 Add System（Host 填 Agent 地址，Port 45876）；API 等价操作：

curl -s -X POST http://localhost:8090/api/collections/systems/records \
  -H "Authorization: $TOKEN" -H 'Content-Type: application/json' \
  -d '{"name":"beszel-agent-node1","host":"agent","port":"45876","users":["egb5322xmdbhc47"]}'

实测输出（节选）：

{"id":"u3q4gtml3pv3us0","name":"beszel-agent-node1","host":"agent","port":"45876","status":"pending"}

第四步：验证指标上报。等待一个采集周期后查询系统状态与指标记录：

curl -s "http://localhost:8090/api/collections/systems/records/u3q4gtml3pv3us0?fields=status,info.cpu,info.mp,info.dp" \
  -H "Authorization: $TOKEN"

实测输出：

{"status":"up","info":{"cpu":3.22,"mp":27.63,"dp":20.29}}

curl -s "http://localhost:8090/api/collections/system_stats/records?perPage=1&sort=-created" \
  -H "Authorization: $TOKEN"

实测输出（节选）：

{"items":[{"created":"2026-10-17 08:07:45.616Z","type":"1m",
 "stats":{"cpu":3.2,"mu":8.77,"mp":28.02,"du":152.4,"dp":20.3,
          "b":[191,62],"la":[1.02,0.85,0.51]}}]}

至此最小可用闭环完成：打开 http://<服务器IP>:8090 即可看到实时与历史图表。

六、适用场景与限制

6.1 适用场景（实测支撑）

1. 个人/小团队多台 VPS 与家庭服务器：Agent 内存实测约 7 MiB，树莓派级设备也可常驻；总览页一屏看清全部节点。
2. 需要「宕机 + 资源阈值」告警但不想建 Prometheus 栈：告警引擎内置、通知一条 Webhook 配置即可（实测 13 秒触发）。
3. 轻量 Docker 主机监控：挂载 socket 即得全部 Docker 统计（实测 30 对象无压力），比部署 cAdvisor + Prometheus 简单一个数量级。
4. 内网/隔离环境：只需 Hub→Agent 的出站 SSH 通道，无需公网可达的回调地址。

6.2 限制与边界

1. 规模上限：分钟级粒度 + 单机 SQLite，适合几台到几十台节点；数百节点高频指标建议转向 Prometheus/VictoriaMetrics 栈（官方未给硬性上限，此为架构层判断）。
2. 无自定义采集插件：指标范围固定在 3.3 节清单，不能像 Netdata 一样采集任意应用指标（MySQL QPS、Nginx 连接数等需另接 exporter）。
3. 告警不持久化历史趋势：alerts_history 只记触发/恢复事件（实测记录结构），不做事件级数据留存分析。
4. 备份为文件级手工操作：无内置定时备份，需自行 cron（实测恢复流程见《Beszel 运维手册》）。
5. 无内置长租期保留策略配置：聚合层级固定为 5 级，不支持自定义「保留 90 天原始数据」类策略。

七、同类选型对比

7.1 横向对比表

选取三个最常被一起比较的自托管方案：Netdata（单机全景监控）、Glances（单机终端/Web 监控）、哪吒监控 Nezha（多服务器探针面板）。

说明：Beszel 数值为本文环境实测；Netdata/Glances/哪吒的内存与 CPU 口径取自各自官方文档与仓库 README 的常见声明量级，不同环境实测会有差异，仅供部署前预估。

关键差异与选型建议：

• 只想「几台机器一个面板看趋势 + 挂了报警」，且极度在意自身开销 → Beszel（三项实测优势：12 MiB 级常驻、分钟级部署完成、SSH 通道零入站面）。
• 需要单机毫秒级深度诊断（每秒粒度、进程级、应用内省）→ Netdata，代价是资源占用高一个数量级。
• 只在某一台机器上临时看指标、无面板诉求 → Glances。
• 面向对外展示的「服务器列表 + 掉线告警」探针页（如给客户/社区看）→ 哪吒监控。

7.2 与 Prometheus 生态的关系

Beszel 不替代 Prometheus：它没有指标查询语言、不支持 exporter 生态、不做长期大规模存储。合理的分工是——Beszel 管「主机层总览 + 轻量告警」，Prometheus 栈管「应用指标与复杂查询」。两者可在同一批机器共存（Beszel Agent 7 MiB 的开销可忽略）。

八、参考链接

• 官方网站与文档：https://www.beszel.dev
• GitHub 仓库：https://github.com/henrygd/beszel
• 官方入门指南：https://www.beszel.dev/guide/getting-started
• Agent 配置（环境变量）：https://www.beszel.dev/guide/agent
• 告警与通知配置：https://www.beszel.dev/guide/alerts
• 发布版本列表：https://github.com/henrygd/beszel/releases
• 社区数据实查日期：2026-10-17（stars/forks/release 时间均取自 GitHub API）
• 相关文档：《Uptime Kuma 介绍与选型指南》《Grafana Docker Compose 部署指南》《Netdata Docker Compose 部署指南》