「サーバーは動いているのにサイトが重い」「気づいたらディスクが満杯だった」——死活監視だけでは防げない障害は多い。中小企業が無料ツールで実現すべき5つの監視指標を実案件ベースで解説します。
「サーバーは生きているのに、サイトが死んでいた」
こんな経験はありませんか？
- 「監視ツールからアラートは来ていないのに、お客さんから『サイト繋がらない』と電話があった」
- 「ある朝突然、WordPressの管理画面にログインできなくなった。原因はディスク容量の枯渇だった」
- 「Webサーバーのプロセスは動いているのに、レスポンスが30秒かかっていて誰も気づかなかった」
中小企業のWebサイト運用で、こういった「サーバーは死んでいないのに、実質的にサービスが止まっている」状態は想像以上によく起きます。
原因のほとんどは同じです——**「死活監視（Ping監視）しか設定していなかった」**こと。
Ping監視はサーバーが「生きているか死んでいるか」しか見ません。CPUが100%張り付いていても、ディスクが残り1GBでも、データベースが接続数上限に達していても、Pingは正常に返ってきます。
この記事では、Fivenineがこれまで神奈川・首都圏の中小企業クライアントを支援してきた経験をもとに、本当に監視すべき5つの指標と、無料ツールだけで実現する具体的な設定方法をお伝えします。
なぜ「死活監視だけ」が危ういのか
多くの中小企業では、レンタルサーバーやVPSを契約した際にサービス提供側の死活監視が自動で設定されています。「監視はしてもらっているから大丈夫」と思いがちですが、これは「建物の火災報知器は設置してある。でも水漏れ・ガス漏れのセンサーはない」のと同じ状態です。
Webアプリケーションは多層構造です。Nginxが動いていても、PHP-FPMがクラッシュしていればページは表示されません。PHP-FPMが動いていても、MySQLの接続プールが枯渇していればアプリは応答を返せません。これらはすべて「Ping監視」をすり抜けます。
あるクライアント（神奈川県内のBtoB製造業、Laravelで構築された見積もりフォームを運用）では、毎月末の見積もり集中時期にMySQLのmax_connectionsを超えてしまい、フォーム送信が無言で失敗するという問題が3ヶ月続いていました。サーバー自体は正常稼働しており、死活監視には一切引っかかっていなかったのです。問題を発見したきっかけは「先月送ったはずの問い合わせが届いていない」というクレームでした。
このケースで私たちが最初に実施したのが、死活監視を超えた5つの指標の可視化です。
本当に監視すべき5つの指標
指標① CPU使用率
しきい値の目安：80%超で警告、90%超で緊急
CPUが高負荷になる原因は多岐にわたります。スクレイピングによる不正アクセス、バッチ処理の暴走、WordPressの無限ループプラグイン——原因はさまざまですが、いずれもレスポンス遅延という形でユーザー体験を直撃します。
指標② メモリ使用率
しきい値の目安：85%超で警告
メモリ不足はOOMKiller（Linux のメモリ超過時にプロセスを強制終了する仕組み）を発動させ、突然Nginxや MySQL が落ちる原因になります。死活監視はプロセス停止後にしか検知できませんが、メモリ監視なら手前で気づけます。
指標③ ディスク使用率
しきい値の目安：85%超で警告、90%超で緊急
前述のクライアントと同様のトラブルで最も多いのがこれです。特にログファイルの肥大化とバックアップファイルの蓄積が主な原因です。ディスクが満杯になると、Webサーバーのログ書き込みに失敗し、セッションが保存できなくなり、最終的にサービス全体が機能停止します。
指標④ レスポンスタイム（外形監視）
しきい値の目安：2秒超で警告、5秒超で緊急
これは「外からサイトを叩いて応答速度を測る」指標です。死活監視と似ていますが、HTTPステータスコードと応答時間を両方チェックする点が異なります。200 OKが返ってきていても3秒かかっていれば異常です。ECサイトやお問い合わせフォームを持つサイトでは特に重要です。
指標⑤ プロセス生存確認（アプリケーション層）
監視対象：nginx、php-fpm、mysql/mariadb、redisなど
サーバー自体は生きていても個別プロセスが落ちていることは珍しくありません。特にPHP-FPMは設定次第でメモリリークを起こしやすく、定期的にプロセスが落ちるケースもあります。
無料ツールによる実装：UptimeRobot ＋ netdata ＋ シェルスクリプト
STEP1：外形監視はUptimeRoboで即設定（5分）
UptimeRobotは無料プランでも5分間隔の外形監視が50件まで設定できます。URLを登録するだけでHTTPレスポンスコードと応答時間を監視し、異常時にメール・Slackで通知してくれます。
設定後の通知例（Slack Webhook連携時）：
[UptimeRobot] DOWN: example.com - Response time: 30241ms
Alert type: HTTP(S) - Status code: 503
設定手順：
- UptimeRobotにアカウント登録
- 「Add New Monitor」→「HTTP(s)」を選択
- URLと通知先（メールorSlack）を入力
- 「Alert Contacts」でSlack Webhookを登録しておくと運用が楽
STEP2：サーバーリソースはnetdataで可視化（15分）
netdataはエージェント型の監視ツールで、インストール後すぐにCPU・メモリ・ディスク・プロセスをリアルタイムでダッシュボード表示できます。
# インストール（公式スクリプト）
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
# サービス確認
systemctl status netdata
# ダッシュボードアクセス（ポート19999）
# http://your-server-ip:19999
セキュリティの注意点： netdataのダッシュボードは外部に公開しないでください。本番環境では/etc/netdata/netdata.confでbindアドレスを127.0.0.1に制限し、SSHポートフォワーディングでアクセスするのが安全です。
# ローカルからSSHトンネルでアクセスする場合
ssh -L 19999:localhost:19999 user@your-server-ip
# → http://localhost:19999 でダッシュボードが開く
STEP3：アラートをSlackに飛ばすシェルスクリプト
netdataはアラート機能を内蔵していますが、シンプルにシェルスクリプトでディスク監視とプロセス監視を組み合わせることも有効です。cronで5〜10分ごとに実行することを推奨します。
#!/bin/bash
# /usr/local/bin/monitor_check.sh
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
HOSTNAME=$(hostname)
send_alert() {
local message="$1"
curl -s -X POST "$SLACK_WEBHOOK" \
-H 'Content-type: application/json' \
--data "{\"text\": \"🚨 [$HOSTNAME] $message\"}"
}
# ディスク使用率チェック（85%超で警告）
DISK_USAGE=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$DISK_USAGE" -gt 85 ]; then
send_alert "ディスク使用率が ${DISK_USAGE}% に達しています！"
fi
# PHP-FPMプロセス確認
if ! systemctl is-active --quiet php8.2-fpm; then
send_alert "php8.2-fpm が停止しています！"
fi
# MySQLプロセス確認
if ! systemctl is-active --quiet mysql; then
send_alert "MySQLが停止しています！"
fi
# メモリ使用率チェック
MEM_USAGE=$(free | awk 'NR==2 {printf "%.0f", $3/$2*100}')
if [ "$MEM_USAGE" -gt 85 ]; then
send_alert "メモリ使用率が ${MEM_USAGE}% に達しています！"
fi
# cronへの登録（5分ごとに実行）
chmod +x /usr/local/bin/monitor_check.sh
crontab -e
# 以下を追記
*/5 * * * * /usr/local/bin/monitor_check.sh
よくある失敗パターンと対処法
**対処法：** まず1〜2週間は「記録だけ」モードで運用し、通常時のリソース使用率の傾向を掴んでください。平常時のピーク値＋10〜15%をしきい値に設定するのが現実的です。netdataのアラートは `warn` と `crit` の2段階を使い分けましょう。
**対処法：** 簡単でいいので「アラート種別ごとの初動対応手順」をNotionやGoogleドキュメントに記載しておきましょう。「ディスク85%超え → まず`/var/log`のgzファイルを削除、それでも改善しなければFivenineに連絡」のように具体的な手順を。
**対処法：** UFW利用の場合は `ufw deny 19999` を実行。netdata設定ファイルでは `bind to = 127.0.0.1` を明記しましょう。
**対処法：** `/etc/logrotate.d/` に設定ファイルを追加し、週次or日次でログをローテーションする習慣をつけましょう。`logrotate -d /etc/logrotate.d/nginx` でdryrunテストができます。
導入前後の変化：あるクライアントの場合
冒頭で紹介したBtoB製造業のクライアントでは、上記の5指標監視を導入してから3ヶ月で以下の変化がありました。
月8時間かかっていた障害対応が1.5時間に短縮され、問い合わせの未着もゼロになりました。何より「深夜に電話が来なくなった」という点をご担当者の方に非常に喜んでいただきました。監視コストより障害対応コストのほうが圧倒的に高い——これはほぼすべてのケースに共通する事実です。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まとめと次のステップ
死活監視は「最後の砦」に過ぎません。Webサービスの安定稼働には、CPU・メモリ・ディスク・レスポンスタイム・プロセスという5つの指標を組み合わせた多層監視が不可欠です。そして、これらはUptimeRobot・netdata・シェルスクリプトというすべて無料のツールで実現できます。
「設定する時間がない」「VPSの操作に自信がない」という方は、ぜひFivenlineにご相談ください。現在のサーバー環境の診断から監視設定の構築まで、神奈川・首都圏のクライアントを中心に対応しています。
