【2026年】Grafana+Prometheus PC監視ダッシュボード構築ガイド

このように、両者は明確に役割が分かれており、連携して動作します。Prometheus が「脳」としてデータを処理し、Grafana が「顔」として人間が見やすい形で情報を提示すると考えると分かりやすくなります。また、近年では Prometheus 単体でのアラート通知機能に加え、専用のアラートマネージャーである Alertmanager を導入することで、Discord や Slack などの外部ツールへ通知を送る柔軟性が強化されています。

事前準備と環境構築：Docker と OS の選定

監視基盤を構築する前に、運用環境のハードウェアやソフトウェア要件を満たす必要があります。特に Docker コンテナを効率的に動かすための OS とリソース選びが重要です。2026 年現在、Windows、Linux、macOS など様々な OS がありますが、サーバー用途や長期的な安定性を考慮すると、Linux ディストリビューションまたは Windows Server が推奨されます。

まず、ホストマシン（監視を行う PC）自体のスペックについて検討します。監視用の Prometheus と Grafana を動かすために、最低限必要なリソースは比較的少ないですが、収集するデータ量や保持期間によって変化します。例えば、10 台程度の PC を監視する場合でも、メモリ 4GB、CPU コア数 2 以上あれば十分稼働可能です。ただし、GPU 監視や高度なログ分析を同時に行う場合は、より多くのリソースが必要となるため、余裕を持ったスペック選定が求められます。

Docker の導入は必須となります。以前は Docker Compose v1 が主流でしたが、現在ではコマンド単体で呼べる docker compose（v2 以降）が標準となっています。これはバックグラウンドコンテナ管理やネットワーク設定が強化されており、運用が容易になっています。OS ごとのインストール手順も異なりますので、以下の表を参考に適切な環境を構築してください。

Docker をインストールした後、パーミッション設定やネットワーク設定を適切に行う必要があります。特に、Windows の場合は Docker Desktop が Windows Subsystem for Linux (WSL2) を利用して動作することが多く、ディスク容量の確保やメモリ割り当ての設定に注意が必要です。また、Linux においては、ユーザーが docker コマンドを実行できるグループへの追加（sudo usermod -aG docker $USER）が必須となります。

さらに、監視対象となる PC とホストマシンの間のネットワーク接続も確認します。通常、ブリッジネットワークを介して通信しますが、Windows の場合はファイアウォール設定によりポート開放が必要になる場合があります。監視用のコンテナ内で外部の PC にアクセスする際にも、ホストの DNS 解決やルーティングが正しく機能しているか確認する必要があります。これらの前提条件を満たした上で、本格的な Docker Compose の構成に移ることができます。

Docker Compose による監視基盤の構築方法

実際の監視システムを動かすためには、Docker Compose を用いて複数のコンテナを定義し、連携させる設定ファイルを作成します。これは YAML 形式で記述され、各サービスのイメージ、ポート割り当て、環境変数、マウントパスなどを指定します。この構成ファイルを正しく作成することで、一度のコマンドで Prometheus、Grafana、Alertmanager を同時に起動・停止できます。

まず、プロジェクトディレクトリを作成し、その中に docker-compose.yml ファイルを配置します。このファイル内では、Prometheus のイメージ（例：prom/prometheus:v3.0.1）と Grafana のイメージ（例：grafana/grafana:latest）を指定します。2026 年時点では、セキュリティ強化のため非ルートユーザーで動作する設定や、データ永続化のためのボリューム管理が標準的に行われています。

Prometheus の設定においては、prometheus.yml でどのターゲット（PC やサーバー）からメトリクスを取得するかを定義する必要があります。これは Service Discovery（サービスディスカバリー）と呼ばれる機能であり、固定 IP 指定だけでなく、DNS レコードや Consul などのキー値ストアを活用して動的に管理することも可能です。ここでは初心者の方にも扱いやすい静的な設定例を示します。また、データ保存先は Docker ボリュームを使用し、コンテナを再起動してもデータが消失しないように設定します。

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:v3.0.1
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/usr/share/prometheus/console_libraries'
      - '--web.console.templates=/usr/share/prometheus/consoles'
    ports:
      - "9090:9090"
    networks:
      - monitoring-network

  grafana:
    image: grafana/grafana:v12.0.0
    container_name: grafana
    volumes:
      - grafana_data:/var/lib/grafana
      - ./provisioning/datasources.yml:/etc/grafana/provisioning/datasources/datasources.yml
    ports:
      - "3000:3000"
    depends_on:
      - prometheus
    networks:
      - monitoring-network

volumes:
  prometheus_data:
  grafana_data:

networks:
  monitoring-network:

この構成では、prometheus.yml と provisioning/datasources.yml の外部ファイルもマウントされています。これにより、コンテナ内の設定ファイルを直接編集しなくてもホスト側のファイルを書き換えるだけで反映されます。また、depends_on を指定することで、Grafana が Prometheus に対して接続を試みる前に Prometheus コンテナが起動するのを待機させます。

ネットワーク設定も重要です。monitoring-network という独自のブリッジネットワークを作成しており、各コンテナはこのネットワーク内で相互に通信できます。外部からはポート 9090（Prometheus）と 3000（Grafana）のみが開放され、内部の通信はセキュリティ面で隔離されています。このように、最小限の権限で動作する設計により、システム全体の安全性を高めることができます。

Windows PC からのメトリクス収集：windows_exporter の詳解

Windows 環境を監視するには、専用の Exporter が必要です。最も一般的に使用されるのは prometheus-community/windows_exporter です。これは Microsoft のパフォーマンスカウンター（Performance Counters）やレジストリ情報を読み取り、Prometheus が認識できる形式で提供するエージェントプログラムです。2026 年時点では、Windows Server 2025 や Windows 11 の最新機能にも対応しており、高精度な測定が可能となっています。

windows_exporter を導入する際、最も注意すべき点は権限とポート開放です。このエクスポートラーはシステム情報を取得するためには高い権限を必要とします。通常は「管理者として実行」して起動するか、サービスとして登録する必要があります。また、デフォルトのポート 9182 がファイアウォールによってブロックされていることが多いため、TCP ポートの開放設定が必須となります。

具体的には、PowerShell を使用して以下のコマンドを実行することで、コンテナとしての起動やサービスの登録が可能です。ただし、Windows の場合はホストネットワークモード（--network host）を使用するとポート競合を避けやすい反面、セキュリティリスクが高まるため、ブリッジネットワークで適切にポートマッピングを行うことが推奨されます。

# コンテナ起動例 (管理者権限が必要)
docker run -d --name windows_exporter `
  -p 9182:9182 `
  --net="host" `
  prom/prometheus/windows-exporter:0.35.0

この設定では --net="host" を使用していますが、これは Docker のネットワークスタックをスキップし、ホストのネットワークインターフェースを直接使用することを意味します。これにより、ポートマッピングの手間が省け、Windows 特有の NAT ルールによる通信障害を防げます。ただし、他のコンテナと競合する可能性があるため、使用しない場合は -p 9182:9182 のポート指定のみで十分です。

収集できるメトリクスには、CPU コアごとの利用率、メモリの空き容量、ディスクの読み書き速度、プロセスの状態などが含まれます。特に温度情報は、特定のハードウェアやセンサードライバーがサポートしている場合に取得可能です。一部の PC では BIOS 設定で温度情報のアクセス権限を制限している場合があり、その場合は Exporter がエラーを返すことがあります。この場合は、Windows のレジストリ編集やデバイスマネージャーの設定を見直す必要があります。

また、windows_exporter はモジュール式になっており、必要な機能のみを有効化できます。例えば、メモリ監視だけを行いたい場合でも CPU モジュールを無効にするなどの設定が可能です。これにより、監視対象の PC への負荷を最小限に抑えることができます。以下は主要なメトリクスと取得可能な情報の一覧です。

このように、Windows PC の状態を多角的に捉えることで、システム全体の健全性を維持することが可能になります。ただし、温度センサーの精度はハードウェアに依存するため、必ずしもすべての PC で正確な数値が表示されるわけではありません。その場合は、BIOS 内の設定やサードパーティ製ツールとの連携を検討する必要があります。

Linux サーバー監視の実装と最適化：node_exporter の活用

Linux 環境では prometheus/node_exporter がデファクトスタンダードとなっています。これはシステムリソース（CPU、メモリ、ディスク、ネットワークなど）を標準的な UNIX コマンドや /proc ファイルシステムから読み取り、メトリクスとして提供します。Windows と異なり、Root ユーザーでの実行や特定の権限設定が求められる場合があるため、Docker コンテナ内で適切に権限を付与する必要があります。

Linux における監視の最大の特徴は、ファイルシステムの監視が容易である点です。node_exporter を使用することで、ディスクの使用率、I/O スケジューラの状態、ファイルシステムタイプ（ext4, xfs など）の情報を取得できます。また、ネットワークインターフェースごとのトラフィック量やエラー発生数も詳細に把握可能です。これはサーバー運用において非常に重要な情報であり、ボトルネック箇所の特定に役立ちます。

起動時には、--collector.textfile.directory オプションを使用して、カスタムのメトリクスファイルを読み込ませることもできます。例えば、特定のアプリケーションの状態をテキストファイルとして保存し、それを Exporter が読み取ることで、独自の指標を監視システムに取り込むことが可能です。これにより、Linux サーバーの運用状況をさらに細かく制御できるようになります。

# node_exporter の起動例 (Docker)
docker run -d --name=node_exporter \
  --net=host \
  --privileged \
  prom/node-exporter:latest \
  --collector.filesystem.ignored-mount-points="^/(sys|proc|dev|host|etc)($|/)"

このコマンドでは、--privileged フラグを使用してコンテナに高い権限を与えています。これにより、システム情報の取得が許可されます。ただし、セキュリティの観点からは、可能であれば CAP_SYS_ADMIN などの特定のCapability のみを付与する方が望ましいです。また、/sys や /proc などの仮想ファイルシステムのマウントを除外することで、不要な監視データをフィルタリングしています。

Linux サーバーでは、カーネルパラメータの変更やコンテナ環境（Docker inside Docker）の影響も考慮する必要があります。例えば、Kubernetes ノードとして運用されている場合、ノードの負荷が Pod のスケジューリングに影響する可能性があるため、より高い粒度での監視が必要になります。また、システムログ（syslog, journalctl）との連携を行うことで、エラー発生時の背景情報も同時に取得できるような構成を検討すると、トラブルシューティングの効率が高まります。

GPU とストレージの深層監視：nvidia_gpu_exporter と SNMP

ハイエンドな PC 自作や AI 学習用途では、GPU の状態監視が極めて重要です。NVIDIA GPU を使用する場合、dcgm-exporter（Data Center GPU Manager Exporter）または nvidia_gpu_exporter が推奨されます。これらは NVIDIA の NVML（NVIDIA Management Library）を介して、GPU コア温度、メモリ使用量、電力消費、ファン回転数などを取得します。

DCGM Exporter はデータセンター向けに設計されていますが、ワークステーション環境でも利用可能です。2026 年時点では、CUDA ツールキットとの統合が強化されており、最新の RTX シリーズや A シリーズ GPU の詳細なメトリクスを正確に反映できるようになっています。特に電力管理（Power Management）の情報を取得できるため、発熱制御や省電力設定の影響も確認可能です。

# DCGM Exporter 構成例 (Docker)
services:
  exporter:
    image: nvidia/dcgm-exporter:v3.3.6
    container_name: dcgm_exporter
    devices:
      - /usr/lib/x86_64-linux-gnu/nvidia-container-runtime/ldconfig:/etc/ld.so.conf.d/dcgm.conf
    ports:
      - "9400:9400"
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=all

この設定では、デバイスマネージャーとドライバーライブラリをコンテナ内で利用できるようにしています。NVIDIA_VISIBLE_DEVICES=all により、すべての GPU を監視対象にします。また、SNMP（Simple Network Management Protocol）を用いた NAS やルーターの監視も重要です。これらは snmp_exporter を使用し、ネットワーク機器の稼働状況や帯域使用率を把握します。

SNMP はネットワーク管理のための標準プロトコルであり、MIB（Management Information Base）ファイルを使用してデバイスの情報を取得します。家庭用ルーターや NAS には SNMP サーバー機能が含まれていることが多く、コミュニティ文字列を設定することで監視が可能になります。ただし、セキュリティ上の理由から v2c よりも認証機能を備えた v3 を使用することが推奨されます。

SNMP 監視では、MIB ファイルの正規化や OID（Object Identifier）の取得設定が複雑になる場合があります。しかし、Grafana と連携する際にプレースホルダーを適切に設定することで、複雑な設定を簡略化できます。また、ネットワーク機器の場合、接続ケーブルの断線やルータ再起動の影響も監視対象となるため、SNMP トラップ（Trap）機能を活用したイベント通知の設定も検討価値があります。

ダッシュボード設計：可視化のための PromQL とパネル構成

収集したデータを人間が見やすい形にするのが Grafana の役割です。ダッシュボード作成では、単にグラフを並べるだけでなく、ユーザーの視点に立った設計が必要です。具体的には、CPU 使用率、温度推移、メモリ、ディスク I/O、ネットワーク帯域といった重要なパラメータをパネル化し、時系列データとして可視化します。

PromQL（Prometheus Query Language）は、Grafana でグラフを描画する際に使用するクエリ言語です。例えば、「すべてのサーバーの CPU 使用率が 80% を超えた場合」のような条件を設定するには、rate(cpu_usage_seconds_total[5m]) > 0.8 のような式を記述します。このように、時間経過に対する変化率や統計関数（avg, max, sum）を活用して、複雑な分析も可能です。

パネルの配置には「ヒートマップ」と「時系列グラフ」を使い分けます。ヒートマップは、長時間のデータ傾向を色で表現するもので、温度がいつ上昇したかなどを一瞬で把握できます。一方、時系列グラフは、特定の時刻の詳細な状態を確認するのに適しています。また、変数（Variables）を使用することで、ダッシュボード上で監視対象を切り替えることができます。

例えば、温度推移を監視するパネルでは、過去 7 日間の日ごとの平均値を表示し、特定の時間帯に急激な上昇があった場合に色を変える設定を行います。また、複数の PC を比較表示する際には、テンプレート変数 $host を使用して、「どの PC のデータを見るか」をユーザーが選択できるようにします。これにより、1 つのダッシュボードで複数環境を管理することが可能になります。

可視化においては、配色やフォントサイズも重要です。特に温度のようなリスク要因については、赤色系の色使いを意識的に使うことで、ユーザーに緊急度の高さを直感的に伝えます。また、モバイル端末からのアクセスも考慮し、パネルの配置が縦長になるよう工夫します。2026 年現在では、Grafana のダッシュボードエディタが改良されており、ドラッグアンドドロップによるレイアウト調整がより容易になっています。

アラート通知システム：Discord と Slack を活用した連携

監視の最終段階は、異常を検知した際の通知です。Prometheus 単体ではアラート判定を行いますが、実際の通知は Alertmanager が担当します。Alertmanager は Prometheus から受信したアラートを受け取り、適切なチャネル（メール、Slack、Discord など）へ転送する役割を担います。

Discord や Slack と連携するには、それぞれの Webhook URL を取得し、Alertmanager の設定ファイルに記述する必要があります。これにより、高温検知や CPU 使用率の閾値超過時に、リアルタイムで通知を受け取ることができます。特に Discord は自作 PC メンバーコミュニティでの利用が多く、チャンネルごとの通知が可能で便利です。

# Alertmanager 設定例 (alertmanager.yml)
route:
  receiver: 'discord-alerts'
  group_by: ['alertname', 'severity']
  group_wait: 10s
  group_interval: 5m
  repeat_interval: 1h

receivers:
- name: 'discord-alerts'
  discord_configs:
  - api_url: 'https://discord.com/api/webhooks/...'
    title: '{{ .GroupLabels.alertname }}'
    text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'

この設定では、アラートがグループ化される際のプロパティ（alertname, severity）や、待機時間（group_wait）、再送間隔などが定義されています。api_url には、Discord の Webhook URL を貼り付けます。また、title や text には、アラートの詳細情報をテンプレート言語で埋め込みます。これにより、通知メッセージに具体的な PC 名やエラー内容を含めることができます。

Slack との連携も同様の手順で行います。ただし、Slack の Webhook URL はチャンネルごとに発行されるため、重要なアラートは特定のチャンネルへ送るなどの設定が可能です。また、複数のチャネルへの同時通知（例えば、Discord には開発チーム、Slack には運営管理者）といった柔軟な構成も可能となっています。

アラート設定では、閾値の調整も重要です。例えば、「CPU 温度が 80 度を超えた場合」ではなく「5 分間連続して 80 度を超えた場合」のように条件を厳しくすることで、一時的なスパイクによる誤通知を防げます。また、メンテナンス期間中にアラートを抑制する機能（Inhibition）も活用し、意図的なシャットダウン時に不要な通知を送らないように設定します。

データ保持期間とスケーリング戦略：長期的な運用の観点

監視システムを長く運用するには、データ保存容量の管理が不可欠です。Prometheus の TSDB は時系列データを圧縮して保存しますが、データ量が増大するとストレージ容量やクエリ速度に影響が出ます。そのため、適切なデータ保持期間とスケーリング戦略を策定する必要があります。

通常、直近の数日間（例：15 日）の詳細なデータを保持し、それ以前のデータは集計して長期保存するという戦略が一般的です。これは「ダウンサンプリング」と呼ばれる技術で、例えば 15 分ごとの平均値のみを保存することで、容量を削減しつつトレンド分析を維持します。Grafana には、クエリ時に異なる時間粒度を指定する機能も用意されています。

ストレージの拡張については、ローカルディスクへの保存だけでなく、S3 や Google Cloud Storage などのオブジェクトストレージを利用する方法もあります。これにより、Prometheus のデータ永続性を高めることができます。特に、10,000 時間以上の長期データを保持する場合や、複数環境を一元管理する際には、クラウドストレージの活用が有効です。

また、システムのスケーリングについても考慮します。監視対象の PC 数が増加し、メトリクス収集負荷が高まる場合は、Prometheus をクラスタ化（Sharding）したり、Thanos や Cortex といった分散 TSDB と連携して拡張性を高める必要があります。ただし、自作 PC ユーザー向けには、単一 Prometheus インスタンスでの運用が基本であり、複雑な構成は避けるべきです。

データ保持期間の設定は prometheus.yml 内の retention パラメータで行います。例えば、--storage.tsdb.retention.time=30d と設定することで、30 日間のデータを保持します。これにより、ディスク容量の予測が可能となり、ストレージ不足によるシステム停止を防げます。

よくある質問（FAQ）

Q1: Grafana と Prometheus の接続ができない場合、どうすればよいですか？ A. まず、Grafana のデータソース設定で Prometheus の URL が正しいか確認してください。http://localhost:9090 ではなく、コンテナ名やネットワーク設定に基づいたアドレス（例：http://prometheus:9090）を使用している必要があります。また、両者のネットワークが同じブリッジネットワークに属しているかも確認してください。

Q2: Windows の温度情報が取得できないのはなぜですか？ A. 多くの PC では BIOS やセンサードライバーの制限により、外部からの温度アクセスを許可していない可能性があります。メーカー独自の管理ツール（ Armoury Crate, MSI Dragon Center など）が有効な場合、その設定で温度情報の公開を許可する必要があるかもしれません。また、windows_exporter のバージョン更新が必要です。

Q3: Prometheus のデータ保存容量がいっぱいになりました。 A. prometheus.yml 内の --storage.tsdb.retention.time パラメータを確認し、保持期間を短縮してください（例：14d）。また、古いデータのアーカイブや Downsampling を実施することで、ディスク使用量を削減できます。

Q4: Docker コンテナ内で Alertmanager が起動しません。 A. ポート衝突が起きている可能性があります。docker-compose.yml 内のポートマッピングを確認し、ホスト側のポート（例：9093）が空いているか確認してください。また、コンテナのログを docker logs alertmanager で確認すると具体的なエラーが表示されます。

Q5: GPU の温度が高すぎる場合の対策は？ A. ファン回転数を上げたり、PC 内部の通気を改善することが第一です。Grafana 上でダッシュボードのパラメータを変更し、ファン制御を自動に行うスクリプトを実装することも可能です。ただし、ハードウェア的な問題（グリス劣化など）の場合は物理的なメンテナンスが必要です。

Q6: SNMP エクスポートラーの設定でエラーが出ます。 A. ルーターや NAS の設定を確認してください。SNMP v2c のコミュニティ文字列が一致しているか、または v3 で認証設定が必要になっていないか確認します。また、MIB ファイルのインストール状態もチェックしてください。

Q7: 複数の PC を一度に監視したいのですが、方法は？ A. prometheus.yml の scrape_configs セクションでターゲットを追加し、それぞれの IP アドレスを指定します。テンプレート変数 $instance を使用して、Grafana で簡単に切り替えられるダッシュボードを作成すると便利です。

Q8: Grafana のダッシュボードをバックアップする方法は？ A. grafana.ini 設定ファイルやプロビジョニングフォルダ（provisioning）をコピーすることで構成情報を保存できます。また、Grafana の CLI ツール（grafana-cli）を使用してダッシュボードの JSON をエクスポートすることも可能です。

Q9: アラート通知が頻繁に来ます。 A. 閾値設定を見直してください。一時的なスパイクを検知しないよう、for 時間（例：5m）を追加することで、一定時間連続して条件を満たす場合にのみアラートを発動させられます。

Q10: 初心者ですが、監視システムは必須ですか？ A. 必ずしも必須ではありませんが、PC の寿命を延ばし、トラブルを未然に防ぐために非常に有効です。最初は CPU 温度と使用率のみの簡易なダッシュボードから始めるとよいでしょう。

まとめ

本ガイドでは、Grafana と Prometheus を用いた PC 監視ダッシュボードの構築方法を詳細に解説しました。以下に記事全体の要点をまとめます。

• アーキテクチャ理解: Prometheus がメトリクス収集・保存を担当し、Grafana が可視化を行う役割分担を明確に理解することが重要である。
• 環境構築: Docker と [Docker Compose を使用して、Prometheus、Grafana、Alertmanager を効率的に管理する。
• Exporter の選択: Windows には windows_exporter、Linux には node_exporter、GPU には nvidia_gpu_exporter をそれぞれ適切に選択する。
• ダッシュボード設計: CPU 使用率、温度、メモリ、ディスク I/O、ネットワーク帯域をパネル化し、PromQL で可視化する。
• アラート設定: Alertmanager を活用し、Discord や Slack と連携して異常時に即時通知を受け取る。
• 運用と拡張: データ保持期間やストレージ管理を適切に行い、長期的な運用を安定させる。

これらのポイントを意識することで、2026 年以降も通用する高品質な監視システムを構築できます。PC の状態を常に見守ることは、安全な自作環境維持の鍵となります。

SNMPを使ったホームネットワーク監視の構築ガイド。Grafana/Prometheus/Zabbixでのトラフィック可視化、スイッチ・ルーター・NASの死活監視を解説。