サーバーを運用していると、避けて通れないのが「ディスク容量不足」の問題です。容量がいっぱいになると、アプリケーションのログが書き込めなくなったり、データベースが動作停止したりと、サービスに深刻な影響を与えることがあります。特に本番環境では、予期せぬ容量不足が発生した瞬間に業務が止まる可能性もあり、早めの対策が欠かせません。
とはいえ、手作業で定期的に df コマンドを叩いて確認するのは非効率ですし、気づかないうちに容量が逼迫してしまうリスクもあります。そこで役立つのが「ディスク容量不足を自動通知する仕組み」です。
この記事では、Linux環境を例に、容量確認の基本コマンド → 自動検知用スクリプトの作成 → cronによる定期監視 → メールやSlackでの通知 まで、実務ですぐに使える流れを解説します。システム管理者だけでなく、自宅サーバーやVPSを利用している方にも役立つ内容です。
ディスク容量不足が起きると何が問題か
ディスク容量の不足は、サーバーやシステムの運用において深刻なトラブルを引き起こします。単なる「空き容量がなくなる」という問題にとどまらず、業務やサービス全体を停止させてしまうリスクがあるため、事前の監視と通知が重要です。
サービス停止やデータ損失のリスク
サーバーの空き容量がゼロになると、アプリケーションはログを書き込めなくなります。ログが出力できないと障害解析が難しくなり、問題が発生しても原因を追跡できない状況に陥ります。さらに、データベースでは新規データの書き込みが失敗し、最悪の場合はクラッシュやデータ破損につながることもあります。
また、ファイルアップロードを伴うWebサービスでは、利用者がファイルを送信しても保存されず、ユーザー体験を大きく損ないます。こうしたトラブルは復旧までに時間がかかることが多く、事前にアラートを受け取る仕組みがなければ深刻化しやすいのです。
サーバー運用でよくあるトラブル事例
実際に運用の現場では、以下のような容量不足がよく見られます。
- ログファイルが肥大化
アプリケーションやシステムログがローテーションされず、気づけば数GB〜数十GBに膨らんでいる。 - バックアップデータの蓄積
定期バックアップを保存し続け、古いデータが削除されないままディスクを圧迫。 - 一時ファイルやキャッシュの残存
/tmpディレクトリやアプリケーションキャッシュが掃除されず、積み重なって容量を消費。 - ユーザーのアップロードによる逼迫
画像や動画ファイルを扱うサービスでは、ユーザーの利用拡大に伴って容量不足が急速に進行。
これらは一度発生すると手作業での対応が必要となり、場合によっては緊急メンテナンスを行わざるを得ません。したがって、容量が逼迫する前に通知を受け取り、計画的に対処できる体制 を整えることが非常に重要です。
容量確認の基本：dfとduコマンド
ディスク容量を監視する仕組みを作る前に、まずは手作業で現在の容量状況を確認する基本コマンドを押さえておきましょう。Linux環境では主に df と du が使われます。これらを理解しておくと、自動化スクリプトを作る際にも応用できます。
dfコマンドで空き容量を確認する
df は「disk free」の略で、ディスク全体の使用状況を確認するためのコマンドです。最もよく使われるオプションは -h で、容量を人間が読みやすい単位（KB, MB, GB）で表示してくれます。
df -h
実行例：
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 35G 12G 75% /
tmpfs 1.9G 1.2M 1.9G 1% /dev/shm
ここで注目すべきは Use%（使用率） と Avail（空き容量） です。たとえば上記では /dev/sda1 が 75% 使用中で、残り 12GB となっています。
サーバー運用の現場では、使用率80%を超えたら要注意、90%を超えたら即対応 といった基準を設けて監視しているケースが多いです。
duコマンドで容量が大きいディレクトリを特定する
du は「disk usage」の略で、特定のディレクトリやファイルがどれくらい容量を消費しているかを調べるコマンドです。容量不足の原因を探るときに役立ちます。
よく使う例：
du -sh /var/*
実行例：
1.2G /var/log
4.5G /var/lib
12M /var/tmp
このように、どのディレクトリがどれくらい容量を消費しているのかを一覧で確認できます。問題の切り分けに非常に便利です。
さらに、容量が大きい順に並べたい場合は sort と組み合わせます。
du -sh /var/* | sort -hr | head -n 10
これで「容量を食っている上位10件」を特定でき、不要ファイルの削除やログローテーションの調整につなげられます。
df で全体の空き容量を確認し、du で原因となる大きなディレクトリを特定する。この流れを理解しておくことが、自動化の第一歩です。
容量不足を自動で検知するスクリプトの作成
容量の確認を人間が毎回手動で行うのは非効率です。そこで役立つのが「自動検知スクリプト」です。一定の閾値を設定し、ディスク使用率がその値を超えたら警告を出す仕組みを作れば、問題が深刻化する前に対応できます。
シェルスクリプトで閾値を設定する方法
まずは基本的なサンプルスクリプトを見てみましょう。
#!/bin/bash
# チェックするパーティション
TARGET="/"
# 閾値（%）
THRESHOLD=80
# dfコマンドで使用率を取得（%は除外して数値化）
USAGE=$(df -hP $TARGET | awk 'NR==2 {print $5}' | sed 's/%//')
# 閾値を超えたら警告を出力
if [ "$USAGE" -ge "$THRESHOLD" ]; then
echo "WARNING: Disk usage on $TARGET is ${USAGE}% (threshold: ${THRESHOLD}%)"
fi
このスクリプトを実行すると、対象ディスクの使用率が80%以上になった時に警告メッセージが表示されます。閾値は任意に設定できるので、運用ポリシーに合わせて変更してください。
実行結果をログに残す工夫
スクリプトを定期実行する場合、その結果をログとして残しておくと便利です。>> を使ってログファイルに追記すれば、いつどんな状態だったかを後から確認できます。
#!/bin/bash
TARGET="/"
THRESHOLD=80
LOGFILE="/var/log/disk_check.log"
USAGE=$(df -hP $TARGET | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
echo "$(date '+%Y-%m-%d %H:%M:%S') WARNING: $TARGET usage is ${USAGE}%" >> $LOGFILE
fi
これで /var/log/disk_check.log に日時付きで記録が残ります。もし通知が届かなかった場合でも、ログを追うことで状態を振り返ることが可能です。
さらに一歩進めて、容量不足を検知したら即メール送信やSlack通知に繋げる 仕組みを追加すれば、実運用に即した監視体制を構築できます。この部分は次の章で詳しく解説します。
cronで定期実行し監視を自動化
容量チェックのスクリプトが用意できたら、定期的に実行されるよう cron に登録して監視を自動化します。cron は分・時・日・月・曜日の5つのフィールドでスケジュールを表現し、設定はユーザーごとの crontab に保存されます。まずはエディタを開きます。
crontab -e
例えば「毎時5分に /usr/local/bin/disk_check.sh を実行し、標準出力と標準エラーを合わせてログへ追記」する設定は下記です。
# m h dom mon dow command
5 * * * * /usr/local/bin/disk_check.sh >> /var/log/disk_check.cron.log 2>&1
PATH の違いに注意しましょう。cron 下ではインタラクティブシェルと環境が異なるため、コマンドはフルパスで書くのが安全です（例： /bin/df、/usr/bin/awk）。また、スクリプト先頭で #!/bin/bash を指定し、chmod +x で実行権限を与えることを忘れずに。
cronの基本設定と実行例
- 毎分：
* * * * * /path/to/script - 15分おき：
*/15 * * * * /path/to/script - 毎日 9:00：
0 9 * * * /path/to/script
容量監視は「過剰な通知を避けつつ、逼迫の兆候を早く掴む」のが理想です。多くのケースで 5〜15分間隔 が妥当ですが、アクセス急増が想定されるサービスでは短めに設定しましょう。
毎日・毎時間のスケジュール設定
「昼間は10分おき、夜間は1時間おき」といった 時間帯別 の監視も可能です。
# 09:00-23:59 は10分おき
*/10 9-23 * * * /usr/local/bin/disk_check.sh
# 00:00-08:59 は1時間おき
0 0-8 * * * /usr/local/bin/disk_check.sh
また、ロックファイルで多重起動を防ぐと誤検知や負荷増を抑えられます。
#!/bin/bash
LOCK=/tmp/disk_check.lock
exec 9>"$LOCK" || exit 1
flock -n 9 || exit 0
# …チェック処理…
このようにスケジュール設計と実行制御を合わせることで、安定した監視基盤になります。
通知方法①：メールでの容量不足アラート
メール通知はセットアップが簡単で、ほぼすべての環境で使える標準的な手段です。サーバーに mail（あるいは mailx）が入っていれば、スクリプトから直接送信できます。
sendmailやmailコマンドを利用する
例として mail コマンドを使った送信を組み込みます。
#!/bin/bash
TARGET="/"
THRESHOLD=85
USAGE=$(df -hP $TARGET | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
HOST=$(hostname -f 2>/dev/null || hostname)
SUBJ="[ALERT] Disk usage ${USAGE}% on ${HOST}:${TARGET}"
BODY="$(date '+%F %T') ${HOST} ${TARGET} is ${USAGE}% (>=${THRESHOLD}%)"
echo "$BODY" | mail -s "$SUBJ" ops@example.com
fi
sendmail を直接叩く場合は、ヘッダと本文を自分で整形します。外部SMTP中継（Postfix/Exim でのリレー設定、または msmtp 等）を使うと、クラウド環境でも確実に投げられます。SPF/DKIM/DMARC の整備や迷惑メール対策もあわせて検討すると運用品質が上がります。
件名や本文を工夫して見やすくする
通知は「一目で判断できること」が重要。件名には 閾値超え・使用率・ホスト名・マウントポイント を含め、本文には 直近の df 結果と上位の容量食いディレクトリ を添えると、一次対応が速くなります。
TOP10=$(du -sh /var/* 2>/dev/null | sort -hr | head -n 5)
BODY="$(date '+%F %T') ${HOST} ${TARGET} ${USAGE}%\nTop dirs:\n${TOP10}"
echo -e "$BODY" | mail -s "$SUBJ" ops@example.com
さらに、**抑止（サプレッション）**の工夫も有効です。例えば「すでにアラート送信済みの状態では再送しない」「しきい値を2段階（Warning/ Critical）に分ける」といった工夫でメール洪水を防ぎます。ステート管理は一時ファイルに「最後の送信時刻」や「最後の状態」を書いて判定するのが簡単です。
通知方法②：Slackやチャットツール連携
チャット通知はチーム全体での可視化に優れ、担当者不在でも誰かが気づける体制を作れます。Slack の Incoming Webhook を使うと、シンプルな HTTP POST だけで通知を送れます。
Webhookを使ったSlack通知の例
まず Slack で Incoming Webhook URL を発行し、スクリプトに環境変数として持たせます。
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/XXX/YYY/ZZZ"
payload=$(cat <<EOF
{
"username": "DiskMonitor",
"icon_emoji": ":warning:",
"text": "*ALERT*: $(hostname -s) / is at ${USAGE}% (>=${THRESHOLD}%)",
"attachments": [{
"fields": [
{"title": "Host", "value": "$(hostname -f)", "short": true},
{"title": "Mount", "value": "${TARGET}", "short": true}
]
}]
}
EOF
)
curl -s -X POST -H 'Content-type: application/json' \
--data "$payload" "$SLACK_WEBHOOK_URL" >/dev/null
curl が失敗した場合を想定し、再送ロジック か メールへのフォールバック を入れておくと安心です。Webhook URL は漏えい対策として 環境変数・root限定の設定ファイル・Vault などで安全に保持します。
チームで共有できる仕組みにするメリット
チャット通知の強みは、履歴とディスカッションがひとつのスレッド に集約されることです。通知チャンネルを #ops-alerts のように分け、緊急度別のリアクション運用（:eyes: で確認、:white_check_mark: で対応完了）を決めると運用が回りやすくなります。さらに、メンション（@here / @oncall） を閾値や時間帯で出し分ける、Grafana/CloudWatch など外部監視と統合 して一元化する、といった発展も容易です。
実運用に役立つ改善ポイント
容量不足を「検知して知らせる」だけでなく、溜まりやすい原因へ先手を打つ と安定運用に近づきます。
容量を食っているログファイルの自動圧縮
logrotate を設定し、日次・週次でローテーション、古いログを圧縮（compress）し、一定世代で削除（rotate 7 など）します。障害解析に必要な保存期間を決め、本番とステージングで方針を分ける と無駄が減ります。アプリ側のログレベル（INFO/DEBUG）を見直すのも重要です。
監視と同時にクリーンアップを自動化
閾値超過時に、安全な範囲で自動掃除 を走らせる選択肢もあります。例えば /tmp の 7日以上前のファイル削除、古いバックアップの削除、キャッシュディレクトリの掃除などです。
# 7日以上前の/tmpファイルを削除（慎重に！）
find /tmp -type f -mtime +7 -delete
ただし自動削除は 誤爆のリスク があります。まずは ドライラン（削除予定をメール通知）→承認後に削除 の2段階運用にし、対象ディレクトリを限定、除外パターンを厳密に定義しましょう。
さらに、多段しきい値（80%でWarning、90%でCritical）、バースト抑止（同内容を一定時間まとめる）、メトリクス蓄積（時系列で推移を可視化）を組み合わせると、アラートの品質が上がります。将来的には Prometheus + Node Exporter で node_filesystem_avail_bytes を監視し、Grafana でダッシュボード化するのがおすすめです。
まとめ：自動通知で安心のサーバー運用へ
ディスク容量不足は、検知が遅れるほど復旧コストが増える典型的な障害 です。本記事で扱った流れ——df/du による状況把握、しきい値判定スクリプト、cron による定期実行、メール・Slack での通知、そしてログ圧縮や不要ファイル掃除の仕組み——を組み合わせれば、少ない工数で実務レベルの監視体制が整います。
まずは 単純な1パーティション監視 から始め、通知品質（件名・本文・頻度）を磨き、対象ディスクの拡張（別ボリュームの追加・S3等への外だし）や メトリクス監視 へ段階的に発展させましょう。運用は「小さく始めて継続的に改善」が鉄則。今日から自動通知を導入し、容量不足でヒヤリとする瞬間をひとつずつ減らしていきましょう。
