/varの容量が事前に増えないようにする対策

Question

/dev/sda1 ext4 8.1G 4.6G 3.1G 60% /

rootしかパティーション切ってないサーバが30台があります。（esxiサーバで仮想化されています。）

/の容量はほとんど8〜10GB程度です。

今年末にこのサーバ群は破棄してAWS化する予定でありますが、

最近、いきなりapacheのエラーが増えて/が100%になってサーバが止まるところまで至たり題となったことがありました。（ちなみにこのサーバはsvnサーバです）

今後の防止対策として何かを考えなければならないですが、
もうすぐ移行するサーバなのであまり運用にコストかけたないし
でも今年末まではこのようなことを防ぐためなんらかの対策は必要なので
何かいい対策があれば教えていただきたいです。

やりたくないこと
・ログはセキュリティ上保存期間があるので一定期間は残す（ロテートはすでにされてる）
・30台のサーバに物理のハードディスクを足すことはしたくない

今やろうとしてること

・特定のIPからxx万件以上のエラーログを出したらログを吐かないようにする
・特定ログの容量が1GB以上になると/etc/cron.hourlyクロンからキャッチし圧縮するか警告を出すようにしたい

何かよい案があればご教示いただきたいです

Answer 1

最近、いきなりapacheのエラーが増えて/が100%になってサーバが止まるところまで…

という状況であれば、ログの扱いに技巧を凝らすより、anonymouskawa さんのご提言のように、まずは日次でログを圧縮し、サーバーダウンという最悪の状況を避けることが先決かと思います。

その上で、もし必要であれば、たとえば /var 配下とか、もっと細かく 特定のログ出力先 にディレクトリを容量制限し、サーバー全体のダウンを機械的に回避すると良いと思います。その際、こんな方法 で確実に容量制限することができます。

いずれサーバーのお引越しがあるとはいえ、ログが大量に出力される状況は決して望ましいものではないので、実際にお引越しするまでの間に是非、根本原因を探って対処なさると良いと思います。

• そもそも、ログレベルの設定は適切か
• 異常なログ出力を引き起こしているアクセスは、その妥当性を検討し場合によってはアクセス自体を制限する必要はないか
• 他にエラーを誘発するような要因はないか
• 各種サーバーにチューニングの余地はないか
  …などなど

以上、いくらかでもご参考になれば幸いです。

Answer 2

・日次でログを圧縮する（1Gと言わず、毎日圧縮してしまう）
・年末といっても4ヶ月あるので、Apacheのエラーを解析してエラーの原因から根絶させる（理想）

あとは、容量が80％以上になったらメール通知し、手動でファイルをローカルに移動するなど
原始的な手法でしょうか…

Answer 3

圧縮していないのなら、圧縮する。
また、compressオプションでログの圧縮形式をxzやbz2に変える。

7.0M Aug 27 08:21 messages.log
567K Aug 27 08:21 messages.log.gz
280K Aug 27 08:21 messages.log.bz2
172K Aug 27 08:21 messages.log.xz

ただし、CPU(時間)を食うので注意が必要です。

Answer 4

ログはtd-agentでログ解析専用サーバに転送する。。。