「なぜかVPSのディスク容量が急激に減っている…」 「Webサーバーやデータベースは何も増やしていないはずなのに、ストレージ残量アラートが止まらない…」
Linux（Ubuntu）で自宅サーバーやVPSを運用し始めた人が、ある日突然見舞われる怪現象。 その原因の9割は、/var/log に溜まり続ける膨大なログの死骸です。
システムログ、メールの送信ログ、WEBサーバーのアクセスログ、UFW（ファイアウォール）のブロックログ…。Linuxは私たちが寝ている間も、休むことなくログを吐き続けています。
特に、Postfixでメールリレーを構築したり、Cronで定期処理を回し始めたりした環境では、ログの肥大化スピードが格段に跳ね上がります。気付いた時にはログだけで3GB〜10GBオーバー。最悪の場合、ストレージが100%になってサーバーごとクラッシュ（停止）します。
「動く環境を作って満足」で終わらせず、サーバーを数か月・数年とクリーンに稼働させ続けるための「ログ完全自動清掃システム」を今すぐ構築しましょう！
🛑 なぜ /var/log は勝手にパンパンになるのか？
Ubuntuには標準で logrotate（ログの世代管理ツール）や journald（systemdのログ機能）が入っています。
「じゃあ放置しても自動で消してくれるのでは？」と思いきや、初期設定（デフォルト）のままだと以下のような「運用の罠」が潜んでいます。
1. 圧縮ログ（.gz や .1）が何世代も残り続ける
logrotate は過去のログを syslog.1 や mail.log.2.gz のように番号や圧縮ファイルで残しますが、保持世代数が多く設定されていると、古いログがいつまでもディスクを圧迫します。
2. Journald（バイナリログ）の上限が開放されている
systemd が管理する journald は、テキストではなくバイナリ形式で高速にログを記録しますが、デフォルトでは「ディスク容量の最大10%まで使ってよい」という大食い設定になっています。数GB規模まで膨らむ最大の犯人はだいたいこれです。
3. エラー連発時に一夜で数GB吐き出す
アプリやスクリプトがループ処理でエラーを連投すると、たった1夜で数GB〜十数GBのログが書き込まれ、ストレージを食い尽くします。
🛡️ ログ肥大化を永久に防ぐ「3重の自動防御陣」
これらを防止し、今後二度と /var/log の容量に悩まされないための設定を3ステップで仕込みます。
🧹 STEP 1：Journaldの最大上限を「200MB」に固定する
まずは、無制限に膨らみやすい journald（バイナリログ）に絶対的な上限サイズを設定します。
設定ファイルを開きます。 sudo nano /etc/systemd/journald.conf
ファイル内の [Journal] セクションにある以下の行を探し、コメントアウト（#）を外して上限値を指定します。
[Journal]
SystemMaxUse=200M※「200M」と指定しておけば、ログが200MBを超えた瞬間に、一番古いログから全自動で削除・上書きしてくれます。
設定を保存して閉じたら、サービスを再起動して反映させます。 sudo systemctl restart systemd-journald
🔄 STEP 2：logrotate の保持世代数を「2世代」に絞る
次に、syslog や mail.log などのテキストログの保持ルールを変更します。デフォルトの4週間保持から「2世代（2回分）」まで縮小します。
設定ファイルを開きます。 sudo nano /etc/logrotate.conf
ファイル内の以下の項目を書き換えます。
# ログ保持世代数を「2」に変更（古いものは自動削除）
# Change the log retention count to "2" (older logs will be automatically deleted)
rotate 2
# 過去ログを圧縮して容量を節約
# Compress old log files to save disk space
compressこれで、過去のログが何世代も無限に積み上がるのを防げます。
⏰ STEP 3：月1回、ゴミログを全自動で一括掃除するCronを仕込む
設定から漏れて放置されたサードパーティ製アプリが、変な場所に .gz ログを溜め込むケースもあります。 万が一に備え、「毎月1日の深夜に、古い圧縮ログ（.gz）や世代ログ（.1など）を全自動で一括削除するクリーンアップタスク」 を Cron に登録しておきます。
root の crontab を開きます。 sudo crontab -e
ファイルの最下行に以下の1行を追記します。
# 毎月1日の午前3時に、古い圧縮ログ(.gz / .1等)を完全削除してディスクをクリーンに保つ
# Permanently delete old compressed logs (.gz / .1, etc.) at 3:00 AM on the first day of every month to keep the disk clean
0 3 1 * * /usr/bin/find /var/log -type f \( -name "*.gz" -o -name "*.[0-9]" \) -delete > /dev/null 2>&1💡 今すぐ手動で数GBの空きを作る緊急避難コマンド
「設定はわかったけど、今まさに /var/log が3GB超えててヤバい！」という場合は、以下のコマンドを実行すれば即座に容量が解放されます。
1. 過去の古い圧縮ログ・世代ログを一括削除（安全）
sudo rm -f /var/log/*.gz /var/log/*.[0-9] /var/log/*/*.[0-9] /var/log/*/*.gz過去のバックアップログを消すだけなので、稼働中のシステムには一切影響しません。
2. Journalログを即座に100MBまで縮小
sudo journalctl --vacuum-size=100Mこれだけで、数GBあった /var/log が一瞬で数百MBまでスリム化します！
🏁 まとめ：構築と同じくらい「メンテの自動化」がインフラの肝
journald.confで上限（200M）を設定するlogrotate.confで保持世代数（rotate 2）を減らすcronで古い.gzログの定期削除を自動化する
インフラ構築の初期は「サービスが無事に動いたかどうか」にばかり意識がいきがちですが、本当に優秀なサーバーとは「運用者が存在を忘れていても勝手に綺麗さを保ち、何年間も落ちずに動き続けるサーバー」です。 最初にこの3ステップを仕込んでおくだけで、「ある日突然ストレージが100%になってサーバーがクラッシュする」というトラブルを未然に防ぎ、ストレスフリーなサーバー運用が実現できます。 まだ設定していない方は、ぜひ今すぐターミナルを開いてコマンドを打ち込んでおきましょう！
コメント