| Oracle® Real User Experience Insightユーザーズ・ガイド 13.3.1.0 for Linux x86-64 E98302-02 |
|
 前 |
 次 |
URL引数
アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があります。
RUEIにおけるページ識別は、アプリケーションに基づいて行われます。 一般的に、アプリケーションはWebページの集合です。 通常、Webサイトのページは特定のアプリケーションにバインドされているためです。 アプリケーション内の各ページには名前が割り当てられていて、それぞれのページはグループに属します。 たとえば、MyShop » Contact » About usは、MyShopアプリケーション内のContactグループのAbout usページを指します。
各アプリケーションには、アプリケーションの有効範囲を定義するページ・ネーミング・スキームが関連付けられています。 スキームの指定には、ドメイン名の一部またはURL構文の一部、あるいはその両方の組合せを使用できます。 また、ページ・ネーミング・スキーム(ページ・タグ付けやHTMLページのタイトル部分など)は、アプリケーション定義を微調整する際にも指定できます。
RUEIで検出される各ページに対し、スキームは、存在するアプリケーション定義を使用して名前を割り当てます。 これらの定義を使用して識別できなかったページに関する情報は廃棄されるため、レポートおよびデータ・ブラウザでは使用できません。
アプリケーション・ページは、自動検出できるのみでなく、手動で定義することもできます。 手動定義が特に役立つのは、URL構文に一貫性のない場合や、識別されたページにサブページが含まれる場合、またはアプリケーションによって自動的に割り当てられた名前とは違う名前を割り当てる必要がある場合です。 これらの手動で定義されたページは、アプリケーション定義によって自動的に識別されたページより優先されます。
現時点で定義されているアプリケーションとそのグループおよびページの構造を表示するには、構成→アプリケーション→アプリケーションの順に選択します。 例を図7-1に示します。
アプリケーションの識別フィルタを編集するには、関連する値(cookieフィルタの編集など)をクリックし、aCookie=22をクリックします。
「アプリケーションの定義」では、タグ・ベースのデータ・コレクタまたはネットワーク・ベースのデータ・コレクタを使用してアプリケーションをモニターする方法を説明します。
タグ・ベースのアプリケーションでは、タグ・データ・コレクタは使用されますが、ネットワーク・データ・コレクタは使用されません。ヘッダーからのデータの収集、XPathおよびコンテンツ・ソースは、アプリケーション構成、ユーザーidおよびコンテンツ・メッセージには適用されません。 たとえば、ユーザーIdおよびコンテンツ・メッセージはタグ・ベースのアプリケーションには適用されません。 タグ・ベースのアプリケーションのユーザーを識別するには、oraInfo.userタグを使用します。 ブラウザ例外を構成するには、コンテンツ・メッセージ内の特定の"ブラウザ例外"ソースを使用し、Javascriptライブラリにより送信されるCookieを使用するようにセッション・トラッキング構成を'Oracle'に設定します。
ただし、タグ・ベースのアプリケーションでは、複数のメトリック(ヒット、アプリケーション言語、アプリケーション・テリトリ、詳細なタイミング、サイズなど)およびリプレイ機能は使用できません。
これらの制限を回避するために、タグ・ベースのコレクタに加えてネットワーク・データ・コレクタをインストールできます。 「フレームワーク例外によるアプリケーション定義の微調整」の説明に従ってフレームワーク例外を作成し、タグ・ベースのトラフィックとネットワーク・ベースのトラフィックの両方が結合されたハイブリッド構成を作成します。
タグ・ベースおよびネットワーク・ベースの監視の設定の詳細は、RUEIインストレーション・ガイドのRUEIソフトウェアのインストールを参照してください。
アプリケーションを定義する手順は、次のとおりです。
最高レベルのフィルタはドメインです。 アプリケーション名を指定して他のすべてのフィールドを空白にすることはできません。 つまり、空白フィルタは使用できません。 「ポートの検索」フィールドにワイルドカード文字(*)を指定することはできず、指定できるポート番号は1つだけです。 さらにポートを指定する必要がある場合は、新しいアプリケーションが作成された後で追加のフィルタとして指定してください。
特定のフィールドではワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。 ワイルドカード文字を指定して、ドメインとURL引数の組合せによるその他の情報を指定しないことはできません。
注意:
スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。 たとえば、ドメインoracle.comでフィルタリングされるアプリケーションと、oracle.com/application_servletでフィルタリングされる別のアプリケーションがある場合、予測できない結果が発生することがあります。 一致ルールが適用される順序を変更できる方法は、「RUEI内でのルール順序設定の制御」を参照してください。
注意:
アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があります。
一致対象とするURL GET引数を指定することもできます。 この機能を使用する場合は、引数名と引数値の両方を完成させて、検出されたページURLsと一致させる必要があります。 つまり、部分一致はサポートされていません。 準備ができたら、次へをクリックします。 「図7-3」に表示されるダイアログが表示されます(「HTMLタイトル」がデフォルトで選択されています)。
また、「cookieの検索」フィールドや「Cookie値」フィールドを使用してcookieを指定することもできます。
7-3 新規アプリケーションダイアログ
注意:
タグ・ベース・アプリケーションチェック・ボックスを選択した場合、次のページ・ネーミング・スキーマが表示されます。
HTMLタイトル(ブラウザJSライブラリ)
Oracle (ブラウザJSライブラリ)
URLベースのオプション
ページのタグ付け: 標準スキーム(Coremetricsなど)とカスタム・スキームのいずれを使用するかを指定します。 カスタム・スキームの場合は、カスタム・タグの名前を指定する必要があります。 HTMLタイトルオプションは、ページの<title>タグにあるテキストを使用してページを識別する必要があることを指定します。 このオプションの使用方法の詳細は、「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。 RUEIでサポートされる一般的なページ・タグ付けスキームの構造と処理については、「Tagging表記規則」で説明します。
クライアント・リクエスト: ページをそのURL構文に基づいて識別することを指定します。 次のオプションにより、URLのどの部分を使用するかを指定します。
URL引数: ページ・ネーミングは、URL内の指定した引数に基づきます。 ASCII文字のみが許可され、特殊文字("&"や"|")"など)をurlエンコードする必要があります。
URL: ページ・ネーミングが、ビジターのブラウザのロケーション・バーに表示される完全なドメインとURLに基づきます。 このスキームは規則指定を使用するときに特に役立ちます。
URLディレクトリ: URLのディレクトリ部分のみを使用します。 URLの各部分は、図7-4に示されています。
URLベース: URLのメイン・ディレクトリとファイル名(ファイル拡張子は除く)の部分を使用します。
URL全体: URLのメイン・ディレクトリ、ファイル名(ファイル拡張子は除く)および構成済の引数を使用します。 このオプションを選択すると、ページ名に含める引数を指定するように求められます。 このダイアログ・ボックスでは、複数の引数はアンパサンド(&)文字で区切る必要があります。 たとえば、frmActionパラメータを定義した図7-4のURLは、myshop » shop » NL index frmAction=buyというページ名になります。
リクエストのヘッダー: ページ・ネーミングでクライアント・リクエスト内の指定されたヘッダーを使用することを指定します。 ヘッダー名で使用できるのはASCII文字のみです(:などの特殊文字は使用できません)。
リクエストのXPath: クライアント・リクエストに適用されたXPath式に基づいてページを識別することを指定します。 XPath式の使用方法の詳細は、「XPath問合せの操作」を参照してください。
JSONリクエストのXPath: JSONクライアント・リクエストに適用されたXPath式に基づいてページを識別することを指定します。 JSONリクエストに対するXPath式の使用の詳細は、「XPath JSONコンテンツ」を参照してください。
リクエスト内のカスタム・パターン: 開始文字列と終了文字列(オプション)を指定して、検索対象のコンテンツを区切ります。 ワイルドカード文字の使用はサポートされておらず、指定するすべての文字がリテラルとして扱われます。 また、終了文字列を指定すると、検索は次の行以降では行われません。
HTTPメソッドおよびURL: ページ・ネーミングが、ビジターのブラウザのロケーション・バーに表示されるHTTPメソッドおよび完全なドメインとURLに基づきます。 これにより、REpresentational State Transfer (REST)スタイルのアプリケーションのサポートが可能になります。このネーミング・スキーム・オプションは、HTTPメソッドおよびスペースで区切られた完全なURLをレポートします。 アプリケーション定義を作成した後、アプリケーション概要でネーミング・スキームを選択して、URL規則指定を定義し、翻訳リストを作成します。
これらいずれかのオプションを選択した場合、使用方法の詳細は、「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。
サーバー・レスポンス: サーバーのレスポンスに基づいてページを識別することを指定します。 次のオプションを使用できます。
レスポンスのヘッダー: サーバー・レスポンス内で指定されたヘッダーに基づいてページを識別することを指定します。
レスポンスのXPath: サーバーのレスポンスに適用されたXPath式に基づいてページを識別することを指定します。 XPath式の使用方法の詳細は、「XPath問合せの操作」を参照してください。
JSONレスポンスのXPath: JSONサーバーのレスポンスに適用されたXPath式に基づいてページを識別することを指定します。 XPath式の使用方法の詳細は、「XPath JSONコンテンツ」を参照してください。
レスポンスのカスタム・パターン: 開始文字列と終了文字列(オプション)を指定して、検索対象のコンテンツを区切ります。 ワイルドカード文字の使用はサポートされておらず、指定するすべての文字がリテラルとして扱われます。 また、終了文字列を指定すると、検索は次の行以降では行われません。
手動: アプリケーション・ページを自動検出せずに手動で定義することを指定します。 このオプションを選択すると、監視するアプリケーションに関連付けられているすべてのページを手動で定義する必要があります。 手動のページ定義の詳細は、「ページの手動識別」を参照してください。 このオプションがデフォルトです。
次に、終了をクリックします。 指定したアプリケーション定義が表示されます。 例を図7-5に示します。
図7-5 アプリケーション概要の例
注意:
アプリケーションを削除すると、構成とそれまで測定されたデータがすべて破棄されます。 この操作は元に戻すことができません。
注意:
URLベースでないページ・ネーミング・スキームを使用してタグ・ベースのアプリケーションを作成し、後から(タグ・ベース・アプリケーションチェック・ボックスを選択解除することにより)そのアプリケーションを編集してタグ・ベースでないアプリケーションにした場合、そのページ・ネーミング・スキームは相当するページ・ネーミング・スキームに変換されます。 たとえば、HTMLタイトル(ブラウザJSライブラリ)スキームはHTMLタイトルになります。
以前はタグ・ベースでなく、URLベースでないページ・ネーミング・スキームを使用していたアプリケーションに対してタグ・ベース・アプリケーションチェック・ボックスを選択すると、そのネーミング・スキームはOracle (ブラウザJSライブラリ)に変換され、すべてのルーリングが削除されます。
タグ・ベースのアプリケーションを作成した場合、ブラウザJSライブラリ(監視対象のタグとして機能するアプリケーションによって提供されるURL)を定義する必要があります。
アプリケーションまたはスイートで使用されるブラウザJSライブラリを指定する手順は、次のとおりです。
図7-6 ブラウザJSライブラリの編集ダイアログ
「アプリケーションの定義」の説明に従ってアプリケーションのページ・ネーミング・スキームとしてOracle (ブラウザJSライブラリ)を選択した場合、oraInfo.pageプロパティも次のように設定する必要があります。
セキュリティ上の理由で、ワイルドカード文字の使用はサポートされません。
ネットワーク・データ監視を使用するアプリケーションおよびスイートの場合、デフォルトでブラウザJSライブラリは構成されておらず、ブラウザJSライブラリを自分で定義しなければ、ページ・ブラウザ時間がゼロとしてレポートされます。 また、レポートされたページ・ロード時間はページ・ブラウザ時間を含まないため、ページ・ロード/読取り時間分析が不正確になる可能性があります。 ページがCDNサーバー(Akamaiなど)からリクエストされている場合、OnLoadイベントを使用すると、CDNで処理されるオブジェクトのレンダリング時間が含まれます。
例7-1 タグ・ライブラリ・プロパティ
タグ・ベースのアプリケーションを作成した場合、RUEIでは、予約されたタグ・ライブラリ・プロパティoraInfo.titleを使用してページ・タイトルが自動的にレポートされます。
さらに、JavaScriptコードを使用して次のプロパティも指定できます。
表7-1 タグのプロパティ
| 名前 | デフォルト | 説明 |
|---|---|---|
oraInfo.url |
document.location.href |
RUEIによってページURLとしてレポートされる値。 |
oraInfo.page |
RUEIによってページ名としてレポートされる値。 |
|
oraInfo.pagegroup |
RUEIによってページ・グループとしてレポートされる値。 |
|
oraInfo.action |
RUEIによってアクションとしてレポートされる値。 |
|
oraInfo.user |
RUEIによってユーザーとしてレポートされる値。 |
次に例を示します。
<script type="text/javascript" src="ruei_library.js"></script> <script type="text/javascript"> oraInfo.page = 'homepage'; oraInfo.action = 'view'; </script>
例7-2 タグ・ライブラリを使用したページのクリックのモニタリング
タグ・ベースのアプリケーションを作成した場合、onclick oraInfo.sendActionプロパティを使用してページ・クリックを監視できます。 たとえば、次のコードでは、ユーザーによる"Click here"リンクのクリックがレポートされます。
<a href="#" onclick="oraInfo.sendAction('clickAction');"> Click here</a>
例7-3 ブラウザJSライブラリ・リンクの手動デプロイメント
「ブラウザJSライブラリ設定の定義」のステップ4のかわりに、指定したマーカー・オブジェクトに対するリクエストを自分で作成することもできます。 リクエストが有効にされたときにRUEIはこれを検知し、ブラウザ時間になるようにリクエストの開始時間を記録します。 指定したURL検索パターンは、トリガーされたリクエスト内のURL検索パターンと一致している必要があります。
次に例を示します。
onLoad="m=new Image(); m.src='http://myhost.com/marker.gif?apikey=yourAPIkey&' + new Date().getTime();"
ここで、yourAPIkeyはブラウザJSライブラリのAPIキーであり、ブラウザ・キャッシュを防ぐための引数としてタイムスタンプが含まれます。 イベントは、HTMLページのBODY部分、またはその他の必要なロケーション(フラッシュ・プログラム内など)に含めることができます。
前述の例には、ブラウザ例外、ナビゲーション・タイミング、オブジェクト・カウントおよび画面解像度は含まれていません。 これらを含める場合はJavaScriptライブラリが必要です。
例7-4 ブラウザJSライブラリでのカスタム・ディメンションの使用
「カスタム・ディメンションの操作」で説明されている「カスタム・タグ(ブラウザJSライブラリ)」ディメンションを作成する場合、これらのディメンションに関連するプロパティを設定できます。 たとえば、製品、グループおよびベンダーの3つのレベルで構成されるディメンションを作成した場合は、次のコードを追加してページのプロパティを設定できます。
<script type="text/javascript" src="ruei_library.js"></script> <script type="text/javascript"> oraInfo.product = 'x9991'; oraInfo.group = 'Servers'; oraInfo.vendor = 'Oracle'; </script>
この3つのレベル・ディメンションを作成すると、RUEIは「カスタム・ディメンションの操作」で説明するレポートで参照および使用できるデータを収集します。
例7-5 サポートされているブラウザ
ブラウザJSライブラリは、W 3 Cタイミングをサポートする最新のブラウザで動作します。たとえば、IE 9 +、Firefox 34 +、Chrome 31 +、Safari 8 +、Opera 26 +などです。 ただし、Internet Explorer 8はサポートされていません。
「ページのネーミング」で説明する定義済のページ・ネーミング・スキームに加えて、ページ翻訳を使用してアプリケーション・ページのレポートを変更することもできます。 これらにより、ページのレポートされたpage-group » page-name仕様に行われる変換を指定できます。
ページ翻訳の定義
ページ翻訳を定義する手順は、次のとおりです。
構成→アプリケーション→アプリケーションの順に選択して、目的のアプリケーションを選択します。 (図7-5に示したような)アプリケーション概要が表示されます。
ページタブ→ページ翻訳タブの順にクリックします。 現在定義されているページの説明が表示されます。 新規翻訳の追加をクリックして新しい説明を定義するか、既存の説明をクリックして変更します。 「図7-7」に示すダイアログが表示されます。
図7-7 ページ翻訳の追加ダイアログ
元のページIDおよびレポートされるグループと名前を指定します。 元の値は、「グループ」 | nameという形式で指定する必要があります。 次に、保存をクリックします。
環境間のページ翻訳の移動
ページ翻訳は、アプリケーション自体と同時に作成することをお薦めします。 そのためには、開発中のアプリケーションをRUEIで開始し、そこで定義されているページ翻訳を取得した結果に基づいて微調整するのが最も確実です。
デプロイの準備ができると、アプリケーションは本番環境に移動されます。 その新しい環境が別のRUEIインストールによって監視される場合でも、アプリケーションのページ翻訳を手動で再作成する必要はありません。 そのかわりに、ダウンロード機能を使用してその最新定義を取得し、生成されたファイルをアップロードして新しいRUEIインストールで使用することができます。
事前定義済のページ翻訳のリストを含むファイルをアップロードするには、次の手順を実行します。
図7-8 ページ・トランザクションのアップロード
現在定義されているページ翻訳をダウンロードするには、ダウンロード・リストをクリックします。 ブラウザの構成方法によって異なりますが、ファイルの保存場所の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。
「アクション・ネーミング・スキームの定義」などのHTTPメソッドおよびURLのアクション・ネーミング・スキームを使用する場合は、このスキーム(指定されたHTTPメソッドおよびURLなど)にアクション翻訳を関連付けることができます。
アクション翻訳の定義
アクション翻訳を定義するには、次の手順を実行します。
図7-9 アクション翻訳の追加ダイアログ
HTMLタイトルスキームまたはクライアント・リクエストのページ・ネーミング・スキームのいずれか(URLベースなど)を選択した場合、そのページ・ネーミング・スキーム内の拡張タブを使用して、これらのスキームの運用を微調整できます。 HTML titleスキームの場合は、図7-10に示すダイアログが表示されます。
時間認識
時間認識メニューを使用して、ページを識別するために非強制オブジェクトを使用するかどうかを制御できます。 図7-11に示す例について考えます。
この場合、ページ識別に使用することができる3つの非強制オブジェクト(home.jsp、sub.jspおよびdown.jsp)があります。
有効なオプション(デフォルト)が時間認識メニューに指定されている場合、最初のオブジェクト(home.jsp)のみがページとして識別され、最後のオブジェクトがヒットしてから1秒以内にヒットが検出されなくなるまで、以降のすべてのヒットがオブジェクトとみなされます。 ただし、有効の場合には、3つの非強制オブジェクトそれぞれ(jspなど)が検出時刻は考慮されずに別のページとして識別されます。 強制オブジェクトの詳細は、「ページとしてのオブジェクトのレポートの制御」を参照してください。
大/小文字の制御
拡張タブにある小文字変換メニューを使用すると、ページ名を小文字に変換するかどうかを指定できます。 表7-2に、使用可能なオプションを示します。
表7-2 大/小文字制御オプション
| オプション | 説明 |
|---|---|
いいえ |
ページ名を元の大/小文字のまま維持します。 これはデフォルトです。 |
ルーリング前 |
選択したアプリケーション、スイート、サービスについてレポートされるページ名を、ルーリングタブで定義されているすべてのルールを適用する前に小文字に変換します。 テスト入力および検索式は小文字で入力する必要があります。 |
ルーリング後 |
選択したアプリケーション、スイート、サービスについてレポートされるページ名を、ルーリングタブで定義されているすべてのルールを適用する後に小文字に変換します。 |
サブヘッダーによる代用
HTMLタイトルページ・ネーミング・スキームを選択した場合は、ページの<title>タグにあるテキストがページの識別に使用されます。 このテキストが見つからない場合は、サブヘッダー<H1>、<H2>および<H3>を使用できます。 このためには、サブヘッダー代替メニューを使用してこの機能を制御します。 デフォルトでは、サブヘッダーは使用されません(無効)。
リダイレクトの処理
クライアント・リクエストベースのいずれかのスキーム(URLベースなど)を選択して、拡張タブをクリックすると、図7-12に示すダイアログが表示されます。
ページの処理メニューを使用して、URL内のリダイレクトをどのように処理するかを指定します。 表7-3に示すオプションがあります。
表7-3 ページ処理オプション
| 設定 | 説明 |
|---|---|
最終ページ |
ページ名を決定するために最終ページのURLのみを使用することを指定します。 これはデフォルトです。 |
リダイレクト・ネーミング |
最終ページの前でリダイレクトから得られる情報を使用してページを識別することを指定します。 ない場合は、最終ページの情報が使用されます。 |
リダイレクトがなるページ |
リダイレクトが実際に識別されるページになるように指定します。 最初のリダイレクトがページ作成に使用され、その後のすべてのリダイレクトは作成されたページのオブジェクトになることに注意してください。 アプリケーションのレポートに及ぼす結果をよく理解した場合のみ、このオプションを選択することを強くお薦めします。 |
注意:
ページ名がリダイレクトから導出された場合、フル・セッション再生機能(「セッション診断の概要」で説明)とエラー・レポートが正しく機能しない場合があることに注意してください。
各アプリケーション定義では、使用するページ・ネーミング・スキームおよびユーザー識別スキームを指定する必要があります。 また、必要に応じて、特定のアプリケーション・ページで表示されたときにレポートする必要のあるコンテンツ・メッセージを指定することも可能です。 これらの各定義は、規則指定機能を使用して拡張できます。 追加の一致規則を指定できるようになり、それによって選択したページ・ネーミング・スキーム、ユーザー識別スキームまたはメッセージの仕様を微調整します。
ページ・ネーミングの規則指定機能を使用しているときには、一致するURLについてのみレポートされます。 URLが一致しない場合、完全に無視されます。 規則指定機能は、自動(手動ではない)ページ・ネーミング・スキームおよびXPathベースの(リテラルではない)コンテンツ・メッセージに対してのみ使用可能です。
推奨される使用方法
規則指定は複雑であるため、選択したアプリケーションの適切なスキームまたはメッセージ構文を十分理解しているユーザーのみがこの機能を使用することをお薦めします。 たとえば、URLベースのページ・ネーミング・スキームの場合、選択したアプリケーションの基礎となるURL構文も明確に理解しておく必要があります。
注意:
小文字変換オプションでルーリング前設定が適用されている場合、テスト入力および検索式は小文字で入力する必要があります。
ルールの定義
アプリケーションの規則指定の使用を指定するには、次の手順を実行します。
図7-13 Edit Application Page-Naming Schemeダイアログ
図7-14 ルーリングタブ
図7-15 一致ルールの追加
図7-16 規則チェック・ダイアログの例
次に、保存をクリックします。 図7-14に示したダイアログに戻ります。
図7-17 規則指定の検証の例
最初の規則は定義済の検証値と一貫性があり、正常に検証されています。 ただし、2番目の規則は非常に汎用性が高いため、複数の評価規則がこの規則と一致すると警告されます。 実際に、汎用性が高いために関連する検証値がすでに正常に適用されてしまい、後続の規則を適用できません。 つまり、3番目の規則が使用されません。 このため、2番目の規則ではなく3番目の規則についてエラーがレポートされます。 ただし、2番目の規則を移動して最後の規則にすると、3つの規則が正常に検証されます。
エラーが報告された状態でルー・リング定義を保存することは可能ですが、ルール・リング定義を保存する前に問題を解決することをお薦めします。 次に、保存をクリックします。 規則指定の定義の変更は5分以内に有効になります。
例7-6 URL一致のルール・リング
URL一致では大/小文字が区別され、URL(一致の後)は小文字に変換されることに注意してください。 規則指定の後で、一致したスラッシュはページ名において空白に置き換えられます。
また、URL構造に基づいてルーリングを実行する場合、URLページ・ネーミング・スキームのみを使用することをお薦めします。 これは、他のURLベースのネーミング・スキームが初期フォーマットの一部のフォームを実行するためです。
例7-7 ユーザー識別のルール・リング
ユーザー識別で規則指定を使用する方法は、ページ・ネーミングの場合と同じですが、ユーザーIDが選択したスキームから識別される方法を指定すること、ページ・グループ識別がサポートされないことが異なります。 次の例について考えてください。 指定したユーザー識別スキームがCookieに基づき、各Cookieは次の構造をしています。
ORA_UCM_INFO=5~DVJ88287~John~Doe~john.doe@myshop.com~USA~en~33~44~5~~1;
このCookieの電子メール・アドレス部分のみに基づいてユーザーを識別するようにします。 この場合、次のように指定できます。
検索式: %\~%\~%\~%\~%\~%
ユーザーID: %5
検証値は、上記の例のCookieまたは同じ構造の他のCookieの例を使用して指定できます。
例7-8 クライアント・ブラウザの規則指定
クライアント・ブラウザの規則指定を使用すると、モバイル・アプリケーション・ベースのトラフィックとブラウザ・トラフィックを分離できます。 たとえば、モバイル・アプリケーションがユーザー・エージェントMyApp/Shopping/v1.3を使用してWebページにアクセスできる場合、規則を使用すると、モバイル・アプリケーションがShopping、クライアント・バージョンがShopping 1.3とレポートされるようにできます。
入力値: MyApp/Shopping/v1.3
検索式: %/%/v%
クライアント・ブラウザ: %2
クライアント・ブラウザ・バージョン: %2~%3
例7-9 クライアント・デバイスのルール・リング
クライアント・デバイスで規則指定を使用すると、デバイス・トラフィックからのトラフィックに基づいてモバイル・アプリケーションを分離できます。 たとえば、モバイル・アプリケーションは、ユーザー・エージェントMozilla/CFNetwork/Darwin/15.0.0'を使用してWebページにアクセスします。ルールを使用すると、モバイル・アプリケーションを'mobile'として、クライアント・デバイス・ブランドを'CFNetwork'としてレポートし、クライアント・デバイス・モデルが'Darwin'としてレポートできます。
値の入力: Mozilla/CFNetwork/Darwin/15.0.0
検索expression:%/CFNetwork/%/%
クライアント・デバイス: モバイル
クライアント・デバイス・ブランド: CFNetwork
クライアント・デバイス・モデル:%2
例7-10 ルール内のページ・グループの識別
ページ・ネーミング・スキームで規則指定機能を使用するとき、ページ・ネーミング・スキームのソースにページ・グループが含まれる場合は、グループ値が正しく識別されるようにする必要があります。 ソースがmyhost.com/myshop/menswear/catalog/basket.jspというURLページ・ネーミング・スキーム(URLを除く)の場合、内部ではmyshop\%7Cmenswear/catalogという構文に変換されます。 その後、正しくレポートされるために次のように変換される必要があります。
入力値: myshop|menswear/catalog
検索式: %|%/%
ページ・グループ: %1
ページ名: %2
検索式で、グループとページ名の間の区切り文字のパイプ文字(|)をエンコードする必要はありません。 URL構文内のスラッシュ記号は規則指定で使用できることに注意してください。 規則指定の後で、一致したスラッシュは、レポートされるグループと名前においては空白に置き換えられます。
例7-11 検索の構成
URL一致規則には、パラメータの他に、表7-4に示す要素も使用できます。
表7-4 拡張検索の構文
| 使用方法 | 説明 |
|---|---|
|
ゼロ個以上の文字に一致し、1つのプレースホルダに入力します。 使用できるプレースホルダは%1から%9です。 |
|
URL引数内に指定した名前のいずれかに一致する1つの値を検索し、元のプレースホルダの1つと一致後のプレースホルダの1つに入力します。 |
|
URL引数内に指定した名前に一致するすべての値を検索し、元のプレースホルダの1つのパラメータ・プレースホルダと、指定した数のプレースホルダの1つのパラメータ・プレースホルダに入力します。 |
|
URL引数内に指定した名前に一致するゼロ個以上の値を検索し、元のプレースホルダの1つと指定した数のプレースホルダの1つに入力します。 |
|
指定した数の文字を検索します。 |
|
URLのディレクトリ・パスを検索し、1つのプレースホルダに入力します。 |
|
URLのファイル名パス(ファイル拡張子は除く)を検索し、1つのプレースホルダに入力します。 |
|
URLのドメイン部分を検索し、3つのプレースホルダに入力します(たとえば |
|
後続の文字の1つが一致するまで一致を試行し、1つのプレースホルダに入力します。 |
|
指定したリストの文字に一致しない文字が見つかるまで一致を試行します。 |
|
指定された |
特殊文字(%、\、|、!、~)が文字どおりに解釈されるようにするには、前にバックスラッシュを付ける必要があります。 たとえば、\%は、パラメータではなく、%文字そのものを示します。 また、%文字の後の特殊文字(^、&、[、])もエスケープする必要があります。 指定できるプレースホルダは最大9つまでであることに注意してください。
例7-12 複数のURLパラメータの一致
複数のURLパラメータを一致する場合、1つのセットの大カッコ内に定義することを強くお薦めします。 たとえば、%[!parm1!parm2]などです。 %[!parm1]%[!parm2]を指定できますが、定義される同じ順序で表示される場合に指定した引数のみ一致するので注意してください。 文字列/example/path/file.htmlを考えてみます。 使用可能な一致スキームを表7-5に示します。
表7-5 複数のURLパラメータの一致
| 定義 | 一致した結果 |
|---|---|
|
|
|
|
例7-13
検索値: %[h]/%/%/%/%?%
ページ・グループ: %6 (electronics)
ページ名: %7 (tv821)
URL (チェック用): www.mydomain.co.uk/shop/catalog/electronics/tv821?params=all
検索値: %[h]/%[&shop_cat]
ページ・グループ: %2 (pcShop)
ページ名: %5 (Cables)
URL (チェック用): www.pcShop.com/home/applications/catalog?cust_id=123&shop_cat=Cables
検索値: %[h]/cart:%[c9]/articleid:%[c9]/%
ページ・グループ: %4 (00000ABCD)
ページ名: %5 (000018201)
URL (チェック用): www.myshop.com/cart:00000ABCD/articleid:000018201/shop.jsp?params=all
ページのうち、そのURL定義によりアプリケーションに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません(デフォルト)。 ただし、そのような未分類のページをデータ・ブラウザ・グループでレポートする場合は、図7-18に示すアプリケーション概要内のページセクションにある未分類のページのレポートチェック・ボックスを使用します。
ページの識別は、時間ベースのアクティビティであるため、オブジェクトとして予約されていないオブジェクトへの参照は、未分類のページであるとして、誤って識別される場合があります。 このため、未分類のページのレポート作成は、テスト目的でのみ有効にすることをお薦めします。 その後、これを再度無効にし、識別された問題のあるページを手動で定義できます。 未分類のページは、対応するデータ・ブラウザ・グループ内のカテゴリその他にレポートされることに注意してください。
監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。 これについては、「サービス・テスト・セッションのユーザー・フローへの変換」で詳しく説明します。
拡張セクションのサービス・テスト・トラフィックのレポートチェック・ボックスを使用して、選択したアプリケーションのためにOracle Enterprise Managerで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。 デフォルトでは、レポートは行われません。 この機能の使用方法の詳細は、「サービス・テスト・トラフィックのレポート」を参照してください。
有効にすると、サービス・テスト・グループは、監視されるサービス・テスト・ビーコン・トラフィックの情報を提供します。 その構造については、「表W-1」で説明します。
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。 ただし、RUEIシステムをNATサービスの前に配置する場合には、特定のHTTPリクエスト・ヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。 これについては、「NATed Trafficのモニタリング」で詳しく説明しています。
前述のように、RUEI内の各ページは、アプリケーション » グループ » 名前という形式になります。 自動的に検出されたページには、URL内のディレクトリ構造に基づき、グループ名とページ名が割り当てられます。 URL内の第1ディレクトリがグループ名に割り当てられ、残りのサブディレクトリがページ名に割り当てられます。 ドメイン部分は、割り当てられる名前で使用されないことに注意してください。 これは、URLのベース、ディレクトリまたは完全なページ・ネーミング・スキームで定義されたアプリケーションにのみ適用されます。
たとえば、ClothingというアプリケーションのページURL http://MyShop.nl/catalog/menswear/sale.htmlでは、Clothing » catalog » menswear saleというRUEIページ名が生成されます。 ディレクトリ構造内のスラッシュは空白に変換されることに注意してください。
URL内にサブディレクトリがない場合、デフォルト・グループであるhomeがページに割り当てられます。 たとえば、Clothingアプリケーション内のURL http://MyShop.nl/sale.htmlには、clothing » home » saleというページ名が割り当てられます。
アプリケーションの定義後に、アプリケーションに関連するページ・ネーミング・スキームを変更するには、この項で前述したように、アプリケーションをクリックして新規スキームを選択します。
識別セクションで、新規フィルタの追加をクリックして、アプリケーションと関連付ける必要のあるページの追加フィルタを指定します。 また、既存のフィルタ定義を変更するには、それをクリックします。 いずれの場合にも、図7-2に示したフィルタの中から選択できます。 ユーザーによる追加または変更を反映するようにアプリケーション概要が更新されます。
セッションでアプリケーション・ページを表示している際のユーザー・エクスペリエンスを評価するために、RUEIではページごとに満足度レベルが割り当てられます。 これを表7-6に示します。
表7-6 ページ・ロード満足度のレベル
| レベル | 説明 |
|---|---|
適切 |
ページは、満足のページ・ロードしきい値の期間内でユーザー・ブラウザにロードされます。 デフォルトでは、これは4秒です。 |
OK |
ページは、OKのしきい値の期間内でユーザー・ブラウザにロードされます。 デフォルトでは、これは16秒です。 |
良くない |
ページのロードは、劣悪のしきい値より長くかかります。 |
ページ・ロード満足度のレポートの例を図7-19に示します。
前述のように、この評価は、ページのロードの完了までに通常想定されるしきい値に基づきます。 このしきい値を変更して、レポートされるページ・ロード満足度を調整することができます。 次を実行します。
図7-20 ページ・ロードの満足度しきい値の編集ダイアログ
図7-21 デフォルトのページ・ロードの満足度しきい値の編集ダイアログ
図7-22 満足度例外の追加ダイアログ
次に、保存をクリックします。 指定した変更は、即座に有効になります。
例7-14 ページとオブジェクトのロードの満足度のレポート方法の理解
ページ・ロード満足度はユーザーのブラウザでページのロードに要する時間に基づいていますが、オブジェクト・ロード満足度はオブジェクトのエンドツーエンド時間の合計に基づいています。 オブジェクト・ロード満足度では、デフォルトのアプリケーション・ページ・ロードしきい値を使用し、定義されている例外は無視します。
「問題分析グループ」で説明されているように、エンド・ツー・エンド時間が2秒未満のオブジェクトは遅いURLとは見なされません。 2秒を超える場合、URLロード満足度はデフォルトのアプリケーション・ページ・ロードしきい値に基づき、定義されている例外は無視します。
RUEIでは、ユーザーがアプリケーションからログアウトしても、自動的にセッションの終了とはみなされません。 かわりに、セッションのアイドル・タイムアウト(デフォルトでは60分)に達すると、ユーザー・セッションの終了と判断されます。 これは、ユーザーがログアウトした際に、アプリケーションによりユーザーのセッションが終了されず、ユーザーがそのアプリケーションに再度ログインした場合、RUEIでは、アプリケーションのログアウトが検出されず、2つのアプリケーション・セッションが同じユーザー・セッションの一部としてレポートされることを意味します。
これがレポート要件として適切でない場合は、そのページに到達すると、自動的に現在のユーザー・セッションの終了とみなされるアプリケーション・イベントを定義できます。 通常、これはログアウト・ページおよびイベントになります。 後続のユーザー・アクションは、新しいユーザー・セッションの一部とみなされてレポートされます。
アプリケーションのログアウト・イベントを定義するには:
ページ内に表示される文字列を検出し、アプリケーション通知("注文が正常に処理されました"など)またはアプリケーション・エラー("サーバーへのネットワーク接続に失敗しました"など)のいずれかとしてレポートする必要が生じる場合があります。
コンテンツ・メッセージのチェックと、システム・エラーおよびページ・コンテンツのチェック
コンテンツ・メッセージは、リターン・コードではなくページ・コンテンツに基づき、選択したアプリケーションに固有であるため、システム・エラー(Webサーバー・エラーまたはネットワーク・エラー)とは異なります。
指定したメッセージ文字列は、選択したアプリケーション内のすべてのページを対象として検索されることに注意してください。 ページ・コンテンツ・チェックが行われるため(「ページ・コンテンツ・チェックの指定」で説明)、検索は特定のページに制限できません。
アプリケーション・コンテンツ・メッセージおよびページ・コンテンツ・メッセージはページベースです。 サービスの場合、それらはコール(つまりヒット)固有です。 したがって、ページベースのグループのみでレポートされ、(URLベースの)診断グループではレポートされません。
コンテンツ・メッセージのレポート
個々のコンテンツ・メッセージは、通知またはエラーとして指定できます。 いずれの場合も、ページ配信ディメンションでレポートされます。
指定した通知文字列と一致するものとして表示されるページ・テキストは、ページ・コンテンツの結果である通知文字列: 通知検索文字列とともにレポートされ、エラーの場合はエラー文字列: エラー検索文字列としてレポートされます。 コンテンツ・エラーのレポートの例を図7-24に示します。
コンテンツ・メッセージの定義
コンテンツ・メッセージの文字列を定義する手順は、次のとおりです。
構成を選択し、アプリケーション、スイートまたはサービスを選択して、目的のアプリケーションを選択します。 (図7-5に示すような)アプリケーション概要が表示されます。
コンテンツ・メッセージタブ→コンテンツ・メッセージの順にクリックします。 現在定義されているコンテンツ・メッセージが表示されます。 新規コンテンツ・メッセージの追加をクリックして新しいメッセージを定義するか、または既存のものをクリックして変更します。 図7-25に示すダイアログが表示されます。
図7-25 コンテンツ・メッセージの追加
検索タイプメニューを使用して、検索範囲を指定します。 検索の場所として、リクエスト・ヘッダー、応答ヘッダー、リクエスト・コンテンツ、応答コンテンツまたはURLを指定できます。 検索タイプは、XPathまたはリテラルです。 XPathの問合せの使用方法の詳細は、「XPath問合せの操作」を参照してください。
リクエスト・ヘッダーまたはレスポンス・ヘッダーを指定する場合、検索するヘッダーを指定できます。 このフィールドを空白のままにすると、完全なヘッダー・コンテンツが自動的に入力されます。
URLを指定する場合、URL部分に追加的にレポートされるURL引数を指定できます。
ワイルドカードの使用はサポートされておらず、指定するすべての文字がリテラルとして扱われます。
次に、保存をクリックします。 変更は5分以内に有効になります。 XPathベースまたはヘッダーのコンテンツ・メッセージを作成すると、規則指定機能を使用してメッセージの仕様を微調整できます。 これについては、「規則指定機能の使用方法」で詳しく説明します。
コンテンツ・メッセージのリストのインポート
監視対象とする各メッセージを個別に定義するかわりに、事前定義済アプリケーション・メッセージのリストを含むファイルをインポートできます。 次を実行します。
図7-26 コンテンツ・メッセージのアップロードダイアログ
必要に応じて、一意のメッセージ文字列それぞれに対して一連の説明を定義することもできます。 たとえば、「表7-7」に表示されるOracle databaseメッセージの翻訳を定義できます。
表7-7 メッセージ文字列の翻訳例
| 文字列 | 変換 |
|---|---|
|
DDLロックの取得が試行されましたが、すでにロックされています。 |
|
一時表の数が一時表ロックの数以上です。 |
|
マウントされているデータベースのDB_BLOCK_SIZE初期化パラメータが違います。 |
|
DB_FILES初期化パラメータの値が超過されました。 |
|
ユーザー・フローがリソースの待機中に互いにデッドロックしました。 |
|
起動中の共有インスタンスがDMLロックを使用しており、実行中のインスタンスがDMLロックを使用していません(あるいは、その逆の状態)。 |
|
インスタンスがDML_LOCKS = 0で起動されたが、実行中の文では全表ロック(S、XまたはSSX)が必要です。 |
|
指定されたログ・ファイルの数が、このリリースでサポートされているログ・ファイルの最大数を超えました。 |
メッセージの説明を定義する手順は、次のとおりです。
適切なアプリケーションまたはスイートを選択したら、コンテンツ・メッセージタブ→メッセージ指定タブの順にクリックします。 現在定義されているメッセージの説明が表示されます。 新規指定の追加をクリックして新しい説明を定義するか、または既存のものをクリックして変更します。 図7-27に示すダイアログが表示されます。
必要なソース値と、必要に応じて説明を指定します。 次に、保存をクリックします。
メッセージ・タイプメニューを使用して、メッセージをエラー(デフォルト)または通知のいずれとしてレポートするかを指定します。 次に、保存をクリックします。
前述の例では、これは次のようにレポートされます。
error code ORA-00056: An attempt was made to acquire a DDL lock that is already locked.
非常に多くの説明がある場合は、検索フィールドを使用すると目的の説明をすぐに見つけることができることに注意してください。 検索機能では部分一致が使用されます。 ワイルドカードの使用はサポートされておらず、すべての文字がリテラルとして扱われます。 次に、実行をクリックします。
説明のリストのインポート
各説明を個別に定義するかわりに、説明のリストを含むファイルをインポートできます。 次を実行します。
コンテンツに関連のないエラー(つまり、Webサイト、ネットワークまたはサーバーのエラー)と一緒にコンテンツ・メッセージがレポートされると非常に便利です。 トラブルシューティングを促進するためにエラーのコンテキストに関する追加情報の提供が可能になります。 ただし、これはレポートのデフォルトの動作ではありません。
「ページ配信ディメンション」で説明されているように、ページでいくつかのタイプのエラー(たとえば、サーバー・エラーとネットワーク・エラーの両方)が発生した場合、ページ・エラーは複数回レポートされません。 かわりに、次の優先度に基づいてレポートされます: webサイト、サーバー、ネットワークおよびコンテンツ。
コンテンツに関連のないエラーが追加情報と一緒にレポートされるように指定する手順は、次のとおりです。
拡張ページ配信の詳細の例を図7-30に示します。
RUEIでは、新たに作成されるアプリケーションは、ユーザー識別がHTTP認可フィールドとSSLクライアント証明書の共通名(CN)部分(使用可能な場合)に基づくように自動的に構成されます。 これは、図7-31に示されています。
ただし、URL、cookie、リクエスト・ヘッダー、レスポンス・ヘッダー、XPath式、カスタム・タグまたはレスポンス、OAMユーザー・トラッキング(「OAM 10gベース・トラフィックのモニタリング」)に関して、アプリケーション・ユーザー識別スキームを構成することもできます。 HTTP認可フィールドは構成される他の値よりも優先されること、SSL証明書は代替スキームであることに注意してください。 構成されたユーザーIDが監視対象トラフィックで検出されたものと一致しない場合、そのユーザーIDは"(値なし)"としてレポートされます。 RUEIで値のないアイテムのレポートの詳細は、「データ・アイテムのサマリー」を参照してください。
アプリケーションのユーザー識別スキームの構成
アプリケーションのユーザー識別スキームを構成する手順は、次のとおりです。
注意:
ユーザー識別を定義した結果は、ユーザー情報(XLS形式)レポートのクライアントカテゴリで確認できます。 レポートの詳細は、「レポートの操作」を参照してください。
例7-15 National Language Support
国際キャラクタ・セットを処理する場合の識別情報に関する影響の詳細は、「各国語サポートの使用」を参照してください。
デフォルトで新規作成されたアプリケーションおよびサービスでは、ローカライゼーション・ソースが構成されません。 ただし、URL、Cookie、リクエストあるいはレスポンス・ヘッダー、XPath式、またはカスタム・タグあるいはレスポンスに関して、アプリケーションのローカライゼーション(テリトリおよび言語)ソースを構成できます。
アプリケーションのローカライゼーション・ソースの構成
アプリケーションのローカライゼーション・ソースを構成するには、次の手順を実行します。
図7-33 ローカライゼーションの構成
アプリケーションで検出されたページの構造は、ウィンドウの左側にあるアプリケーション概要に表示されます。 例を図7-34に示します。
図7-34 アプリケーション・ページ構造の例
アプリケーションには、非常に多くのページが関連付けられている可能性があります。 実際、図7-34に示す構造では、簡単には確認できないほど多くのページが関連付けられています。 このため、この構造のビューは、Point of Interest(POI)を持つページに制限されています。 したがって、レポートに含まれているページ、キー・ページとして定義されているページ、手動で名前が設定されたページ、監視対象KPIの一部であるページなどが表示されます。 図7-35に示す表示メニューでは、構造概要に表示するページのタイプを制御できます。
図7-35 表示メニュー
表7-8に示すオプションがあります。
図7-8 表示メニュー・オプション
| オプション | 説明 |
|---|---|
すべて |
すべてのアプリケーション・ページをリストします。 |
レポート・ページ |
レポート・フィルタとして指定されているページのみをリストします(「レポート・フィルタの使用」を参照)。 |
チェックしたページ |
コンテンツ・チェックが定義されているページのみをリストします(「ページ・コンテンツ・チェックの指定」を参照)。 |
手動で名付けられたページ |
手動で定義されたページのみリストします(「ページの手動識別」 ")を参照)。 |
キー・ページ |
キー・ページとして定義されているページのみをリストします(「トラッキング・ページの使用方法」を参照)。 |
アプリケーション・ページ・カテゴリをドリルダウンすると、特定のページに移動できます。 ただし、多数のページを含むアプリケーションの使用時は、ページ検索機能を使用した方が便利な場合があります。 次を実行します。
アプリケーションで検出された各ページに関する情報は、ページ分析ウィンドウで確認できます。 例を図7-37に示します。
このウィンドウには次のタブがあります。
識別: ページ識別スキーム(手動または自動)と、識別に使用する条件を指定します。
コンテンツ・チェック: コンテンツ検索文字列がページに定義されているかどうかを指定します。 これについては、「ページ・コンテンツ・チェックの指定」で説明しています。
レポート: このページを含むレポートをリストします。 レポートについては、「レポートの操作」で説明します。
監視: このページを含むKPIをリストします。 KPIの定義手順に関する詳細を参照してください。
図7-37のキー・ページチェック・ボックスを使用して、ページをキー・ページとして定義します。
キー・ページは、監視対象のうち、特に注目するWebページです。 通常、これは特に重要なページです。 たとえば、組織のホームページや、注文入力などのユーザー・フロー内の一連のページなどがあります。 これらのページに関しては、追加情報が記録されます。 追加情報には、クライアント情報(ISP、アクセス元の国など)やクライアントのブラウザ情報(オペレーティング・システム、ブラウザ・バージョンなど)があります。
特定のページに特定のテキスト文字列が出現するかどうかの監視が必要となる場合があります。 たとえば、Webアプリケーションに注文ページがあり、販売に成功した後、"ご購入ありがとうございました"というテキスト文字列がこのページに表示されるとします。 目的のページにこの文字列があるかどうかを検索するページ・コンテンツ・チェックを定義できます。 指定したテキスト文字列がそのページで見つからない場合、ページ・ビューは失敗したページとしてレポートされることに注意してください。
ページ・コンテンツ・チェックのレポート
成功したページとしてレポートされるためには、ページに対して指定したすべての文字列がページ・ビュー内で見つかる必要があることに注意してください。 それ以外は失敗したページ・ビューとしてレポートされます。 また、コンテンツ・メッセージ(「アプリケーション・コンテンツ・メッセージのトラップ」)の一致は、ページ・コンテンツ・チェックの前に行われます。 したがって、ページ・コンテンツ・チェックでは失敗したページとしてレポートするように示しても、ページ・ビューは通知(つまり、成功)としてレポートされることがあります。
ページ・コンテンツ・チェックの定義
ページ・コンテンツ・チェックを定義する手順は、次のとおりです。
図7-38 ページ・コンテンツ・チェックの追加
アプリケーション全体のページを識別できるのみでなく、ページを手動で定義することもできます。 手動で識別されたページは、アプリケーションによって自動的に識別されたページより優先されることに注意してください。 この機能は、自動的には識別できないサブページに、別の名前を割り当てる場合に便利です。 手動で識別されるページは、新規ページのベースとなる既存のページを選択して作成します。
ページが手動で識別されるようにするには、新規のページを最初から定義するか、既存のページ(自動で検出または手動で定義されたページ)を新規ページのベースとして使用します。
ページを定義する手順は、次のとおりです。
注意:
目的のページがアプリケーション概要に表示されず、選択できない場合は、「検索」ボタン(「ページ詳細の検索」を参照)を使用して検索します。
URL診断グループ(「問題分析のURL診断」で説明)を使用すると、URLsがアプリケーションのヒットについてレポートした機能URLsを表示できます。 これらは、特定の要件に合せてアプリケーション・レベルでカスタマイズできます。
URL診断を使用すると、アプリケーションの問題の把握に役立ちます。 たとえば、特定のアプリケーションでロード時間が異常に長くかかる場合に、問題がある特定のオブジェクトまたは原因となっているサーバーをすぐに識別できます。 さらに、セッション診断機能と組み合せると(「セッション診断の概要」を参照)、この機能によってアプリケーションの問題の非常に強力な根本原因分析が提供されます。
選択したアプリケーションで使用するURL診断レポート・スキームを指定する手順は、次のとおりです。
例7-16 除外されるURL情報
強制オブジェクト(「ページとしてのオブジェクトのレポートの制御」)は、レポートされるURLsから自動的に削除されます。 この他に、セッション・パラメータおよび静的オブジェクト(イメージなど)のレポートを除外するように、アプリケーション定義を構成することをお薦めします。 こうすることで、診断情報が長くなりすぎて切り捨てられることを防ぎます。
セッション診断の再生機能で表示されるアプリケーション・ページは、インラインJavaScriptコードを含む可能性があります。 通常、このコードはチェックを実行するために使用されます。 たとえば、指定されたサーバーに接続して、セッションが期限切れになったかどうかを判別します。 このようなチェックおよびJavaScriptの他の機能は、関連するページを再生機能で表示するときに問題になることがあります。
このため、アプリケーション構成機能を使用して、インラインJavaScriptコードの実行をリプレイ・ビューア内で処理する方法(「セッション診断の概要」を参照)を指定できます。 JavaScriptの実行を完全に無効にするか、特定の関数またはファイルをページの再生時に置き換えるように指定できます。
実行規則の定義
アプリケーション・ページの再生時に使用されるJavaScriptの実行規則を定義する手順は、次のとおりです。
図7-44 JavaScript再生規則
図7-45 新規ルールの追加ダイアログ
例7-17 置換ファイルのアップロード
置換のための.jsファイルは、レポータ・システムの/opt/ruei/gui/uploadディレクトリにアップロードされます。 必要であれば、適切な規則を選択して、元のファイルを変更したものをアップロードするかまったく新しいファイルを指定することで、置換ファイルの内容を変更できることに注意してください。 どちらの場合も、元のファイルの内容は新たにアップロードされるファイルで上書きされます。 規則が削除されると、その規則についてアップロードされたファイルも自動的に削除されます。
アプリケーションに複数の規則が含まれ、それらが同じファイルを参照する場合、1つのバージョンのファイルのみがレポータ・ファイル・システムに保持され、そのファイルが常に最新バージョンとしてアップロードされることに注意してください。 そのファイルがファイル・システムから削除されるのは、そのファイルを使用するすべての規則も削除された場合のみです。
同じJavaScriptファイルが複数のアプリケーションで使用されることは頻繁にあります。 アプリケーションに指定される各置換ファイルは一意のファイルを表すことに注意してください。 これは、複数のアプリケーションに対して同じファイル名が指定されるときにも該当します。 たとえば、3つのアプリケーションA、BおよびCのすべてに、置換ファイルmychecks.jsが指定されているとします。 この場合、3つのバージョンのmychecks.jsファイルがRUEIによって管理されます。 いずれか1つのファイルを変更すると、対応するアプリケーションのみに適用され、他のアプリケーションには適用されません。
ホスト名www.load-balancer.comを持つロード・バランシング・サーバーが存在し、www.real-server-1.com、www.real-server-2.comなどのホスト名を持ついくつかの実サーバーがロード・バランシング・サーバーの背後に存在する場合、最初にリクエストがロード・バランサに配置され、その後、実サーバー間で分散されます。
ロード・バランス・サーバーと実サーバーの間にRUEIがデプロイされており、そのホスト名で実サーバーにアクセスできないと仮定します。 また、実サーバーから公開ネットワークへのルートもありません。 このシナリオでは、取得されるすべてのページに、URLs like www.real-server-*.com/が含まれます。
ロード・バランサとWebサーバー間のトラフィックを監視するためにRUEIをデプロイした場合、FSRページに、リプレイ記憶域ページのすべてのオブジェクトが表示されない可能性があります。 これは、リプレイするページの元のURLおよびオブジェクトへのアクセス権を持っていないためです。 この問題を解決するには、正常なページ・リプレイ用のリプレイURLマッピングを定義して、RUEIですべてのオブジェクトがFSRウィンドウに正しく表示されることを確認します。
次に例を示します。
FSRでhttp://www.real-server-1.com/1.htmlページをリプレイする場合、パブリック・ネットワークからwww.real-server-1.comへのルートは発生しません。 それらのページのURLはRUEIによって再書込みされます。 リプレイURLマッピング・ルールのhttp://www.real-server-*.comをhttps://www.load-balance.comに定義できます。
これで、ページ上のすべてのオブジェクトを含め、ページが正常にリプレイされたことを確認できます。 これは、load-balance.comがパブリック・ネットワークで表示されるためです。 これは、リプレイURLのマッピングが成功したことを示します。
このようなリプレイURLマッピングのルールはアプリケーションに基づいています。 各アプリケーションには個別のマッピング・ルールがあります。
アプリケーションのリプレイURLマッピング・ルールを構成するには、次の手順を実行します:
「構成」 > 「アプリケーション」に移動し、必要なアプリケーションを選択します。
図7-46 「リプレイURLマッピング」タブ
図7-47 新規ルールの追加
「ソースURLパターン」と「ターゲットURL」を入力します。
保存をクリックします。
注意:
ソースおよび宛先のURLには、http、httpsなどのURLスキームを含める必要があります。
ソースURLには、URLのホスト名文字列にワイルドカードを使用できます。 ただし、ターゲットURLにワイルドカードは使用できません。
リッチ・フレームワーク(Ajaxなど)を使用するアプリケーションの場合は、アクション・ネーミング・スキームを指定できます。 これは、特定のページで実行される対話型のユーザー・アクションの内容を把握する場合に特に便利です。 たとえば、ユーザーがオンライン・カタログ・ページを表示している状況で、買い物かごに入れるというアクションをクリックしたときを把握する場合などです。
アクションに関する情報は、すべてのページおよび問題分析(失敗したページなど)のグループのアクションビューから参照できます。 セッション診断機能内でも表示できます。 例を図7-48に示します。
アクション・ネーミング・スキームを定義するには、次の手順を実行します。
エンリッチ・データ交換機能を使用すると、RUEIで収集されたデータを他のデータ・ソースと組み合せることができます。 この機能の使用方法の詳細は、「エンリッチ・データのエクスポート機能」を参照してください。
エンリッチ・データ交換は、次の方法で個々のアプリケーションに対して有効または無効にできます:
「構成」、「アプリケーション」、変更するアプリケーションの順に選択します。
「詳細」タブ、「エンリッチ済」 「データ」 「交換」サブタブの順に選択します。
「エンリッチ済」 「データ」 「交換」およびKPI 「データ」 「交換」を有効化または無効化するかどうかを選択します。
監査データは、すべてのアプリケーションに行われた変更を記録するために保持されます。 監査データには、ユーザー名、IPアドレスおよび変更イベントの時間が表示されます。 例を図7-49に示します
図7-49 監査データ・サンプル
監査データは次の方法でチェックできます:
「構成」、「アプリケーション」、チェックするアプリケーションの順に選択します。
「詳細」タブ、「監査」サブタブの順に選択します。
シングル・サインオン(SSO)とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。 アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。 SSOには次の利点があります。
ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。
同じIDに対するパスワードの再入力に要する時間を省きます。
ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。
SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。
SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。 このためには、SSOプロファイルを作成します。
SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。 次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。 図7-50に、アプリケーション認証がSSOサーバーで有効化されている場合に機能する仕組みを示します。
図7-50 SSO対応アプリケーション・トラフィック内の認証フロー
図7-50に示す認証フローは、次の順序を取ります。
最後に、ステップ1、2および5で使用されるネットワーク回線は、RUEIの監視対象トラフィックの有効範囲内である必要があることに注意してください。
例7-18 SSOプロファイルとアプリケーション
SSOプロファイルとSSOアプリケーションは、密接に関連していますが、RUEI内では独立したエンティティとしてレポートされることを理解しておく必要があります。 このため、SSOプロファイルとSSOアプリケーションの定義は、相互排他的にする必要があります。 つまり、それぞれが独自のドメインおよびCookieに基づく必要があります。 こうしておかないと、監視対象トラフィックはアプリケーション関連トラフィックとしてレポートされ、拡張レポート作成による利点は得られません。
SSOプロファイルを定義する手順は、次のとおりです。
注意:
SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。 こうしておかないと、予期しない結果がもたらされる可能性があります。 一致ルールが適用される順序を変更できる方法は、「RUEI内でのルール順序設定の制御」を参照してください。
最高レベルのフィルタはドメインです。 ドメインを変更または微調整するには、URLの部分を指定します。
プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。 つまり、空白フィルタは使用できません。 ワイルドカード文字(*)はポートの検索フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、SSOプロファイルは関連付けられないことに注意してください。 指定できるポート番号は1つのみです。 追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。 ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。 フィルタの適用順序を制御する方法は、「RUEI内でのルール順序設定の制御」を参照してください。
準備ができたら、次へをクリックします。 図7-52に示すダイアログが表示されます。
次に、終了をクリックします。 指定したSSOプロファイル定義の概要が表示されます。 例を図7-53に示します。
この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。 この詳細は次の項に記載されています。
ユーザー識別を定義した結果は、ユーザー情報(XLS形式)レポートのクライアントカテゴリで確認できます。 レポートの詳細は、「レポートの操作」を参照してください。
SSOプロファイルを定義後に変更するには、その概要を使用します。 以下のタブを使用することができます。
識別: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。 ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。 新規フィルタを追加するには、新規フィルタの追加をクリックします。 既存のフィルタを変更するには、そのフィルタをクリックします。 図7-54に示すようなダイアログが表示されます。
図7-54 SSOプロファイル・フィルタの編集ダイアログ
ダイアログの最下部にあるメモは、現在のルール順序設定スキームを示します。 これについては、「RUEI内でのルール順序設定の制御」で説明しています。
構成: 使用される認証トークンとCookieを指定します。
ユーザー: ユーザーIDをアプリケーション内で識別する方法を指定します。 これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。
RUEIのデプロイメントで監視中のトラフィックが正しく識別されていることを確認するために、定期的に確認することを強くお薦めします。 そのためには、構成メニューから統計の表示を選択します。 図7-55に示すダイアログが表示されます。
図7-55 構成統計
未確認のヒットやページが予想以上に多い場合は、ページの識別定義を確認する必要があります。 これについては、「ページのネーミング」で説明しています。 セッション識別のないページ・ビューが予想以上に多い場合は、ユーザーの識別定義を確認する必要があります。 これについては、「ユーザー識別の定義」で説明しています。
ビジネス・クリティカルなサービスに対して最上位レベルの可用性およびパフォーマンスを維持するため、Oracle Enterprise Managerを構成してサービス・テストを監視できます。 Oracle Enterprise Managerのサービス・テストはビーコンから実行されます。Oracle Enterprise Managerは、エンドユーザーの観点からサービスを監視し、ベースのITインフラストラクチャとサービスの相関関係も監視します。 通常、ビーコンは、通常のアプリケーション使用に相当するユーザー・フローを実行するように設定されます。Oracle Enterprise Managerは、ユーザー・フローのレスポンス時間を各構成部分に細分化して分析します。 ビーコンおよびサービス・テストを定義する手順の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』に記載されています。
RUEI内のサービス・テスト機能は、比較可能なリアル・ユーザー・トラフィックに対するこの統合トラフィックの結果の検証を許可して、Oracle Enterprise Managerサービス・テストを補完します。 たとえば、サービス・テストがアプリケーションの特定項目の問題をレポートする場合、この機能を使用して、同じ期間中にこの問題がリアル・ユーザー・トラフィックでも確認されるかどうかを判別できます。 この方法で、エラーの多いインシデントをすぐに識別および無視でき、実際のユーザーのレポートされた問題の影響をすぐに評価できます。
RUEI内では、特定のアプリケーションおよびスイートのサービス・テスト・トラフィックを監視でき、検出されるとサービス・テストグループでレポートできます。 また、監視対象のサービス・テストに関する診断情報をサービス・テスト診断機能で表示することもできます。 アプリケーションまたはスイートを構成してサービス・テスト・トラフィックを検出するには、次の手順を実行します。
