機械翻訳について
  1. ユーザーズ・ガイド
  2. 監視対象トラフィックのレポートの制御

12 監視対象トラフィックのレポートの制御

この章では、監視対象トラフィックのレポートを情報要件に合うように最適化する方法について説明します。 また、ネットワーク環境で使用するCookieテクノロジの仕様、名前付きWebサーバーとクライアント・グループの使用方法、および様々な高度な機能(ルール順序設定やデータ保存ポリシーなど)についても説明します。

通信の概要の表示

ネットワーク・トラフィックの概要を開くには、「システム」、「ステータス」の順に選択します。 RUEIのデプロイメントで処理中のシステムのリストが表示され、例を「図12-1」に示します。

図12-1 「データ処理ステータス」ウィンドウ


データ処理

「レポータ統計」をクリックするか、処理エンジンを開き、「処理統計」をクリックして、ヒット、ページ、セッション処理に関する情報およびシステム・ロードを表示します。 例を図12-2に示します。

図12-2「データ処理」ダイアログ


図12-2の説明が続きます
「図12-2 「データ処理」ダイアログ」の説明

「パフォーマンス」タブの「使用可能なリソース使用率(%)」項目は、現在の処理レベルを示します。 この値が100%に近づくと、データの処理に遅延が発生し始め、データをリアルタイムで処理できなくなります。

この機能はアプリケーション・ロジックに基づいているため、表示されるレポートには非アプリケーション(スイート、サービス、SSOなど)のトラフィックは示されません。

ノート:

RUEIが監視しているトラフィックに関して正確にレポートするには、このトラフィック・サマリーを定期的に確認することを強くお薦めします。 必要であれば、RUEIの構成を確認して適切なものにしてください。 たとえば、他のCookieテクノロジを追加します。 また、システムでセッションを追跡できない場合は、ユーザー・フローも適切に追跡できません(ユーザー・フロー・レポートではセッションの追跡が必要になるため)。

セッション・トラッキング・メカニズムの指定

RUEIでユーザーのWeb環境を正確に監視するには、RUEIがユーザーのWebサイトで使用しているcookieテクノロジまたはその他のセッション・トラッキング・メカニズムを把握している必要があります。 Cookieテクノロジは標準的なテクノロジ(ASPやColdFusionなど)かカスタム実装のいずれかになります。 カスタム実装の場合には、関連する情報をシステムに提供する必要があります。

Cookieテクノロジは、特定のアプリケーションおよびスイートの他、グローバル・セッション・トラッキングにも指定できます。 アプリケーション固有のセッション・トラッキング定義は、グローバル・セッション・トラッキングの設定よりも優先されることに注意してください。 監視に使用するアプリケーション固有のCookieテクノロジおよびグローバルCookieテクノロジはそれぞれ最大9個まで定義できます。

アプリケーション固有のCookieテクノロジの指定

次を実行します。

  1. 「構成」、「アプリケーション」または「スイート」の順に選択し、必要なアプリケーションを選択します。 「アプリケーション概要」が表示されます。 「拡張」タブ→「セッション・トラッキング」タブの順にクリックします。

  2. 新規セッション・トラッキング・メカニズムの追加または既存の定義をクリックします。 図12-3に示すようなダイアログが表示されます。

    図12-3 「セッション・トラッキング・スキームの追加」ダイアログ

    図12-3の説明が続きます
    「図12-3 「セッション・トラッキング・スキームの追加」ダイアログ」の説明

  3. Web環境で使用しているCookieテクノロジを「スキーム・タイプ」メニューから選択します。 非標準テクノロジを使用している場合は、(カスタム)を選択し、組織で使用しているCookieの名前を指定します。 ワイルドカード文字(*)をCookie名の一部として指定できます。 Cookie名では大文字と小文字が区別されることに注意してください。

    「XPath(カスタム)」オプションは、リクエストまたはレスポンスに適用されたXPath式に基づくセッション・トラッキングであることを指定します。 XPath式の使用方法の詳細は、「XPath問合せの操作」を参照してください。 「ヘッダー(カスタム)」オプションは、指定されたリクエストまたはレスポンスに基づくセッション・トラッキングであることを示します。

    (URL引数)を選択した場合は、組織で使用しているURL引数の名前を指定する必要があります。 セッション・トラッキングでのURL引数の使用方法は、「Cookie構造」で説明しています。

    次に、「保存」をクリックします。 変更は、少しの間隔(通常5分から10分)を置いて適用され、さらにその少し後にレポータ・システムに表示されます。

グローバル・セッション・トラッキング・メカニズムの指定

次を実行します。

  1. 「構成」→「アプリケーション」→「グローバル・セッション・トラッキング」の順に選択します。 このオプションを使用できるのは管理者のみです。 現在定義されているグローバル設定が表示されます。 例を「図12-4」に示します。

    図12-4 「グローバル・セッション・トラッキング」ウィンドウ

    図12-4の説明が続きます
    「図12-4 「グローバル・セッション・トラッキング」ウィンドウ」の説明
  2. 「常にアプリケーション固有のセッションを使用」のオプションを選択します。 選択したセッションが常にアプリケーション固有として処理される場合。 2つのヒットが異なるアプリケーションとして識別された場合、それらが同じセッションに含まれることはありません。 選択を解除すると、構成済のアプリケーション固有クッキーに一致がある場合にのみ、セッションはアプリケーション固有として処理されます。
  3. 「セッション・トラッキング・スキームの追加」または既存の定義をクリックします。 手順は、前述の手順と同じです。
  4. 「セッション・トラッキング・フォールバック」設定の使用方法については、「代替セッション・トラッキング・メカニズムの指定」で説明します。

例12-1 複数の構成されたCookie

複数の構成されたCookieが同じヒットで検出されると、RUEIは、複数のCookie値を持つすべてのヒットを単一のユーザー・セッションにマージします。 たとえば、3つのヒットが次のCookie値を持つ状況を考えてみます。 

hit1: CookieA=123;
hit2: CookieB=321;CookieA=123;
hit3: CookieB=321;

この場合、すべての3つのヒットは、同じユーザー・セッションに属するとみなされます。

例12-2 重要

同一セッションで複数のアプリケーションがレポートされるようにする場合を除いて、アプリケーション固有ベースでCookie定義を構成することをお薦めします。

JavaScript Cookie生成の実装

前述のように、セッションの追跡はCookieに基づいて実行できます。 ただし、Cookieが適していない状況または使用できない状況があります。 たとえば、次の状況について考えてみます。

  • Cookieがヒットごとに変化する場合(たとえば、ObSSOCookieのケース)。

  • Cookieに設定されているパスがアプリケーションの一部にしか対応しない場合。

  • Webサーバーで構成されているプライバシ・ポリシーのためにCookieの使用が無効な場合。

セッションの追跡のために適切なCookieがない場合は、JavaScriptを使用してクライアント側のCookieメカニズムを実装することをお薦めします。

クライアント側のCookieメカニズムの構成

クライアント側cookieメカニズムを構成する手順は、次のとおりです:

  1. 該当するログイン・ページに次のようなコードを追加します。

    <SCRIPT 
LANGUAGE="JavaScript">if(document.cookie.indexOf('track=')==-1){document.cookie
='track='+parseInt(Math.random()*2147418112)+new 
Date().getTime()+';path=/;domain='+document.location.host.substring( 
document.location.host.lastIndexOf('.',  
document.location.host.lastIndexOf('.') - 1)) ;}</SCRIPT>

    前述のコードは情報提供のみを目的としています。 特定の要件に応じて変更が必要になる場合があります。

  2. 「構成」、「アプリケーション」、「セッション・トラッキング」の順に選択します。 「新規Cookieの追加」をクリックします。 図12-5に示すダイアログが表示されます。

    図12-5 「セッション・トラッキング・スキームの追加」ダイアログ

    図12-5の説明が続きます
    「図12-5 「セッション・トラッキング・スキームの追加」ダイアログ」の説明

  3. Cookieテクノロジ(カスタム)を「スキーム・タイプ」メニューから選択し、適切なCookie名を指定します。 前のJavaScriptコードではCookie名はtrackです。 これはログイン・ページのJavaScriptコードに指定した名前と一致する必要があります。使用できるのは英数字のみです。 また、ヘッダー・サイズを最小限にするためにCookie名は10文字以下にすることをお薦めします。 次に、「保存」をクリックします。

Cookieの構成の確認

Cookie構成が正しく追跡されることを確認する手順は、次のとおりです。

  1. ブラウザですべてのCookieをクリアします。
  2. 監視対象のアプリケーションに(再)ログインします。
  3. いくつかのページ表示を実行します。
  4. 監視対象のアプリケーションからログアウトします。
  5. 少なくとも10分間待機します。
  6. RUEIレポータ環境を開き、「データの参照」を選択し、「すべてのセッション」グループを開いて「セッション診断」を選択します。記録されたセッション(ユーザーID別または時間別)を探します。 アプリケーションについてフィルタリングできます。
  7. セッションを開き、ログイン・ページ以外にページ・ビューがあることを確認します。 これで、セッションIDがログイン後に保存されていることが確認されます。

代替セッション・トラッキング・メカニズムの指定

Cookieテクノロジを指定しない場合は、クライアント・ネットワークとクライアント・ブラウザの組合せを使用してセッションを追跡します(デフォルト)。 ただし、この方法が環境に適していない場合は、代替追跡メカニズムとしてクライアントIPアドレスを使用できます。

代替セッション・トラッキング・メカニズムを指定する手順は、次のとおりです。

  1. 「構成」、「アプリケーション」、「セッション・トラッキング」の順に選択します。 現時点で定義されているCookieの設定が表示されます。 現時点で定義されているセッション・トラッキングの代替メカニズムをクリックします。 「図12-6」に示すダイアログが表示されます。

    図12-6 セッション・トラッキング・フォールバックの設定ダイアログ

    図12-6の説明が続きます
    「図12-6 セッション・トラッキング・フォールバックの設定ダイアログ」の説明
  2. 「トラッキング・メカニズム」メニューを使用して、クライアント・ネットワークとブラウザの組合せを使用する(デフォルト)かクライアントIPアドレスを使用するかを指定します。

    次に、「保存」をクリックします。 行った変更は、即座に有効になります。

例12-3 どちらの代替セッション・トラッキング・メカニズムを選択するか

どちらの代替メカニズムを使用するかを検討するとき、外部用アプリケーションではデフォルトのネットワークとブラウザの組合せを使用し、内部用アプリケーションではクライアントIPアドレスを使用するのが原則です。 同じプロキシ・サーバーで複数のユーザーが存在する場合は、デフォルトの代替メカニズムの使用をお薦めします。 ただし、この場合は、すべてのユーザーが1つのセッションに記録されることに注意してください。 通常、次の状況ではクライアントIPアドレス・メカニズムの使用をお薦めします。

  • すべてのユーザーに一意のIPアドレスがある場合。 アプリケーションごとに、クライアントIPアドレスをTCPパケットから取得するか、特定のHTTPリクエスト・ヘッダーから取得するかを指定できることに注意してください。 これについては、「NATed Trafficのモニタリング」で説明しています。

  • 組織で定められたブラウザが使用されている場合。 つまり、標準のバージョンおよびプラグインの標準ブラウザ(Internet ExplorerまたはMozilla Firefoxなど)。

  • 管理対象のアプリケーションの一部(またはすべて)が部分的にJavaで実装されている場合。 Oracle E-Business Suite(EBS)は、このようなアプリケーション・アーキテクチャの例です。 このようなアプリケーションでは、クライアントIPアドレス・メカニズムの使用により、Javaとクライアント・リクエストの両方が同じレポート・セッションに表示されないようになります。

ノート:

Webサイト内で使用されるcookieテクノロジの正確な仕様は、ネットワーク・トラフィックを正確にレポートするために、「強く」をお薦めします。

また、ビジター・セッションの追跡に指定するCookieがブラインディングされないようにしてください。 ブラインディングが行われると、Cookieに基づくセッション作成が失敗します。

名前付きWebサーバー・グループの定義

名前付きサーバー機能を使用すると、監視対象のWebサイト内でのサーバーの使用状況をより詳細に洞察できます。 この機能を使用すると、サーバーIPアドレスの範囲を1つのWebサーバー・グループおよび個別のWebサーバーに割り当てることが可能です。 たとえば、サーバー・グループとして部門またはデータ・センターを使用し、そのグループに属する特定のWebサーバー名をサーバー名として指定できます。 これにより、問題(ページの失敗など)が発生したときに、該当するWebサーバーの場所を簡単に特定できます。 名前付きサーバー機能を使用できるのは、完全なITユーザー・アクセスを持つユーザーのみです(表14-2を参照)。

サーバー情報の表示

監視中に収集したWebサーバー情報は、データ・ブラウザで、全ページ、キー・ページ、全機能、失敗した機能グループ、失敗したURL、失敗したページおよび遅いURLグループの各項目別に表示できます。 サーバーのIPには指定したIPアドレスが表示され、サーバー・グループにはグループ名が表示されます。 サーバー・グループにズーム・インすると、そのグループを構成する個々のWebサーバー名を表示できます。 さらにズーム・インすると、そのWebサーバーに割り当てられた単一のIPアドレスを表示できます。

名前付きサーバーIDのソース

名前付きサーバーをレポートするとき、デフォルトではサーバーのIPアドレスはIPパケットからフェッチされます。 しかし、WebサーバーがNATデバイスの前面に配置されている場合は、特定のHTTPヘッダーやCookieなどからIPアドレスが取得される方が便利なこともあります。 そのため、IPアドレスを取得するソースを階層として指定することができます。 グループおよびサーバー名には、類似のソース・スキームを指定することもできます。 これらのスキームから値が生成されないときに使用する代替識別情報も定義できます。

名前付きサーバーIDソースの定義

Webサーバーを識別およびレポートする方法を定義するには、次の手順を実行します。

  1. 「構成」→「一般」→「指定サーバー」の順に選択します。 次のいずれかのオプションを選択します。

    • IPアドレス・ソース: このオプションを使用して、サーバーのIPアドレスを取得するソースを指定します。

    • 名前付きソース: このオプションを使用して、サーバー名を取得するソースを指定します。

    • グループ・ソース: このオプションを使用して、サーバーのグループ名を取得するソースを指定します。

    • 識別代替: このオプションを使用して、定義されたソースから取得できない場合にサーバーIDに使用するIPアドレス範囲、グループおよび名前を指定します。 このオプションの使用方法は、「代替セッション・トラッキング・メカニズムの指定」で説明しています。

  2. 「新規ソースの追加」をクリックします。 図12-7に示すようなダイアログが表示されます。

    図12-7 「サーバーIPアドレス・ソースの追加」ダイアログ

    図12-7の説明が続きます
    「図12-7 「サーバーIPアドレス・ソースの追加」ダイアログ」の説明
  3. 「ソース・タイプ」と「ソース値」のフィールドを使用して、選択した項目に使用する識別スキームを指定します。 表12-1に、使用可能なオプションを示します。 次に、「保存」をクリックします。

    表12-1 識別オプション

    オプション 説明

    リクエストのヘッダー

    識別アイテムは、指定したリクエスト・ヘッダーから取得する必要があります。

    レスポンスのヘッダー

    識別アイテムは、指定したレスポンス・ヘッダーから取得する必要があります。

    Cookie

    識別アイテムは、指定したCookie要素から取得する必要があります。

    SSLクライアント証明書名

    識別アイテムは、SSLクライアント証明書から取得する必要があります。 このオプションは、IPアドレスに対して使用できません。

    リテラル値

    識別アイテムのリテラル値を指定します。 このオプションは、IPアドレスに対して使用できません。

  4. ルーリング機能を作成すると、それを使用して、新規作成する定義を調整する追加の一致ルールを指定できます。 これについては、「規則指定機能の使用方法」で説明しています。
  5. サーバーの識別情報として定義されるソースは、リストに出現する順序で評価される点に注意してください。 必要な場合は、項目のコンテキスト・メニューで「上に移動」と「下に移動」のオプションを使用して、リストでの位置を変更できます。

サーバー識別の代替方法の定義

指定されたソースからサーバーの情報を取得できない場合に使用する、サーバー識別方法を定義することができます。 これをサーバー識別代替と言います。 識別の代替方法を定義するには、次の手順を実行します。

  1. 「構成」、「一般」、「指定サーバー」、「識別代替」の順に選択します。 「新規サーバーの追加」をクリックします。 「図12-8」に示すダイアログが表示されます。

    図12-8 「名前付きサーバー代替識別の追加」ダイアログ

    図12-8の説明が続きます
    「図12-8 「名前付きサーバー代替識別の追加」ダイアログ」の説明
  2. ネットマスクで限定した一連のIPアドレス(または特定のIPアドレス)および関連するWebサーバーとグループ名を指定します。 次に、「保存」をクリックします。

ノート:

指定するIPアドレス/ CIDRプレフィクスの長さの組合せは一意である必要があります。 プレフィクスが0と等しいCIDRは、受け入れられません。 また、ネットマスクだけ異なる重複したIPアドレスを指定した場合、レポートの目的には固有性の高い方が使用されます。

例12-4 代替識別のリストのアップロード

オプションで、「アップロード」をクリックして、現在定義されている代替識別情報に代替識別情報定義のリストをマージできます。 リストのファイルでは1行が1エントリである必要があり、各サーバーに関する情報(図12-8のように表示される情報)はタブで区切っておく必要があります。 マージしたファイル内にすでに定義されているサーバー識別情報の定義がある場合には、その既存の定義が上書きされます。

名前付きクライアント・グループの定義

ビジターのIPアドレスに関連する情報の拡張が必要な場合もあります。 イントラネットのトラフィックを監視しているときに、ユーザー独自のクライアント分類を使用する必要がある場合に、これは特に便利です。

この機能を使用する手順は、次のとおりです。

  1. 「構成」→「一般」→「指定クライアント」の順に選択します。 現時点で定義されている名前付きサーバーがリストされます。 「追加」をクリックします。 このオプションを使用できるのは、ITの完全なアクセス権限を持つユーザーのみです。 「図12-9」に示すダイアログが表示されます。

    図12-9 「名前付きクライアントの追加」ダイアログ

    図12-9の説明が続きます
    「図12-9 「名前付きクライアントの追加」ダイアログ」の説明
  2. ダイアログ内のフィールドを使用して、IPv4アドレスの範囲、IPv6アドレス、ネットマスク内の特定アドレス、クライアント、および関連するグループ(会社の部門など)を指定します。 次に、「保存」をクリックします。

例12-5 重要

指定したIPアドレスの組合せは一意である必要があります。 また、ネットマスクだけ異なる重複したIPアドレスを指定した場合、レポートの目的には固有性の高い方が使用されます。

名前付きクライアントのリストのアップロード

オプションで、「アップロード」をクリックして、現在定義されている名前付きクライアントのリストをマージできます。 リストのファイルでは1行が1エントリである必要があり、各クライアントに関する情報(図12-9のように表示される情報)はタブで区切っておく必要があります。 マージしたファイル内にすでに定義されている名前付きクライアントの定義がある場合は、その既存の定義が上書きされます。

定義を変更した名前付きクライアント・グループは、少しの間隔(通常5分から10分)を置いて適用され、さらにその少し後にレポータ・システムに表示されます。

名前付きクライアント・グループ情報の表示

ビジターの情報は、データ・ブラウザの名前付きクライアント・ビューで、失敗したURL、失敗したページ、キー・ページ、遅いURL、全セッション、全機能および失敗した機能グループの各項目別に表示できます。

遅いURLおよび関数コールのレポートの制御

URLsが遅い関数および遅い関数データ・グループ。「表3-6」レポートでは、関数コールのエンド・ツー・エンド時間に基づいて、システムによって検出された5分間ごとに最も遅い5000オブジェクトについて説明します。 デフォルトでは、オブジェクトおよび関数コールは、それぞれのビューでレポートされる、少なくとも2000ミリ秒のエンド・ツー・エンド時間を持つ必要があります。 ただし、このしきい値は、レポート要件に合うように変更できます。

遅いレポートしきい値の変更

次を実行します。

  1. 「構成」、「一般」、「詳細設定」、「URLの処理」、「遅いURLおよび関数コールのしきい値」の順に選択します。 「図12-10」に示すダイアログが表示されます。

    図12-10 「遅いURLおよび関数コールのしきい値の編集」ダイアログ・ボックス

    図12-10の説明が続きます
    「図12-10 「遅いURLおよび関数コールのしきい値の編集」ダイアログ・ボックス」の説明
  2. オブジェクトまたは関数コールが遅いと判断されるまでに必要なエンドツーエンド時間(ミリ秒単位)を指定します。 次に、「保存」をクリックします。

失敗したURLヒットの無視

ヒットの失敗は、失敗したURLグループの中に記録されます。 ヒットの失敗は広範な理由で発生し得るため、どのようなヒットの失敗を記録するのかを設定しておく必要があります。 たとえば、リモート・ロボット検索に関連したインシデントの記録が必要になることはほぼありません。 次を実行します。

  1. 「構成」、「一般」、「詳細設定」、「URLの処理」、「失敗したURLの無視」の順に選択します。 このオプションを使用できるのは管理者のみです。 「図12-11」に示すダイアログが表示されます。

    図12-11 「失敗したURLの無視」ダイアログ

    図12-11の説明が続きます
    「図12-11 「失敗したURLの無視」ダイアログ」の説明
  2. 失敗したURLビュー内で無視する必要のあるファイル名を指定します。 つまり、これらがエラーとして表示されないようにします。 ファイル名定義内のディレクトリ情報は無視され、定義されているファイルはリストされたオブジェクトURLsからも削除されます。 無視する必要のあるファイル名を新たに定義するには、「追加」をクリックします。 また、定義されたファイルの右側にある「削除」 アイコンをクリックすると、無視するファイルのリストからそれが削除されます。

    インストール時に、2つのデフォルト・ファイル(robots.txtおよびfavicon.ico)が自動的に構成されます。 次に、「保存」をクリックします。 この設定への変更は10分後に適用されます。 この少し後に、指定した変更がレポータ・インタフェースに表示されます。

ページURLディメンションにおける引数のフィルタリング

最低レベルのページURLディメンションに、URL引数をすべて記録するか、一部を記録するか、または記録しないかを設定できます。 次を実行します。

  1. 「構成」→「一般」→「詳細設定」→ページURL処理→「ページURL引数のフィルタ」の順に選択します。 このオプションを使用できるのは管理者のみです。 「図12-12」に示すダイアログが表示されます。

    図12-12 ページURL引数のフィルタ

    図12-12の説明が続きます
    「図12-12 ページURL引数のフィルタ」の説明
  2. 「引数フィルタ」メニューを使用して適切なフィルタを選択します。 デフォルトはすべて許可です。 つまり、引数がすべて記録されます。 準備ができたら、「次へ」をクリックします。
  3. 「一部を許可」フィルタを選択した場合は、続くダイアログで、どの引数を記録するかを指定する必要があります。 複数ある引数はアンパサンド(&)記号で区切ります。 準備ができたら、「次へ」をクリックします。

新しい設定は10分後に適用されます。 その少し後に、指定した変更がレポータ・インタフェースに表示されます。

ノート:

ユーザーのページURLにセッション引数またはその他任意の引数が含まれる場合は、この機能を使用することをお薦めします。 この機能を使用しない場合は、ページベース・ビュー(全ページまたは失敗したURLなど)の内容が非常に大きくなることがあります。

セッション・レポートの制御

RUEIでは、セッション情報は「すべてのセッション」グループ内でレポートされます。 この機能では、ビジターのセッションに関する情報はセッション開始後約5分で表示されます。 デフォルトでは、ビジターが活動しない時間が、定義されたセッション・アイドル時間(デフォルトは60分)を超えた場合に、ビジター・セッションが終了したとみなされます。

セッションのレポートを最適化するために、「セッション・アイドル時間」の詳細設定を使用して、ビジターのセッションが終了したとみなされる非アクティブな期間(分)を指定します。 デフォルトは60分です。

ノート:

この設定は、インストールのパフォーマンスおよびレポートされるデータの精度に影響を与える可能性があるため、変更はカスタマ・サポートのアドバイスを受けた場合にのみ行うことを強くお薦めします。

セッション設定の指定

セッションをレポートするときに使用するアイドル時間を指定する手順は、次のとおりです。

  1. 「構成」→「一般」→「詳細設定」→「セッション処理」→「セッション・アイドル時間」の順に選択します。 「図12-13」に示すダイアログが表示されます。

    図12-13 セッション・レポートの変更ダイアログ

    図12-13の説明が続きます
    「図12-13 セッション・レポートの変更ダイアログ」の説明
  2. ビジターが非アクティブになってからセッションが終了したとみなされるまでの時間(分)を指定します。 デフォルトは60分です。 次に、「保存」をクリックします。

この設定は、変更すると、5分以内に有効になります。

RUEI内でのルール順序設定の制御

デフォルトでは、RUEI内でアプリケーション、SSO、プロファイル、スイートおよびサービスの各フィルタで一致が行われる順序は、定義に指定されている詳細のレベルによって決まります。 つまり、最も多くの情報が指定されている定義が最初に適用されます。 ただし、フィルタの適用順序の変更が必要になる場合があります。

たとえば、ドメインshop.oracle.comのネットワーク・トラフィックを監視するとします。 また、2つのアプリケーション(ドメインshop*用に1つおよびドメイン*oracle*用に1つ)を定義しておきます。 文字列*oracle*は、文字列shop*より長いため、最初に適用されます。 ただし、ドメインshop*のページIDを優先する必要があるとします。 ルール順序設定機能を使用すると、デフォルトのルール一致順序を、必要なドメインのページを適用する順序で上書きできます。

ノート:

デフォルトのルール順序設定を使用すること、およびアプリケーション、SSOプロファイル、スイートおよびサービスが相互排他的になるように十分な情報を使用してそれぞれを定義することをお薦めします。

ルール順序設定機能を使用する手順は、次のとおりです。

  1. 「構成」タブをクリックし、「構成」メニュー・オプションを選択してから「ルーリング順序の編集」オプションを選択します。 このオプションを使用できるのは、ITユーザーで「完全」アクセス権限を持つユーザーのみであることに注意してください。 「図12-14」に示すダイアログが表示されます。

    図12-14 ルール順序設定の編集


    図12-14の説明が続きます
    「図12-14 ルール順序設定の編集」の説明

  2. 「自動ルール順序」チェック・ボックスを使用して、現在定義されているアプリケーション、SSO、プロファイル、スイートおよびサービスからルール順序設定を自動的に導出するかどうかを指定します。 前述のように、デフォルトでは、最も多くの情報が指定されている定義が最初に適用されます。 順序コントロールを使用してルールの適用順序を指定すると、このチェック・ボックスの選択が自動的に解除されます。 このチェック・ボックスを再び選択すると、フィルタ順序設定が自動的にデフォルトにリセットされます。

    順序を変更するには、「順序」列の上/下アイコンをクリックし、ポップアップ画面で必要な「新規優先度順」を指定します。

    行った変更は即座に有効になります。 次に、「閉じる」をクリックします。

    ノート:

    デフォルトのルール順序設定を変更してから、新規のアプリケーション、SSOプロファイル、スイートまたはサービスを定義すると、関連付けられているフィルタが現在のルール順序設定の最下部に即座に配置されます。 このため、新規フィルタの作成後には必ずルール順序設定を確認してください。

データ保存ポリシーの指定

RUEIレポートの詳細レベルは、測定されたトラフィックの量と使用可能なディスク領域の量に応じて異なります。 大規模なトラフィックの量を処理するため、データは、特定のレポート目的用にデータ型(「すべてのページ」、「すべてのセッション」および「遅いURL」)に加工され、時間の経過とともにデータ型ごとに集計されます。

時間ベースの集計メソッドは、データ集計と呼ばれます。 次のデータ集計レベルを使用できます。

  • インスタンス: (デフォルトは8日)

  • 5分: (デフォルトは15日)

  • 毎時間: (デフォルトは32日)

  • 日次: (デフォルトは90日)

  • 月次: (デフォルトは60か月)

データ保存では、使用可能なディスク領域の量と、時間の経過に伴って使用できるレポートの詳細レベルとの間のバランスが問題になります。 たとえば、アプリケーションで8から40日間の「インスタンス」データ集計を設定すると、高レベルなアプリケーション詳細をレポートで使用できます(ただし、多くのディスク領域が犠牲になります)。 また、60から90か月の「月次」集計を設定すると、(詳細度の低い)傾向レポートが可能になりますが、相当なディスク領域が犠牲になります。

レポート・データの保存ポリシーの詳細設定画面は、「設定」と「DB使用率」の2つのタブで構成されています。 「設定」タブを図12-15に示します。

図12-15 「設定」タブ


「設定」タブ

ポリシーはデータ型グループごとに、および各データ型の詳細レベルの+記号をクリックして指定できます。 データ集計レベルはデータ型グループまたはデータ型ごとに構成できます。 「データ保存」ダイアログ(図12-16)を開くには、「設定」タブ内の数字をクリックします。

図12-16 ポリシーの指定


「詳細」タブを使用したポリシーの指定

「設定」タブでは、各データベースの最大データベース・サイズを指定できます。 スタンドアロン設定では構成できるデータベースは1つのみです。 スケールアップ設定(複数の処理ノードを持つレポータ)の場合は、データベースごとに最大サイズを指定できます。 「最大データベース・サイズ(GB)」をクリックすると、図12-17のようなダイアログが表示されます。

図12-17 データベース・サイズの指定


データベース・サイズの指定

「DB使用率」タブには、現在および予測されるディスク使用量がデータベース(レポート対象のデータベースまたは処理ノード上のデータベース)ごとに表示されます。 「システム」ドロップダウンを使用してノードを選択し、「ビュー」ドロップダウンで現在と予測のデータベース使用率を切り替えます。 円グラフから表に切り替えるには、表アイコンをクリックします(図12-18)。

図12-18 「DB使用率」タブ


「DB使用率」タブ

新規のデプロイメントの場合は特に、現在および予測されるデータベース使用率を定期的に確認することをお薦めします。 測定データが多ければ多いほど、予測の精度も高くなります。 新しいアプリケーションの追加や既存アプリケーションの変更などによってRUEIの構成が変更された場合は、データベース使用率への影響を監視するように注意する必要があります。

レポータの保存ポリシーの定義

セッション診断の保存期間を長くする場合は、十分な履歴が「すべてのセッション」で5分間レベルでも使用できることを確認してください。

この手順では、レポータの保存ポリシーを定義する方法について説明します。

ノート:

次の設定では、現在のデータのレポータ・データ保存ポリシーを構成するだけでなく、リプレイ・ストアに対する時間ベースのコレクタ・データ保存ポリシーも制御します。

  • 「セッション診断(日)」は、「フル・セッション・リプレイ・ストア」に対する時間ベースの保存も制御します。

  • 「アプリケーション/失敗したURLの設定(日)」または「アプリケーション/失敗したページの設定(日)」は、「エラー・ページ・リプレイ・ストア」に対する時間ベースの保存も制御します。

たとえば、「セッション診断(日)」が8日間に設定されている場合、セッション診断データには最大8日分のセッションと、最大8日分のフル・セッション・リプレイ・データが含まれます。

コレクタのデータ保持ポリシーの詳細は、「コレクタのデータ保存ポリシーの定義」を参照してください。

レポータ・システムで使用するデータ保存ポリシーを指定する手順は、次のとおりです。

  1. 「構成」→「一般」→「詳細設定」→「レポータ・データ保持ポリシー」の順に選択します。 図12-19に示すような画面が表示されます。

    図12-19 レポータのデータ保存ポリシー・パネル


    データ保存ポリシー

  2. 目的の設定を選択します。

    図12-20に示すようなダイアログが表示されます。

    図12-20 データ保存の変更


    データ保存の変更

  3. このダイアログのコントロールを使用して、選択したオプションの保存ポリシーを指定します。

    推定されるデータベース使用率(監視対象トラフィックのレベルに基づく)が示されます。 ディスク領域使用率の情報は、個別設定のダイアログ・ボックスに表示されます。 これらの見積もりは、デプロイされた処理システム内の最も高い使用状況に基づいています。 たとえば、レポータ内の使用状況が50%および処理エンジン内の使用状況が20%の項目の場合、高い値を使用して使用状況および可用性をレポートします。

    ほとんどの設定では、「計算」をクリックすることで、データベース使用率とディスク領域使用率のうち、該当する方に対するユーザーの選択の影響を表示できます。

    次に、「保存」をクリックします。 ディスク領域割当ての変更は約10分後に有効になりますが、データベース割当ての変更は午前0時以降にのみ有効になります。

  4. オプションで、項目に現在使用されている合計データベース領域(GB単位)およびデータベースの許可される最大サイズを表す比率の説明には、「DB使用率」タブをクリックします。 例を「図12-21」に示します。

    図12-21 データベース使用状況の説明


    データベース使用率の説明

ノート:

保持されるデータの量を増やすには、まず下位レベルのデータ保存設定、次に上位レベルのデータ保存設定を変更することをお薦めします。 保持されるデータの量を減らす場合は、まず上位レベルのデータ保存設定、次に下位レベルのデータ保存設定を変更します。

例12-6 必要な月の計算

月次設定の最小値は、指定した日数をカバーするために必要な最大月数を計算することで決定されます。 たとえば、90日を指定すると、月次設定の最小値は4になります(2月、3月、4月を組み合せても89日しかカバーされないため)。 これに対し、3か月を指定すると、日次設定の最大値は89になります。

コレクタのデータ保持ポリシーの構成については、「コレクタのデータ保存ポリシーの定義」を参照してください。

最新期間のレポートの制御

デフォルトでは、最新の(未完了)期間の情報は、選択されている期間の現時点の分までが常に表示されます。 グラフではこの部分は点線で表示されます。 例を図12-22に示します。

図12-22 未完了期間のレポートの例


図12-22の説明が続きます
「図12-22 未完了期間のレポートの例」の説明

未完了期間のレポート時期の指定

未完了の期間をいつレポートするかを指定する手順は、次のとおりです。

  1. 「構成」→「一般」→「詳細設定」→「データの視覚化」→「現在の期間のレポート」を順に選択します。 「図12-23」に示すダイアログが表示されます。

    図12-23 「現在の期間のレポート」ダイアログ


    図12-23の説明が続きます
    「図12-23 「現在の期間のレポート」ダイアログ」の説明

  2. 最新期間をレポートするときに使用する視覚表現を選択します。 表12-2に示すオプションがあります。

    表12-2 「Visualization」のオプション

    オプション 説明

    有効

    すべての未完了期間をすべてのグラフでレポートすることを指定します。値リスト、レポートおよびエクスポートにも含めます。 これはデフォルトです。

    無効

    未完了期間はレポートしないように指定します。

    指定されている

    未完了期間は特定の視覚表現のみでレポートすることを指定します。 値リスト・オプションには、データ・ブラウザの値リストだけでなく、レポートとエクスポートも含まれます。

    次に、「保存」をクリックします。 この設定は、変更すると、即座に有効になります。

KPIおよびSLAレポート精度の指定

KPI値およびSLA値は一定レベルの精度でレポートされます。 デフォルトでは小数点以下2桁です。 ただし、これを変更してユーザーのレポート要件を反映できます。 次を実行します。

  1. 「構成」→「一般」→「詳細設定」→KPIおよびSLAのレポート精度の順に選択します。 レポートを変更するアイテムを選択します。 たとえば、「SLA成功」です。 図12-24に示すようなダイアログが表示されます。

    図12-24 レポート精度の編集ダイアログ

    図12-24の説明が続きます
    「図12-24 レポート精度の編集ダイアログ」の説明
  2. 選択したアイテムをレポートする場合の小数点以下の桁数を指定します。 次に、「保存」をクリックします。 これらの設定は変更すると即座に有効になります。

KPIしきい値プロファイルの定義

しきい値プロファイルは、KPIの自動ターゲットの評価時に使用するパラメータを指定します(「自動ターゲットおよび固定ターゲット」を参照)。

RUEIには、「システム・デフォルト」しきい値プロファイルが含まれています。 新規プロファイルを作成するかこのプロファイルを編集しますが、このプロファイルを削除しないことをお薦めします。

KPIしきい値プロファイルを定義するには:

  1. 「構成」→「一般」→「詳細設定」→「KPIしきい値プロファイル」を選択します。 変更するアイテムを選択するか、「追加」をクリックします。図12-25に示すようなダイアログが表示されます。

    図12-25 「KPIしきい値プロファイルの編集」ダイアログ

    KPIターゲット・プロファイル
  2. しきい値プロファイルの「名前」を指定します。
  3. 次のうちから「タイプ」を選択します。

    • 「連続」は、プロファイルに使用可能なすべての日のデータを使用します。

    • 「週の同日」は、プロファイルに使用可能な同じ曜日のデータを使用します。 たとえば、2つの使用可能な過去の月曜日のデータがある場合、そのデータを使用して月曜日の傾向を評価します。

    • 「週労働日数」では、週の労働日を指定可能で、傾向評価用に2つの日のグループを作成します。 たとえば、月曜日から金曜日のデータを月曜日から金曜日の傾向の評価に使用できます。 同様に、土曜日と日曜日のデータを週末の傾向の評価に使用できます。

  4. プロファイルに使用可能な「日」または「週」の数を指定します。 「連続」タイプのしきい値プロファイルを選択した場合は、傾向の評価に使用できるようにするデータの日数を指定します。 その他のしきい値プロファイルでは、使用可能にする必要があるデータの週の数を指定します。 この設定の最大日数または最大週数は、「レポータの保存ポリシーの定義」で説明されているレポータ・データの保存によって決まります。

    ノート:

    より多くのデータを使用できる場合は、傾向評価のほうが精度が高くなります。 「連続」タイプのしきい値プロファイルを選択して30日分のデータを提供する場合のほうが、「週の同日」タイプを選択して6週間分のデータを提供する場合(それぞれの日が照合され、月曜日など特定の曜日について6つの一致しか存在しない)よりも処理対象データが多くなります。

  5. しきい値プロファイルに「サンプリング・ウィンドウ(分)」を選択します。 これによって、データの変更に関連するターゲットのレスポンス時間が決まります。 たとえば、90分ウィンドウは現在の1分間の前後45分間を調べてターゲットの最小と最大を決定することを意味します。 ウィンドウの時間を長くすると、その期間にターゲットに影響を与える短期間のデータのバリエーションが少なくなる可能性があり、ウィンドウの値を小さくすると、自動ターゲットがより速く変動する可能性があることを意味します。
  6. しきい値プロファイルの「説明」を入力し、「保存」をクリックします。

ノート:

KPIによって使用されているしきい値プロファイルを削除することはできません。

システム全体にわたるプリファレンスの設定

「環境のカスタマイズ」で説明されているように、ユーザーは自分のセッションで使用される書式設定をカスタマイズできます。 小数点に使用する文字、3桁区切りに使用する文字、および使用する日付書式を指定できます。 管理者が、システム全体にわたるこれらの設定のデフォルト値を指定することもできます。それには、「システム」→「メンテナンス」→「書式設定プリファレンス」の順に選択します。

クライアントの場所のレポートの変更

RUEIによって報告されるクライアントの場所の情報は、IPアドレスとネットマスクの特定の組合せに関連付けられている地理上の場所が指定されている事前定義済の表から導出されます。

この表に保持されている情報がレポートの要件を満たさない場合(不十分または不適切)、レポートの際に使用される例外を定義することができます。 IPアドレスの場所の例外を定義するには、次の手順を実行します。

  1. 「構成」、「一般」、「IPアドレス・オリジン」の順に選択します。 このオプションを使用できるのは、ITの完全なアクセス権限を持つユーザーのみです。 現在定義されているIPアドレスの場所の例外がリストされます。 「追加」をクリックして新しい例外を定義するか、既存の例外をクリックして変更します。 「図12-26」に示すダイアログが表示されます。

    図12-26 「IPアドレス発信元の追加」ダイアログ

    図12-26の説明が続きます
    「図12-26 「IPアドレス発信元の追加」ダイアログ」の説明
  2. ダイアログ内のフィールドを使用して、定義済のIPv4またはIPv6アドレスのロケーションに対する例外を指定します。 次に、「保存」をクリックします。

例12-7 重要

指定したIPアドレスの組合せは一意である必要があります。 監視中のトラフィックのクライアントIPアドレスが複数のIPアドレス/ネットマスクの組合せに一致する場合は、レポートにはサブネットの範囲が最も小さい組合せが使用されます。

指定の場所のリストのアップロード

オプションで、「アップロード」をクリックすると、現在定義されているIPアドレスの場所の例外に、例外のリストをマージすることができます。 アップロードするファイルは、1行が1エントリである必要があり、情報のフィールドはタブで区切られている必要があります。 ファイルに、既存の例外に対する定義(つまりIPアドレス/ネットマスクの同じ組合せ)がある場合、既存の例外が上書きされます。 また、アップロードするファイルの各フィールドは、表12-3に示す要件を満たしている必要があります。

表12-3 アップロードしたファイルの要件

フィールド 要件

IPアドレス(CIDR表記)

有効なIP形式で、0と同じCIDRプレフィクス長は受け入れられません

国コード

ISO 3166-1による2文字の有効な国コード(「AL」など)。 サポートされている国コードの完全なリストは、次の場所にあります。 

https://en.wikipedia.org/wiki/ISO_3166-1

地域コード

これは、MaxMindデータベース(http://www.maxmind.com)でリージョンを識別するために使用されるコードである必要があります。 countrycode-regioncodeの形式です。 countrycodeは常に、国コードに指定されているのと同じ2-character ISO 3166-1コードです。 リージョン・コードでISO 3166-2の州/都道府県コードを指定する必要があります。 たとえば、"US-TX" (テキサス州)などです。 サポートされている地域コードの完全なリストは、次の場所からダウンロードできます。 

https://en.wikipedia.org/wiki/ISO_3166-2

市区町村名

このフィールドは、空白にすることはできませんが、それ以外の要件はありません。

ページとしてのオブジェクトのレポートの制御

RUEIでは、強制オブジェクトはページとしてではなく常にオブジェクトとして記録されます。 これは、レスポンス時間の長さや、レポートされるエラーに関係ありません。 強制オブジェクトに使用されるデフォルトのファイル拡張子は、表12-4のとおりです。

表12-4 デフォルトの強制オブジェクトのファイル拡張子

拡張 拡張 拡張 
.bmp
 
.class
 
.css

.dat

 
.doc
 
.gif
 
.ico
 
.jar
 
.jpeg
 
.jpg
 
.js
 
.mid
 
.mpeg
 
.mpg
 
.png
 
.ppt
 
.properties
 
.swf
 
.tif
 
.tiff
 
.xls

特定のファイル拡張子を持つオブジェクトを、強制オブジェクトとしてみなすかどうかを制御できます。 次を実行します。

  1. 「構成」、「一般」、「詳細設定」、「URLの処理」、「強制オブジェクト」の順に選択します。 「図12-27」に示すダイアログが表示されます。

    図12-27 「強制オブジェクト」ダイアログ

    図12-27の説明が続きます
    「図12-27 「強制オブジェクト」ダイアログ」の説明
  2. 強制オブジェクトとして扱うオブジェクトのファイル拡張子を指定します(ピリオドは不要)。 準備ができたら、「追加」をクリックします。 ファイル拡張子が、表示されているリストにただちに追加されます。 オブジェクトのファイル拡張子をリストから削除するには、リストのすぐ右にある「除去」アイコンをクリックします。 次に、「保存」をクリックします。

定義された強制オブジェクトのファイル拡張子のリストに対する変更は、ただちに有効になります。

ロボット・トラフィックのレポートの制御

ネットワーク・トラフィックをより効果的に監視するために、Webサイトへのトラフィックのどの程度がWebクローラ(スパイダやロボットなど)に関連付けられているかを把握することが必要な場合があります。 この場合、ロボットのユーザー・エージェントの元を識別するための一致内容を制御できます。 ロボット・トラフィックは、クライアント・ブラウザ・ディメンション経由で報告されます。 次を実行します。

  1. 「構成」→「一般」→「詳細設定」→「ロボット・トラフィック」の順に選択します。 現在定義されているロボット識別スキームが表示されます。 例を図12-28に示します。

    図12-28 「ロボット・トラフィック」画面

    図12-28の説明が続きます
    「図12-28 「ロボット・トラフィック」画面」の説明

  2. 「追加」をクリックします。 図12-29に示すダイアログが表示されます。

    図12-29 「ロボット識別情報の追加」ダイアログ

    図12-29の説明が続きます
    「図12-29 「ロボット識別情報の追加」ダイアログ」の説明

  3. トラフィックをロボット・トラフィックとしてレポートする必要のあるユーザー・エージェント名、および報告元にする名前を指定します。 各ユーザー・エージェントで、「追加」をクリックします。 次に、「保存」をクリックします。 図12-28に示す画面に戻ります。

  4. 「上に移動」および「下に移動」アイコンを使用して、リストの項目の順序を制御します。 ユーザー・エージェントは、一致した順序でリストに表示されます。

ロボット・トラフィック除外

ロボット・トラフィックの識別のみでなく、レポート・トラフィックからの除外も指定できます。 次を実行します。

  1. 「構成」→「一般」、「詳細設定」、「クライアントベースのトラフィック除外」の順に選択し、「ロボット・トラフィック除外」をクリックします。 「図12-30」に示すダイアログが表示されます。

    図12-30 ロボット・トラフィック除外

    図12-30の説明が続きます
    「図12-30 ロボット・トラフィック除外」の説明
  2. 「ロボット・トラフィックの除外」チェック・ボックスを使用して、前述の指定したユーザー・エージェントに一致するトラフィックをレポートするかどうかを指定します。 デフォルトではレポートされます。

データ・コレクションからのクライアント・トラフィックの除外

原則では、監視中のすべてのトラフィックがレポートされます。 ただし、特定のクライアントにより生成されたトラフィックを、収集から除外することができます。 これは、内部ユーザーから大量のトラフィックがレポートされている場合などに便利です。 さらに、「ロボット・トラフィックのレポートの制御」で説明するように、ロボット関連トラフィックのレポートを除外できます。

クライアント・トラフィックの収集を除外するには、次の手順を実行します。

  1. 「構成」→「一般」→「詳細設定」→クライアント・トラフィックの除外の順に選択します。 「クライアントIPアドレスの除外リスト」をクリックします。 「図12-31」に示すダイアログが表示されます。

    図12-31 「クライアントIPアドレスの除外リスト」ダイアログ

    図12-31の説明が続きます
    「図12-31 「クライアントIPアドレスの除外リスト」ダイアログ」の説明
  2. トラフィックを監視しないクライアントのIPアドレスを指定します。 CIDR形式で指定する必要があります。 各アドレスで、「追加」をクリックします。 次に、「保存」をクリックします。

    ノート:

    CIDR形式の詳細は、次の場所を参照してください。

    https://datatracker.ietf.org/doc/html/rfc4632
  3. または、リクエストされたページのヘッダー情報のコンテンツに基づいて、クライアント・トラフィックのレポートを除外することも可能です。 HTTPリクエスト・ヘッダーの除外リストをクリックします。 図12-32に示すダイアログが表示されます。

    図12-32 「HTTPリクエスト・ヘッダーの除外リスト」ダイアログ

    図12-32の説明が続きます
    「図12-32 「HTTPリクエスト・ヘッダーの除外リスト」ダイアログ」の説明
  4. リストに追加するヘッダーの名前=値ペアを指定します。 それぞれのペアで、「追加」をクリックします。 次に、「保存」をクリックします。

ページ・ダウンロードおよびブラウザ時間レポートの最適化

リクエストしたページがブラウザ内でユーザーに提供されるまでの時間は、次のとおりです。

  • ページ・ダウンロード時間は、配信される最初のページ・オブジェクト(通常はページ・リクエスト)から最後のページ・オブジェクトまでの経過時間です。

  • ページ・ブラウザ時間は、最後のページ・オブジェクトが配信されてから、クライアント側のインストゥルメンテーションによりレポートされたページ・ブラウザの完了時間までの経過時間です。 クライアント側のインストゥルメンテーションは、ブラウザJSライブラリにより定義されます(「ブラウザJSライブラリ設定の定義」を参照)。

    この期間は、WebページにJavaScriptコードが大量または複雑に含まれている場合や、Flashなどのブラウザ・プラグインが実行されている場合には非常に長くなることがあります。 すべての主要なブラウザでは、ページの可用性はonLoadイベントの実行によって示されます。 図12-33を参照してください。

ナビゲーション・タイミングが有効になっている場合、次のナビゲーション・タイミングが使用可能です。

  • ページ・ブラウザ・インタラクティブ時間: これは、ユーザーがページのアイテムをクリックできる(ページがインタラクティブになる)までの時間です。

ナビゲーション・タイミングの例は、図4-4を参照してください。

図12-33 ページ・ダウンロードおよびブラウザ時間のレポート


図12-33の説明が続きます
「図12-33 ページ・ダウンロードおよびブラウザ時間のレポート」の説明

ページ・ダウンロードおよびブラウザ時間の表示

ページ・ダウンロード、ブラウザ時間およびブラウザ・インタラクティブ時間に関する情報は、ページ・ロード時間のブレークダウン・ビューに表示されます。 例を図12-34に示します。

図12-34 ページのロード時間ブレークダウン・ビュー


図12-34の説明が続きます
「図12-34 ページのロード時間ブレークダウン・ビュー」の説明

ブラウザJSライブラリの定義については、「ブラウザJSライブラリ設定の定義」で説明します。