| Oracle® Real User Experience Insightユーザーズ・ガイド リリース11.1 for Linux x86-64 B63041-01 |
|
 前へ |
 次へ |
この章では、監視対象トラフィックのレポートを情報要件に合うように最適化する方法について説明します。また、ネットワーク環境で使用するCookieテクノロジの仕様、名前付きWebサーバーとクライアント・グループの使用方法、および様々な高度な機能(ルール順序設定やデータ保存ポリシーなど)についても説明します。
監視対象のネットワーク・トラフィックの概要を開くには、「System」→「Status」→「Data processing」の順に選択します。これにより、ヒット、ページ、セッション処理およびシステム・ロードに関する情報が即座に表示されます。例を図12-1に示します。
「Performance」タブの「Available resource usage (%)」項目は、現在の処理レベルを示します。この値が100%に近づくと、データの処理に遅延が発生し始め、データをリアルタイムで処理できなくなります。
この機能はアプリケーション・ロジックに基づいているため、表示されるレポートには非アプリケーション(スイート、サービス、SSOなど)のトラフィックは示されません。
|
重要: RUEIが監視しているトラフィックに関して正確にレポートするには、このトラフィック・サマリーを定期的に確認することをお薦めします。 必要であれば、RUEIの構成を確認して適切なものにしてください。たとえば、他のCookieテクノロジを追加します。また、システムでセッションを追跡できない場合は、ユーザー・フローも適切に追跡できません(ユーザー・フロー・レポートではセッションの追跡が必要になるため)。 |
RUEIがユーザーのWeb環境を正確に監視するためには、RUEIは、ユーザーのWebサイトが使用しているCookieテクノロジを把握して認識する必要があります。Cookieテクノロジは標準的なテクノロジ(ASPやColdFusionなど)かカスタム実装のいずれかになります。カスタム実装の場合には、関連する情報をシステムに提供する必要があります。監視時に使用するCookieテクノロジは最大5つ定義できます。
Cookieテクノロジを指定する手順は、次のとおりです。
「Configuration」→「Applications」→「Session tracking」の順に選択します。このオプションを使用できるのは管理者のみです。現時点で定義されているCookieの設定が表示されます。例を図12-2に示します。
「Add new cookie」または既存のCookie定義をクリックします。図12-3に示すようなダイアログが表示されます。
Web環境で使用しているCookieテクノロジを「Cookie type」メニューから選択します。非標準テクノロジを使用している場合は、「(custom)」を選択します。
「(custom)」を選択した場合は、組織で使用しているCookieの名前を指定する必要があります。Cookie名の一部としてワイルドカード文字(*)を指定できることに注意してください。
|
注意: Cookie名は大/小文字が区別されます。 |
「(URL argument)」を選択した場合は、組織で使用しているURL引数の名前を指定する必要があります。セッションの追跡でのURL引数の使用方法は、付録B「Cookieの構造」に記載されています。次に、「Save」をクリックします。
この設定への変更は、少しの間隔(通常5分から10分)を置いて適用され、さらにその少し後にレポータ・システムに表示されます。
前述のように、セッションの追跡はCookieに基づいて行います。ただし、Cookieが適していない状況または使用できない状況があります。たとえば、次の状況について考えてみます。
Cookieがヒットごとに変化する場合(たとえば、ObSSOCookieのケース)。
Cookieに設定されているパスがアプリケーションの一部にしか対応しない場合。
Webサーバーで構成されているプライバシ・ポリシーのためにCookieの使用が無効な場合。
セッションの追跡のために適切なCookieがない場合は、JavaScriptを使用してクライアント側のCookieメカニズムを実装することをお薦めします。
クライアント側のCookieメカニズムの構成
次の手順を実行します。
該当するログイン・ページに次のようなコードを追加します。
<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>
前述のコードは情報提供のみを目的としています。特定の要件に応じて変更が必要になる場合があります。
「Configuration」→「Applications」→「Session tracking」を選択します。「Add new cookie」をクリックします。図12-4のダイアログが表示されます。
Cookieテクノロジ「(custom)」を「Cookie type」メニューから選択し、適切なCookie名を指定します。前のJavaScriptコードではCookie名はtrackです。これはログイン・ページのJavaScriptコードに指定した名前と一致する必要があります。使用できるのは英数字のみです。また、ヘッダー・サイズを最小限にするためにCookie名は10文字以下にすることをお薦めします。次に、「Save」をクリックします。
Cookieの構成の確認
Cookie構成が正しく追跡されることを確認する手順は、次のとおりです。
ブラウザですべてのCookieを消去します。
監視対象のアプリケーションに(再)ログインします。
いくつかのページ表示を実行します。
監視対象のアプリケーションからログアウトします。
少なくとも10分間待機します。
RUEIレポータ環境を開き、「Browse data」を選択し、「All sessions」グループを開いて「Session diagnostics」を選択します。記録されたセッション(ユーザーID別または時間別)を探します。アプリケーションについてフィルタリングできます。
セッションを開き、ログイン・ページ以外にページ・ビューがあることを確認します。これで、セッションIDがログイン後に保存されていることが確認されます。
Cookieテクノロジを指定しない場合は、クライアント・ネットワークとクライアント・ブラウザの組合せを使用してセッションを追跡します(デフォルト)。ただし、この方法が環境に適していない場合は、代替追跡メカニズムとしてクライアントIPアドレスを使用できます。
代替セッション追跡メカニズムを指定する手順は、次のとおりです。
「Configuration」→「Applications」→「Session tracking」の順に選択します。現時点で定義されているCookieの設定が表示されます。現時点で定義されているセッション追跡の代替メカニズムをクリックします。図12-5に示すダイアログが表示されます。
「Tracking mechanism」メニューを使用して、クライアント・ネットワークとブラウザの組合せを使用する(デフォルト)かクライアントIPアドレスを使用するかを指定します。
次に、「Save」をクリックします。行った変更は、即座に有効になります。
代替セッション追跡メカニズムの選択
どちらの代替メカニズムを使用するかを検討するとき、外部用アプリケーションではデフォルトのネットワークとブラウザの組合せを使用し、内部用アプリケーションではクライアントIPアドレスを使用するのが原則です。同じプロキシ・サーバーで複数のユーザーが存在する場合は、デフォルトの代替メカニズムの使用をお薦めします。ただし、この場合は、すべてのユーザーが1つのセッションに記録されることに注意してください。通常、次の状況ではクライアントIPアドレス・メカニズムの使用をお薦めします。
すべてのユーザーに一意のIPアドレスがある場合。アプリケーションごとに、クライアントIPアドレスをTCPパケットから取得するか、特定のHTTPリクエスト・ヘッダーから取得するかを指定できることに注意してください。この詳細は、付録O「NATトラフィックの監視」に記載されています。
組織で定められたブラウザが使用されている場合。つまり、標準のバージョンおよびプラグインの標準ブラウザ(Internet ExplorerまたはMozilla Firefoxなど)。
管理対象のアプリケーションの一部(またはすべて)が部分的にJavaで実装されている場合。Oracle E-Business Suite(EBS)は、このようなアプリケーション・アーキテクチャの例です。このようなアプリケーションでは、クライアントIPアドレス・メカニズムの使用により、Javaとクライアント・リクエストの両方が同じレポート・セッションに表示されないようになります。
|
重要: ネットワーク・トラフィックの正確なレポートのため、Webサイトで使用するCookieテクノロジを正確に指定することを強くお薦めします。また、ビジター・セッションの追跡に指定するCookieがブラインディングされないようにしてください。ブラインディングが行われると、Cookieに基づくセッション作成が失敗します。 |
オプションの名前付きサーバー機能を使用すると、監視対象Webサイトのビジターを詳細に分析できます。この機能を使用すると、一連のサーバーIPアドレス(ネットマスクを使用して指定)を1つのWebサーバー・グループおよび個別のWebサーバーに割り当てることができます。たとえば、サーバー・グループとして部門またはデータ・センターを使用し、そのグループに属する特定のWebサーバー名をサーバー名として指定できます。これにより、問題(ページの失敗など)が発生したときに、該当するWebサーバーの場所を簡単に特定できます。
この機能を使用する手順は、次のとおりです。
「Configuration」→「General」→「Named servers」の順に選択します。このオプションを使用できるのは、ITユーザーで「Analytical」レベルのアクセス権限を持つユーザーのみです。現時点で定義されている名前付きサーバーが表示されます。「Add new server」をクリックします。図12-6に示すダイアログが表示されます。
このダイアログ内のフィールドを使用して、ネットマスクで限定した一連のIPアドレスまたは単一のIPアドレス、および関連するWebサーバーとそのグループを指定します。次に、「Save」をクリックします。
名前付きサーバーのリストのアップロード
オプションの「Upload list」をクリックすると、名前付きサーバーのリストを現時点で定義されているリストとマージできます。リストのファイルでは1行が1エントリである必要があり、各サーバーに関する情報(図12-6のように表示される情報)はタブで区切っておく必要があります。新しくマージするファイルの中に、すでに定義されている名前付きサーバーが含まれている場合は、既存の定義が上書きされるため、注意してください。
名前付きサーバー・グループへの変更は、少しの間隔(通常5分から10分)を置いて適用され、さらにその少し後にレポータ・システムに表示されます。
ビジターのIPアドレスに関連する情報の拡張が必要な場合もあります。イントラネットのトラフィックを監視しているときに、ユーザー独自のクライアント分類を使用する必要がある場合に、これは特に便利です。
この機能を使用する手順は、次のとおりです。
「Configuration」→「General」→「Named clients」の順に選択します。現時点で定義されている名前付きサーバーがリストされます。「Add new client」をクリックします。このオプションを使用できるのは、ITユーザーで「Analytical」レベルのアクセス権限を持つユーザーのみです。図12-7に示すダイアログが表示されます。
このダイアログ内のフィールドを使用して、ネットマスクで限定した一連のIPアドレスまたは単一のIPアドレス、クライアントおよび関連するグループ(たとえば会社の部門)を指定します。次に、「Save」をクリックします。
名前付きクライアントのリストのアップロード
オプションの「Upload list」をクリックすると、名前付きクライアントのリストを現時点で定義されているリストとマージできます。リストのファイルでは1行が1エントリである必要があり、各クライアントに関する情報(図12-7のように表示される情報)はタブで区切っておく必要があります。新しくマージするファイルの中に、すでに定義されている名前付きクライアントが含まれている場合は、既存の定義が上書きされるため、注意してください。
定義を変更した名前付きクライアント・グループは、少しの間隔(通常5分から10分)を置いて適用され、さらにその少し後にレポータ・システムに表示されます。
ヒットの失敗は、失敗したURLグループの中に記録されます。ヒットの失敗は広範な理由で発生し得るため、どのようなヒットの失敗を記録するのかを設定しておく必要があります。たとえば、リモート・ロボット検索に関連したインシデントの記録が必要になることはほぼありません。次を実行します。
「Configuration」→「General」→「Advanced settings」→「URL reporting」→「Ignore failed URLs」の順に選択します。このオプションを使用できるのは管理者のみです。図12-8に示すダイアログが表示されます。
失敗したURLビュー内で無視する必要のあるファイル名を指定します。つまり、これらがエラーとして表示されないようにします。ファイル名定義内のディレクトリ情報はすべて無視され、定義されたファイルはリストされたオブジェクトURLからも削除されます。無視する必要のあるファイル名を新たに定義するには、「Add」をクリックします。また、定義されたファイルの右側にある「Remove」 アイコンをクリックすると、無視するファイルのリストからそれが削除されます。
インストール時に、2つのデフォルト・ファイル(robots.txtおよびfavicon.ico)が自動的に構成されます。次に、「Save」をクリックします。この設定への変更は10分後に適用されます。この少し後に、指定した変更がレポータ・インタフェースに表示されます。
最低レベルのページURLディメンションに、URL引数をすべて記録するか、一部を記録するか、または記録しないかを設定できます。次を実行します。
「Configuration」→「General」→「Advanced settings」→「Page URL argument filtering」→「Page URL argument filtering」の順に選択します。このオプションを使用できるのは管理者のみです。図12-9に示すダイアログが表示されます。
「Argument filter」メニューを使用して適切なフィルタを選択します。デフォルトは「allow-all」です。つまり、引数がすべて記録されます。次に、「Next」をクリックします。
「allow-some」フィルタを選択した場合は、続くダイアログで、どの引数を記録するかを指定する必要があります。複数ある引数はアンパサンド(&)記号で区切ります。次に、「Next」をクリックします。
新しい設定は10分後に適用されます。その少し後に、指定した変更がレポータ・インタフェースに表示されます。
|
注意: ユーザーのページURLにセッション引数またはその他任意の引数が含まれる場合は、この機能を使用することをお薦めします。この機能を使用しない場合は、ページベース・ビュー(全ページまたは失敗したURLなど)の内容が非常に大きくなることがあります。 |
RUEIでは、セッション情報は「All sessions」グループ内でレポートされます。この機能では、ビジターのセッションに関する情報はセッション開始後約5分で表示されます。デフォルトでは、ビジターが活動しない時間が、定義されたセッション・アイドル時間(デフォルトは60分)を超えた場合に、ビジター・セッションが終了したとみなされます。
セッションのレポートを最適化するために、「Session idle time」の詳細設定を使用して、ビジターのセッションが終了したとみなされる非アクティブな期間(分)を指定します。デフォルトは60分です。
|
重要: この設定は、システムのパフォーマンスおよびレポートされるデータの精度に影響することがあるため、Oracleサポート・サービスのアドバイスを受けた場合のみ変更することを強くお薦めします。 |
セッション設定の指定
セッションをレポートするときに使用するアイドル時間を指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Session processing」→「Session idle time」の順に選択します。図12-10に示すダイアログが表示されます。
ビジターが非アクティブになってからセッションが終了したとみなされるまでの時間(分)を指定します。デフォルトは60分です。次に、「Save」をクリックします。
この設定は、変更すると、5分以内に有効になります。
デフォルトでは、RUEI内でアプリケーション、SSO、プロファイル、スイートおよびサービスの各フィルタで一致が行われる順序は、定義に指定されている詳細のレベルによって決まります。つまり、最も多くの情報が指定されている定義が最初に適用されます。ただし、フィルタの適用順序の変更が必要になる場合があります。
たとえば、ドメインshop.oracle.comのネットワーク・トラフィックを監視するとします。また、2つのアプリケーション(ドメインshop*用に1つおよびドメイン*oracle*用に1つ)を定義しておきます。文字列*oracle*は、文字列shop*より長いため、最初に適用されます。ただし、ドメインshop*のページIDを優先する必要があるとします。ルール順序設定機能を使用すると、デフォルトのルール一致順序を、必要なドメインのページを適用する順序で上書きできます。
|
注意: デフォルトのルール順序設定を使用すること、およびアプリケーション、SSOプロファイル、スイートおよびサービスが相互排他的になるように十分な情報を使用してそれぞれを定義することをお薦めします。 |
ルール順序設定機能を使用する手順は、次のとおりです。
「Configuration」タブをクリックし、「Configuration」メニュー・オプションを選択してから「Edit ruling orders」オプションを選択します。このオプションを使用できるのは、ITユーザーで「Full」アクセス権限を持つユーザーのみであることに注意してください。図12-11に示すようなダイアログが表示されます。
「Automatic rule ordering」チェック・ボックスを使用して、現在定義されているアプリケーション、SSO、プロファイル、スイートおよびサービスからルール順序設定を自動的に導出するかどうかを指定します。前述のように、デフォルトでは、最も多くの情報が指定されている定義が最初に適用されます。「Up」および「Down」コントロールを使用してルールの適用順序を指定すると、このチェック・ボックスの選択が自動的に解除されます。このチェック・ボックスを再び選択すると、フィルタ順序設定が自動的にデフォルトにリセットされます。
行った変更は即座に有効になります。次に、「Close」をクリックします。
|
重要: デフォルトのルール順序設定を変更してから、新規のアプリケーション、SSOプロファイル、スイートまたはサービスを定義すると、関連付けられているフィルタが現在のルール順序設定の最下部に即座に配置されます。このため、新規フィルタの作成後には必ずルール順序設定を確認してください。 |
データ・ブラウザ内に特定データとそのデータに基づくレポートを表示できるかどうかは、コレクタ・システムおよびレポータ・システムで使用可能なディスク領域の量、およびレポータ・システムで使用可能なデータベース領域の量によって異なります。図12-12にこれを示します。
監視中に収集されたデータは、まず、コレクタ・システムに格納されているログ・ファイルに書き込まれます。これらのファイルはレポータにコピーされて処理され、データ・ブラウザおよびレポートで表示可能な多次元のデータ構造を持つデータベースに移入されます。これらの一時ログ・ファイルは、3日後にはコレクタ・システムから自動的に削除され、レポータ・システムからは7日後に削除されます(デフォルト)。データ・マスキング・オプション(13.5項「ユーザー情報のマスキング」を参照)を指定すると、機密情報のログを省略することができます。
ログ・ファイルは、セッション完全再生(FSR)データ・ストアを作成するために使用されます。これらのファイルは、定期的にフィルタリングされ、エラー・ページ再生(EPR)データ・ストアが作成されます。EPRファイルには、失敗したイベント(失敗したページ、オブジェクトおよび関数コール)に関する情報のみが格納されます。FSRデータとEPRデータの両方がコレクタ・システムに保持されます。
レポータ・システムのデータベース・ユーザー割当て制限のサイズは、インストール中に設定されます。デフォルトでは200GBに設定されます。レポータ定義の保存ポリシーで必要なくなるとデータが統合されることを理解しておく必要があります。たとえば、デフォルトでは直前の32日間について日単位の情報が保持されます。これより古い日単位の情報は月単位の情報に統合されます。同様に、月単位の情報は年単位の情報に統合されます。
デフォルトでは、RUEIには、日単位レベルで32日、月単位レベルで13か月、年単位レベルで5年間の情報が保持されます。したがって、たとえば、最も古い日単位情報は32日が経過したら削除されます。また、一時ログ・ファイルは、約7日間ファイル・システムに保持されます。新しいインストール済RUEIは、最初の32日間に最も急成長を遂げます。その期間が過ぎると、成長率は低下します。もちろん、成長率は、監視されているトラフィック・レベルによって異なります。
デフォルトでは、失敗したURL、ページおよびサービス・コールに関する情報は15日間保持されます。それが残っている場合、セッション診断の再生機能で表示できます(4.1項「概要」を参照)。
この項の残りの部分で説明する設定により、業務上の要件を満たすように、インストール済RUEIのディスクおよびデータベースの使用率を最適化できます。
レポータ・システムで使用するデータ保存ポリシーを指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Reporter data retention policy」の順に選択します。図12-13に示すような画面が表示されます。
図12-13に表示されるように、データベースに影響があるすべての設定には、対応する「Database usage」のリストがあります。このリストは、その項目に現在使用中の合計データベース領域(GB)と、それがデータベースの最大許容サイズに対して占める比率を表します。推定されるデータベース使用率(監視対象トラフィックのレベルに基づく)も示されます。ディスク領域使用率の情報は、個別設定のダイアログ・ボックスに表示されます。
目的の設定を選択します。表12-1に示す設定が可能です。
表12-1 レポータのデータ保存ポリシー設定
| 設定 | 説明 |
|---|---|
|
Maximum database size |
データベースに格納できるデータの最大量を(GB単位で)指定します。この設定を変更するには、データベースのSYSTEMユーザー・パスワードを指定する必要があることに注意してください。 |
|
Failed event data retention |
失敗したURL、ページおよびサービス・コールに関する情報を使用可能にする期間を指定します。デフォルトは直前の15日間です。セッション診断の再生で情報が使用可能にならない場合には、この設定を確認できます。この設定は、エラー・ページ再生の記憶領域サイズ設定(13.7項「コレクタのデータ保存ポリシーの定義」を参照)に関連していることに注意してください。失敗したイベントのデータ保存設定値を大きくする場合は、適切に動作するように、エラー・ページ再生の記憶領域サイズ設定値も大きくすることをお薦めします。また、この設定はディスク領域使用率に大きな影響を与えるため、変更する場合は、予想されるネットワーク・トラフィックの観点から慎重に検討する必要があります。 |
|
Session diagnostics retention |
セッション診断情報を使用可能にする最大日数を指定します。この機能は、4.1項「概要」に記載されています。デフォルトは直前の7日間で、最小値は直前の2日間です。この設定は、データベース領域およびディスク領域の使用率に影響を与えます。レポートされるディスク領域使用率には、レポートされるデータベース使用率は含まれていません。 |
|
Enriched data exchange retention |
拡張データ交換機能を介して情報を使用可能にする最大日数を指定します。この機能は、付録R「エンリッチ・データのエクスポート機能」に記載されています。デフォルトは7日間です。つまり、データは直前の6日間と当日に使用可能です。最大保持期間は使用可能なデータベース記憶域の容量によって異なります。 この設定は1日の境界(午前0時頃)で適用されます。したがって、日数を(たとえば、7日間から5日間に)減らすと、設定変更が15分以内に有効になり、5日目と6日目のデータがデータベースからパージされます。 1日に設定すると、前日のデータは午前0時頃に削除され、当日にはごく限られた量の情報しか利用できません。したがって、午前0時過ぎに前日のデータにアクセスするには、保持期間を2日間以上に設定する必要があります。 |
|
KPI data exchange retention |
拡張データ交換機能を介してKPI情報を使用可能にする最大日数を指定します。この機能は、付録R「エンリッチ・データのエクスポート機能」に記載されています。デフォルトは365日間です。最大保持期間は使用可能なデータベース記憶域の容量によって異なります。 |
|
Daily data retention |
日単位の情報を使用可能にする期間を指定します。デフォルトは直前の32日間です。日単位データの最大保持期間は月の設定によって異なる場合があります。 |
|
Monthly data retention |
月単位の情報を使用可能にする期間を指定します。デフォルトは直前の13か月です。月単位データの最大保持期間は年の設定によって異なる場合があります。 |
|
Yearly data retention |
年単位の情報を使用可能にする期間を指定します。デフォルトは直前の5年間です。この最小設定は日の設定によって異なり、最小数は月の設定によって異なります。 |
|
Maximum data group size |
データ・グループの拡大可能な最大サイズを指定します。この設定は、12.9.3項「失敗したグループの最大サイズの設定」に記載されています。 |
図12-14に示すようなダイアログが表示されます。
このダイアログのコントロールを使用して、選択したオプションの保存ポリシーを指定します。
ほとんどの設定では、「Calculate」をクリックすることで、データベース使用率とディスク領域使用率のうち、該当する方に対するユーザーの選択の影響を表示できます。
次に、「Save」をクリックします。ディスク領域割当ての変更は約10分で有効になりますが、データベース割当ての変更は午前0時を過ぎるまで有効にならないことに注意してください。
|
注意: 保持されるデータの量を増やすには、まず下位レベルのデータ保存設定、次に上位レベルのデータ保存設定を変更することをお薦めします。保持されるデータの量を減らす場合は、まず上位レベルのデータ保存設定、次に下位レベルのデータ保存設定を変更します。 |
必要な日数、月数および年数の計算
上位、中位および下位のデータ保存設定を指定するときには、保存される日数、月数および年数間の依存関係を理解しておくことが重要です。次のルールを使用して、必要な設定値を計算します。
1か月は30日と想定されています。指定した日数に対応して保存が必要な月数は、日数を30で割った数(次の整数に切上げ)に1を加えたものとなります。たとえば、33日の場合、33/30(1.1となり、切り上げて2)に1を加えたものが必要となるため、3か月になります。
指定した月数に対応する必要な年数は、月数を12で割った数(次の整数に切上げ)になります。たとえば、11か月の場合は1年が必要となり、13か月の場合は2年が必要となります。
例: 900日、31か月および3年。
コレクタのデータ保存ポリシーの構成は、13.7項「コレクタのデータ保存ポリシーの定義」に記載されています。
この項では、監視対象トラフィックについてより正確なレポートを作成するために、デフォルトの最大データ・ブラウザ・グループ・サイズを増やす方法について詳しく説明します。デフォルトの設定を変更する前に、提供されている情報を慎重に検討することを強くお薦めします。
圧縮
パフォーマンスを最適化するため、個々のグループのサイズを無制限に増やすことはできません。メイン・グループ表ごとに最大許容サイズが設定されています。デフォルトでは600MBです。Failed URLs、Failed services、Failed pagesおよびSlow URLsグループのサイズは、グループのメイン・データベース表に5分間に追加できる最大行数によって制御されます。デフォルトでは5000行です。この詳細は、12.9.3項「失敗したグループの最大サイズの設定」に記載されています。セッション診断情報に制限はありません。
グループの最大サイズは、圧縮によって管理されます。これは、使用頻度の最も少ないデータをotherグループに移すことで、グループ表内の行数を減らす方法です。たとえば、クライアント-ブラウザ/バージョンのディメンション内の行には、めったに見られないMozilla Firefoxバージョン用の行が少数含まれている場合があります。この場合、表内の行数は、これらの行を単一のother(firefox)行に置き換えることで減らします。
必要な情報が定期的に圧縮されているのであれば、グループの最大サイズを増やすことを検討してもよいでしょう。たとえば、必須の個々のページ名やユーザーIDは、otherとしてしか報告されません。概して、この方法は、ネットワーク通信量が多い場合にお薦めします。
重要:
最大グループ・サイズを150%(900MB)より大きく設定している場合、データベースをリモート・データベースとして構成することを強くお薦めします。推奨される最大グループ・サイズは300%脚注1(2.0GB)です。最大グループ・サイズを増やした場合、データ・ブラウザの問合せやダッシュボードの更新に対するレスポンス時間は、処理に長くかかる可能性があるので注意してください。
カスタム・ディメンションは、圧縮プロセスに大きな影響を及ぼすので注意が必要です。カスタム・ディメンションの構成を誤ると、圧縮が過剰になる可能性があります。たとえば、製品名(または、同様に選択性の高い属性)は、圧縮処理をゆがめるので、カスタム・ディメンションとして構成しないでください。具体的には、ページ/製品の各組合せは圧縮処理の別々の候補となり、圧縮後にもそのまま表示されるのは、高頻度の組合せのみになります。
最大グループ・サイズ変更の効果の確認
最大グループ・サイズ設定を増やした後、レポータ・システムのパフォーマンスに対する変更の効果を注意深く再確認することを強くお薦めします。最低丸1日待ってから、System、Status、Data processingの順に選択します。システム・ロードを再確認し、レポータ・システムで、最大グループ・サイズ設定の増加による追加の処理オーバーヘッドを処理できるかどうかを判断します。
|
重要: データ・グループ・サイズを増やすと、システム全体のパフォーマンスに大きな影響が出る可能性があります。そのため、データ・グループ・サイズへの変更は、慎重に計画し、処理しやすい手順で実行する必要があります。 |
前に説明したとおり、Failed URLs、Failed servicesおよびFailed pagesグループでは、最大グループ・サイズ設定は使用しません。かわりに、event_max_fail設定によってサイズが制御されます。この設定により、グループのメイン・データベース表に5分間に追加できる最大行数を指定します。デフォルトでは5000行です。Slow URLsグループにはevent_max_slow設定が使用され、5分間ごとに記録される最も遅いURLの数を指定します。デフォルトでは5000行です。
event_max_failまたはevent_max_slow設定を変更する場合、daily_max_fail設定も再確認する必要があります。これは、グループの表に入る最大行数を指定します。最大行数は、288 * event_max_failの式から導出されます。デフォルトは140万行です。
前述の設定を変更するには、次のコマンドを発行します。
$ sqlplus /@$RUEI_DB_TNSNAME SQL> update UXS_CONFIG set VALUE='10000' where NAME='event_max_fail'; SQL> update UXS_CONFIG set VALUE='4320000' where NAME='daily_max_fail';
event_max_fail設定は、最大10,000行に制限されます。
デフォルトでは、最新の(未完了)期間の情報は、選択されている期間の現時点の分までが常に表示されます。グラフではこの部分は点線で表示されます。例を図12-15に示します。
未完了期間のレポート時期の指定
未完了の期間をいつレポートするかを指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Data visualization」→「Current period reporting」を順に選択します。図12-16に示すダイアログが表示されます。
最新期間をレポートするときに使用する視覚表現を選択します。表12-2に示すオプションがあります。
表12-2 「Visualization」のオプション
| オプション | 説明 |
|---|---|
|
Enabled |
すべての未完了期間をすべてのグラフでレポートすることを指定します。値リスト、レポートおよびエクスポートにも含めます。このオプションがデフォルトです。 |
|
Disabled |
未完了期間はレポートしないように指定します。 |
|
Specified |
未完了期間は特定の視覚表現のみでレポートすることを指定します。「Value list」オプションには、データ・ブラウザの値リストだけでなく、レポートとエクスポートも含まれることに注意してください。 |
次に、「Save」をクリックします。この設定は、変更すると、即座に有効になります。
KPI値およびSLA値は一定レベルの精度でレポートされます。デフォルトでは小数点以下2桁です。ただし、これを変更してユーザーのレポート要件を反映できます。次のように実行します。
「Configuration」→「General」→「Advanced settings」→「KPI and SLA precision reporting」の順に選択します。レポートを変更するアイテムを選択します。たとえば、「SLA success」です。図12-17に示すようなダイアログが表示されます。
選択したアイテムをレポートする場合の小数点以下の桁数を指定します。次に、「Save」をクリックします。これらの設定は変更すると即座に有効になります。
1.5項「環境のカスタマイズ」で説明されているとおり、ユーザーはセッションで使用される書式設定をカスタマイズできます。小数点に使用する文字、3桁区切りに使用する文字、および使用する日付書式を指定できます。管理者が、システム全体にわたるこれらの設定のデフォルト値を指定することもできます。それには、「System」→「Maintenance」→「Formatting preferences」の順に選択します。
脚注
脚注1: 最大グループ・サイズを増やすと、レポートのパフォーマンスに影響します。パフォーマンスに問題がないことを確認しながら、この設定値を徐々に増やすことをお薦めします。
