Beszel 監控教學：用 10MB 記憶體取代 Prometheus，把多台 VPS 狀態收進一張儀表板

想監控幾台 VPS 該選什麼工具？多數人下意識的答案是 Prometheus 加 Grafana，然後花一個下午跟 scrape_configs、node_exporter、cadvisor、Loki、Promtail 搏鬥，最後光是監控 stack 本身就吃掉 500MB 記憶體——比被監控的服務還多。Beszel 是 2025 年底開始竄紅的輕量化監控工具，GitHub 星星數從幾千暴衝到兩萬多，但中文資料幾乎是零。它的定位很明確：給只有 3 到 30 台機器的個人或小團隊，用 10 分鐘換掉整套 Prometheus 方案。

為什麼 Prometheus + Grafana 對小規模 VPS 是過度殺雞

Prometheus 的設計目標是動態的容器化叢集，scrape model、PromQL、TSDB 都是為了「服務數量隨時在變、metric 上百萬條」的場景準備的。

如果只有幾台固定的 VPS：

不需要 service discovery
不需要 PromQL 跑高維度聚合
不需要 30 天以上的高解析度資料
看儀表板的頻率是「出事才看」，而不是 SRE 24/7 盯著螢幕

實際上需要的只有：CPU、記憶體、磁碟、頻寬、Docker 容器狀態，超過閾值寄信通知。Beszel 就是專心做這件事，其他一概不碰。這種「克制」反而是它的價值。

Hub 與 Agent：兩個元件就能講完整個系統

Beszel 架構簡單到一句話講完：

Hub：跑在一台機器上的網頁儀表板，用 Go 寫，後端是內嵌 SQLite 的 PocketBase
Agent：跑在每台要監控的機器上的小程式，把指標推給 Hub

Agent 平均吃 10MB RAM、近乎 0% CPU。Hub 加上 PocketBase 的整體記憶體大約 30–50MB。對比 Prometheus + Grafana + node_exporter 動輒 500MB 起跳，差距非常明顯。

通訊預設走 SSH 協定——Hub 持有一對 SSH 金鑰，Agent 那邊填上 Hub 的公鑰，握手成功才會傳資料。這個設計讓 Agent 不必對外開 port 接受匿名連線，安全模型比寫死 token 乾淨很多。

Hub 端：一份 Docker Compose 就搞定

挑一台有對外網域、有反向代理的 VPS 當 Hub。建議跟其他高流量服務分開，不要塞進已經很忙的主機。

services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - ./beszel_data:/beszel_data
    environment:
      APP_URL: https://beszel.example.com
      DISABLE_PASSWORD_AUTH: false

docker compose up -d 之後開瀏覽器到 8090，第一個註冊的帳號自動成為管理員。把 Hub 套上 Caddy 或 Nginx Proxy Manager 的反向代理加 HTTPS，這部分跟其他自架服務沒差別。

要注意一個細節：APP_URL 一定要設正確的對外網址。Beszel 會用這個值組裝 webhook 與通知連結，沒設對的話，告警信裡的連結會點不開，然後在凌晨三點被誤導到錯的儀表板。

Agent 端：兩種連線模式怎麼選

裝 Agent 之前，先在 Hub 介面點「Add System」，畫面會給出三樣資訊：

一段公鑰（ssh-ed25519 ...）
一組 Token
Agent 預設要聽的 port 45876

接下來有兩種部署模式，差別在「誰主動連誰」。

模式一：Hub 主動連 Agent（預設）

適合 Hub 跟 Agent 都在同機房、或 Agent 有公開 IP 的情境。Agent 開 45876 等 Hub 來連：

services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      LISTEN: 45876
      KEY: "ssh-ed25519 AAAA... 從 Hub 介面複製過來"
      TOKEN: "從 Hub 介面複製過來"

network_mode: host 是必要的，否則 Agent 抓到的網卡會是 Docker 的虛擬橋接，所有流量數字會錯。Docker socket 用唯讀模式掛進去，讓 Agent 能讀取容器層級的 CPU/記憶體統計。

防火牆要放行 45876 給 Hub 的 IP——只開給 Hub，不要開給全世界。

模式二：Agent 主動連 Hub（WebSocket）

Agent 卡在 NAT 後面、沒有公開 IP、或不想開額外防火牆 port 的情境用這個。加一個 HUB_URL 變數，Agent 會用 WebSocket 主動建立外連通道：

environment:
  HUB_URL: https://beszel.example.com
  KEY: "ssh-ed25519 ..."
  TOKEN: "..."

選擇建議：機器有公開 IP 用模式一；其餘情況一律用 WebSocket 模式。WebSocket 模式還有一個附加好處——所有流量走 443，穿過任何企業防火牆都沒問題，也免去日後幫每台新機器調整 ACL 的麻煩。

容器層級的監控不必裝任何額外工具

把 /var/run/docker.sock 掛進 Agent 之後，每個容器的 CPU、記憶體、網路 I/O 都自動出現在儀表板上，不用 cAdvisor、不用裝任何 sidecar。Podman 同樣支援，掛 Podman socket 即可。

這個內建功能對自架 n8n、Nextcloud、Mastodon 那類多容器堆疊特別有用——可以直接看到哪個容器在偷吃記憶體，不必每次都 SSH 進機器敲 docker stats 再人工比對時間。

告警設定：預設值等於沒設

每台機器加進 Hub 後，告警閾值預設都是空的，這代表機器爆掉也沒人通知。至少要設這幾條基本規則：

CPU 持續 10 分鐘超過 80%
記憶體使用率超過 90%
磁碟使用率超過 85%
系統離線超過 2 分鐘

通知管道支援 SMTP，以及 Shoutrrr 相容的各種第三方（Telegram、Discord、Slack、Gotify 等）。把通知接到自架的 Telegram Bot 上，手機推播比信箱即時，半夜被叫醒的成功率高很多。

一個容易踩的雷：磁碟告警會分別計算根目錄與每個被掛載的卷。如果 Docker 資料卷掛在 /var/lib/docker 或獨立分割區，那條警報得單獨開啟，光設根目錄不會自動涵蓋。

Beszel 該避開的使用情境

老實講三個明確限制：

沒有 PromQL 那種任意維度查詢。要做「過去一週某 label 的 P95 延遲」這種應用層分析，Beszel 不是答案
長期保留的歷史資料較粗。預設保留約 30 天較細粒度的資料，再久之前的會被抽樣壓縮，不適合做容量規劃的迴歸分析
沒有日誌系統。Beszel 純粹是 metric 工具，要看日誌得另外架 Loki 或直接 journalctl

換句話說，若監控對象超過 50 台、需要長期容量規劃、或要做應用層 SLI/SLO，Prometheus 仍是該選的工具。Beszel 解決的是另一個被忽略的問題：「小規模自架時，不想被監控本身綁架時間」。

監控存在比監控完美更重要

很多自架的 VPS 服務根本沒裝監控，原因不是不重要，而是裝 Prometheus 那套門檻太高，乾脆放著不管，直到某天磁碟滿了 nginx 直接 502 才在事後爬日誌追原因。

Beszel 把這個門檻砍到極低：10 分鐘部署 Hub、5 分鐘加一台 Agent、整體記憶體開銷低到可以忽略不計。對於管理 3 到 30 台機器的場景，這是 2026 年最划算的答案。

NCSE Network 提供的 VPS 採用 Intel Gold CPU 與 NVMe SSD，臺灣是方電訊機房具備 99% SLA 與多上游網路，跑 Beszel 這類輕量監控可以在低資源佔用下掌握每一台機器的健康狀況。需要穩定的伺服器跑自己的監控 stack，可以到 ncse.tw 看 VPS 方案，或直接聯絡團隊討論需求。