「サーバーがなんとなく重い気がする」── この曖昧な不安を，数字とグラフで明確にするのがメトリクス監視だ．CPU・メモリ・ディスク・トラフィックの推移を可視化すれば，問題の予兆も原因も見える．

その定番がPrometheus(メトリクス収集)＋Grafana(可視化)の組み合わせだ．これをVPSに立てれば，サーバーの状態を時系列のグラフで把握でき，異常時にアラートも飛ばせる．

この記事は，VPSの状態を可視化したい個人開発者，監視を本格化したいエンジニアに向けている．Prometheusの仕組みから，メトリクス収集，Grafanaでの可視化，アラートまでを実践的に解説する．

読み終えたとき，あなたは自分のサーバーの状態をグラフで把握し，「なんとなく」を「数字」で語れるようになっている．

なぜメトリクス監視が要るのか

外形監視(死活監視)は「落ちたか」を教えてくれるが(監視の記事参照)，「なぜ落ちたか」「落ちそうか」は分からない．メトリクス監視は，リソースの推移を記録し，原因と予兆を見せる．

たとえば「メモリが徐々に増えてOOMで落ちた」「ディスクが満杯に近づいている」「特定の時間だけCPUが張り付く」──こうしたパターンは，時系列のグラフを見て初めて分かる．

勘や記憶に頼った運用は，問題を後手に回す．メトリクスがあれば，「先週と比べてメモリ使用量が増えている」と気づき，障害になる前に手を打てる．

「なんとなく重い」を「いつ・何が・どれだけ」という数字に変えること── それがメトリクス監視の価値だ．

Prometheusの仕組み ― pull型のメトリクス収集

Prometheusは「pull型」のメトリクス収集システムだ．監視対象が公開するメトリクス(数値)を，Prometheusが定期的に取りに行く(scrape)．集めたデータは時系列DBに蓄積される．

監視対象は「exporter」と呼ばれる小さなプログラムでメトリクスを公開する．サーバーのCPU/メモリ等ならnode_exporter，アプリ独自の数値ならアプリ自身が公開する．

node_exporter ― サーバーメトリクスを公開する

まずnode_exporterを監視対象のVPSで動かす．これがCPU・メモリ・ディスク・ネットワークなどのサーバーメトリクスを公開する．

node_exporterの起動(compose例)

services:
  node-exporter:
    image: prom/node-exporter
    restart: always
    ports:
      - "127.0.0.1:9100:9100"   # localhostのみ(外部公開しない)
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro

node_exporterは9100番でメトリクスを公開する．外部公開せずlocalhostバインドし，Prometheusから内部的にscrapeさせる(同じVPS/内部ネットワーク内)．これでサーバーの状態が数値化される．

Prometheus本体 ― scrape設定

Prometheus本体を立て，「どの対象を・どの間隔で取りに行くか」を設定する．node_exporterを収集対象に指定する．

prometheus.yml

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

scrape_intervalでデータ収集の間隔を決める(15秒程度が一般的)．targetsに監視対象を列挙する．複数のVPSやアプリを監視するなら，ここに追加していく．Prometheus自体は9090番でWeb UIを持ち，収集状況やクエリを確認できる(これも外部公開は避ける)．

Grafana ― メトリクスを美しく可視化する

Grafanaは，Prometheusが集めたデータをグラフ・ダッシュボードで可視化するツールだ．美しいダッシュボードで，サーバーの状態が一目で分かる．

Grafanaの起動(compose例)

services:
  grafana:
    image: grafana/grafana
    restart: always
    ports:
      - "127.0.0.1:3000:3000"   # localhost,前段Nginxで認証付き公開
    volumes:
      - grafana-data:/var/lib/grafana
volumes:
  grafana-data:

Grafanaを起動したら，データソースにPrometheusを登録し，ダッシュボードを作る．node_exporter向けの既製ダッシュボード(コミュニティ製のテンプレート)をインポートすれば，CPU・メモリ・ディスク・ネットワークのグラフが一発で揃う．自分で1から作る必要はない．

アラートルール ― 異常を自動で知らせる

メトリクスを見るだけでなく，閾値を超えたら通知させる．Prometheusのアラートルールや，Grafanaのアラート機能で設定できる(監視の記事のアラート設計も参照)．

Prometheusアラートルールの例

groups:
  - name: node
    rules:
      - alert: DiskAlmostFull
        expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.15
        for: 5m
        labels: { severity: warning }
        annotations:
          summary: "ディスク残量が15%未満"
      - alert: HighMemory
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.9
        for: 5m

アラートは「本当に対応が要るものだけ」に絞る(監視の記事のアラート疲れ参照)．ディスク残量・メモリ逼迫・CPU高止まりなど，放置すると障害になるものを通知する．通知先はDiscord/Slack等，必ず気づく経路に．for: 5mで「5分間継続したら」とすると，一瞬のスパイクでの誤報を防げる．

個人開発での現実的な構成 ― 過剰にしない

Prometheus＋Grafanaは強力だが，それ自体がリソースを消費する．個人開発では「監視のために大きなコストをかける」本末転倒を避け，身の丈に合った構成にする．

  1. 監視対象が1台なら：同じVPSにPrometheus＋Grafana＋node_exporterを同居させて十分．
  2. 複数台なら：監視専用の小さなVPSを1台立て，各サーバーのexporterを集約する．
  3. もっと手軽に済ませたいなら：まず軽量なUptime Kuma(監視の記事参照)で死活監視から始め，必要を感じたらPrometheusへ進む．

重要なのは「監視のための監視」にしないことだ．まず本当に見たいメトリクス(CPU・メモリ・ディスク)から始め，徐々に広げる．Grafana・Prometheus自体も外部公開せず，前段のNginxで認証をかけて限定公開する(リバースプロキシ記事参照)．監視基盤自体のセキュリティも忘れない．

補論：監視基盤は「リソースに余裕のあるVPS」に置く

Prometheusは時系列データを蓄積し，Grafanaは可視化に，それぞれメモリとディスクを使う．監視基盤を本番アプリと同じVPSに詰め込みすぎると，監視が本番を圧迫しかねない．リソースの余裕か，監視専用VPSが望ましい．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はメモリをスケールアップで増やせ，NVMe SSDで時系列データの書き込み・クエリも高速だ．監視専用に小さなVPSをもう1台立て，本番を外から見張る構成も固定費で手軽に組める．スナップショットで監視基盤の構成変更も安全に試せる．

Grafanaダッシュボードを独自ドメインのサブドメイン(例: metrics.example.com)で限定公開するなら，取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ で取得したドメインを使い，HTTPS＋認証＋IP制限で保護しよう(監視基盤こそ厳重に守る)．

よくある質問(FAQ)

Q1．外形監視とメトリクス監視の違いは？

外形監視は「落ちたか」，メトリクス監視は「なぜ・どれだけ・落ちそうか」を見る．Uptime Kuma等の死活監視に加え，Prometheus＋Grafanaでリソースの推移を可視化すると，原因と予兆が分かる．

Q2．Prometheusのpull型とは？

監視対象が公開するメトリクスを，Prometheusが定期的に取りに行く(scrape)方式だ．対象側はexporter(node_exporter等)でメトリクスを公開するだけでよい．

Q3．個人開発に過剰では？

1台ならまずUptime Kuma等の死活監視で十分なことも多い．リソースの推移を詳しく見たくなったらPrometheus＋Grafanaへ進む．監視のためにコストをかけすぎないバランスが大事だ．

Q4．ダッシュボードは自作する必要がある？

不要だ．node_exporter向けの既製ダッシュボード(コミュニティ製テンプレート)をインポートすれば，主要メトリクスのグラフが一発で揃う．まずはそれを使い，必要に応じてカスタマイズする．

Q5．アラートはどう設計する？

放置すると障害になるもの(ディスク逼迫・メモリ枯渇・CPU高止まり)だけを通知する．for: 5mで継続条件を付け，一瞬のスパイクでの誤報を防ぐ．通知は必ず気づく経路へ(監視の記事のアラート設計参照)．

Q6．監視基盤のセキュリティは？

exporter・Prometheus・Grafanaはすべて外部公開しないのが基本だ．localhostバインドし，Grafanaだけ前段Nginxで認証＋IP制限をかけて限定公開する．監視基盤は内部情報を持つため厳重に守る．

まとめ ― 「なんとなく」を「数字」に変える

Prometheus＋Grafanaは，サーバーのメトリクスを収集・可視化し，「なんとなく重い」を数字とグラフで捉える監視基盤だ．node_exporterでサーバーを監視し，既製ダッシュボードで可視化し，アラートで予兆を掴める．

今日やるべきことは，まず死活監視(Uptime Kuma)から始め，リソースの推移を見たくなったらnode_exporter＋Prometheus＋Grafanaを1台に立てること．既製ダッシュボードなら数十分で動く．

数字で語れる運用は強い．リソースに余裕のあるVPSに監視基盤を置き，サーバーの状態を常に見える化しよう．