Webサーバーの監視設計入門｜ディスク・メモリ・CPUで障害を防ぐ方法

「気づいたらサイトが落ちていた」を防ぐために、Webサーバーの3大リソースをどう監視すべきか。実案件での失敗談も交えながら、実践的な監視設計を解説します。

「気づいたら落ちていた」は、もう終わりにしよう

こんな経験はありませんか？

月曜の朝、出社したらサイトが落ちていた。問い合わせフォームも機能せず、週末の注文が全部飛んでいた。

弊社では毎年数件、こういった相談を受けます。共通しているのは「異常に気づいたのがユーザーからの電話」という点です。担当者は何も知らず、サーバーも何も言っていなかった——しかし実際には、障害の予兆は数時間前、あるいは数日前からあったはずです。

監視が適切に機能していれば、多くの場合はユーザーが影響を受ける前に手が打てます。逆に言えば、監視がなければ「運良く気づく」か「最悪の事態になってから気づく」かの二択です。

この記事では、Webサーバーで最低限押さえておくべき3大リソース——ディスク・メモリ・CPU——について、何を・どのしきい値で・どう監視すべきかを、実案件での失敗談も交えながら解説します。

なぜ「3大リソース」なのか——障害の根本原因を知る

Webサーバーの障害原因を大別すると、そのほとんどは以下のいずれかに行き着きます。

ディスクが満杯になった（ログが溜まりすぎ、アップロードファイルが増えすぎ）
メモリが枯渇した（アプリのリーク、キャッシュ設定の誤り）
CPUが張り付いた（重いクエリ、スパイクアクセス、無限ループ）

この3つはいずれも「じわじわと悪化する」という共通点を持ちます。ある日突然ディスクが満杯になるわけではなく、毎日少しずつ増えたログがある日しきい値を超える。この「じわじわ」を捉えるのが監視の本質です。

サーバー・インフラでお困りですか？

障害対応・移行・パフォーマンスチューニングなど、ご相談ください

無料で相談する

各リソースの監視設計——何をどう見るか

1. ディスク監視：「満杯」は静かにやってくる

ディスクが100%に達すると、Webサーバーはログも書けず、セッションも保存できず、即座にサービス不能になります。しかも段階的に警告してくれる仕組みがないため、しきい値ベースの監視が必要です。

推奨しきい値

使用率 70% → 警告（Slack通知など）
使用率 85% → 緊急（電話・SMS通知）

シェルスクリプトで定期チェックする場合の例：

#!/bin/bash
# disk_check.sh — 毎時cronで実行

THRESHOLD_WARN=70
THRESHOLD_CRIT=85
SLACK_WEBHOOK="https://hooks.slack.com/services/xxx/yyy/zzz"

df -H | grep -vE '^Filesystem|tmpfs|cdrom' | awk '{ print $5 " " $1 }' | while read output; do
  usage=$(echo $output | awk '{print $1}' | sed 's/%//')
  partition=$(echo $output | awk '{print $2}')

  if [ $usage -ge $THRESHOLD_CRIT ]; then
    curl -s -X POST $SLACK_WEBHOOK \
      -H 'Content-type: application/json' \
      --data "{\"text\":\"🚨 緊急: $partition のディスク使用率が ${usage}% に達しました\"}"
  elif [ $usage -ge $THRESHOLD_WARN ]; then
    curl -s -X POST $SLACK_WEBHOOK \
      -H 'Content-type: application/json' \
      --data "{\"text\":\"⚠️ 警告: $partition のディスク使用率が ${usage}% です\"}"
  fi
done

あるクライアントでの実例： ECサイトを運営する神奈川の小売業者さんで、商品画像のアップロードが毎月数GBずつ増加していました。監視を入れていなかったため、ある日ディスクが満杯になりCart機能が完全停止。週末の売上が12時間分吹き飛びました。監視導入後は70%で通知が来るようになり、定期的なアーカイブ処理を行う運用が確立できています。

2. メモリ監視：スワップが「予兆」を教えてくれる

メモリ監視で多くの人がやりがちな失敗が、「メモリ使用率だけを見ている」ことです。Linuxはキャッシュに積極的にメモリを使うため、使用率が高くても必ずしも問題ではありません。本当に注目すべきはスワップの使用量です。

スワップが発生し始めたら、それはメモリが実質的に枯渇しかけているサインです。

#!/bin/bash
# memory_check.sh

SWAP_THRESHOLD=30  # スワップ使用率(%)のしきい値
SLACK_WEBHOOK="https://hooks.slack.com/services/xxx/yyy/zzz"

# スワップ使用率を計算
SWAP_TOTAL=$(free | grep Swap | awk '{print $2}')
SWAP_USED=$(free | grep Swap | awk '{print $3}')

if [ $SWAP_TOTAL -gt 0 ]; then
  SWAP_PERCENT=$(( SWAP_USED * 100 / SWAP_TOTAL ))

  if [ $SWAP_PERCENT -ge $SWAP_THRESHOLD ]; then
    # メモリを最も消費しているプロセスTOP5を取得
    TOP_PROCS=$(ps aux --sort=-%mem | awk 'NR<=6 {printf "%s(%s%%)\n", $11, $4}')
    curl -s -X POST $SLACK_WEBHOOK \
      -H 'Content-type: application/json' \
      --data "{\"text\":\"⚠️ スワップ使用率: ${SWAP_PERCENT}%\n主要プロセス:\n${TOP_PROCS}\"}"
  fi
fi

# 実メモリの使用率も確認（available基準）
MEM_AVAILABLE=$(free | grep Mem | awk '{print $7}')
MEM_TOTAL=$(free | grep Mem | awk '{print $2}')
MEM_AVAIL_PERCENT=$(( MEM_AVAILABLE * 100 / MEM_TOTAL ))

if [ $MEM_AVAIL_PERCENT -le 10 ]; then
  curl -s -X POST $SLACK_WEBHOOK \
    -H 'Content-type: application/json' \
    --data "{\"text\":\"🚨 空きメモリが ${MEM_AVAIL_PERCENT}% を下回りました\"}"  
fi

LaravelやWordPressを動かしているサーバーでは、PHPのメモリリークやOPcacheの設定ミスが原因でゆっくりとメモリが食われていくケースが特に多いです。/etc/php.ini の memory_limit と合わせて確認しておきましょう。

3. CPU監視：瞬間値より「持続時間」を見よ

CPUは瞬間的に100%になっても問題ありません。問題なのは高負荷が続く時間です。5分・15分のロードアベレージを指標にするのが実践的です。

#!/bin/bash
# cpu_check.sh

CPU_CORES=$(nproc)
LOAD_WARN=$(echo "$CPU_CORES * 0.8" | bc)  # コア数の80%
LOAD_CRIT=$(echo "$CPU_CORES * 1.5" | bc)  # コア数の150%
SLACK_WEBHOOK="https://hooks.slack.com/services/xxx/yyy/zzz"

# 15分ロードアベレージ
LOAD_15=$(uptime | awk -F'load average:' '{print $2}' | awk -F',' '{print $3}' | xargs)

if (( $(echo "$LOAD_15 >= $LOAD_CRIT" | bc -l) )); then
  curl -s -X POST $SLACK_WEBHOOK \
    -H 'Content-type: application/json' \
    --data "{\"text\":\"🚨 CPU過負荷: 15分ロードアベレージ ${LOAD_15} (しきい値: ${LOAD_CRIT})\"}"
elif (( $(echo "$LOAD_15 >= $LOAD_WARN" | bc -l) )); then
  curl -s -X POST $SLACK_WEBHOOK \
    -H 'Content-type: application/json' \
    --data "{\"text\":\"⚠️ CPU高負荷: 15分ロードアベレージ ${LOAD_15}\"}"
fi

よくある失敗パターンと対処法

しきい値を低く設定しすぎると、日常的に通知が飛びすぎて誰も見なくなります。弊社が経験した案件でも、CPU70%でアラートを設定したところ、アクセスが集中する平日昼間に毎日50件以上通知が来て、2週間後には全員が通知をミュートしていた、という事態がありました。

対処法：まず1〜2週間ノーアラートで稼働させてベースラインを把握してから、しきい値を決めましょう。「普段は最大でもここまで」という実績値の120〜150%を警告ラインにするのが現実的です。

1時間おきのチェックでは、ディスクが急速に埋まるケース（大量ファイルアップロード、ログ爆発）に間に合いません。基本は5〜10分間隔を推奨します。

対処法：`*/5 * * * * /path/to/check.sh` のようにcrontabを設定。ただしスクリプト自体が重い場合は逆効果なので、軽量に書くことが前提です。

通知先がメールだけで、担当者が休日だったため気づかなかった——これは非常によくあるパターンです。

対処法：Slackへの通知を基本とし、85%や緊急しきい値はSMSや電話通知（PagerDuty、OpsGenie等）と組み合わせるのが理想。少なくとも通知先を複数人にすること。

ZabbixやDatadogを導入したのに、アラートのチューニングや定期的な見直しをせず、1年後には「何かアラート来てたけど何のことかわからなくて…」という状態になるケースも多いです。

対処法：監視設定は3ヶ月に1回見直す運用ルールを設けましょう。アラートが発生したら必ず原因を記録し、しきい値が適切だったか振り返る文化が重要です。

監視ツール選定の考え方

自前のシェルスクリプト＋cronは導入コストゼロで始められますが、可視化や複数サーバー管理には限界があります。規模や予算に応じた選択肢を整理しておきましょう。

方法	導入コスト	おすすめ対象
シェルスクリプト＋cron	無料	小規模・1台構成
Zabbix（OSSツール）	サーバー費用のみ	中規模・自社管理
Datadog	$15〜/ホスト/月	中〜大規模・クラウド中心
CloudWatch（AWS）	従量課金	AWS環境一択の場合