logrotate 設定したが、 ログがローテートされない備忘録

こんにちは。次世代システム研究室のB.V.Mです。宜しくお願いします。
(外国人で言葉遣いが間違いましたらご容赦ください。)
logrotate について小さなユーザーケースに勉強されたことがあって、備忘録というものを残したいと思います。
学びとは、「logrotate の設定が正しくてもログローテーションされない事がある」、「dry-run だけは足りない」ということだと思います。
logrotate.confにより設定されたコンフィグが結合的テストのが大事です。そして問題の根本的な原因を把握することのもとても大事だと考えています。

目次

1. 背景

ログファイルが突然大きくなって（今回はapi_http_request.log）、原因調査間にログの保存期間は普通のように長く保存できなくなり、保存期間を一旦調整して短くします。

1.1 初期の対応

/var/log/のフォルダに色々ログファイルがあって、下記のように新規Logrotate設定ファイルを適用しました。

cat /etc/logrotate.d/api_http_request
/var/log/api_http_request*.log {
    daily
    rotate 10 // 90 → 10に変更した
    dateext
    missingok
    compress
    notifempty
    nocreate
    delaycompress
}

書いた設定を実装してみたかったら-fか-dオプションは確認できます。

       -d, --debug
              Turns on debug mode and implies -v.  In debug mode, no changes will be made to the logs or to the logrotate state file.

       -f, --force
              Tells  logrotate  to  force  the rotation, even if it doesn't think this is necessary.  Sometimes this is useful after adding new entries to a
              logrotate config file, or if old log files have been removed by hand, as the new files will be created, and logging will continue correctly.

-dはデバッグモードなので情報が多く出ています。実行してみると：

sudo logrotate -d /etc/logrotate.d/api_http_request
reading config file /etc/logrotate.d/api_http_request
Allocating hash table for state file, size 15360 B

Handling 1 logs

rotating pattern: /var/log/api_http_request*.log  after 1 days (10 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/api_http_request*.log
  log /var/log/api_http_request*.log does not exist -- skipping

「wc -l 」コマンドで結果確認したら確かにログファイルが圧縮、削除されました。というのはconfigファイルの内容が問題ないでした。

ls /var/log/api_http_request.log* | wc -l
11

2. 問題発生と対策

2.1 問題

検証環境で適用したら、設定はdailyのため次の日は結果確認しました。ところが、ログローテートされなかったです。設定ファイルが手動で実行したのに何故か実際に動かなかったです。しばらく調査すると原因がわかりました。
元々、/var/log/フォルダーにある設定がありまして、そのルールはそのフォルダーの中のログファイルが適用されています。ファイル内容は以下のようです。

/var/log/*.log {
    daily
    rotate 90
    dateext
    missingok
    compress
    notifempty
    nocreate
    delaycompress
}

結論から言うと問題発生原因は：設定したルールが重複したことです。
検証方法：logrotate -s でログローテートの結合テストみたいです。これは大事です。１つの設定ファイルが問題なくてもセットで組み合わせるときに問題が発生されることもあります。

sudo logrotate -s /var/lib/logrotate/logrotate.status /etc/logrotate.conf
error: api_http_request:1 duplicate log entry for /var/log/api_http_request.log

man logrotate
...
-s, --state 
    Tells  logrotate  to use an alternate state file.  This is useful if logrotate is being run as a different user for various sets of log files.
    The default state file is /var/lib/logrotate/logrotate.status.

2.1 対策

３つ案があります。
案１：Wildcardで適用ファイルを除外します。
「/var/log/*.log」のルールが「/var/log/[!a]*.log」に修正します。
意味は”a”で始まったログファイルを飛ばします。この案は問題が対応できるが、もしapi_http_response.logファイルがあったら、不具合になってしまいます。
ちなみに、「/var/log/[!a][!p][!i]*.log」とかも検証したが結論的に対応できないです。
→この案は選べられません。

案2：api_http_requestログを別フォルダーに移行してそのフォルダーにルールを適用します。
フォルダー「/var/log/」から「/var/log/api/」に移行するなどです。こちらの案は対応できるし、ログごとにルールが適用できます。
ですが、もしログに関するのNFSサーバーへ転送するやログ分析ツールに転送するなどが適用されていたら、色々修正箇所が必要です。頑張って対応したら対応できるけど、気持ちがよくないと思います。

案３：根本の原因を調査します。
背景のところにも説明したが、ログファイルが突然大きくなっていて、問題を調査します。結局、直近追加したのコードは不注意であるドキュメントの内容を全部ログに出したところがあるのがわかりました。その原因により、ログファイルは数MBから数百MBになってしまいました。そのコードを修正して、ログファイルのサイズは元に戻りました。なので、ログローテートは新規ルール適用必要なくなりました。

3. 感想

ログローテートは-dで検証できますが、-sで結合的にテストのは大事でした。そして、色々検証していたが、結局根本の原因が理解できて、修正必要なくなったことは私にとって残念なことでしたが、いい勉強になりました。同じことが発生しないようにご注意ください。