Posted inホームラボ

DockerでBeszelをデプロイ：ホームラボ向け軽量サーバー監視ダッシュボード（5分でセットアップ）

HomeLab tutorial - IT technology blog
HomeLab tutorial - IT technology blog

午前2時のことだった。ホームラボのNASはひどく重くなり、ファンはタービンのように回り続けていた。何がリソースを食い尽くしているのか、まるで見当もつかない。Grafana + Prometheusを設定していたはずなのに、スクレイパーが3日前にひっそりと止まっていたことに気づいた。アラートもなし。データもなし。午前2時に真っ白なダッシュボードが私を嘲笑うだけだった。

その夜、Beszelを発見した。10分後には、どのDockerコンテナがCPUを酷使しているか正確に把握できた。Beszelが魔法のツールだからではなく、ただ確実に動き続けてくれるからだ。

クイックスタート：5分でBeszelを起動する

Beszelはハブ・エージェント型アーキテクチャを採用している。Hubは操作するWebダッシュボードで、軽量なAgentを監視対象の各サーバーで動かす。単一マシンの場合は、両方を同じホストで実行する。

作業ディレクトリを作成し、以下のdocker-compose.ymlを配置する：

mkdir ~/beszel && cd ~/beszel
version: "3"

services:
  beszel:
    image: henrygd/beszel
    container_name: beszel
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - ./beszel-data:/beszel_data

  beszel-agent:
    image: henrygd/beszel-agent
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - PORT=45876
      - KEY=          # 今は空のまま — Hubセットアップ後に入力する

まずHubだけを起動する：

docker compose up beszel -d

http://your-server-ip:8090を開いてadminアカウントを作成する。次にSystems → Add Systemに進み、以下を入力する：

  • Host: localhost（リモートからアクセスする場合はサーバーIP）
  • Port: 45876

Beszelが公開鍵を生成する。それをコピーしてdocker-compose.ymlのKEY=に貼り付け、agentを起動する：

docker compose up beszel-agent -d

ダッシュボードを更新する。約30秒以内にCPU、RAM、ディスク、ネットワークがリアルタイムで表示される。本当にこれだけだ。

詳細解説：Beszelの仕組み

HubとAgentのアーキテクチャ

HubはPocketBase上で動作する — SQLiteデータベースを内蔵したシングルバイナリのバックエンドだ。そのため、私の環境ではHubのアイドル時のRAM使用量が12〜18MB程度に収まっている。別途メトリクスストアは不要で、Prometheusのスクレイプ間隔を調整する必要もなく、Grafanaのプラグインバージョンに悩まされることもない。

Agentはed25519キーペアを使ったSSHトンネル経由でHubに接続する。セットアップ時にコピーするKEYはHubの公開鍵で、Agentはそれを使って認証し、暗号化チャンネルを開く。メトリクスが平文HTTPで送信されることはなく、Agentが異なるネットワークセグメントにまたがる場合でも安全だ。

追加設定なしで監視できる項目

  • CPU使用率（詳細ビューでコアごとの内訳を確認可能）
  • メモリとスワップの使用量
  • マウントポイントごとのディスク使用量とI/O
  • インターフェースごとのネットワーク帯域幅
  • システムの稼働時間と負荷平均
  • Dockerコンテナの統計情報 — コンテナごとのCPUとメモリ
  • NVIDIAおよびAMDカードのGPU統計情報（存在する場合）

Dockerソケットのマウント（/var/run/docker.sock:/var/run/docker.sock:ro）によってコンテナレベルの統計が有効になる。不要な場合は削除しても問題ない — agentはそれなしでもホストリソースを正常に監視できる。

応用編：マルチサーバーのホームラボ構成

リモートサーバーの追加

ここからが本当に便利なところだ。私の環境では4台のマシン — 2台のUbuntuサーバー、Raspberry Pi 5、そして古めのProxmoxノード — がすべて単一のHubに報告している。各agentのRAM使用量は5〜15MB程度で、CPUへの影響はほぼ皆無だ。リモートマシンにはagentだけをデプロイすればよい。Hub不要、データベース不要、Webサーバーも不要。

リモートノード用の最小限のdocker-compose.yml：

version: "3"

services:
  beszel-agent:
    image: henrygd/beszel-agent
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - PORT=45876
      - KEY=your_hub_public_key_here

Dockerよりもベアメタルのほうがよければ、agentはシングルバイナリとして提供されている：

curl -sL https://get.beszel.dev/agent | bash

再起動後も動作するようsystemdサービスとして登録する：

sudo tee /etc/systemd/system/beszel-agent.service <<EOF
[Unit]
Description=Beszel Agent
After=network.target

[Service]
Environment="PORT=45876"
Environment="KEY=your_hub_public_key_here"
ExecStart=/usr/local/bin/beszel-agent
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable --now beszel-agent

Hubに戻り、Systems → Add Systemからリモートシステムを追加し、リモートIPとポート45876を入力すると、数秒以内に接続される。

アラートとWebhook通知

BeszelはアウトバウンドWebhookをサポートしているので、Discord、Slack、またはPOSTリクエストを受け付けるあらゆるサービスにアラートを送信できる。Settings → Notificationsに進んでWebhook URLを追加し、システムごとにアラートルールを作成する。

CPUが5分間85%を超えた場合のDiscordアラートは、約2分で設定できる：

  1. チャンネル設定でDiscord Webhookを作成する
  2. Webhook URLをBeszelの通知設定に貼り付ける
  3. システムのアラートルールでCPU > 85%を5分間に設定する

システムごとのしきい値設定により、負荷時に温度が上がりやすいRaspberry Piには、メインサーバーよりも緩いCPU上限を設けることができる。異なるハードウェアに合わせたしきい値によるノイズとは無縁だ。

本番環境から学んだ実践的なヒント

3ヶ月間本番環境で運用している。何もひっそりと壊れたことはない。スクレイパーが夜間に止まることも、時系列データベースが20GBを超えて膨れ上がることも、監視スタック自体を監視する必要もない。

痛い経験から学んだこと：

本番で使うイメージはバージョンを固定する。 :latestはテストでは問題ないが、本番ではロックする：

image: henrygd/beszel:0.9.0

beszel-dataを毎日バックアップする。 アカウント、システム、過去のメトリクスなど、すべてがそのディレクトリ1つに格納されている。シンプルなrsyncジョブで対応できる：

rsync -av ~/beszel/beszel-data/ /mnt/backup/beszel-data/

Hubをリバースプロキシの背後に配置する。 ポート8090を直接公開しないこと。CaddyならTLSが簡単に設定できる：

monitor.yourdomain.com {
    reverse_proxy localhost:8090
}

ポート45876がHubからAgentへ到達可能か確認する。 ファイアウォール内のマシンがある場合は、そのポートを明示的に開放するか、すべてをTailscaleネットワーク上で動かす。私はTailscaleを使っており、監視トラフィックはプライベートオーバーレイ内に留まり、公衆インターネットに触れることはない。

ネットワーク帯域幅チャートで予期しないトラフィックを検出する。 私が最も活用している機能だ。ある夜、午前3時にマシンが40 MB/sの通信を継続しているのをチャートで発見した — 設定が誤ったバックアップジョブが毎時間同じデータセットを再アップロードしていたのだ。Beszelは30秒でそれを示してくれた。なければ、翌月のホスティング料金で問題に気づいていたことだろう。

BeszelをフルのGrafana + Prometheusスタックと比較するのは公平ではない — それぞれ異なる問題に対応するツールだからだ。ログの相関分析、カスタムビジネスメトリクス、自動修復をトリガーするアラートパイプラインが必要な場合は、Grafanaが適している。

しかし、ホームラボのサーバーとコンテナの状態を一目で把握するためなら、Beszelは運用の複雑さを約80%削減し、リソースコストも約5%に抑えられる。私の環境では、監視ホストからTIGスタックを削除することでほぼ800MBのRAMが解放され、Plexトランスコーダーが喜んで引き継いだ。

Share:
Tags: