ログ解析の解説

作成
2007/06/12 Tue
更新
2008/04/13 Sun

概要

 まだ書きかけです

 当サイトが使っている著名なWebサイトのログ解析ソフトAnalogによるログ解析について解説します。


◎目次

  1. Analogについて
    1. 全般
    2. 特徴と注意点
    3. 検索の解析結果の文字化けの防止
    4. 解析結果を蓄積しない(ログを保存しておく範囲)
    5. ログ圧縮の対応
  2. 解析結果の解説{未記述}
    1.  

1.Analogについて

1−1.全般

 当サイトは、Analog6でログの解析を行い公開しています。AnalogはWebサーバが出力するログファイルをわかりやすく解析してくれるログ解析ソフトです。結果の表示が国際対応していて、もちろん日本語で表示できます。日本語の場合、EUC-JP、ISO2022-JP、SJIS、UTF-8の4コードに対応しています。

 本家はhttp://www.analog.cx/、(日本語はhttp://www.jp.analog.cx/)です。非常に有名ですので公式ページ以外にもあちこちに紹介をしたページがあります。

1−2.特徴と注意点

 設定などは、他のページに譲るとして、特徴と、紹介ページを見ながら設定した結果、気がついた事について以降に記述します。

 自宅サイトの一般的な解析にはおつりが来ます。

 上記の特徴に引かれてインストールしてみたところ、あまり取り上げられていない、ちょっとした留意点があるのが分かりました。

参考

  1. Analog
  2. 日本 Analog ユーザ会
  3. 第2回:オープンソースアクセスログ解析ソフトの解析結果(1)
  4. @IT 第14回 ログローテーションとAnalogの導入
  5. Linuxで自宅サーバ Apache ログ解析 Analog の導入

1−3.名前解析をさせると解析時間が増加

 DNS検索という機能があります。analog.cfg内に「DNS WRITE」を指定すると、IPアドレスが逆引きされて名前で表示されるようになり、DOMAIN解析なども出来るようになります。

 当サイトの場合、これを指定しなければ、解析は手動ではかかった時間が分からない程度しかかかりませんが、指定した場合、30秒弱かかるようになります。これは解析そのものの負荷が高まったわけではなく、DNSの逆引きの時間が足を引っ張っているようです。

 サーバなどのアドレスは普段DNSで引かれていますのであちらこちらのDNSにキャッシュで残っています。ところがAnalogで逆引きされるアドレスのほとんどはクライアントなので、通常DNSに問い合わされる物ではありません。この為、リゾルバは各クライアントが所属するドメインの本当のDNSまで再帰的に名前の解決を実行することになります。

 この時間はAnalog自身の処理がいかに早くても関わりなくかかる時間です。Analogもこの問題について自身で「DNSFILE」で指定したファイルにDNSキャッシュを持つことで対処しているのですが、このキャッシュが利用できない場面があります。

 ログがすでにたまっている状態で、Analogを初めて導入する場合、AnalogのDNSキャッシュはまだ構成されていないので、全てのIPアドレスのDNS逆引きを実行することになります。当サイトの場合、最初の半月ほどしてから導入したのですが数十分ほどかかりました。

 この時間はDNSがどのくらいで引けるかに大きく影響を受けるせいか、ほとんどのところで説明が無く、待っている間心配になりますが、環境によっては時間がかかる物ですので待ってみてください。

1−4.検索の解析結果の文字化けの防止

 結局、LANGUAGE JAPANESE-UTFを指定してしてUTF8で解析結果のページを作成すれば実用最低限の文字化け回避が出来ます。以下でこのことを説明します。

 Analogには「検索語句レポート」と「検索語レポート」という解析項目があります。自サイトがどんな検索語で検索された結果参照されるのかが分かる便利な機能です。

 ただ、Analog本体の多国語対応がこの辺うまくいっていないらしく、検索語の文字が化けます。これを補うためにanalogurldecodeと言うソフトウエアが公開されています。

 ところが、Analog6ではどうもうまく動かないので「検索語句レポート」と「検索語レポート」の利用を断念しかけました。しかしログをよく見ると、検索語は基本的にUTF8でエンコードされています。そこでLANGUAGE JAPANESE-UTFと指定してしてUTF8で解析結果のページを作成すれば字化け回避が出来ないか試したところ、ほとんどの文字が化けずに済みました。これによりanalogurldecodeを使わずに実用最低限の文字化け防止をして当サイトは運用しています。

 これは、SJISやEUCが検索語として使われているとうまくいかないはずです。現在ほとんどがUTF8で検索されているのでうまくいっているだけですので、なんとかしてもっと確実な方法を工夫したいとは思っています。

1−5.解析結果を蓄積しない(ログを保存しておく範囲)

 Analogは、LOGFILEで指定したファイルを解析して解析ページを作り上げます。LOGFILE /var/log/httpd-access.log*などと指定するとパターンにマッチする全てのログが用いられて解析ページを作り上げます。

 MRTGの様に自分で過去のデータを処理したデータベースを持たないので、蓄積性はありません。Analogは、同じログを対象にすれば何回やっても同じ結果になります。この為、1年の傾向を解析させようとすると、ログが1年分残っている必要があります。

 たとえば四半期ごとの傾向を比べようと思えば最低限4四半期分つまり1年のデータが必要になります。前年のデータと比較したいと思えば2年分のデータが必要になります。この為、長期の傾向を解析させるには、それに見合った容量の保存場所が必要です。当サイトの様な小規模な自宅サイトの場合でさえ、2007/5/14に仮稼働して現在(2007/06/24)までで4,150,062Byteになっています。これは1日あたり100Kbyte強になります。グローバルアドレスの割り当てが行われたのが2007/05/21、初めての被リンクが2007/06/02ですから、計測期間の前半はほとんどアクセスのない状況ですので、通常の自宅サイトはこれを下回ることはない物と思います。実際、被リンクをいただいた以降のログは1日あたり130Kbyte程度有ります。

 よって1年の解析を想定すると、当サイトの場合37Mbyteは間違いなく必要で、46Mbyteは用意する必要があり、安心のためには10倍程度の370Mbyteの保存エリアが欲しくなることになります。

1−6.ログ圧縮の対応

 Analogは解析に必要な期間のログを必要にします。数年に渡る解析にはかなりの量のログが必要です。Apacheのログは圧縮がよく効くので多くのログを保存するには圧縮が有効です。FreeBSDのportsで導入したAnalogは少なくともbz2に対応している(2007/06/24 Sun現在)ので圧縮をかけてローテーションするのが有効のようです。

 ただ、当サイトの場合、初期に対応するかどうかよく分からなかったことと、解析時間の予測が立たなかったので圧縮なしで保存しています。時期を見て切り替えたいと思っています。


2.解析結果の解説

2−1.まず全体の傾向をつかもう

 まず、統計で最低限の傾向を押さえるには、「全体の概要」を確認するのが早道です。

全体の概要の例

全体の概要

このレポートは、全体の統計を表します。

括弧内の数字は 右の日時までの直近7日間の集計 : 2008年 4月13日 11時45分.

リクエスト成功件数: 320,384 (10,153)
上記の日別平均: 977 (1,450)
ページリクエスト成功件数: 44,076 (1,139)
上記の日別平均: 134 (162)
リクエスト不成功件数: 2,572 (36)
リクエストリダイレクション件数: 9 (0)
異なるリクエストファイル数: 380 (295)
異なるサービスホスト数: 27,141 (756)
異常ログ行数: 47
不必要ログ項目数: 162,794
データ転送量: 14.05 ギガ (10億) バイト (727.21 メガバイト)
上記の日別平均: 43.89 メガバイト (103.89 メガバイト)

 上記は、1周年を1ヶ月半程後にひかえた時点での当サイトの物です。「ページリクエスト成功件数」は、Webページを何ページ見てもらえたかを表す物なので、公開し初めはこれが増えるのが楽しみでした。しばらして運用が落ち着いてくると、この項目のすぐ下にある、「上記の日別平均」の中の括弧内の数字が気になるようになります。上記では「(162)」になります。これは、直近の7日間の移動平均で、現在のアクセス状況を端的に表す物になります。

 この数字、大きいほどたくさん見てもらえている指標になるのですが、突然桁違いに増えてしまった時は、注意しなくてはなりません。何処か有名サイトに掲載されて閲覧が増えたのなら良いのですが、DoS攻撃に遭っている場合もあります。今までの経験では、著名な巨大匿名掲示板にリンクが掲載されたようなときでも、430ページリクエスト程度で、桁が変わるようなことはありませんでした。

 トラブルの監視の意味では、「リクエスト不成功件数」は重要です。サイト内で、リンク間違によりリンク切れを超すと増えます。しかし、自身に問題がない場合は、ほとんどの場合脆弱性のスキャニングです。上記の「(36)」はコメントアウトしているはずの画像2つと、HatenaScreenshot/1.0 (checker)がスクリーンショットを取ろうとしているページがあるディレクトリのrobots.txtを確認しているの1つを除いた、33がPHP(Hypertext Preprocessor)の脆弱性をスキャンしているだろうアクセスになっています。現在(2008/04/13 Sun)恒常的に攻撃が検出され続ける状態になっています。

 当サイトの場合、PHPは利用していませんので全て「リクエスト不成功件数」になったいます。しかし、脆弱性を抱えたPHP利用したサイトの場合、その脆弱性をついたアクセスについてはリクエストが成功してしまうので、「リクエスト不成功件数」は少なくなってしまします。このため、PHPを利用するサイトは特に、「リクエスト不成功件数」が増加したときに「リクエスト不成功レポート」を確認する必要があります。そこで、新しいにPHPに対する攻撃が見つかる場合、成功しているアクセスを含めて意図しないアクセスのされ方がないかログを確認した方がよいと思います。

 レンタルサーバなど、転送量に制限のある環境のサイトの場合、「データ転送量」も重要な要素になります。1週間辺りのデータ転送量で制限されていることが多いようなので、この項目の()内の値が制限を超えないように気をつけている必要があります。しかし、急激な変化を検出するには、その下の「上記の日別平均」の()内の値を気をつけている必要があります。特に画像や動画の多いサイトの場合、有名サイトに紹介されるといきなり転送量が増えることがありますので、この値に注意が必要です。


トップへ戻る システムの運用状況(MRTGとAnalog)へ戻る