ロギング · レッスン 6

ログファイルの管理

logrotate で安全なテキストログ rotation を設定、テスト、検証する方法を学びます。

上限のないテキストログはファイルシステムを使い切る可能性があり、削除が積極的すぎると運用や compliance に必要な証拠を失います。logrotate は、設定済みの size、time、compression、ownership、retention policy をファイルベースのログへ適用します。

Rotation を理解する

一般的な rotation は、有効ファイルを rename し、代わりを作り、必要に応じてアプリケーションへ reopen を要求し、古い世代を圧縮し、retention を超えたファイルを削除します。これらの手順は設定に依存します。保持コピーも削除・破損し、同じホストとともに失われるため、rotation は backup ではありません。

log rotation が backup や archival の代わりにならないのはなぜですか？

設定を見つける

main file は通常 /etc/logrotate.conf で、package または application snippet は /etc/logrotate.d/ 以下にあります。単純化した policy は次のようになります。

/var/log/example/app.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 example adm
}

これは daily evaluation、7 世代の retention、1 世代遅らせた compression、log が存在しないまたは空の場合の許容、明示的な mode と ownership の新規ファイルを要求します。実際の rotation は、記録された state と scheduler が logrotate を呼び出す方法にも依存します。

rotate 7 は何を指定しますか？

書き込み側と調整する

ログを rename した後も、daemon が開いたままの file descriptor を通じて旧ファイルへ書き続ける場合があります。postrotate script は、文書化された reload または reopen signal を送ることがよくあります。正確なアプリケーション動作を確認し、script の範囲を限定してください。

copytruncate はログを reopen できないアプリケーション向けに、ファイルをコピーして元ファイルをその場で truncate します。copy と truncate の間に write が失われたり重複したりする可能性があるため、普遍的に安全な default ではなく妥協策です。

rotation 後にアプリケーションへ reopen signal が必要な場合があるのはなぜですか？

有効化前にテストする

debug mode を使い、ファイルを rotation せず判断を調べます。

$ sudo logrotate -d /etc/logrotate.conf

debug 出力は、本番実行時に permission、script、free space、application reopen が成功することを証明しません。新しい rule は管理された環境でテストし、実行後に active file、rotated generation、ownership、compression、application output、logrotate status を確認します。-f は rotation を強制する状態変更オプションで、dry run と取り違えないでください。

logrotate -d から何が得られますか？

ほかの Store を考慮する

logrotate が管理するのは policy で指定した file です。systemd journal は独自の size と retention 設定を持ち、database と remote logging service にも別の lifecycle control があります。filesystem capacity と logging health を監視し、停止した writer や失敗した rotation を容量枯渇前に検出してください。

logrotate rule は systemd journal の retention も自動的に強制しますか？

レッスン完了