"/etc/httpd/conf/httpd.conf"を開く

HTTP ログ データの振り分けは、 Apache のメイン設定ファイル "/etc/httpd/conf/httpd.conf" に記述して行います。

まず、 サブネット 内の適当な クライアント機 から SSHクライアント で 構築中のLinuxサーバー に ログイン します 。

それから su コマンド で アカウント を "root" に変更し、 cp コマンドでバックアップを作成した後、 nano エディタで "/etc/httpd/conf/httpd.conf" を開きます 。

nanoで"/etc/httpd/conf/httpd.conf"を開く

設定ファイルの書式や設定の反映のさせ方については、 及び を参考にしてください。

"/etc/httpd/conf/httpd.conf"の編集ポイント

ログ データの振り分けの設定は、有効になっている "CustomLog" ディレクティブ に対して行います。

つまり バーチャルホスト を設定していない場合には、通常のドキュメントルートに対するCustomLogディレクティブ (500行目付近) が対象になりますが、バーチャルホストを設定している場合にはバーチャルホストコンテナ内のCustomLogディレクティブ を対象とする必要があります。

いずれの場合も設定の方法そのものは同じですので、ここではひとまとめにして設定例を説明します。

実際の記述内容はかなり大掛かりなものになりますので、オリジナルで有効になっている "CustomLog" ディレクティブは、

とコメントアウトし、その下に一連の記述を行うと良いでしょう。

また、アクセスログのデータ形式については、 "common" を設定しても Webalizer での解析は可能ですが、 の説明のとおり、 "common" にしてしまうと、アクセス解析で重要な位置を占める リファラー と ユーザーエージェント の情報が得られなくなってしまいます。

従ってここは基本的に "combined" に設定することをお勧めします。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

ログデータの振り分けのためのディレクティブ

ログ データの振り分けは、まず "SetEnvIf" ディレクティブ で個々のログデータに特定の 環境変数 をセットし、その環境変数による判定式付きの、 "CustomLog" ディレクティブ でログデータを収集する、という方法で行います。

SetEnvIf〜ログデータに環境変数を設定する

Apache が取得する個々の ログ データに対し、 環境変数 をセットする ディレクティブ です。

実際にログデータをログファイルに書き込む役目を担う "CustomLog" ディレクティブは、この "SetEnvIf" ディレクティブによってセットされた環境変数の内容に応じて書き込むべきログデータを判別できますから、これらの二つのディレクティブを適当に組み合わせることでログデータの振り分けを実行することができます。

一般書式は、

SetEnvIf [リクエストの種類] [判定用パラメータ] [環境変数1] [環境変数2] ...

です。

[リクエストの種類] は、ログデータの中のどの要素を環境変数セットの判断材料にするかを指定するパラメータです。

指定可能なパラメータはいくつもありますが、ログファイルの形式が "combined" のときに有効で、実際に指定して意味のあるパラメータは以下のとおりです。

・Remote_Addr　 アクセス要求元の ノード の IPアドレス (1)

・Request_Method　 リクエストに使用されている HTTPメソッド (5)

・Request_URI　 リクエストされた コンテンツ の URI (5)

・Referer　 アクセス元の リファラー (8)

・User-Agent　 アクセス元の ユーザーエージェント (9)

末尾の(数字)は、ログファイルの構造 の各要素に対応していますので参照してください。

[判定用パラメータ] には、 [リクエストの種類] で指定した要素に対する一致条件を 正規表現 で指定します。

そして、これらの条件が満たされたときにセットする環境変数を、 [環境変数1] [環境変数2] ... に記述します。複数記述すれば複数の環境変数がセットされます。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

ログデータの振り分けの記述方法

一般的には、

と記述します。

抽象的な記述では説明が難しいので、具体的な記述例を以下に示します。

IPアドレスで振り分けを行う

自宅内の LAN と、外出先などの特定の IPアドレス からの ログ データを別のログファイルに振り分ける設定です。

このように設定すると、アクセス元のIPアドレスが "192.168.100.*" または "211.183.111.34" の場合、 1) または 2) の "SetEnvIf" ディレクティブ によって "ownlog" 及び "nolog" という二つの 環境変数 がログデータにセットされます。

すると、いずれの場合も次の A) に設定された "CustomLog" ディレクティブの条件式 "env=ownlog" に一致しますから、これらのログデータは "logs/access_own_log" に追記されることになります。

そしてそれ以外のログデータを "logs/access_log" に追記すれば良いわけですが、もしも

と B) に条件式を何も書かなければ、環境変数のセットとは無関係にすべてのログデータが "logs/access_log" に追記されてしまいます。

そこで前の設定例のように、 B) に "env=!nolog" という判定式を記述し、

「"nolog"という環境変数がセットされていないログデータを追記する」

という設定を行うわけです。

ひとつのログデータにわざわざ二つの環境変数をセットしているのは、実はそういう理由によるものです。

以下、その他条件による振り分けの設定について説明しますが、これらは判定の方法が違うだけで振り分けの手順は同じです。

従って以下は振り分けの要点に絞って説明します。

HTTPメソッドで振り分けを行う

例えばこのサイトが参加している 「自宅サーバーWebRing」 では、参加者の Webサーバー の状態を監視するのに "OPTIONS" HTTPメソッド を利用しています。

"OPTIONS" メソッドは利用されることが極めて少ないメソッドですので、これを利用して監視用のログデータを別のログファイルに振り分けることができます。

とはいえ、実際にはHTTPメソッドでログデータを振り分けるケースは比較的少ないと思われます。

リクエストされたURIで振り分けを行う

例えば Apache のユーザーディレクトリの公開機能 を使って、 ユーザーアカウント suzuki に コンテンツ スペースを貸し出し、

での公開を許可している場合、この URL へのアクセスログデータを他のログファイルに振り分けるには、 FQDN 以下のディレクトリ名を使って以下のように設定します。

Webalizer 自身のログデータを振り分ける場合についても同様に、アクセス先のディレクトリ名 "/var/www/usage/" から、

と記述します。

"Request_URI" オプションを利用するときは、指定する文字列が「部分一致」で デフォルト になります。

例えば最初の例で、URIの指定を単に "suzuki" としてしまうと、リクエストされたURIの一部(つまり パス 名やファイル名)に "suzuki" が含まれる場合、例えば、

へのアクセスの場合でも 環境変数 "suzukilog" と "nolog" がセットされ、 "logs/access_suzuki_log" への振り分けが行われてしまいますので注意してください。

リファラーで振り分けを行う

例えば外部から、

へのリクエストが行われた場合、実はalbum.html上にタグで貼り付けられている画像ファイルや参照する外部スタイルシートファイル、 JavaScript ファイルなどは、 http://www.obenri.com/album.html が リファラー となります。

要するに「 サーバー 内部のファイルを呼び出しているだけ」でもすべてリファラーとして記録されるわけですから、実は外部のリファラーの数よりも内部のリファラーの数のほうが圧倒的に多いのが普通です。

だとすれば、外部のリファラーの解析を行うには、この邪魔になる「内部のリファラー」の ログ データも別に振り分けてしまいたいところです。

ところがこの「内部のリファラー」のログまで別のログファイルに振り分けてしまうと、サーバーから送り出されるデータの容量の統計が著しく小さい値になってしまうでしょうし、他にも正確なデータにならないケースも起こりうるでしょう。

従って、原則としてリファラーでのログデータの振り分けは行わないことをお勧めします。

この部分の問題はログデータで振り分けを行うより、 Webalizer で適切に調整して解析を行うほうが現実的だといえます。

ユーザーエージェントで振り分けを行う

及び の説明のとおり、実際にユーザーがアクセスしていないのに外部から HTTP でアクセスしてくるのが 検索ロボット です。

これらを除外するには例えば以下のように設定を行います。

上から３行目までがサイト登録用の検索ロボット、４行目がGoogleのアフェリエイトのクローラーに対する 環境変数 のセットです。

そして４行目で検索ロボットのログデータをまとめて同じ "logs/access_robot_log" に追記し、５行目でアフェリエイトのログデータを "logs/access_affil_log" 収集する、という設定になっています。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

「お便利サーバー.com」の設定例

ではこのパートの最後に、「お便利サーバー.com」で実際に設定しているログデータの振り分けについて掲載しますので参考にしてください。

1) は LAN からのアクセスの ログ の判定で、 A) の logs/access_home_log に保存します。 リファラー や ユーザーエージェント の記録は必要ないので、ログ形式は "common" としています。

2) は 「自宅サーバーWebRing」 のログの判定です。 HTTPメソッド ではなく、 ユーザーエージェント で判定しているのには特に深い意味はありません。 "common" 形式で B) の logs/access_jswc_log に保存しています。

3) は、知人に貸している コンテンツ スペースに対するログの判定です。必要なときはきちんとアクセス解析ができるように "combined" 形式で C) の logs/access_xxx_log に保存しています。

4) 〜 7) は 検索ロボット のログの判定です。検索ロボットはもっとたくさん闊歩しているはずですが、ログの解析に影響を与えそうな「大量の足跡を残す」検索ロボットとしてこれくらいでしょうか。

すべてのログデータをまとめて D) で logs/access_robot_log に収集しますので、後から解析可能なようにこれも "combined" 形式にしています。

8) と 9) はアフェリエイトのクローラーです。もちろん、自分で提携しているものだけ設定すればOKです。 E) で logs/access_affil_log にまとめて収集しますので、これも後から解析可能なように "combined" 形式にしています。

そしてこれらのいずれにも該当しないログデータを「ユーザーからのアクセス」とみなし、 X) で logs/access_log に "combined" 形式で収集しています。

なお、 お便利サーバー.com の Webalizer によるアクセス解析結果は非公開で、管理人はLAN以外から閲覧することはありません。

従ってWebalizerの出力先ディレクトリに対して URI によるログデータの振り分け設定は特に行っていません。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

設定ファイルの書式チェックと有効化

"/etc/httpd/conf/httpd.conf" への ログ データの振り分けの記述は分量が多く間違えやすいので、記述が終わったら必ず書式のチェック を行ってください。

Apache の設定の有効化 を行うと、自動的に "/var/log/httpd/" 以下に新しく設定したログファイルが作成されますので確認してみてください。

ログファイルの振り分けがうまくいっているかどうかは、それぞれのログファイルを nanoエディタ で開くなり、 cat コマンド で内容を表示してみるなりの方法で確認してみてください。

ちなみに、この "/var/log/httpd/" 以下に出力されるログファイルは一定期間ごとにローテーション処理され、古くなったログファイルが削除されていきます。

従って、「ログファイルが多くなりすぎて ハードディスク の容量が足りなくなる 」という心配はまず不要でしょう。

さて、ログファイルの出力が確認できたら、

と実行してください。 "logs/access_log" から除外されたログデータは解析されなくなります。

ただ、この場合一つ気をつけておかなければならないことがあります。

この コンテンツ の推奨どおりに Webalizer の基本設定を行っているとすると、アクセス解析結果は、 及び関連 ディレクティブ の設定で、 「増加処理」 を選択していると思います。

つまり、このパートに従ってアクセスログの振り分けを行っても、それ以前に行われた解析結果に含まれる LAN や 検索ロボット の統計が取り除かれるわけではありません。あくまで、アクセスログの振り分けを実施した以降の解析処理に対してのみ有効であることに注意してください。

ただ、Webalizerは月次単位でアクセス解析結果をレポートしますから、月が変わればきちんとしたアクセス解析結果が得られるようになります。

従ってこういった「解析結果に大幅な影響を与える設定変更」はできるだけ月の変わり目に行うと良いかもしれません。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト