返回博客列表

Beszel 轻量监控：N1 作 Hub 的家庭设备资源监控

2026年8月1日| Ruichen Zhou| 约 10 分钟阅读
Beszel监控OpenWrtArmbian自托管

之前的监控有两层：Kuma 看服务存活（HTTP/ping/port 通不通），xray observatory 看业务链路（SOCKS 延迟）。设备本身的 CPU、内存、磁盘、温度这些系统指标一直是空白，某台机器内存吃紧或磁盘写满时 Kuma 不会报，只能等它崩了再 SSH 上去查。这篇记录补上 Beszel 这一层的过程，范围限定在系统资源监控。

更新说明（2026-08-30）：本文写作时在线 Agent 为 5 台，之后陆续增加。目前 Hub 数据库共 9 条系统记录，8 台 up、1 台 down（已下线的 N1-SD），记录版本均为 Beszel 0.18.7。当前节点覆盖两台路由器、N1、Mac mini、手机服务器、Precision-7920 和两台 VPS。文中的部署步骤和资源占用数字以写作时为准。

1. 为什么选 Beszel

对一套个人基础设施（机器散在德国家里和中国老家），上 Prometheus + Grafana + node_exporter 全家桶成本偏高：要装 exporter、配 scrape、维护时序数据库、画 dashboard，每一项都是长期维护负担，而实际需求只是看几台机器的资源曲线，加上超阈值告警。

Beszel 的取舍和这个场景匹配：

  • 单个二进制（Hub + Agent），Go 编写，资源占用低
  • 内置 SQLite（PocketBase），不用单独跑数据库
  • Web UI 自带图表，不用画 dashboard
  • 支持 Agent 主动连接的 WebSocket 模式，NAT 后的设备主动连 Hub 的 8090 端口，Hub 侧只需保证 8090 可达

连接方式上，Beszel 官方文档（Security）说明有两种：标准模式由 Hub 通过 SSH 连 Agent 的 45876 端口读取数据；WebSocket 模式由 Agent 主动连 Hub 的 /api/beszel/agent-connect，走 Hub 的 8090 端口。按设备的网络位置选一种即可。

代价是不如 Grafana 灵活，没有自定义查询、长期历史聚合和 per-process 视图。但出问题时看一眼资源曲线、设个告警，这些够用；per-process 这类需求直接 SSH 上去 top 更快。

三层监控的分工如下：

层 工具 看什么
服务存活 Kuma HTTP/ping/port 通不通，主动探测
系统资源 Beszel CPU/内存/磁盘/负载/网络/Docker/温度
业务链路 xray observatory SOCKS 延迟、timeout 计数

2. Hub 部署在 N1

Hub 选在斐讯 N1（Armbian 6.12.95，aarch64）。N1 是家里常驻的服务节点（跑 microsocks 和 Tailscale），2GB 内存，千兆网线接主路由 LAN，7x24 在线，网络位置也在我能完全掌控的范围内。

N1 刷的是 ophub amlogic-s9xxx 的 Armbian，写入 eMMC，标准 systemd，Hub 按官方 systemd 方式部署：

# 官方安装脚本，会生成 /etc/systemd/system/beszel.service
curl -sL https://get.beszel.dev -o /tmp/beszel.sh && \
  chmod +x /tmp/beszel.sh && /tmp/beszel.sh

Hub 监听所有接口的 8090，不暴露公网，Tailnet 和局域网内都能访问面板。Tailnet 内用 http://100.x.x.x:8090（N1 的 Tailscale IP），局域网内用 N1 的 LAN 地址。写作时测得 Hub 常驻内存约 32MB，对 2GB 的 N1 没有压力。

3. 注册凭据与 universal token

默认流程是在 Hub 面板上为每台 Agent 创建一个 token，Agent 安装时填入对应 token 和 Hub 的公钥完成注册。机器多了以后，逐台在面板上点、逐个复制 token 很繁琐。

Beszel 支持 universal token：在 Hub 面板的 Settings > Tokens 中创建一个全局 token（官方文档见 Agent Installation），所有 Agent 共用，新 Agent 首次连接时自动在 Hub 注册。批量部署时把它写进安装命令，每台机器变成 SSH 上去跑一行命令，不用回面板拿 token。token 值本身不在文章里展示。

4. systemd Agent：N1 与两台 VPS

N1、VPS-DE、VPS-HK 都是标准 systemd 系统，用官方 Agent 安装脚本，一行命令：

curl -sL https://get.beszel.dev -o /tmp/beszel-agent.sh && \
  chmod +x /tmp/beszel-agent.sh && /tmp/beszel-agent.sh

脚本会注册 beszel-agent systemd service，安装时填入 Hub 地址、token 和公钥，之后 systemctl enable --now beszel-agent。N1 的 Agent 和 Hub 同机，直接读本机数据；两台 VPS 跨 Tailscale 与 Hub 通信，装之前确认 Tailnet 连通。

5. OpenWrt Agent：procd 手写 init 脚本

Cudy 和 AX6 是 OpenWrt，没有 systemd，服务由 procd 管理。官方没有 OpenWrt 的现成 init 脚本，需要手写 /etc/init.d/beszel-agent。完整脚本随各自固件环境调整，这里只记一个 procd 的行为差异：

# 错误写法：多次调用 procd_set_param env
procd_set_param env TOKEN="$TOKEN"    # 只有这一次生效
procd_set_param env PORT="$PORT"      # 这次会覆盖上面的

# 正确写法：所有 env 写在一次调用里
procd_set_param env TOKEN="$TOKEN" PORT="$PORT"

procd_set_param env 只能调一次，再调会覆盖掉之前的值。多个环境变量要写在同一行。这个行为不查文档很难发现，表现是 Agent 进程起来了但连不上 Hub，因为 token 没传进去。

AX6（Redmi，AE86Wrt / OpenWrt 24.10.1）不在 Tailscale 里，IPQ807x 内存吃紧没装，Agent 通过 LAN IP 与 Hub 通信。写作时测得 AX6 上 Agent 内存约 12MB，AX6 总内存 405MB、剩余约 85MB，偏紧但能接受。

6. 连接检查

部署后在 Hub 面板确认各系统是否上线、版本是否一致。2026-08-30 的核对结果见文首更新说明，此处不重复。连接模式上，手机服务器已核对为 WebSocket 模式。

7. 资源占用

写作时（在线 Agent 为 5 台）做过一次测量：

  • Hub（N1）：约 32MB
  • Agent（每台）：约 12MB

合计约 92MB。这是一次性测量的结果，节点增加后总数会变，只作为量级参考。当时内存最紧的 AX6 上没有触发 OOM。这个量级是 Beszel 相对 Grafana 全家桶最实际的好处：轻到可以塞进任何常驻设备。

8. 告警

Beszel 支持按指标设阈值告警（CPU 或磁盘持续超阈值若干分钟等），通知走 webhook。我把 webhook 发给签名转换服务（signer），由它加上 HMAC 签名后转发到 Hermes 的告警路由做自动初步诊断，细节见 Hermes webhook 集成。

Kuma 的服务存活告警和 Beszel 的资源告警各自独立直发，Hermes 只是附加的分析层，Hermes 挂了不影响基础告警，三套监控彼此解耦。

小结

最终这套三层监控覆盖了服务通不通、资源够不够、业务链路稳不稳三个维度，每层各一个轻量工具。Beszel 补上了系统资源这个空白，开销低到可以忽略。出问题时可以按层定位：服务不通看 Kuma，资源异常看 Beszel，链路质量看 xray observatory。

评论