サーバを用意するに当たり、計画しないといけないものの1つにログがある。だいたいは
- httpサーバのアクセスログ
- 同エラーログ
- アプリのログ(SQLのログ)
この3つは管理せねばならない。なので、ウェブアプリが作成されたら、吐かれるログファイルの場所とどう扱うか、は計画的に行い、チェックリストの類を用意して確認して設定すべきである。
原則として、決めねばならぬのは以下ぐらいであり、これらを回避するためにlog correctorの類を使うこともある。使うのがベターなんだろう。
- 生テキスト -> 圧縮 -> 削除/移動 のライフサイクル
- 並列処理の場合、またがっているのを1つにマージする方法(時系列に直列になってないとログの意味が薄い)
- ファイルの命名規則
- 圧縮保存する期間
この辺りのポリシーを決めるには以下のような要因がある。
- カスタマーサポートの期間
- お客様との契約
- カスタマーサポートエンジニアがチェックする分量など
- サーバコスト
- ディスクをできるだけ使わないのか
- 何日削除処理しなくて動き続ければいけないのかなど
とりあえず、テストの段階からどれぐらいの勢いでログが増えていくのかチェックしていけば本番のディスクとか予想できてよかろう。
まとめると
以下ぐらいはチェックリストを作って管理したい。
- Webアプリのログはどこにでるのか
- 方式は？
- ログ保存期間
- 生 > 圧縮 > 削除のタイミングは？
- 保管期間は？
- ディスク消費量の監視
- 1日あたりどれだけ増えるのか？
- この調子でいくと何日持つか？
でも logrotate.d でいいじゃん
とりあえず logrotate.d なら確実に使えるわけで、スモールスタートで、ディスクもケチりにケチったりする場合なら必ず使うであろうこれ。
*.1とかありえないので最低限以下をconfに
logrotate.conf
# use date as a suffix of the rotated file
dateext
ディスクの消費は zabbix だの munin だので確認すること。