用 Beszel 监控 VPS 的资源占用

VPS 偶尔变慢，等你登录时又正常了，一张截图很难找出原因。Beszel 可以保留资源变化曲线，便于回看慢下来的时段。不过，主机指标不能说明网站业务是否正常，还要另外安排网站检查。

Hub 保存数据，每台机器运行 Agent

服务器已有 Docker Compose，且宿主机 8090 空闲时，在独立目录保存以下 Hub 配置。Hub 与 Agent 使用同一版本 0.21.0。已有实例升级前，先保存旧数据，并核对两者的发行说明：

services:
  hub:
    image: henrygd/beszel:0.21.0
    restart: unless-stopped
    ports:
      - "127.0.0.1:8090:8090"
    environment:
      APP_URL: https://beszel.example.com
    volumes:
      - ./beszel_data:/beszel_data

将域名换成实际地址，启动 Hub 后先通过 SSH 转发等受控方式创建管理员，再配置 HTTPS 入口。beszel_data 保存配置与历史数据，不能随容器重建一起删除。

Agent 配置每台单独生成

在 Hub 为需要观察的服务器新增系统，使用它生成的公钥、Token 和安装配置。每台机器保存自己的身份数据，不复制第一台已经运行过的整个 Agent 目录。把生成的配置保存为该机器独立目录里的 compose.yaml，确认 Agent 镜像固定为 henrygd/beszel-agent:0.21.0。公钥 KEY、系统专用 TOKEN 和 HUB_URL 分别核对，不在文章、截图或公开仓库中粘贴 Token。

生成的配置应把自己的 ./beszel_agent_data 挂载到 /var/lib/beszel-agent。这里保存 Agent 的持久身份；迁移原机器时连同该目录一起恢复，为另一台机器新建采集端时则重新生成身份。

连接方式有不同入口要求。采用 Agent 主动连接 Hub 的 WebSocket 模式时，核对 HUB_URL、代理协议升级与出站连接；0.21.0 的 Agent 可以设置 DISABLE_SSH: "true"，关闭 Beszel Agent 自己的 SSH 监听。这不涉及宿主机用于运维的 SSH 服务，也不需要为纯 WebSocket 连接开放 Agent 的 45876 入站端口。公网连接仍使用 HTTPS。

Docker socket 用来读取容器统计，挂载 :ro 不会把 Docker API 权限自动变成只读。不需要容器监控时不挂载，不把该 socket 交给未核对来源的程序。

检查曲线是否积累，告警是否能收到

Agent 上线后，观察 CPU、内存、磁盘与网络曲线开始积累；额外数据盘按文档另安排采集。VPS 通常不提供宿主机物理传感器，缺少温度不一定是安装问题。

配置通知渠道后先发送测试消息，再给对应机器启用告警。正常备份会短时占用 CPU，阈值结合一个正常业务周期调整，避免每次正常任务都触发通知。

可在非关键测试环境暂停 Agent 验证失联通知，恢复后再次检查。这个结果验证采集连接中断，不能据此认定网站错误也一定会被发现。

Hub 如果与被监控业务同机，整机故障时面板和通知也会一起停止。需要更可靠的外部观察，再比较独立 VPS；数据与配置仍做异地备份。

从曲线判断要不要增配

持续观察正常访问与备份、更新时的内存和磁盘，再判断是否需要增加资源。单次告警先查异常任务；压力持续存在且任务合理时，按内存规格选择比较。Hub 与 Agent 的认证、连接和数据也要验证，不能只确认容器还在运行。

只为少量机器保存指标，按 Hub 要保留多少历史、怎样发送通知，选择独立的小实例，不必照被监控业务的规格购买。可以比较 Evoxt 的小型实例与地区，尽量不要与业务机放在同一个会一起故障的位置；更需要中文管理说明时，再查看 雨云 RCS 的部署选项。增配被监控机器之前，先用曲线确认持续压力来自哪项应用。

把 Hub 历史与 Agent 身份一起恢复

迁移 Hub 时，只有 Compose 文件不够。官方冷备方法是停止 Hub 后复制整份 beszel_data，其中包括数据库、历史记录和 Hub 密钥；不要只挑一个 SQLite 文件。Agent 另存自己的 Compose、环境文件和 beszel_agent_data。这些资料包含连接凭据，备份目录和包都要限制访问，并另放一份到原机之外。

以下命令以 Linux 上的独立 Compose 目录为例。Hub 目录用 /srv/beszel-hub，Agent 目录用 /srv/beszel-agent，服务名分别是本文的 hub 和官方生成配置中的 beszel-agent。先改成自己的实际路径和服务名；若另用了 .env、env_file 或密钥文件，也须加入对应打包清单。先在 Agent 主机停止采集并保存完整目录：

set -eu
cd /srv/beszel-agent
test -f compose.yaml
test -d beszel_agent_data
umask 077
BACKUP_DIR=/srv/private-backups/beszel
mkdir -p "$BACKUP_DIR"
chmod 700 "$BACKUP_DIR"
AGENT_BACKUP="$BACKUP_DIR/agent-0.21.0-$(date -u +%Y%m%dT%H%M%SZ).tar"
test ! -e "$AGENT_BACKUP"
docker compose stop beszel-agent
tar -cpf "$AGENT_BACKUP" compose.yaml beszel_agent_data
sha256sum "$AGENT_BACKUP" > "$AGENT_BACKUP.sha256"

再在 Hub 主机取得冷备。两者不在同一台机器时，分别保存各自的包；不要为了打包把所有机器的 Token 合到一个公开文件里。

set -eu
cd /srv/beszel-hub
test -f compose.yaml
test -d beszel_data
umask 077
BACKUP_DIR=/srv/private-backups/beszel
mkdir -p "$BACKUP_DIR"
chmod 700 "$BACKUP_DIR"
HUB_BACKUP="$BACKUP_DIR/hub-0.21.0-$(date -u +%Y%m%dT%H%M%SZ).tar"
test ! -e "$HUB_BACKUP"
docker compose stop hub
tar -cpf "$HUB_BACKUP" compose.yaml beszel_data
sha256sum "$HUB_BACKUP" > "$HUB_BACKUP.sha256"

任一步失败就停下，不继续使用半份备份。确认包与校验文件都完整后，原机可先启动 Hub、再启动 Agent，继续采集。打包和恢复应由有权读取这些文件的同一系统账户完成，并保留原 UID/GID 和目录权限；权限不足时核对实际所有者，不把整个目录改成任何人可写。

恢复先用相同版本和镜像架构，在空目录解包。核对可信备份的 SHA-256，再检查包里确实包含部署配置和整份数据；不要在已有的新数据库上覆盖几份旧文件。Hub 使用独立项目名和回环端口，Agent 的 HUB_URL 指向这个恢复副本，迁移同一采集角色时保留原 KEY、系统 Token 与 fingerprint；如果是另一台也要同时上线的机器，应新建系统和 Agent 身份，不复制原目录。原 Hub 的系统列表和通知设置也会回来，因此演练网络必须隔开正式 Agent 和通知出口，只允许自己控制的测试 Agent 连接。不能让两个 Hub 同时打开同一份数据库目录。

下面只执行校验和解包，不会启动应用。每台目标主机分别把 BACKUP 改成对应的 Hub 包或 Agent 包，并选一个不存在的目标目录。校验文件里记录的是生成备份时的完整路径，因此示例要求备份包仍放在该路径；移动过文件时先核对可信记录中的 SHA-256，不随手重新生成校验文件掩盖变化。

set -eu
umask 077
BACKUP=/srv/private-backups/beszel/hub-0.21.0-实际时间.tar
TARGET=/srv/beszel-hub-restore
test -f "$BACKUP"
test -f "$BACKUP.sha256"
sha256sum -c "$BACKUP.sha256"
test ! -e "$TARGET"
mkdir -m 700 "$TARGET"
tar -xpf "$BACKUP" -C "$TARGET"

Agent 包用同样方式在另一空目录恢复。先核对原 UID/GID、文件权限和完整目录，再调整副本的项目名、回环端口、访问地址与隔离网络。生成配置若有固定 container_name，副本改成独有名称或移除该字段；使用 network_mode: host 的 Agent 也须按演练的隔离网络重新配置，不能只换项目名就认为隔离完成。Hub 和 Agent 的挂载仍指向各自恢复出来的目录，不重建一套空数据后再只补数据库。确认不会连接正式采集端或发出真实通知后，先启动恢复 Hub，再启动自己的测试 Agent。命令中不要顺手执行升级或重新创建系统，否则无法判断旧身份能否继续使用。

原有系统能重新上线后，逐一核对账号、系统身份、较早的主机与容器历史，再等新的采样出现。只看到面板打开，或只看到一条新曲线，都不能说明旧历史与配对关系已恢复。演练完成后保留原实例与冷备，再安排正式切换。

这次在 ARM64 的 Docker Desktop 虚拟机内，使用 0.21.0 Hub 与 Agent、内部 WebSocket 和合成账号做了同版本恢复：先形成主机与容器指标，再把完整冷副本恢复到空目录。通过普通 API 核对，原账号、系统、Hub 密钥和 Agent 身份保留，旧的两条主机指标与两条容器指标完整相同，恢复后又各核对了两条新采样。这是分钟级样本；Linux 双机整套命令、公网 TLS 和通知送达没有完整验证，也没有验证 amd64、物理宿主机指标或跨版本升级。