logrotate 設定方法


logrotate とは

logrotateとは、Linuxに備わったログを定期的にリネーム/削除する仕組みで、ログの肥大化によるディスク溢れを防止する機能です。RPMでパッケージをインストールする場合は自動的にlogrotateが設定されるので、今日では意識する事は少なくなりました。

しかし、以下のような場面ではlogrotateを手作業で設定しなければなりません。

  • ネットワーク機器のログをsyslogd (rsyslogd) で収集する場合
  • 初期バージョンのミドルウェアを使用する場合 (初期バージョンのミドルウェアはログローテーション等の運用関連の設定の作りこみが甘い事が多いです。)
  • なぜかログローテーションされない不具合に遭遇してしまった場合

ネットワーク屋さんならば、「ネットワーク機器のログを収集する」場面に出くわす事が多いと思いますので、知っていて損はない設定であると思います。ネットワークでない人も、(私の経験から推測して)年に1回程度は必要になる知識であると思いますので、覚えておいて損はないと思います。

logrotateの構成と簡単な動作確認

logrotateの構成

logrotateは/etc/logrotate.confというファイルにログローテーションに関する全体の設定が記述されています。以下は、CentOS6.5のデフォルト設定の/etc/logrotate.confです。

このlogrotate.confをよく見ると、/etc/logrotate.dをincludeしているのが分かります。/etc/logrotate.dには、各ミドルウェア毎にログローテーションの設定が記述されています。/etc/logrotate.d以下のファイルは、多くの場合はRPMによるインストールと同時に作成されるので、意識した設定を行なう必要に求められる事は滅多にありません。

logrotateの定期実行

/usr/sbin/logrotateというプログラムが定期的に実行する事によって、ログローテートが実行されます。ディストリビューションにもよりますが、CentOS6.5の場合は、/etc/cron.daily/logrotateに日次で/usr/sbin/logrotateを実行する設定が記述されています。

logrotate ローテーション対象の追加

ログローテーション管理対象とするログを増やす場合の設定を紹介します。このページでは、/var/log/snmpdをログローテーションする例を紹介します。なお、snmpdのログ出力方法については、snmpd 設定方法を参照下さい。

syslogd ( rsyslogd )が出力するログの場合は、/etc/logrotate.d/syslogにローテーション対象とするログファイルを追加します。

logrotate ログローテーションの強制実行

logrotateは日次, 週次で行なわれる処理ですが、次の処理実行まで待って設定がうまくいったかどうか確認するのは非常に非効率です。そこで、logrotateを強制的に実行する方法を紹介します。

logrotateコマンドは以下のように引数に設定ファイルを取る事ができます。マニュアルやブログ記事などを見ると以下2つの流派がありますが、私は/etc/logrotate.confを引数に取る方法が好きです。/etc/logrotate.d/syslogを引数に取ると全体に関わる設定が読み込まれず、定期的に実行されるlogrotateと挙動が異なってしまうためです。

logrotateは、引数-fを取る事によって、強制的に実行する事ができます。ログをローテートすべき日時になっていなくても、強制的にログローテーションを実行する事ができます。

logrotateコマンドが実行されましたら、lsコマンド等でログがローテーションされた事を確認します。

logrotate ログローテーションのデバッグ

もし、ログローテーションが想定通りに動かない場合は、-dでデバッグする事ができます。

私は早とちりしてしまったのですが、-dはデバッグ実行ではなくデバッグログを出力する機能である事に注意して下さい。以下はマニュアルの引用ですが、”In debug mode, no changes will be made to the logs or to the logrotate state file”とログローテーションしない旨が明記されています。

logrotate ログローテーション日付の管理

何回かlogrotateコマンドを実行しつつデバッグ作業を行なうと、ログローテーションが全く行なわれなくなってしまいます。これは、logrotateが内部的にいつログローテーションを行なったかを管理しているからです。

/var/lib/logrotate.statusというファイルを参照すると、いつログローテーションが行なわれたのかが記録されているのが分かります。

もし、ログローテーションが行なわれなくなってしまったのならば、以下のように/var/lib/logrotate.statusを過去日付に書き換えた後に、”logrotate -f”コマンドを実行すると良いでしょう。

ログローテーション前処理 – postrotate

ログローテーションはログファイルの名前変更や削除を行なう処理です。実は、ログローテーションを行なう際は、アプリケーションにログの出力先を変更するように指示しなければなりません。以下はapacheログを例に挙げた例ですが、もし出力先を変更するように指示しない場合は/var/log/httpd/access_log-20140725という古いログファイルにログが出力され続けます。

ログの出力先を変更する方法はアプリケーションによって異なります。ここでは、いくつかのデフォルト設定を紹介します。

ログローテーション前処理 – SIGNAL

syslogの場合はHUPを送る事によって、新しいログファイルにログが出力されるようになります。以下は、/etc/logrotate.d/syslogのデフォルト設定です。ログローテーション前に、syslogd ( rsyslogd )に対してHUP SIGNALを送っている事が分かります。

以下は、/etc/logrotate.d/td-agentのデフォルト設定です。td-agentの場合は、ログローテーション前にtd-agentに対してUSR1 SIGNALを送っている事が分かります。

ログローテーション前処理 – reload

以下は/etc/logrotate.d/httpdのデフォルト設定です。apacheの場合は、ログローテーション前にreloadしているのが分かります。

実際に私が経験した障害なのですが、reloadで再起動しないzombiプロセスができてしまった場合は、accesslogは古いファイルに出力され続けてしまいます。もし、このような現象に遭遇しましたら、restart、それでもダメならばkillするしかありません。

ログローテーション前処理 – mysqladmin

MySQLの場合はかなり特殊な処理をしています。ログローテーション前に、”mysqladmin flush-logs”を実行しています。このような処理を滅多に意識する必要はございませんが、コンパイルしてmysqlをインストールする場合やいわゆるα版のMySQLを使用したい場合は必要になる知識ですので、頭の片隅においておくと良いでしょう。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする