2026年7月11日

サーバーのパフォーマンス監視のベストプラクティス（何を測り、どう通知するか）

VPS・クラウド

サーバーのパフォーマンス監視で大切なのは、ツール選びより先に「何を測るか」「どの状態になったら人が動くか」を決めることです。この記事では、WordPressを載せたLinuxサーバー（Nginx／Apache＋PHP-FPM＋MySQL/MariaDB）を例に、監視すべき指標、平常値の取り方、通知の設計、代表的なツールの役割分担を説明します。読み終えると、小規模なVPSでも無理なく続けられる監視の形を組み立てられるようになります。

監視の目的を3つに分ける

監視は、目的によって見る指標も通知の仕方も変わります。最初に次の3つを分けて考えると、設計がぶれにくくなります。

障害の検知: サイトが落ちた、5xxエラーが増えた、ディスクが満杯になりそう、など今すぐ対応が要る状態を知らせる。
原因の切り分け: 遅くなったときに、CPU・メモリ・ディスクI/O・データベースのどこが詰まっているかを後から調べられるように記録を残す。
容量の計画: アクセス増加に対して、いつ頃サーバーの増強が要るかを傾向から判断する。

1は通知が中心、2と3はデータの蓄積とグラフが中心です。すべてを通知にすると通知が多すぎて誰も見なくなるため、「通知するもの」と「記録だけするもの」を分けるのが最初のベストプラクティスです。

何を測るか：リソースとサービスの両面

サーバーのリソース（USEの観点）

リソースごとに「使用率（Utilization）」「飽和（Saturation）」「エラー（Errors）」を見るUSEメソッドという考え方があります。使用率だけでは足りず、待ちが発生しているか（飽和）を見ることで、本当に詰まっている箇所が分かります。

CPU: 使用率に加えて、ロードアベレージとCPUコア数の比、iowait（ディスク待ち）と steal（仮想化基盤側に取られた時間）を見ます。VPSで steal が継続的に高い場合は、同じ物理ホストの混雑が疑われます。
メモリ: 「空きメモリ」ではなく「利用可能メモリ（available）」とスワップの使用量・スワップイン／アウトの頻度を見ます。Linuxは空きメモリをキャッシュに使うので、freeが小さいこと自体は問題ではありません。OOM Killerの発動はカーネルログに残ります。
ディスク: 容量の使用率とinode使用率の両方、さらにI/O待ち時間と使用率を見ます。ログやセッションファイルが大量に溜まると、容量に余裕があってもinodeが尽きることがあります。
ネットワーク: 送受信量、エラーやドロップ、TCP接続数（特にTIME_WAITやESTABLISHEDの急増）を見ます。VPSによっては月間転送量の上限もあります。

サービスとアプリケーション

リソースが正常でもサイトが遅いことはあります。利用者の体感に近い指標を併せて測ります。

外形監視: 外部からURLにアクセスし、ステータスコードと応答時間を測ります。サーバーの内側の監視だけでは、DNSやSSL証明書の期限切れ、ネットワーク経路の問題に気づけません。
Webサーバー: リクエスト数、ステータスコード別の件数（特に5xx）、応答時間。アクセスログに $request_time（Nginx）や %D（Apache）を出力しておくと、遅いURLを後から特定できます。
PHP-FPM: アクティブなプロセス数、待ち行列（listen queue）、max_children に到達した回数。上限に張り付いている場合は、リクエストが待たされています。
データベース: 接続数、スロークエリの件数、バッファプールのヒット率など。スロークエリログを有効にしておくと、遅いページの原因がクエリかどうかを判断できます。
WordPress特有の負荷: WP-Cronの実行、検索ボットの集中、ログインページへの大量アクセスは、急な負荷の原因として頻出します。

まずは手元のコマンドで平常値を知る

監視ツールを入れる前に、平常時の値を把握しておくと、異常の判断基準が作れます。次のコマンドはほとんどのLinuxで使えます（iostat と sar は sysstat パッケージに含まれます）。

uptime                 # ロードアベレージ
vmstat 5 5             # CPU・メモリ・スワップ・I/O待ちを5秒間隔で5回
free -h                # available とスワップ
df -h && df -i         # ディスク容量と inode
iostat -x 5 3          # ディスクごとの使用率・待ち時間
sar -u -r -q           # 過去のCPU・メモリ・キュー（sysstat の収集を有効にしている場合）
journalctl -k | grep -i -E 'out of memory|oom'   # OOM Killer の発動履歴

アクセスが多い時間帯と少ない時間帯の両方で値を控え、「平日昼のCPU使用率は30〜40%程度」のように平常値の幅を記録しておきます。しきい値はこの幅を基準に決めます。

PHP-FPMとNginxの状態は、それぞれのステータス機能で取得できます。外部に公開しないよう、ローカルホストからのみ許可します。

# PHP-FPM のプール設定で pm.status_path = /fpm-status を有効にしたうえで
location = /fpm-status {
    allow 127.0.0.1;
    deny all;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;   # 環境のソケットパスに合わせる
}

location = /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}

ソケットのパスはディストリビューションやPHPのバージョンで異なります。プール設定の listen の値に合わせてください。

通知の設計：少なく、具体的に

通知は「受け取ったら何をするか」が決まっているものだけに絞ります。対応手順のない通知は、やがて無視されるようになります。

継続時間を条件に入れる: CPU使用率が一瞬だけ上限に張り付くのは、正常な動作の範囲内です。「85%超が15分続いたら」のように時間で条件を付けると、誤報が大きく減ります。
残り時間で考える: ディスクは「使用率90%」よりも「今の増え方だと何日で満杯になるか」で判断するほうが、対応の猶予が分かります。
重要度を分ける: サイト停止や5xxの急増はすぐに気づける連絡手段に、容量の警告はメールやチャットに、と通知先を分けます。
復旧通知も送る: 問題が解消したことが分かると、無駄な調査を避けられます。

Prometheusを使う場合のアラートルールの例です（node_exporterの標準的な指標名を使っています）。

groups:
  - name: server-basic
    rules:
      - alert: HighCpuUsage
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "CPU使用率が15分以上85%を超えています"
      - alert: LowMemoryAvailable
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.10
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "利用可能メモリが10%を下回っています"
      - alert: DiskWillFillIn3Days
        expr: predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h], 3 * 24 * 3600) < 0
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "このままだと3日以内にディスクが満杯になる見込みです"

しきい値はあくまで出発点です。平常値の記録と照らし合わせ、誤報が多いものは条件を見直します。

ツールの選び方と役割分担

監視ツールは1つで全部をまかなうより、役割ごとに組み合わせるほうが運用しやすくなります。以下は代表的なもので、機能や提供形態は変わることがあります（2026年10月現在）。

メトリクス収集とグラフ: Prometheus＋node_exporter＋Grafanaの組み合わせが広く使われています。Zabbixはエージェント型で、テンプレートと通知機能が一体になっています。Netdataは導入が手軽で、1台のサーバーを細かく見るのに向いています。
外形監視: Uptime Kumaのようなセルフホスト型や、外部の監視サービスを使います。監視対象と同じサーバーに置くと、サーバーごと止まったときに通知も止まるため、別の場所から監視します。
ログ: アクセスログ・エラーログ・スロークエリログは、Grafana Lokiなどで集約すると、メトリクスのグラフと時間を合わせて調べられます。
クラウドの監視: AWSのCloudWatchなど、クラウド事業者の監視機能はインスタンスの外側から見た値を取れます。メモリやディスク使用率は追加のエージェントが要る場合があります。
WordPressの開発時: Query Monitorプラグインは、ページごとのクエリやフックを調べるのに便利です。常時の監視ではなく、原因の切り分けや開発環境で使う道具として位置づけます。

小規模なサイトなら、「外形監視＋サーバー上のメトリクス収集＋ログ」の3点がそろえば十分に始められます。

監視を続けるための運用

監視の監視: 監視サーバー自体が止まっていないかを、別の仕組みで確認します。外形監視サービスに監視サーバーのURLを登録する方法が手軽です。
データの保存期間: 細かい粒度のデータは短期間、集計したデータは長期間保存すると、容量を抑えつつ傾向を追えます。
変更の記録: プラグインの更新、設定変更、デプロイの日時を残しておくと、グラフの変化と原因を結びつけやすくなります。
定期的な見直し: 月に一度程度、届いた通知を振り返り、不要な通知を削り、見逃した障害がないかを確認します。
WP-Cronの扱い: アクセスごとに実行されるWP-Cronが負荷の山を作る場合、wp-config.php で DISABLE_WP_CRON を true にし、システムのcronから定期実行する方法があります。変更前に、予約投稿やバックアップなどcronに依存する処理が動き続けるかをステージングで確かめます。

まとめ

監視は「障害の検知」「原因の切り分け」「容量の計画」に分け、通知するものと記録だけするものを分けます。
リソースは使用率だけでなく飽和（待ち）とエラーも見ます。メモリはavailable、ディスクはinodeとI/O待ちも対象です。
外形監視・Webサーバー・PHP-FPM・データベースのサービス指標を併せて測ると、利用者の体感に近づきます。
しきい値は平常値の記録から決め、継続時間を条件に入れて誤報を減らします。
監視サーバーは対象と別の場所に置き、監視そのものも監視します。