![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
「うちのWebサイトには、どれくらいアクセスがあるんだろう?」「うちのサイトを利用する人は何人いるんだろう?」「利用者はどのページを見ているだろうか?」「Web訪問者は、実際にはどこから来るのだろうか?」このような疑問に答えを知るには、Webサイトを作るときにWeb測定テクノロジーを含めることで可能です。業界で採用されてきたWeb測定方式には、ネットワーク・モニター、シングル・ピクセル・ソリューション、およびHTTPサーバー・ログ分析などがあります。
このシリーズの第2回では、HTTPサーバー・ログから測定値を入手する方法に絞って説明します。HTTPサーバー・ログの分析についてよりよい理解を得るために、この記事ではHTTPロギングについて (HTTPロギングとは何か、ログの形式にはどんなものがあるか、どんな情報を利用できるか、など) 説明した後、生のログ・データからどんな測定値を得られるかを示します。基本的な測定値には、ヒット数、利用者数、利用時間、利用元の場所 (サブドメイン、参照元リンク)、利用者のIPアドレス、ブラウザーの種類、プラットフォームの種類があります。またここでは、分類や集約などのテクニックを使ってデータを操作して得られる、さまざまな高度な測定値についても説明します。さらに、データ・ウェアハウジングやデータ・マイニングなどの技術を組み合わせることによってソリューションを拡張できます。
主要なHTTPサーバー・ベンダーで利用できるHTTPサーバー・ロギング機能について簡単に触れた後、生のログ・データに対して分析上のいろいろな概念がどのように適用されるかについて説明します。HTTPサーバー・ロギング機能のベンダーごとに、それぞれ業界標準ロギング形式の1つが採用されています。ここで説明するのは実際に活用されてきた概念であり、Webサーバー・ログからさまざまな測定値を得る方法を示すものです。実際には、業界ではいくつかのWeb測定方式が利用されており、Webサーバー・ログから得る方法はそのうちの1つにすぎません。
HTTPログ分析とは、Webサーバー環境でHTTPサーバーによって生成されるログ・ファイルを分析することです。各HTTPサーバーのベンダーの製品 (Apache、Microsoft Internet Server、Netscape、およびDomino GO) には、ロギング機能が付属しています。多くの場合、そのようなロギング機能には、ログをオン/オフしたり、ログに記録するデータの種類を指定したり、記録するデータの量を指定したりするための構成オプションが含まれています。データは、1つ以上のファイル形式でファイルに記録されます。Webサーバー・ソフトウェアが開発されるにつれて、ログ・オプションやログの実装の種類も増えてきました。ログ・ファイルの形式としては、下記のものが主に使われるようになってきています。
- NCSA結合ログ形式
- NCSAセパレート・ログ形式 (3ログ形式)
- NCSA共通ログ形式 (アクセス・ログ)
- W3C拡張ログ形式
HTTPログの典型的な構成では、サーバーへのHTTP要求 (サーバーでのヒット) ごとに1つずつログ・エントリーが作成されます。そのエントリーには、リソース要求に関する詳しい情報が含まれます。Web分析ソフトウェアでは、それらのログ・ファイルをバッチ式に解析および処理することによって、個々の要求の情報を組み合わせてWebサイトのトラフィックの全体像を得ることができます。図1 に、簡単なデータ収集処理を示します。
図1: Webサーバー・ログの収集と分析
まず、HTTPログの分析によってWebサーバー・ログからどんな情報が得られるかを調べてみましょう。
Webサーバーは、クライアント要求をサーバー・ログに記録するよう設定できます。そのサーバー・ログには、Webサイトのトラフィックや利用状況を調べるのに使用できる情報が入れられます。たとえば、あるクライアントが
http://www.ibm.com を訪れたとすると、その要求を受け取ったWebサーバーのサーバー・ログにその要求が記録されます。
多くの場合、1つのWebページに複数のリソースが含まれており、そのために複数のヒットが発生することになります。たとえば、Webページ
basic.html にimage1.gif、image2.gif、および
image3.gif という3個のイメージが含まれているとします。ユーザーがbasic.html を要求した場合、そのことを1回のヒットと数えるのが普通です。しかし、basic.html の要求には、そのページに含まれるイメージ・ファイルに関する3つの要求も含まれます。リソースはサーバーからそれぞれ別個に要求されるため、
basic.html を要求すると、3回の付加的なヒットが追加されて合計4回のヒットになります。業界用語としてページ・ビューの語は、イメージやその他のリソースのヒットとは違い、1つのページまたは表示可能テキストを1つのリソースとして数えたヒットのことです。前述の例では、ページ・ビューは1つだけですが、Webサーバーのログには、このユーザーのアクションに関して4個のエントリーが作成されることになります。
HTTPサーバーのベンダーやサポートされるログ形式に応じて、Web分析に使用可能な生の情報は少しずつ異なります。以下のセクションでは、ログとして記録される最も典型的な情報について説明します。必要な情報がWebサーバーによって生成されているかどうかについては、実際のログ形式を調べてください。
リモート・ホストは、HTTPリソース要求を発行したHTTPクライアントのIPアドレスまたはホスト/サブドメイン名です。HTTPサーバーは、HTTP要求元クライアントのIPアドレスを入手できます。多くの場合、リモート・ホスト・フィールドには、リモート・ホストのIPアドレスが125.125.125.125のような数値形式で入れられます。しかし、多くのHTTPサーバーでは、IPアドレスのDNS変換機能をオンにすることができます。DNS変換機能がオンの場合、HTTPサーバーはIPアドレスを文字ベースのホスト名、またはibm.comのようなサブドメイン名に変換することを試みます。その場合、サブドメインはリモート・ホストの値になります。
(注: 多くの場合、HTTPサーバーではDNS変換機能がオフに設定されています。DNS変換機能はしばしば時間のかかる処理であり、個々のリソース要求がなるべく短時間で処理されるようにWebサイトを構成したいとWeb管理者が考えている場合には、DNS変換機能をオンにする必要はないでしょう。)
HTTPサーバーで利用できるIPアドレスは、サーバーのHTTPリソースの実際の要求を発行したクライアント・プロセスのIPアドレスです。多くの場合このIPアドレスは、WebブラウザーでWebサーフィンをしているエンド・ユーザーを一意的に特定するものとはなりません。このIPアドレスはキャッシュ・サーバー、proxyサーバー、または個々のHTTP要求ごとにISPによって動的に割り当てられるIPアドレス・プールの1つである可能性があるからです。
これは、HTTP要求発行元のクライアントを特定するための識別子です (利用できる場合)。RFC 931には、このフィールドについてさらに詳しい情報が含まれています (参考文献を参照)。実際には、HTTPサーバーやWebサイトの多くはこのフィールドを利用していません。サーバーでログ名フィールドが使用されているかどうかについては、Webサーバーのドキュメンテーションをご覧ください。
これは、要求されたHTTPリソースでユーザー認証が必要な場合に、認証のためにクライアントによって使用されたユーザー名 (またはユーザーID) です。要求されたリソースで認証が不要なら、このユーザー名の情報はありません。
これは、HTTP要求の日付と時刻のタイム・スタンプです。多くの場合、この情報はグリニッジ標準時 (GMT) で記録されます。実際の日付と時刻のタイム・スタンプの形式には、時刻オフセットも含まれます。そのオフセット情報により、GMT時刻だけでなく、要求を記録したHTTPサーバーでのローカル時刻も入手できます。
この要求は、基本的にはWebクライアントが要求したものです。要求フィールドには、実際には次の3つの情報が含まれます。
- 要求されたリソース (メインとなる情報)
- HTTPメソッド (たとえばGETまたはPOST)
- HTTPプロトコル・バージョン番号 (たとえばHTTP/1.0またはHTTP1.1)
要求されたリソースは、HTTPクライアントによって要求されたHTTPリソースです。たとえば、あるユーザーがブラウザーにWebページをロードしたとします。そのユーザーがそのページをロードすると、ブラウザー (HTTPクライアント) はWebサーバーに対してそのページ (HTTPリソース) を求める要求を発行します。ログ・ファイルの要求フィールドに記録されるリソースには、要求されたリソースのURLの一部として含まれるプロトコル名またはホスト名は含まれません。たとえば、ユーザーが
http://www.ibm.com/index.html のページをロードしたとすると、ログに記録されるリソースの値は、プロトコル (http://) やホスト名 (www.ibm.com) を含まない/index.html になります。
HTTPメソッドとは、HTTPクライアントがリソースを求める要求を送信するために使用するメソッドです。たとえば、ユーザーがブラウザーの入力フィールドにページのURLを入力することによってページをブラウザーにロードした場合、ブラウザー (HTTPクライアント) はそのページを求める "GET" 要求を発行します。GETは、ブラウザーがリソースを要求するためのHTTPメソッドです。もう1つのメソッドは "POST" です。Webページ上のフォームにユーザーが入力し、表示されているページにあるボタンをクリックすることによってその情報を送信すると、ブラウザーはPOSTメソッドを発行します。HTTPクライアントがWebページ上のリンクを解決するためにGETを発行するかPOSTを発行するかは、Webサイトの作成者の選んだWebページの実装方法に応じて異なります。
HTTPプロトコル・バージョン番号とは、HTTPクライアントとHTTPサーバーの間の通信に使用されたのがHTTPバージョン1.0であるか、それともバージョン1.1であるかを示すものです。
状況フィールドは、HTTP要求が成功したか失敗したかを示す数値コードです。たとえば、ユーザーがブラウザーにページを正常にロードした場合、Webサーバーの記録する状況コードは大抵は200 (成功を示す) になります。要求が失敗した場合は、それとは異なる状況コードになります。一般に200～299の状況コードは成功したことを示し、300～399は警告状況 (リンクのリダイレクトなど) を、400～499はクライアント・エラーを、そして500～599はサーバー・エラーを示します。HTTP仕様には、状況コードとその意味が示されています。
バイト数フィールドは、HTTP要求の一部として転送されたデータのバイト数を内容とする数値フィールドです。この値には、HTTPヘッダーのバイト数は含まれません。たとえば、ブラウザーの入力フィールドに
http://www.ibm.com/large10KImage.gif というURLを入力することによってサイズが10KBのイメージをロードし、サーバーがその要求に応じたとすると、バイト数は10,000になります。
参照元は、要求されたリソースをユーザーが参照することになった元のHTTPリソースのURLです。たとえば、あるWebクライアントが第1のページとして
http://www.ibm.com/index.html を表示していて、そこにある第2のページへのリンクをクリックした場合、第1のページが参照元になります。第2のページの参照元ログのエントリーには、参照元として第1のページのURL
http://www.ibm.com/index.html が入れられます。
エージェントは、HTTP要求の発行元のHTTPクライアントです。WebブラウザーなどのHTTPクライアントにとって、HTTP要求を発行する際に自分自身を名前で識別するのは標準的な手続きです。Webサーバーは、その名前をエージェント・ログに書き込みます。HTTPクライアントがWebブラウザーの場合、ブラウザーの名前とバージョン、およびクライアントのオペレーティング・システムを識別するエージェント名によって自分自身を識別するのが普通です。
Webサーバーのログに含まれる情報の種類がわかったとして、そのデータにはどんな値が含まれているのでしょうか? また、ユーザーがその意味を知るにはどうすればいいのでしょうか? 一部の大規模なWebサーバーでは、一日に何百万個ものヒットが記録されます。処理の対象となる情報は、並みの量ではありません。それらのデータすべては、そのWebサイトのトラフィックに関して何を示しているでしょうか? 関係のあるどんなビジネス上の問題および設計上の問題がそこからわかるのでしょうか?
ここでは、まずログ・ファイルに含まれる生のデータから、基本的な照会を実行することについて説明します。次いで、さらに高いレベルでデータを解釈することによって作成される、もっと複雑な照会について述べます。以下に示す基本的な照会では、ログ・ファイルの生データに基づいて回答が得られます。ログ・ファイルの各レコードの各フィールドには、それぞれ意味のある情報が含まれていることがわかることでしょう。
前述のように、クライアントのIPアドレスは、DNSルックアップを実行することによってサブドメイン (ドメイン) に変換できます。クライアントのサブドメインを知るなら、ユーザーIDまたはユーザーのCookieが実装されていない場合に、高レベルのデモグラフィックスが得られます。サブドメインによって、次のようなことがわかります。
- 競争相手はうちのサイトをどの程度の頻度で見ているか?
- 企業からアクセスする顧客が多いか、それともISPからアクセスする顧客が多いか?
- Webクライアントは仕事でアクセスしているのか、家庭からアクセスしているのか?
- 一番多いISPはどこか? (たとえばAOL.comやMindspring.com)
- 主要な大学は、うちのWebサイトを利用しているか? (注: 大学のサブドメインは最後が
.eduです。)
ユーザーIDまたはユーザーCookieが使用されていない場合、IPアドレスはクライアントを特定する唯一の方法です。どのIPアドレスが、このサイトで最も多くの時間を費やしているでしょうか? 1週間で、どのIPアドレスが最も頻繁に訪れているでしょうか?
ユーザーIDがあれば、Webトラフィックをユーザーごとに特定することが可能になり、特定の月に、どのユーザーが最も多くのお金を使っているか、などの質問の回答が得られます。そのユーザーには、何かのプレゼントを送ったり、何らかの特典を付与したりできるでしょう。
- ヒット数では、どのユーザーが一番か?
- セッション数では、どのユーザーが一番か?
前述のように、ログ・レコードのエージェント・フィールドに基づいて、クライアントで使用されているブラウザーとプラットフォーム (オペレーティング・システム) を知ることができます。この情報は、どのブラウザーが一番使用されているか、といった質問の回答を得るのに便利です。これは、動的でないページでもブラウザーの種類によって違ったように見える場合があるので役立ちます。あるWebページが特定のブラウザーでは決まってうまく表示されず、そのブラウザーの利用者が予想していたより多い場合、ページを再構成して、そのブラウザーでも正しく表示されるようにする必要があるでしょう。
同じように、動的なページが正しく表示されないプラットフォームがあるなら、それも特定できます。
- Netscapeで一番使われているのはどのバージョンか?
- Internet Explorer (IE) で一番使われているのはどのバージョンか?
- UNIXベースのOSはどの程度使われているか?
Webサーバーがリソースをクライアントに供給しようとするたびに、Webサーバーは戻りコードをログ・ファイルに記録します。前述のように、戻りコード状況が200なら、それは要求されたリソースが正常にクライアントに送られたことを意味しています。状況が200以外なら、リソースをクライアントに送るときに問題が発生したことを示しています。Webマスターは、しばしば要求されるがクライアントに正しく送られない特定のリソースがあるかどうかを知りたいと思うことでしよう。
最近Webサイトのアドレスを変更し、以前のアドレスを指定するとリダイレクトされるようにした場合、どの程度のクライアントが以前のアドレスを使用しているでしょうか? 戻りコード301または302は、そのような状況を示しています。前のアドレスを保持するために費用がかかっているのであれば、どうすればさらに効果的に新しいアドレスを顧客に伝え、前のアドレスのWebサイトにかかる余分のコストを削減できるでしょうか?
参照元とは、クライアントが別のWebサイトから来たのかどうかを示すものです。ユーザーがブラウザーにhttp://www.ibm.com と入力すると、直接そのページが表示されます。しかし、Yahoo.comのページ上でhttp://www.ibm.com にリンクするようになっているIBMの広告をクリックした場合は、IBM Webサーバー・ログの中でそれが参照元となります。明らかに、別のWebサイトに広告を掲載するために費用がかかっているのに、だれもそのサイトから来ないという場合には、広告の掲載をやめるのがよいでしょう。
図2 は、参照元構成の例です。
図2: 典型的な参照元構成
参照元に関係のある質問として、次のことがあります。
- 参照元のWebサイトはどこか?
- 参照元ページとして一番多いのはどこか?
- 参照元の営利団体としてどこが一番多いか?
- 参照元のURLとしてどこが一番多いか?
リソース測定値は、Webサイトのトラフィックに関する詳細な情報を提供します。それは、次のような質問に対する答えを提供するものとなります。
- 先月、うちのサイトには合計どれだけのヒットがあったか?
- 週のうち一番よくアクセスがあるのは何曜日か?
- 先月、サイトのホーム・ページのヒットはどれだけあったか?
- 一番経過時間の長いページはどれか?
- 要求されることの一番多いイメージはどれか?
- サイトのエントリー・ページとして一番多いのはどれか?
- サイトの終了ページとして一番多いのはどれか?
Webサーバーの処理するバイト数は、Webサーバーが実行している作業量を知るのに役立ちます。次のような質問に対する答えが得られます。
- セール期間中に何バイトがクライアントに送られたか?
- 1回の訪問で平均何バイトクライアントに送られるか?
- このユーザーに対しては何バイト送られたか?
これまでに示した照会と測定値とは、ログ・ファイル中の生のデータからすぐに得られるものです。しかし、データを解釈するためにさらに複雑なアルゴリズムを使用すれば、もっと多くの情報が得られます。ここでは、いくつかの複雑な照会方法と、Webサーバーのログから収集できる情報の種類について説明します。
「セッション化」と「訪問」とは、交換可能な語です。セッション化とは、あるWebサイトの利用者の数を決定するものです。セッション化アルゴリズムでは、IPアドレス、参照元アドレス、ユーザー・エージェント (ブラウザー/プラットフォーム)、タイム・スタンプ、そしてタイムアウト値など、各ヒットをセッション化する際にいくつかの情報が考慮されます。それぞれの情報には、優先順位が付けられています。アルゴリズムでは、どんな場合にヒットをセッション化するかに関する最善の判断をする必要があります。業界ではヒットのセッション化アルゴリズムが研究されてきており、今までにいくつかのアルゴリズムが利用できるようになっています。事実、アルゴリズムの種類が豊富であるために、セッション化の標準規格が確立されたほどです。
分類とは、パターン・マッチングに基づいて、よく似た"もの" をグループとしてまとめる処理のことです。この方法では、複数の"もの" からのデータがグループとしてまとめられます。たとえば、Webサイトに車に関するコンテンツ (ファイル名cars.html) と、飛行機に関するコンテンツ (ファイル名airplanes.html) が含まれている場合、「輸送手段」というカテゴリーを作成し、そのパターンとして*cars.html と*airplanes.html を指定できます。そのようにすれば、cars.html に3回のヒット、airplanes.html に4回のヒットがあった場合、輸送手段カテゴリーのヒットは合計7回になります。「競争相手」というサブドメイン・カテゴリーを作成し、パターンとして競争相手のサブドメインに一致するものを指定するとよいかもしれません。
集約は、実体とそれに対応する測定値のすべてを組み合わせる処理です。たとえば、このIPアドレスで戻りコードが200以外だったことが今までに何回あるかを知りたいことがあるかもしれません。その場合、IPアドレスと戻りコードの集約を組み合わせることができます。あるいは、特定のリソースの戻りコードが正常でなかったことが何回あったかを知りたいなら、リソースと戻りコードとの組み合わせを作成できます。さらには、特定のユーザーが特定のリソースを要求して特定の戻りコードになった場合が今までに何回あったかを調べることが必要になるかもしれません。その場合には、ユーザーIDとリソースと戻りコードを組み合わせることになります。
図3 に、IPアドレスと戻りコードの集約の組み合わせをすべて示します。これには、特定のIPアドレスで戻りコードが200でなかった (ユーザーがページを表示しようとして問題が発生した) ことが何回あったかが示されています。この情報は、正しく表示されないページを表示しようとしたユーザーがどれだけいるかを示すものであり、非常に重要な情報です。この種の情報を使えば、Webサイトのメインテナンスやリソースの修復を指示したらよいかを決定できます。
図3: IPアドレスと戻りコードの集約の組み合わせ
Webサーバー環境でHTTPサーバーによって生成されるログ・ファイルは、そのWebサイトのトラフィック測定値の情報を提供します。HTTPサーバーのベンダーの製品 (Apache、Microsoft Internet Server、Netscape、Domino GOなど) には、ロギング機能が付属しており、さらにロギング機能のオン/オフやログ・ファイルの形式の指定などのロギング構成オプションも用意されています。
現在HTTPサーバーの業界で使用されているログ・ファイルの形式には、下記のものがあります。ここに示すのは、最も普及しているものだけです。
- NCSA共通ログ形式 (アクセス・ログ)
- NCSAセパレート・ログ形式 (3ログ形式)
- NCSA結合ログ形式
- W3C拡張ログ形式
ログ・ファイルには、Webクライアントからの各ヒットまたはHTTP要求ごとに1つずつエントリーが作成されます。ログ・ファイルは、複数のエントリー (レコード) で構成され、各エントリーは一定の形式になっています。下記に示すのは、あるNCSA結合ログ形式のログ・ファイルから5個のヒットの5個のレコードを抜粋したものです。この後に、各フィールドについて説明します。
-
111.134.115.117 - - [08/Jun/1999:08:36:04 +0000] "GET /index.html HTTP/1.0" 404 55 "-" "Mozilla/3.0 [en] (WinNT; I)" -
122.133.123.112 - - [08/Jun/1999:08:36:14 +0000] "GET /images/sp.gif HTTP/1.0" 200 47 "http://www.sample.com/index.shtml" "Mozilla/3.0 [en] (WinNT; I)" -
111.109.230.202 - - [08/Jun/1999:08:36:15 +0000] "GET /images/music.gif HTTP/1.0" 200 47 "http://www.sample.com/index.shtml" "Mozilla/3.0 [en] (WinNT; I)" -
101.223.240.118 - - [08/Jun/1999:08:36:17 +0000] "GET /images/net.gif HTTP/1.0" 200 98 "http://www.sample.com/index.shtml" "Mozilla/3.0 [en] (WinNT; I)" -
101.223.240.118 - - [08/Jun/1999:08:36:19 +0000] "GET /images/header.gif HTTP/1.0" 200 50 "http://www.sample.com/index.shtml" "Mozilla/3.0 [en] (WinNT; I)"
National Center for Supercomputing Applications (NCSA) の共通ログ形式は、基本的なHTTPアクセス情報だけを含む簡単な形式です。NCSA共通ログ (アクセス・ログと呼ばれる) は、NCSAセパレート・ログ形式の3個のログの中の最初のものです。NCSAログ形式は、NCSA httpdに基づくものであり、HTTPサーバー・ベンダーの間で標準として広く受け入れられています。共通ログ形式は、NCSA結合ログ形式から参照元とユーザー・エージェントを取り除いたものと考えることもできます。それらのフィールドは、結合ログ形式でのオプション・フィールドです。共通ログには、要求されたリソースと共にいくつかの情報が含まれていますが、参照元、ユーザー・エージェント、Cookie情報は含まれていません。情報は単一のファイルに入れられます。その構文、例、そして各フィールドの説明を下記に示します。
共通ログの構文と例:
remotehost | logname | username | date
125.125.125.125 - dsmith [10/Oct/1999:21:15:05 +0500]
request | status | bytes
"GET /index.html HTTP/1.0" 200 1043
|
remotehostは、HTTPリソース要求を発行したHTTPクライアントのIPアドレスまたはホスト/サブドメイン名です。
これは、HTTP要求発行元のクライアントを特定するための識別子です (利用できる場合)。"-" の場合は、ログ名がないということです。
ユーザー名 (ユーザーID) は、クライアントによって認証のために使用されるものです。"-" の場合は、ユーザー名がないということです。
date: [10/Oct/1999:21:15:05 +0500]
これは、HTTP要求の日付と時刻のタイム・スタンプです。
日付/時刻のタイム・スタンプの形式は、下記のとおりです。
day of month in | month in | year in | hour | minute | second | timezone [ dd /MMM /yyyy :hh :mm :ss +0500] [ 10 /Oct /1999 :21 :15 :05 +0500] |
実際には、日は1日～9日についても2桁の形式で記録されるのが普通です。たとえば、ある月の2日は02と表記されます。しかし、1日～9日を1桁で表記するHTTPサーバーもあります。ログ・レコードの構文解析では、両方の表記方法に対応するようにしてください。
request: "GET /index.html HTTP/1.0"
これはHTTP要求です。要求フィールドには、3種類の情報が含まれます。メインとなるのは、要求されたリソース (index.html) です。要求フィールドには、さらにHTTPメソッド (GET) とHTTPプロトコル・バージョン番号 (1.0) も含まれます。
statusは、HTTP要求が成功したか失敗したかを示す数値コードです。
bytes
フィールドは、HTTP要求の一部として転送されたデータのバイト数 (HTTPヘッダーを含まない) を内容とする数値フィールドです。
NCSAセパレート・ログ形式 (3ログ形式) は、収集された情報が3つのファイル (ログ) に分割して収集されるログ形式です。この点で、この記事で説明する単一ファイルの他の形式の場合とは異なっています。3つのログは、しばしば次の名前で呼ばれます。
- 共通ログまたはアクセス・ログ
- 参照元ログ
- エージェント・ログ
3ログ形式では、NCSA共通ログ形式の基本的な情報が1つのファイルに、そして参照元情報とユーザー・エージェント情報がそれぞれ別のファイルに入れられます。しかし、このログ形式の場合、Cookie情報は記録されません。前述の例と同じ例を使って、3ログ形式について説明しましょう。
3個のログの最初のものは共通ログ (アクセス・ログ) です。これは、前述のNCSA共通ログ形式と同じ形式、同じ構文です。
参照元ログは、3個のログのうち第2のものです。参照元ログのエントリーは、それぞれ共通ログの各エントリーに対応したものです。参照元ログに含まれるフィールドは2つだけです。
タイム・スタンプは、そのエントリーを共通ログ中のエントリーに対応付けるためのものです。参照元は、参照元アドレスです。下記に例を示します。
構文:
date | referrer
[10/Oct/1999:21:15:05 +0500] "http://www.ibm.com/index.html"
|
-
date: これは、HTTP要求の日付と時刻のタイム・スタンプです。参照元ログに記録されるエントリーの日付と時刻は、共通ログ中のリソース・アクセス・エントリーに対応しています。そのため、2つのログの対応するレコードの日付と時刻は同じです。タイム・スタンプの構文は、共通ログのタイム・スタンプと同じです。
-
referrer: 要求されたリソースをユーザーが参照することになった元のHTTPリソースのURL。たとえば、あるWebクライアントがhttp://www.ibm.com/index.htmlなどのページを表示していて、そこにある第2のページへのリンクをクリックした場合、第1のページが参照元になります。第2のページの参照元ログのエントリーには、参照元として第1のページのURL (http://www.ibm.com/index.html) が入れられます。たとえば、参照元エントリーは、[10/Oct/1999:21:15:05 +0500] "http://www.ibm.com/index.html"というようになります。
エージェント・ログは、3ログ形式の3つのログの第3のものです。参照元ログと同じように、エージェント・ログのエントリーは、それぞれ共通ログ中のエントリーに対応しています。参照元ログには、2つのフィールドが含まれています。第1のフィールドは、そのエントリーを共通ログ中のエントリーに対応付けるためのタイム・スタンプです。第2のフィールドは、リソースの要求を発行したHTTPクライアントのエージェント名です。下記に、ファイルの形式とその説明を示します。
date | agent
[10/Oct/1999:21:15:05 +0500] "Microsoft Internet Explorer - 5.0"
|
-
date: これは、HTTP要求の日付と時刻のタイム・スタンプです。エージェント・ログに記録されるエントリーの日付と時刻は、共通ログ中のリソース・アクセス・エントリーに対応しています。エージェント・ログに記録される情報は共通ログに記録される情報を補うものであるため、2つのログの対応するレコードの日付と時刻は同じです。タイム・スタンプの構文は、共通ログのタイム・スタンプと同じです。
-
agent: エージェントは、HTTP要求を発行したHTTPクライアントです。WebブラウザーなどのHTTPクライアントにとって、HTTP要求を発行する際にそれ自体を名前で識別するのは標準的な手続きです。これは必須ではありませんが、ほとんどのHTTPクライアントは名前によってそれ自体を識別します。Webサーバーは、その名前をエージェント・ログに書き込みます。
NCSA結合ログ形式は、NCSA共通ログ形式を拡張したものです。結合ログ形式には、共通ログ形式と同じ情報に加えて、参照元とユーザー・エージェント、そしてオプションとしてCookie情報が含まれます。情報は単一のファイルに含まれています。この形式の完全な例を下記に示します。
111.134.115.117 - - [08/Jun/1999:08:36:04 +0000] "GET /index.html HTTP/1.0" 404 55 "-" "Mozilla/3.0 [en] (WinNT; I)"
remotehost | logname | username | date
111.134.115.117 - - [08/Jun/1999:08:36:04 +0000]
request | status | bytes | referral
"GET /index.html HTTP/1.0" 404 55 "-"
agent | [cookies]
"Mozilla/3.0 [en] (WinNT; I)" "USERID=CustomerA;IMPID=01234"
|
Cookieは、HTTPサーバーが要求されたリソースと共にクライアントに戻す情報です。クライアントのブラウザーはこの情報を保管し、後でさらにリソース要求を発行する際に、それをHTTPサーバーに送ります。実際、HTTPサーバーは1つのHTTP要求に対して複数のCookieを確立することがあります。Cookieはキー = 値の形式です。複数のCookieの各キー/値のペアは、セミコロン (;) で区切ります。HTTPサーバーのロギング構成でCookieを記録するようになっているなら、要求されたリソースに関してHTTPサーバーに含まれている各Cookieが記録されます。
使用されるCookieの数とその機能は、Webサイトの実装者によります。Cookieの使用方法としてよくあるのは、セッションを特定するためです。同じクライアントからの複数のHTTP要求に関して、それぞれのCookie値を同じに設定できます。セッションを特定するためのCookieはセッションCookieと呼ばれ、セッションCookieの値はしばしばセッションIDと呼ばれます。Cookieのもう1つのよくある使い方は、ユーザーを特定するためです。ここでも、同じクライアントからの複数のHTTP要求で、Cookie値 (ユーザーIDなど) を同じに設定できます。ユーザーを特定するためのCookieはしばしばユーザーCookieと呼ばれ、その値はしばしばユーザーIDと呼ばれます。
W3C拡張ログ形式は、HTTP要求に関する情報を記録するための柔軟性の高い、拡張可能な形式です。NCSAの形式と同じように、このログ形式では1つのHTTP要求について1個のエントリーが記録されます。W3C拡張ログ形式とNCSA形式は、構文の点で違うだけでなく、前者にはさらに有用な、柔軟性の高い機能が含まれている点で違っています。拡張形式では、複数のオプション・フィールドを互いに独立して含めたり除外したりできることができるようになっています。さらに、拡張形式では、注釈やファイル形式などの情報を含めるために、ファイルに特殊なディレクティブを指定できます。それにより、いつでもログの形式を変更できます。#Fields ディレクティブは、各ログ・エントリーの内容を示します。基本フィールド型 (たとえば、リモート・ホスト、日付/時刻、HTTP要求、HTTP状況、バイト数、参照元、およびエージェントCookie) は、W3C拡張ログ形式にも含まれています。このログ形式では、その他の型もサポートされています。
エントリーだけでなく、ログにもディレクティブを含めることができます。実際、ログ・ファイルの行ごとに、ディレクティブまたはエントリーを内容とすることが可能です。ディレクティブには、ログ自体に関する情報が含まれます。"#" で始まる行はディレクティブ行です。有効なインクルードには、下記のものがあります。
-
Version: <integer>.<integer>使用する拡張ログ・ファイル形式のバージョン。 -
Fields: [<specifier>...]各エントリーに記録される情報を指定するフィールド識別子のリスト。 -
Software: stringログを生成したソフトウェア。 -
Start-Date: <date> <time>ログ記録が開始された日付と時刻。 -
End-Date:<date> <time>ログ記録が終了した日付と時刻。 -
Date:<date> <time>エントリーが追加された日付と時刻。 -
Remark: <text>注釈またはコメント。
ログ・エントリーには、HTTP要求に関する情報が含まれます。フィールドとフィールドの間はスペースによって区切られ、記録するデータのないフィールドにはダッシュ文字 (-) がプレースホルダーとして使用されます。
フィールドの数の少ないタイプW3拡張ログ形式からの抜粋を下記に示します。#Fields ディレクティブは、各ログ・エントリーの内容を示しています。
#Version: 1.0 #Date: 12-Jan-1996 00:00:00 #Fields: time cs-method cs-uri 00:34:23 GET /foo/bar.html 12:21:16 GET /foo/bar.html 12:45:52 GET /foo/bar.html 12:57:34 GET /foo/bar.html |
ここまで見てきたように、Webトラフィックを測定する方法としては、いくつかの技術的アプローチがあります。HTTPログの分析は、サイトの利用状況を示すトラフィックを分析するために、多くの企業で採用されている方式です。初めての方のために、HTTPロギング・サポートは、Webサイト配備で使用するHTTPソフトウェア・パッケージの一部として用意されていることがよくあります。その後、分析ソフトウェア製品またはサービス・プロバイダーを選択し、どの測定値を収集するかを決定する必要があります。このシリーズの記事が、HTTPサーバー・ログの分析の方法を理解する助けになることを希望しています。分析の成功を祈ります!
この記事で説明したように、HTTPサーバー・ログの分析は、Webサイトのトラフィックをモニターする方法として効果的なものとなり得ます。IBMでは、この方式による2つのソリューション、IBM WebSphere Site AnalyzerとIBM Surfaid Analyticsを用意しています。
IBM WebSphere Site Analyzerは、NCSA結合ログ形式、NCSAセパレート・ログ形式 (3ログ形式)、およびW3C拡張ログ形式のWebサーバー・ログを分析するためのインストール可能な製品です。IBM WebSphere Site Analyzer V3.5には、企業Webサイトの利用者の傾向、利用状況、およびコンテンツの分析や、WebSphere Commerce Suiteレポートの機能が含まれています。WebSphere Site Analyzerは、e-business上の決定を事実に基づいて下すのに役立ちます。WebSphere Site Analyzerを使用すれば、利用者の傾向と好みを調べたり、Webサイトのコンテンツと構造を管理したりでき、Webイニシアチブおよびキャンペーンの全体的な効果性を向上させることができます。
Site Analyzerは、さまざまなプラットフォームで使用でき、複数の構成がサポートされています。サンプル・レポート照会や、カスタムSQL照会を作成するためのQuery Builderが用意されています。また、Site Analyzerにはデータのカテゴリー化や集約の機能が含まれており、対象となるデータを表示するための機能が豊富に用意されています。Site Analyzerには、堅固なグラフ作成ユーティリティーも含まれています。グラフはGIFファイルとして作成され、最終レポート (HTML形式で表示される) に含められます。Site Analyzerを使用すれば、作成したHTMLレポートを複数のユーザーが見ることができるように、Webサーバー上で公開することができます。Site Analyzerについてさらに詳しくは、http://www.ibm.com/jp/software/websphere/siteanalyzer/ をご覧ください。図4 に、Site Analyzerの分析処理を示します。さまざまなWebサーバーからデータが収集されて、中心となるWebmart (データベース) に入れられ、そこでデータを操作したりレポートを作成したりできます。
図4: OLAPおよびデータ・マイニングを使用することによってWeb分析レポート機能を拡張する例
IBM Surfaid Analyticsは、IBMのアプリケーション・サービス・プロバイダー (ASP) の中心となる製品です。ASP提供製品のユーザーは、HTTPログをサービス・プロバイダーに送るか、またはサービス・プロバイダーがWebサーバー・ログを見ることができるようにします。サービス・プロバイダーは、サーバー・ログを分析して、レポートをユーザーに送付します。IBM Surfaid Analyticsは、米国でのオリンピックやグラミー賞などのイベントにおいて、実際にWeb分析機能を提供してきた製品です。SurfAidについてさらに詳しくは、Surfaidのサイト (参考文献を参照) をご覧ください。または、817-962-SURF に電話するか (米国の場合)、surfaid@us.ibm.com にe-mailをお送りください。図5 に、IBM Surfaid Analyticの処理を示します。
図5: IBM Surfaid Analyticsの処理
- この記事で説明されていることの概要については、Webトラフィックの測定 (第1回) をご覧ください。
-
RFC 931 には、ログ名フィールドについての付加的な情報が提供されています。
-
National Center for Supercomputing Applications (NCSA) のサイトには、Web測定に関する豊富な情報が提供されています。
-
IBM Global Services Surfaid Analytics は、Web測定ソリューションに関心を持つ会社にとって役立つことでしょう。
- クリックをビジネスに結び付けることについては、Aberdeen GroupのサイトにあるTranslating Clicks into Business (2000年12月) のページをご覧ください。
Andrei Malacinskiは、IBMのWebソフトウェア開発のソフトウェア・エンジニアリングです。ノースカロライナ州Research Triangle ParkのIBM Application Integration Middleware Labに勤務しています。Andreiは、IBMのWindows、OS/2、およびUNIXプラットフォーム用の数々のアプリケーション開発製品において開発者として、またチーム・リーダーとして活躍してきました。現在、彼は IBM WebSphere Site Analyzer のチーム・リーダーそしてリード開発者です。連絡先は、malacins@us.ibm.com です。
Scott Dominickは、IBMのソフトウェア・エンジニアであり、ノースカロライナ州Research Triangle ParkにあるIBM Application Integration Middleware Labに勤務しています。彼は、1992年にNorth Carolina State Universityで学士号を取得しています。現在は、 IBM WebSphere Site Analyzer においてWebSphereのツール開発の分野で活躍しています。連絡先はscottdom@us.ibm.com です。
Tom Hartrickは、現在 IBM WebSphere Site Analyzer 製品のソフトウェア・エンジニアであり、ノースカロライナ州Research Triangle ParkにあるIBM Application Integration Middleware Labに勤務しています。Tomは、Rochester Institute of Technologyでコンピューター・サイエンスの学士号を取得しており、WebSphere Application Serverや他のソフトウェア・プロジェクトにおいて開発マネージャーとして活躍してきました。連絡先は thartric@us.ibm.com です。
目次
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ