第14回 ログローテーションとAnalogの導入 、ログファイルの管理方法と、ログの分析手段として「Analog」の導入・運用方法を紹介する。 そうしたことが起こらないよう、定期的に管理・運用するのも管理者の務めである。そこで、ログの定期的なローテーションとその内容分析について紹介する。 そこで、最低でも週に1度くらいの割合で、ログファイルのローテーションを行う(図1)。このようにファイルをローテーションすることで、ファイル1つ当たりのサイズと含まれる情報を必要最小限に抑える。また、過去のログは何世代分か前のものまで保持し、必要に応じて過去にさかのぼれるようにするのである。 一志 達也<ichishi@pochi.tis.co.jp>TIS株式会社 2002/5/8
ログファイルのローテーション
この方式は時間をきっかけにローテーションするから、ファイル1つ1つのサイズは予測できない。それに、管理対象世代を過ぎたログは、自動的に削除されてしまう。従って、ログを残しておきたい場合は削除される前にテープ装置などでバックアップしなければならない。それでもログのサイズが大きくなり過ぎるようなら、ローテーションのタイミングや管理する世代数を見直さなくてはならない。このように、多少の工夫や配慮は必要になるものの、この方式は柔軟性も高く運用も容易である。そのため、Linuxや商用UNIXではログの管理にこの方式を用いることが多い。 ■ログローテーションを行う2種類のプログラム 最近のLinuxディストリビューションには、このログをローテーションするためのプログラムが初めから含まれている。それが「logrotate」である(注)。これは、通常「/usr/sbin」以下に用意されていて、「/etc/logrotate.conf」の内容に従って動作する。ただし、/etc/logrotate.confの設定を書き換えただけではlogrotateは動かない。実際にログをローテーションさせるためには、cronなどを使ってlogrotateを定期的に呼び出してやる必要がある。とはいえ、Linuxを導入した時点でcronの設定も行われているから心配は要らない。
logrotateでApacheのログをローテーションさせるなら、/etc/logrotate.confに設定を追加するだけでOKだ。しかし、Apacheにはログローテーションを行う独自のプログラムが付属している。それが「rotatelogs」である。 rotatelogsは、Apacheのバイナリが格納されているディレクトリ(通常は/usr/local/apache/bin)に用意されており、その設定はhttpd.confで行う。具体的には、次のように「TransferLogディレクティブ」を使う。
TransferLogディレクティブの設定値は、3つのパートから成る。
である。 上記の設定例の場合、access_logとerror_logのそれぞれを24時間(8万6400秒)ごとにローテーションする。ローテーション間隔は、必要に応じて長くしたり短くしたりすればよい。 ■logrotateとrotatelogsの違い logrotateとrotatelogsには、重要な違いが2つ存在する。切り出したログの履歴管理方法と、切り出し後のログファイルの扱い方である。 logrotateは、logrotate.confで指定した世代数(rotateで指定)を超えると、それより古いものは自動的に削除する。それに対し、rotatelogsは管理する世代数を設定しない。そのため、切り出したログファイルは管理者の手で消されるまでディスク上に保存されることになる。2つ目の違いは、logrotateが切り出し後のログファイルをクリアするのに対し、rotatelogsはログファイルをクリアしないことである。 この違いを踏まえて考えると、Apache標準のrotatelogsにはメリットもあればデメリットもある。メリットは、頻繁にログを切り出してもログが消えてしまう心配がないこと。デメリットは、切り出したログを整理しないと、ディスクの領域を浪費することだ。 Apacheのログを分析もせずに捨てるのは、あまり褒められることではない。有益な情報が多数記録されているからである。かといって、切り出した分のログがクリアされないのも、ディスク領域のことを考えれば問題となる。もしrotatelogsを使うのであれば、切り出した分のログをクリアする方法も併せて検討する必要がある。筆者は、シェルスクリプトを作って、切り出した分のログは余裕を持って削除していた(1日に1度、自動的に切り出し、2日前までのログを消していた)。 これらの問題を考慮すると、切り出されたログをちゃんと管理するという前提でlogrotateを使う方をお勧めしたい。
|
Analogの導入によるアクセスログの分析 「ログの分析」とは、記録されたテキストをある一定の基準で集計することにほかならない。たまたまテキストファイルだからそれが難しくなってしまうが、これがデータベース上のデータであればSQLで簡単にできることだし、表計算ソフトであればもっと簡単だ。もちろん、UNIXのコマンドに精通した人であれば、ある程度の分析(集計)は簡単にこなしてしまうだろう。 例えば、記録された行を数えれば「ヒット数」が分かる。これは、UNIXのwcコマンドで簡単にできる。しかし、そこから先はどんどん難しくなっていくし、それぞれの基準で集計コマンドをいくつも走らせるのは面倒だ。おまけに、結果をひと目で見ることもできないから、集計結果から何かを得るのが難しい。 そこで、こうした操作を自動化し、結果を見やすく編集するツールのニーズが生まれる。こうしたツールは多数用意されており、その機能も千差万別だ。高機能なものはWebサイト内の人気ランキングだけでなく、そこからどのページに移動する人が多いのか、どのサイトから移動してくるユーザーが多いのかなども容易に把握できる。 専門的かつ高機能なツールは、商用サイトのアクセスログの分析に用いられているが、価格も相応に高価である。その点、ここで紹介する「Analog」は、必要十分な機能を満たしているうえに無償であることから、多くのサイトで愛用されている。高価なツールほどの機能は求めないものの、ログを分析して情報を把握したい、といった向きにはぴったりだろう。 無償だから、まず試してみて不足を感じる部分を探してみるといい。そのうえで、不足している部分を補ってくれる市販のツールを探せばいいからだ。 ■Analogの導入 Analogのインストールは、だれにでも実に簡単に行える。Analogの公式サイト(http://www.analog.cx/、日本語はhttp://www.jp.analog.cx/)では、過去のバージョンも含め、多くの環境向けのファイルが配布されている。Linux用は、ソースコードのほかにRPMも用意されているから、RPMを使うのもいいだろう(編注)。
この手のツールはオプションをあれこれと指定することもない。従って、筆者もこの手のツールに関しては、RPMを積極的に利用している。ちなみに、RPMでソフトウェアをインストールする手順は以下のとおりだ。
無事にインストールされると、「/usr/local/bin/analog」や「/etc/analog.cfg」といったファイルが作られる。 ■Analogの出力とログファイルの関係 結果のサンプルは、筆者の実験機では自分のアクセスしかなくて参考にならないし、筆者の顧客のものを出すわけにもいかない。申し訳ないが、Analogの公式サイトに掲載されているもの(http://www.statslab.cam.ac.uk/webstats/stats.htmlあるいはhttp://www.jp.analog.cx/501/sjis/outsjis.html)を参考にしてほしい。 結果サンプルを見ると分かるとおり、Analogはログファイルに記録された情報を可能な限り個別の切り口に分けて集計する。このサンプルに掲示されている情報に限らず、設定のカスタマイズによってほかの情報(例えば使っているWebブラウザの種類など)を見ることもできる。 重要なのは、Analogが分析して表示できるのは分析対象としたログファイルの範囲に限られるということだ。これは当たり前のことだが、日別に切り出したログを分析させれば、その日の分だけを対象に分析が行われる。すなわち、ほかの日との比較は、出力結果を自分で見比べるしかないということである。必要であれば、分析対象とするログファイルを複数にすればよい。ただし、あまり多くのログ(例えば1年分)を分析させると、それだけ時間もかかる。どの単位で分析するか、試しながら調整していくしかないだろう。 |
Analogの設定 Analogの設定は、「analog.cfg」(通常は/etc/にある)を編集するだけで行える。とはいえ、200項目にも及ぶAnalogの設定項目を1つ1つ解説することは不可能だ。そもそも、初めからすべての項目を理解して使いこなす必要もないだろう。ほとんどの場合、基本項目で十分用は足りるはずだからだ。ここでは、最初に行うべき設定に的を絞って解説する。 ■表示する項目の設定 まず、Analogの結果として表示する項目を設定する。この設定は最後にするべきなのだが、それを最初に行うのには理由がある。それは、この設定を簡単に行うツールがAnalogに用意されているからだ。ツールは「anlgform.html」というファイルで、Analogを導入したディレクトリにある(画面1)。
日本語版のAnalogであれば、langディレクトリ以下に「jpform.html」という日本語化されたファイルがある(画面2)。
もしなければ(編注)、日本語Analogの公式サイト上でも配布されているので、そちらを参照してほしい。
上記のHTMLファイルをWebブラウザで開くと、表示するレポートの項目やその並べ替えの順序などを指定できる。好みに合わせて選択し、統計情報出力ボタンをクリックすると、Analogの設定ファイル(analog.cfg)に書き出される仕組みだ。 最初にこの手順を行うのは、このツールがanalog.cfgを書き換えてしまうからである。自分で書き換えた内容が、ツールによって書き換えられる可能性もあるので、最初に行っておくこととした。 ■分析するログファイルの設定 ここからは、設定ファイルを手動で編集する。といっても、その内容は拍子抜けするほど簡単だ。ファイルを開くと、「LOGFILE」で始まる行がある。これは、Analogで分析するログファイルを指定する命令である。 ここに、切り出したログファイルを格納しているディレクトリとファイル名を指定する。デフォルトではディレクトリの指定がないと思うが、ディレクトリを省略できるのはAnalogの実行ファイルと同じ場所にログファイルがある場合に限られる。通常は別のディレクトリに保存しているはずだから、ディレクトリも含めて指定することになる。 ここで重要なのは、複数のファイルを一度に分析したい場合の指定である。ファイル名を特定してしまうと、1つのファイルしか分析対象とならない。ワイルドカードで指定すれば、複数のファイルを分析対象にできる。もちろん、ファイル名に共通性がなければ意味はないのだが、通常は「access_log.日付」などのように共通性を持たせているはずだ。そこで、「access_log.200204*」(2002年4月分と指定する場合)のように、ワイルドカードを使って分析を行う。 ■出力するHTMLファイルの設定 次に、結果を出力するファイルを指定する。これは、先ほどの「LOGFILE」の次の行にあるはずの「OUTFILE」で指定する。 このとき、Apacheで参照できる(リモートでHTTPアクセスできる)ディレクトリに書き出すと、結果をリモートのコンピュータからWebブラウザで閲覧できて便利だ(セキュリティ対策は必要)。実際、筆者が担当したサイトでは、次のような仕組みで分析から閲覧までを自動化していた。 まず、分析結果を格納するディレクトリと、それに対応する仮想ディレクトリを作成しておき、その仮想ディレクトリへのアクセスにはユーザー認証を行うようにする。そして、1日に1度ログを切り出し、保存用のディレクトリに移動する(拡張子は日付になるようにする)。同時に、元のアクセスログから2日前までのログを消去する。 保存したログファイルは、週に1度Analogで分析し、結果を格納するディレクトリに出力する。出力した結果のファイル名は分析した日付になるようにする。これによって、過去の結果も閲覧できる。さらに、月に1度、保存しているログファイルから2カ月前の分をテープに吸い上げて削除する。 ここでポイントとなるのは、毎週変化するログファイルの拡張子や出力結果のファイル名をどうやってコントロールするかであろう。この場合は、スケジュール実行されるシェルスクリプトでanalog.cfgを書き換えることで実現した。 ■そのほか使い心地の修正 ここまでの設定で、分析が可能な状態になっている。後は、一度分析させてみて、自分なりに改良したいと思う部分について、該当する設定(命令)を見つけて設定ファイルを変更していくことになる。とはいっても、筆者の経験ではそれほど設定を変更する必要はないと思う。 ■Analogの実行 設定が完了したら、実行してみるだけだ。Analogの実行は簡単で、インストールしたディレクトリ(通常は/usr/local/bin)の、「analog」を呼び出すだけである。 ここで問題になるのが、ドメインの分析である。サンプル出力を見ても分かるように、Analogはアクセスの多いドメイン(.comや.co.jpなど)を集計し、表示する機能を持っている。ただし、これが表示できるのは、ログファイルにドメインが記録されている場合に限られる。通常、アクセスログには、負荷軽減のため、クライアントのIPアドレスのみを記録する。そのため、そのままのログをAnalogに分析させてもドメイン名による集計はできないのだ。 そこで、分析前にIPアドレスをドメイン名に置き換える作業を行う。これには「dnstran」のようなツールを使うのがいいだろう。ただし、IPアドレスをドメイン名に置き換える処理はネットワークやDNSに負荷をかけることになるので、その実施には十分な配慮が必要である。 |