DockerでNetdataをデプロイ：HomeLab向けリアルタイムシステム・コンテナ・ネットワーク監視

Table of Contents

背景と理由：数分ではなく数秒で答えが必要なとき

HomeLabを運用していると、常に同じ疑問が頭をよぎります：なぜこのサービスは今遅いのか？ 私もまさにそんな瞬間を経験しました — 夜11時にJellyfinのストリームがカクカクし始め、CPU・RAM・ディスクI/O・ネットワークのどれが原因かを素早く特定する必要があったのです。

私はすでにインフラメトリクス用にTIG Stack（Telegraf + InfluxDB + Grafana）とログ用にGrafana Lokiを運用しています。どちらも信頼できるツールです。しかしそれらを立ち上げるには時間がかかり、ダッシュボードをゼロから構築する必要があります。ラボに新しいマシンを追加するとき、何も見えないうちからTelegrafエージェントを設定してGrafanaのパネルを繋げたくはありません。

そこでNetdataが私のスタックに組み込まれます。単一のdocker compose upでデプロイでき、CPU・メモリ・ディスク・ネットワーク・実行中のコンテナ・systemdサービスなどのメトリクスを即座に収集し始め、約30秒以内にポート19999で完全に構築済みのダッシュボードとして全てを表示します。スキーマの設計もパネルの構築も不要です。

Netdataは軽量でもあります。ほとんどのHomeLabマシンでRAMは約100MB、CPUは1〜2%程度しか使用しません。15のコンテナを動かしているRaspberry Pi 4でも、ほとんど気にならない程度の負荷です。

実際の経験から言うと、どの監視ツールがどの問題に適しているかを知ることは、習得すべき重要なスキルの一つです。Netdataは「何もない」状態と完全なオブザーバビリティスタックの間のギャップを埋めてくれます。即座の疑問にすばやく答えてくれる一方で、長期的な分析はGrafanaが担当します。

インストール：Docker Composeのセットアップ

Netdata用のディレクトリを作成し、docker-compose.ymlを追加します：

mkdir -p ~/homelab/netdata && cd ~/homelab/netdata

version: "3.8"

services:
  netdata:
    image: netdata/netdata:latest
    container_name: netdata
    hostname: homelab-monitor   # ダッシュボードのヘッダーに表示される
    restart: unless-stopped
    pid: host
    network_mode: host          # 実際のネットワークインターフェースのメトリクスに必要
    cap_add:
      - SYS_PTRACE
      - SYS_ADMIN
    security_opt:
      - apparmor:unconfined
    volumes:
      - netdataconfig:/etc/netdata
      - netdatalib:/var/lib/netdata
      - netdatacache:/var/cache/netdata
      - /etc/passwd:/host/etc/passwd:ro
      - /etc/group:/host/etc/group:ro
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /etc/os-release:/host/etc/os-release:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  netdataconfig:
  netdatalib:
  netdatacache:

そのままコピーして実行する前に、いくつか説明しておく点があります：

pid: host — NetdataがすべてのホストプロセスをPIDで認識できるようにします。これがないと、プロセスごとのCPUとメモリのメトリクスが表示されなくなります。
network_mode: host — これがないと、NetdataはコンテナのバーチャルNICしか見えず、実際のeth0・ens3・ボンドインターフェースは見えません。
/var/run/docker.sock — これにより、Netdataが他のコンテナを自動検出し、追加設定なしでコンテナごとのCPU・メモリ・I/Oを報告できます。
SYS_PTRACE — アクティブなTCP接続やVFS操作などeBPFベースのメトリクスに必要です。

起動してログを少し確認し、正常に初期化されていることを確認します：

docker compose up -d
docker logs -f netdata   # 30秒以内に準備完了するはず

http://<your-host-ip>:19999を開いてください。ダッシュボードが即座に読み込まれます。

設定：データ保持期間・アクセス制御・アラート

メイン設定ファイルの編集

Netdataには、編集前にデフォルトの設定ファイルを永続ボリュームにコピーするヘルパーが付属しています。ゼロからファイルを作成するよりも、このヘルパーを使用してください：

docker exec -it netdata bash
./edit-config netdata.conf

すべてのHomeLabノードで変更する主要な設定：

[global]
  # メモリ内の履歴ウィンドウを拡大する
  history = 7200   # 2時間（秒単位）

[web]
  # ダッシュボードをLANに制限する — インターネットには公開しないこと
  allow connections from = localhost 192.168.1.*

[db]
  # 複数日間の保持のためにメトリクスをディスクに永続化する
  mode = dbengine
  storage tiers = 1

mode = dbengineを設定すると、Netdataはメトリクスをnetdatacacheボリュームに圧縮して保存します。デフォルトでは約2日分のデータが保持され、ほとんどのHomeLabのインシデントに対応できます。複数マシンにわたるより長期の保持が必要な場合は、Netdata Cloud（無料プラン）がすべてを中央で集約してくれます。

2分以内でTelegramアラートを設定する

NetdataにはCPU高負荷・ディスク空き容量低下・RAMプレッシャー・ネットワークエラーなど、あらかじめ組み込まれたアラートルールが付属しています。Telegramに連携するのに約2分しかかかりません：

docker exec -it netdata bash
./edit-config health_alarm_notify.conf

Telegramのブロックを見つけて、認証情報を入力します：

SEND_TELEGRAM="YES"
TELEGRAM_BOT_TOKEN="123456789:ABCdefGHIjklMNOpqrSTUvwxYZ"
DEFAULT_RECIPIENT_TELEGRAM="-1001234567890"   # チャットまたはグループID

実際のアラートを発生させることなく、すぐにテストできます：

/usr/libexec/netdata/plugins.d/alarm-notify.sh test telegram

数秒以内にTelegramにテストメッセージが届きます。

自分の環境に該当しないアラートを無効にする

スワップを意図的に無効にしているマシンでは、スワップ使用率のアラートが常に発火し続けます。ノイズとして放置するのではなく、無効にしてください：

docker exec -it netdata bash
./edit-config health.d/swap.conf

該当しないルールにはenabled: noを追加してください。一般的なデフォルトの代わりに実際の期待値に合わせてしきい値を引き上げることは、ルールを完全に無効化するよりも良い選択肢であることが多いです。

確認と監視：ダッシュボードの読み方

セットアップ後に最初に確認すべきこと

左のサイドバーには、Netdataが検出したすべてのサブシステムが一覧表示されます。典型的なHomeLabサーバーでは以下が見つかります：

System Overview — CPU・RAM・スワップ・ロードアベレージが一か所に
Disk — ディスクごとのI/O・使用率・レイテンシ。NASやメディアサーバーが重い場合はここから確認
Network Interfaces — インターフェースごとのトラフィック・パケット・エラー。network_mode: hostを使えば、VPNトンネル（wg0・tun0）を含む実際のインターフェースが見える
Containers — コンテナごとのCPUとメモリ、使用量順でソート。何かおかしいと感じたとき、私が最初に開くのはここ

コンテナレベルの可視性

サイドバーのContainersをクリックしてください。実行中の各コンテナが独自のチャートグループとして表示されます — CPU使用率・メモリ消費量・ディスク読み書き・ネットワークI/Oがすべて明確に分離されて表示されます。

ラボにNetdataを最初にデプロイしたとき、Uptime Kumaが数分ごとに15 MB/sのディスク書き込みをしていることに気づきました。SQLiteデータベースに積極的にログを書き込んでいたのです。Netdataを導入する前は全く見えていませんでした。ダッシュボードを開いてから見つけるのに約90秒しかかかりませんでした — それまでは、時々発生するディスクのボトルネックを原因不明のノイズとして受け入れていたのです。

Dockerメトリクスが有効であることを確認する

Containersセクションがない、または空の場合は、ソケットのマウントを確認してエラーをチェックしてください：

# Dockerプラグインのエラーを確認する
docker exec netdata cat /var/log/netdata/error.log | grep -i docker

# アクティブなチャートを数える — 20〜30コンテナの正常なインストールでは300〜500以上
curl -s http://localhost:19999/api/v1/charts | python3 -c "
import sys, json
data = json.load(sys.stdin)
print(f'アクティブなチャート数: {len(data[\"charts\"])}')
"

必要になる前にベースラインを把握しておく

セットアップ直後、システムが通常の負荷状態のときに、10分かけてチャートをクリックして確認してください。アイドル時のCPU使用率・通常の空きRAM・ベースラインのディスクI/Oをメモしておいてください。深夜2時に何かが壊れたとき、「正常な状態」のメンタルモデルが必要です — Netdataのカラーコーディング（緑/黄/赤）も、アラートのしきい値に対して自動的にこれを反映します。

Netdata Cloudを使ったマルチノードビュー

HomeLabが複数のマシン（NAS・Proxmoxホスト・Raspberry Pi）にまたがっている場合、Netdata Cloudがすべてに対して単一のURLを提供してくれます。無料プランに登録し、各ノードでクレームコマンドを実行すると、すべてのダッシュボードが一か所に表示されます：

# app.netdata.cloudにサインアップ後、各Netdataコンテナ内で実行する
docker exec -it netdata netdata-claim.sh -token=YOUR_CLAIM_TOKEN -rooms=YOUR_ROOM_ID -url=https://app.netdata.cloud

Netdataのクラウドエージェントを通じてアウトバウンド接続します — 新たな受信ポートを開く必要も、VPNも不要です。

これで、HomeLabのすべての重要なリソースをリアルタイムで可視化できるようになりました。新しいマシンを追加してコンテナをデプロイすれば、即座に報告が始まります。YAMLダッシュボードを構築する必要も、Prometheusのスクレイプ設定も、遅いポーリング間隔のせいでメトリクスが15秒遅れで届くのを待つ必要もありません。