はじめに

ポータル・アナリティクスとは何か

順調に成功を収めている組織は、初期ポータル・リリースの計画と開発に多大な時間を費やしています。この作業は必要不可欠なものですが、ポータルの存続期間全体を考えると、必要な全計画作業の一部でしかありません。ポータルを管理し、監視することも必要で、ポータルが稼動してから初めて明らかになる新しい使用パターンにもポータルを適応させなければなりません。

ポータル・プロジェクトを開発する際には通常、前提、経験、予想に基づいてポータルのサイズを決定します。ですが時が経つにつれ、「このポータルで、進化するユーザーのニーズに応えられるのだろうか」、「ユーザーは実際にこのポータルをどのように使用しているのだろうか」などの疑問が生じてきます。このような疑問に答えられるのが、使用状況データを収集して処理し、レポートするプロセス、ポータル・アナリティクスです。

WebSphere Portal は、使用状況レコードを専用ログ・ファイルに書き込みます。このログのフォーマットは業界標準 (NCSA Combined) に準拠しているため、ポータル使用状況データは、お好みのレポーティング･ツールやアナリティクス・ツールに統合することができます。また、ポータル・アナリティクスには、ポータルでの将来のデマンドを予測するのに役立つトレンド分析技法が組み込まれています。そのためポータル・オペレーターは、しきい値に達してから予告なしに打撃を受けるといったことなく、コミュニティーのニーズに合わせて積極的な適応計画を立てることができます。

WebSphere Portal には、包括的な計測機能が揃っています。この記事を読めば、計測によって提供されたデータに基づいてレポートとアナリティクス情報を引き出す方法が分かるはずです。ここで紹介する例では、標準的な統計レポートのエンドツーエンドのレポート方法を取り上げ、オープン・ソース・レポーティング･ツールでどのようにポータル・アナリティクスにログを使用するかを説明します。

ポータルの使用状況は、なぜ重要なのか

ポータルは通常、1 つまたは複数の特定の目的を持っています。例えば、情報にアクセスしやすくする、ユーザーがより効果的かつ効率的に作業できるようにするなどの目的があり、また、技術的に分離した情報システムを透過的に統合するために使用されることもあります。通常、組織はポータルが果す目的を厳密にイメージします。この目的が果されているかどうかの測定は重要です。さらに、ポータルがユーザーにどれだけ役立っているかを把握することも、ポータルへの投資を調整する手掛かりとなります。

ログのレポート内容

WebSphere Portal では以下のユーザー・アクティビティーをログに記録して、アナリティクスに使用できるようにします。

• ページの管理 (ページの作成、読み取り、更新、削除)
• 特定ページに対するユーザーの要求 (ページに組み込まれたポートレットも含む)
• セッション・アクティビティー (ログイン、ログアウト、タイムアウト、ログイン失敗)
• ユーザー管理アクション (ユーザーおよびグループの作成、読み取り、更新、削除)

WebSphere Portal ログで作成可能なデータについての詳細は、WebSphere Portal インフォメーション・センターのトピック「サイトの分析」(「参考文献」を参照) を参照してください。

ポータル・アナリティクスの構成要素

Patricia Seybold Group の最近のレポートでは、ポータル・アナリティクスに以下の基準を定義しています。

• 計測

  ポータル技術プラットフォームは、使用状況とパフォーマンスを示す情報を収集する必要があります。

• リアルタイム分析

  さまざまな点でカスタマーのポータルがどの程度効果的に機能しているかをリアルタイムで把握しなければなりません。パフォーマンス・データをデータウェアハウスに移さずに (または移す前に)、クエリーとアナリティクスを実行できます。

• レポート

  ポータル技術プラットフォームは、カスタマーがどのようにコンテンツと対話しているか、そしてファシリティーがどの程度効果的に実行されているかを提示するレポートをまとめる必要があります。これらのレポートは、計測された情報をわかりやすいフォーマットで示さなければなりません。

• アナリティクス

  カスタマーの動向とカスタマーのポータル・パフォーマンスを理解するにはレポートでは不十分なことがあり、分析的処理が必要になる場合があります。

この記事では測定に焦点を絞り、WebSphere Portal で作成されたデータからレポートを取得する方法について簡単に説明します。

ポータル・アナリティクスの長期的ビジョンは、機能および機能以外の両方の点でサイトでのデマンドに自動的に対応する自己最適化ポータルです。例えば、ポータル・サイトが人気の高いニュース・サービス (「スラッシュドット効果」) で参照されているとします。自己最適化ポータルでは、アクセス率が標準を上回って高くなると、予備サーバーが現在の構成で自動的にデプロイされ、既存のクラスターに追加されます。デマンドが落ち着いてくると、予備サーバーが他の目的のために解放されます。

機能に関する例には、ユーザーがアクセスすると同時にもっとも人気の高いページだけを表示するようなポータルのナビゲーションがあげられます。ユーザーがサイトの奥深くに進むにつれ、表示されるナビゲーション要素が増えていきます。

ポータル・アナリティクスとログとの違い

ポータル・アナリティクス計測は、監査、パフォーマンス、システム・イベントなどのログの代わりではありません。このようなログの使用目的は異なります。

• 監査ログ は通常、セキュリティーに敏感な環境で使用され、このログにはポータルのランタイム構成に対する変更が記録されます。監査は、WebSphere Portal に不可欠の管理機能です。一方ポータル・アナリティクスは、エンド･ユーザーが表示するポータルの部分、そしてエンド・ユーザーがどのようにポータルを使用しているかを対象としています。

• パフォーマンス・ログは、ポータル全体の特定部分が実動環境でどの程度の性能レベルで実行しているかを判断するために使用されます。オペレーターはパフォーマンス・ログによって、ポータルがサービス・レベル・アグリーメント (SLA) を遵守すると同時に、貴重なリソース (CPU やメモリーなど) をどれだけ消費しているかを判断できます。

• システム・イベント･ログは、システム管理者がポータルの実行中に発生した問題を把握するために使用します。通常、システム・イベント・ログのレコードには Java™ 例外トレースが含まれるため、管理者はこれによって適切な措置を取ることができます。

代わりのソリューション

この記事では、IBM SurfAid (現在は Coremetrics が所有) や Google Analytics などの外部ログ・サービスを使用する手法は取り上げていません。これらのサービスでは通常、ユーザーに配信されるページに、サービス・プロバイダーを示す特定のコンテンツ (インライン JavaScript やリモート・イメージなど) を配置することによってユーザー・アクティビティーを追跡します。ページをレンダリングすると、ブラウザーによって、このコンテンツの項目がサービス・プロバイダーから取得されます。サービス・プロバイダーはアクセス・ログを分析して、何がいつ要求されたかについてのレポートをカスタマーに提供します。この手法は、「Web ビーコン」、「Web バグ」などの名前で呼ばれています。

上に戻る

ポータル・アナリティクスを使用する

WebSphere Portal は、静的ページを送信するサーバーを分析するためのロギングと同様に、イベントを専用ログに書き込むことによってアナリティクス・ロギングを行います。ポータル・アナリティクス・ファイルの名前は sa.log (sa は site analytics の略) で、通常は $WP_HOME/log/ ディレクトリーに置かれています。

sa.log 内のそれぞれの行は、ポータルに対する要求によって発生した特定のイベントを表します。単一の要求 (例えば、特定のページに対する要求) によって複数の行が sa.log に書き込まれることもあります。ロギングのタイプと量は、該当するロガーを構成することによってカスタマイズできます。

WebSphere Portal では以下のサイト・アナリティクス･ロガーを定義しています。

ユーザーがポータルで行った操作ごとに、該当するロガー (構成されている場合) が新しいエントリーをサイト・アナリティクス・ログ・ファイルに作成します。各アクティビティーのログ・レコードには、上記の定義に従った汎用フォーマットが使用されます。違いはリクエスト URI で、ここにはアクティビティーごとに特有のデータが記録されます。

例えば、ページ・ロガーはユーザーが要求したページの名前、親ページ (派生したページの場合) の名前、そしてこれらのページに固有のその他のデータを記録します。セッション・ロガーも同様に、ユーザーがポータルにログインまたはログアウトするごとにレコードを作成します。ログアウトの場合、セッション・ロガーはログアウトの理由 (タイムアウトなど) を URI パラメーターとしてログに記録します。

各ロガーに固有のデータは、リクエスト URI にパス情報または URI パラメーターとして渡されます。

ロガーによるイベントの記録

それでは、ロガーの詳細に目を向けて、関連するリクエスト URI のフォーマットを検討してみましょう。

ログインおよびログアウトのユーザー・アクティビティーを記録する役割を担うのは、SiteAnalyzerSessionLogger です。ユーザーがポータルにログインするときのリクエスト URI は /Command/Login で、ユーザー ID がログ・レコードの USER_ID の部分に記録されます。ログイン・アテンプトが失敗すると、クエリー・ストリング ErrorCode=x (x はエラー・コード値) がリクエスト URI に追加されます。ステータス・コードは該当する HTTP ステータス・コードに設定されます。

ユーザーが明示的に、またはタイムアウトによってログアウトすると、リクエスト URI が /Command/Logout のログ・レコードが作成されます。ログアウトの理由がセッション・タイムアウトの場合、リクエスト URI にクエリー・ストリングReason=SessionTimedOut が追加されます。

ユーザー管理イベントのロギング

ポータルの管理インターフェースで行われるユーザー管理イベントをログに記録するには、SiteAnalyzerUserManagementLogger を使用します。このロガーは新規ユーザーが作成されると、リクエスト URI にこのイベントを /Command/UserManagement/CreateUser として記録します。ユーザーを削除すると、リクエスト URI は /Command/UserManagement/DeleteUser となります。

グループの作成、変更、削除に関連するイベントの記録にも同じメカニズムを使用します。この場合の URI はそれぞれ、/Command/UserManagement/CreateGroup、/Command/UserManagement/ModifyGroup、/Command/UserManagement/DeleteGroup となります。

操作対象のユーザーまたはグループに関するその他の詳細情報は現在、ログに記録されません。重要: 変更 (Modify) イベントについてのロギングは、WebSphere Portal V6 以前のリリースでは使用できません。

ページ・イベントのロギング

SiteAnalyzerPageLogger は、ページが要求側に表示されるごとに対応するログ・エントリーを作成します。リクエスト URI は /Page/ で始まり、そのページの一意のオブジェクト ID と名前が続きます。

SiteAnalyzerPageLogger は、あらゆるページ管理も記録します。リクエスト URI は、/Command/Customizer/CreatePage、/Command/Customizer/EditPage、または /Command/Customizer/DeletePage のいずれかです。リクエスト URI には、管理対象ページの一意のオブジェクト ID と名前がクエリー・ストリングのパラメーターとして追加されます。例えば、以下のようになります。

/Command/Customizer/EditPage?Page=6_0_5RH_[CONTENT_NODE:6001]&PageName=Products

上記の例は、オブジェクト ID が6_0_5RH で、名前が Products のページが編集されたことを示します。

ポートレット・イベントのロギング

SiteAnalyzerPortletLogger が構成されている場合、このロガーはポートレットがどのページに含まれているかに関わらず、レンダリングされたポートレットごとにログ・レコードを作成します。

このログ・レコードのリクエスト URI は、/Portlet/ で始まり、レンダリングされているポートレットの一意のオブジェクト ID およびポートレット名が追加されます。クエリー・ストリングにはポートレットの一意のオブジェクト ID とともに現在のポートレット・モード (表示、編集、構成、ヘルプ) と状態 (標準、最小化、最大化) が組み込まれます。

SiteAnalyzerPageLogger と SiteAnalyzerPortletLogger の両方が有効になっている場合、単一のページをレンダリングすると sa.log に複数のログ・レコードが作成されることになります (ページに 1 行、そのページのポートレットごとに 1 行)。

ポートレット・アクションのロギング

SiteAnalyzerPortletActionLogger は、WebSphere Portal の一般イベント・インフラストラクチャーによって呼び出されることはありません。このロガーが記録を行うのは手動で呼び出した場合で、/PortletAction/ で始まるリクエスト URI を書き込みます。

エラーのロギング

ページやポートレットのレンダリング中にエラーが発生すると、SiteAnalyzerErrorLogger が対応するレコードをアナリティクス・ログ内に作成します。これはシステム・イベント・ログ (wps_*.log) に代わるものではなく、ビジネスの観点からエラーを記録するためのものです (一定の期間中に失敗したポートレット数など)。

レポート対象のエラーがある場合、対応するログ・レコードは /Error/Portlet または /Error/Pageで始まります。

アプリケーション・アクション・ロガー

このロガーは将来の使用に備えて予約されています。このロガーの目的は、ポートレットをサイト・アナリティクス・ログに利用できるようにすることです。ただし、この記事を書いている時点ではまだ、このロガーの使用はサポートされていません。

このロガーが書き込みを行う場合、リクエスト URI は /ApplicationAction/ で始まることになります。

ログ・ファイル・フォーマットの検討

ログ・レコードのフォーマットは、NCSA Combined ログ・フォーマットに準拠しています。EBNF (Extended Backus-Naur Form) を使用して正式に指定したフォーマットは、以下のようになります。

STRING = ? any printable character except the quote sign ?;
HOST, CLIENT_ID, USER_ID = STRING;
HYPHEN = "-";
QUOTE = """;
SIGN = "+" | "-";
SPACE = " ";
TWODIGITHOURS = "00".."23";
MINUTES = "0..59";
DAY = "00..31";
MONTH = "01..12";
SLASH = "/";
COLON = ":";
RFC822TIMEZONE = SIGN SPACE TWODIGITHOURS SPACE MINUTES;
TIMESTAMP = DAY SLASH MONTH SLASH YEAR COLON HOURS COLON MINUTES COLON SECONDS SPACE 
   RFC822TIMEZONE;
PORT = 0..65535;
URI = "http" | "https" + COLON + SLASH + SLASH + HOST + PORT + STRING;
STATUS_CODE = NUMBER ? must be a legal HTTP status code ?;
BYTES = NUMBER;
REFERER = URI;
REQUEST = "GET" | "POST" | "PUT" | "DELETE" URI SPACE "HTTP/1.0" | "HTTP/1.1";
SA_LINE = HOST SPACE CLIENT-ID|HYPHEN SPACE USER_ID|HYPHEN SPACE "[" TIMESTAMP"]" 
   SPACE QUOTE REQUEST_URI QUOTE STATUS_CODE SPACE BYTES SPACE REFERER SPACE QUOTE 


   USER_AGENT QUOTE SPACE QUOTE COOKIES QUOTE;

リクエスト URI は作り物であるため、ブラウザーから呼び出すことはできません。リクエスト URI の唯一の目的は、NCSA 互換の共通の方法で関連するロギング情報を伝えることです。URI は、サイトの構造やコンテンツに対する変更によって変わることはありません。必要に応じて、ページ名やページ ID を使用してレポートを構成することができます。

情報の関連付け

ユーザーがどのページを要求しているかを知ると同時に、さまざまな要求の相互関係を把握したいという場合があります。HTTP はステートレス・プロトコルなので、ユーザーが現在表示しているページの前に表示していたページに関する固有の情報はありません。この問題は通常、ユーザー・セッションを取り入れることで解決します。WebSphere Portal および基礎となる WebSphere Application Server も同じく、ユーザー・セッションを使用して解決しています。

WebSphere Portal は cookie によってセッションを追跡します。デフォルトの cookie は一般的に JSESSIONID と呼ばれています。WebSphere Portal はユーザーがログインするごとに新規セッションを作成し、そのセッションの鍵を cookie の値としてブラウザーに保管します。その後、ブラウザーは各要求で cookie を元のサーバーに送信します。ブラウザーはこの cookie の値を読み取ることで、特定の要求を特定のセッション、および以前の要求に関連付けることができます。

ユーザーのセッションを使用して、サイト・アナリティクス・ログ内の関連要求を見つけることもできます。要求をセッションごとにグループ化して、追加情報を収集するという方法です。例えば、ポータルでもっとも頻度の高いクリックのトレールを見つけるには、すべての要求をセッションごとにグループ化し、それから各セッションのクリック・トレールを抽出します。同様のトレール数をカウントすると、ポータルで「もっとも使用された」クリック・トレールを見分けることができます。

別の関連付けのメカニズムとして、専用の「トレース」cookieをユーザーのブラウザーに送信するという方法もあります。この cookie は、他の cookie と同じように sa.log に書き込むことができます。この cookie の名前と値はポートレット・プログラマーが選択できるため、オーバーヘッドをそれほど増やさずに任意のデータを sa.log に記録できます。

実例

ページ要求のロギング

ユーザーがページを要求すると (PageLogger が有効になっている場合)、WebSphere Portal は以下のように、そのページのログ・エントリーを作成します。

localhost - wpsadmin [15/Jun/2006:23:42:10 +0200] "GET /Page/6_0_4D_[CONTENT_NODE:
141]/Welcome HTTP/1.1" 200 -1 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.8.0.4) Gecko/20060508 (CK-IBM) Firefox/1.5.0.4" "JSESSIONID=
0000c9fiQ6Q14XUbsp3QFQHFkq9:-1"

このログ・エントリーからは、以下のデータを入手できます。

• localhost による要求であること。
• この要求に認証されたユーザーは wpsadmin (ユーザーの短縮名) であること。
• この要求の処理は 2006 年 6 月 15 日午後 11 時 42 分 10 秒、GMT +0200 に終了したこと。
• 「Welcome」というタイトルのページが要求されたこと。
• この要求は正常に完了したこと (HTTP 応答コード 200)。
• 戻されたマークアップのサイズはロガーに不明であること (-1)。
• この要求は、「Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 (CK-IBM) Firefox/1.5.0.4」で識別されるブラウザーによって行われ、このブラウザーは実際には Windows® XP 上の Firefox 1.5.0.4 であること。
• この要求は「0000c9fiQ6Q14 XUbsp3QFQHFkq9」というセッション ID で識別されるセッション内で行われたこと。

ページおよびポートレット要求のロギング

ユーザーがページを要求すると、PageLogger および PortletLogger の両方が有効になっている場合は、要求されたページとそのページ上の各ポートレットに対するログ・エントリーが作成されます。最初のログ・エントリーとそこに含まれる情報は、上記と同様です。

localhost - wpsadmin [15/Jun/2006:23:42:10 +0200] "GET /Page/6_0_4D_[CONTENT_NODE:
141]/Welcome HTTP/1.1" 200 -1 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; 
en-US; rv:1.8.0.4) Gecko/20060508 (CK-IBM) Firefox/1.5.0.4" "JSESSIONID=
0000c9fiQ6Q14XUbsp3QFQHFkq9:-1"

ただし今回は PortletLogger が有効になっているため、ページ上に常駐するポートレットごとに追加エントリーが作成されます。例えば、以下のようになります。

localhost - wpsadmin [15/Jun/2006:23:42:16 +0200] "GET /Portlet/5_0_49_[PORTLET_
ENTITY:137]/Welcome_to_WebSphere_Portal?PortletPID=5_0_49_[PORTLET_ENTITY:137]&Portlet
Mode=View&PortletState=Normal HTTP/1.1" 200 -1 "http://localhost/Page/6_0_4D_[CONTENT_
NODE:141]/Welcome" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4)
Gecko/20060508 (CK-IBM) Firefox/1.5.0.4" "JSESSIONID=0000c9fiQ6Q14XUbsp3QFQHFkq9:-1"

この行には、以下の追加情報が含まれます。

• 「Welcome to WebSphere Portal」というタイトルのポートレットがレンダリングされたこと (/Portlet/ 5_0_49_[PORTLET_ENTITY:137]/Welcome_to_WebSphere_Portal)。
• このポートレットは表示 (View) モードでレンダリングされ、状態は標準 (Normal) であること (最小化でも最大化でもなく、PortletMode=View&PortletState=Normal)。
• このポータルは「Welcome」という名前のページに位置すること (参照元が http://localhost/Page/6_0_4D_[CONTENT_NODE:141]/Welcome)。

どのポートレットが要求されたかをログに記録するのは、一見すると不要なように思えます。それは、ポータルの静的構成では、特定のページにどのポートレットがデプロイされているかが正確に指示されているためです。ただし、エディター （Editor） のロールでページにアクセスしているユーザーが、ポートレットを任意に削除または置換する場合もあるため、ページとポートレットの両方をログに記録すれば、ユーザーが要求したポートレットを判断することが可能になります。

PortletLogger も同様に、参照元フィールドにポートレットが含まれたページを記録します。PageLogger が無効にされている場合は、このフィールドによって、ポートレットをレンダリングしたページを判断することができます。

ログから入手できる情報

このデータに基づいて、ログ・アナリティクス・パッケージは以下の内容のレポートを作成できます。

• ポータルにアクセスしたユーザーのホスト数とドメイン数 (HOST 要素をカウントして合計)
• 認証済みユーザーごとのログイン回数 (USER_ID 要素をカウントして合計)
• ロボットとブラウザーの詳細 (USER_AGENT 要素をカウントして合計)
• 要求されたが見つからなかったページ数 (STATUS_CODE)
• 検索エンジン、キー・フレーズ、キー・ワード (REFERER)
• ブラウザーによってレポートされたオペレーティング・システムの種類 (USER_AGENT)
• ユーザーの参照元ページ (REFERER)
• 入口および出口 URL (固有のセッション内でもっとも頻繁に要求された最初と最後のページ)

上記にリストした他にも、多くのレポートおよび合計が考えられます。例えば、ユーザーの共通クリック・トレールや、マーケティング・キャンペーンに関する反応、それにデータウェアハウスの分野にも及ぶ情報などです。これらの情報は一般的に、大掛かりな特有のプロジェクトでの課題であり、単純なログ・レポートとアナリティクスでは、そのような高度な質問には答えられません

上に戻る

オープン・ソース・ツールによるレポート作成

サイトの分析とレポート作成には、商用およびオープン・ソースを合わせて広範なサイト分析ツールとレポーティング・ツールを使用できます。以下のサンプル・レポートでは、人気の高いオープン・ソース AWStats パッケージを使用します。

サンプルの概要

このサンプルでは、「This Month's Top Pages」という 1 つの単純なレポートを作成します。このレポートは特定の期間内に要求されたページのグラフを表示し、ページの名前、アクセス回数 (ページが要求された回数) を示します。

計測を有効にする

まず始めに、WebSphere Portal で関連する計測を有効にします。

• WebSphere Application Server 管理コンソールで、以下の値を設定してロガーを有効にします。

  SiteAnalyzerPageLogger.isLogging=true
  SiteAnalyzerPortletLogger.isLogging=true

  通常、この設定はすでに存在します。その場合は、単に新しい値に設定してください (この手順についての詳細は、Portal WebSphere V6 インフォメーション・センターの構成プロパティーの設定に関するトピックを参照してください)。

• WebSphere Portal を再起動します。
• ポータルをいくつか要求して、sa.log に新しいレコードが書き込まれていることを確認します。

構成 AWStats をインストールする

AWStats にはインストール手順についての豊富な資料が付属しています。ここでのサンプルでは、オフライン分析しか使用しないので、以下の手順を行うだけで十分です。

1. AWStats をダウンロードします。
   
   
2. パッケージをディレクトリーに解凍します。
   
   
3. 資料に従ってサイトを構成します。例えば、awstats.localhost.conf (localhost にはサイト名を使用) を作成し、以下の構成ステートメントを変更します。
   
   

   LogFile="C:\Program Files\IBM\Portal51UTE\PortalServer\log\sa.log" LogFormat=1 LogSeparator=" " SiteDomain="localhost" DNSLookup=1 AllowToUpdateStatsFromBrowser=0

   
   
4. 以下を実行して、初期統計データベースを作成します。
   
   
5. perl awstats.pl -config=localhost -updatebr />
   
6. 以下を実行して、図 1 に示す概要レポートを作成します。br />
   
7. perl awstats.pl -config=localhost -output -staticlinks > awstats.localhost.html
   
   図 1. AWStats によって生成された概要レポート
   
   
   
   
   

レポートをテストする

要求スキーマによってレポートがどのように変わるかを見るため、一連のテスト・ページ、テスト・ユーザー、そしてテスト要求を作成します。これによって、AWStats がさまざまな要求スキーマをどのように分析してレポートするかが分かります。

ページのテスト階層を作成する

まず、ポータルにたくさんの要求を行う小規模な自動テストをセットアップします。これらを呼び出すことで作成されるレポートが、行われた要求を正確に示すことになります。

このサンプル用の要求を作成するには、Apache の JMeter ツールを使用します。手順を簡潔にするため、JMeter で呼び出される事前定義されたポータル・ページの階層を作成します。サンプル・ページの構造は、ibm.com ホーム・ページのパーツと同様です。

テストを簡潔にするため、各ページには共通テンプレート・ページを使用します。この記事のサポート・ファイルのダウンロードには、完全なサンプル階層を作成できる XMLAccess ファイル (createPortalAnalysisTree.xml) が含まれています。

各ページに、URI マッピング・コンテキストを割り当てます。これによって、JMeter を極めて簡単にセットアップできます。

テスト・ユーザーのグループを作成する

このサンプル・レポートは、ページごとの要求回数を示すだけでなく、認証済みユーザーごとの要求回数も示します。XMLAccess では、ユーザー・レジストリー接続が読み取り/書き込みアクセス用に構成されていれば、ユーザーとグループを作成することができます。ダウンロード・ファイルのコード・アーカイブには、多数のテスト・ユーザーとこれらのテスト・ユーザーのグループを作成する XMLAccess スクリプト (createPortalAnalyticsTestUsers.xml) が含まれています。

サンプル・ページ階層を作成するスクリプトでは、「Portal Analytics Test-Users」グループが存在することを前提としています。createPortalAnalyticsTestUsers.xml スクリプトは、このグループも作成します。

JMeter をインストールして構成する

JMeter は、Apache の Jakarta プロジェクトに含まれる単純なロード・テスト・ツールです。これは生粋の Java ツールで、各種プロトコルを使用してサーバー・パフォーマンスをテストします。このサンプルでは、そのうちの HTTP 接続を使用して、ポータルに対する一連の要求を作成します。次に、JMeter によって行われた要求と、ポータル・アナリティクスによって sa.log に記録された結果を関連付けます。

この記事で記載した例は、JMeter 2.2 で作成したもので、ダウンロードすることができます。すべての前提条件を満たした後、JMeter ディレクトリーの bin サブディレクトリーから起動してください。このツールのメイン・ウィンドウは、図 3 のように表示されます。

初期構成は、基本的に JMeter のユーザー・マニュアルの手順と同じで、サンプルのテスト・ユーザー (analyticsTest001 から analyticsTest009) のいずれかでログインするテスト計画を作成した後、ホーム・ページを要求します。思考時間で中断することなく、続いて製品ページ、サービス・ページ、サポート・ページ、およびアカウント・ページが要求されます。この反復動作は、ログアウトしなくても停止します。

JMeter の詳細な構成詳細は省きますが、テストを実行するために使用した構成項目は主に以下のとおりです。

• 10人のユーザー (スレッド) でスレッド・グループ「Analytics Test Users」を実行します。
• HTTP Request Defaults を http://localhost:9081 に設定します。
• HTTP Cookie Manager を使用して cookie を追跡します。ただし、毎回反復するごとに cookie をクリアします。
• HTTP Header Manager がカスタム User-Agent ヘッダーを送信します。この手法を実動環境で使用すると、作り物の JMeter 要求と実際のユーザーを区別することができます。
• 続いて、以下の 5 つの HTTP 要求を行います。
  1. ログイン。以下の既知のログイン URL を使用して、任意に選択したユーザー ID を渡します。
     
     /wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid= <your user id>&password=<your password>
     
     
  2. /analytics/home
  3. /analytics/products
  4. /analytics/services
  5. /analytics/support
  6. /analytics/account
• 最後に、View Results Tree にテスト計画の結果が表示されます。

ダウンロード・ファイルのアーカイブには、以下のサンプル JMeter テスト計画 (PortalAnalyticsExample.jmx) が含まれています。

テストを実行する

このテストは簡単に実行できます。すべての情報 (テスト・ユーザー、ページ階層、およびテスト計画) を設定したら、JMeter ツールの Run => Start を選択してテストを起動します。するとツールが個別のテスト・ユーザーをモデル化した 10 のスレッドを作成します。各ユーザーがポータルにログオンし、定義されたページの順序を選択します。

結果

テスト計画の実行後にレポートを更新するには、以下を実行して AWStats レポートを呼び出します (「参考文献」を参照)。

perl awstats.pl -config=localhost -output -staticlinks > awstats.localhost.html

図 5 の結果では、サンプル・テスト計画でもっともアクセス回数が多いページは、ホーム・ページであることがわかります。ですが、それぞれの反復動作では 10 人のテスト・ユーザーしかシミュレートしなかったはずです。それなのに、アクセス回数は 20 回になっています。これは、WebSphere Portal と J2EE™ の動作方法を考えれば何も驚くことではありません。最初に行ったのは、ログイン要求です。要求が成功すると、WebSphere Portal は、ユーザーが表示アクセス権を持つ先頭ページを表示します。「My Portal」の下にサンプル・テスト階層しかなければ、最初に表示されるこの先頭ページはホーム・ページとなります。一方、ログイン後の次の呼び出しでも、ホーム・ページが要求されています。その結果、ホーム・ページのアクセス回数が 2 倍となっているのです。

もっともアクセス回数の多いポートレットは「Information Portlet」です。ここでも同じく、単一のページ・テンプレートにはポートレットが 1 つしかないため、このような回数になっています。

実際のシナリオでは、レポートはこれよりずっと複雑に見えるかもしれませんが、このサンプルで説明した単純明快なセットアップによって、ポータル・アナリティクスの機能が明確に理解できるはずです。

上に戻る

WebSphere Portal V5.1 でのパラメーター設定

ポータル・アナリティクス用に WebSphere Portal V5.1 を構成する手順は、WebSphere Portal V6 の場合とは多少異なります。主な違いは、WebSphere Portal V5.1 ではすべての構成設定をプロパティー・ファイルで行いますが、WebSphere Portal V6 では WebSphere Application Server V6 の Resource Environment Provider 機能を使用して、その構成を管理するという点です。

WebSphere Portal V5.1 でアナリティクス計測を有効にするには、<wp_home>/shared/app/config/services/SiteAnalyzerLogService.properties のロガーを以下のように設定して有効にします。

SiteAnalyzerPageLogger.isLogging=true
SiteAnalyzerPortletLogger.isLogging=true

通常、上記は既存のコメント・アウトされた行なので、コメントを解除するだけで十分です。その他の要素は、WebSphere Portal V6 の要素と同様です。

上に戻る

まとめ

WebSphere Portal のアナリティクス・ログには、ポータル・アナリティクスに必要なすべてのデータが揃っています。記録される URL はクリック可能な本物の URL ではありませんが、ポータルのユーザーが表示したページを見つけるために必要な関連情報を提供します。

この記事では、WebSphere Portal で収集されたアナリティクス・ログ・ファイル内のデータを説明し、AWStats オープン・ソース Web サイト分析パッケージでそのデータを使用する方法を紹介しました。

上に戻る

ダウンロード

ダウンロード形式について

参考文献

• NCSA Combined Log Format
  
  
• WebSphere Portal V5 インフォメーション・センターのトピック「サイトの分析」
  
  
• WebSphere Portal V6 インフォメーション・センターのトピック「サイトの分析」
  
  
• 「IBM WebSphere Portal 5.1.0.1. How IBM's Portal Stacks Up against Our Customer Portals Evaluation Framework」(Mitchell Kramer 著、Patricia Seybold Group)
  
  
• スラッシュドット効果
  
  
• 「監査サービス」(WebSphere Portal 5.1 インフォメーション・センター)
  
  
  
• Measuring Web traffic, Part 1
  
  
• Measuring Web traffic, Part 2
  
  
• EBNF (ISO 標準規格 ISO/IEC 14977:1996(E)、最終案)
  
  
• 「Interface HttpSession」(J2EE 1.4 API 資料)
  
  
• AWStats
  
  
• Apache JMeter
  
  
• Building a Web Test Plan
  
  
• 「Portal Usage Analytics: A Key Tool in the Battle Against the Empty Portal」(Robert Haddad 著)
  
  
• 「Analyzing Web Logs with AWStats, Part 1」(Sean Cartos 著)
  
  
• 「Analyzing Web Logs with AWStats, Part 2」(Sean Cartos 著)
  
  

著者について

Stefan Liesche は、ドイツ・ボブリンゲン所在の IBM Development Laboratory のシニア・スタッフ・マネージャーです。ドイツ University of Hildesheim でコンピューター・サイエンスの修士号を取得した後、ソフトウェア開発分野で 12 年の経験を積んでいます。IBM には 1998 年、サービス・チームの一員として入社し、複合環境を対象とした大規模なエンドツーエンドの e-ビジネス・ソリューションの設計を専門としていました。IBM WebSphere Portal での経歴は長年に及びます。WebSphere Portal 開発アーキテクチャー・チームに加わる前は、大規模ポータル・ソリューションの構築に従事した経験を持ちます。現在、彼は Workplace and Portal Foundation の主任アーキテクトです。

Steffen Uhlig は、ドイツ・ボブリンゲン所在の IBM Development Laboratory で、WebSphere Portal を対象としたラボ・サービスのシニア・コンサルタントとして活躍しています。Mittweida University of Applied Sciences で電気工学の学位を取得した彼は、IT 産業で 10 年の経験を積んでいます。2001 年に IBM に入社する以前は、デジタル・オーディオ・ブロードキャスティングとその関連マルチメディア・オブジェクト・トランスファー用ソフトウェアの設計およびインプリメンテーションを手がけてきました。IBM 入社後は、WebSphere Portal のアーキテクチャーおよびインプリメンテーションに関するクライアントの支援に従事しています。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• ポータル・アナリティクスを使用する
• オープン・ソース・ツールによるレポート作成
• WebSphere Portal V5.1 でのパラメーター設定
• まとめ
• ダウンロード
• 参考文献
• 著者について
• コメント