PrometheusとProxmox VE ExporterによるProxmox VEの監視：VM、LXC、ストレージの統合管理 - ITFROMZERO - Share tobe shared! Proxmox VEの各種監視手法を徹底比較し、APIトークンを用いたPrometheusとProxmox VE Exporterの連携構築手順を解説。物理ノードからVM、LXC、ディスク、ZFS/Cephストレージプールまでのリソースを効率的に監視・運用する方法を紹介します。

Table of Contents

Proxmox VEクラスタ監視における3つのアプローチ比較

3ノード以上、40〜50台規模のVMやLXCコンテナで構成されるProxmoxクラスタを運用する場合、継続的な可観測性（オブザーバビリティ）の確保が不可欠です。物理ハードウェアと仮想マシンの稼働状況を即座に把握する必要があります。現在、主に次の3つのアプローチが存在します。

方法1：各VM/LXCにNode Exporterをインストールする。 仮想マシンごとにエージェントプロセスを動作させ、Prometheusが各IPアドレスから個別にメトリクスをプル（スクレイプ）します。
方法2：Proxmox標準搭載のMetric Serverを使い、InfluxDBやGraphiteへプッシュする。 Web GUI上から直接設定するだけで、Proxmoxが定期的にメトリクスを自動送信します。
方法3：REST API経由でProxmox VE Exporterを導入し、Prometheusと連携させる。 Exporterがプロキシとして機能し、APIトークンを用いて物理ノード、VM、LXCからZFS/Cephプールに至るクラスタ全体のメトリクスを取得します。

各ソリューションの実際のメリット・デメリット

1. 各仮想マシンへのNode Exporter導入（VM単位のエージェント方式）

この方式は、ゲストOS内部から最も詳細なメトリクスを収集できます。個別のプロセス状況、キャッシュメモリ、スワップ使用量などを正確に把握可能です。

一方で、運用負荷が非常に高くなります。VMを新規作成するたびにエージェントのセットアップ、ファイアウォールのポート開放、Prometheusターゲットの更新が必要になります。さらに重大な欠点として、VM内のエージェントでは物理サーバーのディスク障害、Cephプールのデグレード、ホスト側KVMプロセスのフリーズなどを検知できません。

2. 組み込みMetric Server（InfluxDBへのプッシュ方式）

Proxmox GUI上で数クリックするだけで設定が完了し、追加の補助サービスを構築する必要がありません。

しかし、既存の監視基盤がPrometheusやAlertmanagerで標準化されている場合、これが大きな障害となります。Proxmoxのメトリクスを受信するためだけに専用のInfluxDBクラスタを構築するのはリソースの無駄であり、アラート通知の一元化も極めて複雑になります。

3. REST API連携によるProxmox VE Exporterの導入

運用チームにとって最も合理的かつ実用的な選択肢です。読み取り専用のAPIトークンを1つ発行するだけで、ゲストOSに手を加えることなく、新設されたすべてのVM/LXCのメトリクスを自動収集できます。物理ノードのハードウェア状態からリソース割り当て、共有ストレージの容量まで包括的に監視可能です。

なぜProxmox VE Exporterが本番環境（プロダクション）に適しているのか？

システム規模が拡大するにつれ、開発チームにエージェント導入を依頼する運用では設定漏れが発生しやすくなります。Proxmox VE Exporterを採用すれば、仮想化基盤レイヤーとアプリケーションレイヤーを完全に分離できます。仮想マシン内部の設定や状態に依存せず、インフラ全体の稼働状況を即座に把握できます。

Proxmox VE ExporterとPrometheusの構築手順

ステップ1：最小権限の原則に基づくユーザーおよびAPIトークンの作成

監視用途にrootアカウントを使用してはなりません。pveレルム上に読み取り専用権限を持つ専用ユーザーを作成します。

任意のProxmoxノードのシェルを開き、以下のコマンドを順次実行します。

# 1. インフラメトリクスの読み取り専用ロールを作成
pveum role add MonitoringRole -privs "VM.Audit Datastore.Audit Sys.Audit Sys.Console"

# 2. 専用ユーザーを作成
pveum user add prometheus-exporter@pve -comment "Prometheus Monitoring User"

# 3. クラスタ全体に権限を付与
pveum acl modify / -user prometheus-exporter@pve -role MonitoringRole

# 4. APIトークンを作成（ユーザー権限を継承するためPrivilege Separationを無効化）
pveum user token add prometheus-exporter@pve monitoring-token --privsep 0

実行後に画面へ表示されるValue（トークンシークレット）を、直ちにパスワードマネージャー等に保存してください。この値はProxmox上で二度と再表示されません。

ステップ2：Docker ComposeによるProxmox VE Exporterのデプロイ

Exporterは監視サーバー上に構築可能です。次のようにdocker-compose.ymlを作成します。

services:
  proxmox-exporter:
    image: prompve/prometheus-pve-exporter:latest
    container_name: proxmox-pve-exporter
    restart: unless-stopped
    ports:
      - "9221:9221"
    volumes:
      - ./pve.yml:/etc/prometheus/pve.yml:ro

続けて、同じディレクトリに認証設定ファイルpve.ymlを作成します。

default:
  user: prometheus-exporter@pve
  token_name: monitoring-token
  token_value: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  verify_ssl: false

コンテナを起動し、接続テストを実行します。

docker compose up -d

# ProxmoxノードのIP（例: 192.168.1.10）を指定してExporterをテスト
curl -s "http://localhost:9221/pve?target=192.168.1.10" | grep pve_up

実行結果としてpve_up 1が返ってくれば、ExporterとProxmox APIの連携は成功です。

ステップ3：Prometheusでのスクレイプターゲット設定

Proxmox VE Exporterは、Blackbox Exporterと同様のクエリプロキシ方式で動作します。prometheus.ymlを開き、以下の設定を追加します。

scrape_configs:
  - job_name: 'proxmox-ve'
    scrape_interval: 20s
    scrape_timeout: 15s
    metrics_path: /pve
    static_configs:
      - targets:
          - '192.168.1.10:8006'  # Node pve-01のIP
          - '192.168.1.11:8006'  # Node pve-02のIP
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: '192.168.1.200:9221'  # Exporterを実行しているホストのIP

Prometheusの設定をリロードします。

curl -X POST http://localhost:9090/-/reload

Proxmox監視における実践ノウハウ

1. ダッシュボードに必須の主要PromQLクエリ

仮想マシンの実メモリ使用率（%）： 正確なメモリメトリクスを取得するには、VM内にqemu-guest-agentをインストールしておく必要があります。
```
(pve_guest_memory_used_bytes / pve_guest_memory_size_bytes) * 100
```
仮想マシンのクラッシュまたは予期せぬシャットダウンの検知：
```
pve_guest_info{type="qemu"} == 0
```
ストレージ安全容量逼迫アラート（使用率85%超）：
```
(pve_storage_used_bytes / pve_storage_size_bytes) * 100 > 85
```

2. 適切なスクレイプ間隔（Scrape Interval）の調整

毎回のスクレイプ処理で、Exporterはクラスタに対して多数のAPIクエリを発行します。50台以上のVMが稼働する環境でscrape_interval: 5sのように短すぎる間隔を設定すると、pvedaemonプロセスのCPU使用率が高止まりする原因になります。スクレイプ間隔は15s〜30s程度に設定するのが推奨されます。この範囲であれば、障害検知の即時性を維持しつつ、ホストAPIへの負荷を安全なレベルに抑えられます。

3. ディスクI/O Wait（iowait）の常時監視

仮想化基盤において、CPUが致命的なボトルネックになるケースは稀であり、真のボトルネックは大半がディスクI/Oに起因します。複数のVMが一斉に大量書き込みを行うと、物理ノードのiowaitが急上昇します。pve_storage_*メトリクスやI/O遅延を注視することで、ドライブの劣化やZFSプールのパフォーマンス低下を、クラスタ全体が機能不全に陥る前に早期発見できます。