「dfコマンドで確認したら使用率98%。でもいつからそうなっていたのか分からない」
Linuxサーバーを長く運用していると、こういったトラブルに必ず一度は直面します。問題は「ディスクが満杯になった」ことではなく、「なぜ予測できなかったか」にあります。
この記事では、dfコマンドの出力を定期的にログとして記録し、使用量の推移データをキャパシティプランニングに活かす方法を具体的に解説します。cronによる自動収集、しきい値の設計、メールアラートの実装まで、現場で即使える手順でまとめています。
この記事のポイント
・df -P の出力をcronで定期記録し、容量推移ログを蓄積する
・awk でログを集計し、直近の増加傾向を数値で把握できる
・しきい値(80%/90%)を設け、超えたらメールで自動アラートを送る
・推移データから「いつ増設が必要か」を逆算するのがプランニングの核心
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
ディスク容量問題はなぜ突然起きるのか
セミナーで3,100名以上のエンジニアを指導してきた中で、「ディスクが満杯で障害が起きた」という経験談は非常によく聞きます。不思議なのは、多くの場合が「突然」だという感覚で語られることです。実際には突然ではありません。ディスク使用量は必ず徐々に増えています。ただ、その増加を追いかけていないから、満杯になって初めて気づくわけです。
現場でよくある増加パターンを整理すると、次の3種類に集約されます。
・ログファイルの肥大化:/var/log 配下が数日のうちに数GBに膨らむ(nginx・Apacheのアクセスログ、maillogなど)
・バックアップデータの蓄積:古いバックアップの削除が自動化されておらず、気づいたら/backupが満杯になっている
・アプリケーションデータの急増:DBのデータ量が予想外に増えた、アップロードファイルが溜まっていた
これらの問題に共通しているのは「定点観測がない」という点です。dfコマンドを手で叩いて確認する習慣があっても、記録が残らなければ傾向は分かりません。ログとして蓄積してはじめて、「先月と比べてどのくらい増えたか」が見えてきます。
dfコマンドでディスク使用量をログとして記録する方法
ログ記録の基礎は、dfコマンドの出力をファイルに書き出すことです。まず基本的な出力を確認しましょう。1. df コマンドの基本出力
# 人間が読みやすい形式(-hオプション) df -h # 出力例(実サーバーでのマスク済み出力) Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 15G 0 15G 0% /dev/shm tmpfs 5.8G 9.4M 5.8G 1% /run /dev/mapper/rl_svXX-root 70G 38G 33G 54% / /dev/sdb1 500G 312G 188G 63% /data /dev/sda1 960M 364M 597M 38% /boot
2. ログ記録に適した出力形式
# POSIXフォーマット(1パーティション1行で出力) df -P # 日時を先頭に付けてログファイルへ追記するスクリプト #!/bin/bash TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S') df -P | awk -v ts="$TIMESTAMP" 'NR>1 {print ts, $0}' >> /var/log/df_capacity.log
3. 数日分のログが蓄積された状態の例
# /var/log/df_capacity.log の記録例(/dataパーティション分のみ抜粋) 2026-07-01 00:00:00 /dev/sdb1 524288000 326836224 197451776 63% /data 2026-07-08 00:00:00 /dev/sdb1 524288000 345030656 179257344 66% /data 2026-07-15 00:00:00 /dev/sdb1 524288000 363225088 161062912 70% /data 2026-07-22 00:00:00 /dev/sdb1 524288000 381419520 142868480 73% /data 2026-07-29 00:00:00 /dev/sdb1 524288000 399613952 124674048 77% /data 2026-08-05 00:00:00 /dev/sdb1 524288000 423624704 100663296 81% /data
cronでdfログを自動収集する
手で実行するのではなく、cronで自動化するのが実務の基本です。1日1回(深夜0時)の収集を設定します。1. 収集スクリプトの作成
# /usr/local/bin/df_collect.sh #!/bin/bash LOGFILE="/var/log/df_capacity.log" TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S') df -P | awk -v ts="$TIMESTAMP" 'NR>1 {print ts, $0}' >> "$LOGFILE"
# 実行権限を付与 chmod 755 /usr/local/bin/df_collect.sh # 動作確認(手動実行してログを確認) /usr/local/bin/df_collect.sh tail -5 /var/log/df_capacity.log
2. crontabへの登録
# rootのcrontabを編集 crontab -e # 以下の行を追加(毎日0時0分に記録) 0 0 * * * /usr/local/bin/df_collect.sh
3. ログファイルのローテーション設定
dfログは小さいファイルですが、毎日記録すると1年で365エントリ以上になります。logrotateで管理しましょう。# /etc/logrotate.d/df_capacity を作成 /var/log/df_capacity.log { yearly rotate 3 compress missingok notifempty }
なお、cronで正確な時刻にスクリプトを動かすには、サーバーの時刻同期が前提です。ntpd 時刻同期設定が適切に行われているか、合わせて確認してください。
ログデータから使用量の推移を可視化する
ログが蓄積されたら、awkを使って特定のマウントポイントの推移を抽出します。1. 特定パーティションの推移を抽出する
# /data パーティションの使用率推移を日時付きで表示 grep '/data$' /var/log/df_capacity.log | awk '{print $1, $2, $7}' # 出力例 2026-07-01 00:00:00 63% 2026-07-08 00:00:00 66% 2026-07-15 00:00:00 70% 2026-07-22 00:00:00 73% 2026-07-29 00:00:00 77% 2026-08-05 00:00:00 81%
2. 記録期間内の増加量を計算するスクリプト
# /data の記録期間内の使用率変化を計算する #!/bin/bash LOGFILE="/var/log/df_capacity.log" MOUNT="/data" OLDEST=$(grep "$MOUNT" "$LOGFILE" | head -1 | awk '{print $7}' | tr -d '%') LATEST=$(grep "$MOUNT" "$LOGFILE" | tail -1 | awk '{print $7}' | tr -d '%') COUNT=$(grep -c "$MOUNT" "$LOGFILE") DIFF=$(( LATEST - OLDEST )) echo "マウントポイント: $MOUNT" echo "記録開始時: ${OLDEST}%" echo "最新: ${LATEST}%" echo "記録数: ${COUNT}回(約${COUNT}日分)" echo "合計増加量: ${DIFF}%"
# 実行結果の例 マウントポイント: /data 記録開始時: 63% 最新: 81% 記録数: 38回(約38日分) 合計増加量: 18%
しきい値の設計と自動アラートの実装
数値で推移が見えたら、次はしきい値を決めてアラートを自動化します。「何%を超えたら警告するか」の基準は、ディスクの用途と増加速度によって変わります。1. しきい値の考え方
実務でよく使われるしきい値の設計基準はこの通りです。・80%(警告):この段階で増設計画の検討を開始。増設に1週間以上かかる場合はここで動く
・90%(緊急):即時対応が必要。ログの圧縮・不要ファイルの削除・一時的なディレクトリ移動
・95%(危険):多くのアプリケーションがファイル書き込み失敗で停止するラインに近い
増加速度が速いサーバー(週に3%以上増える)では、しきい値を5%ほど下げて早めに対応できる余裕を持たせるのが現場の定石です。
2. アラートスクリプトの実装
# /usr/local/bin/df_alert.sh #!/bin/bash WARN_THRESHOLD=80 CRIT_THRESHOLD=90 MAIL_TO="admin@example.com" HOSTNAME=$(hostname) df -P | awk 'NR>1' | while read line; do FILESYSTEM=$(echo $line | awk '{print $1}') USE_PCT=$(echo $line | awk '{print $5}' | tr -d '%') MOUNT=$(echo $line | awk '{print $6}') # tmpfs等の仮想ファイルシステムを除外 echo "$FILESYSTEM" | grep -q '^/dev/' || continue if [ "$USE_PCT" -ge "$CRIT_THRESHOLD" ]; then echo "【緊急】${HOSTNAME} ${MOUNT} 使用率${USE_PCT}% (${CRIT_THRESHOLD}%超)" | \ mail -s "[DISK CRIT] ${HOSTNAME} ${MOUNT} ${USE_PCT}%" "$MAIL_TO" elif [ "$USE_PCT" -ge "$WARN_THRESHOLD" ]; then echo "【警告】${HOSTNAME} ${MOUNT} 使用率${USE_PCT}% (${WARN_THRESHOLD}%超)" | \ mail -s "[DISK WARN] ${HOSTNAME} ${MOUNT} ${USE_PCT}%" "$MAIL_TO" fi done
3. cronへのアラートスクリプト登録
# アラートスクリプトに実行権限を付与 chmod 755 /usr/local/bin/df_alert.sh # crontabへ追加(df収集と同じ0時0分) 0 0 * * * /usr/local/bin/df_collect.sh 0 0 * * * /usr/local/bin/df_alert.sh # メール通知が動くか手動でテスト /usr/local/bin/df_alert.sh
dfログ収集でよくあるエラーと対処法
cronやメール通知を設定する際に、現場でよく直面するエラーをまとめます。1. cronが動いているのにログが記録されない場合
# cron自体の動作確認 systemctl status crond # cronのログを確認(RHEL/CentOS系) grep CRON /var/log/cron | tail -20 # スクリプトのパスが正しいか確認 which df which awk # cron環境ではPATHが制限される。スクリプト内でフルパスを指定する /usr/bin/df -P | /usr/bin/awk -v ts="$TIMESTAMP" 'NR>1 {print ts, $0}' >> "$LOGFILE"
2. メールアラートが届かない場合
# mailコマンドの存在確認 which mail # mailコマンドがない場合はインストール dnf install mailx # RHEL/Rocky Linux 9 apt install mailutils # Ubuntu/Debian # Postfixが起動しているか確認 systemctl status postfix # テストメール送信 echo "テスト" | mail -s "test" admin@example.com # maillogでエラーを確認 tail -50 /var/log/maillog
3. ログファイルの権限エラーが出る場合
# エラー例 /usr/local/bin/df_collect.sh: /var/log/df_capacity.log: Permission denied # 対処1: rootのcrontabから実行する(rootで記録する場合) sudo crontab -e # 対処2: ログファイルを書き込み可能なディレクトリに変更する LOGFILE="/var/log/df_capacity.log" touch "$LOGFILE" chmod 644 "$LOGFILE" # ファイルの権限を確認 ls -la /var/log/df_capacity.log
キャパシティプランニングの実践手順
ログが蓄積されると、「いつ満杯になるか」を逆算できるようになります。これがキャパシティプランニングの核心です。1. 日次増加率と到達日数の計算
# /data パーティションの日次平均増加率と90%到達予測を算出 #!/bin/bash LOGFILE="/var/log/df_capacity.log" MOUNT="/data" OLDEST=$(grep "$MOUNT" "$LOGFILE" | head -1 | awk '{print $7}' | tr -d '%') LATEST=$(grep "$MOUNT" "$LOGFILE" | tail -1 | awk '{print $7}' | tr -d '%') COUNT=$(grep -c "$MOUNT" "$LOGFILE") DIFF=$(( LATEST - OLDEST )) DAILY_RATE=$(echo "scale=2; $DIFF / $COUNT" | bc) REMAIN=$(( 90 - LATEST )) DAYS_TO_90=$(echo "scale=0; $REMAIN / $DAILY_RATE" | bc) echo "現在の使用率: ${LATEST}%" echo "日次平均増加率: ${DAILY_RATE}%/日" echo "90%到達まであと約${DAYS_TO_90}日"
# 実行結果の例 現在の使用率: 81% 日次平均増加率: 0.47%/日 90%到達まであと約19日
2. 増設方式の選択基準
ディスク容量対応には主に3つの選択肢があります。どれを選ぶかは現在の構成と増加の原因によって変わります。・不要データの削除・アーカイブ:ログの圧縮、古いバックアップの整理が最初の選択肢。コスト不要で即効性あり
・LVM論理ボリュームの拡張:LVM構成(pvs・vgsコマンドで確認)なら物理ディスク追加後にpvextend→vgextend→lvextendで無停止拡張が可能
・ディスクの追加・移行:LVM未使用またはルートパーティションの場合は停止メンテナンスが必要になることが多い
3. キャパシティプランニングのチェックリスト
定期的なキャパシティレビューでは、次の項目を確認します。・月次レビュー:全パーティションの直近30日増加率を確認し、90%到達予測を算出する
・四半期レビュー:増加トレンドの変化(季節変動・サービス成長)をデータで確認する
・増設リードタイム:物理サーバーは発注~納品に2週間以上かかることも。データが80%に達した時点では手遅れになるケースを私も経験したことがあります
・ディスク以外のボトルネック:容量だけでなくI/OもIOPSで制限されていないかiostatコマンドで確認する
本記事のまとめ
| やりたいこと | コマンド・手順 |
|---|---|
| ディスク使用量を日時付きでログ記録 | df -P | awk -v ts="$(date)" 'NR>1 {print ts, $0}' >> /var/log/df_capacity.log |
| cronで毎日自動記録 | 0 0 * * * /usr/local/bin/df_collect.sh |
| 特定マウントポイントの推移を抽出 | grep '/data$' /var/log/df_capacity.log | awk '{print $1, $2, $7}' |
| 使用率がしきい値を超えたらメールアラート | /usr/local/bin/df_alert.sh(crontabに登録) |
| 90%到達までの日数を予測 | 日次増加率を算出し、残余容量をbcコマンドで割る |
| ディスク物理構成を確認 | dmidecode -t memory(ディスクスロット状況も把握できる) |
ディスク容量の増加を予測できるエンジニアは、設計の「型」を持っています
キャパシティプランニングはスクリプトで自動化できますが、「どこに注目して設計するか」の判断軸は現場経験から生まれます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Linuxのデバイスファイル命名規則|/dev/sda・パーティション番号の読み方
- この記事の属するカテゴリ:ディスク操作へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます