Web サーバの生ログではなく、独自に欲しい情報だけをログに落として集計に活用すると嬉しいんじゃないかと思った。つかほんとに思いついたのはずいぶん前なんだけど。

ということでまた「一部で当たり前のノウハウなんだろうけど、あんまり見かけることないから書いてしまえメソッド」発動。ちなみに今回の思いつきにおいて「DB に落とせば？」というのは却下とする。書き込みのオーバーヘッドがでかいし、追跡したい情報の変更に柔軟に対応するのが難しくなるし、データが巨大になりすぎた場合の対応も考えるのが面倒だから。ログなら適当に rotate してやるだけでいいし、どうしてもやりたくなったら必要な範囲のログを DB に突っ込んでじっくり解析すりゃいい。

話がそれた。

調べると W3拡張ログファイルフォーマット (W3C Working Draft WD-logfile-960323) というものがあるのでこれを利用するのがよさそうだ。でも基本的に HTTP のことしか考えてないので 1リクエスト:1リソース を記録するもので、複合的な意味を含めることができないように見える。（いやまぁログって普通そうなんでしょうけど。）

記録したい内容にもよるけど、考えられるケースは

• POST メソッドで複合的な内容を送らせているのでこれをトレースできるようにしたい
• トレースはしたいが session 管理はしていないし、する意思もない

なんて辺りかなぁ。というか今回個人的には

• quesy string に埋まっちゃってるパラメータを、生ログ相手に面倒な文字列処理をせずに解析できたら楽じゃね？

というのが主目的だったりする。レベル低くてごめんなさい。

query string の問題は、パラメータの順番が不定なところ。これをそのまま生ログ解析しちゃうと、「実際にはまったく同じリソースにアクセスしているにも関わらず文字列としての URL は一致しない」ので、集計の際に文字列処理をかますなどの面倒な作業が必要になってしまう。

まともな解析ツール入れろ？だからレベル低くてごめんなさいって言ってるの。

で、思いついたのがリソースをユーザーに返す際にログに落とせばいいじゃんて話。しかしさっき書いたようにこのフォーマットは 1リソースに対するリクエストの記録を取るのが目的なので、例えばこれとこれとこのオプションを選びました、みたいな情報は残せない。

と。思ったけど。

uri-stem や uri-query を勝手に組み立てればいいんだ

ということに気づいた。別に今回のログは Web 上に公開されているリソースにどういうアクセスがあったかの情報がほしいわけじゃなくて、内部的にどういう情報が取得されたかを記録できればいいんだから、URI をオレルールで組んじゃえばいいんだよね。なるほどなるほど。オレルールじゃなくても query string の順番の揺れを補正するだけでも結構違いそう。

というかそういうことなら W3拡張ログファイルフォーマットかどうかって、実はあんまり関係ないんだな。別に common log でもいいんだ。ただ uri-stem と uri-query を別々に記録できるのは便利かも。URI として活用できるフィールド、つまりリソースの識別に利用できるフィールドが 2つあるわけだから、より細かく情報を残しやすい。また、対ユーザーという意味ではセッション管理してなくても、ユーザーからのリクエストに対してなんらかのセッション識別文字列を Session Identification URI をもとに付加して複数の情報をベッて吐いて解析時に取り出しやすくするってのも可能だな。

他にも自分でログを吐けば、mod_rewrite なんかで HTTP で公開する URI はサーチエンジン向けにきれいにしつつ、裏で落とすログの URI に細かい情報を載せる、なんてことができるわけだ¹。なかなかいいかも。あとは細かい情報を載せた URI を手軽に生成する方法とそれをログに簡単に落とす方法があればよい、ということですな。（すべて DBMS に入っているなら DBMS のログを解析するんでもいいのかもしれないけど。）