実務で稼働中のSyslogサーバに集約している一部のログについて，ログローテーション(今回は圧縮のみ)できていないことが判明しました。
調査した結果，crontabで設定している実行コマンドにおいて，findコマンドの検索条件が適切でなかったことが原因でした。
本稿では，ログローテーションが期待通りにできていないと判明してから原因を特定するまでの経緯について解説します。
前提知識
Linux
UNIX系OSの一種です。
SolarisなどのUNIX系OSと異なり，LinuxはOSSとして公開されており，無償で利用できるディストリビューションが多く存在します。
Syslog
サーバやネットワーク機器などが出力するログメッセージを，送受信・記録するための標準的な仕組みです。
ログイン履歴やログイン失敗履歴，システムの状態など，機器によって様々なログを記録しています。
今回の環境では，複数のネットワーク機器からSyslogサーバへログを集約しています。
crontab
cron(定期的にジョブを実行する仕組み)で実行するコマンドやスケジュールを設定するために使用します。
イツキWindowsでいう「タスクスケジューラ」だよ！
ログローテーション
ログファイルを一定の期間や容量ごとに切り替え，古いログを圧縮・削除するなどして管理する仕組みです。
ログファイルが増え続けることによる，サーバのディスク容量逼迫を防ぐ目的で主に導入します。
なお，ログローテーションの方法は環境によって異なり，Linuxではlogrotateなどのツールを利用する方法もあります。
今回の環境では，cronからコマンドを実行してログファイルの圧縮を行っています。
環境
日次で各NW機器のログをSyslogサーバへ集約しています。
集約しているログは以下の通りです。
- yyyymmdd.log(20260401.log等)
- yyyymmdd.log-yyyymmdd(20260331.log-20260401等)
集約したログは，最終更新日時から31日以上経過したログを対象として，cronにて圧縮処理を実行しています。
実務での対応
事象
集約しているログのうち，最終更新日時から31日以上経過しているにもかかわらず，圧縮できていないログがありました。
- yyyymmdd.log
→圧縮ができており，「yyyymmdd.log.gz」が存在することを確認済み。 - yyyymmdd.log-yyyymmdd
→圧縮ができていない
切り分け
原因調査にあたり，以下を確認しました。
- crontab設定内容
→毎日午前0時に圧縮を実行する設定となっている。 - cron実行ログ
→cron自体は問題なく実行していることを確認したが，エラー(※1)も起きていた。
- 一部のログで，圧縮済みファイル(yyyymmdd.log.gz)が既に存在することによる上書き防止でエラーとなっていた。
メグミエラーはずっと放置状態だったんですか？
イツキそういうことになるね(汗)
エラーもありはしましたが，cron自体は問題なく実行できていそうなことを確認しました。
上記を踏まえて，次にcronに設定している実行コマンドを確認することにしました。
原因：cronに登録しているfindコマンドの検索条件誤り
cronでは，findコマンドを使用して指定した条件に一致するログを検索しています。
実際に，crontabには以下のように登録してありました。(毎日0時0分にログローテーション(find以降のコマンド)を実行する。)
0 0 * * * find /var/log/syslog -name “*.log” -mtime +31 -exec gzip {} \;
上記のfindコマンド検索条件にある「*.log」では，「yyyymmdd.log」は検索できますが，「yyyymmdd.log-yyyymmdd」を検索できません。
実際にfindコマンドを実行すると，以下のような結果が返ってきます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$find /var/log/syslog -name "*.log" -mtime +31 /var/log/syslog/RouterA/20260401.log /var/log/syslog/RouterA/20260402.log /var/log/syslog/RouterA/20260403.log /var/log/syslog/RouterB/20260401.log /var/log/syslog/RouterB/20260402.log /var/log/syslog/RouterB/20260403.log /var/log/syslog/L3switchA/20260401.log /var/log/syslog/L3switchA/20260402.log /var/log/syslog/L3switchA/20260403.log /var/log/syslog/FireWallA/20260401.log /var/log/syslog/FireWallA/20260402.log /var/log/syslog/FireWallA/20260403.log |
以上の結果から，「yyyymmdd.log」は検索できていますが，「yyyymmdd.log-yyyymmdd」を検索できていないことが分かります。
対処：findの検索条件見直しとスクリプト化
「yyyymmdd.log-yyyymmdd」も検索できるようにするだけであれば，findの条件を以下のように修正すれば対応できます。
＜修正前＞
find /var/log/syslog -name “*.log”
＜修正後(案)＞
find /var/log/syslog \( -name “*.log” -or -name “*.log-[0-9]*” \)
しかし，現状で以下の問題点があることから，今回は単純に検索条件を修正するだけではなくスクリプト化する方向で決定しました。
- cron実行ログの分かりにくさ
パッと見ただけでは，処理結果を確認しにくい。 - エラーの見落とし
エラーが発生していても，cron実行ログが分かりにくいため見落とす可能性も高い。 - 運用設計の未策定
そもそも運用設計も確立していないため，定期的にcron実行結果を確認する習慣もなかった。
スクリプト化の詳細は，別の機会に解説します。
教訓
Windowsのタスクスケジューラでも言えるように，crontab設定前には実際にコマンドを手動実行してみることが重要と改めて実感しました。
今回の件も，crontab設定前に手動実行していれば，問題に気付けた可能性が高いです。
また，コマンドを実行して終わりにせず，実行後の結果まで確認することも重要です。
結果の確認をおろそかにすると，重大なエラーに気付かないまま放置する事態にもなりかねません。
設定して終わりではなく，結果の確認まで一貫して行うことが重要！
まとめ
本稿の要点をまとめると以下の通りです。
- crontab設定前にまずは手動で実行する
- 実行後の確認もおろそかにしない
今回の問題は，findの検索条件を誤っていたことが直接的な原因でした。
しかし，問題の発覚が遅れた背景には，実行結果の確認をおろそかにしていたこともあります。
スクリプト化による自動化は作業効率化や品質確保の点で有用な一方で，自動化した処理も登録して終わりではありません。
実行結果を確認し，問題があれば改善するところまで一貫して行うことが，継続的な運用改善につながります。
本稿を参考にすることで，何かしらの運用改善につなげていただけたら幸いです。
