Proxmox + InfluxDB + Grafana：エンタープライズ級の仮想マシン監視環境を構築する秘訣 – ITFROMZERO

Table of Contents

デフォルトのダッシュボードによる数十台の仮想マシン管理：静かなる悪夢

12台のVMを動かしている個人ラボから実際の商用クラスターまで、半年以上システムを運用して気づいた大きな限界があります。Proxmox VEのインターフェースは設定には非常に優れていますが、全体的な監視（Monitoring）に関してはかなり「窮屈」だということです。システムの規模が大きくなるにつれ、デフォルトのダッシュボードに頼った管理は多くの不都合を露呈し始めます。

例えば、昨夜VM 101のCPUがボトルネックになっていなかったか確認したいとき、毎回Summaryをクリックして小さなグラフを凝視しなければなりません。5台のVMのRAM使用率を同時に比較したいと思っても、Proxmoxはそうした一元的な表示をサポートしていません。特に、Proxmoxはメトリクスの保存に RRD（Round Robin Database）を使用しています。この仕組みは、容量を節約するために古いデータを自動的に上書き・圧縮（平滑化）してしまいます。そのため、1ヶ月前の詳細な負荷状況を確認することは、ほぼ不可能な任務に近いのです。

なぜProxmoxの標準グラフでは不十分なのか？

技術的な観点から見ると、Proxmoxに組み込まれているログおよびメトリクス保存システムには、3つの致命的な弱点があります。

データの平均化： 週単位や月単位でグラフを表示すると、データポイントが統合され、重要なスパイク（突発的な負荷）が消えてしまいます。
俯瞰性の欠如： クラスター全体、ストレージ（ZFS/Ceph）、ネットワークトラフィックを1つの画面で同時に表示することができません。
貧弱なアラート機能： パフォーマンスの閾値に基づいて、TelegramやSlackに柔軟に通知を送る仕組みがProxmox単体では不足しています。

一般的な監視方法とそのデメリット

最適解にたどり着く前に、よくある2つの方法を試しましたが、それぞれに課題がありました。

各VMにZabbix Agentをインストールする： 非常に詳細なデータが得られますが、メンテナンスに手間がかかります。新しいVMを作成するたびにエージェントを入れ、テンプレートを手動で割り当てる必要があります。
Prometheus + Node Exporterを使用する： 業界標準ではありますが、ProxmoxはPrometheusへの直接的なデータプッシュをサポートしていません。サードパーティ製のExporterをインストールする必要がありますが、Proxmoxのメジャーアップデートのたびに動作が不安定になることがよくあります。

最適解：Proxmox + InfluxDB + Grafanaの三種の神器

これは、私が高い安定性を求めるシステムで採用している構成です。Proxmoxには強力な「Metric Server」機能が備わっており、エージェントを追加することなく、InfluxDBへ直接（ネイティブに）データを送信できます。これにGrafanaを組み合わせることで、極めて低遅延なエンタープライズ基準の監視システムを構築できます。

ステップ1：InfluxDBのデプロイ（データの集積所）

システムをクリーンに保つため、Dockerを使用してInfluxDB 2.xを実行することをお勧めします。コマンド1つで、時系列データ（time-series）のストレージが完成します。

docker run -d --name influxdb \
  -p 8086:8086 \
  -v /mnt/data/influxdb:/var/lib/influxdb2 \
  influxdb:latest

起動後、http://<あなたのIP>:8086にアクセスしてOrganizationを設定し、proxmoxという名前のBucketを作成します。Proxmoxからデータを送信するための鍵となるAPI Tokenを忘れずに控えておいてください。

ステップ2：Proxmoxの自動データ送信設定

この部分はWeb UI上で操作するだけで、ホストのコマンドラインを触る必要がないため非常に簡単です。

左メニューのDatacenterを選択します。
Metric Server項目を探し、AddをクリックしてInfluxDBを選択します。
接続情報を入力します：Server IP、ポート8086、そしてステップ1で取得したAPI Tokenを貼り付けます。
OrganizationとBucketの名前が、InfluxDBで設定したものと正確に一致していることを確認してください。

OKを押した瞬間から、Proxmoxは全ノード、VM、コンテナのメトリクスを10秒ごとにストレージへ送信し始めます。

ステップ3：Grafanaによるグラフ作成の設定

InfluxDBが倉庫なら、Grafanaは腕の良い絵師です。GrafanaもDockerで素早く構築できます。

docker run -d --name grafana -p 3000:3000 grafana/grafana

Grafanaのインターフェース（デフォルトは admin/admin）で、Connections -> Data Sources に進み、InfluxDBを選択します。2.x系と完全に互換性を持たせるため、Query LanguageにはFluxを選択してください。

ステップ4：30秒でプロ仕様のダッシュボードをインポート

グラフを一つずつ自作して時間を無駄にする必要はありません。コミュニティが素晴らしいダッシュボードを既に公開しています。おすすめはID：15356のテンプレートです。

Dashboards -> New -> Importに進みます。
“Import via grafana.com”の欄に 15356 と入力します。
作成したInfluxDBのデータソースを選択して完了です。

これで、クラスター全体のCPU、RAM使用率から各VMのディスクI/Oまで、リアルタイムな情報が画面いっぱいに表示されるようになります。

実運用から得られた「血の滲むような」教訓

長期間安定して運用するために、以下の3つの技術的なポイントに注意してください。

1. ディスク容量の管理： 約20台のVMを監視する場合、InfluxDBは月に数GBのデータを消費することがあります。Retention Policy（保存期間ポリシー）を30日程度に設定することをお勧めします。3ヶ月前の1秒単位のCPU詳細データなどは、実運用においてあまり価値がありません。

2. Fluxクエリの威力： InfluxDB 2.xのFlux言語を学ぶことを恐れないでください。従来のSQLよりもはるかに強力で、現在の書き込み速度に基づいた「ディスク容量が枯渇する時期の予測」といった高度な指標も計算できます。

3. ハードウェア温度の監視： デフォルトでは、Proxmox はCPU温度のデータを送信しません。ミニPCなどでホームラボを運用している場合は、ホストにtelegrafを追加でインストールしてセンサー値を取得することをお勧めします。温度は、マシンの清掃やCPUグリスの塗り替え時期を知るための最も重要な指標です。

管理と監視を切り離すことで、システムをより客観的に見ることができるようになります。今では、各ノードにログインしなくても、サブモニターに映るGrafanaをちらっと見るだけで、サーバークラスターが「健康」か「異常」かを即座に判断できるようになりました。