前回は sudo コマンドの実行履歴を auth.log から分離することを検討したが、効果が少ないことから不採用とした。 Debian GNU/Linux の運用におけるログ管理においては、ローテーション間隔が調査効率や安定運用に直結する。デフォルトの weekly では週末に向けてサイズが肥大化し、閲覧や検索が重くなることがあった。そこで、rsyslog の主要ログを daily に変更し、保持期間は従前からのポリシーに則り 3 ヶ月（rotate 90）に統一することにした。本稿はそのメリット・デメリット、設定を整えるスクリプト、所有権とパーミッションの注意点をまとめた。
変更の背景
- weekly では週末に巨大化し、調査が重くなる。
- 障害やインシデントの切り分けで、日次単位の区切りが欲しい。
- ポリシー上、ログは 3 ヶ月保持（daily と rotate 90 の組み合わせが素直）。
daily にしたメリットとデメリット
メリット
- 日次で区切られるため対象日の特定が速く、解析がしやすい。
- 週末に巨大ファイル化しにくく、grep 等の操作が軽い。
- 3 ヶ月保持ポリシーにそのまま適合する。
デメリット
- ファイル数が増える。今回の対象 6 種類 × 90 世代 = 540 ファイル。
- 連番形式だと日付が直感的に分かりにくい。dateext を使うかは運用ポリシー次第。
- ローテーション回数は増えるが、圧縮対象が小さくなるため実負荷は軽微。
3 ヶ月保持（rotate 90）の考察
- 監査やインシデント対応に必要な 90 日分を確実に保持できる。
- より長期の分析（半年〜1 年）は別のログ基盤（例: syslog サーバー、ELK、Loki など）で対応するのが現実的。
- バックアップ方針は要整理。圧縮済み過去ログはバックアップの対象外にするなどの最適化が有効。
ローテーションのオーバーヘッド
- 主な処理はファイルのリネームと古い世代の圧縮。
- daily にすると週比で回数は増えるが、各ファイルが小さくなるため CPU/I/O の実負荷は小さい。
- モダンな環境では定常運用への影響はほぼ無視できる。
切り替えタイミング
- systemd タイマーや cron.daily に依存。環境例では 毎日 00:35 前後に実行。
- weekly の場合は週 1 回の早朝に実行される設定が一般的。
- 夜間バッチと重なる場合は時間調整を検討する。
設定スクリプトの要点
設定変更に際しては手作業での適用を避け、冪等性のあるスクリプトを作成し全環境に一律で適用することにした。
- /etc/logrotate.d/rsyslog のタブを 4 スペースに統一してから編集する。
- 各ブロック内に必ず daily と rotate 90 を入れる（無ければ追加、あれば正規化）。
- ブロック開始は行末の波括弧にも対応する。
- 最後に所有権とパーミッションを root:adm 640 に強制。
- 実行後にファイルの最終内容を表示して人間が確認できるようにする。
パーミッションの注意点
- logrotate は設定ファイルの ユーザー所有者が root（uid 0）でないと読み込まない。
- グループは adm でも root でもよい。パーミッションは 640 でも 644 でもよい。
- 所有者が root 以外だと「Ignoring rsyslog because the file owner is wrong」となりスキップされる。
dateext の採否
- メリット: 日付で探しやすく、監査上の追跡が容易。
- デメリット: 既存スクリプトが連番前提なら互換調整が必要。欠損が日付で目立つ。
- 人間が直接ファイルを追いかける運用なら採用を検討。ツール中心なら連番のままでもよい。
影響しうる周辺コンポーネント
- fail2ban: auth.log のローテーション後も参照パスは変わらないが、ローテート直後の再オープンは logrotate の postrotate フックに依存。
- logwatch/logcheck: 日次レポートは daily との相性が良い。
- 監査・監視ツール: ログサイズや更新時刻監視の閾値は再調整が必要な場合がある。
チェックリスト
- /etc/logrotate.d/rsyslog の所有権が root:adm、モードが 640 になっている。
- logrotate のステータス (/var/lib/logrotate/status) で最新日付が記録されている。
- 手動の強制ローテーションで意図どおりに世代が進む。
- postrotate に rsyslog の再オープン処理が書かれている。
まとめ
- weekly は週末肥大化で調査効率が落ちやすい。daily + rotate 90 は 3 ヶ月保持ポリシーと相性が良い。
- ファイル数は増えるが、システム負荷は小さく、実運用上のメリットが大きい。
- 所有権チェックは落とし穴。必ず root 所有にそろえる。
同様の要件がある環境では、daily 化とパーミッションの徹底、必要に応じて dateext の採否検討をセットで進めるとよい。