/var/logが肥大化する原因と正しいlogrotate設計

URLをコピーしました！

Linuxサーバー運用で頻発するトラブルの一つが、/var/log の肥大化です。気付いた時にはディスク逼迫、サービス停止、最悪の場合 inode 枯渇に発展します。

本記事では、なぜ /var/log が肥大化するのか、そして logrotate を正しく設計・運用する方法を、実務でそのまま使える形で解説します。

/var/logとは何か（役割の整理）

/var/log は、OS やミドルウェア、アプリケーションの動作履歴・エラーログを格納するディレクトリです。

OSログ（messages, syslog）
認証ログ（secure, auth.log）
cronログ
Web / DB / アプリログ

「自動で増え続ける」点が最大の特徴です。

/var/log が肥大化する典型的な原因

① logrotate が設定されていない

意外と多いのが、アプリ独自ログが logrotate 対象外になっているケースです。

② logrotate はあるが動作していない

cron が止まっている
systemd timer が無効
設定ファイルの記述ミス

③ アプリの異常でログが爆発的に出力

ループエラーや接続失敗により、1秒間に数百行ログが出ることも珍しくありません。

④ ローテート後のログが削除されない

rotate 数が多すぎたり、圧縮されていないとディスクを圧迫します。

/var/log 肥大化の初動確認手順

① ディスク使用量を確認

df -h /var

② /var/log 配下の使用量を特定

du -sh /var/log/* | sort -h

容量が突出しているログが一目で分かります。

③ inode 枯渇の併発確認

df -i /var

小さなログが大量にある場合、inode 枯渇も同時に起きます。

logrotate の基本構造

logrotate は以下で構成されています。

/etc/logrotate.conf（全体設定）
/etc/logrotate.d/*（個別設定）

全体設定の例

weekly
rotate 4
create
dateext
compress
include /etc/logrotate.d

これは「週1回・4世代保持・圧縮あり」の基本形です。

正しい logrotate 設計（実務ベストプラクティス）

① アプリ専用ログを必ず個別定義

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

copytruncate は、アプリ再起動不可な環境で特に重要です。

② ログ出力量に応じて daily / weekly を使い分ける

大量ログ：daily
低頻度ログ：weekly

③ rotate 数は業務要件で決める

「何日分のログが必要か？」を基準に設計します。

logrotate が動いているかの確認方法

① 手動実行で確認

logrotate -d /etc/logrotate.conf

-d はデバッグモード（実際には削除しない）です。

② 強制実行

logrotate -f /etc/logrotate.conf

③ cron / timer の確認

systemctl status logrotate.timer

やってはいけない対処（事故例）

ログファイルを直接削除

rm -f /var/log/messages

→ プロセスが掴んだままになり、容量が解放されないことがあります。

正しくは：

truncate -s 0 /var/log/messages

/var/log 肥大化の再発防止策

logrotate 設定の定期レビュー
/var 使用率・inode 使用率の監視
異常ログ増加のアラート
アプリ側ログレベルの見直し

運用現場でのチェックリスト

新規アプリ導入時に logrotate 設定したか
rotate 数は適切か
圧縮は有効か
cron / timer は生きているか

まとめ

/var/log 肥大化は、設計と運用で100%防げる障害です。

logrotate を正しく理解し、

ログの種類
出力量
保持期間

を意識して設計すれば、ディスク障害・inode 枯渇は確実に減らせます。