サーバー容量90%超え！自動アラートで障害を未然防止する監視設定

サーバー容量不足による障害を防ぐ自動監視システムの構築方法。実案件での失敗談も交えながら、中小企業でも導入できる監視設定術を詳しく解説します。

こんな悩み、お持ちではありませんか？

「土曜日の深夜、突然サイトが真っ白になって、顧客からの問い合わせが殺到した...」

神奈川で20年以上Web制作を手がけてきたFivenine Designでは、このような緊急事態のお電話を何度も受けてきました。サーバー容量不足による障害は、予告なしに突然発生し、機会損失だけでなく顧客の信頼も失いかねません。

Webサイトを運営する中小企業の皆さまは、日々の業務に追われながら「サーバーは大丈夫だろう」と考えがちですが、実際にはこんな状況に直面していませんか？

• 毎月のサーバー容量を手動でチェックするのを忘れてしまう
• 容量がいっぱいになってから気づいて慌てて対処する
• 深夜や休日にサーバーダウンが発生して対応に困る
• どのくらいの容量で警告を出すべきかわからない

今回は、実際のクライアントでの導入事例をもとに、サーバー容量の自動監視システム構築について具体的にお話しします。

なぜサーバー容量監視が重要なのか

実案件での教訓：ECサイトが売上ピーク時にダウン

あるクライアント（年商2億円のアパレルECサイト）で、実際に起こった事例をご紹介します。セール開始から3日目の夜中、サーバー容量が100%に達してサイトが完全にダウン。復旧まで約4時間を要し、推定で300万円の機会損失が発生しました。

原因を調査すると、以下のような問題が重なっていたことがわかりました：

容量不足が引き起こす連鎖的な問題

技術的な影響

• データベースの書き込みエラー
• ログファイルの出力停止
• 一時ファイルの作成失敗
• バックアップ処理の中断

ビジネスへの影響

• 新規顧客の流入機会損失
• 既存顧客の信頼低下
• SEO評価への悪影響
• 緊急対応による人的コスト増加

この経験から学んだことは、**「問題が発生してから対処するのではなく、事前に予測して対策する」**ことの重要性でした。

自動監視システム構築の具体的手順

ステップ1：現状把握と監視対象の特定

まず、どの領域を監視すべきかを明確にします。Linux系サーバーでの基本的な確認方法：

# ディスク使用量の確認
df -h

# ディレクトリ別の使用量確認
du -sh /var/www/* | sort -hr

# inode使用量の確認（ファイル数の制限）
df -i

ステップ2：監視スクリプトの作成

実際にクライアントで使用している監視スクリプトをベースに、カスタマイズ版をご紹介します：

#!/bin/bash

# 設定値
ALERT_THRESHOLD=85  # 85%で警告
CRITICAL_THRESHOLD=90  # 90%で緊急アラート
LOG_FILE="/var/log/disk_monitor.log"
EMAIL="[email protected]"

# ディスク使用率を取得（%マークを除去）
USAGE=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')

# ログ出力
echo "$(date): Disk usage is ${USAGE}%" >> $LOG_FILE

# 閾値チェック
if [ $USAGE -ge $CRITICAL_THRESHOLD ]; then
    SUBJECT="【緊急】サーバー容量が${USAGE}%に達しました"
    BODY="サーバー容量が危険レベル（${USAGE}%）に達しています。至急対応が必要です。"
    echo "$BODY" | mail -s "$SUBJECT" $EMAIL
elif [ $USAGE -ge $ALERT_THRESHOLD ]; then
    SUBJECT="【警告】サーバー容量が${USAGE}%に達しました"
    BODY="サーバー容量が${USAGE}%に達しています。容量確保をご検討ください。"
    echo "$BODY" | mail -s "$SUBJECT" $EMAIL
fi

<?php

class DiskMonitor {
    private $alertThreshold = 85;
    private $criticalThreshold = 90;
    private $adminEmail = '[email protected]';
    
    public function checkDiskUsage() {
        $usage = $this->getDiskUsage();
        $this->logUsage($usage);
        
        if ($usage >= $this->criticalThreshold) {
            $this->sendCriticalAlert($usage);
        } elseif ($usage >= $this->alertThreshold) {
            $this->sendWarningAlert($usage);
        }
    }
    
    private function getDiskUsage() {
        $output = shell_exec('df -h / | awk \'NR==2 {print $5}\' | sed \'s/%//\'');
        return (int)trim($output);
    }
    
    private function logUsage($usage) {
        $log = date('Y-m-d H:i:s') . ": Disk usage is {$usage}%\n";
        file_put_contents('/var/log/disk_monitor.log', $log, FILE_APPEND);
    }
    
    private function sendCriticalAlert($usage) {
        $subject = "【緊急】サーバー容量が{$usage}%に達しました";
        $body = "サーバー容量が危険レベル（{$usage}%）に達しています。至急対応が必要です。";
        mail($this->adminEmail, $subject, $body);
    }
}

$monitor = new DiskMonitor();
$monitor->checkDiskUsage();
?>

ステップ3：crontabでの自動実行設定

# crontabの編集
crontab -e

# 30分おきに監視実行
*/30 * * * * /path/to/disk_monitor.sh

# ログローテーション設定も併せて
0 0 * * 0 find /var/log -name "disk_monitor.log*" -mtime +30 -delete

ステップ4：Slack通知の実装（推奨）

メール通知に加えて、Slack通知も設定することで、チーム全体での迅速な対応が可能になります：

# Slack Webhook URLを設定
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

# Slack通知関数
send_slack_notification() {
    local message="$1"
    local color="$2"
    
    curl -X POST -H 'Content-type: application/json' \
        --data "{\"attachments\":[{\"color\":\"$color\",\"text\":\"$message\"}]}" \
        $SLACK_WEBHOOK
}

# アラート時にSlackへ通知
if [ $USAGE -ge $CRITICAL_THRESHOLD ]; then
    send_slack_notification "🚨 サーバー容量が${USAGE}%に達しました！至急対応が必要です" "danger"
elif [ $USAGE -ge $ALERT_THRESHOLD ]; then
    send_slack_notification "⚠️ サーバー容量が${USAGE}%に達しました" "warning"
fi

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

失敗パターン1：閾値設定のミス

よくある失敗：90%でアラートを設定したため、対応する時間がなく結局ダウンしてしまった。

正しい対処法：段階的な閾値設定が重要です。

失敗パターン2：通知の見落とし

よくある失敗：メール通知だけに頼って、休日や深夜の通知を見落とした。

正しい対処法：複数の通知手段を組み合わせます。

• メール通知（基本）
• Slack通知（チーム共有）
• SMS通知（緊急時のみ）
• 電話通知（システムダウン時）

失敗パターン3：不完全な容量計算

よくある失敗：ルートパーティションだけ監視して、データ用パーティションの容量不足を見落とした。

正しい対処法：監視対象を明確に定義します。

# 全パーティションの監視
for partition in $(df -h | awk 'NR>1 {print $6}'); do
    usage=$(df -h $partition | awk 'NR==2 {print $5}' | sed 's/%//')
    echo "$partition: ${usage}%"
    # 各パーティションの閾値チェック
done

失敗パターン4：自動対処機能の暴走

よくある失敗：容量不足時に自動でファイル削除する機能を実装したが、重要なファイルまで削除してしまった。

正しい対処法：自動対処は最小限に留め、必ずバックアップと確認機能を実装します。

# 安全な自動対処の例（ログファイルの圧縮のみ）
if [ $USAGE -ge 90 ]; then
    # 7日以上古いログファイルを圧縮
    find /var/log -name "*.log" -mtime +7 -exec gzip {} \;
    # 30日以上古い圧縮ログを削除（バックアップ後）
    find /var/log -name "*.log.gz" -mtime +30 -exec rm {} \;
fi

導入後の変化：クライアントの声

実際にこの監視システムを導入したクライアントからは、以下のような声をいただいています：

「夜中に起きてサーバーを確認することがなくなりました」（製造業 IT担当者）

「容量不足による障害が完全になくなり、顧客からのクレームも激減しました」（ECサイト運営会社 代表）

「予防的にストレージ拡張ができるようになり、コスト計画も立てやすくなりました」（コンサルティング会社 経営者）

まとめと次のステップ

サーバー容量の監視システムは、一度設定してしまえば24時間365日、あなたのWebサイトを守り続けてくれる頼れるパートナーです。初期設定に少し時間をかけることで、将来的な大きな損失を防ぐことができます。

今すぐ始められるアクションプラン

技術的な課題でお困りの場合

サーバー監視システムの構築は、適切に設定すれば大きな効果を発揮しますが、環境や要件によって最適な設定は異なります。Fivenine Designでは、20年以上の実績をもとに、お客様の環境に最適化された監視システムの構築をサポートしています。

• 設定がうまくいかない
• 既存システムとの連携方法がわからない
• より高度な監視機能を実装したい

このような課題をお持ちでしたら、お気軽にご相談ください。あなたのビジネスに最適な監視システムを一緒に構築いたします。