Beszel 干的事很窄：一分钟记一次 CPU / 内存 / 磁盘 / 显卡占用，摊成历史曲线，指标越线就往自己的地址推一条。手边几台机器跑着定时脚本和小服务，出问题往往第二天才知道。之前看负载靠 glances 手动跑一遍，看完就关了，历史一点没留。这套东西分两半，面板管界面，采集端读硬件，数据落在本地 SQLite 里。

两个 exe，没有一个安装程序

发布页上 Windows 版给了两个 zip，一个是面板，一个是采集端。面板 13,374,188 字节，解压只有一个 beszel.exe，34,170,880 字节；采集端 6,286,962 字节，解开是 beszel-agent.exe，14,544,896 字节。没有 setup.exe，也不用先装 Go 或者数据库，前端文件编译进了二进制。

beszel_windows_amd64.zip          13,374,188 字节
  └─ beszel.exe                   34,170,880 字节
beszel-agent_windows_amd64.zip     6,286,962 字节
  └─ beszel-agent.exe             14,544,896 字节
两个 exe 合计                     48,715,776 字节
运行库依赖                         无

好处是搬到别的机器上只需要复制目录，两个 exe 加起来 48,715,776 字节。坏处是两个都得分别起，面板本身不采集数据，它只负责收和画。

面板 1.58 秒起来，账号在页面上建

起服务的命令很短，端口和数据目录都能指定，不带参数时默认监听 127.0.0.1:8090。从进程启动到首页返回 200，计时 1.58 秒。

beszel.exe serve --http 127.0.0.1:8090 --dir data
进程到首页 200                    1.58 秒
首页 HTML                          1,214 字节
/api/health 十次                   1.24 ~ 1.51 毫秒
data 目录首次生成                  914,659 字节

第一次打开是一张创建管理员的表单，邮箱 / 密码 / 确认密码三格，填完点按钮，0.35 秒进到仪表盘。仪表盘此时是空的，一行写着 No systems found。

有一步容易走岔。它基于 PocketBase，命令行里有 superuser upsert，0.394 秒就能建一个账号并提示 Successfully saved。建出来的是数据库管理员，不是面板用户，回到网页照样让你创建管理员账号。真要重置面板密码，得走 users 集合，不是这条命令。

加机器这一步，坑在一串 token 上

仪表盘右上角 Add System，弹窗里切到 Binary，会直接给你公钥和一条安装命令。系统记录建好之后，采集端要在被监控的机器上跑起来，命令长这样：

beszel-agent.exe -key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP39r046..." \
                 -token "ddd7246a-b0d2-4270-bb26-d278d36f2c51" \
                 -listen 45876

采集端不是 HTTP 服务，日志里写的是 Starting SSH server addr=:45876，它开一个 SSH 端口，由面板主动连过来拉数据。端口要通，面板那边记录的地址和端口也要对。

踩坑就在 token。弹窗里 Token 那一格显示的是一串 3e939361-e677-4f13-...，照着填进去，采集端进程正常，45876 也在监听，面板上那个圆点一直是灰的，状态 down，等了三分钟没动静。翻 data\data.db 的 fingerprints 表才发现，这个系统真正的令牌是另一串 ddd7246a-b0d2-4270-bb26-d278d36f2c51。换成它，六秒内变绿。

这种失败没有任何报错提示，采集端不打印错误，面板也不说为什么连不上，只是把状态标成 down。静默失败最难查，45876 被防火墙拦掉是第一怀疑对象，实际不是。

字符串来源	等待秒数	面板状态	说明
弹窗 Token 格	180	down	进程在跑，端口在听
data.db 的 fingerprints 表	6	up	采集数据正常

第二处坑在改地址。系统建好之后如果改了 host 或者 port（换个端口），面板不会自动重连，得把 hub 停掉再起。改完不重启，界面上还是 down 状态，很容易误判成采集端的问题。

面板上的指标比预想的多

这台测试机是 i5-12400F，6 核 12 线程，31.86 GB 内存，C 盘 329.43 GB 用了 87.78%。接上之后它给出的图表有 CPU 使用率 / 内存 / 根分区 / 磁盘吞吐 / 带宽 / 负载 / 温度，另外还有显卡。

CPU 总占用        15.52%（每核 12 个值：24/11/28/12/21/9/18/10/15/9/15/13）
负载均值          0.01 / 0.04 / 0.02
采集间隔          60 秒一个点

指标	读数
内存已用 GB	24.09
内存总量 GB	31.86
内存占用 %	75.61
根分区已用 GB	289.16
根分区总量 GB	329.43
根分区占用 %	87.78
显存已用 MB	2713.87
显卡占用 %	16.73
显卡功耗 W	31.5
显卡温度 °C	40
磁盘读 B/s	14404
磁盘写 B/s	477055
网卡收 B/s	199077
网卡发 B/s	149139

显卡那几项是没料到的。它读到 nvidia-smi 给的数据，占用 16.73%、显存 2713.87 MB、功耗 31.5 W 三个都在，温度 40°C 也一起进来。跑本地模型或者做转码的机器，看这个比翻任务管理器省事。

时间范围在右上角切换，最短 1 minute，最长 30 days。默认 1 hour，数据点一分钟一个，切到 30 days 时它把老点聚合成更粗的粒度再画。

告警能真的推到自己的地址

通知走的是 Shoutrrr，所以填一条 URL 就够，不用在界面里一个个配服务商。在本地起个接收端，把 generic+http://127.0.0.1:8899/hook 填进 Notifications 的 Webhook 那一行，点 Test URL，三秒内收到一条：

Test Alert

This is a notification from Beszel.

http://localhost:8090

把 CPU 告警阈值设成 1%，一分钟后触发，收到的正文是这样：

shiceku-win CPU above threshold

CPU averaged 19.51% for the previous 1 minute.

http://localhost:8090/system/9hn5nd6gpuj6gdz

它报的是上一分钟的平均值，不是瞬时值。这一点比抓瞬时峰值靠谱，不会因为一次编译把手机吵醒。告警历史里留下一条记录，系统名 / 指标 / 触发时间 / 持续时长四列，状态 Active。

设置里还有 Quiet Hours，可以划一段免打扰时间，比如从 2 点到 6 点这 4 个小时。这段时间照样采集，只是不发通知，省得半夜重启机器被自己的告警吵醒。

占多少内存，长多快

两个进程同时跑，面板 37.5 MB 工作集，采集端 30.8 MB，加起来 68.3 MB。私有内存分别是 59 MB 和 58.5 MB，比工作集大一些，那部分含共享映射，实际吃掉多少看工作集更接近。

beszel.exe         工作集 37.5 MB   私有 59.0 MB
beszel-agent.exe   工作集 30.8 MB   私有 58.5 MB
两个加起来         工作集 68.3 MB
data.db            466,944 字节（含表结构与历史点）
辅助库             4,096 字节
面板私钥           id_ed25519，387 字节
一天数据点         1,440 个（一分钟一个）