Oracle® Real User Experience Insight

ユーザーズ・ガイド

12c リリース6 (12.1.0.7) for Linux x86-64

E61771-02(原本部品番号:E56522-02)

2015年4月

Oracle Real User Experience Insightユーザーズ・ガイド, 12c リリース6 (12.1.0.7) for Linux x86-64

E61771-02

Copyright © 2012, 2015 Oracle and/or its affiliates.All rights reserved.

原本著者: Paul Coghlan

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよびコピーライト情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 用語の更新

- 表記規則

1 スタート・ガイド

- 1.1 RUEIとは

- 1.2 ブラウザの要件

- 1.3 開始前の準備

- 1.4 RUEIの開始

- 1.5 環境のカスタマイズ

- 1.6 セッションの終了

2 レポートの操作

- 2.1 レポート・ライブラリの概要

- 2.2 レポート・ライブラリのカスタマイズ

- 2.3 メーリング機能の使用方法

- 2.4 お気に入り機能の使用方法

- 2.5 レポート・メーリングの管理

- 2.6 カレンダの使用方法

- 2.7 レポート・フィルタの使用方法

- 2.8 レポート要素の概要

- 2.9 レポートされた値の解釈

- 2.10 印刷レイアウト・モードの使用

- 2.10.1 印刷レイアウト・モードを使用したレポートのカスタマイズ

- 2.10.2 値リストの使用

- 2.10.3 値リストの制限

- 2.10.4 比較モードでの操作

- 2.11 新規レポートの作成

- 2.12 PDFへのレポートのエクスポート

- 2.13 レポート・データのエクスポート

3 データ・ブラウザの使用

- 3.1 データ・ブラウザの概要

- 3.2 データ構造の概要

- 3.2.1 リアルタイム・データとセッションベースのデータ

- 3.2.2 問題分析グループ

- 3.2.3 ページ配信ディメンション

- 3.2.4 問題分析のためのURL診断

- 3.2.5 問題分析のためのスイートURL診断

- 3.3 データ・ブラウザ・グループへのアクセス

- 3.4 値リストの使用

- 3.5 データ・ブラウザでの検索

- 3.6 階層ビュー

- 3.7 データのソート

- 3.8 データ・ブラウザでの取消しとやり直し

- 3.9 フィルタの使用

- 3.9.1 フィルタの定義

- 3.9.2 複数のフィルタの使用

- 3.9.3 レポート・フィルタの使用方法

- 3.9.4 拡張フィルタの使用

- 3.10 異なる期間を対象とするデータの比較

- 3.11 データのエクスポート

- 3.11.1 エクスポートするデータの変更

- 3.11.2 エクスポート書式の選択

- 3.12 カスタム・ディメンションの使用

- 3.12.1 カスタム・ディメンションの削除

- 3.13 ブラウザ・ビューのカスタマイズ

4 セッション診断機能の使用

- 4.1 概要

- 4.2 ユーザー・セッションの再生

- 4.3 Microsoft Excelへのセッション・ページのエクスポート

- 4.4 すべてのセッション情報のエクスポート

- 4.5 セッション診断におけるディメンション・リストの制御

- 4.6 外部ツールへのクリックアウトの構成

- 4.7 ビジネス・アプリケーションの監視

5 ダッシュボードの使用

- 5.1 概要

- 5.2 新規ダッシュボードの作成

- 5.3 ダッシュボードの内容の変更

- 5.4 データ・アクセス・フィルタの使用

- 5.5 ダッシュボードへのデータ・ブラウザまたはKPIビューの追加

- 5.6 パブリック・テンプレートの作成

- 5.7 テンプレートのプロパティと内容の変更

- 5.8 ユーザー・ダッシュボードに基づいたテンプレートの作成

- 5.9 テンプレートの公開

- 5.10 テンプレート項目の公開

6 KPI概要およびアラート・リストの使用

- 6.1 KPI概要

- 6.1.1 KPI概要の表示

- 6.1.2 表示形式

- 6.1.3 ズーム・インおよびズーム・アウト

- 6.1.4 KPIおよびターゲット

- 6.1.5 不完全なデータの使用

- 6.1.6 概要のドリルダウン

- 6.1.7 アラート・ログの使用

- 6.2 KPIの変動の比較

- 6.3 アラート・リストの使用

- 6.3.1 アラートのフィルタリング

- 6.3.2 アラートの表示

7 パフォーマンスの監視の設定

- 7.1 概要

- 7.2 KPIおよびSLAの定義

- 7.2.1 KPIへの条件の適用

- 7.2.2 KPIへのターゲット値の適用

- 7.2.3 KPIへの前提条件の適用

- 7.2.4 KPIへのサービス・レベル合意の適用

- 7.2.5 KPIへのアラート・スケジュールの適用

- 7.3 既存のKPIの変更

- 7.3.1 既存のKPIのコピー

- 7.3.2 KPIの計算範囲について

- 7.3.3 自動ターゲットおよび固定ターゲット

- 7.4 サービス・レベル・スケジュールの定義

- 7.5 アラート・スケジュールの定義

- 7.5.1 アラート・プロファイル

- 7.5.2 エスカレーション手順

- 7.5.3 測定および通知間隔

- 7.5.4 アラート・メッセージのテスト

- 7.5.5 メール通知の使用方法

- 7.5.6 SNMP通知の使用方法

- 7.5.7 テキスト・メッセージ通知の使用方法

8 Webページの識別とレポート作成

- 8.1 ページのネーミング

- 8.2 タグ・ベースのアプリケーション

- 8.3 アプリケーションの定義

- 8.3.1 ブラウザJSライブラリ設定の定義

- 8.3.2 ページ・ネーミング翻訳の適用

- 8.3.3 アクション翻訳の適用

- 8.3.4 詳細設定の使用によるページとオブジェクトの処理の制御

- 8.3.5 規則指定機能の使用方法

- 8.3.6 未分類のページのレポート作成

- 8.3.7 サービス・テスト・ビーコン・トラフィックのレポート

- 8.3.8 クライアントIPアドレスの取得

- 8.3.9 ページ・ネーミングの自動割当て

- 8.3.10 アプリケーション定義の微調整

- 8.3.11 ページ・ロードの満足度の指定

- 8.3.12 ログアウト・イベントの定義

- 8.3.13 アプリケーション・コンテンツ・メッセージのトラップ

- 8.3.14 ユーザー識別の定義

- 8.3.15 ローカライゼーション・ソースの定義

- 8.3.16 アプリケーション・ページ構造の表示

- 8.3.17 ページ詳細の検索

- 8.3.18 ページの使用状況の追跡

- 8.3.19 ページ・コンテンツ・チェックの指定

- 8.3.20 ページの手動識別

- 8.3.21 問題分析グループ内のレポートの制御

- 8.3.22 JavaScript再生実行の制御

- 8.3.23 アクション・ネーミング・スキームの定義

- 8.4 シングル・サインオン(SSO)プロファイルの定義

- 8.4.1 SSO対応トラフィックの監視方法の概要

- 8.4.2 SSOプロファイルの作成

- 8.4.3 SSOプロファイルの変更

- 8.4.4 SSO構成の検証

- 8.5 アプリケーションとセッション・トラッキング定義の検証

- 8.6 サービス・テスト・トラフィックのレポート

- 8.6.1 RUEI内のサービス・テスト監視の構成

9 ユーザー・フローの使用

- 9.1 ユーザー・フローの概要

- 9.2 ユーザー・フローの定義

- 9.3 ユーザー・フローの変更

- 9.4 ユーザー・フローのコピー

- 9.5 デフォルトのステップ・アイドル時間の指定

- 9.6 ユーザー・フローへの通貨価値の割当て

- 9.7 ユーザー・フローのレポート方法の概要

- 9.8 サービス・テスト・セッションのユーザー・フローへの変換

10 スイートおよびWebサービスの使用

- 10.1 スイートの使用

- 10.1.1 スイート定義の作成

- 10.1.2 設定ファイルのアップロード

- 10.1.3 スイート定義の変更

- 10.1.4 スイート定義の検証と評価

- 10.2 フレームワーク例外によるアプリケーション定義の微調整

- 10.2.1 URLパターンの評価順序

- 10.2.2 環境間でのフレームワーク例外の移動

- 10.3 Webサービスの定義

- 10.3.1 未分類の関数コールのレポート

- 10.3.2 関数ロードの満足度の指定

- 10.3.3 関数コール・エラーのトラップ

11 OAMおよびSSOベース・トラフィックの監視

- 11.1 OAMベース・トラフィックの監視

- 11.2 シングル・サインオン(SSO)プロファイルの定義

- 11.2.1 SSO対応トラフィックの監視方法の概要

- 11.2.2 SSOプロファイルの作成

- 11.2.3 SSOプロファイルの変更

- 11.2.4 SSO構成の検証

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

- 12.1 トラフィック・サマリーの表示

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

- 12.2.1 JavaScript Cookie生成の実装

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

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

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

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

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

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

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

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

- 12.6 失敗したURLヒットの無視

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13 セキュリティ関連情報の管理

- 13.1 コレクタ・プロファイルの管理

- 13.1.1 コレクタ・プロファイルの作成

- 13.1.2 コレクタ・プロファイルの構成の変更

- 13.1.3 別のプロファイルへのコレクタの割当て

- 13.1.4 インタフェースへのコレクタの割当て

- 13.1.5 新規コレクタの登録

- 13.1.6 コレクタの再起動

- 13.1.7 コレクタの無効化および登録解除

- 13.2 処理エンジンの管理

- 13.3 ネットワーク・ベース監視の有効範囲の管理

- 13.4 ネットワーク・フィルタの定義

- 13.4.1 サーバーIPアドレス・フィルタの定義

- 13.4.2 VLANフィルタの定義

- 13.4.3 全体のトラフィックの制限

- 13.4.4 ロード・バランシングおよびトラフィック・サンプリング定義の確認

- 13.5 SSL鍵の管理

- 13.5.1 SSL鍵の削除

- 13.5.2 鍵の有効期限の監視

- 13.6 ユーザー情報のマスキング

- 13.7 FSRページ・コンテンツのマスキング

- 13.8 SSLクライアント証明書のマスキング

- 13.9 コレクタのデータ保存ポリシーの定義

- 13.10 リプレイ・ポリシーの制御

- 13.11 超特大フレームの監視の制御

- 13.12 RUEIユーザー・セッション・アイドル時間の制御

14 ユーザーと権限の管理

- 14.1 概要

- 14.2 ユーザー・アカウントのロールと権限の概要

- 14.2.1 ユーザー・アカウントのロール

- 14.2.2 ユーザー・アカウントのアクセス・レベル権限

- 14.2.3 システム・アカウント・ロールの権限

- 14.3 新規ユーザーの追加

- 14.4 既存のユーザーの変更

- 14.5 ユーザーの設定の変更

- 14.6 パスワード・セキュリティ・ポリシーの強制

- 14.7 モジュールにおける許可データの有効範囲の管理

- 14.8 LDAPサーバーのユーザー認証の構成

- 14.9 Oracle Single Sign-On(SSO)のユーザー認証の構成

15 システムの監視およびメンテナンス

- 15.1 システムのステータスの監視

- 15.1.1 一時遅延およびアラート

- 15.2 コレクタのステータスの表示

- 15.3 システム障害アラートの構成

- 15.4 データベースおよびディスクの領域制限とアラートの構成

- 15.5 トラフィック・サマリーの表示

- 15.6 構成バックアップの作成とリストア

- 15.7 イベント・ログの使用

- 15.8 テキスト・メッセージ・プロバイダの構成

- 15.9 ヘルプデスク・レポートの作成

- 15.10 セッション・デバッグ・モードの操作

- 15.11 電子メール構成の管理

- 15.12 システムのリセット

- 15.13 データ変換のカスタマイズ

A タグ付け規則

- A.1 ページのタグ付け規則

- A.2 サービスのタグ付け規則

B Cookieの構造

- B.1 URL引数を使用したセッションの追跡

C トラブルシューティング

- C.1 オラクル社のWebサイト

- C.2 Oracleサポート・サービスへの問合せ

- C.3 一般的な(固有でない)問題

- C.4 起動に関する問題

- C.5 レポートされるデータの遅延

- C.6 SNMPアラートに関する問題

- C.7 テキスト・メッセージ・アラートに関する問題

- C.8 タイムゾーンに関する問題

- C.9 データの監視が停止していると思われる状況

- C.10 コレクタがクラッシュするとコア・ダンプが生成されない

- C.11 イベント・ログでの強制コア・ダンプのレポート

- C.12 メモリー割当てエラー

- C.13 同じCookie値を受信する複数のユーザー・セッション

- C.14 データベース・クラッシュ後のオブジェクトのリカバリ

D エラー・コードの説明

- D.1 エラー: website-error

- D.1.1 エラー: website-error » http-bad-request (400)

- D.1.2 エラー: website-error » http-unauthorized (401)

- D.1.3 エラー: website-error » http-payment-req (402)

- D.1.4 エラー: website-error » http-forbidden (403)

- D.1.5 エラー: website-error » http-not-found (404)

- D.1.6 エラー: website-error » http-method-not-allowed (405)

- D.1.7 エラー: website-error » http-not-acceptable (406)

- D.1.8 エラー: website-error » http-proxy-authentication (407)

- D.1.9 エラー: website-error » http-request-timeout (408)

- D.1.10 エラー: website-error » http-conflict (409)

- D.1.11 エラー: website-error » http-gone (410)

- D.1.12 エラー: website-error » http-length-required (411)

- D.1.13 エラー: website-error » http-precondition-failed (412)

- D.1.14 エラー: website-error » http-entity-too-large (413)

- D.1.15 エラー: website-error http-URI-too-long (414)

- D.1.16 エラー: website-error » http-media-not-supp (415)

- D.1.17 エラー: website-error » http-invalid-range (416)

- D.1.18 エラー: website-error » http-expect-failed (417)

- D.2 エラー: server-error

- D.2.1 エラー: server-error » internal-error (500)

- D.2.2 エラー: server-error » not-implemented (501)

- D.2.3 エラー: server-error » dispatch-error (502)

- D.2.4 エラー: server-error » service-unavailable (503)

- D.2.5 エラー: server-error » dispatch-timeout (504)

- D.2.6 エラー: server-error » version-not-supported (505)

- D.3 エラー: no-server-response

- D.4 エラー: network-error

E データ・アイテムの概要

- E.1 データの項目

- E.2 KPIメトリック

- E.3 ディメンション

- E.4 データ収集

- E.4.1 動的コンテンツと静的コンテンツ

- E.4.2 ページとヒットの関連付け

- E.4.3 エンドツーエンド時間、サーバー時間およびネットワーク時間

- E.4.4 ページ・ロード時間とエンドツーエンド時間

- E.4.5 ブラウザ・ロード時間とページ読取り時間

- E.4.6 レポートされるページ・ビュー

- E.4.7 ディメンション・レベルの値

- E.4.8 ネットワーク・トラフィックの圧縮

- E.5 データの集計

F XPath問合せの使用

- F.1 概要

- F.2 名前空間のサポート

- F.3 名前空間の接頭辞およびURLの概要

- F.4 サード・パーティのXPathツールの使用方法

- F.5 XPathスキャンの最適化

- F.6 JSONコンテンツでのXPath

- F.7 xpathtesterユーティリティを使用したXPath式のテスト

G 各国語サポートの使用

- G.1 概要

- G.2 実装に関する考慮事項

- G.3 コンテンツ・チェックの指定

- G.4 URL引数およびコレクタ・エンコーディングの指定

H WebLogic Portal(WLP)のサポート

- H.1 概要

- H.2 WLPスイート定義の作成

- H.3 RUEIとWLP環境の同期化

- H.4 Cookieテクノロジの指定

- H.5 ユーザー認証の構成

- H.6 スイート定義のマッピング

- H.7 データ・アイテム

- H.8 既知の制限事項

I Oracle ADFのサポート

- I.1 概要

- I.2 Oracle ADFスイート定義の作成

- I.3 ADFアプリケーションの監視の有効化

- I.4 Cookieテクノロジの指定

- I.5 ADFのレポート

- I.6 ADFページおよびセッション診断

- I.7 データ・アイテム

J WebCenter

- J.1 WebCenterスイート定義の作成

- J.2 すべてのWebCenter Sitesディメンションのレポートの確認

- J.3 WebCenter Portalアプリケーションの監視の有効化

- J.4 Cookieテクノロジの指定

- J.5 データ・アイテム

K PeopleSoftのサポート

- K.1 概要

- K.2 監視の有効範囲の検証

- K.3 PeopleSoftスイート定義の作成

- K.4 create_PSFT_info.shスクリプトの実行

- K.5 Cookieテクノロジの確認

- K.6 ホスト名およびURL接頭辞

- K.7 データベース表

- K.8 データ・アイテム

- K.9 リソース

- K.10 既知の制限事項

L Siebelのサポート

- L.1 概要

- L.2 Siebelスイート定義の作成

- L.3 Cookieテクノロジの確認

- L.4 ユーザー・ログオンの取得

- L.5 ホスト名およびURL接頭辞

- L.6 セッション

- L.7 アクションとページ

- L.8 関数エラーの認識

- L.9 データ・アイテム

- L.10 Siebelログイン・データの解釈

- L.11 既知の制限事項

M Oracle FLEXCUBEのサポート

- M.1 概要

- M.2 監視の有効範囲の検証

- M.3 Oracle FLEXCUBEスイート定義の作成

- M.4 create_FCUB_info.shおよびcreate_FCDB_info.shスクリプトの実行

- M.5 Cookieテクノロジの確認

- M.6 FCDBポータルの認識

- M.7 ホスト名およびURL接頭辞

- M.8 データベース表

- M.8.1 FCDBのカスタマイズ

- M.8.2 FCUBのカスタマイズ

- M.9 データ・アイテム

- M.10 既知の制限事項

N Oracle FormsおよびOracle E-Business Suiteのサポート

- N.1 概要

- N.2 Formsのみの環境の使用

- N.3 監視の有効範囲の検証

- N.4 EBSスイート定義の作成

- N.5 追跡テクノロジの指定

- N.5.1 カスタムCookieの構成

- N.5.2 EBSからのCookie構成の確認

- N.5.3 RUEIからのCookie構成の確認

- N.5.4 セッションの追跡、相関変数およびセッションURL引数

- N.6 Formsサーバー・モードのタイムアウトの指定

- N.7 RUEIとEBS本番環境の同期化

- N.8 ソケット・モードとサーブレット・モードのチェック

- N.9 ホスト名およびURL接頭辞

- N.10 データベース表

- N.11 アクション、ページおよびオブジェクト

- N.12 関数エラー

- N.13 Forms名のレポート

- N.14 追加メッセージのレポート

- N.15 OAフレームワークでのページ名の推定

- N.16 ページ・コンテキスト

- N.16.1 リクエストとページの境界

- N.17 データ・アイテム

- N.18 リソース

- N.19 既知の制限事項

- N.20 トラブルシューティング

- N.20.1 ネットワーク・トラフィックが測定されていないように見える

- N.20.2 識別されないアクションが多数レポートされる

- N.20.3 Formsのみの環境におけるuser-id識別の構成

- N.20.4 create_EBS_info.plスクリプトでFRM-91500エラーがレポートされる

- N.20.5 PerlのZip機能が使用できない

- N.20.6 frmcmp_batchスクリプトが失敗する

- N.20.7 create_EBS_info.plスクリプトで警告/エラーが生成される

O JD Edwardsのサポート

- O.1 概要

- O.2 監視の有効範囲の検証

- O.3 JD Edwardsスイート定義の作成

- O.4 create_JDE_info.shスクリプトの実行

- O.5 Cookieテクノロジの確認

- O.6 ホスト名およびURL接頭辞

- O.7 データ・アイテム

- O.8 既知の制限事項

P Oracle Fusion Applicationsのサポート

- P.1 概要

- P.2 Oracle Fusion Applicationsスイート定義の作成

- P.3 create_FUS_info.plスクリプトの実行

- P.4 関数エラー

- P.5 データ・アイテム

- P.6 既知の制限事項

Q NATトラフィックの監視

- Q.1 NATデバイスの前への配置

- Q.2 エンドユーザーのIPアドレスの取得

- Q.3 応答するWebサーバーのIPアドレスの取得

R 監視対象ネットワーク・トラフィックの確認

- R.1 概要

- R.2 トラフィックのスナップショットの作成

- R.3 トラフィック情報の分析

S エンリッチ・データのエクスポート機能

- S.1 エンリッチ・データのエクスポート

- S.2 エンリッチ・データ交換のデータベース表の構造

- S.2.1 国および地域のレポート

- S.3 KPIデータ交換のデータベース表の構造

T HSMサポートの構成

- T.1 概要

- T.2 HSMベンダー・ソフトウェアのインストールおよび構成

- T.3 コレクタ・システムの構成

- T.4 HSMキーの構成

- T.5 HSMベース・トラフィックの正常な監視の検証

U 標準レポート・ライブラリ

- U.1 レポート・カテゴリ

- U.2 スイート固有のレポート

- U.3 「トランザクション」カテゴリ

V データ・ブラウザ・グループ内で使用できるディメンション

- V.1 すべてのページ、すべてのセッション、キー・ページおよびサービス・テスト・グループ

- V.2 ユーザー・フロー

- V.3 すべての関数、失敗した関数および処理の遅い関数グループ

- V.4 失敗したページ

- V.5 失敗したURLおよび遅いURL

- V.6 URL診断

- V.7 E-Business SuiteおよびSiebel

- V.8 ADFフレームワークおよびFusion Applications

- V.9 PeopleSoftアプリケーション

- V.10 FLEXCUBE Bankingアプリケーション

- V.11 JD Edwards EnterpriseOneアプリケーション

- V.12 WebLogic Portal

- V.13 WebCenterアプリケーション

W イベント・ログ・コードの説明

X サード・パーティ・ライセンス

- X.1 Apache Software License, Version 2.0

- X.2 OpenSSL

- X.3 PHP

- X.4 Java Runtime Environment

- X.5 MIT License (MIT)

索引

はじめに

Oracle Real User Experience Insight(RUEI)は、ネットワークおよびビジネスのインフラストラクチャに対する強力な分析機能を提供します。RUEIにより、実際のユーザー・エクスペリエンスの監視、キー・パフォーマンス・インジケータ(KPI)と品質保証契約(SLA)の設定、およびこれらに違反するインシデントに対するアラート通知の発行が可能になります。

対象読者

このガイドは、RUEIのすべてのユーザーを対象としています。対象読者には、管理者、セキュリティ担当者、およびビジネス・ユーザーとITユーザーが含まれます。これらのロールについては、14.2項「ユーザー・アカウントのロールと権限の概要」で説明します。

このガイドに直接関係するユーザーは次のとおりです。

- インストール済RUEIのメンテナンスを担当する管理者。メンテナンス作業には、システムの状態ステータスの監視、構成バックアップの実行および監視対象となるネットワーク操作の範囲の定義が含まれます。管理者は、ユーザー認可の作成およびメンテナンスも担当します。

- セキュリティ関連の問題を管理するセキュリティ担当者。セキュリティ関連の問題には、ロギングから除外する機密情報(クレジット・カードの詳細など)の定義、および暗号化したデータを監視するためのSSL鍵のインストールと管理が含まれます。

- その他すべてのシステム・ユーザー。これらはビジネス・ユーザーまたはITユーザー(あるいはその両方)として定義され、割り当てられた権限によってアクセス許可が決まります。

前提条件

特別な技術的知識は必要ありませんが、ネットワークおよびWebテクノロジについてある程度は習熟していることが前提となります。ただし、組織に関する知識は多少必要です。具体的には、次のとおりです。

- 管理者はネットワーク・トポロジを確実に理解し、組織のネットワークとアプリケーション環境の運用に関する十分な知識を持つ必要があります。また、このロールに割り当てられたユーザーはRUEIについて十分に理解しておく必要があります。

- セキュリティ担当者は、セキュリティ関連の問題について確実に把握している必要があります。さらに、ネットワーク構成を変更した場合の影響を正確に評価できる必要があります。

- 前述のように、様々なレベルのビジネス・ユーザーとITユーザーを定義することが可能です。これらのユーザーは、割り当てられる権限により、アクセス可能なデータのレベルと、実行できる構成タスクが決まります。これには、監視対象のWebページの指定、およびWebサイトのビジターの識別方法の指定が含まれます。追加のアクティビティとして、監視対象Webサイトの機能上のアーキテクチャを反映するためのRUEIの構成、キー・パフォーマンス・インジケータ(KPI)の定義、およびカスタム・レポートの作成が含まれることがあります。どの場合でも、ユーザーに割り当てる権限には、ユーザーが必要とする適切なアクセス権限と、組織に関するユーザーの知識を反映する必要があります。

このガイドの使用方法

このガイドの構成は次のとおりです。

- 第1章「スタート・ガイド」ではRUEIの概要について説明します。RUEIで使用されるロールと権限、RUEIインタフェースの外観およびカスタマイズ方法について説明します。対象読者はすべてのユーザーです。

- 第2章「レポートの操作」では、RUEIに付属している標準レポート・ライブラリと、ユーザー独自のレポートを作成および変更する方法について説明します。対象読者は、レポートを使用するすべてのユーザーです。

- 第3章「データ・ブラウザの使用」では、データ・ブラウザの使用方法について説明します。この章に直接関係するユーザーは、データ・ブラウザへのアクセス権限を持つ、ビジネス・ユーザーおよびITユーザーです。

- 第4章「セッション診断機能の使用」では、セッション診断を使用して根本原因分析を実行する方法について説明しています。

- 第5章「ダッシュボードの使用」では、カスタマイズしたダッシュボードの作成について説明します。

- 第6章「KPI概要およびアラート・リストの使用」では、「KPIの概要」とアラート・リストの使用方法について説明します。

- 第7章「パフォーマンスの監視の設定」では、KPIとSLAの設定方法とそれらに関するアラート・スケジュールおよび通知の定義方法について説明します。

- 第8章「Webページの識別とレポート作成」では、監視対象のページの定義方法について説明します。

- 第9章「ユーザー・フローの使用」では、ネットワーク・トラフィックを監視するときのユーザー・フローの役割について説明します。また、ユーザー・フローを構成する要素(ステップ、条件、イベントなど)やRUEIでのそれらのレポートについても説明します。

- 第10章「スイートおよびWebサービスの使用」では、スイートを使用して特定のOracle Enterpriseアーキテクチャを拡張監視する方法について説明します。また、Webサービスの監視についても説明します。

- 第11章「OAMおよびSSOベース・トラフィックの監視」では、OAMベース・トラフィック内におけるユーザー・アクティビティの監視方法について説明します。また、SSOメカニズムを介してユーザー・アクセス制御を管理するWebトラフィックの監視についても説明します。

- 第12章「監視対象トラフィックのレポートの制御」では、監視対象トラフィックのレポートを情報要件に合うように最適化する方法について説明します。

- 第13章「セキュリティ関連情報の管理」では、RUEIで使用されるセキュリティ関連設定の構成と管理の方法について説明します。この章に直接関係するのはセキュリティ担当者です。

- 第14章「ユーザーと権限の管理」では、RUEI内でユーザーに割り当てるロールと権限、およびユーザー・アカウントの作成と管理について説明します。また、外部ユーザー認証メカニズムの構成(LDAP、SSOなど)および組織のセキュリティ・ポリシーを強化するパスワード設定機能の使用方法についても説明します。

- 第15章「システムの監視およびメンテナンス」では、システムのステータスの監視方法、バックアップとアップグレードの実行方法、システム・ユーザーへのメッセージの発行方法、ユーザーの管理方法、およびRUEIからのデータのエクスポート方法について説明します。この章に直接関係するのは管理者です。

- 付録A「タグ付け規則」では、RUEI用にサポートされるページとサービスのタグ付けスキームについて詳しく説明します。

- 付録B「Cookieの構造」では、RUEIでサポートされるCookieテクノロジの概要を示します。

- 付録C「トラブルシューティング」では、RUEIの使用時に発生する最も一般的な問題を取り上げ、それらの問題をすばやく見つけて修正するための解決方法を示します。

- 付録D「エラー・コードの説明」では、Webサーバーによって生成され、リクエストに対する応答としてビジターに送信されるHTTP結果コードを詳しく説明します。

- 付録E「データ・アイテムの概要」では、RUEIで使用されるデータ・アイテムとKPIメトリックについて簡単に説明します。

- 付録F「XPath問合せの使用」では、RUEI内部で用意されている、XPath問合せを使用するためのサポートについて詳しく説明します。

- 付録G「各国語サポートの使用」では、ネットワーク・トラフィックを監視する際にRUEIによりサポートされるキャラクタ・エンコーディング標準について詳しく説明します。ドメイン名、カスタム・ヘッダーおよび関数エラーなどの識別に対する制限を取り上げます。各国語のキャラクタ・セットを使用するときのデータのマスキングやユーザーIDのマッチングの操作についても説明します。

- 付録H「WebLogic Portal(WLP)のサポート」では、WebLogic Portalベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

- 付録I「Oracle ADFのサポート」では、Oracle Application Development Framework (ADF)ベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

- 付録K「PeopleSoftのサポート」では、PeopleSoftベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

- 付録L「Siebelのサポート」では、Siebelベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

- 付録M「Oracle FLEXCUBEのサポート」では、Oracle FLEXCUBEベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

- 付録N「Oracle FormsおよびOracle E-Business Suiteのサポート」では、EBSベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

- 付録O「JD Edwardsのサポート」では、JD Edwards EnterpriseOneベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

- 付録P「Oracle Fusion Applicationsのサポート」では、OAFベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

- 付録Q「NATトラフィックの監視」では、ネットワーク・アドレス変換(NAT)デバイスの前にRUEIシステムを配置する場合に、どのようにして正確なネットワーク・トラフィック・レポートを作成するかについて説明します。

- 付録R「監視対象ネットワーク・トラフィックの確認」では、TCP診断機能を使用して、必要なすべてのネットワーク・トラフィックをRUEIで認識できるようにする方法を説明します。ネットワークが変更された後には、収集したネットワーク・トラフィックを組織のネットワーク・エンジニアが検証することを強くお薦めします。

- 付録S「エンリッチ・データのエクスポート機能」では、エンリッチ・データのエクスポート機能で使用するテーブル構造について説明します。

- 付録T「HSMサポートの構成」では、RUEIを設定してHSMデバイスに格納されている秘密鍵にアクセスする手順について説明します。

- 付録U「標準レポート・ライブラリ」では、レポート・ライブラリに用意されている事前定義済(標準)レポートについて説明します。

- 付録V「データ・ブラウザ・グループ内で使用できるディメンション」では、各データ・ブラウザ・グループ内で使用できるディメンションの詳細なリストについて説明します。

- W項「イベント・ログ・コードの説明」では、イベント・ログにレポートされるメッセージについて説明します。

- 付録X「サード・パーティ・ライセンス」には、RUEIに含まれているサード・パーティ製品に関するライセンス情報が記載さています。

詳細情報の参照先

- Oracle Enterprise Managerに関する情報は、次のサイトを参照してください。

http://www.oracle.com/us/products/enterprise-manager/index.html

- 詳細な技術情報は、My Oracle Supportから入手できます。

https://support.oracle.com

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Real User Experience Insight(RUEI)ドキュメント・セットに含まれる次のドキュメントを参照してください。

- 『Oracle Real User Experience Insightインストレーション・ガイド』。

- 『Oracle Real User Experience Insight管理者ガイド』。

- 『Oracle Real User Experience Insightリリース・ノート』。

このマニュアルの最新版やその他のRUEI関連ドキュメントは、次の場所にあります。

http://www.oracle.com/technetwork/documentation/realuserei-091455.html

RUEIでは総合的なオンライン・ヘルプも提供されます。「システム」メニューの「ヘルプ」オプションを選択するかダイアログ内の「ヘルプ」アイコンをクリックして、オンライン・ヘルプ・システムを表示します。

用語の更新

以前のバージョンのRUEIでは、ユーザー・フローはトランザクションと呼ばれていました。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 スタート・ガイド

この章では、RUEIの概要について説明します。RUEIが提供するネットワークおよびビジネス・インフラストラクチャの強力な分析機能について説明します。また、使用するブラウザの要件、RUEIセッションの開始および終了方法、レポータ・インタフェースの外観のカスタマイズ方法についても説明します。

RUEIを組織のネットワークに適切にインストールし、初期設定ウィザードを実行して、ネットワーク・インフラストラクチャに関する情報を設定しておく必要があります。詳細な手順はOracle Real User Experience Insightのインストレーション・ガイドを参照してください。

1.1 RUEIとは

組織では、インターネットによるビジネス・チャンスへの関心が高まる一方で、自社のインターネット運用の効果を評価するために正確な最新のWebトラフィック情報が必要とされています。求められているのは、あらゆるユーザー・セッションを記録し、複雑なWebデータを意味のあるわかりやすい統計に変換して、事業経営上の効果的意思決定のベースにできるソリューションです。

RUEIは強力なWebベースのユーティリティで、ネットワークからリクエストされる、またはネットワークで生成される実際のユーザーのトラフィックに対してレポートを作成します。ネットワーク・インフラストラクチャの最も重要となるポイントで、ページおよびユーザー・フローのレスポンス時間が測定されます。この強力なセッション診断機能を使用すると、アプリケーション・マネージャおよびIT技術スタッフは根本原因分析を行うことができます。

RUEIにより、実際のユーザー・エクスペリエンスに基づくサーバー時間およびネットワーク時間の表示、キー・パフォーマンス・インジケータ(KPI)および品質保証契約(SLA)の監視、およびこれらに定義されたターゲットに違反するインシデントに対するアラート通知の発行が可能になります。

ページ・コンテンツ、サイト・エラー、およびユーザー・フローの機能要件に対するチェックを実装できます。この情報に基づいて、ビジネス面および技術面での運用を検証できます。RUEIで識別されるすべての対象について、可用性、スループットおよびトラフィックに関するカスタム・アラートを設定できます。

RUEIには強力なレポートのライブラリが付属しており、効果的な意思決定に必要な情報をビジネス・ユーザーとテクニカル・ユーザーの両方に提供します。また、権限のあるユーザーは、簡単に独自のレポートを作成したり、既存のレポートを変更できます。このようなレポートを使用してWebデータと直接対話し、オンラインの使用状況とWebアプリケーションの全体ステータスについて深い理解を得ることができます。レポートはインタラクティブに表示することも、電子メールで受信することもできます。

RUEIのダイナミックなドリルダウン機能を使用して、希望するレベルのWebデータに簡単にたどり着くことができます。これらの情報はソート、フィルタおよびエクスポートできます。さらに、時間、クライアントの場所、ユーザー・フローおよびユーザー名などの様々な基準の間でデータを関連付けることができます。

セッション診断機能では、運用上の問題に対して根本原因分析を実行できます。個々のセッションを評価する機能と、各セッション内のユーザー・アクティビティのすべてを確認する機能が用意されています。

RUEIを使用する方法のデモンストレーションを表示するには、次のURLにアクセスして「Begin Video」をクリックします。

https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5783,1

次のデータ収集オプションが使用可能です。

- ネットワーク・データ・コレクタ: このオプションは、ネットワークを通過するデータを収集するためのもので、以前のリリースでのデフォルト・オプションであり、ローカル・コレクタまたはリモート・コレクタを必要とします。

- タグ・データ・コレクタ: このオプションはタグ・ベースの監視とも呼ばれ、リクエストを監視し、すべてのページに挿入される特定のWeb URL(タグ)を処理することによってデータを収集します。

- ADF監視サービス: このオプションを選択すると、ADFベース・アプリケーション用のアプリケーション・サーバーから直接データが収集されます。

1.2 ブラウザ要件

RUEIユーザー・インタフェースにアクセスするワークステーションには、次のいずれかのブラウザがインストールされている必要があります。

- Mozilla Firefox 3.6(以上)。

- Internet Explorer 7、8または9。

- Safari 4および5。

- Google Chrome 17(以上)。

JavaScriptは有効にする必要があります。その他に必要なプラグインはありません。

また、ワークステーションの画面解像度は、1024×768(以上)が必要です。

注意:
ブラウザ内のポップアップ・ブロッカが無効になっていることを確認してください。

1.3 開始前の準備

RUEIでネットワーク・データの監視およびレポート作成を開始するには、ネットワーク・インフラストラクチャに関する情報を使用して構成する必要があります。構成が完了すると、ユーザー通信のレポート作成が可能になります。RUEIの使用を開始する前に、次の事項に留意してください。

1. 監視されたトラフィックにSSLベースのセッションが含まれている場合、システムに対してSSL鍵が使用可能でなければ、コレクタがSSLトラフィックを復号化できなくなります。この詳細は、13.5項「SSL鍵の管理」に記載されています。SSL以外のトラフィックにはこの要件は必要ありません。

2. ユーザーのWeb環境内で使用するCookieの構造を指定することをお薦めします。指定しない場合、セッション・トラッキングはIPアドレスおよびブラウザに基づいて行われます。これは、12.2項「セッション・トラッキング・メカニズムの指定」に記載されています。

3. RUEIでは、ユーザー識別は最初にHTTP認可フィールドから取得されます。その後、アプリケーションの定義に指定したPOST引数から導出されます。この引数が構成されていない場合は、SSLクライアント証明書が使用されます(存在する場合)。その共通名(CN)部分が使用されます。したがって、URL内で引数を使用する場合は、信頼できる結果を得られるように、ユーザーの識別に使用されるGET/POST項目を指定する必要があります。この詳細は、8.3.14項「ユーザー識別の定義」に記載されています。

4. RUEIにおけるページ識別は、アプリケーションに基づいて行われます。一般的に、アプリケーションはWebページの集合です。アプリケーション定義およびページ定義を使用して識別できないページに関する情報は廃棄されるため、レポートおよびデータ・ブラウザでは使用できません。この詳細は、8.1項「ページのネーミング」および8.3項「アプリケーションの定義」に記載されています。

5. ユーザー・フローを使用すると、Webページにおけるビジター・エクスペリエンスの状況を確実に把握できます。この機能は、第9章「ユーザー・フローの使用」に記載されています。

6. 「システム」→「ステータス」→コレクタ・ステータスを選択して、コレクタのステータスをチェックします。この詳細は、15.2項「コレクタのステータスの表示」に記載されています。また、「システム」→「ステータス」→「データ処理」を選択して、監視しているネットワーク・トラフィックの概要を表示することもできます。この詳細は、15.5項「トラフィック・サマリーの表示」に記載されています。

1.4 RUEIの開始

RUEIセッションを開始するには、ブラウザで次のURLにアクセスします。

https://Reporter/ruei

Reporterには、インストール済RUEIのホスト名またはIPアドレスを指定します。

注意:
この情報をまだ受け取っていない場合は、管理者に問い合せて、必要なIPアドレスまたはURLのホスト名部分を入手してください。

図1-1に示すログイン・ダイアログ・ボックスが表示されます。

図1-1 ログイン・ダイアログ・ボックス

ユーザー名とパスワードを入力して、「ログイン」をクリックします。ユーザー名がまだ割り当てられていない場合は、管理者に問い合せてください。

注意:
ログイン時に問題が発生する場合、ブラウザ内のポップアップ・ブロック機能が無効化されていることを確認します。

1.5 環境のカスタマイズ

「システム」メニューで「プリファレンス」(図1-2)を選択して、個人設定をカスタマイズします。

図1-2 「プリファレンス」メニュー

次のオプションがあります。

- ユーザー: セッションに使用する設定を指定できます。セッション中に使用する言語、受信するレポートが複数の電子メールで送信されるか単一の電子メールにバンドルされるか、セッションの開始元となるモジュール(たとえば、レポート、ダッシュボード、システム)、およびデータ・ブラウザで使用する有効な初期期間を制御できます。これらの設定の詳細は、14.5項「ユーザーの設定の変更」に記載されています。

- 書式設定: レポートにおける数値の書式を指定できます。小数点、3桁区切りとして使用する文字および日付書式(05 Feb 2008またはFeb 05, 2008)を指定できます。

- パスワードの変更: システム・パスワードを変更できます。現行のパスワードを入力し、使用する新規のパスワードを反復入力する必要があります。

注意:
組織のセキュリティ・ポリシー(14.6項「パスワード・セキュリティ・ポリシーの強制」を参照)に従って、パスワードを定期的に変更する必要があります。パスワードの有効期限の7日前から、ログオンするたびに警告が表示されます。この期間にパスワードを再設定しないと、アカウントがロックされます。パスワードの有効期限の8日以上前から不在にする場合は、その前にパスワードを再設定することをお薦めします。

1.6 セッションの終了

セッションを終了するには、「システム」メニューから「ログアウト」を選択します。

2 レポートの操作

この章では、付属の標準ライブラリ・レポート、レポートの使用方法、受信するレポート・メールの制御方法、およびレポートを変更して独自のレポートを作成する方法について説明します。2つのレポート・モード(インライン・レイアウトと印刷レイアウト)の使用方法についても説明します。

2.1 レポート・ライブラリの概要

レポートを使用すると、ネットワーク・インフラストラクチャのパフォーマンスの評価に必要な状況を把握できます。また、定義済のKPIやSLAが達成がされているかどうかも確認できます。レポートにより、問題のある領域を簡単に特定できます。また、アラートと併用することで、必要な修正処理を状況に応じて迅速かつ適切に実行できます。

RUEIには、豊富な事前定義済(標準)レポートのライブラリが付属しており、組織内の監視対象操作を即座に確実に把握できます。これらのレポートはレポート・ライブラリから使用できます。レポート・ライブラリは「レポート」タブをクリックすると表示されます。図2-1にこれを示します。

図2-1 標準レポート・ライブラリ

標準レポート・ライブラリ

レポート・ライブラリは、監視対象の各項目のトラフィックに関するレポートを含む複数のカテゴリ(つまりフォルダ)で構成されています。このため、自分が最も必要とする情報を迅速に見つけることができます。各レポート・カテゴリで入手できる情報の概要を表2-1に示します。

表2-1 レポート・カテゴリ

カテゴリ

説明

アプリケーション

監視対象アプリケーション・ページに関する情報を提供します。これには、ページ・ビュー、ページ上に表示されるオブジェクト、ページのロード時間や読取り時間などが含まれます。

クライアント

監視対象アプリケーション・ページに関する情報を提供します。これには、ページ・ビュー、ページ上に表示されるオブジェクト、ページのロード時間や読取り時間などが含まれます。

ドメイン

監視対象ドメインに関する情報を提供します(トラフィック、ページ・ビュー、ロード時間、読取り時間など)。

E-Business Suite

EBS対応アプリケーションに関する情報を提供します。

Oracle Fusionスイート

Oracle Fusionベースのアプリケーションに関する情報を提供します。

JD Edwardsスイート

JD Edwards対応アプリケーションに関する情報を提供します。

キー・ページ

特に注意が必要な特定のページに関する情報を提供します。これらのページに関しては、追加情報が記録されます。

監視

ダッシュボード項目(SLAやKPIなど)に関する日次または週次情報を提供します。

Oracle ADFスイート

Oracle ADFベースのアプリケーションに関する情報を提供します。

全体

監視対象Webサイトに関する失敗、合計トラフィック、セッション、ページ・ビューなどの累積情報を提供します。

サーバー

割当て済のIP範囲に基づいたクライアント・セッションに関する情報を提供します。

Siebel

Siebelベースのアプリケーションに関する情報を提供します。

トランザクション

ユーザー・フローの履歴データへのアクセスが含まれています脚注1。

URL

失敗したヒットまたは遅いヒット、およびパフォーマンス低下の原因に関する情報を提供します。

ユーザー・フロー

定義済のすべてのWebアプリケーション・ユーザー・フローに関するクライアント情報を提供します。たとえば、ビジターによって開始されたユーザー・フローの数、ユーザー・フローの継続時間、完了または中断したユーザー・フローの数などです。

WebLogic Portal

WebLogic Portalベースのアプリケーションに関する情報を提供します。

脚注1 バージョン6.5.1では、トランザクションはユーザー・フローに名称変更され、処理やレポートの方法に重要な違いがあります。

2.2 レポート・ライブラリのカスタマイズ

標準レポート・ライブラリは、組織の要件により適合するように変更できます。メニューを使用して、レポートのカテゴリまたはサブカテゴリの名前変更、削除または追加が可能です。

標準レポートは変更も削除もできません。また、標準レポートに関連付けられている権限も変更できません。つまり、これらのレポートは、認可されたユーザーが読取り専用でのみ使用できます。標準レポートを変更したバージョンを使用する必要がある場合は、標準レポートをカスタム・レポートのベースとして使用する必要があります。この手順は、2.11項「新規レポートの作成」に記載されています。

カテゴリをメインのレポート・ライブラリに追加するには、「レポート・カテゴリ」項目を右クリックします。図2-2に示すコンテキスト・メニューが表示されます。

図2-2 「レポート・カテゴリ」メニュー

次のオプションがあります。

- パブリック・カテゴリの追加: すべてのユーザーが使用できる新規カテゴリを作成します。

- プライベート・カテゴリの追加: 自分のみが使用できる新規カテゴリを作成します。

必要なオプションの選択後、新規カテゴリに一意の名前を指定するように求められます。レポート・カテゴリはアルファベット順にソートされ、プライベート・カテゴリがパブリック・カテゴリの下に表示されます。

サブカテゴリの追加、あるいはカテゴリの名前変更または削除を行うには、該当するカテゴリを右クリックします。図2-3に示すメニューが表示されます。

図2-3 「レポート・カテゴリ」サブメニュー

次のオプションがあります。

- サブカテゴリの追加: 選択したカテゴリの下に新規サブカテゴリを作成します。この新規サブカテゴリはすべてのユーザーが使用できます。

- カテゴリの編集: カテゴリの名前を変更、またはカテゴリを別の場所に移動します。このオプションを使用できるのは、標準以外のレポート・カテゴリのみです。

- カテゴリの削除: カテゴリを削除します。削除の確認を求められます。このオプションを使用できるのは、標準以外のレポート・カテゴリのみです。

- カテゴリの無効化: 管理者以外のユーザーに対して、パブリック・レポート・カテゴリへのアクセスを制限します。この機能は、レポート構造の変更中、または機密情報を含むレポートへのアクセスを制限する場合に有用です。無効化されたカテゴリ内のレポートは、お気に入りおよびレポート・メーリング機能からも自動的に削除されます。

レポートの権限およびパワー・ユーザー

ユーザーが作成した各レポートおよびレポート・カテゴリには、使用方法が割り当てられます。これは、「ビジネス」または「IT」(あるいはその両方)です。この違いは、14.2項「ユーザー・アカウントのロールと権限の概要」で説明されているユーザー権限の基礎にもなります。ビジネス・ユーザーとITユーザーの両方として(つまり、いわゆるパワー・ユーザーとして)「分析」または「完全」のアクセス・レベル権限が割り当てられている場合、作成するレポートへのアクセスは、レポート・カテゴリ・レベルではなく、個々のレポート・レベルで制御されることに注意してください。

たとえば、図2-4に示すように、使用方法「ビジネス」の新規パブリック・カテゴリを作成した場合、ビジネス・ユーザーは、このカテゴリに保存されたIT関連レポートにアクセスできません。

図2-4 「ビジネス」の新規パブリック・カテゴリの作成

このため、異なるタイプのユーザーを対象としたレポートをカテゴリ内に混在させないことをお薦めします。

2.3 メーリング機能の使用方法

「マイ・メーリング」機能を使用すると、自動電子メールで受信するレポートの概要と、そのレポートの受信頻度(毎日、毎週または毎月)を確認できます。例を図2-5に示します。

図2-5 メーリング・プロファイルの例

レポートの右側にあるチェック・ボックスを使用して、レポートを受信する頻度を指定します。または、レポートを右クリックして「メーリング」を選択し、レポートの頻度(「日次」、「週次」または「月次」)を選択します。また、「メーリングから削除」を選択して、選択したレポートの受信を停止することもできます。

図2-6 「レポート」メニュー

「すぐにメーリング送信」パネルの「日次」、「週次」または「月次」コマンド・ボタンを使用して、以前のレポートをリクエストできます。コマンド・ボタンを使用できない場合は、その頻度のレポートがメーリング・リストにないことを意味します。

注意:
レポート・メーリング機能は、毎日午前6時(レポータのシステム時間)に実行されるようにスケジュールされています。

たとえば、「週次」をクリックすると、リスト(図2-7を参照)で特定の週を選択でき、メーリング・プロファイルで現在選択されているその週のすべての週次レポートを受信できます。

図2-7 「すぐにメーリング送信」ダイアログ

2.4 お気に入り機能の使用方法

よく使用するレポートに簡単にアクセスできるようにするには、「お気に入り」オプションをクリックします。この機能では、レポートへのショートカットを作成できます。

「お気に入り」セクションにレポートを追加するには、目的のレポートを右クリックし、図2-6に示すメニューから「お気に入りに追加」を選択します。レポートを開くには、ショートカットをクリックして、メニューから「ビュー」 を選択します。レポートの現在のメーリング頻度を確認または変更するには、「メーリング」を選択して目的のオプションを選択します。

ショートカットを「お気に入り」から削除するには、目的のショートカットを右クリックし、図2-8に示すコンテキスト・メニューから「お気に入りから削除」を選択します。

図2-8 「お気に入り」のコンテキスト・メニュー

2.5 レポート・メーリングの管理

レポート・メーリング機能を使用すると、ユーザーに送信されるメールを簡単に管理することができます。この機能を使用できるのは管理者のみです。レポートを受け取るユーザーを指定するには、次の手順を実行します。

1. 「レポート」、「メーリング」、「メーリングのレポート」の順にクリックします。

2. 受信者を指定したいレポートを選択します。選択したレポートを現在受信しているユーザーと、その受信頻度がリストされます。例を図2-9に示します。

図2-9 レポート・メーリングの例

オプションで、「毎日」、「毎週」および「毎月」チェック・ボックスを使用して、現在定義されている各受信者が選択したレポートを受信する頻度を変更します。

3. 「メーリングの追加」コマンド・ボタンをクリックし、新しいレポート受信者を追加します。図2-10に示すダイアログが表示されます。

図2-10 レポート・メーリングの追加

4. 選択したレポートが1つ以上のフィルタを指定して作成された場合(3.9.3項「レポート・フィルタの使用方法」を参照)には、適切なディメンション・メニューを使用して適切な値を指定できます。

5. 「毎日」、「毎週」、「毎月」のチェック・ボックスを使用し、選択したレポートを受信者が受け取る頻度を指定します。

6. 「ユーザー」フィールドを使用し、レポートの受信者を指定します。次に、「保存」をクリックします。

2.6 カレンダの使用方法

レポートでは、特定の日付または期間に関する情報が提供されます。したがって、情報を取得する期間を指定する必要があります。図2-11に示すカレンダを使用して、目的の日付または期間を指定します。

図2-11 カレンダ

コントロール

カレンダは次の部分から構成されています。

- 「自」および「至」セクションでは、情報を取得する期間を指定できます。期間は日付単位、週単位または月単位で指定できます。選択した日付は、ハイライト表示されます。日付の選択を解除するには、単に再クリックします。表示される列の下にある矢印キーを使用すると、前後の月または年に移動できます。「日付選択のクリア」をクリックすると、現行のすべての選択を瞬時に解除できます。デフォルトでは、現在の日付が選択されています。これは、「今日」をクリックして選択することも可能です。

- 「日」タブでは、複数の特定日付を指定して目的の期間を指定できます。単一の日付を選択すると、別のパネルが表示され、選択した日付の特定の時間にレポートを限定できます。時間をクリックして選択および選択解除することや、「業務時間」をクリックして9時から18時までをただちに選択することが可能です。また、選択した複数の時間の選択を、「時間選択のクリア」のクリックによって瞬時に解除することもできます。

- 「週」および「月」タブでは、情報を週または月単位で指定してリクエストできます。

- オフセットの比較メニューでは、比較可能な2つの期間のデータを比較できます。この機能の使用方法は、3.10項「異なる期間を対象とするデータの比較」に記載されています。

レポートの表示中は、期間の選択をいつでも自由に変更できます。前述のコントロールを使用するのみで、レポートはただちに更新され、新しく選択した期間が反映されます。

2.7 レポート・フィルタの使用方法

レポート・フィルタ(3.9.3項「レポート・フィルタの使用方法」を参照)で作成したレポートを開くと、レポートのフィルタを指定するように求められます。たとえば、レポートがブラウザ・タイプに関連している場合、表示するKPIを指定するように求められます。図2-12にこれを示します。

図2-12 レポート・フィルタの例

表示されたリストから目的の値を選択し、「レポートの表示」をクリックします。これで、レポートが開きます。

2.8 レポート要素の概要

各レポートは、ヘッダー、情報画面およびいくつかのセクションで構成されます。レポートのこれらのセクションについて、次の各項で説明します。

レポート・ヘッダー

レポート・ヘッダーには、表示中のレポートに関する一般情報が含まれています。一般情報には、レポートのタイトル、レポートされるメトリック、レポートの対象となる日付または期間が含まれます。例を図2-13に示します。

図2-13 レポート・ヘッダーの例

「情報」画面

「情報」画面には、レポートで使用される語句の用語集が表示されます。これは、レポートで使用されるメトリックの説明が必要な場合に役立ちます。例を図2-14に示します。

図2-14 レポートの用語集の例

また、レポートで使用されるすべての用語を記載したリストと、その用語の説明を取得することもできます。それには、用語集内で右クリックして「全用語集」を選択します。

レポートのセクション

一般に、レポートには複数のセクションがあり、含まれるセクションの数はレポートによって異なります。たとえば、日次トラフィック・レポートには、リクエストした期間のページ・ビュー数によってトラフィックをレポートするセクションと、バイト数によってトラフィックをレポートするセクションの2つがあります。

レポートのセクション間を移動するには、レポート・パネルの上部にあるツールバーのアイコンを使用します。また、レポートの「情報」画面を表示して、レポートのデータのビューをグラフィックまたは表(値)の間で切り替えることも可能です。これらのアイコンを図2-15に示し、表2-2で説明します。

図2-15 インライン・レイアウトのアイコン

表2-2 インライン・レイアウトのアイコンの説明

アイコン

説明

用語集。

レポートに現在示されているメトリックの簡単な説明を表示します。

グラフ。

レポートのセクションの標準グラフ(円グラフ、線グラフまたは棒グラフ)を表示します。グラフの種類は、基になるデータによって異なります。

値。

レポートのデータの基となるデータ値を表示します。

前のセクションおよび次のセクション。

これらのコントロールを使用して、レポートのセクション間を移動します。含まれるセクションの数は、レポートによって異なります。

レポート内の現行のセクションを示します。

プレビュー。

レポートを印刷レイアウト・モードで開きます。このモードは、レポートをカスタマイズする場合、またはレポートに基づいて新規レポートを作成する場合に使用します。

PDFのダウンロード。

レポートの現行のコンテンツのAdobe PDFファイルを作成します。

図2-15に示すオプションに加えて、各セクションのコンテキスト・メニューの「参照」オプション(図2-16を参照)を使用して、レポートのセクションの基となるデータの完全なビューを取得することもできます。この詳細は、第3章「データ・ブラウザの使用」に記載されています。

図2-16 レポート・セクション・メニュー

レポート内の各セクションは、有効化または無効化できます。無効化されたセクションは閉じ、このため、再表示するには有効化する必要があります。無効化されたレポートのセクションの例を図2-17に示します。

図2-17 無効化されたレポートのセクション

この機能を使用して最終的な(保存済)レポートのコンテンツを制御できることを理解しておくことが大切です。たとえば、新規レポートのベースとして使用している既存のレポートに、新規レポートとは無関係のセクションが含まれている場合、この機能を使用してそのセクションを最終レポートから削除できます。

2.9 レポートされた値の解釈

レポート(および第3章「データ・ブラウザの使用」で説明されているデータ・ブラウザ)を使用しているとき、値リストに、レポート対象の値でなく、n/aというテキストが含まれる場合があります。測定対象のデータが存在しないためにそのようになります。線グラフおよび棒グラフの場合、この状況は0(ゼロ)の値で示されます。これが発生するのは、次のような状況においてです。

- 選択した期間の平均が常に、存在するデータに基づいて計算されます。このため、過去24時間の平均値の情報をリクエストしたときに、20時間分のデータのみが存在する場合、平均は24時間ではなく20時間に基づいて計算されます。

- 期間ベースのレポートには、行の順序と範囲に一貫性を持たせるため、n/aの行が自動的に挿入される場合があります。

- フィルタを使用すると、アクティブな期間のデータが表示されなくなる場合もあります。この場合も、値n/aが挿入されます。合計をレポートする列の場合、この値は0として解釈されます。

2.10 印刷レイアウト・モードの使用

RUEIでレポートを開くと、レポートはインライン・モードで表示されます。このモードでは、レポートのコンテンツの概要が表示され、レポートで入手可能な他の詳細情報にすばやくアクセスできます。レポートの参照時には、このモードを使用します。ただし、レポートをカスタマイズする場合、または新規レポートを作成する場合は、より強力な編集モードが必要です。これは、印刷レイアウト・モードと呼ばれます。レポートを印刷レイアウトで表示するには、レポート・パネルの上部にあるタスクバー(図2-15を参照)から「プレビュー」を選択します。例を図2-18に示します。

図2-18 印刷レイアウトのレポートの例

このレイアウトは、レポートのテンプレートとして考えることができ、レポートの構造と外観を定義します。レポートの印刷レイアウトは、新規ウィンドウで表示されます。

2つのレイアウト間の主な違いの1つは、印刷レイアウトではレポートの全セクション(「情報」画面を含む)が表示されることです。このため、レポートのコンテンツの概要全体を把握できます。もう1つの主な違いは、レポートのデータがグラフィックと値(表)の両方の形式で表示されることです。

各セクションの背後にあるコンテキスト・メニュー(図2-18を参照)を使用すると、必要に応じてセクションを変更できます。セクションへの説明の追加、レポートのセクションの有効化および無効化(2.8項「レポート要素の概要」を参照)、レポートからのセクションの削除、およびレポート内でのセクションの表示順の変更が可能です。

2.10.1 印刷レイアウト・モードを使用したレポートのカスタマイズ

レポートに表示する列を変更する手順は、次のとおりです。

1. 変更するレポートを選択し、レポート・パネルの上部にあるタスクバー(図2-15)から「プレビュー」をクリックして、プリント・レイアウト・モードを開始します。

2. 変更する列を右クリックして、「編集」をクリックします。図3-24に示すような「エクスポートのカスタマイズ」ダイアログが表示されます。

3. 「データ列」フィールドおよび「値列」フィールドを変更して、必要に応じてレポートの列を追加または削除します。

4. エクスポートのカスタマイズの詳細は、第3章「エクスポートするデータの変更」を参照してください。

2.10.2 値リストの使用

デフォルトでは、レポートのセクション内のデータは、グラフ形式で表示されます。ただし、グラフよりも、具体的な数値の確認が必要となる場合があります。また、印刷機能や表示機能が制限されているユーザーにレポートを配布することを計画する場合もあります。このような場合、レポート・パネルの上部にあるツールバー(図2-15を参照)の「値」および「グラフ」アイコンを使用して、2つのビューを切り替えることができます。値の表の例を図2-19に示します。

図2-19 値の表の例

2.10.3 値リストの制限

値リストでは、メニューから制限値リストを選択して、選択したセクションに表示される値の数を指定できます。図2-20に示すダイアログが表示されます。

図2-20 制限値リスト・ダイアログ

-1の値を指定すると、存在するすべての値が表示されます。この機能は慎重に使用することをお薦めします。値リストが非常に大きくなる可能性があるためです。デフォルトは100です。

2.10.4 比較モードでの操作

比較機能(3.10項「異なる期間を対象とするデータの比較」を参照)を使用してレポートを作成すると、追加オプション「比較」をメイン・セクションのコンテキスト・メニュー内で使用できます。これにより、レポートに使用するオフセット期間を指定できます。指定可能な期間は、レポートでのアクティブ期間の選択(日、週または月)に応じて異なります。

2.11 新規レポートの作成

レポート・ライブラリに表示される標準レポートの他に、新規レポートを作成することもできます。このためには、既存のレポートを新規レポートのベースとして使用してから、要件に合うように新規レポートを変更する必要があります。新規レポートを保存する手順は、次のとおりです。

1. 新規レポートを作成する準備ができたら、「ファイル」メニューから「新規として保存」を選択します。図2-21に示すダイアログが表示されます。

図2-21 「新規レポートとして保存」ダイアログ

2. 新規レポートのタイトルおよび簡単な説明と、保存先のカテゴリを指定します。前述のように、レポートをプライベート・カテゴリに保存すると、レポートを使用できるのは自分のみになります。「オプション」タブでは、レポートに用語集を含めるかどうかを指定できます。次に、「保存」をクリックします。そのタイトルのレポートがすでに存在する場合、それを置き換えるか確認するように求められます。
作成したレポートがレポート・ライブラリにただちに表示されない場合は、「レポート」アイコンをクリックして表示された構造をリフレッシュしてください。

既存のレポートの変更

2.8項「レポート要素の概要」で説明した機能を使用して、レポートを変更できます。標準レポートは変更できないことに注意してください(2.1項「レポート・ライブラリの概要」を参照)。新規レポートを作成できるかどうかは、割り当てられているユーザー権限によって決まります。パブリック・レポートは、作成後、必要な権限を持つユーザーが編集でき、他のすべてのユーザーも読取り専用で使用できます。

2.12 PDFへのレポートのエクスポート

「PDFとしてレポートをダウンロード」アイコンをクリックするか、「ファイル」メニューから「PDFとしてレポートをダウンロード」を選択して、レポートの現行のコンテンツのAdobe PDFファイルを作成できます。「ファイル」メニューから「ページの向き」を使用して、縦または横のPDFファイルを作成します。印刷レイアウトで無効化されているセクションは、生成されるPDFファイルには含まれないことに注意してください。

注意:
生成されたPDFファイルを表示するには、Adobe Acrobat Readerをインストールする必要があります。これはAdobe社のWebサイト(www.adobe.com)からダウンロードできます。

2.13 レポート・データのエクスポート

RUEI内部のレポート・データは、XMLやCSVなどの様々な形式で、Web問合せを使用してホストまたはクライアント・システムにエクスポートできます。たとえば、ビジネス・インテリジェンス(BI)システムへのエクスポートが可能です。エクスポートされたデータはUnicode(UTF-8)形式になります。「レポート・データのエクスポート」ロールを持つRUEIユーザーは、Basic認証を使用して、Webリクエストを使用してRUEIからデータをダウンロードできます。管理者はこの目的で、RUEIを使用して、パラメータを含むURLを構成できます。この機能を使用する手順は、次のとおりです。

1. 「レポート」を選択します。

2. 必要なレポートを選択して、ツールバーの「レポートURLのエクスポート」を選択します。図2-22に示すウィンドウが表示されます。

図2-22 「レポート・データのエクスポート」ウィンドウ

3. データを使用できる必要がある期間を指定します。

4. 「データ形式」メニューを使用して、レポート・データをエクスポートする形式を指定します。デフォルトは、Extensible Markup Language (XML)です。

5. フィルタを使用するレポートの場合、必要なディメンション値を選択します。フィルタの使用方法は、2.7項「レポート・フィルタの使用方法」を参照してください。

6. レポート・データへのURLが表示されます。これをコピーして、関連するすべてのホストに送信します。ユーザーは、レポート・データにアクセスするための有効なユーザー名およびパスワードを要求されます。

7. 必要に応じて、レポート・データにアクセスするための「レポート・データのエクスポート」ロールを持つユーザーを作成します。ユーザー・ロールの詳細は、14.2項「ユーザー・アカウントのロールと権限の概要」を参照してください。

その他の引数

デフォルトでは、エクスポートされるデータは丸一日分がXML形式で提供されます。ただし、表2-3の引数を指定することもできます。

表2-3 レポート・データのエクスポート機能のその他の引数

引数の名前

引数の値

説明

output

pdf

PDF形式でデータをエクスポートします。

xls

XLS形式でデータをエクスポートします。

xml

XML形式でデータをエクスポートします(デフォルト)。

csv

カンマ区切り値でデータをエクスポートします。

tsv

タブ区切り値でデータをエクスポートします。

wqf

Web Query形式のエクスポート・データ。

date脚注1

yyyymmdd

丸一日分のデータをエクスポートします(デフォルト)。

yyyymmddhh

特定の1時間のデータをエクスポートします。

yyymmddhhmm脚注2

特定の5分間のデータをエクスポートします。

date-to脚注1

yyyymmdd

特定の日までのデータをエクスポートします。

yyyymmddhh

特定の時刻(1時間単位)までのデータをエクスポートします。

yyymmddhhmm脚注2

特定の時刻(5分単位)までのデータをエクスポートします。

脚注1 時間範囲の引数には、常にレポータ・システムのローカル時間が使用されます。

脚注2 日付形式の最小単位は5分間です。したがって、yyyymmdd1215という日付を指定すると、12時15分から12時19分の期間の値が返されます。

次に例を示します。

http://myshop/ruei/export.php?id=10056&output=csv&date=20101025&date-to=20101027

このように指定すると、選択したレポート・データが2010年10月25日から27日の期間についてカンマ区切り値の形式でエクスポートされます。

動的にリフレッシュするダッシュボードの作成

レポート・データのエクスポート機能を使用して、動的にリフレッシュするMicrosoft Excelスプレッドシートを作成できます。次に説明する手順では、「レポート・データのエクスポート」ロールを持つ有効なユーザーが必要です。これらは、外部ダッシュボードのベースとなります。このようなデータ・フィードを作成するには、次の手順を実行します。

1. 「システム」→「レポート・データのエクスポート」の順に選択します。表示されたリスト(図2-22)から新たに作成するエクスポートを選択します。エクスポート・データに表示されるURLを書き留めます。

2. 次のコンテンツを使用して、ローカル・システムにファイルruei.iqyを作成します。

WEB
1
https://<Reporter>/ruei/export.php?output=wqf
id=["id","The report ID"]&date=["date","Begin date
YYYYMMDD"]&date-to=["date-to","End date YYYYMMDD"]

上で指定したURLのReporter部分を適切なホスト名またはIPアドレスで置き換える必要があります。

3. Microsoft Excel内で、「ファイル」メニューの「Existing connections」を選択します。「参照」をクリックします。図2-23に示すようなダイアログが表示されます。

図2-23 「Existing Connections」ダイアログ

4. 「Browse for More」をクリックし、以前に作成したruei.iqyファイルに移動して選択します。図2-24に示すようなダイアログが表示されます。

図2-24 「Import Data」ダイアログ

5. インポートしたデータを使用して新しいスプレッドシートを作成するよう指定します。準備ができたら、「OK」をクリックします。図2-25に示すようなダイアログが表示されます。

図2-25 「Enter Parameter Value」ダイアログ

6. レポート・データのエクスポート機能によって示されたURLに含まれるレポートIDを指定します。開始日および終了日を指定するよう求められます。これらは、それぞれスプレッドシート内のセルから取得するか、直接入力できるので注意してください。準備ができたら、「OK」をクリックします。指定したエクスポート・ソースのデータは、RUEIによって自動的に更新されます。

Microsoft Excelスプレッドシート内で戻される行の数は、特定の間隔で異なる場合があります。このため、フィルタリングおよび他の書式設定問合せを設計する場合にこの点を考慮する必要があります。また、適切なメニュー・オプションおよびダイアログの表示は、使用しているMicrosoft Excelのバージョンによっては上記のバージョンと異なる場合があります。

3 データ・ブラウザの使用

この章では、データ・ブラウザの使用方法について説明します。データ・ブラウザはRUEIの中心となる機能であり、監視中に収集された情報への直接アクセスを提供します。データ・ブラウザでは、直感的でユーザーフレンドリな方法を使用して、情報のドリルダウン、検索およびフィルタを実行できます。

3.1 データ・ブラウザの概要

各レポートに示される情報は、監視中に取得したすべての情報を含む多次元データ構造から導出されます。この構造を使用することで、より詳細なレベルを次々にクリックするだけでWebデータを探索でき、様々なディメンション(期間、リファラ、ビジター・タイプなど)別にWebデータを表示できます。このデータ構造は、「データの参照」タブで表示できます。

データ・ブラウザを使用すると、レポートに示されるデータのコンテキストを理解できるとともに、情報をドリルダウン、ランク付け、ソートおよびフィルタすることで原因、結果および傾向を把握することができます。レポート内からデータ・ブラウザを開くには、レポート・メニューから「参照」オプションを選択します。データ・ブラウザを他の場所から開くには、「データの参照」タブをクリックします。図3-1に示すようなウィンドウが表示されます。

図3-1 データ・ブラウザ

データ・ブラウザのツールバー

データ・ブラウザ画面の上部には、図3-2に示すツールバー・アイコンが表示されます。表3-1は、これらのアイコンについて説明しています。

図3-2 データ・ブラウザのツールバー

表3-1 データ・ブラウザのアイコン

アイコン

説明

グラフ。

データの標準グラフ(円グラフ、線グラフまたは棒グラフ)を表示します。グラフの種類は、基になるデータによって異なります。

フィルタを編集します。

フィルタを編集できる新しいウィンドウを開きます。

階層ビュー。

(異なる詳細レベルに対するズーム・インまたはズーム・アウトで使用される)レポート内でのビュー・ディメンションの表示方法を制御します。無効の場合(デフォルト)、ディメンション内のアクティブな詳細レベルのみが表示されます。有効にすると、アクティブな(ズーム)レベルに至るまでのすべてのレベルが表示されます。詳細は、3.6項「階層ビュー」を参照してください。

追加のグラフの種類。

標準的なグラフに加えて、基となるデータによって、追加のグラフの種類を使用できる場合があります。その場合、目的のグラフの種類を選択するには、該当するアイコンをクリックします。

また、「グラフ」メニューの「タイプ」オプションを使用して、グラフの種類を選択することもできます。

値。

ブラウザのデータの基となるデータ値を表示します。値リストの使用方法の詳細は、3.4項「値リストの使用」を参照してください。

前のページおよび次のページ。

これらのコントロールを使用して、表示されたデータセットのページ間を移動します。

用語集。

データ・ブラウザ内に現在示されているメトリックの簡単な説明を表示します。この説明には、グラフまたは値テーブルに示されているディメンションおよび適用されているフィルタの両方が記載されます。フィルタの使用方法は、3.9項「フィルタの使用」に記載されています。

検索。

現在表示されているデータ・セット内の文字列を検索できます。検索機能の使用方法の詳細は、3.5項「データ・ブラウザでの検索」に記載されています。

ズーム・インおよびズーム・アウト。

表示される詳細のレベルを変更できます。ズーム・インおよびズーム・アウトの操作時には、表示されるデータのディメンションを変更します。新しいディメンションは、現在選択されているディメンションによって決まります。たとえば、年次データを表示している場合は、ズーム・イン操作により、月次データの表示に変更されます。クライアントの場所を国別に表示している場合は、ズーム・イン操作により、表示されるディメンションがクライアントの場所が属する国の中のプロバイダに変更されます。

元のディメンションにすばやく戻すには、「ビュー」メニューからビューのリセットを選択します。

レポートとしてオープン。

現在表示されているデータをレポート印刷レイアウト・モードの新しいウィンドウで開きます。レポートの作成とカスタマイズの詳細は、第2章「レポートの操作」に記載されています。

エクスポートとしてオープン。

現在表示されているデータを、各種アプリケーション(Microsoft Excelなど)にエクスポートするにあたってカスタマイズできる新しいウィンドウを開きます。この機能の詳細は、3.11項「データのエクスポート」に記載されています。

ダッシュボードに追加。

選択されているダッシュボードに現在のビューを追加します。この機能の詳細は、5.5項「ダッシュボードへのデータ・ブラウザまたはKPIビューの追加」に記載されています。

戻る/進む。

データ・ブラウザ内での直前のアクションを元に戻す、または繰り返します。

ズームをロック/アンロック。

上位レベルの集計で使用できないディメンション・レベル値を使用して問い合せるため、ビュー・レベルをロック/アンロックします。たとえば、日単位で使用する場合、完全なURLに基づいてフィルタを設定します。通常、このフィルタは、この情報を月単位で使用できないため、月単位にズームアウトする場合に自動的に削除されます。ただし、ズーム・ロックが設定されている場合、月単位のかわりに定義されたフィルタを使用して、30日単位で問い合せられます。

カスタマイズ済ビューを保存します。

カスタマイズ済ビューを、すべてのユーザーがデータ・ブラウザから表示できるように保存します。この機能については、3.13項「ブラウザ・ビューのカスタマイズ」で説明します。

3.2 データ構造の概要

データ・ブラウザ内に表示される情報は、グループ別に分けられます。最上位レベルには、アプリケーション関連グループとサービス関連グループの2つのグループ・タイプがあります。各グループでは、収集されたデータを様々な視点、つまりビューで表示できるようになっています。これらのビューは、データ・ブラウザ・ウィンドウ(図3-1)の左側にある「ビューの選択」パネルから選択できます。

「ビューの選択」パネル内のメイン・グループの1つ1つは、様々な情報カテゴリに関連しています。監視対象のWeb環境でアクセスされたページ、ビジター・セッション、ユーザー・フロー、失敗したURLとページ、およびキー・ページに関するグループがあります。

これらの各グループ内のサブグループには、選択したカテゴリの特定項目に関する情報が表示されます。具体的には、情報が特定のディメンションで表示されます。これらのディメンションは、サブグループの名前に示されます。たとえば、「すべてのセッション」グループには、ドメイン、期間、ユーザーID、クライアント・ブラウザ、言語、場所およびオペレーティング・システムをそれぞれディメンションとしたビューが用意されています。図3-3にこれを示します。

図3-3 データ構造の選択パネル

個々のビューは、表示される情報のタイプを示す標準的な分類(失敗、パフォーマンス、全体およびサイズ)でグループ化されています。これらの中で、基となるデータを調べるために使用するアクティブ・ディメンションを選択できます。

この項で説明されている標準的なディメンションに加えて、カスタム・ディメンションを使用して、データ・ブラウザ内に表示できる情報を拡張することもできます。この詳細は、3.12項「カスタム・ディメンションの使用」に記載されています。

セッション診断機能の詳細は、第4章「セッション診断機能の使用」に記載されています。

3.2.1 リアルタイム・データとセッションベースのデータ

RUEIで対応できる情報には2種類あります。5分間隔で検出されるすべてのアクティブなセッションから導出される情報と、完了した(クローズ)セッションから導出される情報です。それぞれの詳細は次の各項で説明します。

アクティブ・セッションから導出される情報

RUEIでレポートされるほぼすべての情報は、5分間隔で検出されるオープン(アクティブ)セッションに基づきます。1つの例外は、「すべてのセッション」グループでの複数日のレポートです。この詳細は次の項に記載されています。

5分ごとにセッションについてレポートされるプロパティ(IPアドレスやユーザーIDなど)は、実質的には5分間の最後に取得されたスナップショットであることに注意してください。これらのプロパティの値はその5分間内では変動していた可能性がありますが、その期間の最後の値がレポートされます。

クローズ・セッションから導出される情報

「すべてのセッション」グループで複数日についてレポートされる情報は、完了した(クローズ)セッションから導出されます。結果として、この情報には遅延が伴います。遅延が発生するのは、定義されているセッション・アイドル時間が原因です。セッション・アイドル時間は、ビジターのセッションが非アクティブになってから終了したとみなされるまでの期間を指定します。デフォルトでは60分です。

情報がこのようにして導出されるため、5分間隔のレベルにドリルダウンすることはできません。また、ビジター・セッションが午前9時に開始して午後5時に終了する場合について考えてみてください。セッションは、昼食休憩の午後12時から午後1時を除いてずっとアクティブです。通常、このセッションは1つのセッションとしてレポートされます。ただし、「すべてのセッション」グループでの複数日の期間では、2つのセッションとして報告されます。非アクティブな期間があるためです。

レポートされるデータに相違が生じることがある理由

1日についてレポートされるデータと複数日についてレポートされるデータには、わずかな差異が生じる可能性があります。たとえば、ある1日について「すべてのセッション」ビューでレポートされるセッション数は、「すべてのセッション」ビューの2日間に対する表示において、同じ1日についてレポートされる数と若干異なる場合があります。このような差異が生じる理由を理解するためには、1日のデータと複数日のデータが処理される方法を知る必要があります。

図3-4に示す状況について検討します。2名のビジターAとBが両方とも、12:05に閲覧を開始します。Aのセッションは12:45に終了し、Bのセッションは13:55に終了します。ビジターAが14:05に再開し、14:55に終了します。

図3-4 セッションのレポート

時間単位での同時ビジター・セッションの数は、表3-2のようにレポートされます。

表3-2 時間単位のレポート

時刻

セッション

12:00

2(12時から13時には一意のビジターを2名確認)。

13:00

1(13時から14時には一意のビジターを1名確認)。

14:00

1(14時から15時には一意のビジターを1名確認)。

日単位では、2つの同時セッションがレポートされます。ただし、月単位または2日単位で表示すると、セッションの数がレポートされます。この場合、Aの2つのセッションの間にアイドル時間が含まれるため、セッション数は3としてレポートされます。レポートされるセッション数の差異を防ぐには、監視対象のアプリケーションのセッション・アイドル時間と一致するようにセッション・アイドル時間を指定する必要があります。

セッション継続時間、ページ・ロードおよび読取り時間の概要

セッション継続期間は、最後のページがセッション内にロードされた時間から最初のページのロードが開始された時間を引いて計算およびレポートされます。セッション・ロード時間は、セッション内のすべてのページ・ロード時間の合計を表します。セッション読取り時間は、セッション内のすべてのページ読取り時間の合計です。各ページ読取り時間は、最後のヒットがロードされた時間と次のページの最初のヒットの開始の違いとして計算されます。セッションに次のページがない場合、デフォルトの20秒が使用されます。短いセッションの場合、レポートされたページ読取り時間がセッション継続時間より長くなる可能性があることを意味します。図3-5に示す例について考えます。

図3-5 セッションのレポート

ユーザー・フロー

ユーザー・フローの詳細は、9.1項「ユーザー・フローの概要」を参照してください。フローはセッションと同様の方法で追跡され、複数の同時フローがサポートされており、アクティブなフローおよび完了したフローに関するレポートを表示できます。ユーザーがフローの最後のステップを完了するかフローを中断した場合、あるいはセッションがタイムアウトすると、その結果として完了したフローとなります。フロー・レポート・データが予測と異なる場合、次のことを考慮してください。

- 2つの同じフローが別のステップ・アイドル設定で定義されている場合、両方のフローのユーザー動作が同じであっても、レポートされるフロー期間およびフロー・アイドル時間は異なります。

- ユーザーが特定のステップに対して時間が一般的に多く、ステップ・アイドル設定が低い場合は、そのステップに関連するステップ・アイドル時間が多いことがわかります。ステップ・アイドル設定を大きくすると、ユーザー動作に関してより正確な結果が得られます。

- ステップ・アイドル時間中、ユーザーがブラウザを閉じても(あるいはその他の動作を行っても)、RUEIのデータにはこの期間がアクティブ時間として表示されます。

3.2.2 問題分析グループ

問題分析カテゴリのビュー(表3-4を参照)では、アプリケーションの場合、失敗したり問題のあるページ・ビューやヒットに関する詳細な情報が提供されます。それには表3-3に示すグループが含まれます。

表3-3 問題分析グループ

名前

説明

サービス・テスト

実際のエンド・ユーザー・トラフィックに関連するサービス・トラフィックについてレポートします。詳細は、8.3.7項「サービス・テスト・ビーコン・トラフィックのレポート」を参照してください。

URL診断

特定のURLについてレポートします。詳細は、3.2.4項「問題分析のためのURL診断」を参照してください。

失敗したURL

失敗したページ内のオブジェクト(ヒット)についてレポートします。たとえば、破損したイメージや使用できないダウンロードが含まれるページなどです。1分間当たり最大で1000個のオブジェクトが記録されます。該当するオブジェクトのすべての技術エラー(付録D「エラー・コードの説明」を参照)がレポートされます。このビューではアプリケーション情報は使用されないため、アプリケーションが構成されていない場合でも、失敗したページに関して考えられる理由がレポートされます。

失敗したページ

アプリケーションのページで発生したサーバー、ネットワーク、Webサイトおよびコンテンツの各エラーについてレポートします。

遅いURL

オブジェクトのエンドツーエンド時間に基づく、システムによって検出された分ごとに最も遅い1000のオブジェクトに関するレポート。オブジェクトには、このビューでレポートする少なくとも構成された遅いURLのしきい値(デフォルトは2000ミリ秒)のエンドツーエンド時間が必要です。このビューのためにアプリケーションを構成する必要はありません。詳細は、12.5項「遅いURLおよび関数コールのレポートの制御」を参照してください。

失敗した関数

関数コールで発生したサーバー、ネットワーク、Webサイトおよびコンテンツの各エラーについてレポートします。

処理の遅い関数

コールのエンドツーエンド時間に基づく、システムによって検出された分ごとに最も遅い1000のオブジェクトに関するレポート。コールには、このビューでレポートする少なくとも構成された遅いURLのしきい値(デフォルトは2000ミリ秒)のエンドツーエンド時間が必要です。このビューのためにサービスを構成する必要はありません。詳細は、12.5項「遅いURLおよび関数コールのレポートの制御」を参照してください。

スイートURL診断

スイートURL診断およびこれらのデータ・グループが作成されない場合の詳細は、3.2.5項「問題分析のためのスイートURL診断」を参照してください。

注意:
失敗したURL、ページおよびサービス・コールに関する情報の有効期間は、レポータのデータ保存ポリシーによって決定されます。この詳細は、12.10.1項「レポータの保存ポリシーの定義」に記載されています。
RUEI内からのクリックアウトのための外部ユーティリティの構成手順は、4.6項「外部ツールへのクリックアウトの構成」に記載されています。

3.2.3 ページ配信ディメンション

ページ配信ディメンションは、「失敗したページ」、「すべてのページ」、「キー・ページ」の各ビューで使用でき、監視対象のWebサイトで検出されたエラーをレポートします。ページ配信ディメンションでレポートされるすべてのエラーは、セッション診断の再生機能でも表示できます(第4章「セッション診断機能の使用」を参照)。

ページまたはオブジェクトで複数のタイプのエラー(たとえば、ネットワーク・エラーとWebサービス・エラーの両方)が発生した場合、ページ・エラーまたはオブジェクト・エラーは複数回は記録されません。かわりに、エラーは特定の順序(Webサイト、サーバー、ネットワーク、コンテンツの順)でレポートされます。たとえば、Webサイト・エラーとネットワーク・エラーの両方が発生したオブジェクトは、ネットワーク・エラーではなくWebサイト・エラーとして記録されます。

このディメンションでレポートされるエラーは、KPIのベース(カウンタと割合の両方で表されるメトリック)としても使用できます。図3-6にこれを示します。

図3-6 ページ可用性メトリック

アプリケーション違反およびユーザー違反

アプリケーション違反カウンタは、Webサイト、ネットワーク、サーバーおよびコンテンツ・エラーの合計数をレポートします。ユーザー違反カウンタは、コンテンツ通知とクライアント中断の合計数をレポートします。これらのカウンタの使用例は、特定のアプリケーションの一般的な状態を追跡するダッシュボードの作成などです。これらのカウンタは、KPIメトリックとしても使用できます。特定のページ・ビューには、アプリケーション違反およびユーザー違反の両方を含めることができます。

3.2.4 問題分析のためのURL診断

「URL診断」グループは、ページ内の動的オブジェクト(ポートレットやフレームなど)の個別の記録に特に適しています。特定のヒットに関連するリテラルURLをレポートするかわりに、「URL診断」グループは機能URLをレポートします。これらはカスタマイズ可能なレポート方法です。通常は、レポートされたURLからセッション情報や一意の情報は除去されます。

注意:
「URL診断」グループで収集されたデータを他のグループ(「失敗したURL」や「遅いURL」など)で利用することはできません。

このグループで得られる情報を使用すると、ページとは無関係に動的サーバー相互作用URLにアクセスできます。このアプローチには、関連するヒットベースの情報がすぐに見つかるという利点があります。たとえば、JavaまたはPHPベースのコールの監視のみに関心があることを指定できます。これは、診断ユーティリティ(CAMMおよびAD4Jなど)の専用サポートを提供する強力なクリックアウト機能によって補われます。

URL診断の構成はアプリケーション・レベルまたはスイート・レベルで指定します。詳細は8.3.21項「問題分析グループ内のレポートの制御」および3.2.5項「問題分析のためのスイートURL診断」に記載されています。

3.2.5 問題分析のためのスイートURL診断

スイート・カテゴリのビュー(表3-4を参照)では、監視対象スイートの運用に関する詳細な情報が提供されます。各スイート・グループが表示されるかどうかは、構成される少なくとも1つのスイート・インスタンスによって異なります。

インストールおよび構成されている各スイート・タイプについても診断グループを作成でき、アプリケーションに関して「URL診断」グループ(3.2.4項「問題分析のためのURL診断」を参照)で得られる情報と同等の情報が提供されます。

注意:
「スイートURL診断」グループで収集されたデータを他のグループ(「失敗したURL」や「遅いURL」など)で利用することはできません。

スイートURL診断グループの作成の制御

デフォルトでは、スイートURL診断データ・グループは作成されません。作成を有効にするには、次の手順を実行します。

1. 目的のスイート・タイプについて少なくとも1つのインスタンスが定義済であることを確認します。

2. 「構成」→「一般」→「詳細設定」→「スイートURL診断」の順に選択します。目的のスイート・タイプをクリックします。図3-7に示すようなダイアログが表示されます。

図3-7 「E-Business Suite URL診断」ダイアログ

3. 選択したスイート・タイプのURL診断グループに対して、レポートを有効にするか無効にするかを指定します。デフォルトでは、これは無効です。次に、「保存」をクリックします。

有効にしたスイートURL診断グループ内のデータを使用できるかどうかは、定義されたデータ保存ポリシーによって異なります(12.10項「データ保存ポリシーの指定」を参照)。

3.3 データ・ブラウザ・グループへのアクセス

データ・ブラウザの各グループはビジネス関連かIT関連のいずれか(あるいはその両方)です。データ・ブラウザにアクセスできるのは、対応する「分析」アクセス・レベル(以上)の権限を持つユーザーのみです。各データ・ブラウザ・グループのユーザー・タイプ割当てを表3-4に示します。

表3-4 データ・ブラウザ・グループのユーザー・タイプ

カテゴリ

グループ

ビジネス

IT

アプリケーション

Overall

すべてのページ

X

X

すべてのセッション

X

X

ユーザー・フロー完了

X

X

ユーザー・フロー・アクティビティ

X

X

監視対象KPI

X

X

ADFフレームワーク

X

X

Fusion Applications

X

X

Webcenter

X

X

E-Business (Forms)

X

X

Siebel

X

X

PeopleSoft

X

X

JD Edwards EnterpriseOne

X

X

FC Direct Banking

X

X

FC Universal Banking

X

X

WebLogic Portal

X

X

アプリケーション

Problem analysis

サービス・テスト

X

X

URL診断

X

失敗したURL

X

失敗したページ

X

X

遅いURL

X

ADFフレームワーク診断

X

Fusion Applications診断

X

Webcenter診断

X

E-Business (Forms)診断

X

Siebel診断

X

PeopleSoft診断

X

JD Edwards EnterpriseOne診断

X

FC Direct Banking診断

X

FC Universal Banking診断

X

Weblogic Portal診断

X

サービス

Overall

すべての関数

X

Problem analysis

失敗した関数

X

処理の遅い関数

X

3.4 値リストの使用

値リストの使用時に、表示されたリストに列を追加できます。表示されたデータにインジケータ列を追加するには、「値」メニューから「割合の表示」または「成長率の表示」を選択します。これらのオプションを使用できるかどうかは、現在表示されているリストによって異なります。また、リストをレポートとして表示(「ビュー」メニューから「レポートとして開く」を選択)した場合も、列が引き継がれます。

ソート順序の変更

値リストの上部にある列ヘッダーを選択して、ソート順序を変更することもできます。ビューは、選択した列を昇順でソートしたものに変更されます。列ヘッダーを再クリックすると、ソート順序が降順になります。列ヘッダー内の順序記号は、現在の順序を示しています。例を図3-8に示します。

図3-8 ソート順序

包含フィルタと除外フィルタ

値リストでは、項目を右クリックして図3-9に示すメニューを開くこともできます。

図3-9 値のコンテキスト・メニュー

次のオプションがあります。

- 値の選択: 包含フィルタとして選択した値をフィルタ・パネルに追加します。つまり、選択した値と一致する値のみがブラウザに表示されます。

- 値の除外: 除外フィルタとして選択した値をフィルタ・パネルに追加します。つまり、選択した値と一致しない値のみがブラウザに表示されます。

3.5 データ・ブラウザでの検索

検索機能を使用して、現在表示されているデータセット内での文字列の有無を検索できます。図3-10にこれを示します。

図3-10 「検索」タブ

検索機能では、完全一致または部分文字列として指定した検索パターンとの一致が行われます。したがって、検索パターンfireを指定すると、すべてのfireの出現の他に、firefox、x-fireおよびsefirewallの出現とも一致します。

その後、複数セクションコマンド・ボタンをクリックしてから、必要な結果をそれぞれクリックすることにより、1つ以上の結果を使用してデータをフィルタできます。

必要な値を選択したら、画面の下部にあるツールバーを使用して、値を包含フィルタと除外フィルタのいずれにするかを指定できます。また、このツールバーでは、現在定義されているすべてのフィルタを反転したり解除することもできます。

前述のように、検索対象は現在表示されているデータに制限されます。検索を拡張するには、現在のビューを変更するか、適用されているフィルタを解除して、検索を再実行します。一致が見つからなかった場合は、「結果が見つかりません」というポップアップ・ダイアログが表示されます。

注意:
検索機能では、ワイルドカード文字(*など)の使用はサポートされていません。すべての文字がリテラルとして扱われます。結果リストは値リストであり、値リストと同じ機能を持ちます(3.4項「値リストの使用」を参照)。

3.6 階層ビュー

階層ビュー機能は、「データの参照」、「レポート」および「ダッシュボード」内で使用できるトグルとして実装されています。これは(異なる詳細レベルに対するズーム・インまたはズーム・アウトで使用される)レポート内でのビュー・ディメンションの表示方法を制御します。

無効の場合(デフォルト)、ディメンション内のアクティブな詳細レベルのみが表示されます。有効にすると、アクティブな(ズーム)レベルに至るまでのすべてのレベルが表示されます。最低レベルの詳細(ページ名)にズームインしていて、階層ビューが無効になっているアプリケーション・ディメンションのレポートの例としては、次のものがあります。

表3-5 階層ビューが無効化されているアプリケーション・ディメンション

ページ名

ページ・ビュー

index.html

15

次は同じレポートですが、階層ビューが有効になっています。

表3-6 階層ビューが有効化されているアプリケーション・ディメンション

アプリケーション

ページ・グループ

ページ名

ページ・ビュー

Twiki

Home

index.html

10

Twiki

サービス

index.html

4

Twiki

FAQ

index.html

1

階層ビューの有効化/無効化は、ツールバー上のアイコンを使用するか、次に示す「ビュー」メニューで設定できます。

図3-11 「階層ビューの有効化」メニュー・オプション

3.7 データのソート

グラフのデータをソートするには、グラフの下にある凡例から該当するディメンションを選択します。図3-12にこれを示します。

図3-12 凡例

値リスト内でのソートの詳細は、3.4項「値リストの使用」を参照してください。

また、「データ」メニュー内の「ソート」オプションを使用して、指定したソート仕様を元に戻したり(ソートから削除)、現在のソート仕様を反転できます(「ソートの反転」)。

3.8 データ・ブラウザでの取消しとやり直し

データ・ブラウザを使用するとき、タスクバーの「戻る」アイコンと「進む」アイコン(表3-1を参照)を使用すると、それまでの選択動作を元に戻したりやり直したりすることができます。この方法で、直前の動作(フィルタの設定など)を元に戻すことができます。表示するための動作をすべて繰り返す必要はありません。この機能を使用するときは、次の点に注意してください。

- 記憶できる動作は最大で20です。

- セッション診断機能では、「診断の終了」アイコンを使用すると、診断機能を開始する直前のデータ・ブラウザの位置に戻ります。それまでの動作は選択履歴に保存されます。

- データ・ブラウザを離れて他のモジュール(たとえば、構成モジュールまたはレポート・モジュール)を使用しても、データ・ブラウザに戻ると選択履歴が保存されています。

- 「戻る」アイコンを使用して選択を元に戻し、新しい選択を行うと、その時点よりも後の選択履歴は廃棄されます。

- 「ビュー」メニューの「戻る/進むの履歴のリセット」オプションを選択すると、記憶されている表示動作をリセットできます。

3.9 フィルタの使用

データ・ブラウザ・ウィンドウの上部にあるフィルタ・パネルを使用して、表示する情報のプロファイルを制限できます。例を図3-13に示します。

図3-13 フィルタ・パネルの例

フィルタ・パネルの最初の項目は常に、情報が必要な日付または期間になります。図3-13の例では、期間/年の2007がこれに相当します。この項目は、最上位レベルのフィルタとなり、カレンダで変更できます(2.6項「カレンダの使用方法」を参照)。

その後、追加のフィルタを設定できます。フィルタには、包含フィルタと除外フィルタの2種類があります。包含フィルタは、フィルタ内のデータ値と一致するデータ・アイテムのみを表示することを指定します。除外フィルタは、フィルタ内のデータ値とは一致しないデータ・アイテムのみを表示することを指定します。

たとえば、図3-13のフィルタ・プロファイルでは、クライアントの場所がLiechtensteinであり、クライアント・ブラウザがFirefoxでない2007年の情報のみを表示するように指定しています。

異なるディメンションに対するフィルタは、論理AND句の一部とみなされますが、同じディメンションに対する複数のフィルタは、論理OR句の一部とみなされることに注意してください。たとえば、2つの包含クライアント・ブラウザ・フィルタ(「Firefox」用のフィルタと「Chrome」用のフィルタ)を作成すると、KPIはFirefoxブラウザとChromeブラウザの両方によるリクエストを渡します。

3.9.1 フィルタの定義

データ・ブラウザ・ウィンドウ内の任意のデータ・アイテムは、フィルタとして定義できます。それには、データ・アイテムを右クリックして、図3-9に示すメニューを開きます。フィルタは定義した後、クリックして図3-14に示すコンテキスト・メニューを使用し、自由に変更できます。

図3-14 フィルタのコンテキスト・メニュー

次のオプションがあります。

- 反転: 選択した包含フィルタを除外フィルタに変更します(またはその逆)。

- フィルタの反転: 現在定義されているすべてのフィルタの設定を変更します(上記を参照)。

- 削除: 選択したフィルタを解除します。

注意:
フィルタは、定義した順序で適用されます。この順序は、フィルタ・パネルでのフィルタの表示順序でもあり、定義後には変更できません。フィルタの順序を変更するには、フィルタを解除してから、必要な順序で定義しなおす必要があります。

- レポート・フィルタとしてマーク: このオプションの使用方法は、3.9項「フィルタの使用」に記載されています。

- すべて削除: 現在定義されているすべてのフィルタを削除します。

3.9.2 複数のフィルタの使用

値リストでは、複数の値を選択できます。それには、複数選択コマンド・ボタンをクリックしてから、関連リンクを除く必要な値をそれぞれクリックします。選択した項目はハイライト表示されます。例を図3-17に示します。

図3-15 複数の値の選択

必要な値を選択したら、画面の下部にあるツールバーを使用して、値を包含フィルタと除外フィルタのいずれにするかを指定できます。また、このツールバーでは、現在定義されているすべてのフィルタを反転したり解除することもできます。

3.9.3 レポート・フィルタの使用方法

データ・ブラウザから作成したレポートでは、レポート・フィルタを使用できます。レポートに含める情報に対してレポート・フィルタを指定しておくと、レポートを開いたユーザーが、レポートのコンテンツを表示するときに、定義済のフィルタを使用できます。

たとえば、(「すべてのセッション」グループおよび「クライアント|1ブラウザ当たりのページ・ビュー」サブグループを介して)ブラウザ・タイプ情報を表示する場合、ユーザーが特定のブラウザ・タイプを選択できるレポートを作成できます。フィルタを定義する手順は、次のとおりです。

1. 表示された場所のリストから値を選択し、それをフィルタとして定義します。

2. さらにフィルタを追加するには、表3-1で説明されているツールバーのフィルタ・アイコンをクリックし、「追加」をクリックして追加のフィルタを定義します。変更終了後、「保存」をクリックします。

3. フィルタ・パネルに表示された各フィルタを右クリックして、メニューから「レポート・フィルタとしてマーク」を選択します。例を図3-16に示します。

図3-16 レポート・フィルタの例

注意:
複数のフィルタを使用したレポートを設計する場合は、レポートの外観を損わないように注意してください。

4. 「ビュー」メニューから「レポートとして開く」を選択し、必要なレポートの構造を確定します。これで、選択したフィルタがレポート内に表示されます。例を図3-17に示します。

図3-17 フィルタを使用したレポート

5. マウス・ポインタをフィルタ上に置いてフィルタをハイライト表示し、メニューから「フィルタ・タイプの編集」を選択します。図3-18に示すようなダイアログが表示されます。

図3-18 「フィルタ・タイプの編集」ダイアログ

6. 「フィルタ・タイプの編集」ダイアログに表示されたチェック・ボックスを使用してフィルタを設定し、ユーザーがレポートを開くときに選択できるようにしておきます。定義したレポート・フィルタごとにチェック・ボックスが表示されます。次に、「適用」をクリックします。

7. 2.11項「新規レポートの作成」の説明に従って、レポートを保存します。

レポートの実行

レポートが開かれ、レポート・フィルタが有効になると、レポートをフィルタするための1つ以上の値を選択できます。例を図3-19に示します。

図3-19 レポートでのフィルタの使用

3.9.4 拡張フィルタの使用

必要な結果のみを表示するようフィルタを組み合せて、より複雑なロジックを持つフィルタ・セットを作成するのに役立つ場合があります。たとえば、2つのIPアドレスのいずれかからの結果のみを表示するが、アプリケーション言語が英語である結果のみを表示するフィルタを作成できます。この例を図3-17に示します。

図3-20 拡張フィルタ

拡張フィルタを作成するには:

1. 表3-1で説明されているツールバーのフィルタ・アイコンをクリックして、現在適用されているすべてのフィルタを表示します。

2. フィルタ画面の「拡張モード」ボタンをクリックします。

3. 新規フィルタを作成するには、プラス・アイコンをクリックします。

4. 新規グループを作成するには、グループ・プラス・アイコン(+)をクリックします。各グループには独自のロジックがあり、たとえば、「OR」グループには、個々のフィルタ基準のいずれかを満たす場合に結果を生成するフィルタ・セットを含めることができます。

5. 「AND」」から、「OR」にグループを変更するには、グループ・ラベル・テキストをクリックします。たとえば、「AND」をクリックすると、そのグループ・ロジックは「OR」に変更されます。

これらの拡張フィルタはレポートで使用できますが、ダッシュボードまたはKPI定義では使用できません。

3.10 異なる期間を対象とするデータの比較

ある期間に関するデータを、同等の期間と比較できると便利な場合があります。たとえば、トラフィック・レベルの比較またはページ・エラーの発生率を比較できます。次を実行します。

1. 「データの参照」を選択し、目的のグループを選択します。

2. カレンダ・コントロールを使用して、有効な期間を選択します。これらのコントロールの使用方法は、2.6項「カレンダの使用方法」に記載されています。比較する2つの期間をオーバーラップさせないでください。たとえば、それぞれが2日間からなる2つの期間を比較するとき、両期間の間隔が1日しか離れていない場合は比較できません。

3. オフセットの比較メニューを使用して、有効な期間に対して比較する期間を選択します。使用可能なオプションは選択した期間単位(日、週、月)によって異なります。直前の50期間まで選択対象とすることが可能です。

4. 「ビューの選択」パネルから目的のビューを選択します。図3-21に期間の比較の例を示します。

図3-21 2つの期間を対象とするオブジェクトのパフォーマンスおよびヒットの比較

5. 必要に応じて、ツールバーの「棒チャート」、「折れ線チャート」または「値」アイコンを使用して、比較のグラフを変更します。ただし、他のグラフ(円グラフなど)は比較には使用できず、棒グラフや折れ線グラフの表示データには制限事項が適用されます。値リストでは、比較分析用の行が追加作成されます。本期間の値が比較期間の値よりも大きい場合、比率値は緑色で表示されます。それ以外の場合は、赤色で表示されます。例を図3-22に示します。

図3-22 値リストの比較の例

3.11 データのエクスポート

データ・ブラウザに現在表示されているデータは、スプレッドシートなど、様々なアプリケーションにエクスポートできます。データのエクスポートの操作を開始するには、「エクスポートとして開く」アイコンをクリックするか、「ビュー」メニューから「エクスポートとして開く」を選択して、エクスポート・ウィンドウを開きます。現在のデータが表示された新しいウィンドウが開きます。例を図3-23に示します。

図3-23 エクスポート・ウィンドウ

多数の項目のエクスポート

Microsoft Excelへは最大で5000の項目を直接エクスポートできます。この制限の回避策として、次の手順を実行することをお薦めします。

1. 目的のビューをレポートとして保存します。それには、ツールバーの「レポートとして開く」アイコンをクリックし、開いたウィンドウの「ファイル」メニューから「新規として保存」オプションを選択します。

2. 「システム」→レポート・データのエクスポートの順に選択します。新たに作成されたレポートを選択します。この機能の使用方法は、2.13項「レポート・データのエクスポート」に記載されています。

3. レポートの選択時に表示されたURLをコピーし、その末尾に文字列&output=xlsを追加します。

4. 作成したURLを使用して、完成したMicrosoft Excelエクスポートにアクセスします。

3.11.1 エクスポートするデータの変更

エクスポート・ウィンドウ(図3-23)には、エクスポート可能なRAWデータが表示されます。ここで、データのエクスポート方法をカスタマイズできます。それには、エクスポート・ウィンドウ内で右クリックして「編集」を選択します。図3-24に示すようなダイアログが表示されます。

図3-24 「エクスポートのカスタマイズ」ダイアログ

このダイアログでは、データ列の順序やデータ列での値の表示順序を変更したり、Microsoft Excelエクスポートに表示する追加の列を指定できます。

「データ列」フィールドと「値列」フィールドでは、リストを使用して、1次索引列と1次索引列に表示するデータ列を追加できます。各リストで使用可能なデータ列と値列の選択は、使用しているビュー・グループによって厳密に決定されます。たとえば、すべてのクライアント・グループでデータを表示している場合は、Webサイトおよびページのデータ列は、ドメインとWebサイトの場合にのみ選択できます。ただし、「すべてのページ」グループで作業している場合は、ページ・コンテンツやページ・ユーザー・フローなどの項目に追加のデータ列も使用できます。各ビュー・グループ内のエクスポート可能なデータ列と値列の詳細は、付録E「データ・アイテムの概要」を参照してください。

「割合」チェック・ボックスでは、レポートされる値が占める割合構成を示す列を、エクスポートに追加するかどうかを指定できます。

「増加」チェック・ボックスでは、レポートされるメトリックの実増値を示す列を、エクスポートに追加するかどうかを指定できます。

移動合計チェック・ボックスを使用すると、ユーザー・フローの累積合計を示す列をエクスポートに追加するかどうかを指定できます。このオプションは、(「ユーザー・フロー完了」グループの「ユーザー・フロー」ビューから使用可能な)ファンネル・グラフにのみ適用されます。

データ列の選択項目の横にある「上へ」、「下へ」および「削除」アイコンを使用して、ソート順序階層を制御したり、データの索引としてのデータ列を削除できます。同様に、値列フィールド内の同じコントロールを使用して、エクスポートでの値列の表示順序を並べ替えられます。

エクスポートは、新規ファイルまたは既存ファイルに保存したり、既存のエクスポートに追加できます。

3.11.2 エクスポート書式の選択

エクスポートするデータの表示方法を制御できるのみでなく、データのエクスポート書式も指定できます。それには、「ダウンロード」メニューを選択します。次のエクスポート形式が使用可能です。

- カンマ区切り値(CSV)。

- タブ区切り値(TSV)。

- Microsoft Excel(2000互換)ワークシート。

- Webquery書式。

エクスポートされたデータはUnicode(UTF-8)形式になることに注意してください。

3.12 カスタム・ディメンションの使用

カスタム・ディメンションを使用すると、データ・ブラウザのビューに独自のユーザー定義ディメンションを追加できます。この新しいディメンションは、レポートおよびエクスポートにおいてのみでなくKPIでも使用できるようになります。たとえば、組織の仕入先をより簡単に追跡および分析できるように、supplierというディメンションを追加できます。この機能を使用して、主要業務で顧客転換率が最も高い商品の仕入先や、組織のWebサイトで最もページ・ビューの多い仕入先を判別できます。問題ベースのカスタム・ディメンションは、主にアプリケーションをデバッグする目的のために使用することに注意してください。

注意:
カスタム・ディメンションは、ページベース、セッションベース、機能ベース、ユーザー・フロー・ベースまたは問題ベースにすることができます。KPIはリアルタイム・データに基づくため、セッションベースのカスタム・ディメンションはKPIのメトリックとしては使用できません。ただし、ページベースのカスタム・ディメンションはKPIフィルタとして使用できます。

カスタム・ディメンションのレポート

各カスタム・ディメンションには一意の名前があり、ページ、セッション、機能、ユーザー・フローまたは問題をベースとしています。カスタム・ディメンションにより、レポートが行われるデータ・ブラウザ・グループが決まります。また、次の項で説明するように、ディメンション情報がページ・ビュー間でどのように保存されるかが決まります。データ・ブラウザ・グループにおけるカスタム・ディメンションのレポートを、表3-7に示します。

表3-7 データ・ブラウザ・グループにおけるカスタム・ディメンションのレポート

ソース

すべてのページ

キー・ページ

すべてのセッション

失敗したページ

失敗したURL

遅いURL

処理の遅い関数

すべての関数

失敗した関数

(名前付き)スイート

URL診断

すべてのユーザー・フロー

ページ

X

X

X

X

X

X

X

X

ページ(セッション対応)

X

X

X

X

X

X

X

セッション

X

X

X

X

X

X

機能

X

X

問題分析

X

X

X

X

ユーザー・フロー

X

セッションベース・カスタム・ディメンション情報をリアルタイムで(セッションと同じ日に)再確認すると、レポートされるユーザー名が変わることがあります。複数日について同じ情報を表示すると、レポートされるユーザー名はセッションの最後に検出されたユーザー名に基づきます。

ディメンション情報の保存

前に説明したように、カスタム・ディメンションが基づくエンティティ(ページ、セッション、機能、ユーザー・フローまたは問題)によって、ディメンション内の情報がページ・ビュー間で保存される方法が決まります。ここでは、選択した方法がカスタム・ディメンション情報のレポートにどのように影響するかを詳しく説明します。サンプルのビジター・セッションのデータに基づいて説明します。各サンプル・セッションは、販売カタログを含む監視対象のWebサイトを参照します。カタログ内のどのコレクションをビジターが表示しているかという情報を取得するために、3レベルのカスタム・ディメンションが定義されています。これら3つのレベルは3つの引数a、bおよびcから導出されます。

カスタム・ディメンションがページベースとして指定されると、表3-8の値がレポートされます。

表3-8 ページベースのカスタム・ディメンション情報の保存

入力

ディメンション・レベル

1(a)

2 (b)

3 (c)

a=男性用

男性用

'(値なし)'

'(値なし)'

a=男性用、b=コート

男性用

コート

'(値なし)'

a=男性用、b=コート、c=冬物

男性用

コート

冬物

a=男性用、b=帽子

男性用

帽子

'(値なし)'

a=男性用、b=帽子、c=フェルト帽

男性用

帽子

フェルト帽

a=子供用

子供用

'(値なし)'

'(値なし)'

この方法を使用しているとき、カスタム・ディメンション・レベルについてレポートすると、現在のページ・ビューの情報のみが使用されることがわかります。前のページ・ビューから継承される情報はありません。

カスタム・ディメンションがページベース(セッション対応)として指定されると、表3-9の値がレポートされます。

表3-9 ページベース(セッション対応)のカスタム・ディメンション情報の保存

入力

ディメンション・レベル

1(a)

2 (b)

3 (c)

a=男性用

男性用

'(値なし)'

'(値なし)'

(a=男性用、)b=コート

男性用

コート

'(値なし)'

(a=男性用、)(b=コート、)c=冬物

男性用

コート

冬物

(a=男性用、)b=帽子

男性用

帽子

'(値なし)'

(a=男性用、)(b=帽子、)c=フェルト帽

男性用

帽子

フェルト帽

a=子供用

子供用

'(値なし)'

'(値なし)'

ここでは、カスタム・ディメンションのレベル情報がページ・ビューにないと、情報が前のページ・ビューから継承されていることがわかります。継承はカッコによって示されます。カッコ内の情報は現在のページ・ビューには含まれないため、前のページ・ビューから導出されています。

カスタム・ディメンションがセッションベースとして指定されると、表3-10の値がレポートされます。

表3-10 セッションベースのカスタム・ディメンション情報の保存

入力

ディメンション・レベル

1(a)

2 (b)

3 (c)

b=コート

'(値なし)'

コート

'(値なし)'

b=コート、c=冬物

'(値なし)'

コート

'(値なし)'

c=冬物

'(値なし)'

'(値なし)'

冬物

......

'(値なし)'

'(値なし)'

'(値なし)'

この例では、カスタム・ディメンション情報の継承が発生していないことがわかります。また、この方法を使用すると1つのページ・ビューしかレポートできないことに注意してください。これは、カスタム・ディメンション情報が存在する最初のページ・ビューです。このケースでは、これは表示履歴の最初のページです('(値なし)' » コート » '(値なし)')。他のページ・ビューのすべてのカスタム・ディメンション情報は廃棄されます。表3-8、表3-9および表3-10は、いずれも1つのセッションを参照していることに注意してください。

カスタム・ディメンションの説明

必要に応じて、ディメンション・レベルでレポートされる一意の各ソース値に対して一連の翻訳を定義することもできます。たとえば、表3-11に示すように、サービスベースのカスタム・ディメンションである「サーバーID」を定義して、それに説明を関連付けることができます。

表3-11 カスタム・ディメンションの説明の例

値

説明

178349

ビジネス・パートナシップ

561808

ニュースレターとイベント

405969

カタログ

969533

支払い処理

カスタム・ディメンションの定義

カスタム・ディメンションを定義する手順は、次のとおりです。

1. 機能ベースのカスタム・ディメンションの場合は、「構成」→「サービス」→「カスタム・ディメンション」の順に選択します。アプリケーションベースのカスタム・ディメンションの場合は、「構成」→「アプリケーション」→「カスタム・ディメンション」の順に選択します。現在定義されているカスタム・ディメンションのリストが表示されます。ユーザー・フローベースのカスタム・ディメンションは最大で2個、ページベースまたはセッションベースのカスタム・ディメンションは最大で5個定義できます。機能ベースのカスタム・ディメンションは最大で10個定義できます。「新規ディメンション」コマンド・ボタンをクリックします。図3-25に示すようなダイアログが表示されます。

図3-25 「新規カスタム・ディメンション」ダイアログ

2. 新しいディメンションに一意の名前を指定します。定義したカスタム・ディメンションが組み込まれる画面(データ・ブラウザやレポートなど)では、ディメンションの名前にアスタリスク(*)が付けられます。

3. 「基準」メニューを使用して、ディメンションのベースとするエンティティ・タイプを指定します。機能ベースのディメンションの場合は、機能がベースとして自動的に選択され、変更できません。アプリケーションベースのディメンションの場合は、ベースとしてページ、ページ(セッション対応)、セッション、ユーザー・フローまたは問題分析を選択できます。これらのオプションの使用方法は前の項に記載されています。ページベース、セッションベース、ユーザー・フローベースまたは問題ベースのカスタム・ディメンションは最大で5個定義でき、機能ベースのカスタム・ディメンションは最大で10個定義できます。

4. 「レベル数」メニューを使用して、保存するディメンション情報のレベルを指定します。デフォルトでは、定義したカスタム・ディメンションに対して保存される情報は1レベルのみです。ただし、この機能を使用することで、保存するセッション情報の階層を構築できます。たとえば、国、リージョンおよび市区町村の3つのレベルを使用して、ユーザーの場所に関する情報を取得できます。最大で4つのレベルがサポートされます。

5. 「カスタム・ディメンションが有効です」チェック・ボックスを使用して、このカスタム・ディメンションの処理を有効化または無効化します。

6. 表示される「レベル」タブに、ディメンション・レベルの名前を指定します。カスタム・ディメンションを格納するRUEI表内の列名を、「DB列名」フィールドに入力します。

7. 「ソースの追加」をクリックして次の画面に入力し、1つ以上のソースをカスタム・ディメンションに追加します。

図3-26 「カスタム・ディメンション・レベル・ソースの追加」ダイアログ

「ソース」メニューと「ソース値」フィールドを使用して、ディメンションを検索する範囲を指定し、検索でXPath式、ヘッダー、Cookie、HTMLタイトル、URL、URL引数(リクエスト)、またはカスタム・タグあるいは関数を使用するかどうかも指定します。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。ソースがURL引数の場合は、RAW入力(元の入力)が使用されます。ただし、HTTPヘッダーの場合は、ASCII入力のみが許可されます。非ASCII文字は、レポート時にアンダースコア(_)文字で置き換えられます。エンコーディング・サポートの詳細は、付録G「各国語サポートの使用」を参照してください。

カスタム・タグまたはカスタム関数のオプションを選択した場合は、タグまたは関数の名前を「ソース値」フィールドに指定する必要があります。カスタム関数の場合は、最初のパラメータのみが使用されることに注意してください。パラメータは単一引用符または二重引用符で囲む必要があります。次に例を示します。

wiViewState("wi_menu_main_menu");

カスタム・タグおよびカスタム関数がページ内でどのように解釈されるかの詳細は、付録A「タグ付け規則」を参照してください。

次に、「保存」をクリックします。定義したカスタム・ディメンションの概要が表示されます(図3-27を参照)。

図3-27 カスタム・ディメンションの概要

8. 必要に応じて、カスタム・ディメンションの規則指定を編集できます。そのためには、既存のソースをクリックします。図3-29に示すダイアログが表示されます。

図3-28 カスタム・ディメンション規則指定の編集

規則指定の概要は、第8.3.5項「規則指定機能の使用方法」を参照してください。

9. 必要に応じて、ディメンション・レベルでレポートされる一意の各ソース値に対して一連の翻訳を定義することもできます。それには、「新規翻訳の追加」をクリックします。図3-29に示すダイアログが表示されます。

図3-29 翻訳の追加

必要なソース値とその説明を指定します。次に、「保存」をクリックします。

インポートする説明のリストが非常に大きい場合は、図3-27の下部のツールバーにあるコントロールを使用して画面をスクロールできます。また、検索機能を使用して、必要な説明を検索できます。検索文字列には、ソース値または説明を指定できます。ワイルドカード文字(*など)の使用はサポートされておらず、すべての文字がリテラルとして扱われます。

説明のリストのインポート

それぞれの説明を別々に定義するかわりに、(図3-27の下部にある)ツールバーの「アップロード・リスト」アイコンをクリックして、説明のリストを含むファイルをインポートできます。図3-30に示すダイアログが表示されます。

図3-30 カスタム・ディメンションの翻訳のアップロード

「参照」ボタンを使用し、目的のファイルを検索して選択します。必要に応じて、「ファイル・エンコーディング」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。ファイルには、ソース値とその説明をタブで区切って、1行に1つの説明のみを含めることができます。次に、「マージ」をクリックします。

注意:
また、カスタム・ディメンション機能を使用して、標準ディメンションの機能を再定義することもできます。

カスタム・ディメンションでレポートされるフォールバック値

カスタム・ディメンションでは、次の2つのフォールバック値をレポートできます。

- '(値なし)': カスタム・ディメンションに定義されたソースがページまたは関数コール内で見つからなかったことを示します。

- 不明: 定義済のソースがページまたは関数コールの指定期間後に定義されたことを示します。たとえば、カスタム・ディメンションが月曜日の1:00PMに定義された場合、日次ビューには1:00PMより前の期間については「不明」と示されます。週と月のビューでは、カスタム・ディメンションが定義される前の期間について簡単にレポートされます。

3.12.1 カスタム・ディメンションの削除

カスタム・ディメンションを削除する手順は、次のとおりです。

1. アプリケーションベースのディメンションの場合は、「構成」→「アプリケーション」→「カスタム・ディメンション」の順に選択します。機能ベースのディメンションの場合は、「構成」→「サービス」→「カスタム・ディメンション」の順に選択します。現在定義されているカスタム・ディメンションのリストが表示されます。目的のカスタム・ディメンションを右クリックし、メニューから「削除」を選択します。

2. カスタム・ディメンションをKPIまたはレポートでフィルタとして使用している場合は、カスタム・ディメンションを削除すると、関連付けられているKPIまたはレポートも削除されることを警告するメッセージが表示されます。「はい」または「いいえ」をクリックします。

3.13 ブラウザ・ビューのカスタマイズ

RUEIデータ・ブラウザには、カスタム・レポートやデータ・エクスポート定義の基礎として使用できる一連の標準ビューが含まれています。レポートまたはデータ・エクスポート定義をカスタマイズした場合、そのカスタマイズ内容をデータ・ブラウザで使用できるように、カスタマイズ済ビューとして保存できます。新しく作成したカスタマイズ済ビューは、図3-3に示すパネルのカスタム分類またはサブグループ内のオプションとして表示されます。

注意:
カスタマイズ済ビューは、値の表としてのみ表示されます。

カスタマイズ済ビューを作成するには、保存済のレポートまたはエクスポートを使用する方法と、エクスポート定義を編集する方法の2通りあります。

注意:
カスタマイズされたビューを作成できるのは、管理者アクセス権を持つユーザーだけです。データ・ブラウザ・アクセス権を持つすべてのユーザーは、カスタマイズされたビューをすべて表示できます。

保存されているレポートを使用してカスタマイズされたビューを作成するか、エクスポートするには:

1. 2.11項「新規レポートの作成」の説明に従ってレポートを作成するか、3.11項「データのエクスポート」の説明に従ってデータ・エクスポート定義を作成します。

2. 「レポート」を選択してからレポートまたはエクスポート定義を選択して、手順1で作成したレポートまたはエクスポート定義を開きます。

3. 値の表を右クリックして「参照」をクリックし、データ・ブラウザに移動します。

4. (表3-1に示す)「保存」アイコンをクリックします。

エクスポート定義を使用してカスタマイズ済ビューを作成する手順は、次のとおりです。

1. 3.11項「データのエクスポート」の説明に従って、データ・エクスポート定義を作成します。

2. 図3-23に示すエクスポート定義を表示する場合、値の表を右クリックして「編集」をクリックします。

3. ディメンションを追加するなどして、エクスポート定義を変更します。

4. 変更済のエクスポート定義が表示された状態で、値の表を右クリックして「参照」をクリックすると、データ・ブラウザに移動します。

5. (表3-1に示す)「保存」アイコンをクリックします。手順3でエクスポート定義を変更していない場合、「保存」アイコンは表示されません。

4 セッション診断機能の使用

この章では、セッション診断機能の使用方法について説明します。これには、アプリケーション・マネージャとIT技術スタッフが業務上の問題の根本原因分析を行うために使用できる強力な方法が備わっています。セッション・パフォーマンス・ブレークダウンがサポートされ、失敗したページやヒットがセッションに及ぼす影響、失敗した各ページの完全なコンテンツ、さらにオブジェクト、ページ・ビュー、セッションの関係などが表示されます。Webサービスを診断して関数コールの失敗を調査することも可能です。スイートURL診断を使用可能にするには、個別に有効にする必要があります。この詳細は、3.2.5項「問題分析のためのスイートURL診断」に記載されています。

4.1 概要

セッション診断機能では、問題が特定されると、ユーザーがRUEIの大規模なデータ構造をドリルダウンして、その問題がWebサイトのビジターおよびWebサービス・クライアントに及ぼす影響を評価するとともに、考えられる原因を直接見極める手段を得ることができます。

重要:
完全なユーザー・セッションを再生するには、セッション記録を有効にする必要があります。この詳細は、13.10項「リプレイ・ポリシーの制御」に記載されています。

エラー記録機能

これまでに説明した情報に加えて、RUEIでは、監視対象Webサイトのビジターがどのようなエラー・メッセージをいつ受け取ったかを正確に追跡することができます。この機能を使用してアプリケーションの失敗を再現することで、Webページで不備や問題のある箇所を正確かつ早急に除去できます。

セッション・レポートの概要

ユーザー・セッションに関する情報は、セッション診断機能においてはユーザー・レコードとしてレポートされます。情報は5分間隔でレポートされることを理解してください。IPアドレスやユーザーIDなどのセッション関連プロパティは、実質的には5分間隔の最後に取得されたスナップショットです。これらのプロパティの値はその5分間内では変動していた可能性がありますが、その期間の最後の値がレポートされることに注意してください。

セッション診断の使用

必要な診断情報を検索する手順は、次のとおりです。

1. 「データの参照」を選択し、最初のグループ(「すべてのセッション」など)を選択します。診断情報は、表4-1に示すグループおよびスイート固有のグループ(Oracle E-Business SuiteおよびSiebelなど)に使用できます。必要な診断オプション(「セッション診断」など)をクリックします。選択したグループがオプションの名前に反映されることに注意してください。図4-1に示すような診断パネルが表示されます。

図4-1 診断パネル

2. カレンダ・コントロール(2.6項「カレンダの使用方法」を参照)を使用して、目的の期間を選択します。表示範囲としては1日(または未満)を選択する必要があります。この制限外で検索しようとするとエラーが発生します。再生コンテンツの有無は、対応するコレクタの保存ポリシー(13.9項「コレクタのデータ保存ポリシーの定義」を参照)およびセッション診断保存設定(12.10.1項「レポータの保存ポリシーの定義」を参照)によって異なります。

3. 検索機能を使用して、目的のユーザー・レコードを検索します。使用可能な基準は、選択したグループによって異なります。使用できる汎用的な検索基準を表4-1に示します。追加のディメンションは、スイート固有のデータ・グループにも使用できます。
最初の100個の項目のみがセッション・ウィンドウ内にリストされます。「次へ」および「前へ」コントロールを使用して、セッション・リストをスクロールできます。「診断の終了」アイコンを選択すると、セッション診断機能を開始する直前のデータ・ブラウザに戻ります。1つ以上の検索フィルタが必要です。

表4-1 診断の検索基準

データ・ブラウザ・グループ

すべてのセッション

失敗したページ

失敗したURL

サービス・テスト

遅いURL

処理の遅い関数

失敗した関数

ユーザー・フロー・アクティビティ

ユーザー・フロー完了

アプリケーション名

•

•

•

ビーコン名

•

クライアントIPアドレス

•

•

•

•

•

クライアント・ネットワーク

•

ECID

•

•

オブジェクト配信

•

•

•

オブジェクトURL

•

•

ページ配信

•

サービス配信

•

•

サービス名

•

•

•

ユーザー・フロー名

ユーザーID

•

•

•

•

オプションとして、「フィルタの追加」機能を使用して追加の検索基準を指定できます。最初の検索基準と同じく、追加の検索フィルタ・オプションも選択したグループによって異なります。すべての基準が一致しないと、一致したユーザー・レコードはレポートされないことに注意してください。すべてのフィールドでワイルドカードを使用できます。

様々な診断グループについて、一致したユーザー・レコードのレポート順序を「検索結果の順序」機能で指定することもできます。次に、「検索」をクリックします。検索結果がウィンドウの主要部に表示されます。例を図4-2に示します。

図4-2 「セッション診断」ウィンドウ

4. 上部にあるツールバーのコントロールを使用して、結果ページ間で移動できます。ページ・コントロールの横に、検出された合計セッション数とページ数が(「43478アイテムが見つかりました。ページ1/435を表示。」のように)表示されます。
「ソート」メニューを使用して、結果のソートを変更します。1ページ当たり最大で100ユーザー・レコードがリストされます。表示リストの特定のユーザー・レコードをクリックして選択できます。

オプションで、「ディメンション・レベル」メニューおよび「値」メニューを使用すると、表示リストにさらにフィルタを適用できます。次に、「追加」をクリックします。「ディメンション・レベル」メニューのオプションは、選択したグループによって異なります。

図4-2に示すユーザー・レコード・コンテキスト・メニュー内の「セッションのエクスポート」オプションの使用方法の詳細は、4.4項「すべてのセッション情報のエクスポート」に記載されています。

URLベースのグループにセッション診断を実行すると、たとえば、遅いURL、失敗または遅いリクエストがセッションのかわりに一覧表示されます。選択されると、関連付けられているセッションが表示されます。

5. ユーザー・レコードを選択した後、ウィンドウの左側のパネルにある「ビュー」の部分に、選択したユーザー・レコードの情報を表示できます。「セッション」の下の「ページ」、「オブジェクト」および「情報」項目を使用して、選択したユーザー・レコードに関する特定の情報を表示します。例を図4-3に示します。

図4-3 診断パネルの例

セッション・ページはグループ分けされており、展開すると関連するオブジェクトが表示されます。選択したユーザー・レコード内に記録されたページおよびアクション(およびその時間)の概要が表示されます。アイコンによって、処理が遅いオブジェクトまたは失敗したオブジェクト、ページ・ロード満足度、キー・ページかどうか、再生コンテンツの有無が示されます。Replay Viewerの使用方法は、4.2項「ユーザー・セッションの再生」に記載されています。

ツールバーの擬似オブジェクトを含む/除外アイコンを使用すると、レポートされるページに直接関連していないヒットをオブジェクトの表示リストに含めるかどうかを制御できます。この機能は、ロード時間が非常に長くかかる問題のオブジェクトを特定するときに特に役立ちます。通常、このようなオブジェクトにはページが関連していないため、セッション・ページ・レポートには表示されません。

「エクスポート・セッション・ページ」コマンド・ボタンを使用すると、現在選択されているユーザー・レコードのサマリーをMicrosoft Excelにエクスポートできます。この機能の使用方法の詳細は、4.3項「Microsoft Excelへのセッション・ページのエクスポート」に記載されています。

6. パネルの「ビュー」の下にある「ページ」オプションまたは「オブジェクト」オプションをクリックすると、ビジターが表示したページのサマリー、またはそれらのページ内のオブジェクトを確認できます。表示されているリスト内の項目をクリックすると、詳細プロパティ情報とともにウィンドウが開きます。
図4-4にページ・プロパティの例を示します。

図4-4 「ページ・プロパティ」ダイアログの例

図4-5にオブジェクト・プロパティの例を示します。

図4-5 「オブジェクト・プロパティ」ダイアログの例

表示される履歴では、すべてのコンテンツの他に、サーバーやクライアントで受信されたメッセージの基礎となるHTTPコードも表示されます。レポートされるコンテンツは、HTTPプロトコル項目に対して現在定義されているマスキング・オプションによって変化することに注意してください。使用可能な場合、ECID脚注1がオブジェクトに表示されます。関連する場合、Formsクライアントおよびサーバー情報とクライアントが送信したPOSTメッセージも表示されます。ページまたはURLのアプリケーション関連およびセッション関連の詳しい情報は、「情報」オプションで表示されます。例を図4-6に示します。

図4-6 セッション情報の例

スイート関連情報(関連する場合)も表示されます。

7. 次に、選択したユーザー・レコードの右にある「削除」アイコンをクリックします。図4-2に示す診断ウィンドウに戻ります。ここで、他のユーザー・レコードを選択してドリルダウンできます。

セッション診断機能での機密情報のマスキング

前述のように、セッション診断機能での情報(ヘッダーやURL情報など)の表示または非表示は、適切なHTTPプロトコル項目のマスキング機能によって制御できます。この詳細は、13.9項「コレクタのデータ保存ポリシーの定義」に記載されています。

セッション診断のWebサービス

アプリケーションと同じセッションで重複するWebサービスを定義した場合、セッション・ページ情報の一部としてレポートされます。例を図4-7に示します。

図4-7 セッション診断のWebサービス・コールの例

Webサービス・コールは、個々のページではなくページの一部としてのみレポートできます。

ユーザー・フロー診断内のユーザーID

ユーザー・フロー診断グループ内で、2つの追加のユーザーIDがレポートされます。これらは表4-2で説明しています。

表4-2 ユーザー・フロー内のユーザーID

ユーザーID

説明

なし

ステップ遷移がページ・ビューで終了しなかったか(たとえば、ユーザーがアイドルになるなど)、エラーが外部または中断ページで発生しました。

使用不可

短期間にレポートされたエラーのバーストがありました。

4.2 ユーザー・セッションの再生

表示しているページの横に「リプレイ」アイコンがある場合には、それをクリックすると完全なユーザー・セッションを再生できます。こうすることで、ビジターがセッション中に表示した各ページとレポートされたエラー・メッセージを確認できます。例を図4-8に示します。

図4-8 セッション再生の例

再生の詳細は、メイン・ウィンドウと同じサイズの新しいウィンドウに表示されます。選択したユーザー・レコード内でページの「リプレイ」アイコンをクリックして選択した場合、表示されるページ履歴は選択したページから開始します。

ページ表示の下のコントロールを使用して、ページ履歴をナビゲートできます。「ページ情報」セクションには、現在表示されているページのロード満足度、キー・ページかどうか、およびエラーの有無が示されます。

ページ・イベントのレポート

表示されたページにHTTPフォーム要素が含まれる場合、フォーム要素とビジターの応答が「ページ・イベント」パネルにレポートされます。名前のない要素は"NO_NAME_number"としてレポートされます(numberは名前のない要素ごと1つずつ増えます)。非表示のフォーム要素もレポートされます。フォーム要素に対するビジターの応答は、セッション・ページ表示履歴の次のページのリクエスト本文から導出されることに注意してください。したがって、ビジターが、リクエスト・ページとレスポンス・ページの間で別のページにコンテキストを切り替えた場合、ユーザーの応答は抽出できずレポートされません。

図4-8の下部のステータス・バーには、セッション・ユーザーID、ページごとに記録されたタイムスタンプ、ロード時間、オブジェクト数に関する情報が表示されます。また、静的ページの場合には、レポートされたページがライブ・ソース(アプリケーション・サーバーなど)から取得されていることも示されます。

ページ・コンテンツの表示

ツールバーの「HTTPコンテンツ」コマンド・ボタンを使用すると、現在選択されているページの実際のリクエスト・コンテンツとレスポンス・コンテンツを表示できます。例を図4-9に示します。

図4-9 ページ・コンテンツの例

ページ・コンテンツ内のリンクをクリックすると外部のJavaScriptファイルも表示できることに注意してください。このようなファイルのレポートされるコンテンツは、ライブ・ソース(たとえばアプリケーション・サーバー)から取得されます。

静的ページ・コンテンツの表示

表示される表示履歴でページの横に「リプレイ」アイコンがない場合は、ページのコンテンツがないことを意味します。これは、データ保存制限のために情報が期限切れになったため、または表示したページが静的ページだったためです。静的ページの場合は、静的ページのコンテンツを表示できます。表示履歴で静的ページの直前または直後のページをハイライト表示し、そのページから静的ページのコンテンツを表示します。

静的ページのオブジェクトについてレポートされるコンテンツは、ライブ・ソースから取得されることに注意してください。このため、なんらかの理由でライブ・ソースが使用できないと、ページのコンテンツが正しくレポートされないことがあります。また、データ・マスキングやJavaScript実行ルールは、ライブ・ソースから取得されるページ・コンテンツには適用されません。ページ・コンテンツは現状のままで表示されます。静的ページがクライアントでキャッシュされていると、以前の任意のセッションにおける完全なページ・フェッチがプレビューに使用されることに注意してください。したがって、監視対象Webサイトの構成によって異なりますが、ページはビジターが実際にページを見た後で変更されている可能性があります。たとえば、最新の株式相場をリストするページなどです。ライブ・ソースのデータがレポートされるときは、「リプレイ」ステータス・バーに示されます。

Replay ViewerでのJavaScriptの実行

ビジターが表示したページに、インラインJavaScriptコードが含まれることがあります。アプリケーション定義機能を使用して、このJavaScriptコードの実行を再生機能でどのように扱うかを指定できます。この詳細は、8.3.22項「JavaScript再生実行の制御」に記載されています。また、スイート(SiebelおよびPeopleSoftなど)では、Replay Viewerでのレポートを最適化するJavaScriptの実行ルールが事前構成されていることに注意してください。

RIAベース・アプリケーション

リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。

4.3 Microsoft Excelへのセッション・ページのエクスポート

現在選択しているセッション内のページのサマリーをMicrosoft Excelにエクスポートできます。これを行う手順は、次のとおりです。

1. 前に説明した手順を使用して目的のセッションを選択します。「エクスポート・セッション・ページ」コマンド・ボタンをクリックします。ブラウザの構成方法によって異なりますが、ファイルを直接開くツール(デフォルトはMicrosoft Excel)の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。

2. Microsoft Excelで、生成されたファイルを表示して編集できます。例を図4-10に示します。

図4-10 Microsoft Excelでのセッション・ページ・エクスポートの例

エクスポートされたページ表示履歴とセッション・サマリーを使用して、一連のリアルユーザー・セッションをまとめることができます。たとえば、テストまたはパフォーマンス分析のベースとして使用できます。

行の作成および順序設定の制御

Microsoft Excelエクスポートで表示される行(および順序)は、現在選択されているセッション診断ディメンション・テンプレートに基づいていることに注意してください。この詳細は、4.5項「セッション診断におけるディメンション・リストの制御」に記載されています。

4.4 すべてのセッション情報のエクスポート

セッション情報の表示だけでなく、完全なセッション・コンテンツを外部ユーティリティにエクスポートして、詳しい分析や他のデータとの統合を行うことができます。たとえば、この方法を利用すると、完全なリアルユーザー・セッションに基づいてテスト・スクリプト生成を行うことができます。Oracle Application Testing Suite(ATS)などのテスト・プラットフォームを構成すると、アプリケーションで最もよく発生する使用シナリオに対して自動テスト・スクリプトを簡単に生成できます。

また、この機能を使用して高性能の根本原因分析をサポートすることもできます。アプリケーションまたは運用のスペシャリストに完全なユーザー・セッション情報を提供することができ、珍しい問題や切り分けにくい問題を特定するために役立ちます。エクスポートされたデータの機密情報は、HTTPプロトコル項目のマスキング機能で定義される動作に応じてマスキングされます。この詳細は、13.6項「ユーザー情報のマスキング」に記載されています。

セッション情報をエクスポートする手順は、次のとおりです。

1. 目的のセッションを探して、コンテキスト・メニューで「セッションのエクスポート」オプションを選択します。図4-11にこれを示します。

図4-11 ユーザー・レコードのコンテキスト・メニュー

または、セッション詳細ページ内で、「セッション・データのエクスポート」コマンド・ボタンをクリックします。いずれの場合も、選択したセッションのエクスポートの確認を求めるダイアログが表示されます。

エクスポートされるデータに機密情報が含まれる可能性があることを理解してください。セッションのコンテンツをよく確認して、機密情報が正確にマスキングされるようにすることをお薦めします。選択したセッションのエクスポートを確認するには、「はい」をクリックします。

2. ブラウザの構成方法によって異なりますが、zipファイルの保存場所の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。

重要:

セッション・エクスポート・ファイルを正しく作成するためには、次の点を確認する必要があります。

- エクスポートされるセッションが、「フル・セッション・リプレイ」(FSR)設定よりも古くないこと(13.9項「コレクタのデータ保存ポリシーの定義」を参照)。

- URL接頭辞マスキング設定は、「完全ロギング」として指定されます(13.10項「リプレイ・ポリシーの制御」を参照)。

また、エクスポートされたコンテンツ・ファイル(次の項を参照)が存在することを確認してから、エクスポートされたRUEIセッションを外部ユーティリティにインポートすることをお薦めします。

エクスポート・データの構造について

エクスポートされるセッションのzipファイルには次のファイルが含まれます。

- data.tab: コレクタのログ・ファイルから抽出された、選択したセッションの直接(RAW)ヒット情報が含まれます。

- page.tab: 選択したセッションの直接(RAW)ページ情報がコレクタのログ・ファイルから抽出されます。

- content_hitno.tab: 指定されたヒットの完全な(RAW)コンテンツ情報が含まれます。data.tabファイル内のコンテンツを含む各ヒットに対して1つのファイルがあります。たとえば、3番目のヒットと6番目のヒットにコンテンツがある場合には、2つのファイルcontent_3.tabとcontent_6.tabが作成されます。ヒット・ファイルの例を図4-12に示します。

図4-12 ヒット情報ファイルの例

ファイルの最初の行(ここでは589 68 313 221)には4つの整数が含まれ、それぞれがリクエスト・ヘッダー、リクエスト本文、レスポンス・ヘッダー、レスポンス・本文の長さ(バイト単位)を表します。また、このファイルでユーザーのパスワードがマスキングされている方法にも注意してください。

ヒット・ファイルで指定されたファイルの表示可能なバージョンは、content_viewerディレクトリでも使用できます。これは、チャンク化されたエンコーディングで転送されたデータをすぐに表示できることを意味します。data.tabファイルと同じhitnoがファイル・ネーミングに使用されます。

- index.html: 開発者およびRUEI外部のその他の関係者が、セッション診断機能内に表示されるセッション詳細を表示して分析でき、ソース、ページ、オブジェクトの詳細および要素識別にアクセスできます。

注意:
エクスポート・セッション・ファイルを作成する基礎として使用されるログ・ファイルも、RUEIによって内部で使用されます。これらのファイルの形式と内容は予告なしに変更される場合があります。

注意:
Internet Explorer内で、セキュリティ設定によっては、セッション・エクスポート・ファイルを開くと、ActiveXコントロールが無効であることを示す警告を受信する場合があります。

4.5 セッション診断におけるディメンション・リストの制御

特定のページ、アクションおよびカスタム・ディメンションの値が、「セッション診断」ウィンドウの「セッション」アクティビティ・パートに表示されます。必要な場合には、レポートされる値ごとに、関連するディメンション・レベルが表示されるマウスオーバー・テキストを使用できます。例を図4-13に示します。

図4-13 セッション診断ディメンション・リストの例

システム・テンプレートとユーザー・テンプレート

アプリケーションとスイートでレポートされる特定のディメンションとその順序は、テンプレートによって制御されます。テンプレートには、システムとユーザーの2種類があります。システム・テンプレートは製品インストールに含まれています。変更できるのは、リストされるディメンションの順序のみです。システム・テンプレートは管理者のみが変更でき、システム・テンプレートに対する変更はすべてのシステム・ユーザーに適用されます。ユーザー・テンプレートは、個々のユーザーがそれぞれの要件に応じて変更できます。ユーザーがテンプレートを変更するには、セッション診断へのアクセスを許可される必要があります。

ディメンション・テンプレートの変更

ディメンション・テンプレートを変更するには、次の手順を実行します。

1. 「システム」メニューから、「プリファレンス」、「セッション表示」の順に選択します。図4-14に示すようなダイアログが表示されます。

図4-14 「ディメンション・リストの編集」ダイアログ

2. 「アクティブなテンプレート」メニューでは、システム・テンプレートとユーザー・テンプレートのどちらを使用するか指定します。

3. 「アプリケーション・タイプ」メニューでは、汎用(つまりスイート・ベースではないアプリケーション)と特定スイート・タイプのどちらを変更するか選択します。後者の場合はスイート・タイプを指定する必要があります。

4. ユーザー・テンプレートの場合、「ディメンション・レベル」メニューを使用して、「セッション」アクティビティ・セクションでレポートする追加のディメンションを選択できます。次に、「追加」をクリックします。

5. システム・テンプレートとユーザー・テンプレートのどちらの場合も、「上に移動」と「下に移動」のコントロールを使用して、ディメンションのリスト順を変更できます。

テンプレートの適用方法の理解

セッション診断で報告される各ページ・ビューには、アプリケーション・タイプが関連付けられています。これを使用して、適切なディメンション・テンプレートが自動的にロードされます。ユーザー・テンプレートまたはシステム・テンプレートに対する変更がある場合には、開いている「セッション診断」ウィンドウに適用されます。

4.6 外部ツールへのクリックアウトの構成

URL診断グループ(3.2.2項「問題分析グループ」を参照)、スイート診断グループ(3.2.5項「問題分析のためのスイートURL診断」を参照)およびセッション診断(4.1項「概要」を参照)は、選択した機能URLおよび特定のディメンションから外部診断ユーティリティへのクリックアウトをサポートしています。サポートされている外部ユーティリティを表4-3に示します。

表4-3 クリックアウト・オプション

ユーティリティ

説明

Enterprise Manager 12

インストールされているOracle Enterprise Managerミドルウェアおよびアプリケーション管理パックによって異なりますが、次のオプションが使用できます。

- JVMトランザクションのトレース: ECIDに基づき、選択されたリクエストに関するJVMアクティビティの情報が提供されます脚注1。このオプションは、URL診断および問題の分析グループ内のECIDディメンション、およびセッション診断を介して使用できます。

- トレース・リクエスト: 選択されたリクエストに関する集計されたJVMアクティビティの情報を提供します。このオプションは、URL診断グループおよびセッション診断内のURLディメンションを介して使用できます。

ビジネス・トランザクションの管理

Oracle Business Transaction Management(BTM)は、ビジネス・トランザクションをリアルタイムに視覚化するユーティリティです。これにより、組織はトランザクション・エラー、障害およびボトルネックを特定して解決するか、または、迅速に対応して、隔離した問題が広範囲な機能停止に発展するのを回避できます。オプションは次のとおりです。

- トランザクションの診断: 選択されたリクエストに関連付けられているビジネス・トランザクション(およびそれを構成する操作)に関するアクティビティ情報が提供されます。トランザクション情報がない場合には、その他2つのオプションにより、集計された情報が提供されます。このオプションは、セッション診断機能を介してのみ使用できます。

- 操作の診断: 選択されたリクエストに関連付けられている特定の作業フローに関する集計された情報が提供されます。このオプションは、URL診断グループ内のBTMサービス/操作ディメンションを介して使用できます。

- サービスの診断: 選択されたリクエストに関連付けられているアプリケーション環境内にデプロイされたサービスに関する集計された情報が提供されます。このオプションは、URL診断グループ内のBTMサービス・ディメンションを介して使用できます。

EBS

ユーザーがEBSプラグイン内のサーバー概要またはユーザー検索機能を参照できるようにします。オプションは次のとおりです。

- ユーザー検索: 選択されたユーザーIDに基づいて、アプリケーションおよびデプロイメントに関するユーザー・アクティビティ情報が提供されます。このオプションは、EBSグループおよびセッション診断内のユーザーIDに使用できます。

Siebel

ユーザーがSiebelプラグイン内のサーバー概要またはユーザー検索機能を参照できるようにします。オプションは次のとおりです。

- ユーザー・レポートの表示: 選択されたユーザーIDに基づいて、ユーザー・アクティビティ情報が提供されます。このオプションは、Siebelグループおよびセッション診断内のユーザーIDに使用できます。

- サーバー・レポートの表示: 選択されたアプリケーションのエンタープライズ名(Siebelインスタンス定義の一部として構成されている)に基づいて、アプリケーションのパフォーマンスおよび可用性に関する集計された情報が提供されます。このオプションは、Siebelグループおよびセッション診断内のアプリケーション名、ページURLおよびスイート名に使用できます。

- ユーザー・レポートの生成: 選択されたユーザーIDに基づいて、Siebelユーザー分析レポートを作成します。使用可能なレポートがない場合は、「ユーザー・レポートの表示」の前に、このオプションを選択する必要があります。このオプションは、Siebelグループおよびセッション診断内のユーザーIDに使用できます。

- サーバー・レポートの生成: 選択されたアプリケーションのエンタープライズ名に基づいて、Siebelサーバー分析レポートを作成します。使用可能なレポートがない場合は、「サーバー・レポートの表示」の前に、このオプションを選択する必要があります。このオプションは、Siebelグループおよびセッション診断内のアプリケーション名、ページURLおよびスイート名に使用できます。

JD Edwards

ユーザーにJD Edwards EnterpriseOne Server Managerコンソールを表示し、セッション・ユーザーに関連付けられたすべてのユーザー・アクティビティに関する情報を提供します。オプションは次のとおりです。

- セッションのトレース: 現在のセッションに関するセッション情報を提供します。

この機能を使用するには、RUEIでJSESSIONID CookieをプレーンCookieとして記録する必要があります。この設定が正しいことを確認する手順は、次のとおりです。

1. 「構成」に移動し、「セキュリティ」を選択します。

2. 「マスキング」→「Cookieマスキング」を選択します。

3. 「JSESSIONID」を選択するか、必要に応じて新しいマスキングを作成します。

4. 「cookie名のマスキング・アクションの編集」ダイアログで、「アクション」オプションから「プレーン」を選択します。

5. 「保存」をクリックします。

My Oracle Support

レポートされる特定のエラーについて、関連情報をOracleカスタマ・サービスのWebサイト(My Oracle Support)で検索します。たとえば、ORA-12154またはSBL-UIF-00271などについて検索します。オプション:

- My Oracle Support: 選択したコンテンツ・エラーについて、関連情報をMy Oracle Support Webサイトで検索します。このオプションを使用できるのは、標準コンテンツ・エラーのみで、ユーザー定義のコンテンツ・エラー(「在庫切れ」など)では使用できません。

この機能を使用するには、My Oracle Supportに登録している必要があります。詳細は次のサイトを参照してください。

https://support.oracle.com/CSP/ui/flash.html

脚注1 ECIDは、リクエストがOracle Application Serverアーキテクチャ内を移動するときに、その経由場所をトラッキングするために使用されるリクエスト・ヘッダーです。特に診断に役立ちます。

サポートされている旧バージョン

表4-4に、Oracle Enterprise Managerのサポートされている旧バージョンで使用できるクリックアウト・オプションを示します。

表4-4 サポートされている旧バージョンのクリックアウト・オプション

ユーティリティ

説明

EMGC 11

インストールされているOracle Enterprise Managerミドルウェアおよびアプリケーション管理パックによって異なりますが、次のオプションを使用できます。

- JVM診断: 可用性およびパフォーマンスの問題を識別するJVM診断機能が開かれます。リクエスト名は、選択されたURLに基づいてフィルタ処理されます。このオプションは、URL診断グループおよびセッション診断内のURLディメンションを介して使用できます。

- リクエスト監視: 選択されたURLに基づき、Javaリクエストおよびそれらに関連付けられているデータベース・セッションがハイライト表示され、パフォーマンスの問題が識別されます。このオプションは、URL診断グループおよびセッション診断内のURLディメンションを介して使用できます。

- アプリケーションの依存性: 選択されたURLに基づき、基礎となるITインフラストラクチャ内のコンポーネント間の関係が識別されます。このオプションは、URL診断グループおよびセッション診断内のURLディメンションを介して使用できます。

AD4J 10g

Oracle Application Diagnostics for Java(AD4J)は、Oracleミドルウェア用のOracle診断パックに含まれます。オーバーヘッドの少ない監視および診断の機能を提供し、Javaアプリケーションの可用性とパフォーマンスを向上します。この機能を使用するには、組織においてAD4J 10g R4がインストールされていることが必要です。オプション:

- AD4J 10R4: 選択されたURLに基づき、Javaアプリケーション内のパフォーマンスの問題がハイライト表示されます。このオプションは、URL診断グループおよびセッション診断内のURLディメンションを介して使用できます。

CAMM 10g

Oracle Composite Application Monitor and Modeler(CAMM)は、組織で実行している高度に分散されたJava EEおよびSOAアプリケーションを監視できるユーティリティです。この機能を使用するには、組織においてCAMM 10g R4がインストールされていることが必要です。オプション:

- CAMM 10R4: 選択されたURLに基づき、様々なアプリケーション・ビルディング・ブロック間の関係が識別されます。このオプションは、URL診断グループおよびセッション診断内のURLディメンションを介して使用できます。

クリックアウト機能の構成

RUEIからこれらのユーティリティへのアクセスを構成する手順は、次のとおりです。

1. 「構成」タブ→「一般」→「詳細設定」→「クリックアウト設定」の順に選択します。このオプションを使用できるのは管理者のみです。新規アイテムの追加または既存の外部ユーティリティ定義をクリックします。図4-15に示すようなダイアログが表示されます。

図4-15 クリックアウト設定の編集

2. 「クリックアウト・ツール」メニューを使用して、インタフェースを構成する外部ユーティリティを選択します。サポートされている外部ユーティリティは表4-3に示しています。このダイアログに表示される他のフィールドは、選択したユーティリティによって異なることに注意してください。

3. 「ホスト」フィールドを使用して、選択した外部ユーティリティにアクセスする方法を指定します。プロトコル・スキーム(http://など)は含めないでください。たとえば、ruei-camm.oracle.comのように指定します。

4. 「ポート」フィールドを使用して、目的のポート番号を指定します。指定できるポート番号は1つのみです。ワイルドカード文字(*)は指定できません。

5. 「拡張子」入力フィールドを使用して、クリックアウトを行えるオブジェクト・ファイルの拡張子を指定します。「追加」ボタンを使用して、追加の拡張子を指定します。「拡張子なしも許可」チェック・ボックスを使用すると、ファイル拡張子が関連しないヒットについてクリックアウトを可能にするかどうかも指定できます。

6. 「拡張」タブをクリックし、「プロトコル」フィールドを使用して、選択したユーティリティとの接続にHTTPとHTTPSのどちらを使用するかを指定します。デフォルトでは、HTTPが使用されます。

7. 「正規表現」フィールドと「置換」フィールドを使用して、置き換えられる外部アプリケーションに渡すURLの一部を指定します。正規表現の詳細は、My Oracle Support Webサイトにあるナレッジベースの記事を参照してください。これは次の場所から入手できます。

https://support.oracle.com/CSP/ui/flash.html

次に、「保存」をクリックします。これらの設定への変更は即座に適用されます。

アプリケーションおよびスイートの構成

目的のアプリケーションごとに、クリックアウトをサポートする機能URLを指定します。この詳細は、8.3.21項「問題分析グループ内のレポートの制御」に記載されています。

Siebelスイートの場合、クリックアウト機能を使用するためには、エンタープライズ名をスイートの構成に含めて指定する必要があります。この詳細は、10.1項「スイートの使用」に記載されています。

定義されたエンタープライズ名は、適切なスイートを選択し、「拡張」タブ、「Enterprise Manager」タブの順にクリックして特定できます。例を図4-16に示します。

図4-16 エンタープライズ名の例

クリックアウト機能へのアクセス

データ・ブラウザ項目のクリックアウト機能は、項目のコンテキスト・メニューから選択できます。使用できる正確なオプションは、データ・ブラウザ・グループ、選択したディメンション、および定義されたクリックアウト設定によって異なります。例を図4-17に示します。

図4-17 「URL診断」グループ

4.7 ビジネス・アプリケーションの監視

Oracle Enterprise Manager内にビジネス・アプリケーション・ターゲットを作成して監視すると、アプリケーション・パフォーマンス管理(Application Performance Management: APM)機能を実現できるため、ビジネスで重要なアプリケーションのパフォーマンスと可用性を最大限に高めることができます。これらは、アプリケーションとビジネス・トランザクションの関係の直感的な表現と、基本のITインフラストラクチャを提供する管理対象ターゲットです。これらのビジネス・アプリケーションを構成する、RUEIで監視されるコンポーネントにより、エンタープライズ間で情報が提供され、そのアプリケーションの構造、ステータス、可用性、依存性およびパフォーマンスの集中監視が容易になります。

脚注

脚注1: ECIDは、リクエストがOracle Fusion Middlewareアーキテクチャ内を移動するときに、その経由場所をトラッキングするために使用されます。これは、特に診断に役立ちます。

5 ダッシュボードの使用

この章では、カスタマイズしたダッシュボードの作成方法について説明します。また、特定のダッシュボード項目の追加と変更およびダッシュボード・テンプレートの作成と管理についても説明します。

5.1 概要

RUEIでは、独自にカスタマイズした一連のダッシュボードを作成できます。ダッシュボードでは、ある目的を達成するために必要となる最も重要な情報が視覚的に表示されます。情報が1つの画面に統合されて配置されるため、一目で把握することができます。例を図5-1に示します。

図5-1 ダッシュボードの例

現在定義されている各ダッシュボードは、画面上部のタブで選択できます。最後のタブ(»)には、新しいダッシュボードを作成するベースとして使用できるテンプレートの概要が含まれます。

有効なダッシュボードの設計

ダッシュボードを設計するときは、レポートするデータや使用する視覚表現について、ダッシュボードに適した内容をよく考えることをお薦めします。特に、次の項目を注意深く検討してください。

- ダッシュボードの情報内容が多すぎないか。理想としては、傾向、パターンおよび例外を視覚的に特定できるようにします。

- どの視覚表現を使用すれば、最も少ないスペースで、最も明確かつ有意義にデータを表すことができるか。

- 表示される情報をリアルタイムでリフレッシュする必要があるか。その場合の間隔。表示の目的のためにリアルタイム情報が必要かどうか。

- ユーザーの注目に値する情報や処理が必要な情報が、ダッシュボードですぐに注意を引きますか。

ダッシュボードとテンプレート

ダッシュボードはテンプレートに基づいて作成されます。テンプレートには、システム、パブリック、公開の3種類があります。システム・テンプレートは製品インストールに含まれており、変更できません。ただし、システム・テンプレートを無効にすることはできます。一方、パブリック・テンプレートは、管理者が作成して管理するダッシュボードのテンプレートです。他のユーザーが変更することはできません。公開テンプレートは、生成されるリンクを介して外部ユーザーが見られるダッシュボードを作成するために使用されます。

5.2 新規ダッシュボードの作成

新規ダッシュボードを作成する手順は、次のとおりです。

1. 「ダッシュボード」タブをクリックし、最後のタブ(»)をクリックします。現在使用可能なテンプレートがリストされます。例を図5-2に示します。

図5-2 使用可能なテンプレートの例

2. 新規テンプレートのベースとして使用するテンプレートをクリックします。図5-3に示すようなダイアログが表示されます。

図5-3 「ダッシュボードの追加」ダイアログ

3. 新規ダッシュボードの名前を指定します。名前は保持するダッシュボードの中で一意にする必要があり、長さは最大30文字に制限されます。

4. ダッシュボードのベースとするテンプレートを選択します。または、ダッシュボードを最初から作成する場合はオプション(なし)を選択します。新たに作成するダッシュボードとベースのテンプレートの間に関連付けはないことに注意してください。つまり、テンプレートが将来変更されても、そのテンプレートから作成されたダッシュボードには適用されません。

5. ダッシュボードの形式を選択します。形式は1列、2列または3列に基づきます。パーセンテージは、ダッシュボード内の各列に割り当てられる画面のスペースを示します。

6. リフレッシュ間隔を選択します。これは、「手動」(タスク・バーの「リロード」アイコンをクリックしたときだけダッシュボードがリフレッシュされる)または「自動」(5分、10分、15分)のいずれかに設定できます。

7. 「オプション」タブの「データ・アクセス」メニューで、ダッシュボードを特定のアプリケーション、スイートまたはWebサービスにバインドするか、汎用にするかを指定します。これらのメニューのオプションは、ユーザーに割り当てられているアクセス権限によって異なります。ダッシュボード・フィルタの使用方法は、5.4項「データ・アクセス・フィルタの使用」に記載されています。
次に、「保存」をクリックします。

ダッシュボードの表示

現在定義されている各ダッシュボードを使用するには、「ダッシュボード」タブ内の対応するタブをクリックします。タスク・バーの「新規ウィンドウで開く」アイコンをクリックすることもできます。これは、ダッシュボードを全画面で表示する場合や、複数のダッシュボードを同時に表示するため複数のウィンドウをサイズ変更して整列する場合に特に便利です。

ダッシュボードの変更

ダッシュボードのタスク・バーで「編集」アイコンをクリックすると、ダッシュボードのプロパティを変更できます。図5-3に示すようなダイアログが表示されます。このダイアログを使用して、ダッシュボードのベースのテンプレート、名前、レイアウトおよびリフレッシュ間隔を変更します。ダッシュボードのレイアウトとフィルタ(5.4項「データ・アクセス・フィルタの使用」を参照)もレポートされます。

既存の項目を変更するだけでなく、ダッシュボードで項目を追加または削除することもできます。この詳細は次の項に記載されています。

5.3 ダッシュボードの内容の変更

ダッシュボードに項目を追加する手順は、次のとおりです。

1. 目的のダッシュボードを選択し、タスク・バーの「アイテムの追加」アイコンをクリックします。図5-4に示すようなダイアログが表示されます。

図5-4 新規ダッシュボード・アイテム

2. 新規ダッシュボード項目の名前を指定します。選択したダッシュボード内の項目間で一意にする必要があります。

3. 新規項目を表示するダッシュボードを選択します。デフォルトでは、現在選択されているダッシュボードになります。

4. 必要に応じて、項目の高さをピクセルで指定できます。このフィールドを空白にすると、項目のサイズは使用可能なダッシュボード領域の範囲内で自動的に設定されます。表示するウィジェットの種類を選択します。使用可能なウィジェットの種類を表5-1に表示します。

5. 表5-1 ウィジェットの種類

ウィジェットの種類

説明

アラート・ログ

最近生成されたアラートのローリング・リストを表示する項目です。このオプションを選択した場合は、「オプション」タブのフィールドを使用して、アラートのソート方法、表示する順序、およびリストでレポートするアラートの最大数を指定できます。「フィルタ」タブのフィールドを使用して、表示されるKPIアラートのカテゴリ、ステータスおよび重大度を指定できます。

データ・ブラウザ

データ・ブラウザ内のデータ・ソースを表示する項目です。このオプションを選択した場合は、「オプション」タブのフィールドを使用して、項目の導出元のグループ(たとえば「すべてのセッション」または「失敗したページ」)とそのカテゴリやディメンション・レベルを指定できます。視覚表現(たとえば値リストまたは円グラフ)およびビュー・レベル(たとえば5分または年)も指定できます。グラフィカルな表示の場合は、「凡例の表示」チェック・ボックスを使用して、表示されたメトリックの指標を含めるかどうかを指定できます。値リストの場合はリストされる値の最大値を指定できます。使用可能なオプションは、選択されているデータ・ソースによって決まります。

「フィルタ」タブのフィールドを使用して、選択したデータ・ソースに適用するフィルタ(選択されたディメンションに基づく)を指定できます。このウィジェットを使用できるのは、「分析」または「完全」レベルのアクセス権限が付与されている場合のみです(表14-2を参照)。

マップ

選択されたデータ・アイテム(たとえばクライアント・セッション)の場所をハイライト表示する地図として表す項目です。この地図は、選択されたデータ・ソースが発生する場所を表すカラー・コードを使用して示されます。つまり、鮮やかな赤はアクティビティが高レベルの国を示し、白は選択されたデータ・ソースのアクティビティがその場所では発生していないことを示します。また、これより詳細なビューは、「ヨーロッパ」、「アメリカ合衆国」および「アジア」で確認できます。

「フィルタ」タブのフィールドを使用して、レポートされるデータ・ソースに適用するフィルタ(選択されたディメンションに基づく)を指定できます。この項目を使用できるのは、ITユーザーで「分析」または「完全」のアクセス・レベル権限(表14-2を参照)がある場合のみです。

単一のKPI

特定のKPIの現在のステータスをレポートする項目です。このオプションを選択した場合は、「オプション」タブのフィールドを使用して、目的のKPIと項目の視覚表現(計器またはグラフ)を指定できます。

複数のKPI

選択した数の定義済KPIのステータスをレポートする項目です。このオプションを選択した場合は、「オプション」タブ内のフィールドを使用して、レポートされるKPIの数と順序を指定できます。また、「フィルタ」タブを使用して、レポートされるKPIのカテゴリとステータスを指定できます。

複数のSLA

選択されたカテゴリのSLAが、年、月、週、日の定義済パーセント・レベルに到達したかどうかをレポートする項目です。このオプションを選択した場合は、「オプション」タブ内を使用して、レポートされるSLAのソート方法を指定できます。また、「フィルタ」タブを使用して、レポートされるカテゴリを指定できます。「カテゴリ」フィールドを空にしておくと、すべてのカテゴリがレポートされることに注意してください。

6. 新しい項目が、グラフを含む単一KPI、アラート・リスト、データ・ブラウザ項目または地図の場合、「期間」メニューを使用して、レポートされるデータが対応する期間を指定できます。直前の5分間、1時間、6時間、12時間または24時間を指定できます。他のすべての項目の種類(計器を含む単一KPI項目または複数KPI項目)では、このメニューは無効です。項目のレポート期間はKPIの定義済サンプリング間隔から導出されます。この詳細は、7.2項「KPIおよびSLAの定義」に記載されています。

7. 次に、「保存」をクリックします。定義した項目は、選択したダッシュボードの左上に追加されます。ダッシュボード内で項目をドラッグ・アンド・ドロップして位置を決めることができます。

注意:
1つのダッシュボードには最大35個の項目を定義できます。

データ・ブラウザのドリルダウン

データ・ブラウザ・ダッシュボード項目の場合、項目の右上の「参照」アイコンをクリックすると、その項目の導出元データの完全なビューを取得できます。データ・ブラウザの使用方法は、第3章「データ・ブラウザの使用」に記載されています。このアイコンを使用できるのは、ビジネス・ユーザーまたはITユーザーで「分析」または「完全」のアクセス・レベル権限(表14-2を参照)がある場合のみです。

ダッシュボード項目の変更

ダッシュボード項目のタイトルをクリックすると、その項目を編集できます。図5-4に示すようなダイアログを使用して、プロパティを変更できます。項目の導出元テンプレート(アプリケーション固有、サービス固有またはスイート固有)およびユーザーのアクセス・レベル権限によっては、ダイアログ内のいくつかのフィールドが無効になることがあります。タイトル部分にある「削除」アイコンをクリックすると、その項目を削除できます。

5.4 データ・アクセス・フィルタの使用

テンプレートは汎用として定義するか、アプリケーション固有、サービス固有またはスイート固有として定義できます。後者の場合、ダッシュボードのすべての項目は指定されたソースにバインドされます。汎用ダッシュボードにはこの制約はありません。

ソース固有のテンプレートが定義される場合、ダッシュボードの各項目は指定されたソースについてフィルタ処理されます。このフィルタがなんらかの理由で適用されない場合(たとえば、指定されたアプリケーションが削除されていた場合、またはユーザーがその特定のアプリケーションに関する情報の表示を許可されていない場合)、要求されたデータが表示できないという警告が項目のかわりに表示されます。

テンプレート・フィルタを使用すると次の利点が得られます。

- テンプレートのメンテナンスを最小限に抑えることができます。たとえば、ダッシュボード・テンプレートに20個の項目が含まれ、すべてが同じアプリケーションを参照するとします。他のアプリケーションについて同じテンプレートを作成するときに、20個の項目すべてを変更する必要がなくなり、テンプレート・フィルタを変更するだけですみます。

- システムのユーザーが通常は表示できないデータをダッシュボード内で表示できるように許可します。たとえば、ユーザーに「概要」アクセス・レベル権限しかないとします。この場合、データ・ブラウザにはアクセスできません。ただし、ユーザー・アカウント定義(第14章「ユーザーと権限の管理」を参照)を使用して、特定のアプリケーション、サービスまたはスイートについて選択されたデータ項目の表示を許可できます。ただし、他のデータ・ソースから導出された情報は表示できません。

テンプレート・フィルタの検出

アプリケーション、サービスまたはスイートをテンプレート・フィルタとして使用するためには、それらが構成された後、監視対象のトラフィック内で少なくとも1回は識別される必要があります。

5.5 ダッシュボードへのデータ・ブラウザまたはKPIビューの追加

データ・ブラウザの現在のビュー、またはKPI概要機能で現在表示しているKPIを、「ダッシュボードに追加」アイコンをクリックしてダッシュボードに追加することができます。図5-4に示すようなダイアログが表示されます。このダイアログを使用して、ダッシュボードでのデータ・ソースのレポート方法を最終決定できます。

5.6 パブリック・テンプレートの作成

前に説明したとおり、パブリック・テンプレートは管理者によって作成され、他のユーザーがダッシュボードのベースとして使用します。パブリック・テンプレートを作成する手順は、次のとおりです。

1. 「ダッシュボード」タブをクリックし、既存のダッシュボードのタブをクリックしてから、タスクバーの「テンプレートとして保存」アイコンをクリックします。このオプションを使用できるのは管理者のみです。図5-5に示すダイアログが表示されます。

図5-5 「ダッシュボード・テンプレートの作成」ダイアログ

2. 新規テンプレートの名前を指定します。これはシステム・テンプレートを通じて一意である必要があります。

3. テンプレートの形式とリフレッシュ間隔を指定します。

4. 「オプション」タブの「データ・アクセス」メニューを使用して、テンプレートを特定のアプリケーション、サービスまたはスイートにバインドするかどうかを指定します。フィルタの使用方法は、5.4項「データ・アクセス・フィルタの使用」を参照してください。
アプリケーション固有またはサービス固有のテンプレートの場合は、バインドするアプリケーションまたはサービスを指定します。スイート固有のテンプレートの場合は、スイートの種類(たとえばPeopleSoft)と構成されているスイートを指定します。「スイート・タイプ」メニュー内の使用できるオプションは、システムで構成されるスイート・インスタンスによって異なります。

5. 「パブリッシュ」タブ内で「匿名アクセスを許す」チェック・ボックスを使用して、選択されているダッシュボードを外部ユーザーが表示できるかどうかを指定します。選択した場合は、表示されるリンクをコピーして必要なユーザーに送信します。この機能の使用方法の詳細は、5.9項「テンプレートの公開」に記載されています。
次に、「保存」をクリックします。新規作成したテンプレートは、すぐにパブリック・テンプレートのリストに表示されます。テンプレートの項目へのアクセスは、各ユーザーのアクセス権限によって異なります。

システム・テンプレートの変更

システム・テンプレートを直接変更することはできません。システム・テンプレートを変更する必要がある場合は、「無効化」オプションをシステム・テンプレートのコンテキスト・メニューから選択して、他のユーザーがシステム・テンプレートを使用できないようにすることをお薦めします。必要な変更内容を含むように既存のダッシュボードを変更(または新規ダッシュボードを作成)して、そのダッシュボードをパブリック・テンプレートとして保存し、そのパブリック・テンプレートをシステム・テンプレートのかわりに使用するようにユーザーに通知してください。

5.7 テンプレートのプロパティと内容の変更

他のシステム・ユーザーが使用するためのパブリック・テンプレートを作成した後、次の手順でプロパティを編集できます。

1. 「ダッシュボード」タブをクリックし、最後のタブ(»)をクリックします。現在使用可能なパブリック・テンプレートがリストされます。目的のテンプレートのコンテキスト・メニューで「編集」オプションを選択します。図5-5に示すようなダイアログが表示されます。

2. このダイアログに表示されるフィールドを使用して、5.6項「パブリック・テンプレートの作成」に記載されているようにテンプレート名、レイアウト、リフレッシュ間隔、データ・ソースを変更します。次に、「保存」をクリックします。

テンプレートの内容を編集する手順は、次のとおりです。

1. 目的のテンプレートのコンテキスト・メニューで「コンテンツの編集」オプションを選択します。テンプレートが新しいウィンドウに編集モードで表示されます。

2. 5.3項「ダッシュボードの内容の変更」に記載されている手順を使用して、テンプレートの内容を編集します。その後、ウィンドウを閉じます。

前に説明したように、テンプレートと、そのテンプレートに基づいて作成したダッシュボードの間には直接の関連付けはありません。したがって、テンプレートを変更しても、そのテンプレートから作成されたダッシュボードにその変更は反映されません。

5.8 ユーザー・ダッシュボードに基づいたテンプレートの作成

他のユーザーにも便利だと思われるプライベート・ダッシュボードを作成する場合があります。その場合、管理者が、パブリック・テンプレートとして他のユーザーが使用できるようにすることが可能です。次を実行します。

1. 「ダッシュボード」タブをクリックし、既存のダッシュボード・タブをクリックしてから、最後のタブ(「»」)をクリックします。現在使用可能なテンプレートがリストされます。例を図5-2に示します。

2. 「追加」コマンド・ボタンをクリックします。図5-6に示すようなダイアログが表示されます。

図5-6 「ダッシュボード・テンプレートの追加」ダイアログ

3. 新しいパブリック・テンプレートの名前を指定します。これは、パブリック・テンプレートの中で一意にする必要があり、長さは最大30文字に制限されます。

4. ベースとするユーザー・ダッシュボードを選択します。または、テンプレートを最初から作成する場合はオプションの(なし)を選択します。新たに作成するテンプレートとベースとするダッシュボードの間に関連付けはありません。つまり、ダッシュボードが将来変更されても、そのテンプレートまたはそれをベースとするダッシュボードには適用されません。次に、「保存」をクリックします。

5.9 テンプレートの公開

RUEIでは、ダッシュボードの定義やダッシュボードを作成するベースとして使用されるテンプレートの定義の他に、外部ユーザーがテンプレートを使用できるようにすることも可能です。たとえば、ポータル・ページを使用します。5.6項「パブリック・テンプレートの作成」に記載されているように、ダッシュボードを外部から使用可能にすることができます。次を実行します。

1. 目的のテンプレートのコンテキスト・メニューで「編集」オプションを選択します。図5-5に示すようなダイアログが表示されます。

2. 「パブリッシュ」タブをクリックして、「匿名アクセスを許す」チェック・ボックスを選択します。

3. 次に、「保存」をクリックします。

4. もう一度、目的のテンプレートのコンテキスト・メニューで「編集」オプションを選択します。「パブリッシュ」タブをクリックします。表示されるリンクをコピーして必要なユーザーに送信します。例を図5-7に示します。

図5-7 ダッシュボード・テンプレートの編集

5.10 テンプレート項目の公開

テンプレート全体を公開するだけでなく、個々のテンプレート項目を外部ユーザーが使用できるようにすることも可能です。次を実行します。

1. 目的の公開テンプレートを右クリックし、コンテキスト・メニューから「コンテンツの編集」を選択します。選択したダッシュボードが新しいウィンドウで開きます。

2. 目的のダッシュボード項目のタイトルをクリックします。図5-8に示すようなダイアログが表示されます。

図5-8 ダッシュボード・アイテムの編集

3. 「パブリッシュ」タブをクリックし、「パブリッシュURL」リンクをコピーして目的のユーザーに送信します。項目を外部に公開すると、ダッシュボード項目のコンテナ部分(および左上の項目名とアイコン)は削除されることに注意してください。デフォルトでは、指定された範囲(たとえば、240から1024ピクセル)の最も狭い幅でイメージが公開されます。ただし、この幅は、引数&frmWidth=と指定の幅を公開URLに付加することで制御できます。地図ではアスペクト比が保持されることに注意してください。
項目へのアクセスは、対応するテンプレートを介して制御されることに注意してください。このため、公開項目を別のテンプレートに移動したり、テンプレートの提供状況を非公開に修正した場合は、外部ユーザーがその項目を使用できなくなり、公開URLをクリックしたときのエラー・メッセージも無効になります。

6 KPI概要およびアラート・リストの使用

この章では、KPI概要機能の使用方法について説明します。具体的には、レポートされるKPIの外観を制御する方法、ならびにKPIをドリルダウンすることで、KPIを構成するステータス、および生成されるアラートに関する詳細情報を表示する方法について説明します。また、KPI相関機能およびアラート・リストの使用方法についても説明します。このタブを表示するには、少なくとも「概要」アクセス・レベル権限が必要です。ユーザーのアクセス・レベル権限については、14.2項「ユーザー・アカウントのロールと権限の概要」に記載されています。

6.1 KPI概要

KPI概要機能でユーザーが表示できるKPIは、そのユーザーが許可されている情報範囲によって異なります(14.7項「モジュールにおける許可データの有効範囲の管理」を参照)。許可されているKPIのステータスを確認するには、「KPIの概要」タブをクリックします。ここでは、スナップショットが直感的かつ状況把握に役立つ形式で示されます。例を図6-1に示します。

図6-1 「KPIの概要」の例

この概要には、各カテゴリ内のKPIの現在のステータスのサマリーがただちに表示されます。「完全」アクセス・レベル権限がある場合は、カテゴリが組織の特定の要件を反映するよう自由に構成でき、各カテゴリには関連するパフォーマンス・インジケータを含めることができます。たとえば、可用性の問題、パフォーマンスまたはビジターのトラフィックなど、組織内の運用の個々の項目を別々のカテゴリに構成できます。

また、ツールバーの「新規KPI」をクリックし、追加のKPIを作成することもできます。KPIの作成手順の詳細は、7.2項「KPIおよびSLAの定義」に記載されています。

6.1.1 KPI概要の表示

定義済カテゴリを表示するには、「KPIの概要」タブ→「概要」を選択します。「概要」カテゴリは、権限があるKPIの最上位ビューを示す特殊な表示カテゴリです。ここでは、他の全KPIカテゴリの簡潔なサマリーが示されるのみでなく、表示された情報をドリルダウンすることで個々のKPIにもアクセスできます。

特定のKPIカテゴリを表示するには、目的のカテゴリをクリックします。または、目的のカテゴリを右クリックした後、コンテキスト・メニューから「開く」または「新規ウィンドウで開く」を選択します。後者のオプションは、グラフを全画面で表示する場合や、複数のKPIカテゴリを同時に表示するため複数のウィンドウをサイズ変更して整列する場合に特に便利です。

6.1.2 表示形式

KPI概要は、メーターとグラフの2タイプで表示できます。図6-1は、メーターによる概要の例です。この形式では、選択したKPIがアナログ・メーターで表示されます。より詳しい表示が必要な場合は、直近の90分間のKPIに関する情報を示すグラフ形式を選択できます。例を図6-2に示します。

図6-2 グラフによる概要の例

この表示では、縦軸が適切な範囲に自動的に調整され、表示が最適化されます。希望の表示形式を選択するには、「KPIの概要」メニューから「表示形式」オプションを選択し、希望の形式を選択します。

6.1.3 ズーム・インおよびズーム・アウト

グラフ表示形式では、ズーム・インおよびズーム・アウトを行い、グラフを表示する対象となる期間を変更できます。保存されている履歴情報に応じて、時間単位や日単位へのズーム・アウトが可能です。グラフの形式が棒グラフから線グラフに自動的に変更されます。例を図6-3に示します。

図6-3 KPIのズーム・イン

6.1.4 KPIおよびターゲット

「KPIの概要」メニューから「ターゲットのないKPIを含む」オプションを選択すると、ターゲットが定義されていないKPIを、現在表示されているカテゴリに対して追加または除外できます。KPIに設定されているすべてのターゲットがグラフに表示されます。0のベースラインから設定済の最小ターゲットまでが最小ターゲットとして、KPIグラフの最上部から設定済の最大ターゲットまでが最大ターゲットとして表示されます。例を図6-3に示します。

また、グラフ内では、次のカラー・コードを使用して、ターゲットに関する情報が表示されます。

- 青: KPIにはターゲットは設定されていません。

- 緑: 現在選択されている期間のKPIは、設定されたターゲットの範囲内です。

- 赤: 現在選択されている期間のKPIは、設定されたターゲットの範囲外です。

例を図6-4に示します。

図6-4 グラフのカラー・コード

6.1.5 不完全なデータの使用

監視中に収集されたデータは、まず、コレクタ・システムに格納されているログ・ファイルに書き込まれます。これらのファイルは、レポータ・システムによって処理され、KPIの追跡に使用されます。なんらかの理由でこれらのログ・ファイルの1つ以上の生成が遅れてレポータ・システムで処理できない場合、KPI概要には、KPIが不完全なデータに基づいていることが示されます。例を図6-5に示します。

図6-5 不完全なデータに基づくKPI

不完全なデータに基づく期間は、境界が点線で示されます。さらに、マウス・カーソルをその上に置くと、欠落しているデータのレベルに関する情報が表示されます。

6.1.6 概要のドリルダウン

概要とは、あるカテゴリ内のKPIのサマリーであり、各概要をドリルダウンすると、基となるKPIに関する詳細情報を表示できます。それには、KPIのタイトルを右クリックし、図6-6に示すメニューを選択します。

図6-6 概要のドリルダウン

表6-1に示すオプションがあります。

表6-1 KPIのコンテキスト・メニュー・オプション

オプション

説明

関係付け

選択したKPIの所定期間における変動を、他のKPIおよびパフォーマンス・メトリックと比較できます。この詳細は、6.2項「KPIの変動の比較」に記載されています。

編集

KPIの定義を変更できます。設定の詳細は、7.2項「KPIおよびSLAの定義」に記載されています。

名前の変更

選択したKPIの名前変更や、別のカテゴリへの移動が可能です。

コピー

選択したKPIをコピーできます。これは、既存のKPIを新規KPIのベースとして使用する場合に役立ちます。詳細は、7.3.1項「既存のKPIのコピー」を参照してください。

ダッシュボードに追加

現在選択しているKPIを指定したダッシュボードに追加します。この機能は、第5章「ダッシュボードの使用」に記載されています。

アラート履歴の表示

選択したKPIに対して生成されたアラートをリストしたウィンドウが開きます。この詳細は、6.1.7項「アラート・ログの使用」に記載されています。

6.1.7 アラート・ログの使用

目的のKPIをクリックするか、またはメニューから「アラート履歴の表示」オプションを選択すると、KPIに対して生成されたアラート通知の詳細を示すウィンドウが開きます。例を図6-7に示します。

図6-7 アラート・ログの例

各アラートに関する情報は、そのアラートをクリックすると表示されます。ここでは、アラートで通知されたユーザーや通知方法などの情報が示されます。これは、7.5項「アラート・スケジュールの定義」で説明されているとおり、基礎となるアラート・プロファイルに基づきます。

6.2 KPIの変動の比較

KPIの相関機能では、選択したKPIの所定期間における変動を、同じ期間中の他のKPIおよびパフォーマンス・メトリックと比較できます。これにより、パフォーマンス上の問題点を見極め、関連する症状、およびそれに対して考えられる原因を特定できます。比較に含まれる特定のKPIは、現在定義されているKPIのアクセス・タイプ定義と、ユーザー・プロファイルで表示が許可されているアプリケーション、スイートおよびサービスによって異なります。

この機能を使用するには、「相関」構造からKPIを選択します。または、「概要」構造からKPIを選択し、図6-6に示すコンテキスト・メニューから「関係付け」を選択します。図6-8に示すような画面が表示されます。

図6-8 KPI相関

左矢印および右矢印コントロールを使用して、表示される履歴を変更してから、グラフ上部のコントロールを使用して目的の期間を指定します。期間は、1時間から6時間の範囲から選択できます。「範囲の適用」をクリックし、一致したメトリックを表示します。

「KPI」タブには、現在定義されているKPIのうち、指定した期間の変動が、選択したKPIのものに一致する全KPIがリストされます。他のタブ(「すべてのページ」や「遅いURL」など)には、関連付けられているデータ・ブラウザ・グループのうち、選択期間における当該KPIの変動に一致するメトリックがリストされます。これらのタブが表示されるかどうかは、選択したKPIと、インストールされているスイート・パッケージによって異なります。データ・ブラウザ・グループ(たとえば「失敗したページ」など)内にKPIの基となるメトリックが存在する場合、そのグループは「KPI相関」パネルにタブとして表示されます。

指定した期間は、新規KPIの選択時にも保持されます。新しい期間を指定するには、「期間の選択のリセット」をクリックし、前述の時間選択コントロールを使用して目的の新しい期間を指定し、タブをクリックして、見つかった一致を表示します。

6.1.5項「不完全なデータの使用」で説明したように、不完全なデータに基づくレポート対象期間は、境界が点線で表示されます。ただし、KPI概要と異なり、マウス・カーソルをその上に置いても、欠落しているデータのレベルは表示されません。

見つかった一致のドリルダウン

前述のように、選択したKPIに対して見つかった一致は、該当するデータ・ブラウザ・グループのタブでレポートされます。見つかった一致は、相関が90%以上の場合にのみレポートされます。例を図6-9に示します。

図6-9 「すべてのページ」のリストの例

一致したメトリックの右にある「参照」アイコンをクリックすると、データ・ブラウザ(第3章「データ・ブラウザの使用」を参照)が開き、基となるデータを調べることができます。メトリックに相関がない場合もレポートされます。

6.3 アラート・リストの使用

「KPIの概要」→「アラート」の順に選択すると、KPIが指定の範囲を外れたときに生成されたすべてのアラートの完全なリストを表示できます。たとえば、ユーザーのホーム・ページの閲覧者数が1時間当たり100名を下回った場合などです。例を図6-10に示します。

図6-10 アラート・リストの例

アラート・リストの左側に示されるアイコンについて、図6-11で説明します。

図6-11 アラート・リストのアイコン

6.3.1 アラートのフィルタリング

アラート・リストの上にあるコントロールを使用すると、表示されるリストを制限できます。特定のKPI、月、日または時間に対するフィルタリングが可能です。図6-12にこれを示します。

図6-12 アラートのフィルタリング

「KPI」メニューに表示されるメトリックのリストは、アラートが生成されたKPIに指定されているメトリックによって異なります。

6.3.2 アラートの表示

表示されたリスト内のアラートをクリックすると、その詳細を表示できます。例を図6-13に示します。

図6-13 アラートの詳細

これは、失敗したページ・ビューの数に関するアラートを示しています。KPIの範囲は0から10ページ・ビュー/分ですが、これが14.20に達しています。「テキスト・メッセージ」/「SNMP」/「電子メール」の各タブには、通知先ユーザーと、使用された連絡先情報がリストされます。通知を受けて、担当のスタッフ・メンバーは、クライアント・トラフィックの激減に対して考えられる原因の調査を開始できます。

「解析」タブをクリックして、選択したKPIに関連付けられているKPIの詳細情報を表示します。例を図6-14に示します。

図6-14 アラート解析タブ

「実行」コマンド・ボタンを使用して、アラートの関連付けられたKPIの変動と他のKPIおよびパフォーマンス・メトリックを比較します。この機能の使用方法は、6.2項「KPIの変動の比較」に記載されています。「データ・ブラウザ」メニューを使用して、選択されたグループ内でKPIのフィルタが事前に選択されたデータ・ブラウザを開きます。

7 パフォーマンスの監視の設定

この章では、KPIとSLAの定義方法について説明します。KPIとSLAは、ネットワークのパフォーマンスの監視に使用され、ダッシュボードおよびレポートで確認できます。また、サービス・レベルに影響を与えるインシデントをスタッフ・メンバーに通知する際に使用するアラートの管理(誰にいつ通知するかなど)についても取り上げます。KPIとSLAを定義および変更するには、「完全」アクセス・レベル権限が必要です(14.2項「ユーザー・アカウントのロールと権限の概要」を参照)。

7.1 概要

品質保証契約(SLA)は、顧客に対するプロバイダの責任および顧客が期待するサービス・レベルの各条件を明確にする、プロバイダと顧客間の合意です。通常、この合意は、いくつかのキー・パフォーマンス・インジケータ(KPI)を使用して明示されます。これは、組織の業績の特定項目を測定およびベンチマーキングするための手段です。

たとえば、特定サービスのSLAでは、99.999%の稼働時間を約束する場合があります。これは顧客に対する保証であるため、組織ではこれをKPIとして作成することができます。これによって、サービス可用性が監視され、このレベルより低下するたびに、担当のスタッフに通知され、修正処理がとられます。

組織では、SLAとは別に、独自にパフォーマンスを監視するためにKPIを設定する場合もあることを理解しておく必要があります。KPIによって組織の業績を把握できるため、管理ダッシュボードの構成要素としてKPIが追跡される場合もあります。

7.2 KPIおよびSLAの定義

KPIを作成し、オプションでそのKPIをアラートおよびサービス・レベルのベースとして使用する手順は、次のとおりです。

1. 「構成」→「サービス・レベル管理」→「KPI」を選択し、「新規KPI」ボタンをクリックします。図7-1に示すダイアログが表示されます。

図7-1 キー・パフォーマンス・インディケータ(KPI)

2. 監視対象KPIの「名前」および「カテゴリ」を指定します。新しいカテゴリ名を指定すると、そのカテゴリが自動的に作成されます。

3. 次の点に注意して、「メトリック」、「エンティティ」、「計算」および「単位」フィールドを使用してKPIを定義します。

- 選択したメトリックによっては、他のフィールドに値を指定する必要がない場合もあります。

- 計算に複数の入力が必要な場合があります。たとえば、「ページ・ロード時間」メトリックを選択した場合は、参照先のユーザー・フローを指定する必要があります。表示されるリストに目的のオプションがない場合は、「検索」アイコンをクリックして検索できます。

- メトリックの詳細は、E.2項「KPIのメトリック」を参照してください。

- KPI定義を保存した後でこれらのフィールドを編集することはできません。

4. KPIの「計算期間(分)」を指定します。これは1から15分の間の値にすることができ、後で編集できます。

注意:
すべてのKPI値は1分ごとに計算されます。この設定によりKPI値を計算するための時間ウィンドウが決定されます。たとえば、KPIとして平均ページ・ロード時間を選択して計算期間を5分に設定した場合、KPIは過去5分間の平均ロード時間を使用して1分ごとに更新されます。

5. 「説明」タブのフィールドにKPIの簡単な説明を入力します。その他のタブについては、次の各項で説明しています。

- 7.2.1項「KPIへの条件の適用」では、KPIにフィルタを追加できます。

- 7.2.2項「KPIへのターゲット値の適用」では、KPIの最小範囲と最大範囲、およびターゲットの計算方法を定義できます。

- 7.2.3項「KPIへの前提条件の適用」では、選択したメトリックの要件を追加できます。この機能を使用すると、複合KPIを作成できます。

- 7.2.4項「KPIへのサービス・レベル合意の適用」では、KPIをSLAに関連付けることができます。その場合、特定の期間において保証する合意のレベル(パーセント単位)を構成できます。

- 7.2.5項「KPIへのアラート・スケジュールの適用」では、アラートをKPIに関連付けることができます。この場合、準拠していないKPIに対してアラートが発行されるまでの時間を定義する必要があります。

6. 「保存」をクリックします。

7.2.1 KPIへの条件の適用

「KPI」画面の「条件」タブを使用すると、メトリックまたはディメンション・レベルの条件に一致する値にKPIのデータをフィルタできます。集計関数に基づくメトリック・フィルタリング(5ミリ秒未満のロード時間の個別の測定ではなく5ミリ秒未満のすべてのページビューの平均ロード時間など)が必要な場合、「前提条件」タブを使用してその前提条件を作成することを検討してください。

1. 「構成」→「サービス・レベル管理」→「KPI」から、編集するKPIを選択します。図7-1に示すような画面が表示されます。

2. 「条件」タブを選択し、「追加」をクリックして新しい条件を挿入します。「条件の追加」画面が表示されます。

3. 「条件タイプ」で、「ディメンション・レベル」または「メトリック」を選択します。オプションとして表示されるメトリックおよびディメンションの詳細は、付録E「データ・アイテムの概要」を参照してください。

4. 手順3で選択した項目に応じて、「ディメンション・レベル」または「メトリック」を選択します。結果のフィールドはここでの選択によって決まるため、正確な条件を作成できます。

5. 条件の詳細を入力します(たとえば、「データベース処理時間」を50ミリ秒から500ミリ秒の範囲にします)。
大部分のディメンション・レベル(アプリケーション名またはクライアントの場所を除く)に、1つ以上のワイルドカード(*)文字を指定できます。異なるディメンションに対するフィルタは、論理AND句の一部とみなされますが、同じディメンションに対する複数のフィルタは、論理OR句の一部とみなされることに注意してください。たとえば、2つのクライアント・ブラウザ条件(「Firefox」用の条件と「Chrome」用の条件)を作成すると、KPIはFirefoxブラウザとChromeブラウザの両方によるリクエストに適用します。

6. 必要な条件をすべて作成した後、「保存」をクリックします。

7.2.2 KPIへのターゲット値の適用

「KPI」画面の「ターゲット」タブでは、値の範囲をKPIに関連付けることができます。たとえば、KPIでエラー・レベルをパーセンテージで測定する場合、0%から5%のターゲット範囲を作成できます。

1. 「構成」→「サービス・レベル管理」→「KPI」から、編集するKPIを選択します。図7-1に示すような画面が表示されます。

2. 「ターゲット」タブを選択します。

3. 「ターゲット・タイプ」で、「固定値」または「自動」を選択します。

4. 手順3で「固定値」を選択した場合、KPIの「最小値」と「最大値」を入力します。

5. 手順3で「自動」を選択した場合、自動学習ターゲットに「偏差(小)」、「偏差(中)」、「偏差(大)」のいずれを使用するかを選択できます。この機能の使用方法の詳細は、7.3.3項「自動ターゲットおよび固定ターゲット」を参照してください。

6. 「保存」をクリックします。

7.2.3 KPIへの前提条件の適用

「KPI」画面の「前提条件」タブでは、KPIのデータをフィルタできます。「条件」タブではメトリックや簡易なオペレータを使用してフィルタできるのに対して、前提条件ではKPIの定義時と同じ計算オプションを使用してフィルタできます。この指定により、複合メトリック条件を作成できます。たとえば、監視対象サービスに対して、リクエストしたページの98%でエンドツーエンドのページ時間が3から5秒におさまるという要件を、1分当たりのページ・ビュー数が5から10の場合にのみ適用することが可能です。

1. 「構成」→「サービス・レベル管理」→「KPI」から、編集するKPIを選択します。図7-1に示すような画面が表示されます。

2. 「前提条件」タブを選択し、「追加」をクリックして新しい前提条件を挿入します。「前提条件の追加」画面が表示されます。

3. 前提条件に使用する「メトリック」を選択します。メトリックの詳細は、E.2項「KPIのメトリック」を参照してください。

4. 次の点に注意して、「メトリック」、「エンティティ」、「計算」および「単位」フィールドを使用して前提条件を定義します。

- 選択したメトリックによっては、他のフィールドに値を指定する必要がない場合もあります。

- 前提条件の期間や条件はKPIによって決定されるため、入力しないでください。

5. 前提条件の条件を入力します。たとえば、「演算子」を「次の範囲内」に設定し、「最小値」と「最大値」の値を入力します。

6. 「保存」をクリックします。

7.2.4 KPIへのサービス・レベル合意の適用

「KPI」画面の「サービス・レベル合意」タブでは、ターゲット達成のレベルを設定できます。特定の期間において保証する合意のレベル(パーセント単位)を構成できます。

1. 「構成」→「サービス・レベル管理」→「KPI」から、編集するKPIを選択します。図7-1に示すような画面が表示されます。

2. 「サービス・レベル合意」タブを選択します。

3. 「有効」オプションを選択します。

4. ターゲット達成のパーセント値を入力します。たとえば、年単位では全時間の98%でサービスが指定の目標を満たすことを保証します。ただし、時間単位では保証を80%にし、日単位では90%にします。すべての期間フィールドが必須です。

5. 「保存」をクリックします。

7.2.5 KPIへのアラート・スケジュールの適用

「KPI」画面の「アラート」タブでは、KPIをアラート・スケジュールに関連付けることができます。

1. 「構成」→「サービス・レベル管理」→「KPI」から、編集するKPIを選択します。図7-1に示すような画面が表示されます。

2. 「アラート」タブを選択します。

3. 1つ以上のアラート・スケジュールを選択します。アラート・スケジュールの定義については、7.5項「アラート・スケジュールの定義」で説明します。

4. 停止時のトリガー(分)フィールドに、準拠していないKPIに対して「停止」アラートがトリガーされるまでの時間(分)を入力します。

5. 稼働時のトリガー(分)フィールドに、準拠しているKPIに対して「稼働中」アラートがトリガーされるまでの時間(分)を入力します。

6. 「重大度」で、KPIに適したオプション(「警告」など)を選択します。

7. KPIが準拠したときにアラートを生成する場合は、稼働時のトリガー(分)フィールドに「起動時の通知」オプションを有効にします。

8. 「保存」をクリックします。

7.3 既存のKPIの変更

既存のKPIの定義を確認および変更するには、「構成」→「サービス・レベル管理」→「KPI」を選択し、表示されたリストから目的のKPIを選択します。図7-1に示すような画面が表示されます。

タブを使用すると、選択したKPIに特有の項目を見つけ、項目の定義を確認および変更できます。項目に関連付けられる設定は、7.2項「KPIおよびSLAの定義」で説明した設定と同じです。

KPIの変更、名前変更、移動または削除を実行するには、KPIを右クリックして、メニューから「名前の変更」、「コピー」または「削除」オプションを選択します。KPIを変更するには、「編集」オプションを選択します。この手順については、7.2項「KPIおよびSLAの定義」で説明しています。

KPIをダッシュボードに追加するには、KPIを右クリックして「ダッシュボードに追加」を選択します。ダッシュボードの詳細は、第5章「ダッシュボードの使用」を参照してください。

7.3.1 既存のKPIのコピー

新規KPIを最初から作成(7.2項「KPIおよびSLAの定義」を参照)できるのみでなく、既存のKPIのコピーを作成し、それを新規KPIのベースとして使用することもできます。これは、新規KPIが既存のKPIとよく似ている場合は特に便利です。たとえば、アメリカでのユーザー・フローの可用性を監視するKPIがすでに存在し、カナダ用に新しいKPIを作成する場合などです。既存のKPIを新規KPIのベースとして使用する手順は、次のとおりです。

1. 「構成」→「サービス・レベル管理」→「KPI」を選択し、表示されたリストから目的のKPIを右クリックします。メニューから「コピー」を選択します。図7-2に示すダイアログが表示されます。

図7-2 「KPIのコピー」ダイアログ

2. 新規KPIの新しい名前と場所を指定します。オプションで、「カテゴリの追加」をクリックし、新規カテゴリを作成します。次に、「保存」をクリックします。

3. 7.3項「既存のKPIの変更」で説明している手順を使用して、要件に合うように新規のKPIを変更します。

7.3.2 KPIの計算範囲について

すべてのKPI値は1分ごとに計算されます。この設定によりKPI値を計算するための時間ウィンドウが決定されます。たとえば、KPIとして平均ページ・ロード時間を選択して計算期間を5分に設定した場合、KPIは過去5分間の平均ロード時間を使用して1分ごとに更新されます。

デフォルトでは、KPIの計算期間は1分です。ただし、期間を長くして極端な値が平均に及ぼす影響を抑えるには、計算範囲を長めに指定すると役立ちます。計算期間を編集するには、「構成」→「サービス・レベル管理」→「KPI」を選択し、編集するKPIを右クリックしてメニューから「編集」を選択します。これにより、KPIの「計算期間」を編集できるようになります。

1分を超える計算期間のKPI値のレポート

KPIの値は、1分間の期間が終わるたびに計算されます。KPIの計算期間が1分より長く、KPI計算が別のタイム・スケール(たとえば、1時間当たりの平均ページ・ロード時間など)で計算された係数のパーセンテージである場合、KPI値は、計算期間全体の平均を使用して1分ごとにレポートされた値の平均として計算されます。同時セッションおよびパーセントKPIのレポートされた値を解釈する場合、この点に注意することをお薦めします。

7.3.3 自動ターゲットおよび固定ターゲット

前述のように、KPIで自動(自動学習)ターゲットを使用するように指定できます(7.2.2項「KPIへのターゲット値の適用」を参照)。通常、ビジターのトラフィックおよび使用状況パターンは、午後のビジターの数より夜間のビジターの数のほうが少なかったり、日によってビジターの数に差がるなど、1日のうちに大きく変動します。

自動ターゲットの計算にこれを正確に反映するために、次のように動作する評価アルゴリズムが使用されます:

最初に、特定の1分間の最小ターゲットと最大ターゲットは、その期間前後のサンプリング・ウィンドウ内のデータから常に計算されます。これにより、確実に特定期間前後の値の変動における一般的傾向が考慮されます。

次に、ここ数日間の同じサンプリング期間のデータも参照します。これにより、確実に特定の期間の値の変動における日次傾向も考慮されます。たとえば、毎日午前11時のビジターの総数が週の経過とともに増加している場合などです。

サンプリング・ウィンドウのサイズ、および使用する過去の日数は、KPIに割り当てられたKPIしきい値プロファイルによって指定されています。しきい値プロファイルの定義については12.13項「KPIしきい値プロファイルの定義」、KPIへのしきい値プロファイルの割当てについては7.2.2項「KPIへのターゲット値の適用」を参照してください。

これとは対照的に、固定KPIターゲットはその性質上、最小と最大のどちらの場合も直線になります。図7-3にこれを示します。

図7-3 自動KPIターゲットと固定KPIターゲットの比較

自動学習ターゲットの使用時は、次の点に注意してください。

- 自動学習ターゲットが使用可能になるには、少なくとも1日が経過している必要があります。当然ながら、使用できる履歴データの日数が多いほど、計算される自動ターゲットの信頼性が高くなります。自動学習ターゲットでKPIが作成された最初の日は、アラートの生成を避けるために、これらのターゲットは実際に記録される値の少し上または下に自動的に設定されます。

- メトリック値が高すぎる、または低すぎる場合、自動学習ターゲットは問題の存在を示す場合がありますが、問題が長期化すると、それらの異常値が自動学習ターゲットに含まれるようになり、その結果、正常な変動値であると解釈されることになります。

- 自動学習ターゲットは、KPI値を毎日ほぼ同じ時間に取得できない場合、大幅に低下することがあります。たとえば、18:00以降にネットワーク・トラフィックがない場合がこれに該当します。

KPIで自動ターゲットを使用するように定義し、その後、固定ターゲットを使用するようにKPIを変更すると、それまでに計算されたターゲット(一定期間KPIを監視して導出されたターゲット)が新しい固定ターゲットとして設定されます。KPIに設定する固定ターゲットが不明な場合は、この機能を使用して、現実的な初期値を取得できます。この値は、いつでも自由に変更できます。

7.4 サービス・レベル・スケジュールの定義

組織で達成したサービス・レベルの追跡に使用するKPIを定義するのみでなく、これらのサービス・レベルをいつ適用するかも指定する必要があります。通常、組織ではコア・タイム(月曜日から金曜日の9:00AMから5:00PMなど)が設定されており、このコア・タイムでは、約束したサービス・レベルを達成する必要があります。ただし、この例外として祝祭日などの定義も必要です。たとえば、復活祭の月曜日の10:00AMから4:00PMのサービスを制限する必要がある場合などです。最後に、計画的なメンテナンス期間も考慮に入れる必要があります。

計画的なサービス・レベルのスケジュールは、「サービス・レベル・スケジュール」(図7-4を参照)で管理します。これを開くには、「構成」→「サービス・レベル管理」→「サービス・レベル・スケジュール」を選択します。

図7-4 サービス・レベル・スケジュール

「サービス・レベル・スケジュール」内で期間を選択するには、対象となる週の期間にわたってクリックしてドラッグします。選択した期間にステータスを割り当てるには、「アクティブ」または「非アクティブ」モードをクリックします。

例外を定義するには、正符号のアイコン(+)をクリックして「例外」リストから日、月および年を選択します。例外を削除するには、例外の右にある負符号のアイコン(-)をクリックします。

この変更内容は、「保存」をクリックするまでは有効にならないことに注意してください。終了すると、保存していない変更内容は廃棄されます。

7.5 アラート・スケジュールの定義

組織内でアラートを使用して、サービス・レベルに影響のあるインシデントをスタッフ・メンバーに通知する場合、通知する必要のあるユーザーとタイミングを指定する必要があります。これは、アラート・スケジュールを作成して行います。業務上の要件を満たす十分なスケジュールを定義できます。

KPIを定義する場合、KPIで使用するアラート・スケジュールを指定します(7.2.5項「KPIへのアラート・スケジュールの適用」を参照)。各アラート・スケジュールは、ユーザーのグループ、通知の詳細および稼働時間枠で構成されます。標準の運用時間に対する例外も定義できます。KPIで使用するアラート・スケジュールを定義するには、次の手順を実行します。

1. 「構成」、「サービス・レベル管理」、「アラート・スケジュール」の順に選択します。図7-5に示すウィンドウが表示されます。

図7-5 アラート・スケジュールの例

2. 「ビュー」メニューを使用して、現在使用できるアラート・スケジュールを確認します。
例外を定義するには、正符号のアイコン(+)をクリックして「例外」リストから日、月および年を選択します。例外を削除するには、例外の右にある負符号のアイコン(-)をクリックします。スケジュール内で期間をマークするには、対象となる週をクリックし、期間にわたってドラッグします。アラート・プロファイルのいずれかをクリックして、選択した期間を割り当てます。

この変更内容は、「保存」をクリックするまでは有効にならないことに注意してください。終了すると、保存していない変更内容は廃棄されます。

3. ツールバー内の「新規」をクリックして、新しいアラート・スケジュールを定義します。図7-6に示すダイアログが表示されます。

図7-6 アラート・スケジュールの追加

4. アラート・スケジュールの一意の名前を指定し、オプションで簡単な説明を指定します。その有効範囲と目的を示すことをお薦めします。次に、「保存」をクリックします。

5. 次の項の説明に従って、通知するユーザーを指定します。

7.5.1 アラート・プロファイル

アラート・プロファイルでは、アラートの生成に必要な指定期間、KPIが停止している場合に、どのユーザーに通知するかを定義します。KPIの定義方法によっては、これらのユーザーは、設定済のターゲット範囲内にKPIが戻ったときにも通知を受けます。

たとえば、「完了したユーザー・フロー」メトリックにKPIを定義し、通常の操作には70%以上の成功率が必要であることを指定したとします。KPIがコア営業時間内(月曜日から金曜日の9:00AMから5:00PM)にこのレベルを下回ると、Webアプリケーションのすべてのビジネス・マネージャが通知を受けます。この時間外に未達成が発生した場合は、ヘルプデスクが通知を受けます。

各プロファイルをカスタマイズするには、プロファイルを右クリックし、コンテキスト・メニューから「編集」を選択します。図7-7にこれを示します。

図7-7 アラート・プロファイルのコンテキスト・メニュー

図7-8に示すダイアログが表示されます。

図7-8 「アラート・プロファイル」ダイアログ

このダイアログを使用して、通知先ユーザーの名前と簡単な説明を指定します。このダイアログのその他のタブを使用して、電子メール、SNMPおよびテキスト・メッセージの通知の受信者を指定します。それぞれの方法の「有効」チェック・ボックスを使用して、通知をアクティブにします。

注意:
テキスト・メッセージベースのアラートを受信した場合、携帯電話で表示されるメッセージのタイムスタンプが、インストール済RUEIに記録されているタイムスタンプと一致しない場合があります。これは、携帯電話のタイムゾーンの違いが原因です。

7.5.2 エスカレーション手順

図7-9に示す「エスカレーション」タブでは、KPIが引き続きレベルを下回る場合にアラートの受信者に送信するアラームを設定できます。また、定義した期間を経過した後にもKPIが引き続きレベルを下回っている場合のエスカレーション手順も定義できます。たとえば、3時間を経過してもKPIが引き続きレベルを下回っている場合、別のグループに通知します。このエスカレーション・グループをカスタマイズするには、グループを右クリックし、コンテキスト・メニューから「編集」を選択します。

図7-9 「エスカレーション」タブ

7.5.3 測定および通知間隔

KPIには、KPI状態とアラート状態という2つの関連する状態があることを理解しておく必要があります。KPI状態は、測定間隔ごとに異なる場合があります。アラート状態は、アラートに定義するプロパティで制御されます。たとえば、計算範囲を5分(デフォルト)、レベルを下回る期間を15分と定義しているときに、KPIがレベルを下回り始めた場合を考えます。5分後にもKPIは未達成であるとみなされますが、15分連続してレベルを下回らないかぎり、未達成であることは通知されません。

同様に、図7-9で指定するアラームとエスカレーションの期間は、アラートに関連しています。つまり、アラームの期間を1時間ごとに指定すると、KPIの未達成状態が続いている間は、最初のアラートが送信された後に、アラーム通知が60分ごとに生成されます。これらの設定に指定する値は、業務上の要件を満たすように慎重に検討することをお薦めします。

7.5.4 アラート・メッセージのテスト

電子メール、SNMPまたはテキスト・メッセージの通知を有効にしている場合、図7-7に示したメニューの「テスト・プロファイル」オプションを使用して、アラートまたはエスカレーション・プロファイルで指定されている全受信者にテスト・アラートを送信できます。これは、連絡先情報が正しく入力されていることをテストする際に便利です。テスト通知の確認を求められます。

7.5.5 メール通知の使用方法

電子メール・アラートの受信者を定義するには、「電子メール」タブをクリックしてダイアログ(図7-10を参照)を開き、次の手順を実行します。

図7-10 「電子メール」タブ

1. 「受信者」フィールドを使用して、通知先ユーザーの電子メール・アドレスを指定します。「追加」をクリックして、ユーザーを通知リストに追加します。ユーザーをリストから削除するには、ユーザーの右にある「削除」アイコンをクリックします。

2. 「有効化」チェック・ボックスを選択し、電子メール通知をアクティブにします。次に、「保存」をクリックします。

7.5.6 SNMP通知の使用方法

SNMPアラートの受信者を定義するには、SNMPタブをクリックしてダイアログ(図7-11を参照)を開き、次の手順を実行します。

図7-11 「SNMP」タブ

1. 「有効」チェック・ボックスが選択されていることを確認してください。選択されていない場合、SNMPトラップは生成されません。

2. 「バージョン」リストを使用して、使用しているSNMPプロトコルのバージョンを指定します。デフォルトはバージョン2cです。

3. 「マネージャ・アドレス」フィールドを使用して、クライアント・ソフトウェアのアドレスを指定します。これは、有効なネットワーク・アドレスである必要があり、IPアドレスまたはホスト名を指定できます。

4. 「コミュニティ」フィールドを使用して、情報の送信先となるグループを指定します。この文字列は、クライアントからサーバーへのアクセスを制御するパスワードとして機能します。

5. 「有効化」チェック・ボックスを選択し、SNMP通知をアクティブにします。

6. 管理情報ベース(MIB)定義をダウンロードし、管理対象オブジェクトのアドレス帳に取り込みます。この定義には、受信したSNMPメッセージの解釈方法に関して必要な情報が含まれています。ファイル(oracle-ruei.mib)は、RUEI/extraディレクトリのRUEIインストールzipファイル内でも使用できます。MIBファイルの構造を図7-12脚注1に示します。

図7-12 SNMP MIBの構造

MIBにあるKPIの情報およびメトリックは、システム内に構成されている各KPIの最も重要なプロパティを表し、フィルタリングおよびアラート通知のベースとして使用できます。KPIの情報およびメトリックを表7-1に示します。

表7-1 KPIの情報およびメトリックの構造

オブジェクト

型

kpiName

英数字

kpiCategory

英数字

kpiValue

値

kpiMin

値

kpiMax

値

kpiSeverity

英数字

kpiDuration

値

kpiDescription

英数字

eventDateTime

値(形式: YYYYMMDDHHMMSS)。

eventSource

英数字

eventCode

整数

eventDescription

英数字

eventUser

値

eventRepeatCount

整数

kpiCalculationRange

整数

SNMPアラート内のKPI名は、UTF-8形式で送信されます。KPI名に含まれる文字で、ISO-Latin-1形式以外の文字は、疑問符(?)文字に置換されます。また、SNMPマネージャの中には、UTF-8を完全にはサポートしていないものもあります。詳細は、ご使用のSNMPマネージャの製品ドキュメントを参照してください。

デフォルトのSNMPポートの変更

デフォルトでは、SNMPアラートはポート162に送信されます。これを変更するには、「マネージャ・アドレス」(図7-11)の一部として必要なポートを指定する必要があります。次に例を示します。

194.158.1.23:10162

7.5.7 テキスト・メッセージ通知の使用方法

テキスト・メッセージ通知を定義するには、「テキスト・メッセージ」タブをクリックしてダイアログ(図7-13を参照)を開き、次の手順を実行します。

図7-13 「テキスト・メッセージ」タブ

1. 「受信者」フィールドを使用して、通知先ユーザーの電話番号を指定します。「追加」をクリックして、ユーザーを通知リストに追加します。ユーザーをリストから削除するには、ユーザーの右にある「削除」アイコンをクリックします。

2. 「有効化」チェック・ボックスを選択し、テキスト・メッセージ通知をアクティブにします。次に、「保存」をクリックします。

3. テキスト・メッセージ・プロバイダをまだ構成していない場合は、構成が必要です。まだ構成されていないという警告が表示された場合は、警告リンクをクリックし、15.8項「テキスト・メッセージ・プロバイダの構成」で説明されている手順に従ってください。

脚注

脚注1: この画面は、iReasoning MIBブラウザ(http://www.ireasoning.com)の画面です。このユーティリティは、RUEIの付属ソフトウェアとしては出荷されておらず、別途ライセンスが必要です。これは、付属のMIBファイルの構造を示すことのみを目的としています。

8 Webページの識別とレポート作成

この章では、監視するWebページを識別する方法について説明します。特に、追加情報を利用する必要があるWebページおよび特定のテキスト文字列の出現を監視する必要があるページを定義する方法について説明します。また、規則指定機能と他の高度な機能の使用方法についても説明します。最後に、SSOベースの環境におけるトラフィックの監視について説明します。

URL引数

アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があることに注意してください。

8.1 ページのネーミング

RUEIにおけるページの識別は、アプリケーションに基づいて行われます。一般的に、アプリケーションはWebページの集合です。通常、Webサイトのページは特定のアプリケーションにバインドされているためです。アプリケーション内の各ページには名前が割り当てられていて、それぞれのページはグループに属します。たとえば、「MyShop » Contact » About us」は、MyShopアプリケーション内のContactグループの「About us」ページを指します。

各アプリケーションには、アプリケーションの有効範囲を定義するページ・ネーミング・スキームが関連付けられています。スキームの指定には、ドメイン名の一部またはURL構文の一部、あるいはその両方の組合せを使用できます。また、ページ・ネーミング・スキーム(ページ・タグ付けやHTMLページのタイトル部分など)は、アプリケーション定義を微調整する際にも指定できます。

RUEIで検出される各ページに対し、スキームは、存在するアプリケーション定義を使用して名前を割り当てます。これらの定義を使用して識別できないページに関する情報は廃棄されるため、レポートおよびデータ・ブラウザでは使用できません。

アプリケーション・ページは、自動検出できるのみでなく、手動で定義することもできます。手動定義が特に役立つのは、URL構文に一貫性のない場合や、識別されたページにサブページが含まれる場合、またはアプリケーションによって自動的に割り当てられた名前とは違う名前を割り当てる必要がある場合です。手動で定義されたこれらのページは、アプリケーション定義で自動的に識別されたページより優先されることに注意してください。

現時点で定義されているアプリケーションとそのグループおよびページの構造を表示するには、「構成」→「アプリケーション」→「アプリケーション」の順に選択します。例を図8-1に示します。

図8-1 「アプリケーション概要」の例

8.2 タグ・ベースのアプリケーション

8.3項「アプリケーションの定義」で、タグ・ベースまたはネットワーク・ベースのデータ・コレクタを使用してアプリケーションを監視する方法について説明します。

タグ・ベースのアプリケーションではタグ・データ・コレクタが使用されますが、ネットワーク・データ・コレクタは使用されず、アプリケーション構成でヘッダー、XPathおよびコンテンツ・ソースからのデータの収集は適用されません。たとえば、ユーザーIDおよびコンテンツのメッセージはタグ・ベースのアプリケーションに適用されません。タグ・ベースのアプリケーションのユーザーを識別するには、oraInfo.userタグを使用します。ブラウザ例外を構成するには、コンテンツ・メッセージ内の特定の"ブラウザ例外"ソースを使用し、Javascriptライブラリにより送信されるCookieを使用するようにセッション・トラッキング構成を'Oracle'に設定します。

しかし、タグ・ベースのアプリケーションを使用する場合、複数のメトリック(ヒット、アプリケーション言語、アプリケーション・テリトリ、詳細なタイミングやサイズなど)およびリプレイ機能は使用できません。

これらの制限を回避するために、タグ・ベースのコレクタに加えてネットワーク・データ・コレクタをインストールできます。10.2項「フレームワーク例外によるアプリケーション定義の微調整」の説明に従ってフレームワーク例外を作成して、タグ・ベースのトラフィックとネットワーク・ベースのトラフィックの両方が結合されたハイブリッド構成を作成します。

タグ・ベースおよびネットワーク・ベースの監視の設定の詳細は、RUEIインストレーション・ガイドの「RUEIソフトウェアのインストール」を参照してください。

8.3 アプリケーションの定義

アプリケーションを定義する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「アプリケーション」の順に選択し、「新規アプリケーション」をクリックします。図8-2に示すダイアログが表示されます。

図8-2 「新規アプリケーション」の構成

2. アプリケーションの名前を指定します。これは、スイート、サービス、SSOプロファイルとSSOアプリケーションを通じて一意である必要があります。アプリケーション名はレポートされるページに付加されるため、定義されたアプリケーション名をできるだけ短くすることをお薦めします。アプリケーションの名前は後から変更できないため、注意してください。

3. 残りのフィールドを使用して、アプリケーションの有効範囲を指定します。有効範囲はページURLを使用して定義されます。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。
最高レベルのフィルタはドメインです。アプリケーション名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できないことに注意してください。指定できるのはポート番号1つのみです。さらにポートを指定する必要がある場合は、新しいアプリケーションが作成された後で追加のフィルタとして指定してください。

特定のフィールドではワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、ドメインとURL引数の組合せによるその他の情報を指定しないことはできません。

注意:
スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。たとえば、ドメインoracle.comでフィルタリングされるアプリケーションと、oracle.com/application_servletでフィルタリングされる別のアプリケーションがある場合、予測できない結果が発生することがあります。一致規則の適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

注意:
アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があります。

一致対象とするURL GET引数を指定することもできます。この機能を使用する場合は、引数名と引数値の両方を揃えて指定することで初めて、検出されたページURLと一致することに注意してください。つまり、部分一致はサポートされていません。次に、「次へ」をクリックします。図8-3に示すダイアログが表示されます(「HTMLタイトル」がデフォルトで選択されています)。

8-3 「新規アプリケーション」ダイアログ

注意:
「タグ・ベース・アプリケーション」チェック・ボックスを選択した場合、次のページ・ネーミング・スキーマが表示されます。

- HTMLタイトル(ブラウザJSライブラリ)

- Oracle (ブラウザJSライブラリ)

- URLベースのオプション

4. タグ・ベースのアプリケーションを作成する場合は、そのオプションを選択し、「終了」をクリックします。タグおよびネットワークのデータ・コレクタの詳細は、8.2項「タグ・ベースのアプリケーション」を参照してください。

5. ネットワーク・データ・コレクタ・ベースのアプリケーションを作成する場合、このダイアログでは、アプリケーション内のページに使用する自動ページ・ネーミング・スキームを指定できます。各アプリケーションに対して指定できるスキームは1つのみです。次のオプション・グループがあります。

- ページのタグ付け: 標準スキーム(「Coremetrics」など)とカスタム・スキームのいずれを使用するかを指定します。カスタム・スキームの場合は、カスタム・タグの名前を指定する必要があります。「HTMLタイトル」オプションは、ページの<title>タグにあるテキストを使用してページを識別する必要があることを指定します。このオプションの使用方法の詳細は、8.3.4項「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。RUEIでサポートされているページ・タグ付けの汎用スキームの構造および処理は、付録A「タグ付け規則」に記載されています。

- クライアント・リクエスト: ページをそのURL構文に基づいて識別することを指定します。次のオプションにより、URLのどの部分を使用するかを指定します。

- URL引数: ページ・ネーミングは、URL内の指定した引数に基づきます。ASCII文字のみが許可され、特殊文字("&"および"|"など)をURLでエンコードする必要があることに注意してください。

- URL: ページ・ネーミングが、ビジターのブラウザのロケーション・バーに表示される完全なドメインとURLに基づきます。このスキームは規則指定を使用するときに特に役立ちます。

- URLディレクトリ: URLのディレクトリ部分のみを使用します。URLの各部分は、図8-4に示されています。

- URLベース: URLのメイン・ディレクトリとファイル名(ファイル拡張子は除く)の部分を使用します。

- URL全体: URLのメイン・ディレクトリ、ファイル名(ファイル拡張子は除く)および構成済の引数を使用します。このオプションを選択すると、ページ名に含める引数を指定するように求められます。このダイアログ・ボックスでは、複数の引数はアンパサンド(&)文字で区切る必要があります。たとえば、frmActionパラメータを定義した図8-4のURLは、myshop » shop » NL index frmAction=buyというページ名になります。

- リクエストのヘッダー: ページ・ネーミングでクライアント・リクエスト内の指定されたヘッダーを使用することを指定します。ヘッダー名で使用できるのはASCII文字のみです(「:」などの特殊文字は使用できません)。

- リクエストのXPath: クライアント・リクエストに適用されたXPath式に基づいてページを識別することを指定します。XPath式の使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。

- JSONリクエストのXPath: JSONクライアント・リクエストに適用されたXPath式に基づいてページを識別することを指定します。JSONリクエスト用XPath式の使用の詳細は、F.6項「JSONコンテンツでのXPath」を参照してください。

- HTTPメソッドおよびURL: ページ・ネーミングが、ビジターのブラウザのロケーション・バーに表示されるHTTPメソッドおよび完全なドメインとURLに基づきます。これにより、REpresentational State Transfer (REST)スタイルのアプリケーションのサポートが可能になります。このネーミング・スキーム・オプションは、HTTPメソッドおよびスペースで区切られた完全なURLをレポートします。アプリケーション定義を作成した後、アプリケーション概要でネーミング・スキームを選択して、URL規則指定を定義し、翻訳リストを作成します。

これらいずれかのオプションを選択した場合、使用方法の詳細は、8.3.4項「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。

図8-4 URL構文

- サーバー・レスポンス: サーバーのレスポンスに基づいてページを識別することを指定します。次のオプションがあります。

- レスポンスのヘッダー: サーバー・レスポンス内で指定されたヘッダーに基づいてページを識別することを指定します。

- レスポンスのXPath: サーバーのレスポンスに適用されたXPath式に基づいてページを識別することを指定します。XPath式の使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。

- JSONレスポンスのXPath: JSONサーバーのレスポンスに適用されたXPath式に基づいてページを識別することを指定します。XPath式の使用の詳細は、F.6項「JSONコンテンツでのXPath」を参照してください。

- 手動: アプリケーション・ページを自動検出せずに手動で定義することを指定します。このオプションを選択すると、監視するアプリケーションに関連付けられているすべてのページを手動で定義する必要が生じてくるため、注意してください。ページの手動定義の詳細は、8.3.20項「ページの手動識別」を参照してください。このオプションがデフォルトです。

次に、「終了」をクリックします。指定したアプリケーション定義が表示されます。例を図8-5に示します。

図8-5 「アプリケーション概要」の例

6. この概要には、定義したアプリケーションのサマリーが示されます。これには、アプリケーションの名前、これまでに一致した一意のページ数、最後に識別されたページの日付が含まれます。直前の3日間にアプリケーションについて識別されたページがない場合は、アプリケーションが現在機能していないことを示す警告のアイコンが表示されます。
タグ・ベースのアプリケーションを作成した場合、8.3.1項「ブラウザJSライブラリ設定の定義」の説明に従ってブラウザJSライブラリを定義する必要があります。

作成したアプリケーションはすぐに有効になります。これは、設定条件に一致するトラフィックがすべて記録されるという意味です。「データ収集が有効」ボックスの選択が解除されているときには、そのアプリケーションは存在しないものとしてトラフィック・ルールが適用されます。既存データはそのまま残り、アプリケーションはいつでも有効に戻すことができます。

画面の下部のタブでは、アプリケーションの具体的な項目の情報が表示されます。たとえば、「識別」セクションではアプリケーションに対して現在定義されているフィルタ基準のサマリーが表示されます。また、「ページ」セクションでは、使用されるページ・ネーミング・スキーム、未分類のページのレポート設定、ページ・ロード満足度のしきい値、アプリケーションに所属するこれまでに識別されたページが示されます。それぞれのセクションの詳細は次の各項で説明します。

注意:
アプリケーションを削除すると、構成とそれまで測定されたデータがすべて破棄されます。この操作は元に戻すことができません。

注意:
URLベースでないページ・ネーミング・スキームを使用してタグ・ベースのアプリケーションを作成し、後から(「タグ・ベース・アプリケーション」チェック・ボックスを選択解除することにより)そのアプリケーションを編集してタグ・ベースでないアプリケーションにした場合、そのページ・ネーミング・スキームは相当するページ・ネーミング・スキームに変換されます。たとえば、「HTMLタイトル(ブラウザJSライブラリ)」スキームは「HTMLタイトル」になります。
以前はタグ・ベースでなく、URLベースでないページ・ネーミング・スキームを使用していたアプリケーションに対して「タグ・ベース・アプリケーション」チェック・ボックスを選択すると、そのネーミング・スキームは「Oracle (ブラウザJSライブラリ)」に変換され、すべてのルーリングが削除されます。

8.3.1 ブラウザJSライブラリ設定の定義

タグ・ベースのアプリケーションを作成した場合、ブラウザJSライブラリ(監視対象のタグとして機能するアプリケーションによって提供されるURL)を定義する必要があります。

アプリケーションまたはスイートで使用されるブラウザJSライブラリを指定する手順は、次のとおりです。

1. 「構成」を選択し、「アプリケーション」または「スイート」を選択します。必要なアプリケーションまたはスイートを選択して、その概要を表示します。例を図8-1に示します。「ページ」タブ→「構成」タブの順にクリックします。

2. 「ブラウザJSライブラリ」設定をクリックします。図8-6に示すダイアログが表示されます。

図8-6 「ブラウザJSライブラリの編集」ダイアログ

3. リクエストされるオブジェクトのURLを指定し、オプションで、ページ上のオブジェクト数を記録するオプションまたは画面解像度を記録するオプション(あるいは、その両方)を有効にします。画面解像度に関連するデータを参照するには、「データの参照」を選択し、「ユーザー・フロー完了」または「すべてのセッション」を選択します。「クライアント画面解像度」に関連するデータを参照できるようになります。
「ブラウザ例外」オプションを選択した場合、すべてのJavaScriptエラーがRUEIに送信されます。後でこれらのエラーを確認するには、「データの参照」→「ブラウザ例外」を選択します。
ブラウザ・ヒットを確認するには、「すべてのページ」→アプリケーション・ヒットとブラウザ・ヒットを選択します。「URL」フィールドに、ワイルドカードを含まない絶対パスを指定します。監視対象のアプリケーションが別のドメインでホストされている場合、スキームを含む完全URIを指定します(例: http://myhost.com/images/marker.gif)。

注意:
タグ・ベースのアプリケーションを定義する場合、ブラウザJSライブラリURLは、強制オブジェクトとして定義されている拡張子を持つファイルを参照する必要があります(12.16項「ページとしてのオブジェクトのレポートの制御」を参照)。

ブラウザのナビゲーションに関するタイミングのレポートが必要な場合は、「ナビゲーション・タイミング」オプションを選択します。ナビゲーションのタイミングのレポート方法の詳細は、12.19項「ページ・ダウンロードおよびブラウザ時間レポートの最適化」を参照してください。

4. 「JavaScriptの生成」をクリックしてJavaScriptコードをダウンロードし、アプリケーション・ページに次の変更を加え、目的のアプリケーション・ページにコードを含めます。

- <head>タグと</head>タグの間に次の行を追加します。

<script type="text/javascript" src="ruei_library.js"></script>

前述の例は、JavaScriptライブラリがページ自体と同じwebserverパスにあることを前提とします。

- 次を<body onLoad>タグまたはページのレンダリングが終了している適切な場所に追加します。

<body onLoad="oraInfo.sendPageLoad();">

以前のリリースのRUEIでは、次のHTMLが推奨されていました。このコードは引き続きサポートされます。

<body onLoad="oraInfo.sendData();">

8.3項「アプリケーションの定義」の説明に従って、アプリケーションのページ・ネーミング・スキームとして「Oracle (ブラウザJSライブラリ)」を選択した場合は、次に説明するようにoraInfo.pageプロパティも設定する必要があります。

セキュリティ上の理由で、ワイルドカード文字の使用はサポートされていないことに注意してください。

ネットワーク・データ監視を使用するアプリケーションおよびスイートの場合、デフォルトでブラウザJSライブラリは構成されておらず、ブラウザJSライブラリを自分で定義しなければ、ページ・ブラウザ時間がゼロとしてレポートされます。また、レポートされたページ・ロード時間はページ・ブラウザ時間を含まないため、ページ・ロード/読取り時間分析が不正確になる可能性があります。ページがCDNサーバー(Akamaiなど)からリクエストされている場合、OnLoadイベントを使用すると、CDNで処理されるオブジェクトのレンダリング時間が含まれます。

タグ・ライブラリのプロパティ

タグ・ベースのアプリケーションを作成した場合、RUEIでは、予約されたタグ・ライブラリ・プロパティoraInfo.titleを使用してページ・タイトルが自動的にレポートされます。

さらに、JavaScriptコードを使用して次のプロパティも指定できます。

表8-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>

タグ・ライブラリを使用したページ・クリックの監視

タグ・ベースのアプリケーションを作成した場合、onclick oraInfo.sendActionプロパティを使用してページ・クリックを監視できます。たとえば、次のコードでは、ユーザーによる"Click here"リンクのクリックがレポートされます。

<a href="#" onclick="oraInfo.sendAction('clickAction');"> Click here</a>

ブラウザJSライブラリ・リンクの手動デプロイメント

8.3.1項「ブラウザJSライブラリ設定の定義」の手順4のかわりに、自分で指定したマーカー・オブジェクトへのリクエストを作成することもできます。リクエストが有効にされたときにRUEIはこれを検知し、ブラウザ時間になるようにリクエストの開始時間を記録します。指定するURL検索パターンはトリガーされるリクエスト内のURL検索パターンと一致している必要があります。

次に例を示します。

onLoad="m=new Image(); m.src='http://myhost.com/marker.gif?apikey=yourAPIkey&' + new Date().getTime();"

ここで、yourAPIkeyは、ブラウザJSライブラリ構成画面で指定したAPIキーです(図8-6を参照)。イベントは、HTMLページのBODY部分、またはその他の必要な場所(フラッシュ・プログラム内など)に含めることができます。

前述の例には、ブラウザ例外、ナビゲーション・タイミング、オブジェクト・カウントおよび画面解像度は含まれていません。これらを含める場合はJavaScriptライブラリが必要です。

ブラウザJSライブラリでのカスタム・ディメンションの使用

3.12項「カスタム・ディメンションの使用」の説明に従って「カスタム・タグ(ブラウザ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によってデータが収集され、後からこのデータを参照してレポートで使用できます(3.12項「カスタム・ディメンションの使用」を参照)。

8.3.2 ページ・ネーミング翻訳の適用

8.1項「ページのネーミング」に記載されている定義されたページ・ネーミング・スキーム以外に、ページ翻訳の使用によってアプリケーション・ページのレポートも変更できます。これらにより、ページのレポートされたpage-group » page-name仕様に行われる変換を指定できます。

ページ翻訳の定義

ページ翻訳を定義する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示したような)「アプリケーション概要」が表示されます。

2. 「ページ」タブ→「ページ翻訳」タブの順にクリックします。現在定義されているページの説明が表示されます。「新規翻訳の追加」をクリックして新しい説明を定義するか、既存の説明をクリックして変更します。図8-7に示すダイアログが表示されます。

図8-7 「ページ翻訳の追加」ダイアログ

3. 元のページIDおよびレポートされるグループと名前を指定します。元の値を形式group|nameで指定する必要があります。次に、「保存」をクリックします。

環境間のページ翻訳の移動

ページ翻訳は、アプリケーション自体と同時に作成することをお薦めします。そのためには、開発中のアプリケーションをRUEIで開始し、そこで定義されているページ翻訳を取得した結果に基づいて微調整するのが最も確実です。

デプロイの準備ができると、アプリケーションは本番環境に移動されます。その新しい環境が別のRUEIインストールによって監視される場合でも、アプリケーションのページ翻訳を手動で再作成する必要はありません。そのかわりに、ダウンロード機能を使用してその最新定義を取得し、生成されたファイルをアップロードして新しいRUEIインストールで使用することができます。

事前定義済のページ翻訳のリストを含むファイルをアップロードするには、次の手順を実行します。

1. 必要なアプリケーションを選択した後、「ページ」タブをクリックします。「アップロード・リスト」をクリックします。図8-8に示すダイアログが表示されます。

図8-8 ページ・トランザクションのアップロード

2. 「参照」ボタンを使用して、ページ翻訳ファイルの名前を検索および指定します。アップロードされるファイルの拡張子は.txtであることが必要です。必要に応じて、「ファイル・エンコーディング」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。ページ翻訳が重複した場合には、最後の翻訳が使用されます。ファイルには、1行に1つの翻訳のみを含めることができ、ページ・グループとページ名をタブで区切ります。次に、「マージ」をクリックします。

現在定義されているページ翻訳をダウンロードするには、「ダウンロード・リスト」をクリックします。ブラウザの構成方法によって異なりますが、ファイルの保存場所の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。

8.3.3 アクション翻訳の適用

8.3.23項「アクション・ネーミング・スキームの定義」で説明するように、アクション・ネーミング・スキームを、HTTPメソッドおよびURLなどに使用する場合、このスキームを、アクション翻訳を備えた、指定されたHTTPメソッドおよびURLなどに関連付けることができます。

アクション翻訳の定義

アクション翻訳を定義するには、次の手順を実行します。

1. 「構成」→「アプリケーション」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示したような)「アプリケーション概要」が表示されます。

2. 「ページ」タブをクリックし、「アクション翻訳」タブをクリックします。現在定義されているアクション翻訳が表示されます。「新規翻訳の追加」をクリックして新しい説明を定義するか、既存の説明をクリックして変更します。図8-7に示すダイアログが表示されます。

図8-9 「アクション翻訳の追加」ダイアログ

3. 元の値と、この値に関連付けるアクションを指定します。次に、「保存」をクリックします。

8.3.4 詳細設定の使用によるページとオブジェクトの処理の制御

「HTMLタイトル」スキームまたはクライアント・リクエストのページ・ネーミング・スキームのいずれか(「URLベース」など)を選択した場合、そのページ・ネーミング・スキーム内の「拡張」タブを使用して、これらのスキームの運用を微調整できます。「HTML title」スキームの場合は、図8-10に示すダイアログが表示されます。

図8-10 「Edit Application Page-Naming Scheme」ダイアログ

時間認識

「時間認識」メニューを使用して、ページを識別するために非強制オブジェクトを使用するかどうかを制御できます。図8-11に示す例について考えます。

図8-11 時間ベースの認識

この場合、ページ識別に使用することができる3つの非強制オブジェクト(home.jsp、sub.jspおよびdown.jsp)があります。

有効なオプション(デフォルト)が「時間認識」メニューに指定されている場合、最初のオブジェクト(home.jsp)のみがページとして識別され、最後のオブジェクトがヒットしてから1秒以内にヒットが検出されなくなるまで、以降のすべてのヒットがオブジェクトとみなされます。ただし、「有効」の場合には、3つの非強制オブジェクトそれぞれ(jspなど)が検出時刻は考慮されずに別のページとして識別されます。強制オブジェクトの詳細は、12.16項「ページとしてのオブジェクトのレポートの制御」を参照してください。

大/小文字の制御

「拡張」タブにある「小文字変換」メニューを使用すると、ページ名を小文字に変換するかどうかを指定できます。表8-2に、使用可能なオプションを示します。

表8-2 大/小文字制御オプション

オプション

説明

いいえ

ページ名を元の大/小文字のまま維持します。これがデフォルトです。

ルーリング前

選択したアプリケーション、スイート、サービスについてレポートされるページ名を、「ルーリング」タブで定義されているすべてのルールを適用する前に小文字に変換します。テスト入力および検索式は小文字で入力する必要があります。

ルーリング後

選択したアプリケーション、スイート、サービスについてレポートされるページ名を、「ルーリング」タブで定義されているすべてのルールを適用する後に小文字に変換します。

サブヘッダーによる代用

「HTMLタイトル」ページ・ネーミング・スキームを選択した場合は、ページの<title>タグにあるテキストがページの識別に使用されます。このテキストが見つからない場合は、サブヘッダー<H1>、<H2>および<H3>を使用できます。このためには、「サブヘッダー代替」メニューを使用してこの機能を制御します。デフォルトでは、サブヘッダーは使用されません(「無効」)。

リダイレクトの処理

クライアント・リクエストベースのいずれかのスキーム(「URLベース」など)を選択して、「拡張」タブをクリックすると、図8-12に示すダイアログが表示されます。

図8-12 アプリケーション・ページ・ネーミング・スキームの編集

「ページの処理」メニューを使用して、URL内のリダイレクトをどのように処理するかを指定します。表8-3に示すオプションがあります。

表8-3 ページ処理オプション

設定

説明

最終ページ

ページ名を決定するために最終ページのURLのみを使用することを指定します。これがデフォルトです。

リダイレクト・ネーミング

最終ページの前でリダイレクトから得られる情報を使用してページを識別することを指定します。ない場合は、最終ページの情報が使用されます。

リダイレクトがなるページ

リダイレクトが実際に識別されるページになるように指定します。最初のリダイレクトがページ作成に使用され、その後のすべてのリダイレクトは作成されたページのオブジェクトになることに注意してください。アプリケーションのレポートに及ぼす結果をよく理解した場合のみ、このオプションを選択することを強くお薦めします。

注意:
ページ名がリダイレクトから導出された場合、完全セッション再生機能(4.1項「概要」を参照)とエラー・レポートが正しく機能しない場合があることに注意してください。

8.3.5 規則指定機能の使用方法

各アプリケーション定義では、使用するページ・ネーミング・スキームおよびユーザー識別スキームを指定する必要があります。また、必要に応じて、特定のアプリケーション・ページで表示されたときにレポートする必要のあるコンテンツ・メッセージを指定することも可能です。これらの各定義は、規則指定機能を使用して拡張できます。追加の一致規則を指定できるようになり、それによって選択したページ・ネーミング・スキーム、ユーザー識別スキームまたはメッセージの仕様を微調整します。

ページ・ネーミングの規則指定機能を使用しているときには、一致するURLについてのみレポートされます。URLが一致しない場合、完全に無視されます。規則指定機能は、自動(手動ではない)ページ・ネーミング・スキームおよびXPathベース(リテラルではない)のコンテンツ・メッセージのみで使用できることに注意してください。

推奨される使用方法

規則指定は複雑であるため、選択したアプリケーションの適切なスキームまたはメッセージ構文を十分理解しているユーザーのみがこの機能を使用することをお薦めします。たとえば、URLベースのページ・ネーミング・スキームの場合、選択したアプリケーションの基礎となるURL構文も明確に理解しておく必要があります。

注意:
「小文字変換」オプションで「ルーリング前」設定が適用されている場合、テスト入力および検索式は小文字で入力する必要があります。

ルールの定義

アプリケーションの規則指定の使用を指定するには、次の手順を実行します。

1. 「構成」を選択し、「アプリケーション」を選択します。目的のアプリケーションをクリックして概要を表示します。例を図8-1および図10-4に示します。

2. 必要な規則指定の使用方法に応じて、ページ・ネーミング・スキーム(「ページ」タブ内)、適切なユーザー識別スキーム(「ユーザー」タブ内)、または適切なコンテンツ・メッセージの仕様(「コンテンツ・メッセージ」タブ内)をクリックします。図8-13に示すようなダイアログが表示されます。

図8-13 「Edit Application Page-Naming Scheme」ダイアログ

3. 「ルーリング」タブをクリックして、使用する規則と、規則を評価する順序を指定します。図8-14に示すダイアログが表示されます。

図8-14 「ルーリング」タブ

4. このダイアログを使用し、新しい規則を定義するか、既存の規則を削除します。各規則のコンテキスト・メニューを使用して、適用順序を変更することもできます。「新規の一致ルールの追加」項目をクリックし、新しい一致規則を定義します。図8-15に示すようなダイアログが表示されます。

図8-15 一致ルールの追加

5. 規則の次の要素を指定します。

- 入力値: 予期されるスキーム(URLまたはページ・タグ付けなど)またはメッセージ仕様の構文を指定します。通常、受信したスキームまたは仕様を解釈するためのテンプレートを指定します。

- 検索式: 一致する必要があるスキームの定義または仕様を指定します。これは通常、必須のパラメータまたは要素からなるシーケンスで表されます。

- ページ・グループ: 受信したページ・ネーミング・スキームからページ・グループを識別する方法を指定します。これが未指定の場合、ページ・グループは空のままになります。このフィールドを使用できるのはページ・ネーミング規則のみです。

- ユーザーID/ページ名/コンテンツ・メッセージ: 受信したスキームまたは仕様からページ名、ユーザーIDまたはコンテンツ・メッセージを識別する方法を指定します。

- クライアント・ブラウザ/クライアント・ブラウザ・バージョン: 受信したユーザー・エージェント文字列からどのようにクライアント・ブラウザ/クライアント・ブラウザ・バージョンを識別するかを指定します。

6. 規則の要素を指定したら、「ルールのチェック」ボタンをクリックして、定義した規則が指定されている検証値と一貫性があることを検証できます。結果のウィンドウを展開すると、一致するプレースホルダのサマリーを表示できることに注意してください。例を図8-16に示します。

図8-16 規則チェック・ダイアログの例

次に、「保存」をクリックします。図8-14に示したダイアログに戻ります。

7. 必要なすべての規則を定義したら、「ルールのチェック」をクリックして、定義したすべての規則を検証値に対して検証できます。各検証値は、対応する規則に関連している必要があります。検証の後で、各規則の横にステータスを示すアイコンが表示されます。検証が失敗した規則については、マウスを重ねるとボックスに追加の情報が表示されます。図8-17に示す例について考えます。

図8-17 規則指定の検証の例

最初の規則は定義済の検証値と一貫性があり、正常に検証されています。ただし、2番目の規則は非常に汎用性が高いため、複数の評価規則がこの規則と一致すると警告されます。実際に、汎用性が高いために関連する検証値がすでに正常に適用されてしまい、後続の規則を適用できません。つまり、3番目の規則が使用されません。このため、2番目の規則ではなく3番目の規則についてエラーがレポートされます。ただし、2番目の規則を移動して最後の規則にすると、3つの規則が正常に検証されます。

エラーがレポートされた規則指定の定義を保存することは可能ですが、問題があれば規則指定の定義を保存する前に解決することを強くお薦めします。次に、「保存」をクリックします。規則指定の定義の変更は5分以内に有効になります。

URL一致に関する規則指定

URL一致では大/小文字が区別され、URL(一致の後)は小文字に変換されることに注意してください。規則指定の後で、一致したスラッシュはページ名において空白に置き換えられます。

また、URL構造に基づいてルーリングを実行する場合、「URL」ページ・ネーミング・スキームのみを使用することをお薦めします。これは、他のURLベースのネーミング・スキームが初期フォーマットの一部のフォームを実行するためです。

ユーザー識別に関する規則指定

ユーザー識別で規則指定を使用する方法は、ページ・ネーミングの場合と同じですが、ユーザー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の例を使用して指定できます。

クライアント・ブラウザの規則指定

クライアント・ブラウザの規則指定を使用すると、モバイル・アプリケーション・ベースのトラフィックとブラウザ・トラフィックを分離できます。たとえば、モバイル・アプリケーションがユーザー・エージェントMyApp/Shopping/v1.3を使用してWebページにアクセスできる場合、規則を使用すると、モバイル・アプリケーションがShopping、クライアント・バージョンがShopping 1.3とレポートされるようにできます。

入力値: MyApp/Shopping/v1.3

検索式: %/%/v%

クライアント・ブラウザ: %2

クライアント・ブラウザ・バージョン: %2~%3

規則内のページ・グループの識別

ページ・ネーミング・スキームで規則指定機能を使用するとき、ページ・ネーミング・スキームのソースにページ・グループが含まれる場合は、グループ値が正しく識別されるようにする必要があります。ソースがmyhost.com/myshop/menswear/catalog/basket.jspというURLページ・ネーミング・スキーム(「URL」を除く)の場合、内部ではmyshop\%7Cmenswear/catalogという構文に変換されます。その後、正しくレポートされるために次のように変換される必要があります。

入力値: myshop|menswear/catalog

検索式: %|%/%

ページ・グループ: %1

ページ名: %2

検索式で、グループとページ名の間の区切り文字のパイプ文字(|)をエンコードする必要はありません。URL構文内のスラッシュ記号は規則指定で使用できることに注意してください。規則指定の後で、一致したスラッシュは、レポートされるグループと名前においては空白に置き換えられます。

検索の構文

URL一致規則には、パラメータの他に、表8-4に示す要素も使用できます。

表8-4 拡張検索の構文

使用方法

説明

%

ゼロ個以上の文字に一致し、1つのプレースホルダに入力します。使用できるプレースホルダは%1から%9です。

%[!...]

URL引数内に指定した名前のいずれかに一致する1つの値を検索し、元のプレースホルダの1つと一致後のプレースホルダの1つに入力します。

%[&...]

URL引数内に指定した名前に一致するすべての値を検索し、元のプレースホルダの1つのパラメータ・プレースホルダと、指定した数のプレースホルダの1つのパラメータ・プレースホルダに入力します。

%[|...]

URL引数内に指定した名前に一致するゼロ個以上の値を検索し、元のプレースホルダの1つと指定した数のプレースホルダの1つに入力します。

%[c#]

指定した数の文字を検索します。

%[d]

URLのディレクトリ・パスを検索し、1つのプレースホルダに入力します。

%[f]

URLのファイル名パス(ファイル拡張子は除く)を検索し、1つのプレースホルダに入力します。

%[h]

URLのドメイン部分を検索し、3つのプレースホルダに入力します(たとえばa.b.name.co.ukに対する一致は、%1=a.b、%2=nameおよび%3=co.ukです)。

%[t...]

後続の文字の1つが一致するまで一致を試行し、1つのプレースホルダに入力します。

%[t^...]

指定したリストの文字に一致しない文字が見つかるまで一致を試行します。

%[^name=value]

指定したnameおよびvalueペアがURL引数で検出される場合に一致を試行します。1つのパラメータ・プレースホルダを入力します。

特殊文字(%、\、|、!、~)が文字どおりに解釈されるようにするには、前にバックスラッシュを付ける必要があります。たとえば、\%は、パラメータではなく、%文字そのものを示します。また、%文字の後の特殊文字(^、&、[、])もエスケープする必要があります。指定できるプレースホルダは最大9つまでであることに注意してください。

複数のURLパラメータの一致

複数のURLパラメータを一致する場合、1つのセットの大カッコ内に定義することを強くお薦めします。たとえば、%[!parm1!parm2]などです。%[!parm1]%[!parm2]を指定できますが、定義される同じ順序で表示される場合に指定した引数のみ一致するので注意してください。文字列/example/path/file.htmlを考えてみます。使用可能な一致スキームを表8-5に示します。

表8-5 複数のURLパラメータの一致

定義

一致した結果

%[f]

%1 = /example/path/file
%2 = .html

%[d]%[f]%

%1 = /example/path/
%2 = file
%3 = .html

例

検索値: %[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

8.3.6 未分類のページのレポート作成

ページのうち、そのURL定義によりアプリケーションに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません(デフォルト)。ただし、そのような未分類のページをデータ・ブラウザ・グループでレポートする場合は、図8-18に示す「アプリケーション概要」内の「ページ」セクションにある「未分類のページのレポート」チェック・ボックスを使用します。

図8-18 アプリケーション・ページの「構成」セクション

ページの識別は、時間ベースのアクティビティであるため、オブジェクトとして予約されていないオブジェクトへの参照は、未分類のページであるとして、誤って識別される場合があります。このため、未分類のページのレポート作成は、テスト目的でのみ有効にすることをお薦めします。その後、これを再度無効にし、識別された問題のあるページを手動で定義できます。未分類のページは、対応するデータ・ブラウザ・グループ内のカテゴリ「その他」にレポートされることに注意してください。

8.3.7 サービス・テスト・ビーコン・トラフィックのレポート

監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。この詳細は、9.8項「サービス・テスト・セッションのユーザー・フローへの変換」に記載されています。

「拡張」セクションの「サービス・テスト・トラフィックのレポート」チェック・ボックスを使用して、選択したアプリケーションのためにOracle Enterprise Managerで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。デフォルトでは、レポートは行われません。この機能の使用方法の詳細は、8.6項「サービス・テスト・トラフィックのレポート」に記載されています。

有効にすると、サービス・テスト・グループは、監視されるサービス・テスト・ビーコン・トラフィックの情報を提供します。構造の詳細は、表V-1に記載されています。

8.3.8 クライアントIPアドレスの取得

ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。ただし、RUEIシステムをNATサービスの前に配置する場合には、特定のHTTPリクエスト・ヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。この詳細は、付録Q「NATトラフィックの監視」に記載されています。

8.3.9 ページ・ネーミングの自動割当て

前述のように、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というページ名が割り当てられます。

8.3.10 アプリケーション定義の微調整

アプリケーションの定義後に、アプリケーションに関連するページ・ネーミング・スキームを変更するには、この項で前述したように、アプリケーションをクリックして新規スキームを選択します。

「識別」セクションで、「新規フィルタの追加」をクリックして、アプリケーションと関連付ける必要のあるページの追加フィルタを指定します。また、既存のフィルタ定義を変更するには、それをクリックします。いずれの場合にも、図8-2に示したフィルタの中から選択できます。ユーザーによる追加または変更を反映するようにアプリケーション概要が更新されます。

8.3.11 ページ・ロードの満足度の指定

セッションでアプリケーション・ページを表示している際のユーザー・エクスペリエンスを評価するために、RUEIではページごとに満足度レベルが割り当てられます。これを表8-6に示します。

表8-6 ページ・ロード満足度のレベル

レベル

説明

良好

ページは、満足のページ・ロードしきい値の期間内でユーザー・ブラウザにロードされます。デフォルトでは、これは4秒です。

OK

ページは、OKのしきい値の期間内でユーザー・ブラウザにロードされます。デフォルトでは、これは16秒です。

劣悪

ページのロードは、劣悪のしきい値より長くかかります。

ページ・ロード満足度のレポートの例を図8-19に示します。

図8-19 ページ・ロード満足度レポート

前述のように、この評価は、ページのロードの完了までに通常想定されるしきい値に基づきます。このしきい値を変更して、レポートされるページ・ロード満足度を調整することができます。次を実行します。

1. 目的のアプリケーションを選択し、「ページ」セクションをクリックし、「デフォルト」設定をクリックします。図8-20に示すダイアログが表示されます。

図8-20 「ページ・ロードの満足度しきい値の編集」ダイアログ

2. 「デフォルト」項目をクリックします。図8-21に示すダイアログが表示されます。

図8-21 「デフォルトのページ・ロードの満足度しきい値の編集」ダイアログ

3. ページ・ロードの満足度を評価するときに使用するしきい値を指定します(秒単位)。これらのしきい値は表8-3で説明しています。デフォルトは4から16秒です。定義するしきい値は0.001から86400(つまり1日)の範囲です。次に、「保存」をクリックします。図8-20に示したダイアログに戻ります。

4. オプションで、「例外の追加」をクリックし、ユーザー・エクスペリエンスの評価に別の(デフォルトとは異なる)ページ・ロードのしきい値を使用する状況を指定します。この機能は、特定のユーザー・アクションを実行するとき他のアプリケーション・アクションよりかなり長く時間がかると想定される場合に特に便利です。たとえば、ダウンロードや複雑なデータベース問合せなどの場合です。図8-22に示すダイアログが表示されます。

図8-22 「満足度例外の追加」ダイアログ

5. 定義された例外においてページおよびユーザー・アクションの評価に使用されるページ・ロードしきい値を指定します。

6. 例外が到達されたとみなされるために満たされる必要があるイベントを指定します。例外が発生するには、定義するイベントがすべて満たされる必要があります。イベントごとに、「ディメンション・レベル」および「値」メニューを使用して、チェックされるディメンションと保持する必要がある値を選択します。目的の値が「値」メニューにない場合は、横にある「検索」アイコンをクリックして探すことができます。
必要に応じて、「除外」チェック・ボックスを使用すると、定義したディメンション・レベル=値ペアを除外するように適用できます。つまり、定義したイベントが満たされない場合に、イベントが達成されたとみなされます。次に、「追加」をクリックします。新しいイベントが例外の定義に追加されます。1つの例外に定義できるイベントは最大10件までです。次に、「保存」をクリックします。図8-20に示したダイアログに戻ります。

7. 例外は、上から下の順で解決されることに注意してください。必要な場合は、例外のコンテキスト・メニューで「上に移動」と「下に移動」のオプションを使用して、例外の位置を移動できます。定義できる例外の最大数は100です。

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

ページとオブジェクト・ロードの満足度のレポート方法の理解

ページ・ロード満足度はユーザーのブラウザでページのロードに要する時間に基づいていますが、オブジェクト・ロード満足度はオブジェクトのエンドツーエンド時間の合計に基づいています。オブジェクト・ロード満足度では、デフォルトのアプリケーション・ページ・ロードしきい値を使用し、定義されている例外は無視します。

3.2.2項「問題分析グループ」で説明するように、2秒未満のエンドツーエンド時間のオブジェクトは遅いURLとみなされません。2秒を超える場合、URLロード満足度はデフォルトのアプリケーション・ページ・ロードしきい値に基づき、定義されている例外は無視します。

8.3.12 ログアウト・イベントの定義

RUEIでは、ユーザーがアプリケーションからログアウトしても、自動的にセッションの終了とはみなされません。かわりに、セッションのアイドル・タイムアウト(デフォルトでは60分)に達すると、ユーザー・セッションの終了と判断されます。これは、ユーザーがログアウトした際に、アプリケーションによりユーザーのセッションが終了されず、ユーザーがそのアプリケーションに再度ログインした場合、RUEIでは、アプリケーションのログアウトが検出されず、2つのアプリケーション・セッションが同じユーザー・セッションの一部としてレポートされることを意味します。

これがレポート要件として適切でない場合は、そのページに到達すると、自動的に現在のユーザー・セッションの終了とみなされるアプリケーション・イベントを定義できます。通常、これはログアウト・ページおよびイベントになります。後続のユーザー・アクションは、新しいユーザー・セッションの一部とみなされてレポートされます。

アプリケーション・ログアウト・イベントの定義

次を実行します。

1. 「構成」、「アプリケーション」、「アプリケーション」または「スイート」の順に選択し、必要なアプリケーションを選択します。(図8-5に示したような)「アプリケーション概要」が表示されます。

2. 「ページ」タブ→「ログアウト・イベント」タブの順にクリックします。現時点で定義されているログアウト・イベントがリストされます。「新規イベントの追加」をクリックします。または、既存の定義をクリックしてそれを編集します。図8-23に示すダイアログが表示されます。

図8-23 「アプリケーション・ログアウト・イベントを指定します」ダイアログ

3. 必要なイベント条件ごとにディメンション・レベル=値ペアを指定します。必要に応じて、「除外」チェック・ボックスを使用すると、定義したペアを除外するように適用できます。つまり、定義した条件が満たされない場合に、イベントが達成されたとみなされます。次に、「追加」をクリックします。定義したイベントが1つでも取得されればセッションは終了したとみなされますが、達成したとみなされるには、イベント内のすべての条件が満たされる必要があります。次に、「保存」をクリックします。

8.3.13 アプリケーション・コンテンツ・メッセージのトラップ

ページ内に表示される文字列を検出し、アプリケーション通知("注文が正常に処理されました"など)またはアプリケーション・エラー("サーバーへのネットワーク接続に失敗しました"など)のいずれかとしてレポートする必要が生じる場合があります。

コンテンツ・メッセージのチェックと、システム・エラーおよびページ・コンテンツのチェック

コンテンツ・メッセージは、リターン・コードではなくページ・コンテンツに基づき、選択したアプリケーションに固有であるため、システム・エラー(Webサーバー・エラーまたはネットワーク・エラー)とは異なります。

指定したメッセージ文字列は、選択したアプリケーション内のすべてのページを対象として検索されることに注意してください。ページ・コンテンツ・チェックが行われるため、特定のページのみを検索することはできません(8.3.19項「ページ・コンテンツ・チェックの指定」を参照)。

アプリケーション・コンテンツ・メッセージおよびページ・コンテンツ・メッセージはページベースです。サービスの場合、それらはコール(つまりヒット)固有です。したがって、ページベースのグループのみでレポートされ、(URLベースの)診断グループではレポートされません。

コンテンツ・メッセージのレポート

個々のコンテンツ・メッセージは、通知またはエラーとして指定できます。いずれの場合も、ページ配信ディメンションでレポートされます。

指定した通知文字列と一致するものとして表示されるページ・テキストは、ページ・コンテンツの結果である「通知文字列: 通知検索文字列」とともにレポートされ、エラーの場合は「エラー文字列: エラー検索文字列」としてレポートされます。コンテンツ・エラーのレポートの例を図8-24に示します。

図8-24 関数エラーの分析

コンテンツ・メッセージの定義

コンテンツ・メッセージの文字列を定義する手順は、次のとおりです。

1. 「構成」を選択し、「アプリケーション」、「スイート」または「サービス」を選択して、目的のアプリケーションを選択します。(図8-5に示すような)「アプリケーション概要」が表示されます。

2. 「コンテンツ・メッセージ」タブ→「コンテンツ・メッセージ」の順にクリックします。現在定義されているコンテンツ・メッセージが表示されます。「新規コンテンツ・メッセージの追加」をクリックして新しいメッセージを定義するか、または既存のものをクリックして変更します。図8-25に示すダイアログが表示されます。

図8-25 コンテンツ・メッセージの追加

3. 「検索タイプ」メニューを使用して、検索範囲を指定します。検索の場所として、リクエスト・ヘッダー、応答ヘッダー、リクエスト・コンテンツ、応答コンテンツまたはURLを指定できます。検索タイプは、XPathまたはリテラルです。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。
リクエスト・ヘッダーまたはレスポンス・ヘッダーを指定する場合、検索するヘッダーを指定できます。このフィールドを空白のままにすると、完全なヘッダー・コンテンツが自動的に入力されます。

URLを指定する場合、URL部分に追加的にレポートされるURL引数を指定できます。

ワイルドカードの使用はサポートされておらず、指定するすべての文字がリテラルとして扱われます。

次に、「保存」をクリックします。変更は5分以内に有効になります。XPathベースまたはヘッダーのコンテンツ・メッセージを作成すると、規則指定機能を使用してメッセージの仕様を微調整できます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。

コンテンツ・メッセージのリストのインポート

監視対象とする各メッセージを個別に定義するかわりに、事前定義済アプリケーション・メッセージのリストを含むファイルをインポートできます。次を実行します。

1. 目的のアプリケーションまたはスイートを選択したら、「メッセージ指定」タブをクリックします。「アップロード・リスト」をクリックします。図8-26に示すダイアログが表示されます。

図8-26 「コンテンツ・メッセージのアップロード」ダイアログ

2. 「参照」ボタンを使用し、目的のファイルを検索して選択します。必要に応じて、「ファイル・エンコーディング」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。
アップロードされるファイルでは、1行に1つのメッセージを含める必要があり、空白の行を含めることはできません。これらのメッセージが、レスポンス内容で検索されるリテラル文字列になります。次に、「マージ」をクリックします。

8.3.13.1 コンテンツ・メッセージの説明の定義

必要に応じて、一意のメッセージ文字列それぞれに対して一連の説明を定義することもできます。たとえば、Oracle Databaseメッセージの説明を表8-7のように定義できます。

表8-7 メッセージ文字列の説明の例

文字列

説明

ORA-00056

DDLロックの取得が試行されましたが、すでにロックされています。

ORA-00057

一時表の数が一時表ロックの数以上です。

ORA-00058

マウントされているデータベースのDB_BLOCK_SIZE初期化パラメータが違います。

ORA-00059

DB_FILES初期化パラメータの値が超過されました。

ORA-00060

ユーザー・フローがリソースの待機中に互いにデッドロックしました。

ORA-00061

起動中の共有インスタンスがDMLロックを使用しており、実行中のインスタンスがDMLロックを使用していません(あるいは、その逆の状態)。

ORA-00062

インスタンスがDML_LOCKS = 0で起動されたが、実行中の文では全表ロック(S、XまたはSSX)が必要です。

ORA-00063

指定されたログ・ファイルの数が、このリリースでサポートされているログ・ファイルの最大数を超えました。

メッセージの説明を定義する手順は、次のとおりです。

1. 適切なアプリケーションまたはスイートを選択したら、「コンテンツ・メッセージ」タブ→「メッセージ指定」タブの順にクリックします。現在定義されているメッセージの説明が表示されます。「新規指定の追加」をクリックして新しい説明を定義するか、または既存のものをクリックして変更します。図8-27に示すダイアログが表示されます。

図8-27 「メッセージ指定の追加」ダイアログ

2. 必要なソース値と、必要に応じて説明を指定します。次に、「保存」をクリックします。

3. 「メッセージ・タイプ」メニューを使用して、メッセージをエラー(デフォルト)または通知のいずれとしてレポートするかを指定します。次に、「保存」をクリックします。

前述の例では、これは次のようにレポートされます。

error code ORA-00056: An attempt was made to acquire a DDL lock that is already locked.

非常に多くの説明がある場合は、「検索」フィールドを使用すると目的の説明をすぐに見つけることができることに注意してください。検索機能では部分一致が使用されます。ワイルドカードの使用はサポートされておらず、すべての文字がリテラルとして扱われます。次に、「実行」をクリックします。

説明のリストのインポート

各説明を個別に定義するかわりに、説明のリストを含むファイルをインポートできます。次を実行します。

1. 「アップロード・リスト」をクリックします。図8-28に示すダイアログが表示されます。

図8-28 メッセージ仕様のアップロード・ダイアログ

2. 「参照」ボタンを使用して、翻訳ファイルの名前を検索および指定します。メッセージ定義が重複している場合は、最新の定義が使用されます。必要に応じて、「ファイル・エンコーディング」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。ファイルには、ソース値とその説明をタブで区切って、1行に1つの説明のみを含めることができます。

3. 「メッセージ・タイプ」メニューを使用して、ファイルに定義されたメッセージをエラー(デフォルト)または通知のいずれとしてレポートするかを指定します。次に、「マージ」をクリックします。

8.3.13.2 エラーへのコンテンツ・メッセージの追加

コンテンツに関連のないエラー(つまり、Webサイト、ネットワークまたはサーバーのエラー)と一緒にコンテンツ・メッセージがレポートされると非常に便利です。トラブルシューティングを促進するためにエラーのコンテキストに関する追加情報の提供が可能になります。ただし、これはレポートのデフォルトの動作ではありません。

3.2.3項「ページ配信ディメンション」に記載されているように、1ページで数種類のエラー(たとえばサーバー・エラーとネットワーク・エラー)が発生しても、ページ・エラーは複数回レポートされません。かわりに、エラーは特定の順序(Webサイト、サーバー、ネットワーク、コンテンツの順)でレポートされます。

コンテンツに関連のないエラーが追加情報と一緒にレポートされるように指定する手順は、次のとおりです。

1. 「構成」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「アプリケーション概要」が表示されます。「コンテンツ・メッセージ」タブ→「拡張」タブの順にクリックします。図8-29に示す画面が表示されます。

図8-29 コンテンツ・メッセージの「拡張」タブ

2. ページ上に定義済コンテンツ・メッセージが見つかった場合はレポート時にエラーに追加するよう指定するには、「コンテンツ・メッセージの追加」チェック・ボックスを選択します。デフォルトでは、コンテンツ・メッセージは追加されません。同じページ内に複数のコンテンツ・メッセージが見つかった場合は、ページ上で最初に見つかったメッセージがレポートで使用されることに注意してください。

拡張ページ配信の詳細の例を図8-30に示します。

図8-30 追加のページ配信詳細の例

8.3.14 ユーザーIDの定義

RUEIでは、新たに作成されるアプリケーションは、ユーザー識別がHTTP認可フィールドとSSLクライアント証明書の共通名(CN)部分(使用可能な場合)に基づくように自動的に構成されます。図8-31にこれを示します。

図8-31 アプリケーションのユーザー識別スキーム

ただし、URL、Cookie、リクエスト・ヘッダー、レスポンス・ヘッダー、XPath式、カスタム・タグまたはレスポンス、OAMユーザー・トラッキング(11.1項「OAMベース・トラフィックの監視」を参照)に関して、アプリケーションのユーザー識別スキームを構成することもできます。HTTP認可フィールドは構成される他の値よりも優先されること、SSL証明書は代替スキームであることに注意してください。構成されたユーザーIDが監視対象トラフィックで検出されたものと一致しない場合、そのユーザーIDは"(値なし)"としてレポートされます。RUEIにおける値なしアイテムのレポートの詳細は、付録Eを参照してください。

アプリケーションのユーザー識別スキームの構成

アプリケーションのユーザー識別スキームを構成する手順は、次のとおりです。

1. 目的のアプリケーションを選択し、「ユーザー」セクションをクリックします。

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

図8-32 新しいユーザーIDソースの追加ダイアログ

3. 「ソース・タイプ」および「ソース値」フィールドを使用して、ユーザー識別メカニズムを指定します。これは、リテラル検索文字列またはXPath式を使用して指定できます。次の点に注意してください。

- リテラル検索文字列の場合、リクエスト・ヘッダーまたはレスポンス・ヘッダーを検索するかどうかを指定できます。

- XPath式の場合、リクエストまたはレスポンスを検索するかどうかを指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。

- Cookieの場合は、Cookieの名前を指定する必要があります。選択したCookieに対して、またはデフォルトのCookieマスキング・アクションとしてハッシングが指定されている場合、Cookieの一意性は保たれますが、元の値は保存されません。この詳細は、13.6項「ユーザー情報のマスキング」に記載されています。

- URL引数の場合は、引数の名前を指定する必要があります。

- OAMベース・トラフィックの場合は、詳細について11.1項「OAMベース・トラフィックの監視」を参照してください。

- カスタム・パターンの場合は、開始文字列と終了文字列(オプション)を指定して、検索対象のコンテンツの範囲を決める必要があります。ワイルドカード文字の使用はサポートされておらず、指定するすべての文字がリテラルとして扱われることに注意してください。また、終了文字列を指定すると、検索は次の行以降では行われません。

- カスタム・タグの場合は、ユーザーIDが取得されるname=valueペアに名前を指定する必要があります。

- 前述のように、HTTPベースの認証が指定されている場合は、他に識別スキームが定義されても優先されます。また、SSLクライアント証明書が指定されている場合、これは代替スキームになります。

4. 「詳細」タブをクリックします。「小文字変換」メニューを使用して、ユーザー名を小文字に変換するかどうかを指定し、変換する場合にはユーザー識別定義の作成後に定義できる一致ルールの適用前か適用後かも指定します。
次に、「保存」をクリックします。ユーザー識別スキームを定義すると、ルーリング機能を使用して実装を絞り込むことができます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。

注意:
ユーザー識別を定義した結果は、ユーザー情報(XLS形式)レポートの「クライアント」カテゴリで確認できます。レポートの詳細は、第2章「レポートの操作」を参照してください。

各国語サポート

各国語のキャラクタ・セットを使用する際に識別が持つ意味の詳細は、付録G「各国語サポートの使用」を参照してください。

8.3.15 ローカライゼーション・ソースの定義

デフォルトで新規作成されたアプリケーションおよびサービスでは、ローカライゼーション・ソースが構成されません。ただし、URL、Cookie、リクエストあるいはレスポンス・ヘッダー、XPath式、またはカスタム・タグあるいはレスポンスに関して、アプリケーションのローカライゼーション(テリトリおよび言語)ソースを構成できます。

アプリケーションのローカライゼーション・ソースの構成

アプリケーションのローカライゼーション・ソースを構成するには、次の手順を実行します。

1. 必要なアプリケーションを選択し、「拡張」セクションをクリックします。

2. 「ローカライゼーション」セクションをクリックします。

3. 「アプリケーション・テリトリ」または「アプリケーション言語」セクションを選択します。

図8-33 ローカライゼーションの構成

4. 「新規ソースの追加」をクリックします。

5. 「ソース・タイプ」および「ソース値」のフィールドを使用して、ローカライゼーション識別メカニズムを指定します。次の点に注意してください。

- リテラル検索文字列の場合、リクエスト・ヘッダーまたはレスポンス・ヘッダーを検索するかどうかを指定できます。

- XPath式の場合、リクエストまたはレスポンスを検索するかどうかを指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。

- Cookieの場合は、Cookieの名前を指定する必要があります。選択したCookieに対して、またはデフォルトのCookieマスキング・アクションとしてハッシングが指定されている場合、Cookieの一意性は保たれますが、元の値は保存されません。この詳細は、13.6項「ユーザー情報のマスキング」に記載されています。

- URL引数の場合は、引数の名前を指定する必要があります。

- カスタム・パターンの場合は、開始文字列と終了文字列(オプション)を指定して、検索対象のコンテンツの範囲を決める必要があります。ワイルドカード文字の使用はサポートされておらず、指定するすべての文字がリテラルとして扱われることに注意してください。

- 行文字列の終わりを指定しないかぎり、検索は新規行を超えて拡張しません。

- カスタム・タグの場合は、ユーザーIDが取得される名前=値ペアに名前を指定する必要があります。

6. 「詳細」タブをクリックします。「小文字変換」メニューを使用して、値を小文字に変換するかどうかを指定し、変換する場合は、ローカライゼーション・ソースの作成後に定義できる一致ルールの適用前か適用後かも指定します。次に、「保存」をクリックします。ローカライゼーション・ソースを定義すると、ルーリング機能を使用して実装を絞り込むことができます。この詳細は、8.3.5項「規則指定機能の使用」に記載されています。

8.3.16 アプリケーション・ページ構造の表示

アプリケーションで検出されたページの構造は、ウィンドウの左側にあるアプリケーション概要に表示されます。例を図8-34に示します。

図8-34 アプリケーション・ページ構造の例

アプリケーションには、非常に多くのページが関連付けられている可能性があります。実際、図8-34に示す構造では、簡単には確認できないほど多くのページが関連付けられています。このため、この構造のビューは、Point of Interest(POI)を持つページに制限されています。したがって、レポートに含まれているページ、キー・ページとして定義されているページ、手動で名前が設定されたページ、監視対象KPIの一部であるページなどが表示されます。図8-35に示す表示メニューでは、構造概要に表示するページのタイプを制御できます。

図8-35 「ビュー」メニュー

表8-8に示すオプションがあります。

表8-8 「ビュー」メニューのオプション

オプション

説明

すべて

すべてのアプリケーション・ページをリストします。

レポート・ページ

レポート・フィルタとして指定されているページのみをリストします(2.7項「レポート・フィルタの使用方法」を参照)。

チェックしたページ

コンテンツ・チェックが定義されているページのみをリストします(8.3.19項「ページ・コンテンツ・チェックの指定」を参照)。

手動で名付けられたページ

手動で定義されているページのみをリストします(8.3.20項「ページの手動識別」を参照)。

キー・ページ

キー・ページとして定義されているページのみをリストします(8.3.18項「ページの使用状況の追跡」を参照)。

8.3.17 ページ詳細の検索

アプリケーション・ページ・カテゴリをドリルダウンすると、特定のページに移動できます。ただし、多数のページを含むアプリケーションの使用時は、ページ検索機能を使用した方が便利な場合があります。次を実行します。

1. 検索するアプリケーションを選択します。「ページ」セクションを選択し、「識別されたページ」タブをクリックします。

2. 目的のページの検索に使用する検索プロファイルを指定します。検索は現在のアプリケーションに制限され、ページ名は、アプリケーション » グループ » 名前という構造になることに注意してください。検索機能では、完全一致または部分文字列として指定した検索パターンとの一致が行われます。このため、検索パターンhomeは、アプリケーション、グループまたはページの名前におけるこの文字列または部分文字列の出現に一致します。次に、「実行」をクリックします。結果リストを図8-36に示します。

図8-36 「ページの検索と結果」

3. 検索結果がダイアログの下半分に表示されます。一致したページをクリックして開きます。右および左矢印ボタンを使用し、結果の複数のページ間を移動します。また、表示メニュー(8.3.16項「アプリケーション・ページ構造の表示」を参照)を使用すると、特定の基準(レポートで使用されるページなど)に合うように表示リストを制限できます。

注意:
検索範囲には、検出済のページと、レポートおよびユーザー・フローに存在する未検出ページの両方が含まれます。

4. 識別されたページをすべて削除する場合は、ウィンドウの一番下にある「すべての識別されたページのパージ」を選択します。これにより、「識別されたページ」カウンタがリセットされ、結果リストがクリアされます。

8.3.18 ページの使用状況の追跡

アプリケーションで検出された各ページに関する情報は、ページ分析ウィンドウで確認できます。例を図8-37に示します。

図8-37 ページ分析ウィンドウ

このウィンドウには次のタブがあります。

- 識別: ページ識別スキーム(手動または自動)と、識別に使用する条件を指定します。

- コンテンツ・チェック: コンテンツ検索文字列がページに定義されているかどうかを指定します。この詳細は、8.3.19項「ページ・コンテンツ・チェックの指定」に記載されています。

- レポート: このページを含むレポートをリストします。レポートの詳細は、第2章「レポートの操作」に記載されています。

- 監視: このページを含むKPIをリストします。KPIの定義手順に関する詳細を参照してください。

8.3.18.1 キー・ページの定義

図8-37の「キー・ページ」チェック・ボックスを使用して、ページをキー・ページとして定義します。

キー・ページは、監視対象のうち、特に注目するWebページです。通常、これは特に重要なページです。たとえば、組織のホームページや、注文入力などのユーザー・フロー内の一連のページなどがあります。これらのページに関しては、追加情報が記録されます。追加情報には、クライアント情報(ISP、アクセス元の国など)やクライアントのブラウザ情報(オペレーティング・システム、ブラウザ・バージョンなど)があります。

8.3.19 ページ・コンテンツ・チェックの指定

特定のページに特定のテキスト文字列が出現するかどうかの監視が必要となる場合があります。たとえば、Webアプリケーションに注文ページがあり、販売に成功した後、"ご購入ありがとうございました"というテキスト文字列がこのページに表示されるとします。目的のページにこの文字列があるかどうかを検索するページ・コンテンツ・チェックを定義できます。指定したテキスト文字列がそのページで見つからない場合、ページ・ビューは失敗したページとしてレポートされることに注意してください。

ページ・コンテンツ・チェックのレポート

成功したページとしてレポートされるためには、ページに対して指定したすべての文字列がページ・ビュー内で見つかる必要があることに注意してください。それ以外は失敗したページ・ビューとしてレポートされます。また、コンテンツ・メッセージ(8.3.13項「アプリケーション・コンテンツ・メッセージのトラップ」を参照)の一致はページ・コンテンツ・チェックの前に行われます。したがって、ページ・コンテンツ・チェックでは失敗したページとしてレポートするように示しても、ページ・ビューは通知(つまり、成功)としてレポートされることがあります。

ページ・コンテンツ・チェックの定義

ページ・コンテンツ・チェックを定義する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「アプリケーション」の順に選択して、目的のアプリケーション・ページを選択します。ページ分析ウィンドウ(図8-37を参照)が表示されます。

2. 「コンテンツ・チェック」タブ→「チェックの追加」の順にクリックします。図8-38に示すダイアログが表示されます。

図8-38 ページ・コンテンツ・チェックの追加

3. 検索時に、リテラル検索文字列またはXPath式のいずれを使用するか、およびサーバーのレスポンスまたはクライアントのリクエストのどちらを検索するかを指定します。XPath式の場合は、クライアントまたはサーバーのレスポンス・コンテンツで検索する詳細な値も指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。次に、「保存」をクリックします。

8.3.20 ページの手動識別

アプリケーション全体のページを識別できるのみでなく、ページを手動で定義することもできます。手動で識別されたページは、アプリケーションによって自動的に識別されたページより優先されることに注意してください。この機能は、自動的には識別できないサブページに、別の名前を割り当てる場合に便利です。手動で識別されるページは、新規ページのベースとなる既存のページを選択して作成します。

ページが手動で識別されるようにするには、新規のページを最初から定義するか、既存のページ(自動で検出または手動で定義されたページ)を新規ページのベースとして使用します。

ページを定義する手順は、次のとおりです。

1. ページを最初から定義するには、目的のアプリケーションを選択し、「新規ページ」ボタンをクリックします。既存のページを新規ページのベースとして使用するには、目的のアプリケーション・ページを選択し、「新規ページ(現在のページに基づく)」ボタンをクリックします。いずれの場合も、図8-39に示すダイアログが表示されます。

図8-39 手動によるページ・ネーミング・ウィザード

注意:
目的のページがアプリケーション概要に表示されず、選択できない場合は、「検索」ボタンを使用して検索します(8.3.17項「ページ詳細の検索」を参照)。

2. このダイアログを使用して、割り当てた名前がページに設定されるための条件を指定します。この条件は、ページURLの一部または詳細、コンテンツ、ドメインまたは引数を使用して定義できます。XPath式も指定できます。「条件の追加」をクリックして必要な各条件を追加します。
詳細なURL(たとえばhttp://www.oracle.com/contact.htmlなど)を指定する場合、ドメインとそれ以外のURL構文はページ条件に自動的に割り当てられます。たとえば、ドメイン内の検索オプション(oracle.com)や「正確なURLの検索」(/contact.html)のようになります。

3. 追加条件を指定すると、それらがダイアログに表示されます。一致を行うときは、指定したすべての条件が満たされる必要があります。青字で表示される条件はクリックすると削除できますが、黒字で表示される条件は削除できないことに注意してください。ページを識別するには、1つ以上の条件を指定する必要があります。次に、「次へ」をクリックします。図8-40に示すダイアログが表示されます。

図8-40 「別名保存」ダイアログ

4. このダイアログを使用して、ページのグループおよび名前を指定します。次に、「終了」をクリックします。

5. 新規ページの詳細が、図8-34に示すようなウィンドウに表示されます。このウィンドウを使用すると、ページ検出を追跡し、その定義を変更できます。

8.3.21問題分析グループ内のレポートの制御

URL診断グループ(3.2.4項「問題分析のためのURL診断」を参照)を使用すると、アプリケーションのヒットについてレポートされた機能URLを表示できます。これらは、特定の要件に合せてアプリケーション・レベルでカスタマイズできます。

URL診断を使用すると、アプリケーションの問題の把握に役立ちます。たとえば、特定のアプリケーションでロード時間が異常に長くかかる場合に、問題がある特定のオブジェクトまたは原因となっているサーバーをすぐに識別できます。さらに、この機能をセッション診断機能(4.1項「概要」を参照)と組み合せると、アプリケーションの問題について非常に高性能の根本原因分析を行うことができます。

選択したアプリケーションで使用するURL診断レポート・スキームを指定する手順は、次のとおりです。

1. 「構成」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「アプリケーション概要」が表示されます。「拡張」セクションをクリックし、「URL診断」タブをクリックします。監視対象のURL範囲を指定するために使用される、現時点で定義済のURLパターンが表示されます。「新規URLパターンの追加」をクリックして新しいパターン一致スキームを定義するか、既存のパターン一致スキームをクリックして変更します。図8-41に示すようなダイアログが表示されます。

図8-41 URL診断の編集ダイアログ

2. 「URL一致タイプ」メニューを使用して、これから定義するスキームをすべてのアプリケーションのURLに適用するか、特定のURLのみに適用するかを指定します。後者の場合は、URL構文を指定する必要があります。この構文が「URL診断」グループ内でアプリケーションについてレポートされます。定義するURLパターンが検出されたURLと一致したときにレポートされます。ワイルドカード文字(*)の使用はサポートされますが、指定する他の文字はすべてリテラルとして解釈されます。URL構文を定義しないと、アプリケーションの関連するヒットが「URL診断」グループでレポートされないことに注意してください。

3. 検出されるURL構文の一部(要素)をレポートするように指定することもできます。または、レポートされるURLを特定の引数に限定することもできます。いずれの場合も、「URL引数/コンポーネントの追加」をクリックします。図8-42に示すようなダイアログが表示されます。

4. 図8-42URL引数/コンポーネントの追加

5. 「スキーム・タイプ」メニューを使用して、一致するURLをレポートするときに、特定のパラメータまたは要素に限定するかどうかを指定します。パラメータの場合は、レポートされるパラメータ名を指定する必要があります。要素の場合は、一致したURLから分離する要素を指定し、「パート」メニューを使用してレポートする必要がある部分を指定します。使用可能なオプションの数は、「URLコンポーネント」フィールドに指定されるワイルドカード(*)の数と同じです。
たとえば、図8-43に示す要素の定義について考えます。

図8-43 URL診断の要素定義の例

この場合は、*/MyShop/catalog/よりも後の部分のみがレポートされます。部分のパラメータは、「値」定義に指定されたワイルドカードと照合されることに注意してください。たとえば、指定された値*/session=*/*には3つのワイルドカードが含まれるため、一致するURLは3つの論理部分を含むとみなされます。URL診断の定義には最大で9個のワイルドカードを指定できます。

次に、「保存」をクリックします。図8-41に示したダイアログに戻ります。

6. アプリケーションのパラメータと要素の定義を確認します。次に、「保存」をクリックします。5分後から一致するURLパターンが「URL診断」グループでレポートされます。

除外するURLの情報

強制オブジェクト(12.16項「ページとしてのオブジェクトのレポートの制御」を参照)は、レポートされたURLから自動的に除去されます。この他に、セッション・パラメータおよび静的オブジェクト(イメージなど)のレポートを除外するように、アプリケーション定義を構成することをお薦めします。こうすることで、診断情報が長くなりすぎて切り捨てられることを防ぎます。

8.3.22 JavaScript再生実行の制御

セッション診断の再生機能で表示されるアプリケーション・ページは、インラインJavaScriptコードを含む可能性があります。通常、このコードはチェックを実行するために使用されます。たとえば、指定されたサーバーに接続して、セッションが期限切れになったかどうかを判別します。このようなチェックおよびJavaScriptの他の機能は、関連するページを再生機能で表示するときに問題になることがあります。

この理由のために、アプリケーション構成機能を使用して、インラインJavaScriptコードの実行をReplay Viewerでどのように扱うかを指定できます(4.1項「概要」を参照)。JavaScriptの実行を完全に無効にするか、特定の関数またはファイルをページの再生時に置き換えるように指定できます。

実行規則の定義

アプリケーション・ページの再生時に使用されるJavaScriptの実行規則を定義する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「アプリケーション概要」が表示されます。「拡張」セクションをクリックし、次に「JavaScriptリプレイ」タブをクリックします。現時点で定義されている実行規則が表示されます。図8-44に示すようなダイアログが表示されます。

図8-44 JavaScript再生規則

2. 「すべてのJavaScript実行の無効化」チェック・ボックスを使用して、選択したアプリケーションのページが再生機能で再生されるときに、ページ内のすべてのJavaScriptコードを無効にするように指定します。このチェック・ボックスを選択すると、既存の実行規則は無視されます。新しい規則を定義することもできません。デフォルトでは、このチェック・ボックスが選択されています。

3. 「新規ルールの追加」をクリックして新しい規則を定義するか、既存の規則をクリックして変更します。この機能が使用できるのは、「すべてのJavaScript実行の無効化」チェック・ボックスを選択していない場合のみであることに注意してください。図8-45に示すようなダイアログが表示されます。

図8-45 「新規ルールの追加」ダイアログ

4. 「ルール・タイプ」メニューを使用して、定義する実行規則のタイプを指定します。次のオプションから選択してください。

- 関数の置換: 実行時に、指定したJavaScriptの関数を削除し、オプションとしてリターン・コードで置き換えるように指定します。たとえば、Cookieがまだ有効かどうかを調べる関数を、再生時にOKという戻り値で置き換えることができます。
指定される関数の定義は、ページのインライン・コードに含まれる必要があります。外部関数を置き換えることはできません。JavaScriptコードが置き換えられるのは、レンダリングされるブラウザ・ページのみです。再生されるページのコンテンツでは置き換えられません(「HTTPコンテンツ」機能でレポートされます)。

関数の定義でfunction構文と関数名の間にコメントが含まれる場合は、置換が失敗することに注意してください。たとえば、次の構文では失敗します。

function
/* some comment */
myfunction ( url ) {
.....}

アプリケーション・ページに外部関数への参照が含まれる場合は、変更した関数定義を含むファイルをアップロードして置き換えることができます。これは次に説明します。

- ファイルの置換: JavaScriptコードを含む指定のファイルを別のファイルで置き換えるように指定します。たとえば、検証ルーチンを含むファイルを、再生用に簡単な内容に置き換えることができます。このオプションを選択した場合は、置き換えるファイルの名前と拡張子を「ソース名」フィールドに指定する必要があります。これらは、対応するscript要素に指定するものと同じであることが必要です。たとえば、次のファイル参照があるとします。

<script type="text/javascript" src="public/scripts/checks.js"></script>

ここでは、ファイル名checks.jsを指定する必要があります。

置換ファイル・フィールドを使用して、代替ファイルを指定します。このファイルの拡張子は.jsで、MIMEタイプはtextであることが必要です。このファイルはレポータ・システムの/opt/ruei/gui/upload/ディレクトリにアップロードされます。

次に、「保存」をクリックします。定義済のアプリケーション再生規則に行った変更は、すぐに適用されます。

置換ファイルのアップロード

置換のための.jsファイルは、レポータ・システムの/opt/ruei/gui/uploadディレクトリにアップロードされます。必要であれば、適切な規則を選択して、元のファイルを変更したものをアップロードするかまったく新しいファイルを指定することで、置換ファイルの内容を変更できることに注意してください。どちらの場合も、元のファイルの内容は新たにアップロードされるファイルで上書きされます。規則が削除されると、その規則についてアップロードされたファイルも自動的に削除されます。

アプリケーションに複数の規則が含まれ、それらが同じファイルを参照する場合、1つのバージョンのファイルのみがレポータ・ファイル・システムに保持され、そのファイルが常に最新バージョンとしてアップロードされることに注意してください。そのファイルがファイル・システムから削除されるのは、そのファイルを使用するすべての規則も削除された場合のみです。

同じJavaScriptファイルが複数のアプリケーションで使用されることは頻繁にあります。アプリケーションに指定される各置換ファイルは一意のファイルを表すことに注意してください。これは、複数のアプリケーションに対して同じファイル名が指定されるときにも該当します。たとえば、3つのアプリケーションA、BおよびCのすべてに、置換ファイルmychecks.jsが指定されているとします。この場合、3つのバージョンのmychecks.jsファイルがRUEIによって管理されます。いずれか1つのファイルを変更すると、対応するアプリケーションのみに適用され、他のアプリケーションには適用されません。

8.3.23 アクション・ネーミング・スキームの定義

リッチ・フレームワーク(Ajaxなど)を使用するアプリケーションの場合は、アクション・ネーミング・スキームを指定できます。これは、特定のページで実行される対話型のユーザー・アクションの内容を把握する場合に特に便利です。たとえば、ユーザーがオンライン・カタログ・ページを表示している状況で、「買い物かごに入れる」というアクションをクリックしたときを把握する場合などです。

アクションに関する情報は、すべてのページおよび問題分析(「失敗したページ」など)のグループの「アクション」ビューから参照できます。セッション診断機能内でも表示できます。例を図8-46に示します。

図8-46 ページ・ビューのアクション発生

アクション・ネーミング・スキームを定義するには、次の手順を実行します。

1. 「構成」→「アプリケーション」→「アプリケーション」の順に選択して、適切なアプリケーションをクリックします。(図8-5に示したような)「アプリケーション概要」が表示されます。

2. 「ページ」タブ→「アクション・ネーミング・スキーム」設定の順にクリックします。

3. 同じアクション・ネーミング・スキームがページ・ネーミング(手動を除く)に使用でき、8.1項「ページのネーミング」に記載されています。

4. オプションで、「拡張」タブをクリックし、アクション名を小文字に変換するかどうかを指定できます。デフォルトでは、元の大/小文字のまま維持します。次に、「保存」をクリックします。

5. 必要なアクション・ネーミング・スキームを選択したら、ルーリング機能を使用して操作を絞り込むことができます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。

8.4 シングル・サインオン(SSO)プロファイルの定義

シングル・サインオン(SSO)とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。SSOには次の利点があります。

- ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。

- 同じIDに対するパスワードの再入力に要する時間を省きます。

- ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。

SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。

SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。このためには、SSOプロファイルを作成します。

8.4.1 SSO対応トラフィックの監視方法の概要

SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。図8-47に、アプリケーション認証がSSOサーバーで有効化されている場合に機能する仕組みを示します。

図8-47 SSO対応アプリケーション・トラフィック内の認証フロー

図8-47に示す認証フローは、次の順序を取ります。

1. ユーザーが、保護されたURLへのアクセスを試行します。アプリケーション・サーバーが、リクエストされたアプリケーションの認証Cookieが存在するかどうかをチェックします。Cookieが見つかった場合は、ユーザーがすでにログオンしていることを意味し、追加認証は不要です。

2. ユーザーは、アプリケーション・サーバーによってSSOサーバーにリダイレクトされます。また、アプリケーション・サーバーは、アプリケーションURLをSSOサーバーに提供し、SSOサーバーがユーザー・ログオン後の移動先を把握できるようにします。SSOサーバーは、既存の認証Cookieを検証することで、ユーザーが(別のアプリケーションによって)認証済かどうかもチェックすることに注意してください。

3. ユーザーが既存の認証Cookieに基づいて認識されない場合、SSOサーバーは、ログイン・ページでユーザーの資格証明を要求します。資格証明は、ユーザーによってユーザー名とパスワードの組合せで指定されます。

4. ユーザーの資格証明が、SSOサーバー・データベース内の対応するエントリと照合されます。検証されると、SSO Cookieによって認証が維持されます。このCookieの名前は、SSOプロファイルの作成時に指定する必要があります。

5. SSOサーバーが、ユーザーの属性をフェッチします。実際にフェッチされる属性は実装固有であり、RUEIには無関係です。

6. SSOサーバーが、手順2で提供されたURLを使用して、フェッチされた属性をパートナ・アプリケーション・サーバーに渡します。トークン引数がこのURLに追加されることに注意してください。このトークン引数の名前は、SSOプロファイルの作成時に指定する必要があります。アプリケーション・サーバーは、通常、ユーザーへの独自のCookieの発行も行います。これは、アプリケーションまたはスイートの定義中に構成されます。

最後に、手順1、2および5で使用されるネットワーク回線は、RUEIの監視対象トラフィックの有効範囲内である必要があることに注意してください。

SSOプロファイルとSSOアプリケーション

SSOプロファイルとSSOアプリケーションは、密接に関連していますが、RUEI内では独立したエンティティとしてレポートされることを理解しておく必要があります。このため、SSOプロファイルとSSOアプリケーションの定義は、相互排他的にする必要があります。つまり、それぞれが独自のドメインおよびCookieに基づく必要があります。こうしておかないと、監視対象トラフィックはアプリケーション関連トラフィックとしてレポートされ、拡張レポート作成による利点は得られません。

8.4.2 SSOプロファイルの作成

SSOプロファイルを定義する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「シングル・サインオン」の順に選択し、「新規SSOプロファイル」をクリックします。図8-48に示すダイアログが表示されます。

図8-48 新規シングル・サインオン・ダイアログ

2. SSOプロファイルの名前を指定します。これは、スイート、サービス、アプリケーションおよびSSOプロファイルを通じて一意である必要があります。SSOプロファイルの名前は後から変更できないため、注意してください。

3. 残りのフィールドを使用して、SSOプロファイルの有効範囲を指定します。有効範囲はページURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。

注意:
SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。こうしておかないと、予期しない結果がもたらされる可能性があります。一致規則の適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、SSOプロファイルは関連付けられないことに注意してください。指定できるポート番号は1つのみです。追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。

ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。フィルタの適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

次に、「次へ」をクリックします。図8-49に示すダイアログが表示されます。

図8-49 シングル・サインオン・サーバー情報ダイアログ

4. このダイアログを使用し、使用しているSSO認証サーバーに関する情報を指定します。セッションCookie名、認証トークンを含んでいるURL引数、および監視対象トラフィックでのユーザーの識別方法を指定する必要があります。これは通常、URL引数と値を使用して定義します。ただし、Cookie、リクエスト・ヘッダーまたはレスポンス・ヘッダーあるいはXPath式で指定することもできます。
次に、「終了」をクリックします。指定したSSOプロファイル定義の概要が表示されます。例を図8-50に示します。

図8-50 SSOプロファイルの概要

この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。この詳細は次の項に記載されています。

ユーザー識別を定義した結果は、ユーザー情報(XLS形式)レポートの「クライアント」カテゴリで確認できます。レポートの詳細は、第2章「レポートの操作」を参照してください。

8.4.3 SSOプロファイルの変更

SSOプロファイルを定義後に変更するには、その概要を使用します。次のタブがあります。

- 識別: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。新規フィルタを追加するには、「新規フィルタの追加」をクリックします。既存のフィルタを変更するには、そのフィルタをクリックします。図8-51に示すようなダイアログが表示されます。

図8-51 「SSOプロファイル・フィルタの編集」ダイアログ

ダイアログの最下部にあるメモは、現在のルール順序設定スキームを示します。この詳細は、12.9項「RUEI内でのルール順序設定の制御」に記載されています。

- 構成: 使用される認証トークンとCookieを指定します。

- ユーザー: ユーザーIDをアプリケーション内で識別する方法を指定します。これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。

8.4.4 SSO構成の検証

SSO対応アプリケーションの動作およびレポートが正しいかどうかを検証する場合、重要ポイントは、ユーザーIDが正しいかどうかを検査することです。データ・ブラウザ内のレポートを定期的に確認することをお薦めします(「すべてのセッション」→「ユーザーID」→セッションとページ・ビュー)。たとえば、未識別ユーザーの数が予想より多い場合などです。

また、SSO対応アプリケーション内のURLがアプリケーション関連データとしてレポートされていないかどうかも検証する必要があります。レポートされている場合は、問題があることを示している可能性があります。

8.5 アプリケーションとセッション・トラッキング定義の検証

RUEIのデプロイメントで監視中のトラフィックが正しく識別されていることを確認するために、定期的に確認することを強くお薦めします。そのためには、「構成」メニューから「統計の表示」を選択します。図8-52に示すダイアログが表示されます。

図8-52 構成統計

未確認のヒットやページが予想以上に多い場合は、ページの識別定義を確認する必要があります。この詳細は、8.1項「ページのネーミング」に記載されています。セッション識別のないページ・ビューが予想以上に多い場合は、ユーザーの識別定義を確認する必要があります。この詳細は、8.3.14項「ユーザー識別の定義」に記載されています。

8.6 サービス・テスト・トラフィックのレポート

ビジネス・クリティカルなサービスに対して最上位レベルの可用性およびパフォーマンスを維持するため、Oracle Enterprise Managerを構成してサービス・テストを監視できます。Oracle Enterprise Managerのサービス・テストはビーコンから実行されます。Oracle Enterprise Managerは、エンドユーザーの観点からサービスを監視し、ベースのITインフラストラクチャとサービスの相関関係も監視します。通常、ビーコンは、通常のアプリケーション使用に相当するユーザー・フローを実行するように設定されます。Oracle Enterprise Managerは、ユーザー・フローのレスポンス時間を各構成部分に細分化して分析します。ビーコンおよびサービス・テストを定義する手順の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』に記載されています。

RUEI内のサービス・テスト機能は、比較可能なリアル・ユーザー・トラフィックに対するこの統合トラフィックの結果の検証を許可して、Oracle Enterprise Managerサービス・テストを補完します。たとえば、サービス・テストがアプリケーションの特定項目の問題をレポートする場合、この機能を使用して、同じ期間中にこの問題がリアル・ユーザー・トラフィックでも確認されるかどうかを判別できます。この方法で、エラーの多いインシデントをすぐに識別および無視でき、実際のユーザーのレポートされた問題の影響をすぐに評価できます。

8.6.1 RUEI内のサービス・テスト監視の構成

RUEI内では、特定のアプリケーションおよびスイートのサービス・テスト・トラフィックを監視でき、検出されると「サービス・テスト」グループでレポートできます。また、監視対象のサービス・テストに関する診断情報をサービス・テスト診断機能で表示することもできます。アプリケーションまたはスイートを構成してサービス・テスト・トラフィックを検出するには、次の手順を実行します。

1. 「構成」を選択し、「アプリケーション」または「スイート」のいずれかを選択します。目的のアプリケーションまたはスイートをクリックして、その概要を表示します。例を図8-1に示します。

2. 「拡張」タブ、「Enterprise Manager」タブの順にクリックし、「サービス・テスト・トラフィックのレポート」チェック・ボックス(図8-53を参照)を使用して、選択したアプリケーションのOracle Enterprise Manager内で構成されるサービス・テスト・トラフィックをRUEI内でレポートするかどうかを指定します。デフォルトでは、これは無効です。

図8-53 「Enterprise Manager」タブ

9 ユーザー・フローの使用

この章では、ネットワーク・トラフィックを監視するときのユーザー・フローの役割について説明します。また、ユーザー・フローを構成する要素(ステップ、条件、イベントなど)やRUEIでのそれらのレポートについても説明します。

9.1 ユーザー・フローの概要

ユーザー・フローとは、1つの論理タスクを定義したWebページの集合です。タスクを完了するために実行する必要がある複数のステップで構成されます。たとえば、予約ユーザー・フローには次のステップが定義されます。

1. 航路と日付の詳細。

2. 乗客と船舶の詳細。

3. 支払いの詳細。

4. 確認書。

個々のステップは複数のWebページで構成される場合があります。たとえば、上記の支払いの詳細ステップでは、使用できる支払い方法(クレジット・カードや銀行振込みなど)ごとに独立したページを定義できます。ユーザー・フローは、ビジターが最後のステップに到達したときに完了したとみなされます。また、ステップは主にページに関して定義されますが、他のディメンション(SiebelのメソッドまたはEBSの職責やアクションなど)に関しても定義できます。

管理を容易にするために、ユーザー・フローはカテゴリにグループ分けされます。たとえば、予約、パンフレット請求、CRMアクティビティなどのために個別のカテゴリを定義できます。

条件とイベント

ユーザー・フローのステップは条件に関して定義されます。条件は、ステップに到達したとみなされるために満たす必要がある要件です。各条件はイベントに基づいて定義されます。イベントはディメンション値を使用して指定されます。

たとえば、上記の支払いの詳細ステップについて考えてみます。通常、このステップにはいくつかの異なる条件が定義され、それぞれが別の支払方法に対応しています。ステップに到達したとみなされるためには、ユーザー・セッション中にこれらの条件の1つだけが満たされる必要があります。各条件はイベント(つまり、特定のディメンション値)を使用して定義されます。条件が満たされたとみなされるためには、イベントが実現する必要があります。ある条件が満たされたとみなされるには、その条件について定義されたすべてのイベントが実現する必要があることに注意してください。

オプション・ステップと必須ステップ

ユーザー・フロー内のステップは、オプションまたは必須として構成できます。たとえば、ステップA、B、CおよびDを持つユーザー・フローを定義し、パスA > B > C > D、A > B > D、A > BおよびA > C > Dを可能とします。この場合、ステップBおよびCはオプションで、ステップAおよびDは必須です。ビジターがパスA > B > Dを進んだ場合、ユーザー・フローではA > B > C (スキップ) > Dとレポートされます。ユーザー・フローの最初と最後のステップはオプションとして定義できません。

外部ページとアボート・ページ

ビジターがユーザー・フローを完了する途中でステップとして定義されていないページにナビゲートすることがあります。このようなページは外部ページと呼ばれます。この場合、ビジターがユーザー・フローを実際にアボートしようとしているのか、ユーザー・フローに戻ることが許可されるのかを判別する必要があります(たとえば、ヘルプ・ページで操作方法を調べた後など)。ただし、ビジターが特定の外部ページにナビゲートしたときは、ユーザー・フローがアボートされたとみなす必要があります。このようなページはアボート・ページと呼ばれます。

最初のステップには特に注意する必要があります。ビジターが最初のステップに戻った場合、現在のユーザー・フローをアボートして新しいユーザー・フローを開始しようとしているのか、現在のユーザー・フローを完了する意図がまだあるのかを判別する必要があります。たとえば、上記の予約ユーザー・フローでは、ビジターが支払いの詳細ステップにいたときに、航路と日付の選択ステップに戻ることを選択した場合は、現在のユーザー・フローを中止して新しいユーザー・フローを開始しようとしていると考えられます。

アイドル時間とタイムアウト

ビジターは特定の時間内(たとえば5分間)でユーザー・フロー・ステップを完了することが予期されます。時間内に完了しないと、ユーザー・フローはアイドルとみなされます。ただし、ステップによっては時間が長くかかることがあるため(たとえば、ビジターが情報を読むための時間が必要な場合など)、ユーザー・フローの各ステップについて許容されるビジターのアイドル時間を構成できます。

セッション・アイドル時間(12.8項「セッション・レポートの制御」を参照)では、ビジターが非アクティブになってからセッションが終了したとみなされるまでの時間が指定されることに注意してください。デフォルトでは60分です。ただし、ステップのアイドル時間は、特定のユーザー・フロー・ステップ内でビジターが非アクティブになる時間のみを指します。セッションのアイドル時間がユーザー・フローで経過すると、ユーザー・フローのタイムアウトとしてレポートされます。

9.2 ユーザー・フローの定義

新しいユーザー・フローを定義するには、ビジネス・レベルの「完全」権限が必要です。次を実行します。

1. 「構成」→「アプリケーション」→「ユーザー・フロー」の順に選択します。現在定義されているユーザー・フローのカテゴリがウィンドウの左側にリストされます。ツールバーの「新規ユーザー・フロー」コマンド・ボタンをクリックします。図9-1に示すダイアログが表示されます。

図9-1 「ユーザー・フローの追加」ダイアログ

注意:
既存のユーザー・フローではステップの追加または削除を行うことはできません。ユーザー・フローが基づいているデータ・アクセス権限も変更できません。したがって、ユーザー・フローを構成する前に、要件を反映するように注意深く設計することをお薦めします。

2. ユーザー・フローの名前を指定します。名前はすべてのユーザー・フローを通じて一意にする必要があり、長さは255文字までに制限されます。定義できるユーザー・フローの最大数は200であることに注意してください。

3. 「カテゴリ」メニューを使用して、ユーザー・フローを収めるカテゴリを選択します。新しいカテゴリに収める場合は、「新規カテゴリ」ボタンをクリックして新しいカテゴリの名前を指定します。

4. 「データ・アクセス」メニューを使用して、ユーザー・フローを特定のアプリケーションまたはスイートにバインドするか、汎用にするかを指定します。データ・アクセス・フィルタの使用方法は、14.7項「モジュールにおける許可データの有効範囲の管理」に記載されています。これらの定義を後で変更できないので注意してください。

5. 「レポート・オプション・ステップ」チェック・ボックスを使用して、累積ユーザー・フロー情報をレポートする際にオプションのステップを含める必要があるかどうかを指定します。デフォルトではレポートされます。

6. 必須ユーザー・フロー・ステップごとに、「新規ステップの追加」をクリックします。図9-2に示すダイアログが表示されます。1つのユーザー・フローに含めることができるステップの最大数は15であることに注意してください。

図9-2 「ユーザー・フロー・ステップの追加」ダイアログ

7. ステップの名前を指定します。これはこの新規ユーザー・フロー内で一意にする必要があります。ユーザー・フロー・レポートで読みやすくするためにステップ名は短くすることをお薦めします(9.7項「ユーザー・フローのレポート方法の概要」を参照)。

8. ビジターが非アクティブになってからステップがタイムアウトしたとみなされるまでの時間(分)を指定します。デフォルトでは10分です。ステップのアイドル時間は、ステップで必要な読取りの時間やビジターが実行する必要がある他の操作(計算や選択など)に対応できるようによく検討することをお薦めします。デフォルトのユーザー・フロー・ステップのアイドル時間は、9.5項「デフォルトのステップ・アイドル時間の指定」に記載される手順を使用して指定できます。
このステップがユーザー・フローの最初または最後のステップでない場合は、「オプション」チェック・ボックスを使用して、ユーザー・フローの一部としてビジターがこのステップを完了する必要があるかどうかを指定できます。デフォルトでは、ステップは必須です(チェック・ボックスは選択されていません)。

9. ステップに到達したとみなされるために満たす必要がある最初のステップ条件を指定します。条件のイベントごとに、「ディメンション・レベル」および「値」メニューを使用して、チェックされるディメンションと保持する必要がある値を選択します。目的の値が「値」メニューにない場合は、横にある「検索」アイコンをクリックして探すことができます。
オプションとして、「除外」チェック・ボックスを使用すると、定義したディメンション・レベル=値のペアを除外するように適用できます。つまり、定義したイベントが満たされない場合に、イベントが達成されたとみなされます。たとえば、特定のページが表示されない場合です。次に、「保存」をクリックします。図9-1に示したダイアログに戻ります。

10. 必要に応じて、新規ステップの下の「新規条件の追加」をクリックして、ステップで必要な追加の条件を定義します。図9-3に示すダイアログが表示されます。

図9-3 ユーザー・フロー・ステップ条件の追加

必要な条件イベントごとにディメンション・レベル=値のペアを指定します。次に、「追加」をクリックします。ステップに到達したとみなされるためには定義された1つの条件のみを達成する必要がありますが、条件が満たされたとみなされるためには条件内のすべてのイベントが達成される必要があります。次に、「保存」をクリックします。図9-1に示したダイアログに戻ります。

11. 図9-1の「中断条件」タブをクリックして、ユーザー・フローがアボートされたとみなされる状況を指定します。図9-4に示すダイアログが表示されます。

図9-4 ユーザー・フロー中断条件セクション

次のチェック・ボックスがあります。

- 最初のユーザー・フロー・ステップ: ビジターが最初のステップに戻った場合にユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。

- すべての外部ページ: 選択されたユーザー・フロー内のステップとして定義されていないページにビジターがナビゲートした場合に、ユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。

- その他すべての最初のユーザー・フロー・ステップ: 別のユーザー・フローの最初のステップとして定義されているページにビジターがナビゲートした場合に、ユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。

必要に応じて、「追加」をクリックして、ビジターがナビゲートした場合にユーザー・フローがアボートされたとみなす特定のページ(またはディメンション)を指定します。

12. 必要に応じて、「通貨値」タブをクリックし、図9-5に表示される「通貨ソース」メニューと「ソース値」フィールドを使用して、ユーザー・フローでレポートされる通貨価値が基づくソースを指定します。「通貨書式」メニューを使用して、値が解釈されるソースを指定します。選択した書式によって、レポートは変更されないことに注意してください。この機能の使用方法の詳細は、9.6項「ユーザー・フローへの通貨価値の割当て」に記載されています。

図9-5 ユーザー・フロー詳細セクション

通貨価値は、URL引数、XPath式、ヘッダー、Cookie、カスタム・タグまたはカスタム関数から導出できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。また、通貨値のレポートに使用される書式設定を指定できます。

13. 次に、「保存」をクリックします。新規ユーザー・フローの監視は5分以内に開始されます。新しいユーザー・フローの概要が表示されます。

イベント・ステップの処理方法の概要

レポートされるユーザー・フロー情報を分析するときは、RUEIがユーザー・フロー・アクティビティを処理する順序を理解することが重要です。この順序をまとめると次のようになります。

- RUEIは、ビジターがユーザー・フローで進んだかどうかを判別しようとします。つまり、ビジターが次のステップに移動したかどうかを判別しようとします。移動した場合、それに応じてレポートされる進捗が更新されます。

- 次のステップに直接進んでいない場合は、後続の各ステップ(オプション・ステップの場合)に進んだかどうかがチェックされます。進捗が判別されると、レポートされます。

- 進捗が判別されなかった場合は、現在のステップがチェックされます。これが失敗すると、先行するすべてのステップ(オプション・ステップの場合)がチェックされます。進捗が判別されると、レポートされます。

- ここまですべてのチェックでユーザー・トランザクションの進捗が確認できない場合は、アボート条件がチェックされます。条件が一致すると、ユーザー・フローがアボートされたとレポートされます。一致しない場合、ユーザー・フローの現在のステータスが、外部アクティビティとしてレポートされます。

ベスト・プラクティス

ユーザー・フローを定義するときは特に次の点に注意することをお薦めします。

- ビジターが最後のステップに到達したときにユーザー・フローが完了したとみなされるため、最後のステップとして確認ページまたは完了のページを必ず定義する必要があります。

- オプション・ステップを定義するときは、承認されたナビゲーションが行われるようにWebサイトを構成してください。

- ユーザー・フローを定義するときはステップ・アイドル時間に特に注意することをお薦めします。ステップのアイドル時間をセッションのアイドル時間よりも長く定義すると、セッションのアイドル時間が優先され、セッションのアイドル時間を超過したユーザー・フローがタイムアウトとしてレポートされることに注意してください。

- フリー・テキスト機能を使用する場合は、ユーザー・フローの定義を慎重に確認して、すべての属性が定義済のデータ・アクセス制限内にあるようにすることを強くお薦めします。属性(ページ名など)が1つでもこれらの制限外にある場合は、データ・アクセス制限の強制によって、それが使用できなくなります。

9.3 ユーザー・フローの変更

既存のユーザー・フローではステップの追加または削除を行うことはできません。ユーザー・フローが基づいているデータ・アクセス権限も変更できません。したがって、ユーザー・フローを構成する前に、要件を反映するように注意深く設計することをお薦めします。

ステップの条件およびステップの他の情報(名前、場所、アボート条件、通貨価値など)は変更できることに注意してください。ユーザー・フローを変更する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「ユーザー・フロー」の順に選択します。ウィンドウの左側で適切なカテゴリとユーザー・フローをクリックします。選択したユーザー・フローの概要が表示されます。例を図9-6に示します。

図9-6 ユーザー・フロー概要

2. 「編集」コマンド・ボタンをクリックします。図9-1に示すようなダイアログが表示されます。

3. オプションとして、ステップのコンテキスト・メニューで「編集」を選択し、名前、アイドル時間またはオプションと必須の設定を変更します。前述のように、ユーザー・フローは少なくとも2つのステップを含む必要があります。最初のステップと最後のステップは必須です。次に、「保存」をクリックします。

4. オプションとして、個々のステップ条件をクリックして変更することもできます。または、横にある「削除」アイコンをクリックすると削除できます。ステップ内の「新規条件の追加」項目をクリックして、ステップに追加の条件を定義することもできます。
次に、「保存」をクリックします。ユーザー・フロー定義の変更は5分以内に有効になります。

9.4 ユーザー・フローのコピー

既存のユーザー・フローに行える変更は限られているため、ウィンドウの左側でユーザー・フローのコンテキスト・メニューの下にある「コピー」オプションを使用すると便利です。特に、このオプションを使用すると、問題のあるユーザー・フローのwhat-if分析を実行できます。

たとえば、ユーザー・フロー内の特定のステップでのアボート率が高い場合があります。ビジターのブラウザの言語設定に問題が関係しているのではないかと考えます。コピー機能を使用して、ユーザー・フローの複製を作成し、必要なステップ定義を変更します。その後、元のユーザー・フローと変更したユーザー・フローの結果を比較して、ユーザー・フローの変更によって改善したかどうかを確認します。

重要:

ユーザー・フローをコピーするときにデータ・アクセス設定を変更する場合、新規ユーザー・フローの定義を慎重に確認して、すべての属性が変更後のデータ・アクセス制限内にあるようにすることを強くお薦めします。属性(ページ名など)が1つでもこれらの制限外にある場合は、データ・アクセス制限の強制によって、それが使用できなくなります。

9.5 デフォルトのステップ・アイドル時間の指定

新しいユーザー・トランザクションが作成されるたびに、そのトランザクションのステップにアイドル時間が割り当てられます。これは、ビジターが非アクティブになってからステップがタイムアウトしたとみなされるまでの時間です。デフォルトは10分です。ただし、「構成」→「一般」→「詳細設定」→「セッション処理」→デフォルトのユーザー・フロー・ステップの時間の順に選択して、デフォルトを変更できます。この設定の変更は新規ユーザー・トランザクション定義のみに適用されることに注意してください。既存のユーザー・フローには影響しません。

9.6 ユーザー・フローへの通貨価値の割当て

パフォーマンス問題の実際のコストを把握するために、終了したユーザー・フローに通貨価値を割り当てることができます。終了したユーザー・フローとは、完了したユーザー・フロー、タイムアウトしたユーザー・フローまたはアボートされたユーザー・フローです。たとえば、この機能を使用すると、ユーザー・フローの損失に関してサーバー・アップグレードのコストを判別できます。通貨価値のソースは、カスタム・ディメンションと同様の方法で指定されます(3.12項「カスタム・ディメンションの使用」を参照)。様々なユーザー・フローの通貨価値の比較例を図9-7に示します。

図9-7 ユーザー・フロー通貨価値合計の概要の例

重要:

ユーザー・フローに通貨価値を割り当てるときは、次の点に注意してください。

- 選択した要素の通貨価値を判別するとき、先行するスペースはすべて削除されます。数字が出現してから次に数字以外の文字が出現するまでの部分が、値として取得されます。たとえば、?Basket=99.99 US dollarsという要素は99と計算されます。

- 値が、負の数、2^32よりも大きい、または文字列であると判別されると、0が返されます。

- 基礎となる要素(リクエスト・ヘッダーなど)は、ユーザー・フローの間に変化することがあります。図9-8に示す状況を考えます。ユーザー・フローAが開始したとき、通貨価値は0でした。ユーザー・フローが進行するにつれ、通貨価値は80、120、90と変化します。完了時には通貨価値90がレポートされます。

図9-8 レポートされる通貨価値の計算

9.7 ユーザー・フローのレポート方法の概要

このじょうご型の図では、選択したユーザー・フローに関する一般的な情報が得られます。選択した期間のユーザー・フローでのビジターの推移が示されます。例を図9-9に示します。

図9-9 ユーザー・フローのじょうご型図の例

選択したユーザー・フローの最新ステータスのさらに詳しい情報は、じょうご型図で確認できます。特に、現在各ステップを使用しているビジター数、ビジターがステップで行ったWebアクション(ページ・ロードやエラーなど)の状況、タイムアウトしたステップとアボートされたステップの数が表示されます。レポートされた各項目(外部ページなど)をクリックして、セッション診断機能内に表示できます。例を図9-10に示します。

図9-10 ユーザー・フロー・ステータスの詳細の例

ユーザー・フロー内のオプション・ステップは点線で示されます。ステップで発生した特定のエラーに関する詳しいセッション情報を含む診断情報は、ステップ内の「ステップのエラー」インジケータをクリックすると表示されます。レポートされた数の悪いページ・ビューの診断情報も使用できます。この機能の使用方法の詳細は、9.1項「ユーザー・フローの概要」に記載されています。

ユーザー・フローの最も詳細な情報は、「フロー遷移」表示で得られます。例を図9-11に示します。

図9-11 ユーザー・フロー遷移の詳細の例

ステップにおける外部アクティビティのレベル、アボート、タイムアウト、オプション・ステップのスキップなど、ステップ間の遷移について豊富な情報が提供されます。「アイドル」項目は、ステップを使用しているが、定義されたステップ・アイドル時間よりも非アクティブな状態が続いているビジター数を示すことに注意してください。これらのビジターが1時間以内にアクティビティを再開すると、「アイドル・リターン」項目に表示されます。再開しない場合は、タイムアウトとみなされてステップが停止します。

ユーザー・フロー・ステータス(図9-10)およびユーザー・フロー遷移(図9-11)にレポートされる数の導出方法を理解するには、図9-12に表示されているセッション情報の例を考慮してください。3つのユーザー(X、YおよびZ)が参照するページが表示されます。ユーザー・フローは監視され、ページP1、P2およびP3に対応する3つのステップで構成されます。

図9-12 ユーザー・フローのレポートの例

各ユーザー・セッションが進むと、各ステップの真上にある矢印がステップを開始するユーザーの数を示し、ステップ内の数が参照されたステップ・ページの合計数を示し、右側の3つの数値が外部、外部者リターンおよび停止したユーザー・フローの数を示します。表示されたページに関連するエラーがある場合、ページ名の後にアスタリスク(*)で示されます。

P4はヘルプ・ページで、P5は中断ページとみなされます。このため、P4が検出されると外部が(ステップAで)レポートされ、P5が検出されると停止したユーザー・フローがレポートされます。ユーザーがP4から戻ると、外部リターンがレポートされることにも注意してください。

ユーザーXおよびユーザーYのユーザー・フローは10:20で完了し、ユーザーZはタイムアウトします。このため、停止したユーザー・フローは11:20でレポートされます。タイムアウトしたユーザー・フローをレポートされるデータに含める場合、十分な期間を選択する必要があります。

ユーザー・フローの累積レポート

選択した期間のユーザー・フローのレポートおよびユーザー・フローの累積レポートの違いを理解してください。選択したステップにレポートするページ・ロード時間を考慮してください。これは、選択した期間中のステップのページ・ビューのロード時間(秒単位)を示します。ただし、中断したステップの合計ページ・ロード時間がレポートされる場合、選択した期間に関係なく、そのステップのすべての中断したページ・ビューの合計ロード時間を表します。停止したステップの合計ページ・ロードがタイムアウトおよび中断したステップ・ページ・ビューのページ・ロードの合計を表すことに注意してください。

図9-13 終了したユーザー・フローのレポート方法の概要

ローリング・サム・レポート

ファンネル・グラフ(ユーザー・フロー完了グループ内のユーザー・フロー・ビューで使用可能)内で、「ローリング・サムの表示」を「値」メニュー内で使用できます。選択されると、ユーザー・フローの累積合計を示す追加の列が表示されます。この列は、エクスポート時にも使用できます。

期間レポート

ユーザー・フロー完了グループ内の多くのビューにより、ユーザー・フローの期間を把握できます。例を図9-14に示します。

図9-14 ユーザー・フローのアクティブ/アイドル時間ビュー

これらのビューを使用する場合は、次の点に注意してください。

- ユーザー・フローがアイドルになる場合(定義済のステップのアイドル時間に基づく)、最後のページ・ビュー時間およびステップのアイドル時間の間の時間が「アクティブ」としてマークされ、この後の時間が「アイドル」としてレポートされます。このため、異なる定義済のステップのアイドル時間の2つの同じユーザー・フローには、異なるフロー期間およびフロー・アイドル時間で同じセッションがレポートされます。

- ユーザーがステップの後にアクティブになった後、ステップのアイドル時間がアクティブ時間に含まれます。ユーザーがユーザー・フローの外部に移動して戻らなかった場合も、ステップ・アイドル時間がアクティブ時間に含まれます。その場合は、セッションがタイムアウトとして報告されます。

9.8 サービス・テスト・セッションのユーザー・フローへの変換

「サービス・テスト診断」グループ(8.6項「サービス・テスト・トラフィックのレポート」を参照)では、選択したサービス・テスト・セッションをRUEIユーザー・フローに変換することができます。こうすると、監視対象のユーザー・フローがすべてのユーザー・フロー・グループ内でレポートされるという利点が得られます。監視対象の他のユーザー・フローと直接比較できるだけでなく、レポート機能が強化されます。

サービス・テスト・セッションをRUEIユーザー・フローに変換するには、ビジネス・レベルの「完全」権限が必要です。次を実行します。

1. 「データの参照」、「サービス・テスト」グループの順に選択し、「サービス・テスト診断」機能を選択します。カレンダ・コントロール(2.6項「カレンダの使用方法」を参照)を使用して、目的の期間を選択します。表示範囲としては1日(または未満)を選択する必要があります。この制限外で検索しようとするとエラーが発生します。図9-15に示す検索パネルが表示されます。

図9-15 「サービス・テスト診断」検索機能

セッション診断機能の概要は、4.1項「概要」を参照してください。

2. 必要に応じて、使用可能な基準を使用し、指定期間についてリストされるサービス・テスト・セッションを制限します。次に、「検索」をクリックします。検索結果がウィンドウの主要部に表示されます。例を図9-16に示します。

図9-16 サービス・テスト診断

3. ユーザー・フローに変換するサービス・テスト・セッションをクリックして選択します。そのセッションの詳細が表示されます。例を図9-17に示します。

図9-17 サービス・テスト・セッションの詳細

4. ツールバーの「ユーザー・フローの作成」コマンド・ボタンをクリックし、選択したサービス・テスト・セッションをRUEIユーザー・フローに変換します。図9-18に示すダイアログが表示されます。

図9-18 「サービス・テスト・セッションからユーザー・フローを追加」ダイアログ

5. 新しいユーザー・フローの名前を指定します。これは選択したユーザー・フロー・カテゴリ内で一意にする必要があります。デフォルトは、監視対象のサービス・テスト名です。

6. 新しいユーザー・フローを収めるするカテゴリを指定します。既存のカテゴリでも新規カテゴリでもかまいません。デフォルトは「サービス・テスト」です。

7. 変換処理では、基礎となるサービス・テスト・セッションから論理ユーザー・フローを構築することに注意してください。そのため、ステップ内で同じページ名が複数回出現すると、それらはページごとに統合され、ステップ内で個別の条件を構成します。また、サービス・テスト・セッション内で前後にスキップするように見えるステップは、オプション・ステップとみなされます。したがって、新規ユーザー・フローの構造を慎重に確認して、それが要件を満たしていることを確実にする必要があります。次に、「保存」をクリックします。

重要:

サービス・テスト・セッションをユーザー・フローに変換するときは、次の点に注意してください。

- 新規ユーザー・フローのステップは最大15に制限されます。この制限を超えるステップを含むサービス・テスト・セッションは、自動的に切り捨てられます。

- 変換されたユーザー・フローには少なくとも2つのステップが含まれる必要があります。

10 スイートおよびWebサービスの使用

この章では、スイートを使用して特定のOracle Enterpriseアーキテクチャ(Oracle E-Business Suite、Siebel、WebLogic Portalなど)を拡張監視する方法について説明します。また、Webサービスの監視についても説明します。

10.1 スイートの使用

前述のように、RUEIにおけるページ識別は、アプリケーションに基づいて行われます。ただし、アプリケーションが特定のOracle Enterpriseアーキテクチャ(Oracle E-Business Suite、Siebel、WebLogic Portalなど)に基づいている場合、スイートという第4のレベルが導入されます。スイートとは一般にアプリケーションの集合であり、スイートに関連付けられているWebページは、スイート » アプリケーション » グループ » ページという構造を持ちます。

重要:

現在サポートされているOracle Enterpriseアーキテクチャのいずれかを監視対象の環境で使用している場合は、この機能を使用することを強くお薦めします。この機能を使用すると、アプリケーション定義にかかる時間が短縮され、スイート内のアプリケーションの互換性が高くなるのみでなく、これらのアーキテクチャが正しく監視されるようにもなります。

10.1.1 スイート定義の作成

スイートのインスタンスを定義する手順は、次のとおりです。

1. 「構成」→「アプリケーション」の順に選択して、図10-1に示すメニュー構造から「スイート」を選択します。

図10-1 スイート

2. 「新規スイート」をクリックします。図10-2に示すダイアログが表示されます。

図10-2 「新規スイート」

3. スイートの名前を指定します。この名前は、スイート、サービス、SSOプロファイルおよびアプリケーションを通じて一意である必要があります。スイート・インスタンスの名前は後から変更できないため、注意してください。

4. 残りのフィールドを使用して、スイートの有効範囲を指定します。有効範囲はページURLの部分として定義されます。これらのフィルタ基準の使用方法は、8.3項「アプリケーションの定義」に記載されているものと同じです。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。空白フィルタは使用できません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できません。標準以外のポート(つまりポート80/443)に着信するネットワーク・トラフィックには、スイート・インスタンスは関連付けられないことに注意してください。明示的に指定できるポート番号は1つのみです。さらに必要な場合は、追加フィルタとして構成する必要があります。ワイルドカード文字を指定して、ドメイン名とURL引数の組合せによるその他の情報を指定しないことはできません。次に、「次へ」をクリックします。図10-3に示すダイアログが表示されます。

注意:
スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。相互に排他的でないフィルタ定義を使用すると、予期しない結果が生じることがあります。フィルタの適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

図10-3 スイート・タイプ

5. このダイアログでは、スイートのベースとなるOracle Enterpriseアーキテクチャを指定できます。次に、「終了」をクリックします。指定したスイート定義が表示されます。例を図10-4に示します。

図10-4 スイートの概要

6. この概要には、定義したスイートのサマリーが示されます。これには、定義したページ識別フィルタ、これまでに表示されたページ数の合計(0:00現在日以降)、検出および記録が必要な関数エラー(存在する場合)、およびビジター・セッションの追跡にスイート内で使用されるユーザー識別メカニズムが含まれます。これらはすべて、必要に応じて個別に変更できます。手順は、8.3項「アプリケーションの定義」に記載されているものと同じです。

10.1.1.1 タグ・ベースのスイート

デフォルトでは、スイートはネットワーク・ベースのデータ収集を使用するように定義されています。WebCenter Sitesの場合のみ、タグ・ベースのデータ収集を使用できます。これは、図10-4に示すスイート定義画面で有効にできます。

タグ・ベースのデータ収集を有効にした場合、8.3.1項「ブラウザJSライブラリ設定の定義」の説明に従ってブラウザJSライブラリを定義する必要があります。タグ・ベースおよびネットワーク・ベースの監視の設定の詳細は、RUEIインストレーション・ガイドの「RUEIソフトウェアのインストール」を参照してください。

10.1.2 設定ファイルのアップロード

特定のOracleアーキテクチャの本番環境に基づいたトラフィックの監視時に使用するために提供された適切なスクリプトを実行することを強くお薦めします。たとえば、create_EBS_info.plスクリプトなどです。この目的は、実際の環境でこれらのアーキテクチャが実装された方法を特定することです。特に重要なのは、ページ・ネーミング・スキームです。次を実行します。

1. 選択したスイートに付属の適切なスクリプトをダウンロードします。この機能の使用方法の詳細は、対応する付録を参照してください。

2. スクリプトをデプロイメント環境で実行します。このスクリプトにより、環境内でページIDにIDが割り当てられます。スクリプトを実行するディレクトリ内に、多数の.txtファイルが作成されます。

3. 生成された.txtファイルから.zipファイルを作成し、RUEIレポータ・システムへのファイルのアップロードに使用可能な場所に、この.zipファイルをコピーします。

4. 「構成」→「アプリケーション」→「スイート」の順に選択して、該当するスイートを選択します。スイートの概要が表示されます。「構成のアップロード」コマンド・ボタンをクリックします。図10-5に示すダイアログが表示されます。

図10-5 「スイート構成のアップロード」

5. スクリプトで生成されたファイルの名前を指定します。目的のファイルを検索するための「参照」ボタンが使用可能です。ファイルは.zipファイルである必要があります。次に、「アップロード」をクリックします。

重要:
この構成ファイルを、目的の各スイート・インスタンス用にアップロードする必要があります。構成ファイルには、既知の(および空でない).txtファイルのみを含めることができます。これらのファイルはすべてルート・ディレクトリに存在する必要があります。つまり、サブディレクトリは許可されていません。実際の本番環境に基づいた適切な構成ファイルを目的のスイート・インスタンス用にアップロードする必要があります。監視対象のアプリケーションを変更する場合、スクリプトを再実行して、生成された.zipファイルを再インポートする必要があります。エラーの多い構成ファイルのインポート結果は、正しくないレポートになります。

10.1.3 スイート定義の変更

前述のように、スイートとは一般にアプリケーションの集合です。スイートの定義後にそのプロパティを変更するには、8.3項「アプリケーションの定義」でアプリケーションに関して記載されているのと同じ方法を使用します。

次の点に特に注意してください。

- スイートでクリックアウト機能を使用するためには、スイート・インスタンスのエンタープライズ名を正しく指定する必要があります(4.6項「外部ツールへのクリックアウトの構成」を参照)。これは、EMGCでのスイートの構成から取得できます。たとえば、ec2ebs2-Oracle E-Business Suite、siebel_emgc-amp11.oracle.comのように指定します。

- スイート固有のデフォルトの関数エラーが多数定義されています。これを確認して、実際の環境の要件に合うようにしてください。手順は、8.3.13項「アプリケーション・コンテンツ・メッセージのトラップ」に記載されているものと同じです。

- デフォルトでは、未分類のページはレポートされません。これを変更するには、「未分類のページのレポート」チェック・ボックスを選択します。手順は、8.3.6項「未分類のページのレポート作成」に記載されているものと同じです。

- 「サービス・テスト・トラフィックのレポート」チェック・ボックスを使用して、選択したスイートのためにOracle Enterprise Managerで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。デフォルトでは、レポートは行われません。この機能の使用方法の詳細は、8.6項「サービス・テスト・トラフィックのレポート」に記載されています。監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。この機能は、9.8項「サービス・テスト・セッションのユーザー・フローへの変換」に記載されています。

- ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。ただし、RUEIシステムをNATデバイスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。この詳細は、付録Q「NATトラフィックの監視」に記載されています。

- スイートごとに、デフォルトのユーザー識別スキームが定義されています。これを確認して、実際の環境の要件に合うようにしてください。手順は、8.3.14項「ユーザー識別の定義」に記載されているものと同じです。

- スイート診断グループ(3.2.5項「問題分析のためのスイートURL診断」を参照)を使用すると、スイートのヒットについてレポートされた機能URLを表示できます。この機能の使用方法は、アプリケーションの場合と同じです(8.3.21項「問題分析グループ内のレポートの制御」を参照)。

- スイート全体のページを識別できるのみでなく、ページを手動で定義することもできます。手順は、8.3.20項「ページの手動識別」に記載されているものと同じです。ただし、新規ページを最初から定義することはできません。既存のページを新規ページのベースとして使用する必要があります。

10.1.4 スイート定義の検証と評価

Oracle Enterpriseアーキテクチャ・ベースのアプリケーションについてRUEIで収集およびレポートされるデータの品質を保証するために、レポートされる詳細を検証することを強くお薦めします。定義済スイートについて検出される関連ページの数に特に注意する必要があります。

「データの参照」→「すべてのページ」グループ→「アプリケーション」サブグループの順に選択します。ページ・ビューやヒットなど個々のディメンションにおいて、ページ・ビューがいくつかのアプリケーションについてレポートされているのを確認できます。ディメンションのスイート名は、カッコ内に表示されます。WLPストリーミング・ポータルの例を図10-6に示します。

図10-6 スイートのページ・ビュー

10.2 フレームワーク例外によるアプリケーション定義の微調整

10.1項「スイートの使用」ですでに説明しているように、RUEIは、特定のOracle Enterpriseアーキテクチャ(SiebelやOracle E-Business Suiteなど)の監視の専用サポートを提供します。これは、各アーキテクチャが基礎となる標準のフレームワークに基づいて異なるためです。しかし、カスタマイズしたバージョンのアーキテクチャ・フレームワークを使用してアプリケーションを開発した場合、そのネットワーク・トラフィックを正確に監視してレポートするために、RUEIでは変更点に関する情報が必要になります。これは、アーキテクチャ・フレームワークがレガシー・アプリケーションのラッパーとして使用された場合でも同様です。アプリケーション開発者は、フレームワーク例外の機能を使用して、RUEIの標準アーキテクチャでのレポート・スキームに対して必要な例外を指定することができます。この機能は、スイート以外のアプリケーションでも使用できます。

アプリケーションの基礎となるフレームワークを変更してカスタム・ページを追加した場合には、そのページが正しく識別されるように、手動でページを定義するのではなく(8.3.20項「ページの手動識別」を参照)、フレームワーク例外の機能を使用することを強くお薦めします。

アプリケーションのURLパターン

通常、アプリケーションは、ドメインによって識別されます。たとえば、myshop.comなどです。可能なホーム・ページを図10-7に示します。

図10-7 アプリケーション・ホームページの例

各機能部は、URLパターンで識別されます。次に例を示します。

- myshop.com/catalog: 使用できる項目のオンライン・カタログから項目を参照および注文する顧客の機能を含みます。これは、標準フレームワーク実装に基づきます。

- myshop.com/user/preferences: 顧客がWebサイトの表示を変更してパーソナル・プリファレンスを反映できる機能を含みます。たとえば、言語、測定単位、通貨などです。これは、カスタマイズされたフレームワーク実装に基づきます。

- myshop.com/shop/checkout: 顧客の注文を確認して支払いを手配できる機能を含みます。これは、カスタマイズされた請求実装に基づきます。

この場合、正しいレポートを確認するため、アプリケーションのuser/preferencesおよびshop/checkout部に行われたカスタマイズの情報が提供される必要があります。catalog部は標準フレームワークに基づいているため、詳細情報を指定する必要がありません。

フレームワーク例外の指定

アプリケーションに対して使用されるフレームワーク例外を定義するには、次の手順を実行します。

1. 「構成」→「アプリケーション」→「フレームワーク例外」の順に選択します。「新規フレームワーク例外」項目をクリックします。図10-8に示すダイアログが表示されます。

図10-8 「フレームワーク例外の追加」ダイアログ

2. フレームワーク例外の一意の名前を指定します。フレームワーク例外をすべてのアプリケーション定義に適用する場合には「汎用」、特定のOracle Enterpriseアーキテクチャに適用する場合には「スイート」を選択してください。後者の場合は、アーキテクチャを指定する必要があります。少なくとも1つのスイート・インスタンスが定義されている場合、スイートが「スイート・タイプ」メニューにのみ表示されます。オプションで、短い説明を指定します。定義する例外の目的と範囲に関する説明を含めることをお薦めします。次に、「保存」をクリックします。

3. 新規作成したフレームワーク例外をクリックします。図10-9に示すような概要が表示されます。

図10-9 フレームワーク例外の概要

4. 「識別」タブをクリックし、「新しいURLパターンの追加」アイテムをクリックします。これにより、フレームワーク例外の範囲が指定されます。1つ以上のパターンを入力し、アプリケーションの構造を反映させます。パターンはスラッシュ("/")またはワイルドカード("*")で始める必要があります。そうしないと、URLと一致しません。ワイルドカードを必要に応じて使用して、ディレクトリにつながるパスに関係なく、特定のURLパターンのすべてのサブディレクトリを含めるか、特定のサブディレクトリのみを指定します。たとえば、*/preferences/*は、次のような深いパスを含め、"preferences"を含む任意のパスと一致します。

1. www.myshop.com/preferences

2. www.myshop.com/user/preferences

3. www.myshop.com/another/location/preferences/subdir/subdir/

ただし、ワイルドカードのないパスは、正確なURLとのみ一致します。たとえば、/shop/checkoutは、/shop/checkout/payments/とは一致しません。

また、パス内のURL引数は考慮されないため、同じパス(URL引数を持つものと持たないもの)は同じとみなされます。

5. ページ/オブジェクト条件タブをクリックします。「新規条件の追加」項目をクリックします。図10-10に示すダイアログが表示されます。

図10-10 「ヒット・タイプ条件の追加」ダイアログ

6. 「ヒット・タイプ」メニューを使用して、検出されたヒットの処理方法を指定します。表10-1に、使用可能なオプションを示します。

表10-1 「ヒット・タイプ」オプション

ヒット・タイプ

ページ名脚注1

ロード時間脚注2

コンテンツ・エラー脚注3

プレビュー脚注4

ページ

X

X

X

X

オブジェクト

-

X

-

-

リダイレクト

-

X

-

-

ハートビート

-

-

-

-

脚注1 レポートされるページ名は、ヒットから取得されます。

脚注2 ページ・ロード時間を決定する際にヒットが考慮されます。

脚注3 コンテンツ・エラーについてヒットがスキャンされます。

脚注4 「セッション診断」機能でプレビューに使用されます。

例外が適用されるために満たされる必要があるイベントを指定します。イベントごとに、「ディメンション・レベル」および「値」メニューを使用して、チェックされるディメンションと保持する必要がある値を選択します。目的の値が「値」メニューにない場合は、横にある「検索」アイコンをクリックして探すことができます。

必要に応じて、「除外」チェック・ボックスを使用すると、定義したディメンション・レベル=値ペアを除外するように適用します。つまり、定義したイベントが満たされない場合に、イベントが達成されたとみなされます。次に、「追加」をクリックします。例外が適用されるためには定義された1つの条件のみを達成する必要がありますが、条件が満たされたとみなされるためには条件内のすべてのイベントが達成される必要があります。次に、「保存」をクリックします。図10-9に示したダイアログに戻ります。

7. 「ディメンション定義」タブをクリックします。選択したアプリケーション・タイプに固有のディメンションが表示されます。例を図10-11に示します。

図10-11 「ディメンション定義」セクション

8. デフォルト・ソースを変更したいディメンションをクリックします。「ソース・タイプ」と「ソース値」のフィールドを使用して、選択したディメンションのレポート値を導出する方法を指定します。図10-12を参照してください。

図10-12 「ソース・タイプ」のオプション

オプションで「置換値」フィールドを使用すると、取得した値に適用する変換を指定できます。表10-2に、使用可能なオプションを示します。次に、「保存」をクリックします。

表10-2 識別オプション

オプション

説明

URL引数

ディメンション値は、指定したURL引数から導出する必要があります。

リクエストのXPath

ディメンション値は、リクエストに適用されるXPath式から導出する必要があります。

JSONリクエストのXPath

ディメンション値は、JSONリクエストに適用されるXPath式から導出する必要があります。

リクエストのヘッダー

ディメンション値は、指定したリクエスト・ヘッダーから導出する必要があります。

レスポンスのXPath

ディメンション値は、レスポンスに適用されるXPath式から導出する必要があります。

JSONレスポンスのXPath

ディメンション値は、JSONレスポンスに適用されるXPath式から導出する必要があります。

レスポンスのヘッダー

ディメンション値は、指定したレスポンス・ヘッダーから導出する必要があります。

Cookie

ディメンション値は、指定したCookie要素から導出する必要があります。

カスタム・タグ

ディメンション値は、指定したカスタム・タグから導出する必要があります。

カスタム関数

ディメンション値は、指定したカスタム関数から導出する必要があります。最初のパラメータのみが使用され、単一引用符または二重引用符で囲む必要があります。次に例を示します。

wiViewState("wi_menu_main_menu");

リテラル値

ディメンション値を指定したリテラル値に設定する必要があります。

HTMLタイトル

ディメンション値は、ページの<title>タグ内で見つかったテキストから導出する必要があります。

URL

ディメンション値は、ビジターのブラウザのロケーション・バーに表示される完全なドメインとURLから導出する必要があります。

URLベース

ディメンション値は、URLのメイン・ディレクトリとファイル名(ファイル拡張子は除く)の部分から導出する必要があります。

URLディレクトリ

ディメンション値は、URLのディレクトリ部から導出する必要があります。

URL全体

ディメンション値は、URLのメイン・ディレクトリ、ファイル名(ファイル拡張子は除く)および構成済の引数から導出する必要があります。

9. ルーリング機能を作成すると、それを使用して、新規作成する定義を調整する追加の一致ルールを指定できます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。

10.2.1 URLパターンの評価順序

デフォルトでは、個々のURLパターンが評価される順序は、URLパターンがシステムで定義されている順序になります。つまり、新しく定義する各URLパターンは、パターン評価チェーンの末尾に配置されます。処理中に、RUEIはURLを、この順序で使用可能なパターンと照合しようとします。

1つ以上のURLパターンの評価優先度の変更が必要になる場合があります。たとえば、パターンが高レベルの詳細を含んでいるため、特定のURL (/shop/checkout/payment-failed.jspなど)に絞り込む場合、/shop/*などのより汎用的な式より前に評価する必要があります。

RUEIは、URLパターンの評価優先度の管理機能を提供します。フレームワーク例外の概要画面で、ツールバーの「フレームワーク例外の優先度の編集」ボタンをクリックします。

図10-13 「フレームワーク例外」ウィンドウ

次のダイアログが表示されます。

図10-14 「フレームワーク例外の優先度」ウィンドウ

このダイアログでは、フレームワーク例外のすべてのURLパターンの概要が、評価される順序で表示されます(チェーンの上にあるパターンは、下にあるパターンより先に評価されます)。

1列目にはURLパターンが含まれています。2列目には、このパターンが定義されているフレームワーク例外が表示されます。3列目には、フレームワーク例外のタイプ(これはフレームワーク例外の作成時に指定したタイプ)が表示されます。4列目は、フレームワーク例外が現在有効であるかどうかを示します。(一致優先度チェーン内の位置に関係なく、無効なフレームワーク例外のURLパターンは、URL一致時にスキップされます。)

最終列には、チェーン内でパターンを上下に動かせるコントロールが含まれています。上向き矢印をクリックすると、現在のURLパターンは1行上昇し、一致優先度が高くなります。下向き矢印をクリックすると、現在のURLパターンは1行下降し、一致優先度が下がります。変更はすぐに有効になります。

終了したら、「閉じる」ボタンをクリックします。

10.2.2 環境間でのフレームワーク例外の移動

フレームワーク例外は、アプリケーション自体と同時に作成することをお薦めします。そのためには、開発中のアプリケーションをRUEIで開始し、そこで定義されている例外を取得した結果に基づいて微調整するのが最も確実です。

デプロイの準備ができると、アプリケーションは本番環境に移動されます。その新しい環境が別のRUEIインストールによって監視される場合でも、アプリケーションの例外ルールを手動で再作成する必要はありません。そのかわりに、ダウンロード機能を使用してその最新定義を取得し、生成されたファイルをアップロードして新しいRUEIインストールで使用することができます。

この機能は、複数の環境間でアプリケーションをデプロイするときに特に便利です。たとえば、エクストラネット・ベースのアプリケーションをビジネス・パートナーが使用するように提供する場合などです。

重要:
生成されるフレームワークは独自のフォーマットなので、どんな場合でも変更しないでください。

フレームワーク例外定義のダウンロード

定義済のフレームワーク例外をダウンロードするには、次の手順を実行します。

1. 「構成」→「アプリケーション」→「フレームワーク例外」の順に選択します。「フレームワーク例外のダウンロード」コマンド・ボタンをクリックします。現在定義されているフレームワーク例外を示すウィンドウが開きます。例を図10-15に示します。

図10-15 「フレームワーク例外のダウンロード」ウィンドウ

2. 必要なフレームワーク例外を選択します。準備ができたら、「ダウンロード」をクリックします。

3. ブラウザの構成方法によって異なりますが、zipファイルの保存場所の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。

フレームワーク例外定義のアップロード

フレームワーク例外定義をアップロードすると、この定義に含まれているURLパターンは、評価優先度チェーンの末尾に追加されます。したがって、定義をアップロードした後は、URLパターンの評価優先度を見直すことを強くお薦めします。フレームワーク例外定義がすでに存在する場合、URLパターンは、アップロードにあるURLパターンと置換されます。

注意:
フレームワーク例外が最初にダウンロードされた後に追加または変更されたURLパターンは、このフレームワーク例外定義をアップロードすると削除されます。

置換済のすべてのパターンの場合、パターン一致優先度と、最後に使用されたときを示すカウンタの両方はリセットされます。したがって、パターンの置換は、レポート済の最終使用時の情報をリセットする場合の手法として使用できます。

アップロードを行った後は、URLパターン一致優先度の見直しおよび調整を行うことを忘れないでください。

10.3 Webサービスの定義

Webサービスの出現は、IT産業における最も重要な進歩の1つです。各組織は、情報(たとえば注文書、在庫水準、出荷通知およびインターバンク取引など)を交換するためにエンタープライズ・アプリケーションの統合を進めています。

Webサービスの概要

ここでいう「Webサービス」とは新しい種類のサービスであり、それまで「Webサービス」と呼ばれてきたものとは区別する必要があります。通常、Webサービスは、Web上で使用可能な任意のサービスのことを指していました(たとえば検索エンジン、言語翻訳、天気ガイド、地図など)。ただし、このようなタイプのWebサービスには、人間によるなんらかの介入が必要でした。

WebサービスはW3C脚注1により、「ネットワーク上で相互作用できるマシンとマシンの対話をサポートするために設計されたソフトウェア・システム」と定義されています。Webサービスが実装するビジネス機能は明確に規定されており、他のサービスの状態に依存せずに稼働します。Webサービスには、その消費者との間で明確に規定された契約があります。サービス同士の接続は柔軟で、あるサービスが他のサービスと連動するためにその技術的な詳細を把握する必要はなく、すべての相互作用はインタフェースを介して行われます。サービス・プロバイダは、このテクノロジを使用して、Web上でサービスとともにインタフェースとサービスのネーミング仕様を単に公開して、接続を待機します。

サービスはサービスの説明で使用可能にします。それには、サービスのコール方法、およびサービスをリクエストしてレスポンスを得るために必要な情報を記述します。データ交換は、リクエスト/レスポンスのパターンを踏襲します。RUEIでは主としてXML-SOAPおよび同様のメッセージの監視がサポートされます。

Webサービス定義の作成

Webサービスを定義する手順は、次のとおりです。

1. 「構成」→「サービス」の順に選択します。現時点で定義されているWebサービスがリストされます。「新規サービス」をクリックします。図10-16に示すダイアログが表示されます。

図10-16 サービス構成ウィザード

2. サービスの名前を指定します。定義されたサービスに対して、この名前がレポートおよびデータ・ブラウザ内で使用されます。この名前は、サービス、SSOプロファイル、スイートおよびアプリケーションを通じて一意である必要があります。サービスの名前は後から変更できないため、注意してください。

3. 残りのフィールドを使用して、サービスの有効範囲を指定します。有効範囲はサービスURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。
最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。サービス名を指定して他のすべてのフィールドを空白にすることはできません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、サービスは関連付けられないことに注意してください。「ポートの検索」フィールドには1つのポート番号しか指定できません。追加のポートを指定する必要がある場合は、新しいサービスが作成された後で追加のフィルタとして指定してください。

ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURL引数の組合せ情報を指定しないことはできません。

注意:
サービス、SSOプロファイル、アプリケーションおよびスイート間でフィルタ定義を相互排他的にしておくことをお薦めします。たとえば、ドメインoracle.comでフィルタリングされるサービスを定義した状態で、oracle.com/application_servletでフィルタリングされる別のサービス、スイートまたはアプリケーションを定義しないでください。相互に排他的でないフィルタ定義を使用すると、予期しない結果が生じることがあります。フィルタの適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

URLの部分の中に、一致対象とする引数を指定することもできます。この機能を使用する場合は、引数と引数名の両方を揃えて指定することで初めてページURLと一致することができることに注意してください。つまり、部分一致はサポートされていません。次に、「次へ」をクリックします。図10-17に示すダイアログが表示されます。

図10-17 「関数ネーミング・スキーム」ダイアログ

4. このダイアログを使用し、サービスを識別してレポートする方法を指定します。アプリケーション(8.3項「アプリケーションの定義」を参照)がアプリケーション » グループ » ページという構造で構成されているのに対して、サービスはサービス名 » 機能グループ » 機能名という構造で構成されていることを理解しておく必要があります。グループ・ネーミング・スキームを指定する場合、グループ・ネーミング・スキームがレポートされるためには、グループ・ネーミング・スキームが関数コール内にあることが必要です。
次に、「終了」をクリックします。指定したサービス定義の概要が表示されます。例を図10-18に示します。

図10-18 サービスの概要

サービス定義の微調整

サービスを定義した後で、関連する機能スキームを変更できます。「識別」セクションで、「新規フィルタの追加」をクリックして、サービスに関連付ける必要がある機能に追加のフィルタを指定できます。定義済フィルタのいずれかと一致する機能が、サービスに割り当てられます。また、既存のフィルタ定義を変更するには、それをクリックします。いずれの場合にも、図10-16に示したフィルタの中から選択できます。ユーザーによる追加または変更を反映するようにサービス概要が更新されます。

クライアント識別

クライアントID識別スキームを定義する手順は、アプリケーションやスイートについての手順と同じです。8.3.14項「ユーザー識別の定義」に記載されています。

IPアドレス・ソースの指定

ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはTCPパケットからフェッチされます。ただし、RUEIシステムをNATデバイスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。「拡張」セクション(図10-16)のクライアントIPソース・チェック・ボックスを使用して、目的のスキームを指定できます。この詳細は、付録Q「NATトラフィックの監視」に記載されています。

10.3.1 未分類の関数コールのレポート

関数コールのうち、そのURL定義によりサービスに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません(デフォルト)。ただし、そのような未分類のコールをレポートする場合は、「関数」セクションの「未分類のコールのレポート」チェック・ボックスを使用します。

サービスに属していることが確認されていないヒットは未分類のコールとして識別されるため、定義が不正確または不十分な関数コールは未分類として識別されます。未分類のコールは、関連するデータ・ブラウザ・グループ内のカテゴリ「その他」にレポートされることに注意してください。

10.3.2 関数ロードの満足度の指定

関数のレスポンス時間を評価するために、RUEIでは関数コールごとに満足度レベルが割り当てられます。これは、8.3.11項「ページ・ロードの満足度の指定」で説明するページ・ロードしきい値と等価です。

10.3.3 関数コール・エラーのトラップ

関数に関連付けられた文字列を検出する手順は、アプリケーションの場合の手順と同じです。8.3.13項「アプリケーション・コンテンツ・メッセージのトラップ」に記載されています。

脚注

脚注1: World Wide Web Consortium(W3C)は、World Wide Webの中心的な国際標準組織です。

11 OAMおよびSSOベース・トラフィックの監視

この章では、OAMベース・トラフィック内におけるユーザー・アクティビティの監視方法について説明します。また、SSOメカニズムを介してユーザー・アクセス制御を管理するWebトラフィックの監視についても説明します。

11.1 OAMベース・トラフィックの監視

Oracle Access Manager(OAM)トラフィック内のユーザーIDを識別するように、RUEIを構成できます。OAMバージョン10.1.4.x(以上)がサポートされます。OAMベース・トラフィックを監視する手順は、次のとおりです。

1. 目的のアプリケーションを選択し、「ユーザー」セクションをクリックします。

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

3. 「検索タイプ」メニューで「Oracle Access Manager」オプションを選択します。

4. 「ソース値」フィールドに、監視対象のOAMベース・トラフィック内でユーザー識別を追跡するために使用するCookieの名前を指定します。デフォルトでは、これはObSSOcookieです。次に、「保存」をクリックします。カスタマイズされたCookie実装がOAMサーバーで使用される場合は、OAM管理者に問い合せてください。OAM Cookieのカスタマイズの情報は、Oracle Access Manager管理者ガイドに記載されています。

5. 「構成」→「アプリケーション」→「セッション・トラッキング」の順に選択します。現時点で定義されているCookieの設定が表示されます。例を図12-4に示します。

6. 「新規Cookieの追加」をクリックします。図12-3に示すダイアログが表示されます。

7. 「Cookieタイプ」メニューでOAMオプションを選択します。

8. 「Cookie名」フィールドに、監視対象のOAMベース・トラフィック内でユーザー識別を追跡するために使用するCookieを指定します。デフォルトでは、これはObSSOcookieです。次に、「保存」をクリックします。

RUEIで使用するためのOAMサーバーの構成手順は、Oracle Real User Experienceインストレーション・ガイドに記載されています。

OAMベース・トラフィックのレポート

データ・ブラウザでのユーザーIDのレポートは、識別名(DN)に基づいています。例を図11-1に示します。

図11-1 OAMトラフィックのレポートの例

11.2 シングル・サインオン(SSO)プロファイルの定義

シングル・サインオン(SSO)とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。SSOには次の利点があります。

- ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。

- 同じIDに対するパスワードの再入力に要する時間を省きます。

- ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。

SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。

SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。このためには、SSOプロファイルを作成します。

11.2.1 SSO対応トラフィックの監視方法の概要

SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。図11-2に、アプリケーション認証がSSOサーバーで有効化されている場合に機能する仕組みを示します。

図11-2 SSO対応アプリケーション・トラフィック内の認証フロー

図11-2に示す認証フローは、次の順序を取ります。

1. ユーザーが、保護されたURLへのアクセスを試行します。アプリケーション・サーバーが、リクエストされたアプリケーションの認証Cookieが存在するかどうかをチェックします。Cookieが見つかった場合は、ユーザーがすでにログオンしていることを意味し、追加認証は不要です。

2. ユーザーは、アプリケーション・サーバーによってSSOサーバーにリダイレクトされます。また、アプリケーション・サーバーは、アプリケーションURLをSSOサーバーに提供し、SSOサーバーがユーザー・ログオン後の移動先を把握できるようにします。SSOサーバーは、既存の認証Cookieを検証することで、ユーザーが(別のアプリケーションによって)認証済かどうかもチェックすることに注意してください。

3. ユーザーが既存の認証Cookieに基づいて認識されない場合、SSOサーバーは、ログイン・ページでユーザーの資格証明を要求します。資格証明は、ユーザーによってユーザー名とパスワードの組合せで指定されます。

4. ユーザーの資格証明が、SSOサーバー・データベース内の対応するエントリと照合されます。検証されると、SSO Cookieによって認証が維持されます。このCookieの名前は、SSOプロファイルの作成時に指定する必要があります。

5. SSOサーバーが、ユーザーの属性をフェッチします。実際にフェッチされる属性は実装固有であり、RUEIには無関係です。

6. SSOサーバーが、手順2で提供されたURLを使用して、フェッチされた属性をパートナ・アプリケーション・サーバーに渡します。トークン引数がこのURLに追加されることに注意してください。このトークン引数の名前は、SSOプロファイルの作成時に指定する必要があります。アプリケーション・サーバーは、通常、ユーザーへの独自のCookieの発行も行います。これは、アプリケーションまたはスイートの定義中に構成されます。

最後に、手順1、2および5で使用されるネットワーク回線は、RUEIの監視対象トラフィックの有効範囲内である必要があることに注意してください。

SSOプロファイルとSSOアプリケーション

SSOプロファイルとSSOアプリケーションは、密接に関連していますが、RUEI内では独立したエンティティとしてレポートされることを理解しておく必要があります。このため、SSOプロファイルとSSOアプリケーションの定義は、相互排他的にする必要があります。つまり、それぞれが独自のドメインおよびCookieに基づく必要があります。こうしておかないと、監視対象トラフィックはアプリケーション関連トラフィックとしてレポートされ、拡張レポート作成による利点は得られません。

11.2.2 SSOプロファイルの作成

SSOプロファイルを定義する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「シングル・サインオン」の順に選択し、「新規SSOプロファイル」をクリックします。図11-3に示すダイアログが表示されます。

図11-3 新規シングル・サインオンダイアログ

2. SSOプロファイルの名前を指定します。これは、スイート、サービス、アプリケーションおよびSSOプロファイルを通じて一意である必要があります。SSOプロファイルの名前は後から変更できないため、注意してください。

3. 残りのフィールドを使用して、SSOプロファイルの有効範囲を指定します。有効範囲はページURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。

注意:
SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。こうしておかないと、予期しない結果がもたらされる可能性があります。一致規則の適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、SSOプロファイルは関連付けられないことに注意してください。指定できるポート番号は1つのみです。追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。

ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。フィルタの適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

次に、「次へ」をクリックします。図11-4に示すダイアログが表示されます。

図11-4 シングル・サインオン・サーバー情報ダイアログ

4. このダイアログを使用し、使用しているSSO認証サーバーに関する情報を指定します。セッションCookie名、認証トークンを含んでいるURL引数、および監視対象トラフィックでのユーザーの識別方法を指定する必要があります。これは通常、URL引数と値を使用して定義します。ただし、Cookie、リクエスト・ヘッダーまたはレスポンス・ヘッダーあるいはXPath式で指定することもできます。
次に、「終了」をクリックします。指定したSSOプロファイル定義の概要が表示されます。例を図11-5に示します。

図11-5 SSOプロファイルの概要

この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。この詳細は次の項に記載されています。

ユーザー識別を定義した結果は、ユーザー情報(XLS形式)レポートの「クライアント」カテゴリで確認できます。レポートの詳細は、第2章「レポートの操作」を参照してください。

11.2.3 SSOプロファイルの変更

SSOプロファイルを定義後に変更するには、その概要を使用します。次のタブがあります。

- 識別: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。新規フィルタを追加するには、「新規フィルタの追加」をクリックします。既存のフィルタを変更するには、そのフィルタをクリックします。図11-6に示すようなダイアログが表示されます。

図11-6 「SSOプロファイル・フィルタの編集」ダイアログ

ダイアログの最下部にあるメモは、現在のルール順序設定スキームを示します。この詳細は、12.9項「RUEI内でのルール順序設定の制御」に記載されています。

- 構成: 使用される認証トークンとCookieを指定します。

- ユーザー: ユーザーIDをアプリケーション内で識別する方法を指定します。これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。

11.2.4 SSO構成の検証

SSO対応アプリケーションの動作およびレポートが正しいかどうかを検証する場合、重要ポイントは、ユーザーIDが正しいかどうかを検査することです。データ・ブラウザ内のレポートを定期的に確認することをお薦めします(「すべてのセッション」→「ユーザーID」→セッションとページ・ビュー)。たとえば、未識別ユーザーの数が予想より多い場合などです。

また、SSO対応アプリケーション内のURLがアプリケーション関連データとしてレポートされていないかどうかも検証する必要があります。レポートされている場合は、問題があることを示している可能性があります。

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

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

12.1 トラフィック・サマリーの表示

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

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

ヒット、ページ、セッション処理、システム・ロードに関する情報を表示する必要があるシステムをクリックしてください。例を図12-2に示します。

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

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

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

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

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

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

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

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

次を実行します。

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

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

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

3. Web環境で使用しているCookieテクノロジを「スキーム・タイプ」メニューから選択します。非標準テクノロジを使用している場合は、(カスタム)を選択し、組織で使用しているCookieの名前を指定します。ワイルドカード文字(*)をCookie名の一部として指定できます。Cookie名では大文字と小文字が区別されることに注意してください。
「XPath(カスタム)」オプションは、リクエストまたはレスポンスに適用されたXPath式に基づくセッション・トラッキングであることを指定します。XPath式の使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。「ヘッダー(カスタム)」オプションは、指定されたリクエストまたはレスポンスに基づくセッション・トラッキングであることを示します。

(URL引数)を選択した場合は、組織で使用しているURL引数の名前を指定する必要があります。セッションの追跡でのURL引数の使用方法は、付録B「Cookieの構造」に記載されています。

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

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

次を実行します。

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

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

2. 「セッション・トラッキング・スキームの追加」または既存の定義をクリックします。手順は、前述の手順と同じです。

3. 「セッション・トラッキング・フォールバック」設定の使用方法の詳細は、12.2.2項「代替セッション・トラッキング・メカニズムの指定」に記載されています。

複数の構成されたCookie

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

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

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

重要:

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

12.2.1 JavaScript Cookie生成の実装

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

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

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

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

セッションの追跡のために適切なCookieがない場合は、JavaScriptを使用してクライアント側の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 「セッション・トラッキング・スキームの追加」ダイアログ

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

Cookieの構成の確認

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

1. ブラウザですべてのCookieを消去します。

2. 監視対象のアプリケーションに(再)ログインします。

3. いくつかのページ表示を実行します。

4. 監視対象のアプリケーションからログアウトします。

5. 少なくとも10分間待機します。

6. RUEIレポータ環境を開き、「データの参照」を選択し、「すべてのセッション」グループを開いて「セッション診断」を選択します。記録されたセッション(ユーザーID別または時間別)を探します。アプリケーションについてフィルタリングできます。

7. セッションを開き、ログイン・ページ以外にページ・ビューがあることを確認します。これで、セッションIDがログイン後に保存されていることが確認されます。

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

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

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

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

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

2. 「トラッキング・メカニズム」メニューを使用して、クライアント・ネットワークとブラウザの組合せを使用する(デフォルト)かクライアントIPアドレスを使用するかを指定します。
次に、「保存」をクリックします。行った変更は、即座に有効になります。

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

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

- すべてのユーザーに一意のIPアドレスがある場合。アプリケーションごとに、クライアントIPアドレスをTCPパケットから取得するか、特定のHTTPリクエスト・ヘッダーから取得するかを指定できることに注意してください。この詳細は、付録Q「NATトラフィックの監視」に記載されています。

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

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

重要:
ネットワーク・トラフィックの正確なレポートのため、Webサイトで使用するCookieテクノロジを正確に指定することを強くお薦めします。
また、ビジター・セッションの追跡に指定するCookieがブラインディングされないようにしてください。ブラインディングが行われると、Cookieに基づくセッション作成が失敗します。

12.3 名前付き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アドレスを取得するソースを階層として指定することができます。グループおよびサーバー名には、類似のソース・スキームを指定することもできます。これらのスキームから値が生成されないときに使用する代替識別情報も定義できます。

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

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

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

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

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

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

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

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

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

3. 「ソース・タイプ」と「ソース値」のフィールドを使用して、選択した項目に使用する識別スキームを指定します。表12-1に、使用可能なオプションを示します。次に、「保存」をクリックします。

表12-1 識別オプション

オプション

説明

リクエストのヘッダー

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

レスポンスのヘッダー

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

Cookie

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

SSLクライアント証明書名

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

リテラル値

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

4. ルーリング機能を作成すると、それを使用して、新規作成する定義を調整する追加の一致ルールを指定できます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。

5. サーバーの識別情報として定義されるソースは、リストに出現する順序で評価される点に注意してください。必要な場合は、項目のコンテキスト・メニューで「上に移動」と「下に移動」のオプションを使用して、リストでの位置を変更できます。

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

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

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

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

2. ネットマスクで限定した一連のIPアドレス(または特定のIPアドレス)および関連するWebサーバーとグループ名を指定します。次に、「保存」をクリックします。

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

代替識別のリストのアップロード

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

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

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

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

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

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

2. このダイアログ内のフィールドを使用して、ネットマスクで限定した一連のIPアドレスまたは単一のIPアドレス、クライアントおよび関連するグループ(たとえば会社の部門)を指定します。次に、「保存」をクリックします。

重要:

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

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

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

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

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

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

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

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

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

次を実行します。

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

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

2. オブジェクトまたは関数コールが遅いと判断されるまでに必要なエンドツーエンド時間(ミリ秒単位)を指定します。次に、「保存」をクリックします。

12.6 失敗したURLヒットの無視

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

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

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

2. 失敗したURLビュー内で無視する必要のあるファイル名を指定します。つまり、これらがエラーとして表示されないようにします。ファイル名定義内のディレクトリ情報はすべて無視され、定義されたファイルはリストされたオブジェクトURLからも削除されます。無視する必要のあるファイル名を新たに定義するには、「追加」をクリックします。また、定義されたファイルの右側にある「削除」 アイコンをクリックすると、無視するファイルのリストからそれが削除されます。
インストール時に、2つのデフォルト・ファイル(robots.txtおよびfavicon.ico)が自動的に構成されます。次に、「保存」をクリックします。この設定への変更は10分後に適用されます。この少し後に、指定した変更がレポータ・インタフェースに表示されます。

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

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

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

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

2. 「引数フィルタ」メニューを使用して適切なフィルタを選択します。デフォルトは「すべて許可」です。つまり、引数がすべて記録されます。次に、「次へ」をクリックします。

3. 「一部を許可」フィルタを選択した場合は、続くダイアログで、どの引数を記録するかを指定する必要があります。複数ある引数はアンパサンド(&)記号で区切ります。次に、「次へ」をクリックします。

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

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

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

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

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

重要:
この設定は、システムのパフォーマンスおよびレポートされるデータの精度に影響することがあるため、Oracleサポート・サービスのアドバイスを受けた場合のみ変更することを強くお薦めします。

セッション設定の指定

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

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

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

2. ビジターが非アクティブになってからセッションが終了したとみなされるまでの時間(分)を指定します。デフォルトは60分です。次に、「保存」をクリックします。

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

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

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

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

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

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

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

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

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

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

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

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使用率」タブ

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

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

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

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

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

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

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

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

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

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

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

2. 目的の設定を選択します。
図12-20に示すようなダイアログが表示されます。

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

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

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

次に、「保存」をクリックします。ディスク領域割当ての変更は約10分で有効になりますが、データベース割当ての変更は午前0時を過ぎるまで有効にならないことに注意してください。

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

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

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

必要な月数の計算

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

コレクタのデータ保存ポリシーの構成は、13.9項「コレクタのデータ保存ポリシーの定義」に記載されています。

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

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

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

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

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

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

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

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

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

オプション

説明

有効

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

無効

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

指定済

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

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

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

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

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

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

2. 選択したアイテムをレポートする場合の小数点以下の桁数を指定します。次に、「保存」をクリックします。これらの設定は変更すると即座に有効になります。

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

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

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

KPIしきい値プロファイルを定義する手順は、次のとおりです。

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

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

2. しきい値プロファイルの「名前」を指定します。

3. 次のうちから「タイプ」を選択します。

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

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

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

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

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

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

6. しきい値プロファイルの「説明」を入力し、「保存」をクリックします。

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

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

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

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

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

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

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

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

2. ダイアログのフィールドを使用して、事前定義済のIPアドレスの場所に対する例外を指定します。次に、「保存」をクリックします。

重要:

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

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

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

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

フィールド

要件

IPアドレス

カンマ区切りの4つのフィールドで構成されます。各フィールドは、0から255の整数です。

サブネット・マスク

カンマ区切りの4つのフィールドで構成されます。各フィールドは、0から255の整数です。ただし、0から255の範囲でも有効ではない数があります。

国番号

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

http://www.maxmind.com/app/iso3166

地域コード

MaxMindデータベース(http://www.maxmind.com)で地域の識別に使用されているコードです。countrycode-regioncodeという形式です。countrycodeは必ず、国コードで指定されているのと同じISO 3166-1の2文字コードです。米国とカナダのIPアドレスの場合、regioncodeにはISO 3166-2の州コードを指定する必要があります。他の地域の場合、FIPS 10-4の地域コードを指定します。たとえば、「US-TX」(テキサス州)、「CH-25」(チューリッヒ)などです。サポートされている地域コードの完全なリストは、次の場所からダウンロードできます。

http://www.maxmind.com/app/fips10_4

市区町村名

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

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

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 「強制オブジェクト」ダイアログ

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

定義された強制オブジェクトのファイル拡張子のリストの変更はすぐに有効になるので注意してください。

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

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

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

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

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

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

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

4. 「上に移動」および「下に移動」アイコンを使用して、リストの項目の順序を制御します。ユーザー・エージェントの一致はリスト内での出現順に行われることに注意してください。

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

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

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

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

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

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

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

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

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

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

2. トラフィックを監視しないクライアントのIPアドレスを指定します。CIDR形式で指定する必要があることに注意してください。各アドレスで、「追加」をクリックします。次に、「保存」をクリックします。

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

http://tools.ietf.org/html/rfc4632

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

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

4. リストに追加するヘッダーの名前=値ペアを指定します。それぞれのペアで、「追加」をクリックします。次に、「保存」をクリックします。

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

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

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

- ページ・ブラウザ時間は、最後のページ・オブジェクトが配信されてから、クライアント側のインストゥルメンテーションによりレポートされたページ・ブラウザの完了時間までの経過時間です。クライアント側のインストゥルメンテーションは、ブラウザJSライブラリによって定義されます(8.3.1項「ブラウザJSライブラリ設定の定義」を参照)。
この期間は、WebページにJavaScriptコードが大量または複雑に含まれている場合や、Flashなどのブラウザ・プラグインが実行されている場合には非常に長くなることがあります。すべての主要なブラウザでは、ページの可用性はonLoadイベントの実行によって示されます。図12-33を参照してください。

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

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

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

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

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

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

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

ブラウザJSライブラリの定義の詳細は、8.3.1項「ブラウザJSライブラリ設定の定義」に記載されています。

13 セキュリティ関連情報の管理

この章では、トラフィックの監視のためにRUEIで使用されるコレクタ・プロファイルの使用方法およびセキュリティ関連設定の構成方法について説明します。また、ネットワーク・フィルタを設定して、特定のネットワーク、ホスト、仮想Local Area Network(VLAN)が取得されないようにしたり、監視対象トラフィック全体を減らす方法についても説明します。機密データのセキュリティを維持するために、HTTPプロトコル・アイテム(HTTPヘッダー、Cookieなど)のマスキング・アクションを指定することもできます。また、暗号化で保護されたトラフィックを処理するWebサーバーの秘密鍵の管理についても説明します。

すべてのセキュリティ関連情報の管理は、セキュリティ担当者が担当します。

13.1 コレクタ・プロファイルの管理

コレクタの管理を容易にするため、各コレクタは1つのコレクタ・プロファイルに割り当てられます。コレクタ・プロファイルの構成が変更された場合、それらは割当て済のすべてのコレクタに自動的に適用されます。

インストール時に、次の2つの事前定義済のコレクタ・プロファイルが作成されます。

- システム・ネットワーク・データ・コレクタ(ネットワーク・ベースのデータ収集の場合)

- システム・タグ・サーバー(タグ・ベースのデータ収集の場合)

レポート要件に応じて追加のプロファイルを作成するには、既存のプロファイルをコピーして、それを新規プロファイルのベースとして使用します。ユーザー定義のコレクタ・プロファイルとは異なり、Systemコレクタ・プロファイルは削除できないことに注意してください。

現在使用可能なコレクタ・プロファイルを表示するには、「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。例を図13-1に示します。

図13-1 コレクタ・プロファイル・パネル

各コレクタ・プロファイルでは、表13-1に示すオプションをコンテキスト・メニューで使用できます。

表13-1 コレクタ・プロファイルのコンテキスト・メニュー

オプション

説明

構成

選択したプロファイルに割り当てられているすべてのコレクタの構成を指定できます。それには、ネットワーク・フィルタ、コレクタでリスニングするTCPポート、およびセキュリティで保護されたトラフィックの復号化に使用する秘密鍵の使用が含まれます。この詳細は、13.1.2項「コレクタ・プロファイルの構成の変更」に記載されています。プロファイルの構成を変更した後に、プロファイルに割り当てられているコレクタを自動的に再起動するか、または手動による再起動を要求するメッセージを表示するかを指定できます。この詳細は、13.1.6項「コレクタの再起動」に記載されています。

コピー

選択したコレクタ・プロファイルを新規プロファイルのベースとして使用します。この詳細は、13.1.1項「コレクタ・プロファイルの作成」に記載されています。

プロパティの編集

コレクタ・プロファイルの名前および簡単な説明を変更できます。デフォルトのコレクタ・プロファイルのプロパティは変更できないことに注意してください。

削除

選択したコレクタ・プロファイルを削除します。選択したプロファイルにコレクタが割り当てられている場合、それらは自動的にデフォルトの(System)コレクタ・プロファイルに再割り当てされることに注意してください。デフォルトのコレクタ・プロファイルは削除できません。

13.1.1 コレクタ・プロファイルの作成

新規コレクタ・プロファイルを作成する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。現時点で定義されているコレクタ・プロファイルが表示されます。例を図13-1に示します。

2. 新規プロファイルのベースとして使用するコレクタ・プロファイルのコンテキスト・メニューで「コピー」を選択します。図13-2に示すダイアログが表示されます。

図13-2 「コレクタ・プロファイルのコピー」ダイアログ

3. 新規コレクタ・プロファイルに一意の名前および必要に応じて簡単な説明を指定します。この説明にはプロファイルの目的と有効範囲を示すことをお薦めします。次に、「保存」をクリックします。新規プロファイルが作成されると、使用可能なコレクタ・プロファイルのリストに表示されます(図13-1)。

4. 新規コレクタ・プロファイルを監視要件に応じて構成します。この詳細は、13.1.2項「コレクタ・プロファイルの構成の変更」に記載されています。

13.1.2 コレクタ・プロファイルの構成の変更

作成された新規プロファイルの構成は、ベースとなるプロファイルと同じです。その構成を要件に応じて変更する手順は、次のとおりです。

1. 使用可能なコレクタ・プロファイルのリスト(図13-1)から目的のプロファイルをクリックするか、コンテキスト・メニューで「構成」を選択します。ウィンドウが開き、選択したプロファイルに現在割り当てられているコレクタが表示されます。例を図13-3に示します。

図13-3 「ネットワーク・データ・コレクタ・ステータス」ウィンドウ

2. 「構成」メニュー→「構成」の順に選択して、コレクタ・プロファイルの構成を変更します。表13-2に示すオプションがあります。

表13-2 コレクタ・プロファイルの「構成」のオプション

オプション

説明

プロトコル

プロファイルに割り当てられているコレクタでリスニングするTCPポートを指定するには、このオプションを選択します。これについては、13.3項「ネットワーク・ベース監視の有効範囲の管理」で説明します。

ネットワーク・フィルタ

プロファイルに割り当てられているコレクタの監視対象をネットワーク・トラフィックの特定のセグメントに制限するか、または特定のサーバーやサブネットに制限するかを指定するには、このオプションを選択します。この詳細は、13.4項「ネットワーク・フィルタの定義」に記載されています。

SSL鍵

暗号化されたコンテンツを監視するため、プロファイルに割り当てられている各コレクタにインポートする証明書を指定するには、このオプションを選択します。この詳細は、13.5項「SSL鍵の管理」に記載されています。

コレクタ再起動メソッド

構成を変更した後で、プロファイルに割り当てられているコレクタを自動的に再起動するかどうか指定するには、このオプションを選択します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。

13.1.3 別のプロファイルへのコレクタの割当て

プロファイルに割り当てられているコレクタは、レポート要件に応じて別のコレクタに簡単に再割り当てできます。たとえば、ネットワーク・トラフィックのパターンまたはセキュリティ要件が変更された場合などです。コレクタを再割り当てする手順は、次のとおりです。

1. コレクタの現在の割当て先であるプロファイルを選択します。図13-3に示すようなウィンドウが表示されます。

2. コレクタのコンテキスト・メニューで「プロファイルの割当て」オプションを選択します。図13-4に示すダイアログが表示されます。

図13-4 「コレクタ・プロファイルの割当て」ダイアログ

3. コレクタの新しい割当て先となるプロファイルを選択します。次に、「保存」をクリックします。

4. 選択したプロファイルにコレクタが割り当てられると、図13-5に示すステータス・メッセージが表示されます。

図13-5 移動したコレクタのステータス・メッセージ

このステータス・メッセージは最大で60秒間表示されます。その後、コレクタが自動的に再起動されるか、手動による再起動を要求するメッセージが表示されます。詳細は、13.1.6項「コレクタの再起動」を参照してください。

重要:
新規プロファイルのセグメンテーション・スキームが以前のプロファイルと異なる場合、新規プロファイルと一貫性が保たれるようにコレクタのセグメンテーション・スキームが調整されることに注意してください。したがって、トラフィック・フィルタの設定を新規プロファイルに割り当てた後で確認することを強くお薦めします。詳細は、13.4.3項「全体のトラフィックの制限」を参照してください。

複数のコレクタの割当て

異なるプロファイルに複数のコレクタを割り当てる場合は、「構成」メニューの複数選択オプションを使用できます。目的のコレクタをクリックしてから、ツールバーの「プロファイルの割当て」コマンド・ボタンをクリックします。

13.1.4 インタフェースへのコレクタの割当て

コレクタは、ネットワーク・ベースにもタグ・ベースにもでき、別のインタフェースに関連付けることができます。コレクタをインタフェースに割り当てる手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。現時点で定義されているコレクタ・プロファイルが表示されます。例を図13-1に示します。

2. 変更するコレクタに移動します。図13-3に示すようなウィンドウが表示されます。変更するコレクタを右クリックします。

3. コレクタのコンテキスト・メニューから「ネットワーク・インタフェースの割当て」オプションを選択します。図13-4に示すダイアログが表示されます。

図13-6 コレクタ・ネットワーク・インタフェース

4. タグ・ベースの収集の場合、「IPありのインタフェース」を割り当てる必要があります。ネットワーク・ベースの収集の場合、「IPなしのインタフェース」を割り当てる必要があります。あるいは、「指定されたインタフェース」を選択して、すべてのインタフェースを表示し、個々に選択します。次に、「保存」をクリックします。

13.1.5 新規コレクタの登録

新規コレクタをシステムに登録する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。現時点で定義されているコレクタ・プロファイルがリストされます。例を図13-1に示します。

2. 新規リモート・コレクタを登録するプロファイルを選択します。または、コンテキスト・メニューで「構成」を選択します。選択したプロファイルに現在割り当てられているコレクタがリストされます。例を図13-3に示します。

3. 「構成」メニューで「リモート・コレクタの登録」オプションを選択します。図13-7に示すダイアログが表示されます。

図13-7 「コレクタの登録」ダイアログ

4. 新規コレクタ・システムのIPアドレスおよび必要に応じて簡単な説明を指定します。これには、その有効範囲と目的を示すことをお薦めします。次に、「登録」をクリックします。コレクタ・システムの構成要件は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。

13.1.6 コレクタの再起動

コレクタ・プロファイルでなんらかの構成を変更した場合、変更を有効にするには、そのプロファイルに割り当てられているすべてのコレクタを再起動する必要があります。この再起動は自動(デフォルト)または手動のいずれかで実行できます。コレクタの再起動の方法を構成する手順は、次のとおりです。

1. 使用可能なコレクタ・プロファイルのリスト(図13-1)から目的のプロファイルをクリックするか、コンテキスト・メニューで「構成」を選択します。ウィンドウが開き、選択したプロファイルに現在割り当てられているコレクタが表示されます。例を図13-3に示します。

2. 「構成」メニュー→「構成」→「コレクタ再起動メソッド」の順に選択します。図13-8に示すダイアログが表示されます。

図13-8 「コレクタ再起動メソッドの編集」ダイアログ

3. 「再起動メソッド」メニューを使用して、選択したプロファイルに割り当てられているコレクタを、プロファイルの構成を変更した後で自動的に再起動(デフォルト)するか、または手動による再起動を要求するかを指定します。次に、「保存」をクリックします。

コレクタの手動による再起動

「ネットワーク・データ・コレクタの構成」ウィンドウに再起動を要求するメッセージが表示されるまで、コレクタは再起動できません。例を図13-9に示します。

図13-9 再起動を待機中のコレクタ

個々のコレクタを再起動するには、コンテキスト・メニューで「再起動」を選択します。コレクタ・プロファイルに多数のコレクタが含まれている場合は、「構成」メニューの「すべてのコレクタの再起動」オプションを使用した方が便利です。

13.1.7 コレクタの無効化および登録解除

リモート・コレクタ・システムでメンテナンスまたはトラブルシューティングを実行するときは、コレクタ・インスタンスを停止する必要が生じる可能性があります。この場合は、コレクタのコンテキスト・メニューで「無効化」を選択します。次に、「再起動」オプションを選択すると、コレクタに監視を再開するように指示できます。

リモート・コレクタ・システムが廃止された場合は、インストール済RUEIからそれを削除する必要があります。それには、コレクタのコンテキスト・メニューで「登録解除」オプションを選択します。確認後に、レポータのコレクタ・システムへの接続が中止されます。ローカル・コレクタ・インスタンスは登録解除できないことに注意してください。

ローカル・コレクタ

レポータ・システムのローカル・コレクタ・インスタンスは、System(localhost)項目で表します。インストール後はまだ有効化されておらず、現在定義されているすべてのコレクタ・プロファイルに表示されることに注意してください。特定のプロファイルで有効になると、選択したコレクタ・プロファイルのみで表示されます。ローカル・コネクタ・インスタンスは登録解除できません。

13.2 処理エンジンの管理

単一システムの能力を超えて処理を拡大するために、通常はレポータによって実行されるデータ処理を負担するように1つ以上の処理エンジンを構成することができます。

処理エンジンの登録

RUEIのデプロイメントに処理エンジンを追加するには、次の手順を実行します。

1. 処理エンジンのインストールおよび構成手順がターゲット・システムで完了していることを確認してください。詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。

2. 「構成」、「セキュリティ」、「処理エンジン」の順に選択します。現時点で登録されている処理エンジンがリストされます。例を図13-10に示します。

図13-10 「処理エンジン」ウィンドウ

3. 「登録」をクリックします。図13-11に示すダイアログが表示されます。

図13-11 「処理エンジンの登録」ダイアログ

4. 処理エンジン・システムのホスト名またはIPアドレスと、データベース・リンク名を指定します。次に、「保存」をクリックします。データベース・リンク名は、ホスト名を含んでいる必要があり、Oracleの命名規則に準拠している必要があります。たとえば、空白を含むことはできず、数字またはアンダースコアで開始することはできません。詳細は、次のサイトで入手可能な『Oracle Database管理者ガイド』を参照してください。

http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/ds_admin.htm#ADMIN029

5. 新しく登録した処理エンジンは、「なし」モードで図13-10に示すリストに表示されます。これは、まだ初期化されていないためにレポータで使用できないことを示しています。「処理エンジン」の「モード」設定をクリックします。図13-12に示すダイアログが表示されます。

図13-12 処理エンジン・モード

6. 「モード」メニューから「有効」を選択します。次に、「保存」をクリックします。短い期間の後、図13-10に示すウィンドウに戻ります。

処理エンジンの無効化

システムのメンテナンス(パッチのインストールなど)を実行するため、処理エンジンを一時的に無効にできます。処理エンジンを無効にする場合、次の点に注意してください。

- 処理エンジンを長期間無効にすると、短期間のデータが失われる場合があります。

- 無効になった処理エンジンで通常実行される処理は、残りの有効な処理エンジンに自動的に再分散されます。すべての処理エンジンを無効にすると、処理がレポータ・システムに戻ります。

処理エンジンの削除

処理エンジンを削除すると、関連するすべての情報(データベース・リンクなど)がRUEIデプロイメントからパージされます。ただし、処理エンジン・データベース内の情報は保存されます。このため、以前に削除した処理エンジン・システムを再登録する場合、データベース内のデータをレポータで引き続き使用できます。

13.3 ネットワーク・ベース監視の有効範囲の管理

RUEI内で、ネットワーク・データ・ベースの収集に対して監視対象のTCPポートを指定して、トラフィック監視の有効範囲を制御します。監視対象外のポートについての情報は表示されません。監視対象および監視対象外のTCPポート(HTTPおよびHTTPSの両方)の選択について、注意深く確認することをお薦めします。

現在監視対象であるポートを表示するには、「構成」→「セキュリティ」→「プロトコル」の順に選択します。例を図13-13に示します。

図13-13 監視対象のポート

この設定を変更する手順は、次のとおりです。

1. 「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。

2. ポート設定を変更するプロトコルをクリックします。表13-3に使用可能な設定を示します。

表13-3 プロトコル設定

プロトコル

説明

HTTP/Formsサーブレット・モード

プロファイルのコレクタがFormsサーブレット・トラフィックをリスニングするポートを指定します。このオプションはEBSベース・トラフィック専用です(付録N「Oracle FormsおよびOracle E-Business Suiteのサポート」を参照)。

Formsソケット・モード

プロファイルのコレクタがソケット・モードのFormsトラフィックをリスニングするポートを指定します。このオプションはEBSベース・トラフィック専用です(付録N「Oracle FormsおよびOracle E-Business Suiteのサポート」を参照)。

HTTP

プロファイルのコレクタがHTTPトラフィックをリスニングするポートを指定します。この設定は「純粋な」HTTPトラフィックに対してのみ使用してください。

HTTPSプロキシ

SSLトラフィックの送信先のプロキシ・サーバーのポート番号を指定します。次の点に注意してください。

- SSL以外のトラフィックのみがプロキシ・ポートに送信される場合、この設定でそのポート番号を指定しないでください。指定すると、コレクタのパフォーマンスに大きな影響を与えることがあります。

- SSLトラフィックを受信するサーバー(プロキシの後ろ)のポート番号は、HTTPS設定で指定する必要があります。

HTTPS

プロファイルのコレクタがHTTPSトラフィックをリスニングするポートを指定します。インストール時には、デフォルトの監視対象ポートとしてHTTPSポート443が定義されます。

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

図13-14 「コレクタ・ポートの編集」ダイアログ

3. 新規ポート番号またはポートの範囲(80-85など)を追加するには、「ポート番号」フィールドに必要な番号を入力し、「追加」をクリックします。リストからアイテムを削除するには、ポートの右側にある「削除」アイコンをクリックします。次に、「保存」をクリックします。

重要:
各プロトコルに指定するポート番号はコレクタ・プロファイル内で重複しないようにしてください。つまり、1つのポート番号は、1つのプロトコルの割当てポート番号リストのみに指定する必要があります。

4. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。

13.4 ネットワーク・フィルタの定義

ポート番号の他に、ネットワーク・フィルタを使用しても、監視するトラフィックの有効範囲を管理できます。また、監視対象を特定のサーバーやサブネットに制限したり、パケットの取得レベルを制限できます。

ネットワーク・フィルタを定義または変更する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「ネットワーク・フィルタ」の順に選択します。

2. 「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。現時点で定義されているネットワーク・フィルタが表示されます。例を図13-15に示します。

図13-15 「ネットワーク・フィルタ」パネル

3. 次の項で説明しているフィルタを使用して、監視対象トラフィックの有効範囲を管理します。

4. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。

ネットワーク・フィルタの適用の理解

ネットワーク・トラフィックは、定義されているフィルタの総合的な処理に基づいて監視されています。たとえば、定義されているすべてのポート番号でトラフィックが監視されます。同様に、定義されているネットワーク・フィルタ(サーバーIPアドレス範囲など)もすべて監視されています。このルールには1つだけ例外があり、それがVLANフィルタの使用です。有効にすると、指定したVLAN IDを持つVLANトラフィックのみが監視されます。これを有効にしてVLAN IDを指定しない場合は、すべてのVLANトラフィックが監視されます。

13.4.1 サーバーIPアドレス・フィルタの定義

フィルタを定義すると、監視対象の有効範囲を特定のサーバーやサブネットに制限できます。この機能は、コレクタ・プロファイルにコレクタが1つ以上割り当てられている場合にのみ使用できることに注意してください。次を実行します。

1. 「新規フィルタの追加」をクリックして新しいフィルタを定義するか、または既存のフィルタをクリックして変更します。図13-16に示すダイアログが表示されます。

図13-16 「ネットワーク・フィルタの追加」ダイアログ

2. 「サーバーIPアドレス」と「ネットマスク」フィールドを使用して、コレクタでリスニングするアドレスを指定します。これは、ネットワーク・スペシャリストに相談した上で行うことをお薦めします。次に、「保存」をクリックします。

13.4.2 VLANフィルタの定義

VLANフィルタを使用すると、監視対象トラフィックを特定のサーバーおよびサブネットに限定できます。VLANフィルタを定義する手順は、次のとおりです。

1. 図13-15に表示されている「VLANフィルタ」の現在の設定をクリックします。図13-17に示すダイアログが表示されます。

図13-17 「VLANフィルタの構成」ダイアログ

2. フィルタ・モードメニューを使用して、VLANフィルタを有効化する必要があるかどうかを指定します。デフォルトでは、VLANトラフィックが監視されません。このフィルタを有効化すると、VLANトラフィックのみが監視されることに注意してください。

3. 必要に応じて、VLAN IDフィールドを使用して、フィルタの基準とする特定のVLANを指定します。次に、「保存」をクリックします。

13.4.3 全体のトラフィックの制限

ネットワークおよびVLANフィルタを使用できる以外にも、他のフィルタが適用された後に残るトラフィック全体のどの程度を実際に監視するかも指定できます。デフォルトでは、残るすべてのトラフィックが監視されます。

トラフィック全体の監視レベルを指定する手順は、次のとおりです。

1. 図13-15に表示されている「トラフィック・フィルタ」の現在の設定をクリックします。図13-18に示すダイアログが表示されます。

図13-18 「トラフィック全体の制限」ダイアログ

2. 「スキームをフィルタリング中」メニューを使用して、物理IPアドレスと機能IPアドレスのどちらに基づいてネットワーク・トラフィックのフィルタリングを行うかを指定します。
デフォルトでは、ネットワーク・トラフィックのフィルタリングは物理IPアドレスに基づいて行われます。つまり、IPアドレスがIPパケットから取得されます。ただし、コレクタがCDNデバイスまたはプロキシ・サーバーの後ろにインストールされている場合は、機能IPアドレスに基づいたフィルタリングをお薦めします。この場合は、次の点に注意する必要があります。

- 機能IPアドレスが使用できない場合は、IPパケットから取得されたIPアドレスがかわりに使用されます。

- ネットワーク・フィルタリングで構成済のクライアントIPヘッダーを使用すると、かなりの処理オーバーヘッドがコレクタで発生します。監視対象のトラフィックでSSL暗号化が使用されている場合は特に増加します。物理アドレスのフィルタリングはTCPレベルで実行できるのに対して、機能IPアドレスのフィルタリングは通常はHTTPレベルで実行する必要があるためです。

3. 「パケット取得」メニューを使用して、プロファイルのコレクタで監視する必要のあるトラフィックの一部を指定します。表13-4に使用可能なオプションを示します。

表13-4 パケット取得スキーム

オプション

説明

すべてのトラフィック

他のフィルタが適用された後に残るすべてのトラフィックを監視するように指定します。これがデフォルトです。

指定されたドメイン

アプリケーション、スイートおよびサービスの定義で明示的に指定されたドメインのみに監視対象を制限するように指定します。

トラフィック・サンプリング

トラフィックの一部のみを監視対象とすること、およびその割合を指定します。たとえば、オプション「トラフィックの1/4 - パート4」では、選択したプロファイル内の各コレクタがネットワーク・トラフィックの最後の1/4のみを監視するよう指定します。

ロード・バランシング

パケット・ストリームの監視をコレクタ・プロファイル内の複数のコレクタ全体に分散させ、各コレクタがストリームの一部を受け取るように指定します。2-16コレクタでこの設定がサポートされています。

- 自動: 各コレクタには、プロファイル定義における順位に基づいて、トラフィックの一部が監視対象として割り当てられます。たとえば、8番目の割当て済コレクタは、直近の8番目のトラフィックを監視することになります。

- 手動: 監視対象とするトラフィックの一部および割合をコレクタごとに指定できます。

このオプションは、コレクタ・プロファイルにコレクタが1つ以上割り当てられている場合にのみ使用できます。

次に、「保存」をクリックします。

4. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。

トラフィックの監視

前述の設定では、合計ネットワーク・トラフィックの何分の1を測定するかを指定しています。したがって、トラフィックの1/2を監視対象とするよう指定した場合は、監視対象の1/2のみがレポートされます。100%未満の設定を使用する場合、レポートされる情報は実際のトラフィック全体ではなく選択したサンプルを反映していることを忘れないようにしてください。

トラフィックの監視はIPアドレスに基づいて行われます。このことは、使用する設定に関係なく、すべてのユーザー・セッションが記録されることを意味します。ただし、これらのセッションの数は選択した設定によって決まります。

13.4.4 ロード・バランシングおよびトラフィック・サンプリング定義の確認

ロード・バランシングおよびトラフィック・サンプリング定義によってネットワーク・トラフィックの正しくない監視が生じる可能性があることを理解してください。たとえば、選択したプロファイルに16個のコレクタが割り当てられていない場合に、ロード・バランシング部「16で分割されたすべてのトラフィック」を選択できます。同様に、トラフィック・サンプリング部「トラフィックの1/8 - パート1」を選択して、選択したプロファイルに8個のコレクタを割り当て、それぞれでネットワーク・トラフィックの同じ部分を監視できます。このため、次の点を確認する必要があります。

- RUEIデプロイメントがネットワーク・インフラストラクチャ内の異なる監視ポイントに接続されるコレクタを取り込む場合は、トラフィック・サンプリングのみ指定されます。

- ロード・バランシングを使用する場合、選択したオプションがプロファイルに割り当てられるコレクタの数と一致する必要があります。

重要:
ネットワーク・インフラストラクチャの完全な知識を持つユーザーがネットワーク・フィルタ定義を確認することを強くお薦めします。

プロファイルのコレクタの追加および削除

プロファイルのコレクタを追加または削除する場合にネットワーク・フィルタ定義は自動的に更新されず、そのような変更によってネットワーク・トラフィックが欠落または何度も処理される場合に警告は生成されないので注意してください。このため、コレクタ・プロファイル設定を変更した後、ネットワーク・フィルタ定義を注意して確認する必要があります。

13.5 SSL鍵の管理

暗号化データ(HTTPSやSSLなど)を監視するようRUEIを構成できます。この構成を行うには、WebサーバーのSSL秘密鍵のコピーをRUEIにインポートする必要があります。暗号化されたコンテンツを監視するための証明書をインポートする手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「SSLキー」→「SSLキー管理」の順に選択します。「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。現時点でインストール済の鍵のリストが表示されます。例を図13-19に示します。

図13-19 SSL鍵のステータス

2. 「新規キーの追加」をクリックして新規の鍵を定義します。既存のSSL鍵の定義は変更できないことに注意してください。図13-20に示すダイアログが表示されます。

図13-20 「SSL鍵の追加」ダイアログ

3. 「キー」フィールドを使用して、鍵を含むファイルを指定します。鍵が暗号化されている場合は、パスフレーズを指定する必要があります。次に、「鍵のインストール」をクリックします。

注意:
PEM、DERまたはPKCS12形式のファイルを指定でき、ファイルには鍵および一致する証明書が含まれている必要があります。鍵はRSA鍵である必要があります。40ビット鍵(DES_40、RS2_4-0、RC4_40など)およびAEAD暗号を使用する暗号化プロトコルはサポートされていないことに注意してください。Camelliaは、Oracle Linux 6.5以上でのみサポートされています。

サポートされる暗号化プロトコルとメカニズム

Message Authentication Code(MAC)では、MD5、SHA-1およびSHA-2機能がサポートされます。暗号化プロトコルSSL v3、TLS v1.0、TLS v1.1およびTLS v1.2がサポートされています。現在サポートされているすべての暗号化アルゴリズムは、「コレクタ統計」ウィンドウの「SSL接続」セクションに表示されます(15.2項「コレクタのステータスの表示」を参照)。

SSLトラフィックの監視

SSLトラフィックおよびOracle Formsトラフィックは両方とも、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。

したがって、各コレクタが信頼性の高いネットワーク・デバイス(TAPなど)に接続されることを確認する必要があります。また、「コレクタ統計」ウィンドウ(15.2項「コレクタのステータスの表示」を参照)に表示される情報を定期的に調べて、TCPパケット・ストリームが正常な状態であることを確認するように強くお薦めします。TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。

秘密鍵の抽出の失敗

秘密鍵のロードに失敗した場合、パスワードが間違っている、証明書が格納されているファイルや秘密鍵の破損などの理由が考えられます。

13.5.1 SSL鍵の削除

インストール済のSSL鍵を削除するには、必要な鍵を右クリックして「削除」を選択します。鍵の削除を確認するように求められます。

13.5.2 鍵の有効期限の監視

オプションで、保留中のSSL鍵の有効期限に関する通知を構成できます。これにより、新規の鍵のインポートを計画でき、新規の鍵を取得してアクティブ化する間に監視対象データにずれが生じることがなくなります。次を実行します。

1. タスクバーにある「キー有効期限の監視」アイコンをクリックします。アイコンが未表示の場合は、「構成」→「セキュリティ」→「SSLキー」→「SSLキー管理」の順に選択します。図13-21に示すダイアログが表示されます。

図13-21 「SSL鍵の有効期限の監視」ダイアログ

2. 有効期限より何日前に通知を生成する必要があるか、その日数を指定します。その他のタブにあるコントロールを使用して、電子メール、SNMPおよびテキスト・メッセージの通知詳細を指定します。これらは7.5.1項「アラート・プロファイル」で説明したダイアログと似ています。次に、「保存」をクリックします。

3. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。

注意:
期限切れのSSL鍵がないかどうかのチェックが、1日に1回6:00AM(レポータ・システム時間)に実行されるようスケジュールされます。

13.6 ユーザー情報のマスキング

RUEIインストールは機密情報をログに記録しないように構成できます。これをマスキングと呼びます。これによって、パスワード、クレジット・カード情報などの機密情報をディスクに記録しないようにできます。

RUEIのセキュリティ機能によって、POST URL引数、HTTPヘッダー、Cookieとその値、Oracle Forms要素およびURLの内容のログを制御できます。

マスキングを実装する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「マスキング」の順に選択し、構成するHTTPプロトコル・アイテムについて適切なオプションを選択します。たとえば、URL POST引数マスキングなどです。図13-22に示すようなウィンドウが表示されます。

図13-22 「URL POST引数マスキング」ウィンドウ

選択したHTTPプロトコル・アイテムについて現時点で定義されているマスキングが表示されます。

2. 既存の項目の「使用中」リストをクリックして、使用状況の情報を表示します。例を図13-23に示します。

図13-23 HTTP項目の使用状況の例のダイアログ

この場合、選択したURL POST引数をアプリケーションのユーザーIDスキームの一部として使用し、RUEIの内部トラフィック検出の一部としても使用することを示します。これらの自動的に検出された項目は、後の項で説明します。

3. 「新規マスキングの追加」をクリックして新規マスキングを定義します。図13-24に示すようなダイアログが表示されます。

図13-24 「POST引数のマスキング・アクションの追加」ダイアログ

4. ログを制御するアイテムの名前を指定します。選択したプロトコル・アイテムに応じて、POST URL引数の名前、Cookie名または値、Oracle Forms要素、HTTPヘッダー内のアイテム、またはURL接頭辞を指定します。

5. 定義するアイテムに割り当てるマスキング・アクションを選択します。表13-5に、URL接頭辞以外のプロトコル・アイテムで使用可能なオプションを説明します。

表13-5 マスキング・アクション

オプション

説明

デフォルト

選択したHTTPプロトコル・アイテムの定義済デフォルト・アクションをこのアイテムに対して実行するように指定します。この機能の使用方法は次の項に記載されています。

ハッシュ済

計算されたハッシュ値でアイテムの内容を置き換えてログに記録するように指定します。ハッシュは比較に使用可能な一意の値であるものの、判読可能な形式ではありません。たとえば、5つの異なるユーザーIDでログインすると、5つの異なるハッシュを受け取りますが、同じビジターによる複数セッションでは、同じハッシュを受け取ります。この作成された(ハッシュされた)値には一意性がありますが、それ自体は実質的な値ではありません。

ブラインド済

アイテムの元の内容をXで置き換えてログに記録するように指定します。

プレーン

アイテムを元の状態のままログに記録するように指定します。つまり、保護されません。

切捨て

HTTPプロトコル・アイテムの最初の1KB分の文字のみがログに記録されるように指定します。1KBより長い値の場合は、その値が切り捨てられてハッシュされたアラームが、(ハッシュされていない)プレーン・データの最初の1KBに追加されます。このような方法で、一意性が保持されます。

次に、「保存」をクリックします。指定した変更は5分以内に有効になります。

URL要素のマスキング

URL POST引数、Forms要素、CookieおよびHTTPヘッダーの他に、接頭辞を指定してURLの特定の内容を保護することもできます。この機能が役立つのは、機密情報を含む可能性があるURL構文を保存できないようにする場合です。

URLコンポーネントを(データ・ブラウザ・グループ内の情報およびセッション診断機能が導出される)コレクタ・ログ・ファイルに保存するかどうかを指定します。表13-6に使用可能なマスキング・アクションを示します。

表13-6 URL接頭辞マスキング・アクション

マスキング・アクション

説明

ロギング

(他のすべての定義済マスキングを適用後)URLコンポーネントをコレクタ・ログ・ファイルに保存するよう指定します。これがデフォルトです。

ロギングなし

コレクタ・ログ・ファイルに何も保存しないように指定します。

URL接頭辞のマスキング・アクションが「ロギングなし」に設定されている場合、これはリプレイ・アクションにもなります。13.10項「リプレイ・ポリシーの制御」で説明するように、これは最初にマスキング・アクションを変更しないと変更できません。

重要:
URL接頭辞のデフォルトのマスキング・アクションが「ロギングなし」に設定されている場合、データはコレクタ・ログ・ファイルに書き込まれず、レポートに何も使用できません。このため、記録されるURLコンポーネントのホワイトリストを最初に定義した場合のみ、このオプションを選択する必要があります。

デフォルトのマスキング・アクションの指定

前述のように、デフォルト設定では、セキュリティ定義においてアクションが明示的に指定されないHTTPプロトコル・アイテムに対して実行する必要があるアクションが指定されます。「デフォルト」アクションのアイテムを定義すると、1回の操作で多数のデータ・アイテム(表示されているアイテムと非表示のアイテムの両方)のセキュリティ設定を変更できます。

デフォルト・アクションを指定する手順は、次のとおりです。

1. デフォルト・アクションを指定するHTTPプロトコル・アイテムを選択します。たとえば、「HTTPヘッダー・マスキング」を選択します。

2. 「デフォルトのマスキング・アクション」メニューの現在の設定をクリックします。これは、マスキングのウィンドウの一番上にあります。図13-20に示すようなダイアログが表示されます。

図13-25 デフォルトのマスキング設定の編集ダイアログ

3. アクションが「デフォルト」のすべてのデータ・アイテムに適用する、目的のセキュリティ設定を選択します。次に、「保存」をクリックします。この設定は、変更すると、5分以内に有効になります。

自動表示アイテム

明示的に定義するHTTPプロトコル・アイテムのマスキングに加えて、構成時にRUEIで自動的に検出されるアイテムもあります。たとえば、URL POST引数pagelabelを使用してWebLogic Portalアプリケーションを追跡し、HTTPヘッダーAccept-Languageを使用してエンド・ユーザーの言語プリファレンスを決定します。これらのアイテムは、「システム」として「使用中」列に示されます。一般的に、マスキング・アクション「プレーン」を受信します。これは、関連付けられているアイテムが元の状態で記録されることを意味します。アクションは、ネットワーク・トラフィックの正確な監視のために必要であり変更できません。

セッションの追跡が標準のテクノロジ(ApacheまたはColdFusionなど)に基づいている場合、Cookieは「使用中」セクションではレポートされません。このようなCookieは手動で定義されて、デフォルト値以外に構成されていないかぎり、デフォルト・マスキング・アクションが割り当てられています。デフォルト・マスキング・アクションが「ブラインド済」に設定されていない場合、問題はありません。設定されていると、すべてのビジター・セッションが1セッションに記録されます。

認証フィールドのマスキング

8.3.14項「ユーザー識別の定義」に記載しているように、ユーザーの識別は最初はHTTP認可フィールドに基づいて行われます。この情報がネットワーク上でプレーン形式で送信されると、ユーザー名とパスワードをデコードされる可能性があり、セキュリティ問題が生じることに注意してください。これは、基本的な認証プロトコルの制限です。

認証フィールドがネットワーク上でプレーン形式で送信される場合は、前のセクションで説明したマスキング・オプションを使用して、Replay Viewerに保存する内容を制御できます。または、認証がネットワーク・トラフィックに含まれるときにハッシュされるようにすることができます。この場合、セッション診断でユーザーIDを使用できません。

Cookie値のマスキング

Cookie値-1には自動的にマスキング・アクション「Plain」が割り当てられる(つまり、元の状態のまま保持される)ことに注意してください。これが必要な理由は、Oracle E-Business Suite内ではセッションの終了を示すためにこの値が頻繁に使用されるからです。

重要:

マスキング機能を使用する場合には、次の点に特に注意する必要があります。

- 定義するマスキング・アクションはすべての監視対象ドメインに適用されます。

- すべてのマスキングされたHTTPプロトコル・アイテム(URL接頭辞を除く)では、大/小文字が区別されません。

- 複数の(重なり合う)アイテム定義が可能ですが、一致部分が長い方の指定が、割当てのマスキング・アクションとして使用されます。

- 定義済のマスキング・アイテム(たとえば、3.12項「カスタム・ディメンションの使用」に記載されているカスタム・ディメンション・アイテム)を削除すると、そのマスキング・アクションを変更しなくても、そのアイテムは表示されるアイテム・リストから自動的に削除されます。ただし、定義済アクションを事前に変更していた場合は、アイテム・リストから明示的にアイテムを削除する必要があります。

- 各国語のキャラクタ・セットを使用する際のデータ・マスキング設定の詳細は、付録G「各国語サポートの使用」を参照してください。

- 付録S「エンリッチ・データのエクスポート機能」に記載しているように、RUEIによって収集されるデータをエクスポートして、他のデータ・ウェアハウス・データと組み合せることができます。RUEIでマスキングしたデータ・アイテムはマスキングされたままエクスポートされるため、外部アプリケーションで使用されるデータ・アイテムの要件をよく確認することをお薦めします。マスキング機能の設定ウィンドウで、セキュリティ要件を確認するために最適な監査ツールが提供されます。

- データ・アイテムのセキュリティを変更するときは、ログ・ファイルにすでに保存されているデータは変更の影響を受けないことに注意してください。必要であれば、システムのパージを検討する必要があります(この詳細は、15.12項「システムのリセット」に記載されています)。

- すべての機密データが間違いなくマスキングされていることを定期的に検証することを強くお薦めします。通常、アプリケーションは時間とともに変化し、それに伴ってPOST変数、Cookie、ヘッダー、URL構文の使用方法も変化します。コレクタおよびレポータのRAWログ・ファイルは、ディレクトリ/var/opt/ruei/processor/dataを参照してください。セッション診断のエクスポート機能を使用して、これらのファイルの内容を監査することもできます。この詳細は、4.4項「すべてのセッション情報のエクスポート」に記載されています。

13.7 FSRページ・コンテンツのマスキング

13.6項「ユーザー情報のマスキング」で説明されているマスキング機能では、ヘッダー、URL、CookieおよびOracle Forms要素内の引数のマスキング・ポリシーを定義できます。また、フル・セッション・リプレイ(FSR)機能内で表示されるアプリケーション・ページの実際のコンテンツについて、マスキング・ポリシーを定義することもできます。これは、実際のWebサーバー・コンテンツ内の機密情報(パスワードおよびクレジット・カード情報など)へのアクセスを制限する場合に特に有用です。

ページ・コンテンツのマスキング・ポリシーを定義するには、次の手順を実行します。

1. 「構成」、「アプリケーション」、「アプリケーション」または「スイート」の順に選択し、必要なアプリケーションを選択します。「アプリケーション概要」が表示されます。

2. 「拡張」タブ→リプレイ・マスキングタブの順にクリックします。現在定義されているマスキング・ポリシーが表示されます。「編集」をクリックします。図13-26に示すダイアログが表示されます。

図13-26 リプレイ・マスキング・アクションの編集ダイアログ

3. 「検索タイプ」メニューを使用して検索範囲を指定します。これには、リクエストまたはレスポンスのコンテンツのいずれかを指定できます。「検索値」フィールドを使用して、目的のページ・コンテンツの検索に使用するXPath式を指定します。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。必要な検索ごとに「追加」を追加します。次に、「保存」をクリックします。
変更は5分以内に有効になります。

XPath検索式の設計

目的のページ・コンテンツを検索するための正確なXPath検索式は、アプリケーション・ページの構造に応じて異なります。次のリクエストおよびレスポンス・フラグメントを確認します。

POST /cgi-bin/post HTTP/1.1
Accept: */*
Connection: keep-alive
Content-Length: 97
Content-Type: text/xml
Host: myshop.com
Pragma: no-cache<user><CardName>AMEX</CardName><CardExp>150606</CardExp><CardNo>12345-12345-12345</CardNo></user>

HTTP/1.1 200 OK
Date: Fri, 03 Aug 2012 08:29:01 GMT
Server: Apache/2.2.3 (Oracle)
Connection: close
RUEI-Transfer-Encoding: chunked
Content-Type: text/xml
<?xml version="1.0"?>
<info>
<request>
<action>do_refund</action>
<meta>
<merchantid>8500</merchantid>
<ipaddress>10.69.10.214</ipaddress>
<version>1</version>
</meta>
<params>
<payment>
<orderid>2012050901</orderid>
<countrycode>nl</countrycode>
<paymentproductid>1</paymentproductid>
<amount>100</amount>
<currencycode>eur</currencycode>
<creditcardnumber>12345-12345-12345</creditcardnumber>
<expirydate>150606</expirydate>
</payment>
</params>
</request>
</info>

ユーザーのクレジット・カード番号がリクエストおよびレスポンスの両方に表示されます。このため、セッション診断内で完全にマスキングするには、次の2つのマスキング・アクションを定義する必要があります。

- 検索タイプ: リクエスト・コンテンツ内のXPathの検索
検索値: //CardNo

- 検索タイプ: レスポンス・コンテンツ内のXPathの検索
検索値: //creditcardnumber

クレジット・カードの関連情報(有効期限など)をマスキングするには、追加のアクションを定義する必要もあります。

重要:

この機能内で定義されるマスキング・ポリシーは、アプリケーション・ページのFSR機能内の表示方法にのみ適用され、RUEIインストール内の記憶域には適用されません。

13.8 SSLクライアント証明書のマスキング

デフォルトでは、すべてのSSLクライアント証明書プロパティ(ある場合)は、各コレクタ・システムで生成されるログ・ファイルの一部として記録されます。これが組織のセキュリティ・ポリシーにそぐわない場合は、次の手順を実行します。

1. 「構成」、「セキュリティ」、「SSL証明書マスキング」の順に選択します。図13-27に示すパネルが表示されます。

図13-27 コレクタのSSLクライアント証明書のマスキング・ポリシー

2. 目的のコレクタ・プロファイルの証明書マスキング・アクションをクリックします。図13-28に示すダイアログが表示されます。

図13-28 「コレクタのSSL証明書マスキングの編集」ダイアログ

表13-7に示すオプションがあります。

表13-7 SSL証明書マスキング・アクション

オプション

説明

すべての証明書のプロパティを記録

SSL証明書全体をログに記録するように指定します。これがデフォルトです。

セッションIDのみを記録

セッションID情報のみを記録するように指定します。

証明書のプロパティが記録されていません

SSL証明書をまったくログに記録しないように指定します。

目的のマスキング・アクションを選択します。次に、「保存」をクリックします。

3. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。

13.9 コレクタのデータ保存ポリシーの定義

次の手順では、データ保存を構成し、アプリケーション・ベースまたはコレクタ・ベースで現在のディスク使用状況を監視できます。コレクタのデータ保存は、次の基準を使用して構成できます。

- サイズ・ベース - サイズ割当て(X GB)が満たされるとデータが破棄されます。

- 時間ベース - 定義された期間(N日間)が経過するとデータが破棄されます。

記憶域にはN日を超える分のデータは含まれず、記憶域がX GBを超えるディスク領域を占有することはありません。この手順では、サイズ・ベースのデータ保存ポリシーを構成する方法について説明します。時間ベースのデータ保存はレポータ保存ポリシーに関連しており、これについては12.10.1項「レポータの保存ポリシーの定義」で説明されています。

サイズ・ベースのコレクタ保存ポリシーはアプリケーション/スイート単位で指定できますが、時間ベースのコレクタ/レポータのデータ保存ポリシーはこの単位で指定できません。

レポータに登録済のコレクタで使用されるサイズ・ベースのデータ保存ポリシーを指定する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「コレクタ・データ保持ポリシー」の順に選択します。図13-29に示すパネルが表示されます。

図13-29 コレクタ・データ保持ポリシー

2. 「アプリケーション・ビュー」タブ内で、定義された各アプリケーション、スイート、サービス、および各コレクタ・プロファイル全体に対して、次の情報が表示されます。

- 制限(GB): エラー・ページ・リプレイ(EPR)およびフル・セッション・リプレイ(FSR)のデータ用に現在予約されているディスク領域の最大量を示します。

- 平均使用量(GB): リプレイ・データ用のプロファイル内で、各コレクタによって現在使用されているディスク領域の平均容量を示します。

- 平均期間: リプレイ・データを使用可能な時間の長さ(秒、分、時間または日数)を示します。通常、10分とレポートされる場合は、10分を超えるデータを格納できないほどシステムがビジーであることを意味します。

3. アプリケーション、スイート、およびサービスについて、「リプレイ・アクティブ」列のラジオ・ボタンを使用して、再生データの作成を有効にするかどうかを指定します。デフォルトでは、再生データは有効になっています。

4. 有効にした場合、変更するアプリケーションを監視する各コレクタ・プロファイルの「エラー・ページ・リプレイ・ストア」(ERS)設定またはフル・セッション・リプレイ記憶域(FRS)設定をクリックします。図13-30に示すようなダイアログが表示されます。

図13-30 「エラー・ページ・リプレイ格納サイズ」ダイアログ

アプリケーション、スイートまたはサービスの選択したプロファイル内のすべてのコレクタについて、FSRまたはEPRデータのために予約しておくディスク領域の最大容量を指定します。

5. または、特定のコレクタ・プロファイルの個々のアプリケーションおよびスイートのFSRおよびEPRデータ・ストア・サイズを指定するかわりに、図13-29に表示されている「リプレイのデフォルトの設定」コマンド・ボタンをクリックできます。図13-31に示すようなダイアログが表示されます。

図13-31 「リプレイのデフォルトの設定」ダイアログ

リプレイ記憶域をデフォルトで有効化するかどうか、および各コレクタ・システムのFSRとEPRデータ用に予約するディスク領域の最大量を指定します。

6. これらの設定を変更したら、「ネットワーク・データ・コレクタ・ステータス」(15.2項「コレクタのステータスの表示」を参照)を使用して、それぞれの適切なコレクタ・プロファイルに対する最後の更新を確認し、適用されていることを確認することをお薦めします。必要な場合は、13.1.6項「コレクタの再起動」の説明に従って、すべての必要なコレクタを再起動します。

重要:

次の点に注意してください。

- リプレイ機能は、ネットワーク・データ・コレクタを使用している場合に使用できます。タグ・データ・コレクタのみを使用している場合、この機能は使用できません。

- 関連付けられているコレクタ・プロファイルのリプレイ記憶域の有効化以外に、アプリケーション、スイートまたはサービスについてリプレイ・データを使用可能にする場合、リプレイ・ロギング・ポリシーが適切に設定されていることも確認する必要があります。この詳細は、13.10項「リプレイ・ポリシーの制御」に記載されています。

- アプリケーションで使用可能な再生用のディスク領域を、現在使用中の容量よりも減らすと、再生データ・ストアのサイズを調整するために、ストアの最も古いデータが削除されます。たとえば、アプリケーションのFSRデータ・ストアを20GBから10GBに減らすように指定し、現在14GBが使用されているとします。この場合、ストアのサイズを調整するために、現在のFSRデータ・ストアの最も古い4GB分が削除されます。

- この項の冒頭で説明したように、データ保存は時間および領域の割当てによって制限されます。

- FSR期間が15分未満の場合、エラー・リプレイ機能が正常に実行されない場合があります。また、0に設定されると、EPRサイズ設定を変更できなくなります。

- 「コレクタ・ビュー」タブをクリックして、レポータ・システムに接続された各コレクタの使用できるおよび使用されたリプレイ・データ記憶域、期間および最新の更新を表示できます。これを定期的に確認してレポート要件を満たしていることを確認することをお薦めします。

リプレイ・データのパージ

アプリケーションまたはスイートが削除されるとき、関連するFSRおよびEPRデータはコレクタ・システムから自動的に削除されません。引き続き表示することができます。このデータを削除する場合、「リプレイ・アクティブ」列に表示されている「削除」アイコンをクリックする必要があります。データの削除を確認するように求められます。

13.10 リプレイ・ポリシーの制御

RUEIで使用されるリプレイ・ビューアに書き込まれる情報を制御することができます。リプレイ・アクションを監視中のすべてのトラフィックに適用するか、特定のIPアドレス範囲に適用するかを指定できます。また、接頭辞を指定することによって、特定のURLコンテンツをログに記録する方法も制御できます。RUEIのデプロイメントでリプレイ・ポリシーを指定するには、次の手順を実行します。

1. 「構成」、「セキュリティ」、「リプレイ・ロギング・ポリシー」の順に選択します。図13-32に示すウィンドウが表示されます。

図13-32 「リプレイ・ロギング・ポリシー」ウィンドウ

2. 「デフォルトのリプレイ・アクション」設定をクリックします。図13-33に示すダイアログが表示されます。

図13-33 「デフォルトのリプレイ・アクションの編集」ダイアログ

3. 「アクション」メニューを使用して、リクエストとレスポンスのヘッダーおよび本体において、監視中のトラフィックのどの要素をリプレイ・ビューア機能とコレクタ・ログ・ファイルに記録するかを指定します。表13-8に、使用可能なオプションを示します。

表13-8 デフォルトのロギング・アクション

マスキング・アクション

説明

リプレイなし

すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアには何も保存しないように指定します。これがデフォルトです。

完全ロギング

すべての部分をリプレイ・ビューアとコレクタ・ログ・ファイルの両方に保存するように指定します(他にマスキングが定義されていればその適用後)。

リクエスト本体なし

すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアにリクエスト本体は保存しないように指定します。

返信本体なし

すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアに返信本体は保存しないように指定します。

ヘッダーのみ

すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアにはリクエスト・ヘッダーとレスポンス・ヘッダーのみを保存するように指定します。

マスキング・アクションの使用方法の詳細は、13.6項「ユーザー情報のマスキング」を参照してください。

4. 「リプレイIP範囲」設定をクリックします。図13-34に示すダイアログが表示されます。

図13-34 「コレクタのリプレイIP範囲の編集」ダイアログ

5. 「範囲」メニューでは、選択したデフォルト・アクション(デフォルト)を使用してすべてのIPアドレス範囲のネットワーク・トラフィックをログに記録するか、それとも特定のアドレス範囲のトラフィックのみを記録するか指定します。次に、「保存」をクリックします。図13-32に示すウィンドウに戻ります。

6. 特定のIPアドレス範囲からのみネットワーク・トラフィックをログに記録する場合は、IP範囲のロギング・タブをクリックします。「すべてのIPアドレス」オプションを選択した場合は、既存のIPアドレス範囲の定義が無効になり無視されます。

7. 「新規IP範囲の追加」をクリックして新しいIPアドレス範囲を定義するか、既存の定義をクリックして変更します。図13-35に示すダイアログが表示されます。

図13-35 「リプレイIPアドレス範囲の追加」ダイアログ

8. トラフィックのロギングを限定するIPアドレスとネットマスクの組合せを指定します。次に、「保存」をクリックします。

9. オプションで、「アップロード・リスト」をクリックすると、現在定義されているIPアドレス範囲に、IPアドレス範囲のリストをマージすることができます。ファイルは、1行が1エントリである必要があり、各アドレス範囲に関する情報(IPアドレスとネットマスク)はタブで区切られている必要があります。次に、「マージ」をクリックします。

10. URLコンポーネントのロギング・ポリシーを指定するには、「URL接頭辞」タブをクリックします。現時点で定義されているURL接頭辞がリストされます。例を図13-36に示します。

図13-36 「URL接頭辞」セクション

11. 「新規URL接頭辞の追加」をクリックして新しいURL接頭辞を定義するか、既存のURL接頭辞をクリックして変更します。図13-37に示すダイアログが表示されます。

図13-37 「URL接頭辞のリプレイ・アクションの追加」ダイアログ

12. URLコンポーネントを指定し、対応するロギング・アクションを選択します。表13-8に、使用可能なオプションを示します。次に、「保存」をクリックします。

リプレイ・アクションの適用方法の理解

次の点を理解してください。

- マスキング・アクション「ロギングなし」が明示的に定義されているURL接頭辞のリプレイ・アクション(13.6項「ユーザー情報のマスキング」を参照)は、自動的にリストされた項目として表示されて変更できません。例(/bin)を図13-36に示します。これらの項目を変更する場合、最初にマスキング・アクションを「ロギング」に変更する必要があります。

- 表13-8に記載されているリプレイ・アクションは、リプレイ・ビューア機能に記録されている項目を制御します。表13-9に、各リプレイ・アクション内で記録される部分を示します。

表13-9 リプレイ・アクション内に記録される項目

マスキング・アクション

リクエスト・ヘッダー

リクエスト本文

レスポンス・ヘッダー

レスポンス本文

コレクタ・ログ・ファイルへの記録

完全ロギング

X

X

X

X

X

リクエスト本体なし

X

X

X

X

ヘッダーのみ

X

X

X

リプレイなし

X

- リプレイ・ビューアで確認用にログ・アイテムを使用できる期間は、各監視対象アプリケーションに指定されるエラー・ページ・リプレイ(EPR)およびフル・セッション・リプレイ(FSR)によって決定されます。このため、レポート要件を満たす十分な記憶域が割り当てられていることを確認する必要があります。これらの設定は、13.9項「コレクタのデータ保存ポリシーの定義」で説明されています。

URL接頭辞の適用方法の理解

- アクティブなIPアドレス範囲にURL接頭辞のリプレイ・アクションが定義されていると、デフォルトのリプレイ・アクションより優先されます。

- 一致するURL接頭辞が重複する場合(たとえば、/ruと/rueiなど)には、別々のリプレイ・アクションが割り当てられ、最長一致が採用されます。また、接頭辞は厳密に先頭部分に適用されることに注意してください。たとえば、対象のURLが/app/rueiの場合は、/ruも/rueiも一致しません。

- URL接頭辞に疑問符(?は)指定できません。指定すると、疑問符とその後の内容がすべて無視されます。たとえば、URL /catalog/jn.php?itemと指定すると、切り捨てられて/catalog/jn.phpになります。URLは判読可能な形式で(エンコーディングではなく)指定する必要があります。

- URL接頭辞は大/小文字が区別されます。

13.11 超特大フレームの監視の制御

デフォルトでは、レポータに接続されているコレクタは、ペイロード・サイズが64KBまでの受信フレームのみを監視します。これにより、ネットワーク・ドライバでTCPセグメンテーション・オフロードを使用している場合に、RUEIはトラフィックを監視できます。場合によっては、メモリー使用量を削減して、メモリーに保持できるフレーム数を増やすために、最大フレーム・サイズを大きくする必要があります。最大フレーム・サイズを削減する手順は、次のとおりです。

1. 「構成」、「セキュリティ」、「超特大フレーム」の順に選択します。

2. 「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。

3. 最大フレーム・サイズの設定をクリックします。

4. プロファイルのコレクタによって受け入れられる受信フレームの最大サイズを選択します。デフォルトは64 KBです。指定した最大値を超えるフレームは破棄され、メッセージがイベント・ログに記録されます。次に、「保存」をクリックします。

表13-10に、メモリーに保持できるフレーム数を示します。

表13-10 最大フレーム・サイズ、フレーム数およびバッファ・サイズ

最大フレーム・サイズ

フレーム数

バッファ・サイズ

64K脚注1

8K

512MB脚注2

32K

16K

512MB脚注2

16K

32K

512MB脚注2

8K

64K

512MB

4K

64K

256MB

2K

64K

128MB

脚注1 デフォルトです。

脚注2 フレーム数は自動的に調整されます。

このため、監視対象トラフィック内の予想される最大フレーム・サイズを超える最大フレーム設定を行わないことをお薦めします。コレクタ統計機能の「インタフェース」タブ内で、各コレクタで出現する最大フレーム・サイズを確認できます(15.2項「コレクタのステータスの表示」を参照)。

トラブルシューティング手順の詳細は、RUEIインストレーション・ガイドの付録「トラブルシューティング」を参照してください。

13.12 RUEIユーザー・セッション・アイドル時間の制御

デフォルトでは、ユーザー・アクティビティがない状態で60分経過すると、ユーザーはRUEIから自動的にログアウトされます。ユーザーが自動的にログアウトされるまでのアイドル時間を変更するには、「構成」→「一般」→「詳細設定」→「ユーザー・インタフェース」を選択します。表示されるリストから「RUEIセッション・アイドル時間(分)」を選択します。ビジターが非アクティブになってからRUEIセッションを終了するまでに必要な経過時間を指定するか、空のままにします(制限を設定しない場合)。

14 ユーザーと権限の管理

この章では、RUEI内でユーザーに割り当てるロールと権限、およびユーザー・アカウントの作成と管理について説明します。また、外部ユーザー認証メカニズムの構成(LDAP、SSOなど)および組織のセキュリティ・ポリシーを強化するパスワード設定機能の使用方法についても説明します。

14.1 概要

ユーザー定義の処理を開始するには、「システム」→「ユーザー管理」の順に選択します。図14-1に示す画面が表示されます。

図14-1 ユーザー管理

この画面には、現在定義されているシステム・ユーザーが表示されます。ユーザー・アカウントごとに、アカウント名、フルネーム、電子メール・アドレスおよび認証メカニズムが表示されます。ユーザー・アカウントのロールとステータスは、図14-2に示すカラー・コード・スキームを使用して表示されます。

図14-2 ユーザー・アカウントのロールとステータス

システム・アカウント・タイプ

ユーザー・アカウントだけでなく、RUEIユーザー・インタフェースへのアクセス権を持たないシステム・アカウントも作成できます。ADF監視サービスを使用する場合などは、これらのアカウントを使用して、サービス・レベルでRUEIと対話します。システム・アカウントは完全アクセス・レベルを持ち、表14-3に示す権限を持つように構成できます。

ユーザー認証

システム・ユーザーの認証は、RUEIそのものがデータベースに格納されているユーザー情報を使用して実行することも、外部の認証サーバーによって実行することもできます。現在、RUEIでは2つの外部認証メカニズムがサポートされています。LDAPサーバーを使用する方法とOracle Single Sign-On(SSO)サーバーを使用する方法です。いずれの場合も、サーバーがRUEIと一緒に機能するように構成されている必要があります。LDAPサーバーを構成する手順の詳細は、14.8項「LDAPサーバーのユーザー認証の構成」に記載されています。Oracle SSOサーバーを構成する手順の詳細は、14.9項「Oracle Single Sign-On(SSO)のユーザー認証の構成」に記載されています。

14.2 ユーザー・アカウントのロールと権限の概要

ここでは、構成機能やレポート・データへのアクセスをRUEIが管理する方法を説明します。次の情報をよく確認することをお薦めします。

各RUEIユーザーにはロールが割り当てられます。このロールにより、ユーザーが実行できるアクションとユーザーがアクセスできる情報の種類が決まります。表14-1でこれらのロールについて説明します。

表14-1 ユーザー・アカウントのロール

ロール

説明

管理者

RUEIの初期構成を行い、システムで使用される基本的なネットワーク関連構成(メール設定やコレクタ添付ファイル)のメンテナンスを管理するユーザーです。

また、管理者権限を割り当てられたユーザーは、システムの第1レベル・サポートの役割も持ち、現在の構成のバックアップ、拡張システム設定の構成、およびシステムの操作権限のある他のユーザーの管理などを担当します。

セキュリティ担当者

組織のネットワーク・セキュリティ・ポリシーの影響を受けるすべてのシステム設定を管理するユーザーです。具体的には、次のことを行います。

- HTTPSユーザー・フローの復号化に使用するセキュリティ証明書と秘密鍵をインポートし、これらを最新の状態で維持します。

- 組織のネットワーク内の監視対象の有効範囲を決定します。ネットワーク・フィルタを設定して、特定のネットワークまたはホスト、あるいは仮想Local Area Network(VLAN)が取得されないようにしたり、ネットワーク・トラフィック全体を削減できます。

- Webトラフィックで渡されるプライベート・データのセキュリティ関連メジャーを実装およびメンテナンスします。

ビジネス・ユーザー

事業目標に照らしてビジターの行動の評価に取り組むユーザーです。このため、システムに用意されているビジネス・インテリジェンスを使用して、Webサイトにアクセスするまでの最も一般的なパスの特定や、特定のページやセクションにアクセスするビジターの関心度の強さなどの様々な問題を監視します。このユーザーは、顧客満足度、顧客維持率および顧客ロイヤルティの向上、顧客転換率の増加、Webサイトベースのマーケティング活動の効果の監視などに注力します。

このユーザーは、割り当てられている権限に基づいてダッシュボード機能やオンデマンドで郵送されるレポートを使用し、組織の事業概要のメンテナンスを行います。また、このレポートやデータのエクスポートを、ITスペシャリストに詳細な分析の基本データとして提供します。

ITユーザー

Web環境の監視に必要となるIT情報およびその他の技術情報のサポートに従事するユーザーです。一般に、未達成のSLAやKPIをより深く分析することを担当します。レポート作成機能やデータ・ブラウザ機能をフル活用し、レポートされた例外またはエラーを特定します。たとえば、特定のネットワーク・ドメインのユーザーのセッションのみが失敗していることを突き止めます。

レポート・データのエクスポート

これらのユーザーはBasic認証を使用してレポートにアクセスします。この機能の詳細は、2.13項「レポート・データのエクスポート」を参照してください。

14.2.1 ユーザー・アカウントのロール

ユーザーには、組織で必要とされる構成に応じて、これらのロールの組合せを実行する権限を付与できます。定義できるユーザーの数には制限がありません。

スーパー管理者と権限が割り当てられた管理者

RUEIにはスーパー管理者という1つの事前定義済ユーザーがあることに注意してください。このユーザーは、他のすべてのユーザーとは異なり、初期パスワードがset-admin-password.shスクリプトを使用して設定され、常にローカルで認証されています。業務上の要件によっては、他のユーザーに管理者権限を割り当てることができます。ただし、そのようなユーザーはスーパー管理者の管理下に置かれます。管理者権限が割り当てられた他のユーザーとスーパー管理者を明確に区別する必要がある場合は、スーパー管理者をadminユーザーと表記します。

相互のプロパティを変更する管理者

デフォルトでは、管理者権限を持つユーザーは、他の管理者のプロパティを変更したり、管理者ユーザー・アカウントを作成および削除できます。セキュリティ要件と一致しない場合、この機能を無効にできます。この手順の詳細は、『Oracle Real User Experience Insight管理者ガイド』に記載されています。

14.2.2 ユーザー・アカウントのアクセス・レベル権限

ロールに加えて、各ユーザー(管理者以外)には、ビジネス関連およびIT関連の情報のための個別のアクセス・レベル権限を割り当てることもできます。これらの権限では、ユーザーがアクセスできるモジュール(データ・ブラウザ、KPI概要、システムなど)が定義されます。これについては表14-2で説明します。

表14-2 ビジネス・ユーザーおよびITユーザーのアクセス・レベル権限

アクセス・レベル

ビジネス・ユーザー

ITユーザー

なし

アクセス権限がありません。

アクセス権限がありません。

概要脚注1

ダッシュボード、KPI概要およびアラート履歴を表示可能。

ダッシュボード、KPI概要およびアラート履歴を表示可能。

照会

レポートへの読取り専用アクセス権限があり、PDFダウンロードを作成可能。

レポートへの読取り専用アクセス権限があり、PDFダウンロードを作成可能。

分析

- データ・ブラウザへのアクセス権限があります。

- 新規レポートを作成、および(パブリックまたは自分の)レポートを変更可能。

- データ・ブラウザへのアクセス権限があります。

- 新規レポートを作成、および(パブリックまたは自分の)レポートを変更可能。

完全

- KPIを定義および変更。

- サービス・レベル・スケジュールを編集。

- アラート・スケジュールを編集。

- ユーザー・フローを定義および変更。

- サイト全体で共通となるエラーを定義および変更。

- KPIを定義および変更。

- サービス・レベル・スケジュールを編集。

- アラート・スケジュールを編集。

- アプリケーションを定義および変更。

- 名前付きWebサーバーを定義および変更。

- 名前付きクライアントを定義および変更。

- サイト全体で共通となるエラーを定義および変更。

脚注1 ビジネス・ユーザーかITユーザーとして少なくとも「概要」レベルの権限を付与されていないユーザーは、ログオンできません。

ユーザーのロールとアクセス・レベル権限の管理については、14.2項「ユーザー・アカウントのロールと権限の概要」で説明しています。

これにより、ビジネス・ユーザーおよびITユーザーは自分に関連する情報をただちに見つけることができます。たとえば、ビジネス・ユーザーがレポート・ライブラリにアクセスすると、ビジネス・ユーザーに必要なレポートのみのリストがフィルタリングされ、作業対象のレポートに反映されます。

14.2.3 システム・アカウント・ロールの権限

現在システム・アカウントに関連付けられたロールはなく、次の権限のみ存在します:

表14-3 システム・アカウントの権限

アクセス・レベル

システム・アカウント

ADF監視サービス

これらのユーザーはRUEIを使用してADFアプリケーションを監視します。ADFを使用するためのRUEIの設定の詳細は、RUEIインストレーション・ガイドを参照してください。

Enterprise Managerアクセス

これらのユーザーは、Oracle Enterprise ManagerでRUEIデータを使用できます。Oracle Enterprise Managerを使用するためのRUEIの設定の詳細は、RUEIインストレーション・ガイドを参照してください。

ユーザーがOracle Enterprise Managerアプリケーション・パフォーマンス管理(APM)機能内のRUEIデータにアクセスするには、認可が必要です。この機能については、『Oracle Enterprise Manager Cloud Control Oracle Fusion Middlewareマネージメント・ガイド』で詳細に説明されています。

14.3 新規ユーザーの追加

新規ユーザーを作成する手順は、次のとおりです。

1. 「システム」→「ユーザー管理」を選択し、タスクバーの「新規アカウントの追加」コマンド・ボタンをクリックします(図14-1を参照)。図14-3に示すようなダイアログが表示されます。
LDAPサーバーまたはOracle SSOサーバーの接続が構成されている場合(14.8項「LDAPサーバーのユーザー認証の構成」を参照)は、図14-3に示すダイアログにLDAP認証オプションが表示されます。

図14-3 アカウントの追加ウィザード

2. 図14-3に示すラジオ・ボタンを使用して、新規のユーザー・アカウントまたはシステム・アカウントを作成し、ユーザーをRUEIインストールに保持されている設定と照合して認証する(デフォルト)か、構成済のLDAPサーバーまたはOracle SSO Serverと照合して認証するかを指定します。次に、「次へ」をクリックします。LDAPサーバーが構成されている場合は、図14-4に示したダイアログが表示されます。そうでない場合は、図14-8に示すようなダイアログが表示されます。

3. 図14-8に示すダイアログを使用して、新規アカウントに関する次の情報を指定します。

- インストール済RUEI内でユーザーを識別するユーザー名。この名前は一意である必要があります。ユーザー名は大/小文字が区別されます。Oracle SSOサーバーのユーザー認証が有効になっている場合、ユーザーは自動的にOracle SSOユーザーとして作成されることに注意してください。この場合、指定されるユーザー名はOracle SSOサーバーに定義されたユーザー名と同じであることが必要です。

- ユーザーのフルネーム。

- ユーザーの電子メール・アドレス。これがレポートと電子メール・アラートの送信先アドレスになります。正しいアドレスであることを確認してください。

- ユーザーをインストール済RUEIでのローカルの設定と照合して認証する場合は、新規ユーザーのパスワードを指定および確認入力しておく必要があります。パスワード要件の詳細は、14.6項「パスワード・セキュリティ・ポリシーの強制」を参照してください。新規パスワードはユーザーが7日以内に変更する必要があります。変更しないと、ユーザーがロックされます。

- 必要に応じて、「無効」チェック・ボックスを使用して、当座の間ユーザーを無効化できます。また、後で有効化することもできます。

図14-4 「ユーザーの詳細」ダイアログ

図14-3で構成済のLDAPサーバーに対してユーザーを認証するように選択した場合は、「LDAPからユーザー・データを取得」ボタンをクリックして、構成済のLDAPサーバーからユーザーの設定を取得できます。

4. 「次へ」をクリックして、続行します。ユーザー・アカウントを追加する場合は、手順4に進みます。14.1項「概要」で説明するようにシステム・アカウントを追加する場合は、手順5に進みます。

5. ユーザー・アカウントを追加する場合、図14-5に示すダイアログが表示されます。

図14-5 ユーザー・アカウントの権限

チェック・ボックスとメニューを使用して、新規ユーザーに割り当てるロールと権限を指定します。これらについては、14.2項「ユーザー・アカウントのロールと権限の概要」で詳しく説明しています。新規ユーザーに割り当てられる権限が「完全」アクセス・レベル権限を下回る場合は、「認可」メニューを使用して、ユーザーが情報を見ることができる特定のアプリケーション、スイートおよびサービスを指定する必要があります。

6. システム・アカウントを追加する場合は、図14-6に示すダイアログが表示されます。

図14-6 システム・アカウントの権限

システム・アカウントには、アプリケーション、スイートおよびサービス・データへのフル・アクセス権があります。ADF監視サービスおよびEnterprise Managerアクセスの設定の詳細は、RUEIインストレーション・ガイドを参照してください。

7. 「終了」をクリックして、ユーザー定義を作成します。図14-1に示すユーザー・リストに戻ります。

注意:
前述の設定の他に、多数の追加設定(言語やメーリング・タイプなど)があります。これらはユーザーの作成時にデフォルト値に設定されます。これらの追加設定は、1.5項「環境のカスタマイズ」に説明されている手順を使用して変更することもできます。

14.4 既存のユーザーの変更

ユーザー定義を変更するには、「システム」→「ユーザー管理」の順に選択します。図14-1に示す「ユーザー管理」パネルが表示されます。目的のユーザーを右クリックします。図14-7に示すコンテキスト・メニューが表示されます。

図14-7 ユーザー・メニュー

表14-4に示すオプションがあります。

表14-4 ユーザーのコンテキスト・メニュー・オプション

オプション

説明

編集

ユーザーの定義を変更できます。この詳細は、14.5項「ユーザーの設定の変更」に記載されています。

アカウントの有効化/無効化

当座の間、ユーザー・アカウントを有効化または無効化できます。現時点で定義されているすべてのユーザーは、SSO認証が有効化されると無効になります。また、すべてのSSOユーザー・アカウントはSSO認証が無効化されると無効になることに注意してください。

切替え

選択したユーザーに一時的に切り替えることができます。これは、そのユーザーに表示権限があるモジュールやレポートを表示する場合に役立ちます。自身のロールに戻るには、「ビュー」メニューから「スイッチ・バック」を選択します。選択したユーザー・アカウントが無効の場合には、このオプションは使用できないことに注意してください。

削除

選択したユーザーをシステムのユーザー管理から削除します。そのユーザーが作成したプライベート・レポートも削除されるため、注意してください。ただし、そのユーザーが作成したパブリック・レポートは引き続き他のユーザーから使用できます。

14.5 ユーザーの設定の変更

既存のユーザーの設定を変更する手順は、次のとおりです。

1. 図14-1に示したユーザー・リスト内で目的のユーザーを選択し、「編集」を選択します。LDAPサーバー接続が構成されている場合(14.8項「LDAPサーバーのユーザー認証の構成」を参照)は、図14-3に示したようなダイアログが表示されます。そうでない場合は、図14-8に示すダイアログが表示されるため、手順3に進んでください。

2. ラジオ・ボタンを使用して、ユーザーの設定を、インストール済RUEIでの設定(デフォルト)または構成済のLDAPサーバーのどちらと照合して認証するかを指定します。次に、「次へ」をクリックします。LDAPサーバーが構成されている場合は、図14-4に示したダイアログが表示されます。そうでない場合は、図14-8に示すダイアログが表示されます。

図14-8 ユーザーの詳細

3. 必要に応じて、表示された任意の情報を変更します。赤のアスタリスクが付いているフィールドは必須であることに注意してください。つまり、空白にはできません。
SSOユーザーのアカウントを変更しているときに、SSO認証が無効になると、そのアカウントはローカル認証アカウントに自動的に変換されることに注意してください。したがって、ユーザーのパスワードの指定と確認が必須になります。

「無効」チェック・ボックスを使用して、ユーザーによるこのアカウントの使用を無効化できます。無効化したユーザーは後で有効化することもできます。この機能も役立ちます。前述のように、現時点で定義されているすべてのユーザー・アカウントは、SSO認証が有効化されると無効になり、すべてのSSOユーザー・アカウントはSSO認証が無効化されると無効になるためです。

ユーザーが正しいパスワードの入力を5回連続して失敗すると、ユーザー・アカウントは自動的にロックされます。このような場合は、「ロック済」チェック・ボックスの選択を解除してロックをリセットできます。パスワード・セキュリティの詳細は、14.6項「パスワード・セキュリティ・ポリシーの強制」に記載されています。このチェック・ボックスを使用して、ユーザーのアカウントのロックを解除できます。次に、「次へ」をクリックします。図14-9に示すダイアログが表示されます。

注意:
ユーザーのパスワードがこのインタフェースで変更された場合、ユーザーはパスワードを自分で7日以内に変更する必要があります(1.5項「環境のカスタマイズ」に記載されている手順を使用)。そうしないと、アカウントがロックされます。

図14-9 ユーザー・プリファレンス

4. 必要に応じて、表14-5に示す設定を変更できます。

図14-5 「ユーザー・プリファレンス」の設定

設定

説明

言語

システム・メッセージとプロンプトを表示する言語です。現時点で選択可能な言語は英語のみです。

メーリング・タイプ

ユーザーが受け取るレポートを複数の電子メール(レポートごとに1つ)で送信するか、単一の電子メールにバンドルするかを指定します。デフォルトは複数の電子メールです。

起動モジュール

ユーザーがセッションを開始するモジュールを指定します。(たとえば、「レポート」、「システム」または「ユーザー管理」)。デフォルトはダッシュボードです(第5章「ダッシュボードの使用」を参照)。

最初の参照期間

データ・ブラウザ機能またはレポート機能の開始時の初期期間を指定します。デフォルトは直前の6時間です。

次に、「次へ」をクリックします。図14-5に示すようなダイアログが表示されます。

5. 必要に応じて、チェック・ボックスとメニューを使用して、ユーザーに割り当てるロールと権限を指定します。これらについては、14.2項「ユーザー・アカウントのロールと権限の概要」で説明しています。新規ユーザーに「完全」アクセス・レベル権限が割り当てられない場合は、「認可」メニューを使用して、そのユーザーが表示できる特定のアプリケーション、スイートおよびサービスを指定する必要があります。次に、「終了」をクリックして、変更を有効にします。

スーパー管理者パスワードのリセット

adminユーザーのパスワードをリセットする必要が生じた場合は、set-admin-password.shスクリプトを使用して対応できます。この詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。新規パスワードは(14.5項「ユーザーの設定の変更」の手順を使用して)7日以内に変更する必要があることに注意してください。

14.6 パスワード・セキュリティ・ポリシーの強制

各ユーザーを定義してRUEIを使用できるように認可する必要があります。この手順の詳細は、14.1項「概要」に記載されています。インストール環境のセキュリティを最適化するために、パスワード設定機能を使用して組織のセキュリティ・ポリシーを強制できます。具体的には、ユーザー・パスワードの最大長、ユーザーがパスワードを変更する必要がある頻度、新規ユーザー・アカウント作成後のパスワードの変更期限、およびユーザー・アカウントがロックされるまでのログオン試行の失敗回数を制御できます。

インストール環境のパスワードの強制を設定する手順は、次のとおりです。

1. 「システム」→「ユーザー管理」→「パスワード設定」をクリックします。図14-10に示すダイアログが表示されます。

図14-10 パスワード設定

2. 表14-6に記載されている情報を指定します。

表14-6 すべてのアカウントのパスワード設定

フィールド

説明

最小長

ユーザー・パスワードとして必要な最小文字数を指定します。8から255文字を指定する必要があります。デフォルトは8文字です。

有効期限

ユーザーにパスワードの変更を要求する頻度を指定します。デフォルトは60日です。0に設定すると、パスワードが無期限になります。最大の有効期限は999日です。

最初の有効期限

新規ユーザー・アカウントを作成してから、最初のパスワードの変更が必要になるまでの日数を指定します。これには1から30日を指定する必要があります。これによって、管理者がユーザーのパスワードをリセットした後にユーザー自身がパスワードを変更する必要がある期限も指定されます。デフォルトは7日です。

許可されたログイン試行回数

ユーザー・アカウントがロックされるまでのログオン試行の失敗回数を指定します。これには1から10回を指定する必要があります。デフォルトは5回です。

3. システム・アカウントのパスワードの有効期限をなしに指定するには、「パスワードの有効期限なし」オプションを有効にします。次に、「保存」をクリックします。

パスワードの強制

ユーザーを作成して認可すると、次のルールが自動的に強制されます。

- 指定の回数の試行が失敗すると、ユーザー・アカウントがロックされます。ユーザーが再度ログオンできるようにするには、アカウントのロックを解除する必要があります(14.5項「ユーザーの設定の変更」を参照)。ただし、ロックされたユーザーにも、メール送信されるレポートやアラートが引き続き届きます。

- パスワードの有効期限を0に設定し、後で0以外の値に再設定した場合(またはその逆の場合)、新しく指定した方のパスワード有効期限が既存のすべてのユーザー・アカウントに適用されます。

- ユーザー・パスワードの最小長は8文字です。ユーザー・パスワードには、英数字以外の文字($、@、&、!など)を少なくとも1文字含める必要があります。

- パスワードには、定義済のユーザー名またはその姓や名を含めることはできません。また、ユーザーの直前の3つのパスワードも記憶され、再使用できません。

- パスワードは大/小文字が区別されます。

14.7 モジュールにおける許可データの有効範囲の管理

「完全」アクセス・レベル権限を持つユーザーは、データ・ブラウザ、レポート、KPI概要機能およびダッシュボード内のすべての情報にアクセスできます。それ以外のすべてのユーザーの場合、アクセスできる情報は各ユーザー・プロファイルの一部として管理されます。この機能の使用方法については、14.2項「ユーザー・アカウントのロールと権限の概要」で詳しく説明しています。

汎用の項目と、アプリケーション、スイートおよびサービス固有の項目

KPI、ユーザー・フローおよびダッシュボードは、汎用として定義することも、特定のアプリケーション、スイートまたはサービスに対して定義することもできます。項目内の情報へのアクセスは、各ユーザーに割り当てられる権限を介して自動的に管理されます。

項目が汎用として定義された場合は、すべてのアプリケーションへのアクセスが承認されているユーザーしか表示できません。汎用項目には、複数のアプリケーション、スイートまたはサービスの情報が含まれる場合があるためです。同様に、ユーザーが表示を許可されているのが2つのアプリケーションの情報のみの場合、その2つのアプリケーションに直接関連するKPI、ダッシュボード、データ・ブラウザ情報およびレポートしか表示できません。

14.8 LDAPサーバーのユーザー認証の構成

セキュリティを強化するために、インストール済RUEIのローカルでの設定を使用せずにLDAPサーバーを使用してユーザー認証を有効化するようにRUEIを構成できます。LDAPサーバー接続が構成されている場合は、定義済のユーザーごとに、使用する認証方式を指定できます。adminユーザーは事前定義済であり、そのパスワードは初期構成時に設定されるため(『Oracle Real User Experience Insightインストレーション・ガイド』を参照)、管理者ユーザーにはローカル認証のみを使用できます。

LDAP認証を使用する場合は、ユーザー・アカウントを作成する前にLDAP接続を定義することをお薦めします。これは、以前に指定したユーザー設定の変更を不要にするためです。

LDAPサーバーの証明書の構成

LDAPセキュア・サーバーの証明書は、PEM形式を使用して、/etc/openldap/ldap.confファイルのTLS_CACERTディレクティブで指定する必要があることに注意してください。証明書ファイルはルート・ユーザーが所有し、RUEIおよびApacheユーザー・グループが読取り可能である必要があります。LDAPサーバーの証明書のCNは、LDAPサーバーの完全修飾ドメイン名に一致する必要があることに注意してください。

LDAP接続の問題のトラブルシューティング

前述のLDAPセキュア・サーバーの証明書を構成する手順で、機能する接続が確立されない場合は、OpenLDAPユーティリティ(Oracle LinuxまたはRedHat Enterprise Linuxの配布セットに付属)を使用して、LDAPサーバーの構成を検証できます。このユーティリティをインストールして実行するには、次のコマンドを使用します。

sudo yum install openldap-clients
ldapsearch -x -P 2 -H "LDAP_server_URL" -D
cn=jsmith, dc=oracle, cn-com

LDAP_server_URLにはLDAPサーバーの完全なURLを指定し、その組合せはLDAPサーバーの構成によって異なります。正しく指定すると、そのユーザーに関する情報がLDAPサーバーから返されます。そうでない場合は、発生した問題(指定したホスト名がLDAPサーバーと一致しない、またはLDAP証明書が正常にインストールされていないなど)がレポートされます。

証明書が機能しない場合は、/etc/openldap/ldap.confファイルでTLS_REQCERTディレクティブをneverに設定すると、証明書の検証やセキュアな接続の継続を中止できることに注意してください。

LDAPサーバー接続の構成

LDAPサーバー認証を有効化する手順は、次のとおりです。

1. 「システム」→「ユーザー管理」→「LDAP接続の構成」をクリックします。LDAPサーバー接続がすでに構成されている場合、最後のオプションは「LDAP接続の変更」として表示されます。図14-11に示すダイアログが表示されます。

図14-11 「LDAP設定」ダイアログ

2. 表14-7に記載されている情報を指定します。

表14-7 「LDAP設定」ダイアログのフィールド

フィールド

説明

LDAP認証を許可

LDAPサーバーをユーザー認証に使用できるかどうかを指定します。デフォルトでは選択されていません(無効化されています)。

サーバー名

使用するLDAPサーバーのホスト名またはIPアドレスを指定します。サーバー名にプロトコル情報(LDAP://など)を含めないでください。

接続タイプ

LDAPバージョンおよび接続方法を指定します。デフォルトはV2(非セキュア)です。

ポート番号

LDAPサーバーがリスニングしているポートを指定します。この情報については、必要に応じてシステム管理者に問い合せてください。デフォルト・ポートは389または636(SSL暗号化用)です。

検索ベース

ユーザーIDを一意にする必要があるディレクトリ構造の場所を指定します。この場所には有効なDNを指定する必要があります。パフォーマンス上の理由により、この場所にはできるかぎり深いディレクトリを指定してください。デフォルトはディレクトリ・ツリーのルートです。

Anonymous

LDAPサーバー参照を匿名ユーザーを使用して実行する必要があるかどうかを指定します。選択しない場合は、有効な識別名(DN)を指定する必要があります。このユーザーのパスワードは、新規ユーザーとして作成される際に要求されます。デフォルトでは、匿名参照が使用されます。

ユーザーID、電子メール・アドレス、フルネーム

LDAPサーバーからユーザー設定を抽出するために使用する必要がある属性を指定します。デフォルトは標準のLDAP機能に基づいています。これらの属性については、必要に応じてLDAP管理者に問い合せてください。

3. 必要に応じて、「テスト」をクリックして、LDAPサーバーに対して、機能する接続を確立できるかどうかを検査できます。この詳細は次の項に記載されています。次に、「保存」をクリックします。

LDAP構成設定に対して指定した変更は即座に有効になります。

LDAPサーバーのテスト

前述のように、LDAPサーバーに対する接続はテストできます。次を実行します。

1. 図14-11内の「テスト」をクリックします。図14-12に示すダイアログが表示されます。

図14-12 LDAP設定のテスト

2. 「検索するユーザーID」フィールドを使用して、LDAPサーバーが検索対象とするユーザーIDを指定します。これには有効なユーザーIDを使用する必要があります。準備ができたら、「テスト」をクリックします。指定したユーザーのエントリがディレクトリ内に見つかると、取得した詳細が表示されます。次に、「取消」をクリックします。図14-11に示したダイアログに戻ります。

14.9 Oracle Single Sign-On(SSO)のユーザー認証の構成

セキュリティを強化するために、LDAPサーバーまたはインストール済RUEIのローカルでの設定を使用せずに、Oracle Single Sign-On(SSO)サーバーを使用してユーザー認証を有効化するようにRUEIを構成できます。

これを有効化すると、RUEIユーザー(adminユーザー以外)は自動的にOracle SSOログオン・ページにリダイレクトされます。ユーザーは、RUEIログイン・ダイアログ(図1-1を参照)ではなく、このページからRUEIにログオンします。adminユーザーは事前定義済であり、そのパスワードは初期構成時に設定されるため(『Oracle Real User Experience Insightインストレーション・ガイド』を参照)、管理者ユーザーにはローカル認証のみを使用できます。管理者権限を持つ他のユーザーも、Oracle SSOサーバーからログオンする必要があることに注意してください。

SSOサーバーのアクティブ化

SSOサーバーをアクティブにする手順は、次のとおりです。

1. 「システム」→「ユーザー管理」→SSO接続の構成をクリックします。Oracle SSOサーバー接続がすでにアクティブになっている場合、最後のオプションはSSO接続の変更として表示されます。図14-13に示すようなダイアログが表示されます。

図14-13 「Oracleシングル・サインオン(SSO)設定」ダイアログ

2. Oracle SSOの有効化/無効化チェック・ボックスを使用して、ユーザー認証にSSOサーバーを使用できるようにするかどうかを指定します。デフォルトでは選択されていません(無効化されています)。次に、「保存」をクリックします。

3. Oracle SSOサーバーを有効化または無効化した後では、RUEIからログアウトして再びログオンすることをお薦めします。こうすることで、RUEIインストールが確実に変更を反映します。

Oracle SSO認証の有効化

ユーザー認証にOracle SSOサーバーを使用するときは、次の点に注意することが重要です。

- 複数のSSO登録アプリケーションにユーザーがログオンしているとき、1つのアプリケーションからログアウトすると、RUEIを含む他のすべてのSSO登録アプリケーションからもログアウトします。同様に、ユーザーがRUEIからログアウトすると、SSOセッションからもログアウトします。

- SSO認証が有効化されているとき:

- LDAP認証は自動的に無効化されます。

- レポータ・インタフェースでユーザーのパスワードを変更することはできません。ただし、adminユーザーのパスワードは引き続き変更できます。前述のように、このパスワードはローカルで認証されるためです。

- 現時点で定義されているすべてのRUEIユーザーは無効になります。これには管理者権限を持つユーザーも含まれます(adminユーザーを除く)。

- Oracle SSO以外の既存のユーザー・アカウントを変更すると、ユーザー・アカウント名が小文字に変換されます。

- 現時点で定義されているパスワード・ポリシー設定(14.6項「パスワード・セキュリティ・ポリシーの強制」を参照)は、adminユーザーのみに適用されます。Oracle SSOサーバーでは独自に定義されたパスワード・ポリシーが強制されます。

- SSOサーバーが実行していない場合、または問題が発生している場合、ユーザーはログオンできません。

- Oracle SSOディレクトリにあるユーザー名は、RUEIに指定されているユーザー名と同じである必要があります。また、ユーザー名はRUEIでは小文字で格納されます。Oracle SSOユーザー名に含まれる大文字はRUEIでは自動的に小文字に変換されることに注意してください。

- 前述のように、adminユーザーは引き続きローカルで認証されます。ログオンするには次のURLを使用する必要があります。

https://Reporter/ruei/admin.php

- RUEIアプリケーションをSSOサーバーに登録するとき、ログアウトURLは次の形式で指定する必要があります。

https://hostname/ruei/index.php?frmWindow=wnd_logout&frmLogoutMode=initial

hostnameには適切なホスト名を指定します。

Oracle SSOサーバーのインストールと構成

Oracle SSOサーバーでユーザー認証を行うには、前もってOracle HTTPサーバーをインストールおよび構成する必要があることに注意してください。詳細な手順は、『Oracle Real User Experience Insightインストレーション・ガイド』の第7章を参照してください。

15 システムの監視およびメンテナンス

この章では、管理者が実行するタスクについて説明します。これには、システムのステータスの監視、バックアップおよびアップグレードの実行、イベント・ログの処理、システム・ユーザーの管理、データ保存ポリシーの構成が含まれます。

15.1 システムのステータスの監視

管理者は、システムの状態を確認し、ステータス・ページで自動ステータス監視メッセージを受信できます。このページにアクセスするには、「システム」→「ステータス」を選択します。例を図15-1に示します。

図15-1 「ステータス」ウィンドウ

ステータス・ページでは、接続されているコレクタのステータス、ログ・ファイル処理、システムにおける現在の処理レベル、レポータおよび処理エンジンのデータベース表領域に十分な領域があるかどうか、およびイベント・ログを確認できます。また、システム・ステータス・エラーが発生した場合に通知を受け取るユーザー(およびその方法)も構成できます。

コンポーネントの失敗の概要

図15-1に示す各コンポーネントは、現在のステータスを示しています。通常の運用では、これは「OK」とレポートされます。ただし、1つ以上のコンポーネントで「Error」とレポートされる場合は、表15-1の情報を使用して、問題の特定と解決を行ってください。

表15-1 レポートされたエラーの原因

コンポーネント

考えられる原因

コレクタ・ステータス

- レポータにコレクタが登録されていない。

- (1つまたは複数の)コレクタに接続の問題がある(ネットワークまたはSSH認証に関する問題など)。

- (1つまたは複数の)コレクタが動作していない。

- (1つまたは複数の)コレクタが頻繁にクラッシュする。

- 直近のログ・ファイル生成から10分を超える時間が経過している。

ログ・ファイル処理

- 直近のログ・ファイル処理から10分を超える時間が経過している。

データ処理

- データ処理が遅延している(つまり、直近のログ・ファイル更新から15分を超える時間が経過している)。

イベント・ログ

- (1つまたは複数の)未読のエラー・イベントがイベント・ログに報告されている。

使用可能なデータベース領域

- データベース領域の使用率が警告制限を超えている場合の警告ステータス。

- データベース領域の使用率がエラー制限を超えている場合のエラー・ステータス。

(15.4項「データベースおよびディスクの領域制限とアラートの構成」を参照)。

ディスク領域

- ディスク領域の使用率が警告制限を超えている場合の警告ステータス。

- ディスク領域の使用率がエラー制限を超えている場合のエラー・ステータス。

(15.4項「データベースおよびディスクの領域制限とアラートの構成」を参照)。

15.1.1 一時遅延およびアラート

図15-1に示したシステム・ステータス・インジケータが更新されるのは、ブラウザ画面のリフレッシュ時のみです。1つ以上のシステム・プロセスで障害が発生していることが検出されたときにシステム・アラートを生成するように設定できます(15.3項「システム障害アラートの構成」を参照)。このため、1つのプロセスに一時的に障害が発生していることが(赤いxによって)示されるが、アラートは生成されないという状況が生じる場合があります。これは、システム・プロセスがチェックされる時点までにシステム・ステータス・インジケータが正常状態に戻っていたことが原因です。

このような設計のため、アラートがトリガーされた場合は、システム障害が発生し始めているという警告とみなすことをお薦めします。障害は、デフォルトの境界よりもシステム遅延の方が長くなった結果、発生する場合があります。たとえば、監視対象の行がヒットした時点と、このヒットに基づく情報がレポータで使用可能になる時点との間の待機時間がそれほど長くない場合です。この待機時間が、トラフィックが多い環境における境界を超えている可能性があります。また、障害は、トラフィックが一時的にピークを示した結果である場合もあります。ただし、この状況が続く場合は、監視対象のトラフィック・レベルを確認することをお薦めします。

15.2 コレクタのステータスの表示

システムに接続された各コレクタのステータスを表示するには、「システム」→「ステータス」→コレクタ・ステータスを選択します。これにより、「ネットワーク・データ・コレクタ・ステータス」ウィンドウが開きます。例を図15-2に示します。

図15-2 「ネットワーク・データ・コレクタ・ステータス」ウィンドウ

「システム(ローカル・ホスト)」アイテムはレポータ・システム上のネットワーク・データ・コレクタ・インスタンスを表すことに注意してください。ネットワーク内の他のネットワーク・コレクタは、そのIPアドレスで表されます。目的のコレクタをクリックするか、またはコンテキスト・メニューから「統計の表示」を選択して、コレクタの監視対象トラフィックの詳細なレポートを表示します。例を図15-3に示します。

図15-3 「コレクタ統計」ウィンドウ

このウィンドウに表示される情報は、選択したコレクタについて午前0時以降またはカウンタのリセット以降に監視されたトラフィックを示します。ウィンドウの左下にある稼働時間フィールドは、コレクタが稼働している時間を示します。コレクタが構成を更新するために再起動されると、この稼働時間はリセットされます。ウィンドウに表示されているすべてのHTTPリクエスト・カウンタをリセットするには、「ビュー」メニューで「カウンタのリセット」を選択します。このカウンタが自動的にリセットされるのは、ネットワーク・パケットが次回検出されたときです。このため、ネットワーク・トラフィックが行われていないインストール環境の場合、カウンタはリセットされません。この表示は2秒ごとに自動的にリフレッシュされます。

「コレクタ統計」ウィンドウの使用

ウィンドウの左上部分にあるタブにより、選択したコレクタによって監視されたトラフィックの詳細なブレークダウンを確認できます。これについて表15-2で説明します。

表15-2 「コレクタ統計」レポートのタブ

タブ

説明

インタフェース

データ収集に使用可能なネットワーク・インタフェースについての情報を提供します。インタフェースの数とステータスはシステム構成によって異なります。タグ・サーバーの場合、インタフェースはIPに関連付けられ、ネットワーク・データ・コレクタはIPに関連付けられません。

標準的に構成されるインタフェースは表示されません。使用可能なネットワーク・インタフェースごとに、(ethx形式の)名前、使用状況(現在の帯域幅)および状態が表示されます。状態には、「OK」、「停止」、「未構成」、「非アクティブ」または「無差別ではない」(ネットワーク・アダプタが確認できるのはそのMACアドレスに送信されたトラフィックのみ)があります。

イーサネット

監視対象のポートを介して送信されるRAWパケット・データのブレークダウンを、そのプロトコル(IPv4やARPなど)および測定されたフレーム数として表示します。「切捨て」リストは、フレームが破損しているか削除されていることを示します。

TCP

TCPストリームの分析結果を示します。レポートされるカウンタは、次のとおりです。

- 処理中: 現在アクティブなTCPセッションの数。これには、現在データが転送されているセッション、まだ接続の確立段階のセッション、または切断手順が開始されているがまだ完了していないセッションがあります。このカウンタはネットワークの負荷を直接反映しています。

- 最大同時: コレクタが起動されてから「処理中」カウンタが到達した最大数。

- 接続リセット: TCP RESETセグメントによって終了されたセッションの数。このようなセッションは通信の両側によって即座に削除されます。これらのセッションでは、これ以上のデータは送信できません(切断手順の場合も含む)。

- 接続が拒否されました: リクエストしたサービスが存在していなかったために確立できなかったセッションの数。この状況が発生するのは、ピアが接続を確立しようとするシステム上のポートがリスニングされていない場合です。

- 合計: コレクタが起動してから実行されたセッションの合計数。

次のネットワーク・エラー・メーターも表示されます。

- 順序が間違っています: 順序が乱れて受信されたセグメント数を示します。このようなエラーのセグメント数が非常に多数ある場合、ピア間のネットワークの性能に問題が潜んでいることを示します。このネットワークは通常、クライアントPCとサーバー間のインターネットです。

- 無効なチェックサム: 破損の途中であるセグメントの数を示します。このような問題のセグメントの数が多い場合、ハードウェア、配線またはネットワークに問題が潜んでいることを示します。

- 無効なオフセットおよび/または長さ: 通知されている長さと比べると長さが正しくないパケットの数を示します。これで、破損したパケットが示されます。

- 削除されたセグメント: チェックサムや長さが正しくないなどの予期しない理由のために削除されたセグメントの合計数を示します。この値が常に高くなった場合は、ハードウェアおよびネットワークのアーキテクチャをチェックしてください。
複雑な構成においては、この値は、必要なトラフィックがコレクタのTAPデバイスに対して正確にルーティングされていないことを示す場合があることに注意してください。たとえば、2つのネットワーク・トランク(インバウンド・トラフィックおよびアウトバウンド・トラフィック用)を使用できますが、コレクタが認識できるのは1つだけです。この場合、TAPデバイスが両方のトランクに正しく接続されていることを確認する必要があります。また、VLANトランクが使用される構成(たとえば、インバウンド・トラフィックとアウトバウンド・トラフィックを分けるため)では、VLANトラフィックと非VLANトラフィックを混在させることはできません。

これらいずれかのメーターで問題が示されるときは、TCP診断機能を使用して可能性のある原因を特定することをお薦めします。

TCP診断

この機能の使用方法の詳細は、付録R「監視対象ネットワーク・トラフィックの確認」に記載されています。

HTTP

監視したHTTPストリームの分析結果を示します。特に、ストリームに含まれるリクエストのタイプ(GETやPOSTなど)を示します。

SSL接続

暗号化されたデータのパケットに使用されている暗号化メソッドをレポートします。具体的には、次のとおりです。

- SSLv2: SSLバージョン2の接続数(これらの接続の追跡はコレクタではサポートされません)。

- SSLv23: 混在モードのSSL接続の数(SSLバージョン2として開始されたが、接続の確立フェーズでこれより高いバージョン3に切り替えられたセッション)。コレクタはこれらの接続を追跡できないことに注意してください。

- SSLv3: SSLバージョン3の接続数。

- TLSv1: TLSバージョン1の接続数。

- TLSv1.1: TLSバージョン1.1の接続数

- TLSv1.2: TLSバージョン1.2の接続数

- その他: その他の接続(前述のいずれのカテゴリにも当てはまらない接続)の数。

SSL鍵管理に関するエラーがレポートされます。具体的には、次のとおりです。

- サーバー鍵がありません: リクエストしたサーバー接続用の秘密SSL鍵で、コレクタが使用できるものがありません。

- マスター鍵がありません: 接続のマスター鍵が計算できなかったために削除された接続の数。

- セッション鍵がありません。: 接続のセッション鍵がないために削除された接続の数。

(現時点で)サポートされていない暗号化メソッドは、次のとおりです。

- 純正のSSLv2: クライアントは純正のSSLバージョン2プロトコルを使用しています。これはコレクタではサポートされていません。

- エフェメラル: セッションは一時的な鍵を使用して暗号化を行います。このような鍵はコレクタが認識できないため、このようなセッションは追跡できません。

- 匿名DH: セッションは匿名のDiffie-Hellman鍵交換アルゴリズムに依存します。このような鍵はコレクタが認識できないため、このようなセッションは追跡できません。

- AEAD暗号: セッションはAEAD(Authenticated Encryption with Associated Data)暗号を使用しています。これらは、RUEI 12.1.0.6ではサポートされていません。

復号化エラー・ゲージは、復号化できなかった接続の数を示します。これには、マスター鍵を復号化できなかった、セッション鍵の計算が間違っていた、またはセグメントを復号化できなかったなどの複数の理由があります。

SSL暗号化

監視対象の暗号化データのブレークダウンを、採用された暗号化アルゴリズムの観点から示します。「使用中」列は、暗号化アルゴリズムを使用した監視対象のSSL暗号化トラフィック(割合)を示します。「エラー」列は、失敗した(読み取ることができなかった)測定対象のSSL暗号の割合を示します。

パフォーマンス

コレクタに対する影響をレポートします。ピークの負荷が100%に近づいた場合は、データがコレクタによって削除されないようにするためのアクションを即座に実行する必要があります。トラフィックのサンプリングは、13.4.3項「全体のトラフィックの制限」を参照してください。これでも問題が解決されない場合は、Oracleサポート・サービスに連絡することも必要になってきます。コレクタのメモリー使用率も示されます。最大メモリーしきい値は、レポータとコレクタが両方ともあるシステムの場合は30%、コレクタのみのシステムの場合は70%です。

SSLトラフィックおよびFormsトラフィックの監視

SSLトラフィックおよびOracle Formsトラフィックは、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。

したがって、各コレクタが信頼性の高いネットワーク・デバイス(TAPなど)に接続されることを確認する必要があります。また、「コレクタ統計」ウィンドウに表示される情報を定期的に調べて、TCPパケット・ストリームが正常な状態であることを確認するように強くお薦めします。TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。

15.3 システム障害アラートの構成

KPIおよびSLAの違反に関する通知を受信できるのみでなく、システム障害のアラートを構成することもできます。そのようにすることを強くお薦めします。システム・アラートを使用すると、システムの問題(コレクタの障害など)に際してすぐにアクションを実行できるだけでなく、外部の深刻な問題(DoS攻撃など)を示すためにも役立ちます。それには、「システム」→「ステータス」→「ステータス通知」の順に選択します。表示されるダイアログは、7.5.1項「アラート・プロファイル」に示したダイアログに似ています。

基本的に、図15-1に示すインジケータ(1つまたは複数)が警告またはエラーのステータスをレポートするイベントによって、システム・アラートがトリガーされます。たとえば、コレクタ・ステータスのアラートは、コレクタが使用できないかコレクタの障害が発生していることを示します。

重要:

特に次の点に注意することをお薦めします。

- 構成された受信者には、データベース領域およびディスク領域の使用率の警告とエラーも通知されます(15.4項「データベースおよびディスクの領域制限とアラートの構成」を参照)。

- システム・ステータスのアラートでは、アラートのスケジュールやエスカレーション・レベルは考慮されません。アラートを構成するときは、受信者のすべての情報(電子メール・アドレスや電話番号など)を正しく指定してください。また、システム・ステータスのチェックが10分ごとに実行されることにも注意してください。このため、図15-1のページにシステム障害が表示された場合、その障害に関するアラートをすぐには受信せず、スケジュールされたシステム・チェックが実行されたときに受信することがあります。

- イベント・ログのアラートの場合、15.7項「イベント・ログの使用」で説明するように、レポートされたイベントを確認することをお薦めします。イベント・ログ・インジケータのステータスを「OK」に戻すためには、イベント・ログの警告またはエラーを読取り済としてマーキングする必要があることに注意してください。

- コレクタ・ステータスのアラートの場合、「コレクタ統計」ウィンドウ(15.2項「コレクタのステータスの表示」を参照)を使用して問題をトラブルシューティングすることをお薦めします。

- 他のエラーまたは警告の際(あるいはエラーや警告が長く続く場合)は、カスタマ・サポートに連絡してください。

SNMPトラップ通知

KPIおよびSLAの違反のように、SNMPトラップを使用してシステム・イベント通知を送信するように構成できます。この場合、イベント・ログでレポートされる各イベント(15.7項「イベント・ログの使用」を参照)は、独立したSNMPトラップになります。

システム・イベントに対してSNMPトラップを構成する手順は、次のとおりです。

1. 「システム」→「ステータス」→「ステータス通知」の順に選択します。「システム・ステータス監視」画面が表示されます。

2. SNMPタブをクリックします。図15-4に示すダイアログが表示されます。

図15-4 「システム・ステータス監視」ダイアログ

3. 「有効」および「イベント・ログ監視」チェック・ボックスが選択されていることを確認してください。そうしないと、システム・イベントに対してSNMPトラップは生成されないことに注意してください。

4. 「イベント・ログ送信制限」フィールドを使用して、1分間に送信されるSNMPトラップの最大数を指定します。この機能は、受信側のSNMPマネージャに大量のトラップが過度に送信されるのを防ぐのに役立ちます。たとえば、1分間に500件のイベントがレポートされる場合について考えます。原則として、これらはそれぞれ独立したSNMPトラップになります。ただし、送信制限が100に設定されている場合は、最も深刻な100件のイベントのみがSNMPトラップとして生成されます。

5. ダイアログにある別のフィールドの使用方法は、7.5.6項「SNMP通知の使用方法」を参照してください。

6. 管理情報ベース(MIB)定義をダウンロードし、管理対象オブジェクトのアドレス帳に取り込みます。この定義には、受信したSNMPメッセージの解釈方法に関して必要な情報が含まれています。MIBファイル(oracle-ruei.mib)は、RUEI/extraディレクトリのRUEIインストールzipファイル内でも使用できます。

15.4 データベースおよびディスクの領域制限とアラートの構成

システムが中断しないで運用されるようにするために、使用可能なデータベース領域およびディスク領域の使用率に上限を設定します。データベースの使用率が上限に達すると、管理メカニズムによってデータベースのサイズが許容された境界内に戻るまで、新しいデータが書き込まれなくなります。同様に、ディスク領域使用量が最大レベルに達すると、コレクタが停止し、管理者が既存ファイルの削除処理を行うまで、(ログ形式の)データはファイル・システムに書き込まれません。この結果、進行中のセッションの情報が失われ、フル・セッション・リプレイ(FSR)・データも同様です。さらに、これらのいずれかの問題が発生しそうな場合にアラートを生成するように設定することも可能です。

重要:
RUEIを熟知していて、これらの設定の用途と効果を明確に理解している場合にのみ、デフォルト設定を変更することを強くお薦めします。

データベース領域またはディスク領域のしきい値を定義する手順は、次のとおりです。

1. 「構成」→「一般」→「詳細設定」→「データベース/ディスク領域の使用率」の順に選択します。図15-5に示すしきい値選択パネルが表示されます。

図15-5 データベース領域とディスク領域のしきい値

2. 目的のしきい値を選択します。図15-6に示すようなダイアログが表示されます。

図15-6 データ保存の変更

3. アラートのしきい値の場合には、このダイアログを使用してデータベース領域またはディスク領域の最大使用率を指定し、その使用率を超えたらアラートが生成されるようにします。生成されたアラートは同じ受信者に送信され、システム障害アラートに定義した通知メカニズム(15.3項「システム障害アラートの構成」を参照)と同じ通知メカニズムが使用されます。停止のしきい値の場合には、データベース領域またはディスク領域の最大使用率を指定し、その使用率を超えたらデータベース処理またはデータ収集が停止するようにします。次に、「保存」をクリックします。指定した変更は、即座に有効になります。

しきい値の定義

しきい値を定義するときには、次の点に注意してください。

- データベース領域またはディスク領域の使用を停止するために指定可能な最大設定は、95%です。これは、使用可能なディスク領域が完全に(100%)いっぱいになった場合、システム上の他のコンポーネントが動作しなくなることがあるためです。また、システムへのリモート・ログオンができなくなる可能性もあります。同様に、データベースが完全にいっぱいになることを許可した場合には、そのサイズを削減するための管理メカニズムが動作できなくなります。

- 指定したしきい値は、RUEIで使用されるすべてのパーティションに適用されます。つまり、/var/opt/ruei、およびその下にマウントされたすべてのパーティションです。少なくとも1つのパーティションが指定されたしきい値に達すると、アラート・メカニズムおよび停止メカニズムがトリガーされます。

- 定義されたしきい値のチェックは、絶えず実行されるのではなく、10分ごとに実行されます。したがって、チェックが実行されてアラートが発行されるまでに、データベース領域またはディスク領域の使用率が指定されたしきい値をすでに上回っている場合もあります。そのため、しきい値は、意図したターゲットより少し低く設定することをお薦めします。たとえば、ディスク領域の停止しきい値は95%でなく93%か94%に設定します。

- アラート通知しきい値は、関連する停止しきい値より高い値に設定することはできません。たとえば、データベースの停止しきい値が95%の場合には、アラートしきい値をそれより高い値に設定することはできません。

- デフォルトでは、アラートしきい値は85%、停止しきい値は95%です。

- Linuxオペレーティング・システムでも、ディスク領域使用率の制限は95%です。この制限に達すると、ディスクに書き込めるのはrootユーザーのみとなります。RUEIにはこの権限がないため、ディスク領域をそれ以上使用できなくなります。

15.5 トラフィック・サマリーの表示

監視対象のネットワーク・トラフィックの概要を開くには、「システム」→「ステータス」→「データ処理」の順に選択します。これにより、ヒット、ページ、セッション処理および各処理ユニットのシステム・ロードに関する情報が即座に表示されます。例を図15-7に示します。

図15-7「データ処理」ダイアログ

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

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

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

15.6 構成バックアップの作成とリストア

システムの現在の構成のバックアップを作成したり、必要に応じてそのバックアップをリストアできます。バックアップは定期的に作成することをお薦めします。バックアップにはシステム設定のみが含まれることに注意してください。セキュリティ上の理由により、SSL鍵と収集されたデータは含まれません。

バックアップを作成またはリストアする手順は、次のとおりです。

1. 「システム」→「メンテナンス」→「バックアップおよびリストア」の順に選択します。図15-8に示すダイアログが表示されます。

図15-8 「バックアップおよびリストア」ダイアログ

2. ラジオ・ボタンを使用して、必要な操作を選択します。次に、「次へ」をクリックします。

3. 図15-8の「ファイルからのシステムのリストア」オプションを選択した場合、図15-9に示すダイアログが表示されます。

図15-9 「システム・リストア」ダイアログ

「参照」をクリックして、必要なバックアップ・ファイルを検索および選択します。

デフォルトでは、コレクタと処理エンジンに関する管理情報はリストアされません。「コレクタ」と「処理エンジン」のチェック・ボックスを使用すれば、この情報がリストアされるように指定することができます。バックアップを作成した時点でシステムに構成されており、その後で削除されたコレクタと処理エンジンが、リストア後のシステムには追加されることに注意してください。同じように、現在システムで構成されており、バックアップ作成時には構成されていなかったコレクタと処理エンジンは無効化されます。次に、「次へ」をクリックします。

4. 図15-8の「ファイルへのシステムのバックアップ」オプションを選択した場合、ブラウザの構成方法によって、zipファイルの保存場所の指定を求めるメッセージが表示されるか、定義済のデフォルトの場所にファイルがすぐに保存されます。

重要:

- 生成されるバックアップ・ファイルには、Oracleサポート・サービス専用の大量の情報が含まれます。このファイルの内容を変更しないでください。リストアを実行するときは、現在のすべての設定がリストアされる設定で上書きされることに注意してください。

- バックアップからリストアを実行した後、すべての必要なSSL鍵をすぐにアップロードする必要があります。これは、すべての既存のSSL鍵が削除され、バックアップ・ファイルに含まれないためです。

15.7 イベント・ログの使用

RUEIでは、15.1項「システムのステータスの監視」で説明されているステータス情報の他に、イベント・ログが保持されます。これには、すべてのシステム・イベントのレコードが含まれます。ユーザーもカスタマ・サポートも、イベント・ログを使用することで、RUEIインストールで発生する可能性のある問題をすぐに特定して解決できます。

イベント・ログの内容を定期的に確認することをお薦めします。イベント・ログに未読のエラー・メッセージが含まれる場合、「ステータス」パネルの「イベント・ログ」項目にエラー・アイコンが表示されます。ほとんどのイベントはすぐにレポートされますが、コレクタ関連のイベントはレポートされるまで最大で5分かかることに注意してください。

イベント・ログを確認する手順は、次のとおりです。

1. 「システム」→「ステータス」→「イベント・ログ」の順に選択します。図15-10に示すようなダイアログに最近のイベントが表示されます。

図15-10 イベント・ログ

2. ツールバーのコントロールを使用して、イベントのリストをスクロールします。表示される各ログ・ページには、レポートされるイベントが最大100件まで含まれます。デフォルトでは、すべてのイベント・タイプが表示されます。ただし、「重大度」メニューを使用すると、選択したカテゴリのみに制限してリストを表示できます。イベントの潜在的な影響は、表15-3で説明している重大度によって示されます。

図15-3 イベントの重大度

重大度

説明

情報

ユーザーが開始したアクションを示します。たとえば、コレクタの再起動、新規ユーザー・アカウントの作成、構成のバックアップまたはリストアがあります。

警告

RUEIインストールの障害を引き起こす可能性があるイベントを示します。たとえば、レポータ・システムのディスク領域が不足しかけている、またはログ・ファイルの処理でバックログが増えている場合です。

エラー

RUEIインストールが完全には作動しなくなるイベントを示します。たとえば、リモート・コレクタが使用できなくなる場合です。

デバッグ

イベントに関する詳細な情報を表示します。

また、「ステータス」メニューを使用すると、レポートされるすべてのイベントを表示したり、新しい(未読)イベントのみに表示リストを制限したりできます。

注意:
5分間の期間内に同じイベントが複数回発生した場合は、レポートされるイベント内にリピート・カウンタが表示されます。

3. 必要に応じて、「イベント」メニューで、表15-4に示すオプションを選択できます。

表15-4 「イベント」メニュー・オプション

オプション

説明

すべてのイベントを既読としてマーク

表示されたイベント・リストを、ログを開いてから発生したイベント情報を使用して更新します。ツールバーの「リロード」アイコンをクリックしても同じ操作を実行できます。

リロード

表示されたイベント・リストを、ログを開いてから発生したイベント情報を使用して更新します。ツールバーの「リロード」アイコンをクリックしても同じ操作を実行できます。

閉じる

イベント・ログを閉じます。

4. 表示されているイベントをクリックすると、その詳細を表示できます。図15-11に示すようなダイアログが表示されます。

図15-11 イベント・ログ・エントリの例

このダイアログでは、完全なイベント・テキストと関連するイベント・コードが表示されます。カスタマ・サポートに問い合せるときには、これら両方を指定する必要があることに注意してください。リモート・コレクタの場合、レポートされるソースはコレクタのIPアドレスです。

15.8 テキスト・メッセージ・プロバイダの構成

RUEIでは、テキスト・メッセージ通知の使用がサポートされています。この機能を使用するには、使用するすべてのテキスト・メッセージ・プロバイダを構成してシステムに認識させる必要があります。プロバイダ情報を管理するには、「システム」→「メンテナンス」→「テキスト・メッセージ・プロバイダ」の順に選択します。図15-12に示すダイアログが表示されます。

図15-12 「テキスト・メッセージ・アカウント」ダイアログ

テキスト・メッセージ・プロバイダを構成する手順は、次のとおりです。

1. 「新規アカウントの追加」をクリックして、新規テキスト・メッセージ・プロバイダを定義します。図15-13に示すダイアログが表示されます。

図15-13 「テキスト・メッセージ・プロバイダの選択」ダイアログ

2. リストから目的のテキスト・メッセージ・プロバイダを選択します。リストには、サポートされている事前定義済のサービスが多数用意されています。これらの各サービスを使用するには、該当するプロバイダのアカウントが必要です。次に、「次へ」をクリックします。図15-14に示すようなダイアログが表示されます。

重要:
「ローカルGSMモデム」を指定する場合は、システムにGSMモデムを装着しておく必要があります。装着が必要なローカル・モデムは、USBまたはシリアルGSM ETSI 07.05準拠のモデムです。

図15-14 「アカウント詳細」ダイアログ

3. ダイアログに表示される正確なフィールドは、図15-13で選択したプロバイダによって異なります。たとえば、「ローカルGSMモデム」を選択した場合は、ローカル・ポートとモデムのボー・レートを指定する必要があります。不明な場合は、自動検出を使用できます。オプションで、SIM PINも指定できます(必要な場合)。

4. 事前定義済のMollieまたはClickatellサービスを選択した場合は、アカウントのユーザー名、パスワード、作成者、API IDおよびプロトコル送信メソッドを指定する必要があります。これらの情報は、アカウント・プロバイダによって提供されます。次に、「保存」をクリックします。図15-12に示すダイアログ・ボックスに戻ります。

5. リストでプロバイダを右クリックし、「上に移動」および「下に移動」オプションを使用してリスト内のプロバイダの位置を制御します。プロバイダは、リストでの順序どおりに試行されます。つまり、最初のアカウントが試行され、それが失敗すると2番目のアカウントが試行されます(それ以降についても同様)。

6. 次に、「閉じる」をクリックしてダイアログを閉じます。

Unicodeサポート

テキスト・メッセージではUnicodeがサポートされていますが、多数の制限事項があることを認識しておく必要があります。ローカルに装着したモデムの場合では、7ビットGSM 3.38アルファベットを使用してメッセージが送信されます。サポートされていない文字が元のメッセージに含まれる場合は、疑問符(?)文字に置換されます。外部サービス・プロバイダの場合は、マルチバイト・キャラクタ・セットのサポートに関してサービス・プロバイダに問い合せることをお薦めします。ローカルに装着したモデムと外部サービス・プロバイダの両方で、テキスト・メッセージは160文字に制限されます。

15.9 ヘルプデスク・レポートの作成

RUEIの使用または操作に関して問題が発生した場合は、Oracleサポート・サービスに問い合せることができます。ただし、その前に、ご使用のシステムのヘルプデスク・レポート・ファイルを作成することをお薦めします。これを実行するには、「システム」→「メンテナンス」→「ヘルプデスク・レポート」の順に選択します。ヘルプデスクの作成に時間がかかる場合があります。完了すると、ファイルのダウンロード先となる場所を指定するように求められます。

ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。

重要:
生成されたファイルには、ソフトウェアの所有権情報が含まれます。コンテンツを変更しないでください。

15.10 セッション・デバッグ・モードの操作

デフォルトでは、内部エラーは次のような汎用エラー・メッセージでユーザー・インタフェース内に表示されます。

An internal system error has occurred. Please contact the Administrator with the error details.

しかし、エラーの詳細が必要な場合には、次の手順を実行して、セッション・デバッグを有効にすることができます。

1. 「ヘルプ」メニューから「セッション・デバッグ」オプションを選択します。図15-15に示すダイアログが表示されます。

図15-15 「セッション・デバッグ」ダイアログ

注意:
「セッション・デバッグ」オプションが「ヘルプ」メニューに表示されるのは、RUEI管理者ユーザーとしてログインした場合のみです。

2. デバッグ・モードを有効にするよう指定するには、「デバッグの有効化」チェック・ボックスをオンにします。次に、「保存」をクリックします。

有効にすると、詳細なエラー・メッセージがレポートされます。また、メッセージ(および対応する診断情報)は指定されたログ・ファイルにも追加されます。この設定が適用されるのは、現在のセッションのみです。

注意:
カスタマー・サポートにエラーを報告する際には、セッション・デバッグの機能を有効にすることをお薦めします。

15.11 電子メール構成の管理

2.3項「メーリング機能の使用方法」で説明しているように、RUEIでは要求されたレポートの自動電子メールを送信できます。この機能では、初期構成フェーズ(『Oracle Real User Experience Insightインストレーション・ガイド』を参照)で指定した情報を利用します。ただし、「システム」→「メンテナンス」→「電子メール設定」の順に選択して、この構成を変更できます。図15-16に示すダイアログが表示されます。

図15-16 「電子メール設定」ダイアログ

図15-16に示すフィールドを表15-5で説明しています。

表15-5 「電子メール設定」のフィールド

フィールド

説明

返信用アドレス

失敗した電子メールまたは問題が発生した電子メールのレポート先となる電子メール・アドレスを指定します。このアドレスを定期的にチェックすることを強くお薦めします。

送信元アドレス

受信者のメール・クライアントに表示されるアドレスを指定します。

返信先アドレス

ユーザーが電子メール内でクリックして返信できるアドレスを指定します。これが指定されていない場合は、「送信元アドレス」設定が使用されます。

メール・サイズ制限

電子メールの最大許容メッセージ・サイズ(KB単位)を指定します。電子メールにこの制限を超えるレポートが含まれる場合は、この制限に対応するために、レポートが個別の電子メールに分割されます。個別に送信するには大きすぎるレポートは送信されず、ユーザーに問題が通知されます。デフォルトのメール・サイズ制限は5000KBです。

レポータURL

電子メールの受信者がレポータ・システムに接続するために必要となる詳細なURLを指定します。通常、このURLは、RUEIユーザーがレポータ・システムにアクセスするために使用するURLと同じです。

15.12 システムのリセット

原因不明の問題が発生した場合は、処理が適切に動作して同期化されるように、処理をリセットできます。ただし、このオプションを選択すると、データの可用性と監視に一時的な遅延が発生します。

最後の手段として、収集されたすべてのデータをシステムから削除できます。また、すべてのパラメータ(作成されたユーザーや環境パラメータなど)をデフォルト値にリセットできます。

システムをリセットする手順は、次のとおりです。

1. 「システム」→「メンテナンス」→「システム・リセット」の順に選択します。図15-17に示すダイアログが表示されます。

図15-17 システム・リセット・ウィザード

2. 目的のオプションを選択します。これらは表15-6で説明しています。

表15-6 「システム・リセット」のオプション

オプション

説明

最新構成の再適用

すべての構成変更(ruei.conf構成ファイルへの変更など)を即座に有効にします。これがデフォルトです。

システム処理の再起動

システム処理を再アクティブ化します。

収集したデータのパージ

収集されたすべてのデータをシステムから削除します。

出荷時のデフォルトにリセット

収集されたすべてのデータとSSL鍵を削除し、すべてのシステム・パラメータをデフォルト値にリセットします。

次に、「次へ」をクリックします。

注意:
「収集したデータのパージ」および「出荷時のデフォルトにリセット」オプションは、実行すると取消しできません。収集されたすべてのデータが消去されます。「出荷時のデフォルトにリセット」の場合、すべてのシステム設定も元の状態に戻ります。したがって、レポータ・インタフェースにアクセスするには、初期構成をすべて(およびset-admin-password.shスクリプトを使用したadminユーザー・パスワードの定義)行うことが必要になります。以前にバックアップを作成している場合(15.6項「構成バックアップの作成とリストア」を参照)は、初期構成後にそのバックアップをリストアできます。この初期構成の手順は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。

15.13 データ変換のカスタマイズ

特定の要件に合わせて、データ・アイテム(データ・ブラウザ・グループ、フィールド名など)をカスタマイズできます。RUEIカタログの動作方法について正しい知識を持っている場合のみ、この機能を使用することをお薦めします。

デプロイメントで使用するデータ変換をカスタマイズするには、次の手順を実行します。

1. 「構成」→「一般」→「詳細設定」→「データ変換」の順に選択します。カタログ・リストが表示されます。

2. 適切なデータ・アイテムをクリックします。図15-18に示すダイアログが表示されます。

図15-18 「表示値の編集」ダイアログ

3. 優先する変換を指定します。「デフォルトに戻す」をクリックすると、出荷時のデフォルトにアイテムをリセットできます。次に、「保存」をクリックします。

A タグ付け規則

この付録では、RUEI用にサポートされる一般的なページおよびサービスのタグ付け規則について説明します。

A.1 ページのタグ付け規則

タグの一致は表A-1内での出現順に行われることに注意してください。つまり、上にある行との一致は下にある行との一致より先に行われます。一致スキームに関する情報は、次の項を参照してください。

表A-1 ページ・タグの一致

タグ

スキーム

構造脚注1

Clicktracks

C

C

'?i=%'

"?i=%"

Coremetrics

C

C

C

C

C

PageID[\t ]*=[\t ]*'%'

PageID[\t ]*=[\t ]*"%"

cmCreateTechPropsTag('%'

cmCreateTechviewTag('%'

cmCreateProductviewTag ('[0-9]*',[\t ]*'%'

カスタム関数

(TAGNAMEが関数名)

C

C

TAGNAME[\t ]*([\t ]*'%'

TAGNAME[\t ]*([\t ]*"%"

カスタム・タグ

(TAGNAMEがタグ名)

C

C

C

<TAGNAME>%</TAGNAME>

TAGNAME[\t ]*=[\t ]*'%'

TAGNAME[\t ]*=[\t ]*"%"

Google

C

C

C

C

_uccn[\t ]*=[\t ]*'%'

_uccn[\t ]*=[\t ]*"%"

_setCampNameKey[\t]*'%'

_setCampNameKey[\t]*"%"

Hitbox

C

C

hbx.pn[\t ]*=[\t ]*'%'

hbx.pn[\t ]*=[\t ]*"%"

Intellitracker

C

C

pqry[\t ]*=[\t ]*'%'

pqry[\t ]*=[\t ]*"%"

Omniture

C

C

pageName[\t ]*=[\t ]*'%'

pageName[\t ]*=[\t ]*"%"

Oracle脚注2

C

C

C

C

A

A

orainfo.page[\t ]*=[\t ]*'%'

orainfo.page[\t ]*=[\t ]*"%"

mfinfo.page[\t ]*=[\t ]*'%'

mfinfo.page[\t ]*=[\t ]*"%"

mfinfo.page=%

page=%

Sitestat

C

C

'http://[a-z0-9.-]+/[a-z0-9%.+_-]+/[a-z0-9%.+_-]+/s?%'

"http://[a-z0-9.-]+/[a-z0-9%.+_-]+/[a-z0-9%.+_-]+/s?%"

Title

C

C

C

C

<title[^>]*>%</title>

<h1[^>]*>%</h1>

<h2[^>]*>%</h2>

<h3[^>]*>%</h3>

URL-structure

Webtrekk

C

C

wt_be[\t ]*=[\t ]*'%'

wt_be[\t ]*=[\t ]*"%"

Webtrends

C

C*

<meta[\t ]+name="WT.cg_n"[\t ]+content="%"

<meta[\t ]+name="WT.cg_s"[\t ]+content="%"

XiTi脚注3

C

C

xtpage[\t ]*=[\t ]*'%'

xtpage[\t ]*=[\t ]*"%"

脚注1 *は0(ゼロ)個以上の任意の種類の文字です。%は文字列の一致部分です。

脚注2 非推奨のMoniforce社のタグが含まれています。これは、すべてのOracle製品で自動的に動作するわけではありません。

脚注3 ページ・グループのセパレータとして、パイプ文字(|)の他に::も指定できます。

ページ・グループ・セパレータ

表A-1にリストしたすべてのページ・タグ付けスキームについて、タグ内でページ・グループ・セパレータとしてパイプ文字(|)を指定できます。

一致スキーム

Cはコンテンツ内での一致です(*は任意の部分)。

AはURL内の引数との一致です。

%は文字列の一致部分です。

[...]*は0(ゼロ)回以上の出現を示します。

[...]+は1回以上の出現を示します。

[^...]*は、0回以上の排他的(...でない)出現を示します。

\tはタブ文字を示します。

注意:
タグの一致では大/小文字が区別されます。

A.2 サービスのタグ付け規則

サービス・タグの一致は表A-2のように行われます。

表A-2 サービス・タグの一致

タグ

スキーム

説明

WebDAV

H

サポートされる次のHTTPメソッドと一致します。ACL、CONNECT脚注1、LOCK、MKCOL、MOVE、OPTIONS、PROPFIND、PROPPATCH、PUT、REPORT、SEARCH、TRACEおよびUNLOCK。

脚注1 デフォルトでは、RUEIはすべてのGET、POSTおよびCONNECTメソッドをサポートします。

B Cookieの構造

この付録では、RUEIでサポートされるCookieテクノロジの概要を示します。

RUEIによってユーザーのWeb環境を正確に監視するには、RUEIがユーザーのWebサイトで使用されているCookieテクノロジを把握している必要があります。Cookieテクノロジの指定方法の詳細は、12.2項「セッション・トラッキング・メカニズムの指定」を参照してください。

表B-1に、サポートされているCookieテクノロジの構造を示します。

表B-1 Cookieの構造

テクノロジ

構造脚注1

ADF脚注2

JSESSIONID=%

Apache

Apache=%

ASP

ASPSESSIONID*=%

ASP.NET_SessionId*=%

ColdFusion

CFTOKEN=%

Google

__utma=%

JD Edwards脚注2

JSESSIONID=%

Oracle脚注3

OraTrack=%

MfTrack=%

mf_sess=%

Oracle Access Manager(OAM)

ObSSOcookie脚注4

Oracle FLEXCUBE Universal BankingおよびDirect Banking

PHPSESSID=%

PeopleSoft脚注2

ps_token=%

PHP

PHPSESSID=%

Siebel脚注2

_sn=%

WebLogic Portal(WLP)脚注2

JSESSIONID=%

WebSphere

JSESSIONID=%

(カスタム)

CUSTOMNAME脚注5=%

(URL引数)

URLARGUMENT脚注6=%

脚注1 *は0(ゼロ)個以上の任意の種類の文字です。%は文字列の一致部分です。

脚注2 これらは事前定義済カスタムCookieとして実装されています。

脚注3 タグ・ベースのアプリケーションに使用されます。非推奨となったMoniforceのCookieも含まれます。これは、すべてのOracle製品で自動的に動作するわけではありません。

脚注4 デフォルトのCookie名です。

脚注5 CUSTOMNAMEはCookie名です。

脚注6 URLARGUMENTはURLの引数名です。この詳細は、次の項に記載されています。

B.1 URL引数を使用したセッションの追跡

URL引数をユーザー・セッションの追跡に使用するように指定すると、指定された引数について最初にオブジェクトのURLがチェックされます。見つからない場合、指定された引数が親ページのURLで検索されます。

オブジェクトのURLと親ページのURLの両方で、次の例のURL構文が仮定されます。

www.domainname.com/sitename/shop;URLARGUMENT=blabla?......

指定されたURL引数が見つからない場合は、次のURL構文が仮定されます。

www.domainname.com/sitename/shop?URLARGUMENT=blabla&......

C トラブルシューティング

この付録では、RUEIの使用時に発生する最も一般的な問題を取り上げ、それらの問題を見つけて修正するための解決方法を示します。Oracleサポート・サービスに問い合せる前に、この付録の内容を確認してください。

C.1 オラクル社のWebサイト

様々なトピックの詳細は、RUEI Webサイト(http://www.oracle.com/enterprise_manager/user-experience-management.html)を参照してください。定期的にこのサイトにアクセスしてサポートの告知を確認することをお薦めします。

さらに、Oracleサポート・サービスのWebサイトでは詳しい技術情報を公開しています(https://metalink.oracle.com)。このサイトには、使用可能なサービス・パック、FAQ、トレーニング資料、ヒントとテクニック集および最新バージョンの製品ドキュメントが含まれます。

C.2 Oracleサポート・サービスへの問合せ

RUEIの使用または操作に関して問題が発生した場合は、Oracleサポート・サービスに問い合せることができます。ただし、その前に、ご使用の構成のヘルプデスク・レポート・ファイルを作成することをお薦めします。これを実行するには、「システム」→「構成」→「ヘルプデスク・レポート」の順に選択します。ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。

C.3 一般的な(固有でない)問題

『Oracle Real User Experience Insightインストレーション・ガイド』の「トラブルシューティング」を参照してください。

レポータ・モジュールで問題が発生したり、そのインタフェースが不安定な場合は、次の操作を実行することをお薦めします。

- ブラウザ内のすべてのキャッシュをクリアし、ブラウザを再起動します。

- エラー・ログを調べます。この詳細は、15.7項「イベント・ログの使用」に記載されています。

- レポータがインストールされているシステムを再起動します。

C.4 起動に関する問題

RUEIが開始しない場合や正しいポートをリスニングしない場合は、次の操作を実行してください。

- ネットワーク・フィルタ定義を確認します。この詳細は、13.4項「ネットワーク・フィルタの定義」に記載されています。特に、通常のネットワーク・フィルタが適用されていないことを確認してください。これは、VLANの場合に特に重要です。

- RUEIが正しいプロトコルとポートをリスニングしていることを確認します。これについては、13.3項「ネットワーク・ベース監視の有効範囲の管理」で説明します。

C.5 レポートされるデータの遅延

すべての監視対象トラフィックのレポートには遅延があることを理解しておく必要があります。ダッシュボードに表示される情報(いわゆるリアルタイム・データ)では、この遅延は5分です。その他大部分のデータ・ビュー(つまり、セッションベースのデータ)では、この遅延は15分です。ただし、全ページ・ビューと失敗したURLビューの2つは例外です。これらの遅延は両方とも5分です。リアルタイム・データのレポートとセッションベースのデータのレポートの内容に、わずかな相違があることに直面したときに備えて、これらのデータの違いを理解しておくことは重要です。この詳細は、3.2.1項「リアルタイム・データとセッションベースのデータ」に記載されています。

C.6 SNMPアラートに関する問題

SNMPアラートに関する問題(必要なユーザーがアラートを受信できないなど)が発生した場合は、次の操作を実行することをお薦めします。

- SNMP通知設定を十分に確認します。特に、マネージャのアドレスが正しいこと、必要なMIB定義をダウンロードして実装していること、およびそのSNMP通知が有効化されていることを確認してください。この詳細は、15.3項「システム障害アラートの構成」に記載されています。

- 最新バージョンのMIBファイルをダウンロードしてインストールしていることを確認します。

- 受信者のネットワーク接続をチェックします。

- SNMPマネージャの構成をチェックします。

また、SNMPアラートのKPI名がUTF-8で指定されていること、および一部のSNMPマネージャがUTF-8を完全サポートしていないことに注意してください。詳細は、ご使用のSNMPマネージャの製品ドキュメントを参照してください。

C.7 テキスト・メッセージ・アラートに関する問題

テキスト・メッセージ・アラートに関する問題が発生した場合は、次の操作を実行することをお薦めします。

- テキスト・メッセージ通知設定を十分に確認します。この詳細は、7.5.7項「テキスト・メッセージ通知の使用方法」および15.3項「システム障害アラートの構成」に記載されています。

- レポートされた問題についてテキスト・メッセージ・プロバイダに問い合せます。

- モデムが正しく機能していることを確認します。

C.8 タイムゾーンに関する問題

レポータ内のレポート時間に関する問題が発生した場合は、目的のタイムゾーンが/etc/php.iniファイルの[Date]セクションに明示的に設定されていることを確認してください。この詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。また、次のコマンドを使用してApache Webサーバーを再起動(rootとしてログオン)する必要があります。

httpd -k restart

C.9 データの監視が停止していると思われる状況

大量のトラフィックを監視している場合は、レポートされたデータから、RUEIでネットワーク・トラフィックが監視されなくなったか、遅延が発生しているように見えることがあります。例を図C-1に示します。

図C-1 レポートされたネットワーク・トラフィックの激減

このレポートによると、ネットワーク・トラフィックの監視が19:00に停止したことが示されています。実際、この状況はRUEIシステムの過負荷が原因で発生しています。トラフィックは継続して監視されていますが、トラフィックが大量で、対応に十分なリソースがないため、生成するコレクタ・ログ・ファイルを処理できなくなっています。

この状況を確認するには、「システム」→「メンテナンス」→「データ処理」の順に選択し、「パフォーマンス」タブをクリックします。レポートされたシステム・ロードが100%に近づいている場合は、システムは過負荷状態になっています。この機能の使用方法の詳細は、15.5項「トラフィック・サマリーの表示」に記載されています。

システムが恒久的に過負荷状態にならないように、RUEIでは、午前0時から約30分間、前日のすべてのコレクタ・ログ・ファイルの処理を自動的に停止します。これにより、バックログを廃棄してRUEIを標準の処理レベルに戻すことができます。

図C-1に示す状況が継続する場合は、ネットワーク・フィルタを使用して監視対象トラフィックを制限することをお薦めします。この詳細は、13.4.3項「全体のトラフィックの制限」に記載されています。また、RUEIシステムに追加リソースを割り当てることも検討してください。

C.10 コレクタがクラッシュするとコア・ダンプが生成されない

コレクタのインスタンスがクラッシュしたときは、コア・ダンプが生成されません。ただし、コア・ダンプを取得できても、ユーザーの問題にはカスタマ・サポートでしか解決できないものがあります。コレクタ・システムのコア・ダンプを有効にする手順は、Oracle Real User Experience Insightアドバンスト管理者ガイドに記載されています。

C.11 イベント・ログでの強制コア・ダンプのレポート

Thread deadlock detected in the log file processor; forcing a core dump.This may be caused by insufficient system memory.

このエラーがイベント・ログに記録された場合は、次を実行します。

- このメッセージが不定期に出現する場合は、RUEIソフトウェアのバグが原因である可能性があります。関連するイベントの詳細とともにカスタマ・サポートに問い合せてください。

- このメッセージが毎晩(またはほぼ毎晩)出現する場合は、高レベルのメモリー・スワップが発生するときにシステムが過負荷になっていることを示す可能性があります。この場合、システムへのメモリーの追加を検討する必要があります。

C.12 メモリー割当てエラー

次のエラーがイベント・ビューアでレポートされます。

linux.c, 326,cap_dev_set_filter()]: setsockopt(): Cannot allocate memory

コレクタがトラフィックの監視のために使用している、ベースのLinuxソケット・インタフェースのメモリー割当て制限は20KBです。多数のネットワーク・フィルタ(またはVLAN定義)を構成すると、この制限を上回ることがあります。

次のコマンドをrootユーザーとして発行すると、実行しているシステムでベースの制限を増やすことができます。

/sbin/sysctl -w net.core.optmem_max=65535

リブートしてもこの設定が保たれるようにするには、次の行を/etc/sysctl.confファイルに追加します。

net.core.optmem_max=65535

C.13 同じCookie値を受信する複数のユーザー・セッション

8.3.14項「ユーザー識別の定義」に記載しているように、RUEIは、Cookieを使用してユーザー・セッションを追跡します。多くの同時ユーザーが監視対象のWebサイトを訪問し、制限された一意のCookie値を選択できる場合、異なるユーザー・セッションに同じCookie値を割り当てる可能性があるので注意してください。これが発生する場合、予期しないレポートになる可能性があります。このため、次のCookieおよびCookie値をセッション・トラッキングに対して使用しないことを強くお薦めします。

- ロード・バランシングCookie。

- 時間ベースCookie。

- ログアウトCookie値。

- ユーザー・プリファレンスが格納されるCookie(特に使用可能な値の範囲が制限される場合)。

- 完全なアプリケーション・ドメインに設定されていないCookie。

重要:
トラッキング・ユーザー・セッションに対して高速回転のCookie値の使用を回避することを強くお薦めします。

また、構成されたCookieテクノロジがすべての監視対象ヒットに対応し、ヒットの複数の一致Cookieが回避されるようにすることをお薦めします。

C.14 データベース・クラッシュ後のオブジェクトのリカバリ

データベース・クラッシュが発生した場合、オブジェクトが破損する可能性があります。通常、これはORA-00376で表示され、同様のエラーがイベント・ログにレポートされます。

重要:

My Oracle Supportで(1303180.1を検索して)ナレッジ・ベース記事1303180.1をよく確認してください。

https://support.oracle.com

特に、ロギングを強制するために示された表領域が設定されていることを確認してください。

データベース表の確認

次のコマンドを使用して、データベース表のステータスを表示できます。

cop stats %period

periodは、必要な年(2012)、月(201203)または日(20120326)を示します。コマンド出力が次のように表示されます。

STRUCTURE      PRESENTATION   DATA ROWS         DATA SIZE hash  data dims lvls  pres view   data    desc      data     desc   cube name------ ---- ---- ----  ---- ----  ------  ------   -------  -------  ----------fTq7vQ  19   11   22   133  156        0       2    0.1 MB   0.1 MB  wg_keypage_mo_201203u7q+3g   9    4    8    13    7        -     470    0.6 MB   0.1 MB  wg_kpi_mo_201203PMocAw  22    9   17   159  174        -   16960   19.0 MB   4.0 MB  wg_page_mo_201203K/p4ww  12   12   29   123  104        0       0    0.1 MB   0.1 MB  wg_service_mo_2012031S2Ggg  10   19   29    79   90        -     247    2.0 MB   0.1 MB  wg_slowurl_mo_201203lZRuxg  29    5   10   279   61        0       0    0.1 MB   0.1 MB  wg_trasta_mo_201203yuY0aQ  29   11   20   153  204        -     343    2.0 MB   0.1 MB  wg_visit_mo_201203

データ列にゼロ値が含まれるか、多くのゼロまたはダッシュがある場合、破損したデータベース表を示します。この場合、(556733.1を検索して)次のナレッジ・ベース記事556733.1に記載されているスクリプトを使用して、データベースをリストアする必要があります。

https://support.oracle.com

また、次のコマンドを発行してRUEI構成およびテンプレート表の更新を強制することをお薦めします。

makedatabase @
modr -fn all

D エラー・コードの説明

この付録では、このWebサーバーによって生成され、リクエストに対する応答としてビジターに送信されるHTTP結果コードを説明します。

D.1 エラー: website-error

400番台のステータス・コードは、クライアントにエラーが発生したと思われるケースを対象としています。HEADリクエストに応答する場合を除き、サーバーには、エラー状況に関する説明と、エラーが一時的な状態と永続的な状態のどちらであるかの説明が記載されたエンティティが含まれます。これらのステータス・コードは、任意のリクエスト・メソッドに適用されます。ユーザー・エージェントは、含まれている任意のエンティティをユーザーに表示する必要があります。

クライアントがデータを送信する場合、TCPを使用したサーバーの実装は慎重に行う必要があります。つまり、サーバーが実行されている接続を閉じる前に、レスポンスが含まれるパケットの受信をクライアントが確認できるようにします。接続が閉じられた後もクライアントがデータをサーバーに送信し続けると、サーバーのTCPスタックはリセット・パケットをクライアントに送信します。リセット・パケットにより、クライアントが確認していない入力バッファは、HTTPアプリケーションが読み取って解釈する前に消去される可能性があります。

D.1.1 エラー: website-error » http-bad-request (400)

構文の形式が正しくないため、サーバーがリクエストを理解できませんでした。クライアントは、リクエストを変更しないままで繰り返さないようにする必要があります。

D.1.2 エラー: website-error » http-unauthorized (401)

リクエストにはユーザー認証が必要です。レスポンスには、リクエストされたリソースに適用可能なチャレンジが含まれるWWW-Authenticateヘッダー・フィールド(RFC 2616ドキュメント、14.47項)を含める必要があります。クライアントは、適切なAuthorizationヘッダー・フィールドを使用してリクエストを繰り返すことができます。リクエストに認可資格証明がすでに含まれている場合は、401レスポンスはこの資格証明に対して認可が拒否されたことを示しています。401レスポンスに前のレスポンスと同じチャレンジが含まれ、ユーザー・エージェントがすでに少なくとも1回は認証を試行していた場合、このレスポンスに指定されていたエンティティは、関連する診断情報を含んでいる場合があるため、ユーザーに提供する必要があります。

D.1.3 エラー: website-error » http-payment-req (402)

現時点では、このコードはほとんどのWebサーバーで実装されていません。これは、将来使用するために予約されています。

D.1.4 エラー: website-error » http-forbidden (403)

サーバーはリクエストを理解しましたが、その遂行を拒否しています。この場合、認可は役に立たないため、リクエストを繰り返さないでください。リクエスト・メソッドがHEADでなく、リクエストが遂行されなかった理由をサーバーから公開する場合は、拒否の理由を前述のエンティティに記述する必要があります。サーバーでこの情報をクライアントに提供しない場合は、ステータス・コード404(Not Found)をかわりに使用できます。

D.1.5 エラー: website-error » http-not-found (404)

Request-URIに一致するものが見つかりませんでした。この状態が一時的なものか永続的なものかを示す情報はありません。旧リソースが永続的に使用できず転送先アドレスがないことを、サーバーが内部構成可能なメカニズムを介して把握している場合は、410(Gone)ステータス・コードが使用されます。このステータス・コードは通常、リクエストが拒否された詳細な理由をサーバーで公開しない場合や、適用可能なレスポンスが他にない場合に使用されます。

D.1.6 エラー: website-error » http-method-not-allowed (405)

Request-Lineに指定されたメソッドは、Request-URIによって識別されるリソースでは使用できません。レスポンスには、リクエストされたリソースに対して有効なメソッドのリストを含むAllowヘッダーを含める必要があります。

D.1.7 エラー: website-error » http-not-acceptable (406)

リクエストによって識別されたリソースは、リクエストで送信されたAcceptヘッダーによって受入れ不可となったコンテンツ特性を含むレスポンス・エンティティを生成することのみが可能です。

レスポンスがHEADリクエストでないかぎり、レスポンスにはエンティティを含める必要があります。このエンティティには、エンティティの特性および場所のリストを含めます。このリストから、ユーザーまたはユーザー・エージェントが最も適切な特性と場所を選択できます。エンティティの形式は、Content-Typeヘッダー・フィールドに指定されたメディア・タイプによって指定されます。ユーザー・エージェントの形式および機能に応じて、最も適切な選択肢が自動的に選択されます。ただし、この指定により、この自動選択の標準値が定義されることはありません。

HTTP/1.1サーバーは、リクエストで送信されたAcceptヘッダーに従って受入れ不可となったレスポンスを戻すことができます。場合によっては、406レスポンスを送信するよりもこの方が適切なこともあります。ユーザー・エージェントは、受信したレスポンスのヘッダーを調べてそれが受入れ可能かどうかを確認できます。

D.1.8 エラー: website-error » http-proxy-authentication (407)

このコードは401(Unauthorized)と似ていますが、クライアントが最初にプロキシから認証を受ける必要があることを示します。プロキシは、Proxy-Authenticateヘッダー・フィールドを戻す必要があります。このフィールドには、リクエストされたリソースがあるかどうかについての、プロキシ自身に適用するチャレンジを含めます。クライアントは、適切なProxy-Authorizationヘッダー・フィールドを使用してリクエストを繰り返すことができます。

D.1.9 エラー: website-error » http-request-timeout (408)

サーバーが待機するように設定されていた時間内に、クライアントがリクエストを生成しませんでした。クライアントは、後でいつでも、リクエストを変更しないで繰り返すことができます。

D.1.10 エラー: website-error » http-conflict (409)

リソースの現在の状態と競合しているため、リクエストを完了できませんでした。このコードは、ユーザーが競合を解消してリクエストを再送できることが見込まれる状況でのみ使用できます。レスポンス本文には、ユーザーが競合のソースを認識するために十分な情報を含める必要があります。レスポンス・エンティティには、ユーザーまたはユーザー・エージェントが問題を解決するために十分な情報を含めることをお薦めします。ただし、これは不可能な場合があり、必須ではありません。

競合が最も発生しやすいのは、PUTリクエストに対するレスポンスにおいてです。たとえば、バージョニングが使用されており、PUTに含まれているエンティティが、前の(サード・パーティ・)リクエストによる変更と競合するリソースに変更された場合、サーバーで409レスポンスを使用して、リクエストを完了できないことを示す場合があります。このような場合は通常、レスポンス・エンティティには、レスポンス内のContent-Typeに定義された形式で2つのバージョン間の差異のリストを含めます。

D.1.11 エラー: website-error » http-gone (410)

リクエストしたリソースをサーバーで使用できなくなり、転送アドレスも不明です。この状況は永続的なものと想定されます。リンク編集機能を持つクライアントは、ユーザー承認の後でRequest-URIへの参照を削除する必要があります。この状況が永続的であるかどうかをサーバーが特定できない、またはそのことを判断する機能がサーバーにない場合は、ステータス・コード404(Not Found)をかわりに使用する必要があります。このレスポンスはキャッシュ可能です(キャッシュ不可と指定されていない場合)。

410レスポンスは基本的に、リソースが意図的に使用できなくなっていることと、サーバー所有者がこのリソースに対するリモート・リンクの削除を求めていることを受信者に通知することで、Webのメンテナンス・タスクを支援することを目的としています。このようなケースがよく発生するのは、期間を限定した販売促進サービスや、サーバーのサイトで勤務しなくなった個人に属するリソースにおいてです。永続的に使用できないすべてのリソースをgoneとしてマークしたり、一定期間にわたってマークを保持する必要はありません。これはサーバー所有者の判断に任されます。

D.1.12 エラー: website-error » http-length-required (411)

サーバーは、Content-Lengthが定義されていないリクエストの受入れを拒否しています。クライアントは、メッセージ本文の長さを含む有効なContent-Lengthヘッダー・フィールドをリクエスト・メッセージに追加することにより、このリクエストを繰り返すことができます。

D.1.13 エラー: website-error » http-precondition-failed (412)

1つ以上のリクエスト・ヘッダー・フィールドに指定された事前条件が、サーバーでテストされたときに、falseと評価されました。クライアントはこのレスポンス・コードを使用して、現在のリソース・メタ情報(ヘッダー・フィールド・データ)に事前条件を設定できます。これにより、リクエストされたメソッドが目的外のリソースに適用されるのを阻止できます。

D.1.14 エラー: website-error » http-entity-too-large (413)

サーバーが処理できる長さをリクエスト・エンティティが超えているため、サーバーはリクエストの処理を拒否しています。サーバーは、クライアントがリクエストを続行するのを阻止するために、接続を閉じることができます。

この状況が一時的なものである場合、サーバーはRetry- Afterヘッダー・フィールドを含めることにより、この状況が一時的なものであることと、クライアントが再試行可能になるまでの時間を示す必要があります。

D.1.15 エラー: website-error http-URI-too-long (414)

サーバーが解釈できる長さをRequest-URIが超えているため、サーバーはリクエストの処理を拒否しています。この状況はまれにしか発生しませんが、このような状況が発生するのは、クライアントが長い問合せ情報を持つPOSTリクエストをGETリクエストに不正に変換した場合、クライアントがURIのリダイレクションのブラックホールに陥った(リダイレクトされたURI接頭辞がそれ自体の接尾辞を指し示している)場合、または固定長のバッファを使用してRequest-URIを読み取ったり操作するために、一部のサーバー上に存在するセキュリティ・ホールを利用しようとしているクライアントの攻撃をサーバーが受けている場合のいずれかが考えられます。

D.1.16 エラー: website-error » http-media-not-supp (415)

リクエストされたメソッドに対するリクエストのエンティティが、リクエストされたリソースではサポートされていない形式であるため、サーバーはリクエストの処理を拒否しています。

D.1.17 エラー: website-error » http-invalid-range (416)

サーバーがこのステータス・コードを使用してレスポンスを戻す必要があるのは、リクエストにRangeリクエスト・ヘッダー・フィールド(RFC 2616ドキュメント、14.35項)が含まれ、このフィールド内の範囲指定子の値のいずれもが、選択されたリソースの現在のエクステントと重複せず、リクエストにIf-Rangeリクエスト・ヘッダー・フィールドが含まれていない場合です。(バイト範囲の場合、このステータス・コードは、byte-range-specのすべての値のfirst-byte-posが、選択したリソースの現在の長さより大きいことを意味します)。

バイト範囲のリクエストに対してこのステータス・コードが戻された場合、レスポンスには、選択したリソースの現在の長さを指定するContent-Rangeエンティティ・ヘッダー・フィールドを含める必要があります(RFC 2616ドキュメント、14.16項を参照)。このレスポンスでは、複数パートまたはバイト範囲のContent-Typeは使用しないでください。

D.1.18 エラー: website-error » http-expect-failed (417)

Expectリクエスト・ヘッダー・フィールドに指定された要求は、このサーバーで満たされません(RFC 2616ドキュメント、14.20項を参照)。または、サーバーがプロキシである場合は、リクエストが次のホップのサーバーでは満たされなかったことの明白な証拠がサーバーにあります。

D.2 エラー: server-error

数値5で始まるレスポンス・ステータス・コードは、エラーがあることやリクエストの実行が不可能であることをサーバーが認識しているケースを示しています。HEADリクエストに応答する場合を除き、サーバーには、エラー状況に関する説明と、エラーが一時的な状態と永続的な状態のどちらであるかの説明が記載されたエンティティが含まれます。ユーザー・エージェントは、含まれている任意のエンティティをユーザーに表示する必要があります。これらのレスポンス・コードは、任意のリクエスト・メソッドに適用されます。

D.2.1 エラー: server-error » internal-error (500)

サーバーに予期しない状況が発生し、リクエストを遂行できなくなりました。

D.2.2 エラー: server-error » not-implemented (501)

サーバーは、リクエストを遂行するために必要な機能をサポートしていません。これは、サーバーがリクエスト・メソッドを認識しておらず、リソースに対してそのメソッドをサポートできない場合に適したレスポンスです。

D.2.3 エラー: server-error » dispatch-error (502)

RFC 2616ドキュメントの10項では、これは502 Bad Gatewayとして記載されています。サーバーは、ゲートウェイまたはプロキシとして動作中に、リクエストを遂行しようとしてアクセスしたアップストリーム・サーバーから無効なレスポンスを受け取りました。

D.2.4 エラー: server-error » service-unavailable (503)

サーバーは現在、サーバーの一時的な過負荷状態またはメンテナンスのため、リクエストを処理できません。つまり、これは多少の遅延後に緩和される一時的な状況であるということです。遅延の長さは、判明している場合にはRetry-Afterヘッダーに示される場合があります。

注意:
503ステータス・コードは、サーバーが過負荷状態になったときに必ずしも使用する必要があるわけではありません。接続を拒否するのみでもかまいません。

D.2.5 エラー: server-error » dispatch-timeout (504)

RFC 2616ドキュメントの10項では、これは504 Gateway Timeoutとして記載されています。サーバーは、ゲートウェイまたはプロキシとして動作中に、リクエストを完了するためにアクセスする必要があった、URI(HTTP、FTPまたはLDAPなど)によって指定されたアップストリーム・サーバーまたは他の補助サーバー(DNSなど)から、適時にレスポンスを受け取りませんでした。

注意:
DNS参照がタイムアウトしたときに、デプロイされている一部のプロキシは400または500を戻すことが判明しています。

D.2.6 エラー: server-error » version-not-supported (505)

サーバーは、リクエスト・メッセージで使用されていたHTTPプロトコル・バージョンをサポートしていないか、サポートすることを拒否しています。サーバーは、クライアントと同じメジャー・バージョンを使用してリクエストを完了できないか完了することを拒否している(このエラー・メッセージを除く)ことを示しています。レスポンスには、バージョンがサポートされていない理由と、このサーバーでサポートされている他のプロトコルが記載されたエンティティを含める必要があります。

D.3 エラー: no-server-response

クライアントによってリクエストされたがサーバーがまったく応答しなかったヒット数です。これは、サーバー・エラーまたはネットワーク・エラー(あるいはその両方)が原因です。

D.4 エラー: network-error

ネットワーク・エラーとは、TCPレベルのビューから完全な配信が行われなかったヒットです。これには、複数の原因が考えられます。

- server-abort
このステータスは、サーバー関連の接続に関する問題を示します。次のいずれかの状況がレポートされます。

- サーバーが接続をリセットしました。
これは、サーバー・アプリケーションの問題を示します。すべてのデータが正しく送信または受信されたかどうかを確認できません。

- サーバーが不正なデータを送信しました。
サーバーから送信されたデータの形式が正しくないため、上位レベルのHTTP情報を抽出できません。この原因には、パケット・ロスや順序が乱れた多数のパケットなどの多くの要因があります。

- クライアントが認識されなくなりました。
クライアントが突然認識されなくなる場合があります(コンピュータまたはモデムのクラッシュ、ISPの停止、あるいは接続が即時切断される原因となる他のハードウェア障害など)。この状況はサーバー・エラーとして現れます。つまり、サーバーが最終的にタイムアウトしたり、接続がリセットされます。クライアントが受信した送信データの量は確認できません。

ビジターへの影響

ビジターは、サーバー・エラー・メッセージを受信します。または、少なくとも、リクエストした情報以外を受信します。場合によっては、部分的に受信した情報がビジターに示されることがあります。多くの場合、これは、サーバーに問題があることを示します。

使用方法

サーバー・エラーは繰り返し発生しないようにする必要があります。多数のサーバー・エラーがレポートされる場合、ネットワーク・プロトコル分析(NPA)ツールを使用してネットワークおよびサーバー・コンポーネントを調べる必要があります。

サーバー・エラーの原因を分析するための指標:

- 負荷: サーバーまたはロード・バランサ(あるいはその両方)に対する接続が多すぎると、リソースの問題が発生する可能性があります。

- バランサ: すべてのサーバー間で負荷が適切に分散されていますか。または、常に1つのサーバーが過負荷状態になっていたりエラーを生成していますか。

- URL: 特定のアプリケーションURLのみがこのタイプの問題を起こしていますか。

- server-timeout
サーバー・タイムアウトは、サーバーがクライアントからのリクエストに対する応答に失敗した場合に発生します。タイムアウト状況では、サーバーは回線を介してデータを送信しません。つまり、レスポンスまたはレスポンスの一部が送信されません。(サーバーの中断は、完了ステータス4としてレポートされます)。

この完了ステータスの正確な意味は、次のとおりです。

- クライアントは完全なHTTPリクエストを送信しました。

- サーバーからデータがいっさい返送されませんでした。

注意:
タイムアウトは、データが送信されなかったことを示します。つまり、サーバーのTCPスタックは、クライアントのリクエストが受信されたことを確認セグメントの送信によって確認している可能性もありますが、サーバー・アプリケーション自体がデータを返送できません。

ビジターへの影響

クライアントはコンテンツを受信していません。サーバーが単に応答に失敗しました。これは、ネットワークまたはサーバー・アプリケーションに問題があるにすぎないことを示している場合があります。

使用方法

サーバーのタイムアウトの原因は、この問題が発生したネットワークを分析することによって調べることができます。サーバーのタイムアウトは散発的にしか発生しないため、影響を受けるリクエストの割合が多くないかぎり、問題とみなさないでください。すべてのクライアントでタイムアウトが発生する割合が高い場合は、ネットワーク分析ツールおよびアプリケーション・パフォーマンス・テスト・ツールを使用して、ネットワークおよびサーバー・コンポーネントを調べてください。

- network-timeout
受信したクライアントまたはサーバーのヘッダーのパケットが切り捨てられています。これは、ネットワークの問題によるタイムアウトが原因です。

これは、通常はネットワーク・エラーとみなす必要がある例外です。ただし、この問題の原因は顧客が解決できるものではないため、通常は標準の動作とみなされます。このため、この問題は、失敗のキューブには追加されず、このヒットは成功とみなされます。

- client-abort
ページのロード中に、クライアントがブラウザを閉じる、リロードをクリックする、何かをクリックして他のページに移動する、またはリダイレクトされた可能性があるために、転送が中断されました。

E データ・アイテムの概要

この付録では、RUEIで使用されるデータ・アイテムおよびKPIメトリックについて簡単に説明します。また、RUEIでの情報の収集とレポートの技術的側面についてもいくつか説明します。

E.1 データの項目

RUEIで使用されるデータの項目を表E-1に示します。次の表記規則を使用します。

- データおよびディメンション・レベルのアイテムで、値が見つからないかRUEI処理によって割り当てられていないものは、RUEIのUI上(ダッシュボード、レポート、データ・ブラウザを含む)で「"(値なし)"」と表示されます。このような値は、データベース・レベルではデータベースNULL値として格納されます。

- (%)を含むアイテムは割合を表します。たとえば、エラー・ヒット(%)は、関連するエラーが発生したヒットの割合を表します。

- タイトルにスラッシュまたは「当たりの」を含むアイテムは平均を表します。スラッシュの後、または「当たりの」の前のテキストが範囲を示しています。たとえば、「1セッション当たりのコンテンツ・エラー」は、検出されたコンテンツ・エラーの1ユーザー・セッション当たりの平均数を表します。

- P95(%)を含むアイテムは、95%というパーセント制限を適用した平均です。このため平均を算出する前に上位5%の極値が除かれ、指標としては信頼性が高くなります。

- スラッシュまたは「当たりの」も(%)も含まないアイテムは合計を表します。たとえば、「失敗したヒット」は、なんらかの理由でエラーになったヒットの合計数を表します。

表E-1 データの項目

項目

説明

中断

中断されたユーザー・フローの数。

終了したユーザー・フローのアクティブ時間

終了したユーザー・フローのアクティブ時間。

ステップでアクティブ

ユーザー・フローの状態を変更していないアクション。

ユーザー・フロー内のアクティビティ

エンドユーザーをユーザー・フロー定義内に入れるアクティビティが見つかったユーザー・フローの数。

ユーザー・フローの外部に移動するアクティビティ

エンド・ユーザーをユーザー・フロー定義から出すアクティビティが見つかったユーザー・フローの数。

ステップでエラーが発生していないアクティビティ

ステップで見つかった、(技術的な)エラーのないアクティビティの数。

ステップのアクティビティ

ステップ・アクティビティの数(ステップ内のアクティビティに関連するページ・ビュー)。

アプリケーション・ヒット

オブジェクトの合計数。

アプリケーション・ヒット/日

ページ内でリクエストされたオブジェクト数の1日当たりの平均。

アプリケーション・ヒット/時

1時間当たりのヒット。

アプリケーション・ヒット/分

1分当たりのヒット。

1ページ当たりのアプリケーション・ヒット

リクエストされたオブジェクト数の1ページ当たりの平均。

アプリケーション・ヒット/秒

1秒当たりのヒット。

1セッション当たりのアプリケーション・ヒット

クライアント・セッション中にリクエストされたオブジェクトの平均数。

アプリケーション違反コール

検出された悪いWebサービス・コールとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーの合計数。

アプリケーション違反コール(%)

悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーが検出されたWebサービス・コールの割合。

アプリケーション違反ページ・ビュー

検出された悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーの合計数。

アプリケーション違反ページ・ビュー(%)

悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーが検出されたページ・ビューの割合。

アプリケーション違反

ユーザーフロー・アクティビティ中に検出された悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツのエラーの合計数。

アプリケーション違反(%)

悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーが検出されたページ・ビューの割合。

1ユーザー・フロー当たりの平均アクティブ時間(秒)

1ユーザー・フロー当たりの平均アクティブ時間は、ユーザー・フローのフィルタ定義のすべてのアクティブ時間を合計し、その数値をユーザー・フローの数で割って計算されます。フローの追跡時には、フローの開始からフローの完了または中断までの時間が3つのカテゴリに分割されます。

- アクティブ時間: フロー・ステップ定義と一致するページのクリック、およびフロー・ステップ定義と一致するアクティビティの実行に費やされる時間。

- アイドル時間: (ステップ・アイドル時間の待機後に)フロー内にアクティビティが存在しない時間。

- 外部時間: フロー・ステップ定義と一致しないページのクリックに費やされる時間。

平均アクティブ時間の計算では、アイドル時間と外部時間の測定値は使用されません。

1ユーザー・フロー当たりの平均継続時間(秒)

各ユーザー・フローのトランザクション継続時間。

1ユーザー・フロー当たりの平均アイドル時間(秒)

各ユーザー・フローのトランザクション・アイドル継続時間。

1フロー当たりの平均通貨値

1フロー当たりの終了時の通貨値。

1ユーザー・フロー当たりの平均外部時間(秒)

各ユーザー・フローのトランザクション外部継続時間。

終了した1フロー当たりの平均ページ・ロード時間(秒)

ユーザーフロー・アクティビティ中の終了した1フロー当たりの平均ロード時間。

終了したフロー当たりの平均ページ・ビュー

ユーザーフロー・アクティビティ中の1フロー当たりのページ・ビューの平均数。

完了時の平均通貨値

ユーザー・フローの完了時の平均通貨値。

失敗時の平均通貨値

ユーザー・フローの中断時またはセッション・タイムアウト時に失われた平均通貨値。

合計されたステップ当たりの平均ページ・ロード時間

ユーザー・フローの中断時またはセッション・タイムアウト時に失われた平均通貨値。

1ヒット当たりのブラウザのビジー時間(ミリ秒)

クライアント側でのブラウザ・アクティビティによって生じる、1ヒット当たりの平均遅延時間(ミリ秒単位)。これは、クライアントのTCPウィンドウ・サイズが0と示される期間です。

ブラウザ・ヒット

ブラウザJSライブラリにより測定されるページ上のオブジェクト数。

コール

サービス関数コールの合計数。

取り消されたユーザー・フロー

(中断またはセッション・タイムアウトによって)停止したユーザー・フローの数。

クライアント中断アプリケーション・ヒット

クライアント中断ヒット。

クライアント中断アプリケーション・ヒット(%)

クライアント中断ヒット(%s)。

クライアント中断コール

ロード中にクライアントが接続を閉じて転送を中断したサービス関数コールの数。

クライアント中断コール(%)

ロード中に、クライアントがブラウザを閉じる、リロードをクリックする、または何かをクリックして移動した可能性があるために、転送が中断されたサービス関数コールの割合(%)。

クライアント中断ページ・ビュー

ロード中に、クライアントがブラウザを閉じる、リロードをクリックする、または何かをクリックして他のページに移動した可能性があるために、転送が中断されたページ・ビューの数。

クライアント中断ページ・ビュー(%)

ロード中に、クライアントがブラウザを閉じる、リロードをクリックする、または何かをクリックして他のページに移動した可能性があるために、転送が中断されたページ・ビューの割合(%)。

1セッション当たりのクライアント中断

ロード中に、クライアントがブラウザを閉じる、リロードをクリックする、または何かをクリックして他のページに移動した可能性があるために転送が中断された、1セッション当たりのページ・ビューの合計数。

クライアント・データ(バイト)

クライアントからWebサーバーに送信されるバイト数。

クライアント・パケット

クライアントからWebサーバーに送信されるパケット数。

1コール当たりのクライアント時間(ミリ秒)

クライアント側でのアクティビティによって生じる、1サービス関数コール当たりの合計遅延時間。

完了したユーザー・フロー

完了したユーザー・フローの数。

コンテンツ・エラー・コール

サービス関数コール中にコンテンツ・エラーが確認された回数。

コンテンツ・エラー・コール(%)

コンテンツ・エラーが確認されたサービス関数コールの割合(%)。

コンテンツ・エラー・ページ・ビュー

コンテンツ・エラーが確認されたページ・ビューの数。

コンテンツ・エラー・ページ・ビュー(%)

表示時にコンテンツ・エラーが確認されたページ・ビューの割合(%)。

コンテンツ・エラー・ビュー(%)

コンテンツ・エラーが確認されたページ・ビューの割合(%)。

ステップのコンテンツ・エラー

ステップで見つかったコンテンツ・エラーの数(ステップ・アクティビティのみを考慮)。

コンテンツ・エラー

事前定義済のコンテンツ文字列がページから検出されなかった場合、またはエラー文字列が検出された場合。たとえば、「Webサイトへようこそ」という文字列が含まれている必要があるページで、その文字列が検出されなかった場合などです。

終了したフローのコンテンツ・エラー(%)

ユーザーフロー・アクティビティ中にコンテンツ・エラーが確認されたページ・ビューの割合。

終了したユーザー・フローのコンテンツ・エラー

事前定義済のコンテンツ文字列がページから検出されなかった場合、またはエラー文字列が検出された場合。たとえば、「Webサイトへようこそ」という文字列が含まれている必要があるページで、ユーザーフロー・アクティビティ中にその文字列が検出されなかった場合などです。

1セッション当たりのコンテンツ・エラー

セッション中、ページの表示時にコンテンツ・エラーが確認された平均回数。

コンテンツ通知関数コール

コンテンツ通知が確認された関数コールの数。

コンテンツ通知関数コール(%)

コンテンツ通知が確認された関数コールの割合。

コンテンツ通知ページ・ビュー

コンテンツ通知が確認されたページ・ビューの数。

コンテンツ通知ページ・ビュー(%)

コンテンツ通知が確認されたページ・ビューの割合。

コンテンツOKコール

サービス関数コール中に事前定義済のコンテンツ文字列が検出された回数。

コンテンツOKコール(%)

事前定義済のコンテンツ文字列が検出されたサービス関数コールの割合(%)。

コンテンツOKページ・ビュー

ページの表示時に事前定義済のコンテンツ文字列が検出された回数。

コンテンツOKページ・ビュー(%)

表示時に事前定義済のコンテンツ文字列が検出されたページ・ビューの割合(%)。

1コール当たりのコンテンツ・サイズ(バイト)

1サービス関数コールにおけるオブジェクトのRAWコンテンツの平均サイズ(バイト単位)。

1ヒット当たりのコンテンツ・サイズ(バイト)

オブジェクトの平均コンテンツ・サイズ(バイト単位)。

1ページ当たりのコンテンツ・サイズ(バイト)

ページ上のすべてのオブジェクト(ヘッダーを除く)の平均サイズ(バイト単位)。

見つかったCookie(%)

セッション固有のトラッキング・スキームから識別できたページ・ビューの割合。Cookieまたは他のスキームから識別できなかったセッションは、IPアドレスとブラウザ固有の情報を組み合せて識別されます。

遅延ログ率(%)

コレクタのログ・ファイルでの関連する処理が遅延したログの割合(%)。

分母

KPI値を計算する際に分母として使用される数字(KPIメトリックに基づく)。

終了したユーザー・フローの継続時間

終了したユーザー・フローの継続時間。

(開始された)1ユーザー・フロー当たりの継続時間

このユーザー・フローで使用された時間。ページのロード時間と読取り時間の合計として算出されます。

1遷移当たりの継続時間

このステップで使用された時間。ページのロード時間と読取り時間の合計として算出されます。

1ページ当たりの動的アプリケーション・ヒット

1ページ上の動的オブジェクト数の平均。

1ヒット当たりの動的コンテンツ・サイズ(バイト)

動的オブジェクトの平均コンテンツ・サイズ(バイト単位)。

1ページ当たりの動的コンテンツ・サイズ(バイト)

ページ上のすべての動的オブジェクトの平均コンテンツ・サイズ(バイト単位)。

1ページ当たりの動的エンドツーエンド時間(ミリ秒)

表示されたページにおける、すべてのオブジェクトの動的ネットワーク時間と動的サーバー・レスポンス時間をあわせた時間の平均。

1ヒット当たりの動的ヘッダー・サイズ(バイト)

HTTPリクエストのヘッダー部分に含まれるすべての動的オブジェクトの平均サイズ(バイト単位)。

1ページ当たりの動的ヘッダー・サイズ(バイト)

ページ上の動的オブジェクトのすべてのヘッダーの合計サイズの平均(バイト単位)。

1ヒット当たりの動的ネットワーク時間(ミリ秒)

動的オブジェクトをネットワーク経由で送信するために要した平均時間(ミリ秒単位)。これには、リクエストとレスポンスの両方の送信が含まれます。

1ページ当たりの動的ネットワーク時間(ミリ秒)

ページ内のすべての動的オブジェクトをネットワーク経由で送信するために要した平均時間(ミリ秒単位)。これには、リクエストとレスポンスの両方の送信が含まれます。

1ヒット当たりの動的サーバー時間(ミリ秒)

ページ内の動的オブジェクトの平均サーバー・レスポンス時間(ミリ秒単位)。

1ページ当たりの動的サーバー時間(ミリ秒)

ページ内のすべての動的オブジェクトの平均サーバー・レスポンス時間(ミリ秒単位)。

1ヒット当たりの動的サイズ(バイト)

リクエストされた動的オブジェクトの平均サイズ(バイト単位)。

1ページ当たりの動的サイズ(バイト)

ページ内のすべての動的オブジェクトの合計サイズの平均(バイト単位)。

1ヒット当たりの動的時間(ミリ秒)

すべての動的オブジェクトのエンドツーエンド時間の平均(ミリ秒単位)。

1ページ当たりの動的時間(ミリ秒)

ページ上のすべての動的オブジェクトの平均時間(ミリ秒単位)。

1コール当たりのエンドツーエンド時間(ミリ秒)

1サービス関数コールにおける、オブジェクトのネットワーク時間とサーバー・レスポンス時間をあわせた時間の平均。

1コール当たりのエンドツーエンド時間P95 (ミリ秒)

1サービス関数コールにおける、オブジェクトのネットワーク時間とサーバー・レスポンス時間をあわせた時間の平均。ただし、95%というパーセント制限を適用してあります。このため上位5%の極値が除かれ、指標としては信頼性が高くなります。

1ヒット当たりのエンドツーエンド時間(ミリ秒)

表示されたページにおける、オブジェクトのネットワーク時間とサーバー・レスポンス時間をあわせた時間の平均。

1ページ当たりのエンドツーエンド時間(ミリ秒)

表示されたページにおける、すべてのオブジェクトのネットワーク時間とサーバー・レスポンス時間をあわせた時間の平均。

1ページ当たりのエンドツーエンド時間P95 (ミリ秒)

表示されたページにおける、すべてのオブジェクトのネットワーク時間とサーバー・レスポンス時間をあわせた時間の平均。ただし、95%というパーセント制限を適用してあります。このため上位5%の極値が除かれ、指標としては信頼性が高くなります。

終了したユーザー・フロー

終了したユーザー・フロー数。

終了したユーザー・フロー

(完了、中断またはセッション・タイムアウトによって)終了したユーザー・フローの数。

ステップのエラー(%)

ステップで見つかったエラーの割合(すべてのステップ・アクティビティを考慮)。

エラー・アプリケーション・ヒット

エラーが関連するヒットの数。

エラー・アプリケーション・ヒット(%)

エラーが関連するヒットの割合(%)。

エラー・コール

なんらかの理由で正常に呼び出されなかったサービス関数コールの合計数。

エラー・コール(%)

なんらかの理由で正常に呼び出されなかったサービス関数コールの割合(%)。

エラー・ページ・ビュー

なんらかの理由で正常に表示されなかったページ・ビューの合計数。

エラー・ページ・ビュー(%)

なんらかの理由で正常に表示されなかったページ・ビューの割合(%)。

終了したフローのエラー・ページ・ビュー

ユーザーフロー・アクティビティ中になんらかの理由で正常に表示されなかったページ・ビューの合計数。

終了したフローのエラー・ページ・ビュー(%)

ユーザーフロー・アクティビティ中になんらかの理由で正常に表示されなかったページ・ビューの割合。

ステップのエラー

ステップに表示されたエラーの数(ステップ・アクティビティのみを考慮)。

1セッション当たりのエラー

ビジター・セッション中に発生したサービス関数コール・エラーの平均数。

フロー遷移

ステータスを変更するユーザー・フロー内の遷移(移動)の数。つまり、現在のステップを繰り返すことにならなかったすべてのアクションです。

良好なアプリケーション・ヒット

ロード時間が定義されたしきい値内だったヒットの数。

良好なコール

エンドツーエンド時間(すべてのサーバー時間とネットワーク時間の合計)が指定されたしきい値を下回るサービス関数コールの数。

良好なページ・ビュー

ページのロード時間が、定義されたページ・ロード満足度のしきい値内だったページ・ビューの数。

良好なページ・ビュー(%)

ページのロード時間が、定義されたページ・ロード満足度のしきい値内だったページ・ビューの割合。

終了したフローの良好なページ・ビュー

ユーザーフロー・アクティビティ中に、ページのロード時間が、定義されたページ・ロード満足度のしきい値内だったページ・ビューの数。

終了したフローの良好なページ・ビュー(%)

ユーザーフロー・アクティビティ中に、ページのロード時間が、定義されたページ・ロード満足度のしきい値内だったページ・ビューの割合。

良好なステップ・アクティビティ

定義されたページ・ロード満足度のしきい値内でクライアント・ブラウザにロードされたステップ・アクティビティの数。

1コール当たりのヘッダー・サイズ(バイト)

1サービス関数コールにおける、リクエストされたオブジェクトのヘッダーの平均サイズ(バイト単位)。

1ヒット当たりのヘッダー・サイズ(バイト)

リクエストされたオブジェクトのヘッダーの平均サイズ(バイト単位)。

1ページ当たりのヘッダー・サイズ(バイト)

ページのヘッダーの平均サイズ(バイト単位)。

時間

時間数。

アイドル・リターン

少なくとも構成されたステップ・アイドル時間遅延した後、ユーザー・フローに戻ります。セッションのタイムアウトに達すると、ステップ・アイドルとしてマークされます。これにより、アイドルアウトとアイドルインを直接的に関連付けることができます。

アイドル

少なくとも構成されたステップ・アイドル時間の間、エンドユーザーによるアクティビティがありませんでした。

KPI平均値

KPIの平均値。

KPI停止時間(分)

KPIにより監視されるメトリック値がターゲット値を超えてからの合計時間(分)。

KPIエンティティ

KPIの計算期間。

KPI失敗(%)

KPIが未達成状態であった時間の割合(%)。

KPI最大ターゲット

計算でのKPIの最大ターゲット。

KPI最小ターゲット

計算でのKPIの最小ターゲット。

KPI成功

KPIの現在の状態を示す指標(OK、未達成または未定義)。

KPI成功(%)

KPIが達成状態であった時間の割合(%)。

最終ユーザー・フロー・ステップ番号

このユーザー・フローに定義されているステップの合計数。

最大解決時間(分)

KPIが構成の境界外にあった最長の期間。

最大ステップ番号

ユーザー・フローの最大ステップ番号(ステップ番号の計算に使用される)。

中央の動的エンドツーエンド時間(ミリ秒)

表示されたページにおける、すべてのオブジェクトの動的ネットワーク時間と動的サーバー・レスポンス時間をあわせた時間の中央。

中央動的サイズ(バイト)

すべての動的オブジェクトの中央サイズ(バイト)。

中央エンドツーエンド時間(ミリ秒)

中央エンドツーエンド時間(ミリ秒単位)。これには、ネットワーク転送時間とサーバー・レスポンス時間を含みます。

中央ネットワーク時間(ミリ秒)

中央ネットワーク転送時間(ミリ秒)。

中央ページ・ブラウザ時間(秒)

すべてのページの中央ブラウザ時間。

中央ページ・ロード時間(秒)

すべてのページの中央ロード時間。

中央ページ読取り時間(秒)

最後にリクエストされたページのオブジェクトがクライアント・ブラウザにロードされてから、クライアントが別ページをリクエストするまでの中央時間。

中央サーバー時間(ミリ秒)

合計エンドツーエンド時間におけるサーバー中央時間数。

中央の静的エンドツーエンド時間(ミリ秒)

表示されたページにおける、すべてのオブジェクトの静的ネットワーク時間と静的サーバー・レスポンス時間をあわせた時間の中央。

中央静的サイズ(バイト)

ヘッダーと本文を含むすべての静的オブジェクトの中央サイズ(バイト)。

停止したユーザー・フローにおける通貨値

セッション・タイムアウトによって失われた合計通貨値。

ネットワーク・エラー・アプリケーション・ヒット

オブジェクトについて確認されたネットワーク・エラーの数。

ネットワーク・エラー・アプリケーション・ヒット(%)

ネットワーク・エラーが確認されたオブジェクトの割合(%)。

ネットワーク・エラー・コール

サービス関数コール中にネットワーク・エラーが確認された回数。

ネットワーク・エラー・コール(%)

サービス関数コール中にネットワーク・エラーが確認された割合。

ネットワーク・エラー・ページ・ビュー

ページの表示時にネットワーク・エラーが確認された回数。

ネットワーク・エラー・ページ・ビュー(%)

ページの表示時にネットワーク・エラーが確認された割合。

ネットワーク・エラー・ビュー(%)

ページ・ビューの間にネットワーク・エラーが確認された回数の割合。

ステップのネットワーク・エラー

ステップで見つかったネットワーク・エラーの数(ステップ・アクティビティのみを考慮)。

ネットワーク・エラー

ネットワーク・エラーとは、TCPレベルのビューから完全な配信が行われなかったヒットです。理由として、サーバー関連の問題や、サーバーがクライアントのリクエストに応答できずにサーバー・タイムアウトが発生したことが考えられます。

終了したフローのネットワーク・エラー

ユーザーフロー・アクティビティ中のページの表示時にネットワーク・エラーが確認された回数。

終了したフローのネットワーク・エラー(%)

ユーザーフロー・アクティビティ中のページの表示時にネットワーク・エラーが確認された割合。

1セッション当たりのネットワーク・エラー

セッション中にネットワーク・エラーが確認された平均回数。

ネットワークOKコール

ネットワーク・エラーが確認されなかったサービス関数コールの数。

ネットワークOKコール(%)

ネットワーク・エラーが確認されなかったサービス関数コールの割合(%)。

ネットワークOKページ・ビュー

ページの表示時にネットワーク・エラーが確認されなかったページ数。

ネットワークOKページ・ビュー(%)

ネットワーク・エラーが確認されなかったページ・ビューの割合(%)。

ネットワーク時間(%)

合計エンドツーエンド時間におけるネットワーク時間の割合。

1コール当たりのネットワーク時間(ミリ秒)

サービス関数コール中に、サーバーが応答してからオブジェクトがクライアント・ブラウザに到達するまでの平均時間。

1コール当たりのネットワーク時間P95 (ミリ秒)

サービス関数コール中に、サーバーが応答してからオブジェクトがクライアント・ブラウザに到達するまでの平均時間。ただし、95%というパーセント制限を適用してあります。このため上位5%の極値が除かれ、指標としては信頼性が高くなります。

1ページ当たりのネットワーク時間(ミリ秒)

ネットワークのすべてのスレッドがクライアントに到達するために要した平均時間(ミリ秒単位)。

終了したフローの1ページ当たりのネットワーク時間(ミリ秒)

ユーザーフロー・アクティビティ中にネットワークのすべてのスレッドがクライアントに到達するために要した平均時間(ミリ秒)。

1ページ当たりのネットワーク時間P95 (ミリ秒)

ネットワークのすべてのスレッドがクライアントに到達するために要した平均時間(ミリ秒単位)。ただし、95%というパーセント制限を適用してあります。このため平均を算出する前に上位5%の極値が除かれ、指標としては信頼性が高くなります。

ネットワーク・タイムアウト・アプリケーション・ヒット

オブジェクトについて確認されたネットワーク・タイムアウトの数。

ネットワーク・タイムアウト・アプリケーション・ヒット(%)

ネットワーク・タイムアウトが確認されたオブジェクトの割合(%)。

ネットワーク・タイムアウト・ページ・ビュー

ネットワーク・タイムアウトが発生したページ・ビューの数。

ネットワーク・タイムアウト・ページ・ビュー(%)

ネットワーク・タイムアウトが発生したページ・ビューの割合(%)。

分子

KPI値を計算する際に使用される分子。選択項目はKPIメトリックによって異なります。

OKアプリケーション・ヒット

エンドツーエンド時間(すべてのサーバー時間とネットワーク時間の合計)が、良好のしきい値を超え、指定された劣悪のしきい値未満であるオブジェクトの数。つまり、最適ではないが許容できるオブジェクト・リクエストの数です。

OKコール

エンドツーエンド時間(すべてのサーバー時間とネットワーク時間の合計)が、良好のしきい値を超え、指定された関数コール劣悪のしきい値未満のサービス関数コールの数。つまり、最適ではないが許容できる関数コールの数です。

問題のないページ・ビュー

定義されたページ・ロード良好のしきい値を超えるが、劣悪のしきい値を下回る時間でクライアント・ブラウザにロードされたページ・ビューの数。つまり、最適ではないが許容できるページ・ロードです。

問題のないページ・ビュー(%)

定義されたページ・ロード良好のしきい値を超えるが、劣悪のしきい値を下回る時間でクライアント・ブラウザにロードされたページ・ビューの割合。つまり、最適ではないが許容できるページ・ロードです。

終了したフローの問題のないページ・ビュー

ユーザーフロー・アクティビティ中に、定義されたページ・ロード良好のしきい値を超えるが、劣悪のしきい値を下回る時間でクライアント・ブラウザにロードされたページ・ビューの数。つまり、最適ではないが許容できるページ・ロードです。

終了したフローの問題のないページ・ビュー(%)

ユーザーフロー・アクティビティ中に、定義されたページ・ロード良好のしきい値を超えるが、劣悪のしきい値を下回る時間でクライアント・ブラウザにロードされたページ・ビューの割合。つまり、最適ではないが許容できるページ・ロードです。

問題のないステップ・アクティビティ

定義されたページ・ロード良好のしきい値を超えるが、劣悪のしきい値を下回る時間でクライアント・ブラウザにロードされたページ・ビューの数。つまり、最適ではないが許容できるページ・ロードです(ステップ・アクティビティを考慮)。

外部

ユーザーフロー/ステップの定義に一致しないアクティビティをエンドユーザーが実行した回数。

外部リターン

エンドユーザーをユーザー・フロー内部に戻したアクション。

ページ・ダウンロード時間(秒)

1ページ当たりの平均ダウンロード時間。

ページ・ロード時間(秒)

1ページ当たりの平均ロード時間。

終了したフローのページ・ロード時間(ミリ秒)

ユーザーフロー・アクティビティ中の1ページ当たりの平均ロード時間。

ページ・ロード時間P95(秒)

1ページ当たりの平均ロード時間(秒)。ただし、95%というパーセント制限を適用してあります。このため平均を算出する前に上位5%の極値が除かれ、指標としては信頼性が高くなります。

終了したフローの1ページ当たりのページ・ロード時間(秒)

ユーザーフロー・アクティビティ中の1ページ当たりの平均ページ・ロード時間(秒)。

1遷移当たりのページ・ロード時間(秒)

1遷移当たりの平均ページ・ロード時間(秒)。

1ユーザー・フロー当たりのページ・ロード時間(秒)

1ユーザー・フロー当たりの平均ページ・ロード時間(秒) (合計ページ・ロード時間と開始済ユーザー・フロー数に基づいて算出される)。

ページ読取り時間(秒)

最後にリクエストされたページのオブジェクトがクライアント・ブラウザにロードされてから、クライアントが別ページをリクエストするまでの平均時間。

ページ読取り時間P95(秒)

最後にリクエストされたページのオブジェクトがクライアント・ブラウザにロードされてから、クライアントが別ページをリクエストするまでの平均時間(秒単位)。ただし、95%というパーセント制限を適用してあります。このため平均を算出する前に上位5%の極値が除かれ、指標としては信頼性が高くなります。

ページ順序番号

セッション内のページ・ビューのシーケンス番号。

ページ・ビュー

ページ・ビューの合計数。

終了したフローのページ・ビュー

ユーザーフロー・アクティビティ中のページ・ビューの合計数。

ページ・ビュー/日

1日当たりのページ・ビュー数の平均。

ページ・ビュー/時間

1時間当たりのページ・ビュー数の平均。

1セッション当たりのページ・ビュー

1セッション当たりのページ・ビュー数の平均。

中断されたフローの割合

中断条件が満たされたため途中で終了したフローの割合。

完了したフローの割合

正常に完了したフローの割合。

停止したフローの割合

セッション・タイムアウトにより途中で終了したフローの割合。

成功フローの割合

正常に完了したフローの割合。

悪いアプリケーション・ヒット

エンドツーエンド時間が、指定された劣悪のしきい値を超えるオブジェクトの数。

悪いコール

エンドツーエンド時間が、指定されたサービス関数コール劣悪のしきい値を超えるサービス・コールの数。

悪いページ・ビュー

ページをロードするために、指定されたページ劣悪のしきい値を超える時間をクライアントが待機する必要があったページ・ビューの数。

悪いページ・ビュー(%)

クライアント・ブラウザにロードするために、指定されたページ劣悪のしきい値を超える時間をクライアントが待機する必要があったページ・ビューの割合。

終了したフローの悪いページ・ビュー

ユーザーフロー・アクティビティ中にページをロードするために、指定されたページ劣悪のしきい値を超える時間をクライアントが待機する必要があったページ・ビューの数。

終了したフローの悪いページ・ビュー(%)

ユーザーフロー・アクティビティ中にクライアント・ブラウザにロードするために、指定されたページ劣悪のしきい値を超える時間をクライアントが待機する必要があったページ・ビューの割合。

悪いステップ・アクティビティ

クライアント・ブラウザにロードするために、指定されたページ劣悪のしきい値を超える時間がかかったステップ・アクティビティの数。

進捗中ですが完了していません

完了数と、次のステップへの平均遷移数との差異。

前のステップから進む

エンドユーザーが前のステップからこのステップに進んだ回数。

1ステップ当たりの進捗

次のステップへの遷移数を最大ステップ数で割った数。

次に進む

現在をスキップ。エンドユーザーが前のステップから先のステップに進んだ回数。

進捗

ユーザー・フローの上下移動によって生じる遷移の数。

1コール当たりの応答コンテンツ・サイズ(バイト)

1サービス関数コールにおけるオブジェクトのレスポンス本文の平均サイズ(バイト単位)。

1ヒット当たりの応答コンテンツ・サイズ(バイト)

オブジェクトのレスポンス本文の平均サイズ(バイト単位)。

1コール当たりの応答ヘッダー・サイズ(バイト)

1サービス関数コールにおけるオブジェクトのレスポンス・ヘッダーの平均サイズ(バイト単位)。

1ヒット当たりの応答ヘッダー・サイズ(バイト)

オブジェクトのレスポンス・ヘッダーの平均サイズ(バイト単位)。

1コール当たりの応答サイズ(バイト)

1サービス関数コールにおけるオブジェクトのレスポンス・ヘッダーとレスポンス本文の平均サイズ(バイト単位)。

1ヒット当たりの応答サイズ(バイト)

オブジェクトのレスポンス・ヘッダーとレスポンス本文の平均サイズ(バイト単位)。

1コール当たりのリクエスト・コンテンツ・サイズ(バイト)

1サービス関数コールにおけるオブジェクトのリクエスト本文の平均サイズ(バイト単位)。

1ヒット当たりのリクエスト・コンテンツ・サイズ(バイト)

オブジェクトのリクエスト本文の平均サイズ(バイト単位)。

1コール当たりのリクエスト・ヘッダー・サイズ(バイト)

1サービス関数コールにおけるオブジェクトのリクエスト・ヘッダーの平均サイズ(バイト単位)。

1ヒット当たりのリクエスト・ヘッダー・サイズ(バイト)

オブジェクトのリクエスト・ヘッダーの平均サイズ(バイト単位)。

1コール当たりのリクエスト・サイズ(バイト)

1サービス関数コールにおけるオブジェクトのリクエスト・ヘッダーとリクエスト本文の平均サイズ(バイト単位)。

1ヒット当たりのリクエスト・サイズ(バイト)

オブジェクトのリクエスト・ヘッダーとリクエスト本文の平均サイズ(バイト単位)。

1コール当たりのリクエスト時間(ミリ秒)

サービス関数コールの平均レスポンス時間(ミリ秒単位)。

1ヒット当たりのリクエスト時間(ミリ秒)

1オブジェクトに要した平均時間(ミリ秒単位)。

次のステップから戻る

エンドユーザーが次のステップからこのステップに戻った回数。

次から戻る

現在をスキップ。エンドユーザーが次のステップから前のステップに戻った回数。

SLA日次結果

SLAの1日当たりの平均値。

SLA日次ターゲット(%)

SLAの日単位でのサービス基本契約レベルの定義。

SLA停止時間(分)

SLAの合計停止時間(分単位)。

SLAエンティティ

SLAの計算期間。

SLA失敗(%)

SLA不履行の割合(%)。

SLA金曜日

すべての金曜日においてSLAが達成されたかどうかを示します。

SLA最大値

SLAの最大目標レベル。

SLA最小値

SLAの最低目標レベル。

SLA月曜日

すべての月曜日においてSLAが達成されたかどうかを示します。

SLA月次結果

月単位でSLAが達成されたかどうかを示します。

SLA月次ターゲット(%)

SLAの月単位でのサービス基本契約レベルの定義。

SLA結果

選択された期間においてSLAが達成されたかどうかを示します。

SLA土曜日

すべての土曜日においてSLAが達成されたかどうかを示します。

SLA成功(%)

選択された期間におけるSLA達成割合(%)。

SLA日曜日

すべての日曜日においてSLAが達成されたかどうかを示します。

SLAターゲット(%)

SLAのサービス基本契約レベルの定義。

SLA木曜日

すべての木曜日においてSLAが達成されたかどうかを示します。

SLA火曜日

すべての火曜日においてSLAが達成されたかどうかを示します。

SLA稼働時間(分)

SLAの稼働時間の合計(分)。

SLA水曜日

すべての水曜日においてSLAが達成されたかどうかを示します。

SLA週次結果

週単位でSLAが達成されたかどうかを示します。

SLA週次ターゲット(%)

SLAの週単位でのサービス基本契約レベルの定義。

SLA年次結果

年単位でSLAが達成されたかどうかを示します。

SLA年次ターゲット(%)

SLAの年単位でのサービス基本契約レベルの定義。

サーバー中断アプリケーション・ヒット

オブジェクト・リクエスト中にサーバーの中断が確認された回数。この原因として、サーバーが接続をリセットした、サーバーが不適切なデータを送信した、クライアントが突然認識されなくなったなど、いくつかの理由が考えられます。

サーバー中断アプリケーション・ヒット(%)

サーバーの中断が確認されたオブジェクトの割合(%)。

サーバー中断コール

サービス関数コール中にサーバーの中断が確認された回数。この原因として、サーバーが接続をリセットした、サーバーが不適切なデータを送信した、クライアントが突然認識されなくなったなど、いくつかの理由が考えられます。

サーバー中断コール(%)

サーバーの中断が確認されたサービス関数コールの割合(%)。

サーバー中断ページ・ビュー

ページの表示時にサーバーの中断が確認された回数。この原因として、サーバーが接続をリセットした、サーバーが不適切なデータを送信した、クライアントが突然認識されなくなったなど、いくつかの理由が考えられます。

サーバー中断ページ・ビュー(%)

サーバーの中断が確認されたページ・ビューの割合(%)。

サーバー・データ(バイト)

サーバーとクライアントの間で送信されるバイト数。

サーバー・エラー・アプリケーション・ヒット

サーバー・エラーが確認されたオブジェクトの数。サーバー・エラーとは、HTTPレスポンス・コード500から599に終わったオブジェクトのことです。

サーバー・エラー・アプリケーション・ヒット(%)

サーバー・エラーが確認されたオブジェクトの割合(%)。サーバー・エラーとは、HTTPレスポンス・コード500から599に終わったオブジェクトのことです。

サーバー・エラー・コール

サービス関数コール中にサーバー・エラーが確認された回数。

サーバー・エラー・コール(%)

サーバー・エラーが確認されたサービス関数コールの割合。

終了したフローのサーバー・エラー(%)

ユーザーフロー・アクティビティ中のページの表示時にサーバー・エラーが確認されたページ・ビューの割合。

サーバー・エラー・ページ・ビュー

ページの表示時にサーバー・エラーが確認された回数。

サーバー・エラー・ページ・ビュー(%)

表示時にサーバー・エラーが確認されたページ・ビューの割合。

サーバー・エラー・ビュー(%)

サービス・エラーが確認されたページ・ビューの割合(%)。

ステップのサーバー・エラー

サーバー・エラーの数(ステップ・アクティビティのみを考慮)。

サーバー・エラー

サーバー・エラーとは、HTTPエラー・コード500から599に終わったヒットのことです。

終了したフローのサーバー・エラー

ユーザーフロー・アクティビティ中のページの表示時にサーバー・エラーが確認された回数。

1セッション当たりのサーバー・エラー

ページの表示時にサーバー・エラーが1セッション当たりに確認された平均回数。

サーバー・パケット

サーバーとクライアントの間で送信されるパケット数。

サーバー時間(%)

合計エンドツーエンド時間におけるサーバー時間の割合。

終了したフローのサーバー時間(ミリ秒)

ユーザーフロー・アクティビティ中の合計サーバー・レスポンス時間(ミリ秒)。

1コール当たりのサーバー時間(ミリ秒)

1サービス関数コール当たりの平均サーバー・レスポンス時間。

1コール当たりのサーバー時間P95 (ミリ秒)

1サービス関数コール当たりの平均サーバー・レスポンス時間。

1ヒット当たりのサーバー時間(ミリ秒)

1ヒット当たりの平均サーバー・レスポンス時間。

1ページ当たりのサーバー時間(ミリ秒)

1ページ当たりの平均サーバー・レスポンス時間(ミリ秒単位)。

終了したフローの1ページ当たりのサーバー時間(ミリ秒)

ユーザーフロー・アクティビティ中の1ページ当たりの平均サーバー・レスポンス時間(ミリ秒)。

1ページ当たりのサーバー時間P95 (ミリ秒)

1ページ当たりの平均サーバー・レスポンス時間(ミリ秒単位)。ただし、95%というパーセント制限を適用してあります。このため平均を算出する前に上位5%の極値が除かれ、指標としては信頼性が高くなります。

サーバー・タイムアウト・アプリケーション・ヒット

サーバー・タイムアウトが確認されたオブジェクトの数。サーバー・タイムアウトは、サーバーがクライアントからのリクエストに対する応答に失敗した場合に発生します。つまり、レスポンスは送信されないか、一部のみが送信されます。

サーバー・タイムアウト・アプリケーション・ヒット(%)

サーバー・タイムアウトが確認されたオブジェクトの割合(%)。サーバー・タイムアウトは、サーバーがクライアントからのリクエストに対する応答に失敗した場合に発生します。つまり、レスポンスは送信されないか、一部のみが送信されます。

サーバー・タイムアウト・コール

サービス関数コール中に確認されたサーバー・タイムアウトの回数。サーバー・タイムアウトは、サーバーがクライアントからのリクエストに対する応答に失敗した場合に発生します。つまり、レスポンスは送信されないか、一部のみが送信されます。

サーバー・タイムアウト・コール(%)

サービス関数コール中に確認されたサーバー・タイムアウトの回数。ただし、95%というパーセント制限を適用してあります。このため平均を算出する前に上位5%の極値が除かれ、指標としては信頼性が高くなります。サーバー・タイムアウトは、サーバーがクライアントからのリクエストに対する応答に失敗した場合に発生します。つまり、レスポンスは送信されないか、一部のみが送信されます。

サーバー・タイムアウト・ページ・ビュー

サーバー・タイムアウトが確認されたページ・ビューの数。サーバー・タイムアウトは、サーバーがクライアントからのリクエストに対する応答に失敗した場合に発生します。つまり、レスポンスは送信されないか、一部のみが送信されます。

サーバー・タイムアウト・ページ・ビュー(%)

サーバー・タイムアウトが確認されたページ・ビューの数。ただし、95%というパーセント制限を適用してあります。このため上位5%の極値が除かれ、指標としては信頼性が高くなります。サーバー・タイムアウトは、サーバーがクライアントからのリクエストに対する応答に失敗した場合に発生します。つまり、レスポンスは送信されないか、一部のみが送信されます。

セッション継続時間(秒)

平均セッション期間(秒単位)。

セッション・ロード時間(秒)

1セッション当たりでページのロードに使用された平均時間(秒単位)。

セッション読取り時間(秒)

1セッション当たりでページの参照に使用された平均時間(秒単位)。これは、ページ(およびすべてのオブジェクト)がロードされてから次のページ・リクエストまでの時間です。つまり、ビジターがページを読むための時間です。

1ページ当たりのセッション時間(秒)

1セッション中に1ページに使用された平均時間(秒単位)。

セッション

セッションの数。ビジターがWebサイトに(最低15分の間隔を置いて)アクセスするたびに、セッションがカウントされます。

最初のステップのセッション

ユーザー・フローの最初のステップを表すセッションの数。

最後のステップのセッション

ユーザー・フローの最後のステップを表すセッションの数。

ステップのセッション

選択されたユーザー・フローを表すセッションの数。

セッション/日

1日当たりの平均セッション数。

1コール当たりのサイズ(バイト)

1サービス関数コールにおけるオブジェクトのリクエストとレスポンスの平均サイズ(バイト単位)。

1ヒット当たりのサイズ(バイト)

オブジェクトのリクエストとレスポンスの平均サイズ(バイト単位)。

開始されたユーザー・フロー

開始されたユーザー・フローの数。

1ページ当たりの静的アプリケーション・ヒット

1ページ当たりの静的オブジェクト数の平均。

1ヒット当たりの静的コンテンツ・サイズ(バイト)

本文内のリクエストされた静的オブジェクトの平均サイズ(バイト単位)。

1ページ当たりの静的コンテンツ・サイズ(バイト)

ページ・ヘッダー内のすべての静的オブジェクトの合計サイズの平均(バイト単位)。

1ページ当たりの静的エンドツーエンド時間(ミリ秒)

表示されたページにおける、すべてのオブジェクトの静的ネットワーク時間と静的サーバー・レスポンス時間をあわせた時間の平均。

1ページ当たりの静的ヘッダー・サイズ(バイト)

ページ・ヘッダー内のすべての静的オブジェクトの合計サイズの平均(バイト単位)。

1ヒット当たりの静的ネットワーク時間(ミリ秒)

サーバーが応答してから静的オブジェクトがクライアント・ブラウザに到達するまでの平均時間(ミリ秒単位)。

1ページ当たりの静的ネットワーク時間(ミリ秒)

サーバーが応答してからページ内のすべての静的オブジェクトがクライアント・ブラウザに到達するまでの平均時間(ミリ秒単位)。

1ヒット当たりの静的サーバー時間(ミリ秒)

ページ内の静的オブジェクトの平均サーバー・レスポンス時間(ミリ秒単位)。

1ページ当たりの静的サーバー時間(ミリ秒)

ページ内におけるすべての静的オブジェクトの合計サーバー・レスポンス時間の平均(ミリ秒単位)。

1ヒット当たりの静的サイズ(バイト)

リクエストされた静的オブジェクトの平均サイズ(バイト単位)。

1ページ当たりの静的サイズ(バイト)

ページ内のすべての静的オブジェクトの合計サイズの平均(バイト単位)。

1ヒット当たりの静的時間(ミリ秒)

すべての動的オブジェクトのエンドツーエンド時間の平均(ミリ秒単位)。つまり、それらのネットワーク時間とサーバー・レスポンス時間の合計です。

1ページ当たりの静的時間(ミリ秒)

ページ上のすべての静的オブジェクトのエンドツーエンド時間の平均(ミリ秒単位)。つまり、それらのネットワーク時間とサーバー・レスポンス時間の合計です。

統計ステータス・コード

スナップショット中に監視されたTCPトラフィックのステータスを示します。付録「監視対象ネットワーク・トラフィックの確認」を参照してください。

ステップ変更

エンドユーザーをユーザー・フロー内の1ステップ先に進めた、または前に戻したアクション(開始と完了を含む)。

ステップ番号

ユーザー・フロー内のステップの数。

停止したユーザー・フロー

セッション・タイムアウトによって終了したユーザー・フローの数。

成功アプリケーション・ヒット

定義された満足度のしきい値内で正常にロードされたオブジェクトの数。

成功率

進行したユーザー・フロー内の完了済ユーザー・フローの割合(最大100%)。

成功率

ユーザー・フローの成功率(完了したユーザー・フロー数を進行遷移数で割って計算される)。

テスト動的ネットワーク時間(ミリ秒)

サービス・テスト(ビーコン)トラフィック内のすべての動的オブジェクトをネットワーク経由で送信するために要した時間(ミリ秒単位)。

テスト動的サーバー時間(ミリ秒)

サービス・テスト(ビーコン)トラフィックのサーバー・レスポンス時間(ミリ秒単位)。

テスト・ロード時間(秒)

サービス・テスト(ビーコン)トラフィック内のページをロードするための時間(秒単位)。

テスト・ネットワーク・エラー・ページ・ビュー(%)

ネットワーク・エラーが確認された、サービス・テスト(ビーコン)トラフィック内のページ・ビューの割合(%)。

テスト・ページ・ビュー

サービス・テスト(ビーコン)トラフィック内のページ・ビューの数。

テスト読取り時間(秒)

最後にリクエストされたページ・オブジェクトがクライアントによってロードされてから、クライアントが別ページをリクエストするまでの、サービス・テスト(ビーコン)トラフィック内の時間(秒単位)。

テスト・サーバー・エラー・ページ・ビュー(%)

サービス・テスト(ビーコン)トラフィック内でエラーが確認されたページ・ビューの割合(%)。

テスト静的ネットワーク時間(ミリ秒)

サービス・テスト(ビーコン)トラフィック内の静的オブジェクトをネットワーク経由で送信するために要した時間(ミリ秒単位)。

テスト静的サーバー時間(ミリ秒)

サービス・テスト(ビーコン)トラフィック内の静的オブジェクトのサーバー・レスポンス時間(ミリ秒単位)。

テスト・トラフィック・アプリケーション・ページ・ビュー

悪いページ・ビューの合計数。

テスト・トラフィック・コンテンツ・エラー・ページ・ビュー(%)

コンテンツ・エラーが確認された、サービス・テスト(ビーコン)トラフィック内のページ・ビューの割合(%)。

テスト・トラフィック・ユーザー違反

サービス・テスト(ビーコン)トラフィックで検出されたコンテンツ通知およびクライアント中断の合計数。

テスト・トラフィック違反ページ・ビュー

サービス・テスト(ビーコン)トラフィック内でユーザーおよびアプリケーション違反が検出されたページ・ビューの割合。

テスト・トラフィックWebサイト・エラー・ページ・ビュー(%)

サービス・テスト(ビーコン)トラフィック内でエラーが確認されたページ・ビューの割合。

テスト訪問時間(秒)

サービス・テスト(ビーコン)トラフィック内のセッションの時間(秒単位)。

日数

日数。

スループット(KBps)

サーバーの合計スループット(KB/秒単位)。

フロー当たりに要した時間(ミリ秒)

1フロー当たりに要した平均時間。

フローに要した合計アクティブ時間(ミリ秒)

完了したユーザー・フローの合計アクティブ時間。

合計ブラウザ・ビジー時間(ミリ秒)

所要時間(ミリ秒)。

合計クライアント時間(ミリ秒)

クライアント側でのアクティビティによって生じる合計遅延時間(ミリ秒単位)。

中断時の合計コンテンツ・エラーの割合

中断されたユーザー・フローにおけるコンテンツ・エラーの割合。

取消し時の合計コンテンツ・エラーの割合

停止したユーザー・フローにおけるコンテンツ・エラーの割合。

完了時の合計コンテンツ・エラーの割合

コンテンツ・エラーが含まれていた完了済ユーザー・フローの割合。

停止したユーザー・フローにおける合計コンテンツ・エラーの割合

セッション・タイムアウト時に見つかったコンテンツ・エラーの割合。

中断時の合計コンテンツ・エラー

中断されたユーザー・フローにおけるコンテンツ・エラーの合計数。

取消し時の合計コンテンツ・エラー

停止したユーザー・フローにおけるコンテンツ・エラーの合計数。

完了時の合計コンテンツ・エラー

完了したユーザー・フローにおけるコンテンツ・エラーの合計数。

停止したユーザー・フローにおける合計コンテンツ・エラー

セッション・タイムアウト時に見つかったコンテンツ・エラーの合計数。

合計動的アプリケーション・ヒット

動的オブジェクトの合計数。

合計動的コンテンツ・サイズ(バイト)

すべての動的オブジェクトの合計本文サイズ(バイト単位)。

合計動的ヘッダー・サイズ(バイト)

すべての動的オブジェクトの合計ヘッダー・サイズ(バイト単位)。

合計動的ネットワーク時間(ミリ秒)

すべての動的オブジェクトに要した合計ネットワーク時間(ミリ秒単位)。

合計動的サーバー時間(ミリ秒)

すべての動的オブジェクトに要した合計サーバー・レスポンス時間(ミリ秒単位)。

合計動的サイズ(バイト)

すべての動的オブジェクトの合計サイズ(バイト単位)。

合計動的時間(ミリ秒)

すべての動的オブジェクトに要した合計時間(ミリ秒単位)。

合計エンドツーエンド時間(ミリ秒)

合計エンドツーエンド時間(ミリ秒単位)。これには、ネットワーク転送時間とサーバー・レスポンス時間を含みます。

中断時の合計エラーの割合

中断されたユーザー・フローにおけるすべてのエラーの割合。

取消し時の合計エラーの割合

停止したユーザー・フローにおける合計エラーの割合。

完了時の合計エラーの割合

完了したユーザー・フローにおけるエラーの割合。

停止したユーザー・フローにおける合計エラーの割合

セッション・タイムアウト時に見つかったエラーの割合。

中断時の合計エラー

中断されたユーザー・フローにおけるエラーの合計数。

取消し時の合計エラー

停止したユーザー・フローにおけるエラーの合計数。

完了時の合計エラー

完了したユーザー・フローにおけるエラーの合計数。

停止したユーザー・フローにおける合計エラー

セッション・タイムアウト時に見つかったエラーの合計数。

中断時の良好なページ・ビューの合計

中断されたユーザー・フローにおける良好なページ・ビューの合計数。

取消し時の良好ページ・ビューの合計

停止したユーザー・フローにおける良好なページ・ビューの合計数。

完了時の良好なページ・ビューの合計

完了したユーザー・フローにおける良好なページ・ビューの合計数。

停止したユーザー・フローにおける良好なページ・ビューの合計

セッション・タイムアウト時の良好なユーザー・フロー・ページ・ビューの合計数。

中断時の良好の合計の割合

中断されたユーザー・フローにおける良好なページ・ビューの割合。

取消し時の良好の合計の割合

停止したユーザー・フローにおける良好なページ・ビューの割合。

完了時の良好の合計の割合

完了したユーザー・フローにおける良好なページ・ビューの割合。

停止したユーザー・フローにおける良好の合計の割合

セッション・タイムアウト時の良好なユーザー・フロー・ページ・ビューの割合。

合計ヘッダー・サイズ(バイト)

ページのヘッダー・サイズ(バイト単位)。

フローに要した合計アイドル時間(ミリ秒)

完了したユーザー・フローの合計アイドル時間。

合計通貨値

合計通貨値。

中断時の合計通貨値

エンドユーザーがユーザー・フローを中断したために失われた合計通貨値。

完了時の合計通貨値

完了したユーザー・フローによって取得された合計通貨値。

失敗時の合計通貨値

ユーザー・フローの中断時またはセッション・タイムアウト時に失われた合計通貨値。

中断時の合計ネットワーク・エラーの割合

中断されたユーザー・フローにおけネットワーク・エラーの割合。

取消し時の合計ネットワーク・エラーの割合

停止したユーザー・フローにおけるネットワーク・エラーの割合。

完了時の合計ネットワーク・エラーの割合

完了したユーザー・フローにおけるネットワーク・エラーの割合。

停止したユーザー・フローにおける合計ネットワーク・エラーの割合

セッション・タイムアウト時にユーザー・フローについて見つかったネットワーク・エラーの割合。

中断時の合計ネットワーク・エラー

中断されたユーザー・フローにおけるネットワーク・エラーの合計数。

取消し時の合計ネットワーク・エラー

停止したユーザー・フローにおけるネットワーク・エラーの合計数。

完了時の合計ネットワーク・エラー

完了したユーザー・フローにおけるネットワーク・エラーの合計数。

停止したユーザー・フローにおける合計ネットワーク・エラー

セッション・タイムアウト時のネットワーク・エラーの合計数。

合計ネットワーク時間(ミリ秒)

合計ネットワーク転送時間(ミリ秒単位)。

中断時の合計ネットワーク時間

中断されたユーザー・フローで使用された合計ネットワーク時間(ミリ秒)。

取消し時の合計ネットワーク時間

停止したユーザー・フローで使用された合計ネットワーク時間。

完了時の合計ネットワーク時間

完了したユーザー・フローで使用された合計ネットワーク時間(ミリ秒)。

停止したユーザー・フローにおける合計ネットワーク時間

セッション・タイムアウト時にユーザー・フローで使用された合計ネットワーク時間(ミリ秒)。

中断時の問題のないページ・ビューの合計の割合

中断されたユーザー・フローにおける問題のないページ・ビューの割合。

取消し時の問題のないページ・ビューの合計の割合

停止したユーザー・フロー内の問題のないページ・ビューの割合。

完了時の問題のないページ・ビューの合計の割合

完了したユーザー・フローにおける問題のないページ・ビューの割合。

停止したユーザー・フローにおける問題のないページ・ビューの合計の割合

セッション・タイムアウト時の問題のないユーザー・フロー・ページ・ビューの割合。

中断時の問題のないページ・ビューの合計

中断されたユーザー・フローにおける問題のないページ・ビューの合計数。

取消し時の問題のないページ・ビューの合計

停止したユーザー・フロー内の問題のないページ・ビューの合計数。

完了時の問題のないページ・ビューの合計

完了したユーザー・フローにおける問題のないページ・ビューの合計数。

停止したユーザー・フローにおける問題のないページ・ビューの合計

セッション・タイムアウト時の問題のないユーザー・フロー・ページ・ビューの数。

1ページ当たりの合計オブジェクト・サイズ(バイト)

ページ・ビュー内におけるすべてのオブジェクトの合計サイズの平均(バイト単位)。

フローに要した合計外部時間(ミリ秒)

完了したユーザー・フローの合計外部時間。

合計ページ・ロード時間(秒)

クライアント・ブラウザがすべてのページ・ビューの処理に要した合計時間(ミリ秒単位)。

中断時の合計ページ・ロード時間

中断されたユーザー・フローで使用された合計ページ・ロード時間(秒)。

取消し時の合計ページ・ロード時間

停止したユーザー・フローで使用された合計ページ・ロード時間(秒)。

完了時の合計ページ・ロード時間

完了したユーザー・フローで使用された合計ページ・ロード時間(秒)。

停止したユーザー・フローにおける合計ページ・ロード時間

セッション・タイムアウト時のユーザー・フローの合計ページ・ロード時間(秒)。

合計ページ読取り時間(秒)

最後にリクエストされたページのオブジェクトがクライアント・ブラウザにロードされてから、クライアントが別ページをリクエストするまでの合計時間(秒単位)。

中断時のページ・ビューの合計

中断されたユーザー・フローにおけるページ・ビューの合計数。

取消し時のページ・ビューの合計

停止したユーザー・フローにおけるページ・ビューの合計数。

完了時のページ・ビューの合計

完了したユーザー・フローにおけるページ・ビューの合計数。

終了したユーザー・フローにおけるページ・ビューの合計

終了したユーザー・フローにおけるページ・ビューの合計数。

停止したユーザー・フローにおけるページ・ビューの合計

セッション・タイムアウト時のユーザー・フロー・ページ・ビューの合計数。

中断時の悪いページ・ビューの合計

中断されたユーザー・フローにおける悪いページ・ビューの合計数。

取消し時の悪いページ・ビューの合計

停止したユーザー・フローにおける悪いページ・ビューの合計数。

完了時の悪いページ・ビューの合計

完了したユーザー・フローにおける悪いページ・ビューの合計数。

停止したユーザー・フローにおける悪いページ・ビューの合計

セッション・タイムアウト時にユーザー・フローについて見つかった悪いページ・ビューの合計数。

中断時の悪い合計の割合

中断されたユーザー・フローにおける悪いページ・ビューの割合。

取消し時の悪い合計の割合

停止したユーザー・フローにおける悪いページ・ビューの割合。

完了時の悪い合計の割合

完了したユーザー・フローにおける悪いページ・ビューの割合。

停止したユーザー・フローにおける悪い合計の割合

セッション・タイムアウト時にユーザー・フローについて見つかった悪いページ・ビューの割合。

合計応答コンテンツ・サイズ(バイト)

レスポンス本文のすべての部分の合計サイズ(バイト単位)。

合計応答ヘッダー・サイズ(バイト)

レスポンス・ヘッダーのすべての部分の合計サイズ(バイト単位)。

合計応答サイズ(バイト)

応答全体の合計サイズ(バイト)。

合計リクエスト・コンテンツ・サイズ(バイト)

リクエスト本文のすべての部分の合計サイズ(バイト単位)。

合計リクエスト・ヘッダー・サイズ(バイト)

リクエスト・ヘッダーのすべての部分の合計サイズ(バイト単位)。

合計リクエスト・サイズ(バイト)

すべてのリクエストの合計サイズ(バイト)。

合計リクエスト時間(ミリ秒)

すべてのリクエストの合計時間(ミリ秒単位)。

中断時の合計サーバー・エラーの割合

中断されたユーザー・フローにおけるサーバー・エラーの割合。

取消し時の合計サーバー・エラーの割合

停止したユーザー・フローにおけるサーバー・エラーの割合。

完了時の合計サーバー・エラーの割合

完了したユーザー・フローにおけるサーバー・エラーの割合。

停止したユーザー・フローにおける合計サーバー・エラーの割合

セッション・タイムアウト時に見つかったユーザー・フロー・サーバー・エラーの割合。

中断時の合計サーバー・エラー

中断されたユーザー・フローで見つかったサーバー・エラーの合計数。

取消し時の合計サーバー・エラー

停止したユーザー・フローにおけるサーバー・エラーの合計数。

完了時の合計サーバー・エラー

完了したユーザー・フローにおけるサーバー・エラーの合計数。

停止したユーザー・フローにおける合計サーバー・エラー

セッション・タイムアウト時に見つかったユーザー・フロー・サーバー・エラーの合計数。

合計サーバー時間(ミリ秒)

合計サーバー・レスポンス時間(ミリ秒単位)。

中断時の合計サーバー時間

中断されたユーザー・フローで使用された合計サーバー時間(ミリ秒)。

取消し時の合計サーバー時間

停止したユーザー・フローで使用された合計サーバー時間(ミリ秒)。

完了時の合計サーバー時間

完了したユーザー・フローで使用された合計サーバー時間(ミリ秒)。

停止したユーザー・フローにおける合計サーバー時間

セッション・タイムアウト時にユーザー・フローで使用された合計サーバー時間(ミリ秒)。

合計セッション時間(秒)

すべてのセッションの合計時間(秒単位)。

合計静的アプリケーション・ヒット

すべての静的オブジェクトの合計数。

合計静的コンテンツ・サイズ(バイト)

静的オブジェクトのすべての本文セクションの合計サイズ(バイト単位)。

合計静的ヘッダー・サイズ(バイト)

静的ヘッダーのすべてのセクションの合計サイズ(バイト単位)。

合計静的ネットワーク時間(ミリ秒)

すべての静的オブジェクトのネットワーク転送時間の合計(ミリ秒単位)。

合計静的サーバー時間(ミリ秒)

すべての静的オブジェクトのサーバー・レスポンス時間の合計(ミリ秒単位)。

合計静的サイズ(バイト)

すべての静的オブジェクトの合計サイズ(バイト)。

合計静的時間(ミリ秒)

すべての静的オブジェクトのネットワーク時間とサーバー時間の合計(ミリ秒)。

フローに要した合計時間(ミリ秒)

フローに要した合計時間。

合計トラフィック(バイト)

すべてのページとそのオブジェクトの合計サイズ(バイト)。

合計転送時間(ミリ秒)

サーバーが応答してからクライアントに到達するまでに要した合計時間(ミリ秒単位)。

中断時の合計Webサイト・エラーの割合

中断されたユーザー・フローにおけるWebサイト・エラーの割合。

完了時の合計Webサイト・エラーの割合

完了したユーザー・フローにおけるWebサイト・エラーの割合。

停止したユーザー・フローにおける合計Webサイト・エラーの割合

セッション・タイムアウト時のユーザー・フローWebサイト・エラーの割合。

中断時の合計Webサイト・エラー

中断されたユーザー・フローにおけるWebサイト・エラーの合計数。

完了時の合計Webサイト・エラー

完了したユーザー・フローにおけるWebサイト・エラーの合計数。

取消し時の合計Webサイト・エラーの割合

停止したユーザー・フロー内のWebサイト・エラーの割合。

取消し時の合計Webサイト・エラー

停止したユーザー・フロー内のWebサイト・エラーの合計数。

停止したユーザー・フローにおける合計Webサイト・エラー

セッション・タイムアウト時のユーザー・フローWebサイト・エラーの合計数。

トラフィック/日(バイト)

すべてのページとそのオブジェクトの1日当たりの平均サイズ(バイト単位)。

1セッション当たりのトラフィック(バイト)

セッション内のすべてのページとそのオブジェクトの合計サイズの平均(バイト単位)。

トランザクション・ステップ番号

ユーザー・フロー内のステップの順序。

1コール当たりの転送時間(ミリ秒)

サーバーが応答してからサービス関数コールがクライアントに到達するまでの平均時間(ミリ秒単位)。

1ヒット当たりの転送時間(ミリ秒)

サーバーが応答してからオブジェクトがクライアント・ブラウザに到達するまでの平均時間(ミリ秒単位)。

遷移

エンド・ユーザーをユーザー・フロー内の1ステップ先に進めた、または前に戻したアクション(開始と完了を含む)。

次のステップへの遷移

次のユーザー・フロー・ステップへの遷移数(開始と完了を含む)。

前のステップへの遷移

前のステップへの遷移数。

ユーザー動的ネットワーク時間(ミリ秒)

サービス・テスト(実際のユーザー)トラフィック内の動的オブジェクトをネットワーク経由で送信するために要した時間(ミリ秒単位)。

ユーザー動的サーバー時間(ミリ秒)

サービス・テスト(実際のユーザー)トラフィック内の動的オブジェクトのサーバー・レスポンス時間(ミリ秒単位)。

ユーザー・フロー完了(%)

セッション中に開始されて正常終了したユーザー・フローの割合(%)。

ユーザー・フロー・ロード時間(秒)

ユーザー・フローに含まれるすべてのページの合計ロード時間(秒単位)。

ユーザー・フロー・ネットワーク時間(ミリ秒)

ユーザー・フローに含まれるすべてのページの合計ネットワーク転送時間(ミリ秒単位)。

ユーザー・フロー・ページ・ビュー

ユーザー・フロー内のページ・ビューの数。

ユーザー・フロー読取り時間(秒)

ユーザー・フローに含まれていたすべてのページの合計読取り時間(最後にリクエストされたページ・オブジェクトがクライアント・ブラウザにロードされる間)。

ユーザー・フロー・サーバー時間(ミリ秒)

ユーザー・フローに含まれるすべてのページの合計サーバー・レスポンス時間(ミリ秒単位)。

ユーザー・フロー訪問時間(秒)

クライアントがユーザー・フローで使用した合計時間(秒単位)。つまり、クライアントがトランザクションを正常に終了するか、中止するまでの時間です。

終了したユーザー・フロー

終了したフローの数(成功または中断)。

ユーザー・フロー失敗

中断またはセッション・タイムアウトにより途中で終了したフローの数。

非アクティブなユーザー・フロー

非アクティブなユーザー・フローの数(アイドル状態および外部の数値に基づいて計算される)。

ユーザー・フロー成功

正常に完了したフローの数。

ユーザー・ロード時間(秒)

サービス・テスト(実際のユーザー)トラフィック内のページをロードするための時間(秒単位)。

ユーザー・ネットワーク・エラー・ページ・ビュー(%)

サービス・テスト(実際のユーザー)トラフィック内でネットワーク・エラーが確認されたページ・ビューの割合(%)。

ユーザー・ページ・ビュー

サービス・テスト(実際のユーザー)トラフィック内のページ・ビューの数。

ユーザー読取り時間(秒)

最後にリクエストされたページ・オブジェクトがクライアントによってロードされてからの、サービス・テスト(実際のユーザー)トラフィック内の時間(秒単位)。

ユーザー・サーバー・エラー・ページ・ビュー(%)

サービス・テスト(実際のユーザー)トラフィック内でサーバー・エラーが確認されたページ・ビューの割合(%)。

ユーザー静的ネットワーク時間(ミリ秒)

サービス・テスト(実際のユーザー)トラフィック内の静的オブジェクトをネットワーク経由で送信するために要した時間(ミリ秒単位)。

ユーザー静的サーバー時間(ミリ秒)

サービス・テスト(実際のユーザー)トラフィック内の静的オブジェクトのサーバー・レスポンス時間(ミリ秒単位)。

ユーザー・トラフィック・アプリケーション違反ページ・ビュー

サービス・テスト(実際のユーザー)トラフィック内で検出されたコンテンツ通知およびクライアント中断の合計数。

ユーザー・トラフィック・ユーザー・コンテンツ・エラー・ページ・ビュー(%)

サービス・テスト(実際のユーザー)トラフィック内でコンテンツ・エラーが検出されたページ・ビューの割合。

ユーザー・トラフィック・ユーザー違反ページ・ビュー

サービス・テスト(実際のユーザー)トラフィックで検出されたコンテンツ通知およびクライアント中断の合計数。

ユーザー・トラフィックWebサイト・エラー・ページ・ビュー(%)

Webサイト・エラーが確認された、サービス・テスト(実際のユーザー)トラフィック内のページ・ビューの割合(%)。

ユーザー違反コール

サービス・テスト(実際のユーザー)トラフィック内でコンテンツ通知およびクライアント中断が検出されたWebサービス・コールの数。

ユーザー違反コール(%)

サービス・テスト(実際のユーザー)トラフィック内でコンテンツ通知およびクライアント中断が検出されたWebサービス・コールの割合。

終了したフローのユーザー違反(%)

ユーザーフロー・アクティビティ中にサービス・テスト(実際のユーザー)トラフィック内でコンテンツ通知およびクライアント中断が検出されたページ・ビューの割合。

ユーザー違反ページ・ビュー

サービス・テスト(実際のユーザー)トラフィック内でコンテンツ通知およびクライアント中断が検出されたページ・ビューの数。

ユーザー違反ページ・ビュー(%)

サービス・テスト(実際のユーザー)トラフィック内でコンテンツ通知およびクライアント中断が検出されたページ・ビューの割合。

終了したフローのユーザー違反

ユーザーフロー・アクティビティ中にサービス・テスト(実際のユーザー)トラフィック内でコンテンツ通知およびクライアント中断が検出されたページ・ビューの数。

ユーザー訪問時間(秒)

サービス・テスト(実際のユーザー)トラフィック内のセッション時間(秒単位)。

最初のステップのビュー

最初のユーザー・フロー・ステップにあるページ・ビューの数。

最後のステップのビュー

最後のユーザー・フロー・ステップにあるページ・ビューの数。

ステップのビュー

ユーザー・フロー・ステップにあるページ・ビューの数。

違反コール

検出されたコンテンツ通知、クライアント中断、悪いWebサービス・コールと、Webサイト、ネットワーク、サーバー、コンテンツのエラーの合計数。

違反コール(%)

コンテンツ通知、クライアント中断、悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーが検出されたWebサービス・コールの割合。

終了したフローの違反(%)

ユーザーフロー・アクティビティ中に検出されたコンテンツ通知、クライアント中断、悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーの割合。

違反ページ・ビュー

検出されたコンテンツ通知、クライアント中断、悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーの合計数。

違反ページ・ビュー(%)

コンテンツ通知、クライアント中断、悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーが検出されたページ・ビューの割合。

終了したフローの違反

ユーザーフロー・アクティビティ中に検出されたコンテンツ通知、クライアント中断、悪いページ・ビューとWebサイト、ネットワーク、サーバーおよびコンテンツ・エラーの合計数。

(開始された)1ユーザー・フロー当たりの訪問時間(秒)

(開始された)1ユーザー・フロー当たりの平均訪問時間。

1ステップ当たりの訪問時間(秒)

1ユーザー・フロー・ステップ当たりの平均訪問時間(分)。

1遷移当たりの訪問時間(秒)

1遷移当たりの平均訪問時間(分)。

1ユーザー・フロー当たりの訪問時間(分)

ユーザー・フロー訪問時間(分)。

Webサイト・エラー・アプリケーション・ヒット

Webサイト・エラーが確認された、サービス・テスト(実際のユーザー)トラフィック内のオブジェクトの数。

Webサイト・エラー・アプリケーション・ヒット(%)

Webサイト・エラーが確認された、サービス・テスト(実際のユーザー)トラフィック内のオブジェクトの割合(%)。

Webサイト・エラー・コール

サービス関数コール中にWebサイト・エラーが確認された回数。

Webサイト・エラー・コール(%)

ネットワークのWebサイト・エラーが発生したサービス関数コールの割合(%)。

Webサイト・エラー・ページ・ビュー

ページの表示時にWebサイト・エラーが確認された回数。

Webサイト・エラー・ページ・ビュー(%)

ネットワークのWebサイト・エラーが発生したページ・ビューの割合(%)。

Webサイト・エラー・ビュー(%)

ネットワークWebサイト・エラーが発生したページ・ビューの割合。

Webサイト・エラー

Webサイト・エラーとは、HTTPエラー・コード400から499に終わったヒットのことです。

1セッション当たりのWebサイト・エラー

セッション中、ページの表示時にWebサイト・エラーが確認された平均回数。

終了したフローのWebサイト・エラー(%)

ユーザーフロー・アクティビティ中にネットワークWebサイト・エラーが発生したページ・ビューの割合。

終了したフローのWebサイト・エラー

ユーザーフロー・アクティビティ中のページの表示時にWebサイト・エラーが確認された回数。

E.2 KPIメトリック

RUEIで使用可能なKPIメトリックを表E-2に示します。

表E-2 KPIメトリック

メトリック

説明

コール当たりのApdex

Apdexは、0から1の値を使用する索引形式でトランザクション・アプリケーションのレスポンス時間のメトリックを計算およびレポートするための方法です。この数値はコール当たりの平均として計算され、失敗/悪い満足度は0、問題のない満足度は0.5、良好は1としてレポートされます。

アプリケーション違反

検出された悪いページ・ビューまたはWebサイト、ネットワーク、サーバーおよびコンテンツのエラーの数。

ブラウザのビジー時間

クライアント側でのブラウザ・アクティビティによって生じる、1ヒット当たりの平均遅延時間。これは、クライアントのTCPウィンドウ・サイズが0と示される期間です。

ブラウザ例外

ブラウザJSライブラリにより測定されたブラウザ例外数。

ブラウザ・ヒット

ブラウザJSライブラリにより測定されるページ上のオブジェクト数。

ブラウザ時間

ブラウザがページのレンダリングに費やした時間。

取り消されたユーザー・フロー

(中断またはセッション・タイムアウトによって)停止したユーザー・フローの数。

クライアント中断

関数またはページのロード中にクライアントが接続を閉じたためにクライアントが転送を中断した回数。

完了したユーザー・フロー

正常に完了したユーザー・フローの数。

同時セッション

計算での現在のアクティブ・セッションの数。

コンテンツ・エラー

サービス関数コールまたはページ・ビュー中に確認されたコンテンツ・エラーの数。

コンテンツ通知

コンテンツ通知が確認されたサービス関数コールまたはページ・ビュー。

コンテンツ・サイズ

オブジェクト・コンテンツのサイズ(ヘッダーを除く)。

データベース処理時間

データベース・サーバーがアクションを処理するために費やした1ページ・ビュー当たりの時間。

ダウンロード時間

1ページ当たりのダウンロード時間。これは、ページの最初のオブジェクトの配信が開始されてから最後のオブジェクトの配信が完了するまでの経過時間です。

終了したユーザー・フロー

終了したユーザー・フロー。

エラー

なんらかの理由で正常に呼び出されなかったまたは表示されなかった関数コールまたはページ・ビュー。

フロー遷移

フロー遷移数。

ヘッダー・サイズ

オブジェクト・ヘッダーのサイズ(コンテンツを除く)。

ヒット

ヒット数。

非アクティブなユーザー・フロー

計算時に非アクティブであったユーザー・フロー。

ロード時間

このページ・ビューまたは関数コールのロード時間。

ネットワーク・エラー

この関数コールまたはページについて確認されたネットワーク・エラーの数。

ネットワーク・スループット

ネットワーク時間当たりの平均オブジェクト・サイズ。

ネットワーク時間

合計ダウンロード時間の割合(%)としてのネットワーク転送時間。

ネットワーク・タイムアウト

測定されたネットワーク・タイムアウトの数。

ページApdex

Apdexは、0から1の値を使用する索引形式でトランザクション・アプリケーションのレスポンス時間のメトリックを計算およびレポートするための方法です。この数値はページ当たりの平均として計算され、失敗/悪い満足度は0、問題のない満足度は0.5、良好は1としてレポートされます。

読取り時間

ページ(およびそのすべてのオブジェクト)のロードから次のページ・リクエストまでの時間、つまり、ビジターがページを読むために使用可能な時間。

応答コンテンツ・サイズ

応答コンテンツのサイズ。

応答ヘッダー・サイズ

応答ヘッダーのサイズ。

リプライ・サイズ

応答(コンテンツとヘッダー)のサイズ。

リクエスト・コンテンツ・サイズ

リクエスト・コンテンツのサイズ。

リクエスト・ヘッダー・サイズ

リクエスト・ヘッダーのサイズ。

リクエスト・サイズ

リクエスト(コンテンツとヘッダー)のサイズ。

満足度が良好

ロード時間が定義済の満足度しきい値内であった関数コールまたはページ・ビューの数。

満足度OK

ロード時間が定義済の満足度しきい値を超えているが、このしきい値の4倍未満であった関数コールまたはページ・ビューの数。

満足度が悪い

ロード時間が定義済の満足度しきい値の4倍を超えていた関数コールまたはページ・ビューの数。

サーバー中断

関数またはページのロード中にサーバーが接続を閉じたためにサーバーが転送を中断した回数。

サーバー・エラー

サービス関数コールまたはページ・ビューの間に確認されたサーバー・エラーの数。

サーバー時間

サービス関数コールまたはページ・ビューのサーバー・レスポンス時間を合計ダウンロード時間の割合(%)として表した値。

サーバー・タイムアウト

関数コールまたはページ・ビューの間に確認されたサーバー側タイムアウトの数。

サイズ

関数コールまたはページ・ビュー当たりのトラフィックのサイズ。

開始されたユーザー・フロー

開始されたユーザー・フローの数。

ステップ変更

エンドユーザーをユーザー・フロー内の1ステップ先に進めたアクション、または1ステップ前に戻したアクション(開始と完了を含む)の数。

停止したユーザー・フロー

セッション・タイムアウトによって終了したユーザー・フローの数。

転送時間

サーバーが応答してからサービス関数コールまたはページ・ビューがクライアントに到達するまでの時間。

ユーザー違反

検出されたコンテンツ通知とクライアント中断の数。

表示/アクション

ユーザー・フローのビューまたはアクションの数。

違反

検出されたコンテンツ通知、クライアント中断、悪いWebサービス・コールと、Webサイト、ネットワーク、サーバー、コンテンツのエラーの合計数。

Webサイト・エラー

ネットワークWebサイト・エラーが発生したサービス関数コールまたはページ・ビューの数。

レポートされる平均値の計算

表E-1および表E-2に示すデータ・アイテムのうち、「per」という語が含まれるアイテムは、対応する合計値を「per」の後にあるアイテムで割って計算します。たとえば、1ページ当たりのダウンロード時間は、すべてのページのダウンロード時間を合計ページ数で割って算出されます。

E.3 ディメンション

RUEIでレポートされるディメンションを表E-3に示します。

表E-3 ディメンション

ディメンション

説明

5分

5分(および時)。

アクション

アクションの名前。

アプリケーション

アプリケーションの名前。

アプリケーション

スイートの名前。

BTMサービス

BTMサービス名。

BTMサービス操作

BTMサービス操作。

クライアント・ブラウザ

クライアント・ブラウザの名前。

クライアント・ブラウザ・バージョン

クライアント・ブラウザの名前とバージョン。

クライアントの市区町村

クライアントの市区町村(プロバイダのDNSレコードに指定された市区町村に基づきます)。(MaxMindディレクトリから導出されます)。

クライアントの国

クライアントの国(プロバイダのDNSレコードに指定された国に基づきます)。(MaxMindディレクトリから導出されます)。

クライアント・デバイス

デバイス・クラス名。

クライアント・デバイス・ブランド

デバイスのブランド名。

クライアント・デバイス・モデル

デバイスのブランド名とモデル。

クライアントID

サービス・クライアントのID。

クライアントIDグループ

クライアントIDのグループ名(「(値なし)」または「ユーザー」)。

クライアントIP

クライアントのIPアドレス。

クライアント言語

クライアントPCの言語。

クライアント・ネットワーク

クライアントのネットワーク名(登録されたIPアドレス範囲に基づきます)。12.4項「名前付きクライアント・グループの定義」を参照してください。

クライアントOS

Webサイトへのアクセスに使用された、クライアントのオペレーティング・システムのクラス名。

クライアントOSバージョン

Webサイトへのアクセスに使用された、クライアントのオペレーティング・システムの完全名。

クライアント・プロバイダ

クライアントのプロバイダの名前(プロバイダのDNSレコードに指定された国に基づきます)。

クライアントの地域

クライアントのリージョン(プロバイダのDNSレコードに指定された市区町村に基づきます)。

日

日(および月)。

ドメイン

リクエストされたURLのドメイン部分。

ECID

オブジェクトのECID。

機能

サービス関数名。

関数グループ

サービス関数グループ。

時刻

時(および日)。

月

月(および年)。

指定クライアント

クライアントのIPアドレスまたは範囲に割り当てられた名前。12.4項「名前付きクライアント・グループの定義」を参照してください。

指定クライアント・グループ

クライアントのIPアドレスまたは範囲に割り当てられたグループ名。12.4項「名前付きクライアント・グループの定義」を参照してください。

指定サーバー

Webサーバーの名前。12.3項「名前付きWebサーバー・グループの定義」を参照してください。

指定サーバー・グループ

Webサーバーのグループ名。12.3項「名前付きWebサーバー・グループの定義」を参照してください。

オブジェクト・クラス

オブジェクトの分類(たとえば、イメージやビデオなど)。

オブジェクト配信

オブジェクトの配信が成功したかどうかの指標。配信が失敗した場合のエラーのカテゴリ(Webサイト、ネットワークまたはサーバー)またはその他の理由。

オブジェクト配信の詳細

成功した配信、またはオブジェクトがエラーになったことを示すレスポンス・コードまたは理由。

オブジェクト拡張子

オブジェクトのファイル拡張子。

オブジェクトの完全なURL

オブジェクトの完全なURL。つまり、ドメイン、ディレクトリおよびパラメータ。

オブジェクト・タイプ

オブジェクト・タイプ(静的または動的)。

オブジェクトURL

オブジェクトの最初のディレクトリのURL。

オブジェクトURLの最上位ディレクトリ

ページ・グループ。

ページ

アプリケーションのページ名。

ページ配信

配信が成功しなかった場合。

ページ配信の詳細

成功した配信、またはページがエラーになったことを示すレスポンス・コードまたは理由。

ページの完全なURL

ページの完全なURL。つまり、ドメイン、ディレクトリおよびパラメータ。大/小文字が区別されます。

ページ・グループ

アプリケーションのページ・グループ。

ページURI

ドメインまたは引数を含むページURL。

ページURLの最上位ディレクトリ

ページ・グループ。

物理クライアントIP

クライアントの物理的なIPアドレスまたは範囲。

リファラ・ドメイン

リファラURLのドメイン。

リファラURL

完全なリファラURL。つまり、ドメイン、ディレクトリおよびパラメータ。

サーバーIP

WebサーバーのIDアドレス。

サービス

サービスの名前。

サービス・デリバリ

配信が成功しなかった場合のエラーのカテゴリ(Webサイト、ネットワーク、サーバーまたはコンテンツ)またはその他の理由。

サービス・デリバリの詳細

配信が成功しなかった場合のリターン・コードまたは関数が失敗した理由。

サービス関数

サービス関数名。

サービス関数グループ

サービス関数グループ。

トランザクション

トランザクションの名前。

トランザクション・グループ

トランザクションのグループ。

トランザクション・ステップ

トランザクションのステップ名。

ユーザー・フロー

ユーザー・フローの名前。

ユーザー・フロー・グループ

ユーザー・フローのカテゴリ。

ユーザー・フロー・ステップ

ユーザー・フロー内のステップ名。

ユーザー・グループ

エラーのあるセッションのユーザーIDのグループ名(「(値なし)」または「ユーザー」)。

ユーザーID

ユーザーのID (Webサイトにログオンしている場合)。

ユーザーID

エラーのあるセッションのユーザーのユーザーID (Webサイトにログオンしている場合)。

年

年。

E.4 データ収集

ビジターがオブジェクトをリクエストすると、RUEIではそのリクエストを確認し、リクエストされたオブジェクトをビジターに示すまでにWebサーバーで要する時間を測定します。この時点で、RUEIは、ページをリクエストしたユーザー(クライアントのIP)、リクエストされたオブジェクト、オブジェクトのリクエスト元のサーバー(サーバーのIP)を知ることができます。これを図E-1に示します。

図E-1 RUEIのデータ監視

RUEIでは、Webサーバーが応答し、リクエストされたオブジェクトをビジターに送信するときに、そのレスポンスを確認します。この時点で、RUEIでは、サーバーからのレスポンスがあるかどうか、そのレスポンスが適切かどうか、リクエストされたオブジェクトの生成にWebサーバーが要した時間、およびオブジェクトのサイズを把握できます。

また、RUEIでは、ビジターがオブジェクトを完全に受信したかどうか、またはビジターがダウンロードを中断したかどうか(つまり配信証明)も把握できます。したがって、RUEIはオブジェクトがインターネットを経由してビジターに到達するまでの時間を計算できるとともに、ビジターとサーバー間のインターネット・スループット(ビジターの接続速度)を計算できます。

E.4.1 動的コンテンツと静的コンテンツ

サーバーからリクエストされるオブジェクトは動的または静的のいずれかです。動的オブジェクトはサーバーによってその場で生成されます。また、php、php3、php4、asp、aspxなどのファイル拡張子によって識別されます。静的オブジェクトはあらかじめダウンロード可能な状態になっており、それ以上のサーバー・アクションを必要としません。静的オブジェクトは通常、グラフィック、ビデオまたはドキュメント・ファイルです。一般的に、動的に生成されたオブジェクトでは、静的オブジェクトよりもサーバーに大きな負荷がかかります。表E-4に、静的オブジェクトとして記録されているオブジェクトのファイル拡張子を示します。

表E-4 静的オブジェクトのファイル拡張子

拡張子

拡張子

拡張子

.7z

.aac

.aaf

.ace

.ani

.arc

.arj

.atom

.au

.avi

.bmp

.bz2

.cab

.class

.css

.cur

.dat

.deb

.divx

.docx

.dot

.dotx

.dtd

.flv

.gif

.gz

.htm

.html

.ico

.iso

.jar

.java

.jpeg

.jpg

.js

.lzh

.m4a

.m4p

.mid

.mpe

.mpeg

.mpg

.mov

.mp4

.ogg

.par

.par2

.pdf

.ppt

.properties

.ra

.rar

.rm

.rss

.rtf

.svg

.swa

.swf

.tar

.tar

.tiff

.tgz

.ttf

.txt

.wav

.wma

.wma

.xhtm

.xhtml

.xls

.xml

.xsl

.xslt

.z

.zip

表E-2は、GETまたはPOSTで使用されるオブジェクトにのみ適用されることに注意してください。それ以外の場合は、動的オブジェクトとしてレポートされます。

表E-5に、動的オブジェクトとして明示的に記録されているオブジェクトのファイル拡張子を示します。表E-4に含まれていないオブジェクトのファイル拡張子もすべて動的として記録できます。

表E-5 動的オブジェクトのファイル拡張子

拡張子

拡張子

拡張子

.asp

.aspx

.cfm

.cgi

.jsp

.php

.php3

.php4

.php5

.phtml

.pl

E.4.2 ページとヒットの関連付け

ページとヒットの関係付けは時間ベースで行われ、その時間差が15秒を超えることはありません。ヒット間隔が15秒を超えると、そのヒットはそれに関連付けられたページには属さなくなったとみなされるようになります。また、リダイレクトが認識された場合、そのデータは次のページ・ビューに関係付けられます。

完了までの時間が5分を超えるダウンロード(PDFや大容量のグラフィック・ファイルなど)はRUEIによって廃棄され、レポートされません。これは、ダウンロードが成功したかどうかとは無関係に行われます。

E.4.3 エンドツーエンド時間、サーバー時間およびネットワーク時間

リクエストされたオブジェクトがクライアント側に到達するまでの時間をエンドツーエンド(e2e)時間と呼びます。この時間は次の2つの部分で構成されます。

- サーバー時間: サーバーがレスポンスを生成するためにかかる時間。

- ネットワーク時間: レスポンスがサーバーからクライアントに到達するまでにかかる時間。

E.4.4 ページ・ロード時間とエンドツーエンド時間

ページ・ロード時間とエンドツーエンド時間の正確な定義を理解することが重要です。これらは密接に関係しており、サーバーとクライアント・ブラウザのやりとりの方法によって影響を受けるためです。図E-2に、3つのヒットを含むページ・ビューを示します。

図E-2 1つのページ・ヒットと2つのオブジェクト・ヒットを含むページ・ビュー

各ヒットには次の3つの矢印が対応しています。

- クライアント・ブラウザからサーバーへのリクエスト。

- サーバーからクライアント・ブラウザへの応答。

- クライアント・ブラウザからサーバーへの確認。

サーバー時間は、リクエストの受信から、サーバーがリクエストへの応答を開始する瞬間までの時間に基づきます。ネットワーク時間は、クライアントへの応答の送信から、クライアント・ブラウザによる応答の確認までの時間に基づきます。RUEIによってレポートされるエンドツーエンド時間は、ネットワーク時間とサーバー時間の合計です。

ページ・ロード時間は、ページ・リクエストの開始から最後のオブジェクトの確認までの時間として計算されます。図E-2でページ・ビューのネットワーク時間とサーバー時間を確認すると、すべてのヒットのネットワーク時間とサーバー時間の合計は、ページのロード時間よりも長いように見えます。これは、最後の2つのヒット(緑と青)が並行して処理されるためです。ネットワーク時間とサーバー時間の計算では、これらは個別に時間計測される2つのヒットとして処理されます。

E.4.5 ブラウザ・ロード時間とページ読取り時間

リクエストしたページの各オブジェクトがクライアント・ブラウザに受信されたとき、ブラウザによるオブジェクトの処理とロード開始までに遅延が発生する場合があります。これをブラウザ・ロード時間と呼びます。すべてのオブジェクトのロードが完了すると、ページがクライアント・ブラウザに表示されます。この瞬間から次のページ・リクエストまでの時間をページ読取り(アイドル)時間と呼びます。これはクライアント・ユーザーがリクエストしたページを確認する時間であり、最大で2分に設定されています。

E.4.6 レポートされるページ・ビュー

特定の項目または時間に対してレポートされるページ・ビュー数は、使用するデータ・ブラウザ・グループによって異なる場合があります。データ・ブラウザで参照可能な情報の構造については、3.2項「データ構造の概要」を参照してください。具体的には、「すべてのセッション」グループと「すべてのページ」グループでは計算方法が少し異なります。これを表E-6に示します。

表E-6 「すべてのページ」グループと「すべてのセッション」グループのページ・ビューのレポート方法

時間

アクセスしたページ

レポートされるページ・ビュー数

ビジター1

ビジター2

すべてのページ

すべてのセッション

00:00

A、B

A、B、C

5

(ビジター1: A、B、A)

ビジター2: B、C)

0

00:15

C、D

A

3

(ビジター1: C、D)

(ビジター2: A)

0

00:30

E

B

2

(ビジター: 1E)

(ビジター2: B)

0

00:45

F

C

2

(ビジター: F)

(ビジター: C)

0

01:00

-

D

1

(ビジター2: D)

6

(ビジター1: A、B、C、D、E、F)

01:15

D

-

1

(ビジター1: D)

7

(ビジター2: A、B、C、A、B、C、D)

01:30

F

A

2

(ビジター1: F)

(ビジター2: A)

0

01:45

-

-

-

3

(ビジター1: D、F)

(ビジター2: A)

8

8

16

16

表E-6には、2人のユーザーがアクセスしたページの履歴が示されています。2人のビジターは監視対象のWebサイトを参照したため、アクセスしたページ数は「すべてのページ」グループにただちに記録されます。たとえば、00:00から00:15の間に、これらのユーザーは5ページ分のページにアクセスしました。ただし、セッションは依然としてアクティブであったため、これらのページは「すべてのセッション」グループにまだ記録されていません。この状態は01:00から01:15まで続き、そのセッションでアクセスされた他のページにおいても同様です。

2人のビジターのセッションの進行とともに、累計されたアクセス・ページ数が保存されていきます。「すべてのセッション」グループでは、各セッションが終了したとみなされるまで待機するため、関連するページ履歴は「すべてのページ」グループよりも後の時間間隔で記録されます。ただし、表E-6の下部の合計で確認できるように、2つのセッションが終了した後は、各グループでレポートされる合計ページ・アクセス数は同じになります。

通常、「すべてのページ」グループは機能分析(パフォーマンス監視など)に使用され、「すべてのセッション」グループはユーザーに影響を与える問題の特定に使用されます。

最後に、セッションのページ・ビューは、12:00PMの30分以上前までに到達した場合に当日扱いとして記録されることに注意してください。それ以降のページ・ビューは翌日の新しいセッションに属するものとして処理されます。したがって、リアルタイム・データ(ダッシュボードなど)のグループとセッションベースのグループとでは、レポートされるページ・ビューにわずかな違いが生じる場合があります。

E.4.7 ディメンション・レベルの値

すべてのディメンション・レベルの値は255文字に制限されます。これより長い値は自動的に切り捨てられます。切り捨てられたデータは、省略記号(…)で終了していることで示されます。この制限は、オブジェクト・レベルのセッション診断内、またはポストされたフォーム・コンテンツには適用されません。

E.4.8 ネットワーク・トラフィックの圧縮

RUEIでは、圧縮されたネットワーク・トラフィックを監視できます。現在、DEFLATE(zlib)とgzip圧縮アルゴリズムがサポートされています。ユーザーが受信したエラー・メッセージに関する情報は、セッション診断の再生機能(第4章「セッション診断機能の使用」を参照)にそのまま書き込まれ、表示のリクエストがあるまで解凍されません。この情報を正しく表示できるかどうかは、使用するブラウザの性能によって異なります。Internet ExplorerやMozilla Firefoxではこの機能が完全にサポートされていますが、(この機能がサポートされていない)他のブラウザを使用すると、問題が生じる場合があります。

E.5 データの集計

集計はRUEIのデータベース使用サイズを制御するうえで重要なデータ管理メカニズムです。集計では無関係な詳細や重複する詳細がデータベース表から取り除かれます。たとえば、1か月の期間において1日当たりのビジター数を確認するとき、個々のユーザーIDの追跡は関係ありません。この情報を削除して、役立つカウンタを追加することで、レポートできる情報量を簡単に増やすことができます。表E-8に示すデータベース表について考えてみます。

表E-7 ページ・ビュー

Page.Group

Page.Name

User.Group

User.Name

ページ・ビュー

ヒット

Homepage

Homepage

Users

Jan

4

44

Product

Product » Details

Users

Jan

5

50

Homepage

Homepage

"(値なし)"

"(値なし)"

1

8

About-Us

About-Us » Contact

"(値なし)"

"(値なし)"

10

30

About-Us

About-Us » FAQs

"(値なし)"

"(値なし)"

2

13

Page.Nameレベルを削除すると、表E-9に示す表が作成されます。行数が5から4に減ることに注意してください。

表E-8 ページ・ビュー

Page.Group

User.Group

User.Name

ページ・ビュー

ヒット

Homepage

Users

Jan

4

44

Product

Users

Jan

5

50

Homepage

"(値なし)"

"(値なし)"

1

8

About-Us

"(値なし)"

"(値なし)"

2

43

ただし、かわりにUser.Nameレベルを削除すると、表E-9に示す表が作成されます。この場合、行数は減らないことに注意してください。

表E-9 ページ・ビュー

Page.Group

Page.Name

User.Group

ページ・ビュー

ヒット

Homepage

Homepage

Users

4

44

Product

Product » Details

Users

5

50

Homepage

Homepage

"(値なし)"

1

8

About-Us

About-Us » Contact

"(値なし)"

10

30

About-Us

About-Us » FAQs

"(値なし)"

2

13

F XPath問合せの使用

この付録では、RUEI内で用意されている、XPath問合せを使用するためのサポートについて詳しく説明します。これらはコンテンツ・メッセージ、クライアント識別、カスタム・ディメンション、およびページ識別とサービス識別の定義の一部として使用できます。

F.1 概要

XPath(XML Path言語)は、XML文書からノードを選択したり、値を計算するのに使用できる問合せ言語です。RUEIにおけるXPathバージョン1.0のサポートはlibxml2に基づきます。詳細は次のサイトを参照してください。

http://xmlsoft.org/

XPath言語の仕様の詳細は、次のサイトを参照してください。

http://www.w3.org/TR/xpath

RUEIは、XML、HTMLまたはJSONコンテンツでXPathをサポートしています。JSONコンテンツは、XPath問合せが適用される前に、内部でXMLに変換されます。

重要:

RUEIでは、すべてのトラフィックのコンテンツに対して、実際にそれがXML形式であるかどうかにかかわらず、XPath一致が適用されます。このため、正確な結果を取得するには、すべてのXPath式が整形式XHTMLコードに対して実行されるようにし、F.5項「XPathスキャンの最適化」の情報を確認することを強くお薦めします。また、XPath式では大/小文字が区別されることに注意してください。

F.2 名前空間のサポート

XML名前空間を使用すると、XML文書内の要素および属性に一意の名前を付けることができます。XMLインスタンスには、複数のXMLボキャブラリからの要素名または属性名が含まれている場合があります。各ボキャブラリに名前空間が割り当てられている場合は、同じ名前の要素間または属性間のあいまいさを解決できます。

RUEIでは、XPath問合せで使用するすべての名前空間が明示的に定義されている必要があります。名前空間を問合せで使用する場合は、定義されていないと機能しません。名前空間を定義する手順は、次のとおりです。

1. 「構成」→「一般」→「詳細設定」→「XPathネームスペース」の順に選択します。図F-1に示すウィンドウが表示されます。

図F-1 「XPathネームスペース」の例

このウィンドウは、XPathベースのコンテンツ・メッセージ、カスタム・ディメンション、ユーザー識別、およびページ識別とサービス識別の定義を指定するときに、「ネームスペース」タブをクリックしても表示できます。

2. 「新規追加」をクリックして新しい名前空間を定義するか、または既存の定義をクリックして変更します。図F-2に示すダイアログが表示されます。

図F-2 「XPathネームスペースの追加」ダイアログ

3. 監視対象のXML文書内で使用する名前空間接頭辞および対応する基本URLを指定します。名前を一意にする必要があります。名前空間と接頭辞の使用方法に関する重要な情報は、F.3項「名前空間の接頭辞およびURLの概要」を参照してください。名前空間の定義はグローバルで、すべての監視対象トラフィックに適用されます。
次に、「保存」をクリックします。新しい定義または既存の定義の変更は、5分以内に有効になります。

注意:
定義済のネームスペースを削除する場合、トラフィックの監視で必要ないことを確認することをお薦めします。

F.3 名前空間の接頭辞およびURLの概要

名前空間は接頭辞(ローカル・バインディングの形式とみなすことができる)とURLで構成されます。これは、実際の名前空間を定義する文書の場所を示します。たとえば、my_ns1=http://www.w3.org/1999/xhtmlのようになります。

名前空間はそのURL(または該当する場所にある文書のコンテンツ)によって定義されることを理解しておく必要があります。接頭辞は単に、XMLノードおよび要素内で名前空間URLへの参照を示します。このため、同じ名前空間を複数の接頭辞にバインドしたり、これらの接頭辞を文書内に混在させることができます。その結果、すべての接頭辞が同じURLを指すことにより、すべての要素が同じ名前空間に配置される可能性があります。

別の文書の異なる名前空間に同じ接頭辞がバインドされる場合があります。さらに、XMLでは、同一文書内で異なる複数のURLに同じ接頭辞をバインドできます。

異なる複数の名前空間、同一の接頭辞

次の例を考えてみます。

<parent xmlns:ns1="foo">
<child xmlns:ns2="bar">
<ns2:some_element>
</child>
<child xmlns:ns2="baz">
<ns2:some_element>
</child>
</parent>

ここでは、2つの子ノードが2つの異なる名前空間(barとbaz)を使用していますが、ローカルでのバインドには同じ接頭辞を使用してしています。このため、<some_element>ノードは、2つの子ノードにおいてそれぞれ異なる意味を持ちます。

2番目の<some_element>ノードを選択することを考えてみます。XPath式//ns2:some_elementの使用を考慮します。ただし、RUEIでns2接頭辞が最初の定義(bar)または2番目(baz)を参照するかどうかを判別できないため、これは機能しません。

ここで、これらのノードを両方とも一致させる場合について考えてみます。可能性としては、名前空間の定義をまったく無視して、ワイルドカード式を使用する方法が考えられます。次に例を示します。

//*[local-name()='some_element']

ただし、この式では、関係ない名前空間にバインドされたものまで含むすべての<some_element>ノードが検出されます。実際の接頭辞名は意味を持たないことを理解しておく必要があります。接頭辞は定義されている文書の一部に対してローカルであるため、対象の場所で有効な名前空間に接頭辞がバインドされている限り、XPath式でどの接頭辞を使用するかは問題になりません。このため、次のXPath式は、

//ns2:some_element

(ns2はbazを指す)2番目の<some_element>ノードに一致します。ただし、XPath式に指定された実際の接頭辞は文書で使用されている接頭辞と一致する必要がないので、次のXPath式も使用できます。

//boo:some_element

booはbarを指します。この場合、XPath式では、名前空間bazにローカルでバインドされているノードを検出し、booを使用してXPath式内の該当する名前空間を参照します。RUEIでは、この式がロードされると、booが指している名前空間(この場合はbaz)を参照し、名前空間baz内で<some_element>という名前のノードを検出する必要があることを記録します。その時点で、接頭辞はもう必要ありません。RUEIでは、文書のスキャン時に<some_element>要素を検出するたびに、ローカルで定義された接頭辞を介して現在の名前空間を取得して、XPath式に定義された名前空間と比較します。両方ともbazであれば、一致が検出されます。

前述の内容を踏まえ、次のXPath式を使用して両方のノードが抽出されるようにRUEIを構成できます。

//boo:some_element where boo=bar//hoo:some_element where hoo=baz

その他の例

次のXML文書について考えてみます。

<parent xmlns:ns2="foo">
<child xmlns:ns2="bar">
<ns2:some_element>
</child>
</parent>

この例では、親ノードと子ノードが異なる名前空間を使用していますが、両方とも同じ接頭辞(ns2)にバインドされています。名前空間の定義はローカルであるため、これは有効です。<some_element>ノードの内容を検出するには、次のXPath式を使用できます。

/p_parent:parent/p_child:child/p_child:some_element

p_parentはfooで、p_childはbar(または、任意のローカル接頭辞文字列)です。

F.4 サード・パーティのXPathツールの使用方法

利便性向上のため、Mozilla FirefoxのXPather拡張など、サード・パーティのXPathツールを使用して、RUEI内で使用可能なXPath式を作成できるようになっています。このXPather拡張は、次のサイトから入手可能です。

http://xpath.alephzarro.com/index

インストールすると、ページ内で右クリックしてXpatherで表示オプションを選択できるようになります。例を図F-3に示します。

図F-3 XPatherツール

次に、XPatherブラウザ(図F-4を参照)内でXPath式をコピーすれば、RUEIでのXPath問合せのベースとして使用できます。必ず、生成されたXPath式を確認して、前述の制限事項に準拠していることを確認してください。

図F-4 XPatherブラウザ

注意:
ページ内の基礎となるXHTMLコードが整形式でない場合、XPatherによって生成されたXPath式はRUEI内で正常に機能しない場合があります。

F.5 XPathスキャンの最適化

この項では、XMLスキャンの最適化方法およびコレクタ・システムの過剰なメモリーおよびCPU使用率が生じる可能性がある多数のドキュメントの不要なスキャンを防ぐ方法について説明します。

定義済のXPath定義に対してスキャンするドキュメントは、次の方法で決定されます。

- ドキュメントが強制オブジェクトの場合、スキャンされません。強制オブジェクトとみなされるファイル拡張子および構成方法の詳細は、12.16項「ページとしてのオブジェクトのレポートの制御」を参照してください。

- それ以外の場合は、ドキュメントのContent-TypeヘッダーでHTMLまたはXMLを指定すると、HTMLまたはXMLファイルとしてスキャンされます。

- ドキュメントのContent-Typeがhtmlまたはxml以外の場合またはドキュメントにContent-Typeヘッダーが含まれない場合、メッセージ・コンテンツの開始が事前定義済のコンテンツ文字列と比較され、一致するとドキュメントがHTMLまたはXMLコンテンツに対してスキャンされます。

- 最後に、事前定義済のコンテンツ文字列が一致せず、デフォルトのコンテンツ・タイプ(HTMLまたはXML)が構成されている場合、指定されたデフォルト・タイプでもドキュメントがスキャンされます。

XML/HTMLコンテンツ文字列

Content-Typeヘッダーがドキュメントに見つからない場合またはHTMLまたはXML以外が指定されている場合、メッセージ・コンテンツの開始が事前定義済の文字列と比較され、一致するとHTMLまたはXMLドキュメントでもスキャンされます。デフォルトのコンテンツ文字列を表F-1に示します。

表F-1 デフォルトのXML/HTML/JSONコンテンツ文字列

XML

HTML

<?xml

<html

<head

<!DOCTYPE

XMLコンテンツ文字列は大/小文字が区別され、HTML文字列は区別されません。

コレクタ・システムでRUEI_USERユーザーとして次のコマンドを発行して、追加のコンテンツ文字列を定義できます。

execsql config_set_prj_value xpath-options type add "content-string"

構造の各要素の意味は、次のとおりです。

- typeでは、ドキュメントをHTML(html-magic)またはXML(xml-magic)としてスキャンするかどうかを指定します。

- content-stringでは、ドキュメントの開始を比較する文字列を指定します。

次に例を示します。

execsql config_set_prj_value xpath-options xml-magic add "<soap:"

デフォルトのコンテンツ・タイプ

定義されたコンテンツ文字列が一致しない場合、スキャンするためにデフォルトのコンテンツ・タイプをこれらのドキュメントに割り当てることができます。それには、コレクタ・システムでRUEI_USERユーザーとして次のコマンドを発行します。

execsql config_set_prj_value xpath-options default-content-type replace "type"

typeはxmlまたはhtmlです。

F.6 JSONコンテンツでのXPath

JSON文書は内部でXML構造に変換されます。この場合、JSON文書の各値はXMLタグに変換されます。オブジェクトの値は文字列キーを持ち、XMLタグはオブジェクトの文字列キーにちなんで名前を付けられます。配列の値はXMLキーを取得し、順序番号が1つ増えます。JSON文書のルート値は、名前jsonを持ったXMLタグに変換されます。

たとえば、JSON文書は次のコンテンツを持つことができます。

{"name":"juices","value":["apple","orange","carrot"]}

これは次のXML文書に変換されます。

<?xml version="1.0" encoding="UTF-8"?>
<json>
<name>juices</name>
<value>
<0>apple</0>
<1>orange</1>
<2>carrot</2>
</value>
</json>

次の例は、前述のJSON文書に基づいたXPath問合せおよび結果を示しています。

/json/name  => juices
count(/json/value/*)   =>   3
/json/value/1   => orange

F.7 xpathtesterユーティリティを使用したXPath式のテスト

RUEIには、XPath式を簡単にテストするための方法としてxpathtesterユーティリティが組み込まれています。基本的な使用方法の構文を次に示します。

xpathtester filename xpath-expr

filenameは使用するXML HTMLファイルの名前であり、xpath-exprはテストするXPath式です。次に例を示します。

xpathtester boe.html //body

-->> Input file is "boe.html"
-->> Parsing document in XML mode...done, parse time: 0000.000164
-->> Evaluating expression: "//body"
-->> Eval time: 0000.000037
-->> Found the following object(s)
Node 0 (0x12b4c00), type element:
name: body (ns="")
value: "
Hoi
"
where: line=5-7, file offset=46-59
match: "
Hoi
"

高度な使用方法の構文を次に示します。

xpathtester [options] filename xpath-expr1 [xpath-expr2 xpath-expr3 ..]

optionsについては表F-2で説明します。

表F-2 xpathtesterユーティリティのオプション

オプション

説明

-H

XMLパーサーではなくHTMLパーサーを使用するHTMLモード。このパーサーはXMLパーサーよりも許容度が高く、HTMLファイルに対して使用する必要があります。

-c namespace_file

指定したファイルからネームスペースをロードします。ファイルの各行で次の形式を使用する必要があります。

namespace1=http:/the/namespace/url

次に例を示します。

soap12=http://www.w3.org/2003/05/soap-envelope

-d dump_file

指定したファイルに(書式設定された) XMLコンテンツをダンプします。これは、ドキュメントを単一の行として送信するsoapサービスで役立ちます。

-e encoding

指定したコーディングをHTMLモードで使用します。パーサーによって自動的に決定できないエンコーディングがドキュメントで使用されている場合、この引数を使用するようにエンコーディングを設定できます。ここでは標準のIANAネーミング(UTF-8やISO-LATIN-2など)を使用します。

-h

xpathtesterユーティリティのヘルプを表示します。

-m

XPath式によって一致した選択内容をマスクします。これは、XPathマスキングによりドキュメントのどの部分がマスキングされるかを確認するために役立ちます。

-v[vvv]

冗長性レベルを設定します(vを指定すると冗長性が最も低くなり、vvvvを指定すると冗長性が最も高くなります)。

G 各国語サポートの使用

この付録では、ネットワーク・トラフィックを監視する際にRUEIによりサポートされるキャラクタ・エンコーディング標準について詳しく説明します。ドメイン名、カスタム・ヘッダーおよび関数エラーなどの識別に対する制限を取り上げます。各国語のキャラクタ・セットを使用するときのデータのマスキングやユーザーIDのマッチングの操作についても説明します。

G.1 概要

コレクタでは、様々なエンコーディング標準のデータを含むネットワーク・トラフィックを監視できます。RUEIで現在サポートされているすべてのエンコーディング標準を表G-1に示します。

表G-1 サポートされているエンコーディング

標準名

MIME名脚注1

説明

Big5

Big5

繁体字中国語。

EUC-JP

EUC-JP

EUCエンコーディングの日本語。

GB_2312-80

GB_2312-80、gb2312、chinese

中国語。

GBK

GBK、CP936、MS936、windows-936

簡体字中国語。

ISO-8859-1

ISO-8859-1、ISO_8859-1、latin1

ラテン・アルファベットNo.1。

ISO-8859-10

ISO-8859-10、latin6

ラテン・アルファベットNo.6(スカンジナビア)。

ISO-8859-13

ISO-8859-13

ラテン・アルファベットNo.7(バルト海沿岸諸国)。

ISO-8859-14

ISO-8859-14、latin8

ラテン・アルファベットNo.8(ケルト)。

ISO-8859-15

ISO-8859-15、latin9

ラテン・アルファベットNo.9。

ISO-8859-16

ISO-8859-16、latin10

ラテン・アルファベットNo.10(東南ヨーロッパ)。

ISO-8859-2

ISO-8859-2、ISO_8859-2、latin2

ラテン・アルファベットNo.2(中央および東ヨーロッパ)。

ISO-8859-3

ISO-8859-3、latin3

ラテン・アルファベットNo.3(南ヨーロッパ)。

ISO-8859-4

ISO-8859-4、latin4

ラテン・アルファベットNo.4(北欧)。

ISO-8859-5

ISO-8859-5、cyrillic

キリル語。

ISO-8859-6

ISO-8859-6、arabic

アラビア語。

ISO-8859-7

ISO-8859-7、greek

ギリシャ語。

ISO-8859-8

ISO-8859-8、hebrew

ヘブライ語。

ISO-8859-9

ISO-8859-9、latin5

ラテン・アルファベットNo.5(トルコ語)。

KOI8-R

KOI8-R

ロシア語。

Shift_JIS

Shift_JIS、shift-JIS

日本語。

US-ASCII

US-ASCII、ascii

米国の情報交換標準コード(ASCII)。

UTF-32

UTF-32

32ビットUCS変換形式。UCS-4とも呼ばれます。

UTF-16

UTF-16

16ビットUCS変換形式。バイト・オーダーはオプションのバイト・オーダー・マークで指定されます。

UTF-16BE

UTF16BE

16ビットUnicode変換形式。ビッグエンディアンのバイト・オーダー。

UTF-16LE

UTF16LE

16ビットUnicode変換形式。リトルエンディアンのバイト・オーダー。

UTF-32BE

UTF32BE

32ビットUnicode変換形式。ビッグエンディアンのバイト・オーダー。

UTF-32LE

UTF32LE

32ビットUnicode変換形式。リトルエンディアンのバイト・オーダー。

UTF-8

UTF-8

8ビットUCS変換形式。

windows-1250

windows-1250

Microsoft Windows東ヨーロッパ。

windows-1251

windows-1251

Microsoft Windowsキリル語(ロシア語)。

windows-1252

windows-1252

Microsoft Windowsラテン語。

windows-1253

windows-1253

Microsoft Windowsギリシャ語。

windows-1254

windows-1254

Microsoft Windowsトルコ語。

windows-1255

windows-1255

Microsoft Windowsヘブライ語。

windows-1256

windows-1256

Microsoft Windowsアラビア語。

windows-1257

windows-1257

Microsoft Windowsバルト言語。

windows-1258

windows-1258

Microsoft Windowsベトナム語。

脚注1 HTTPエンコーディング宣言によって認識されている名前(およびサポートされている別名)。

ベンダー固有のWebサイト・エンコーディングはサポートされない場合があります。サポートされていないエンコーディングを含むネットワーク・トラフィックは、記録はされますが、マッチングできない場合があります。たとえば、ページのコンテンツはReplay Viewerで表示できますが、定義されたページ名をそのコンテンツに正しく関連付けることができない場合があります。

Webサイト構成

各国のテキストを使用するWebサイトを正しく監視するには、Webサイトを適切に構成しておく必要があります。たとえば、WebサーバーがUTF-8を通知しているが実際のページがUTF-8でエンコードされていない場合、一部のWebブラウザではサポートされていないコンテンツを自動検出して修正できたとしても、RUEIではそのページを正しく監視できません。したがって、関数エラー・チェックやコンテンツ・チェックなどはこれらのページでは正しく動作しません。

G.2 実装に関する考慮事項

データ・マスキング

コレクタは機密情報をログに記録しないように構成できます。この詳細は、13.6項「ユーザー情報のマスキング」に記載されています。サポートされるのはASCIIの引数名のみです。引数の内容に使用されるエンコーディングは何でもかまいません。どのエンコーディングも置き換えられます。

ドル($)文字を含む特定の変数名には注意する必要があります。たとえば、監視対象トラフィックに含まれるfoo$barは、foo%24barとして転送される場合があります(ブラウザによって異なります)。この場合、この変数を正しくマスキングするには、パーセントをエンコードした変数名を指定する必要があります。

マスキングする変数はASCII形式で指定する必要があります。また、セッション診断でレポートされたとおりに正確に指定する必要があります。たとえば、変数名user nameは、セッション診断ではuser%20nameとしてレポートされますが、user+nameとして表示される場合もあります。したがって、マスキングの対象としてはこれら両方の変数名を指定する必要があります。

引数名に非ASCII文字が含まれる場合、セッション診断(第4章「セッション診断機能の使用」を参照)を使用してその文字がどのようにレポートされるかを確認し、そのレポートされた名前を、マスキング対象の変数として指定する必要があります。また、ログ・ファイルを定期的にチェックして、データが正しくマスキングされていることを確認する必要があります。

前述のURL引数のマスキングに関する制限事項と要件は、URL引数への直接アクセスが必要なあらゆる状況にもあてはまります。たとえば、カスタム・ディメンションやアプリケーション定義などです。

注意:
HTMLフォームのフィールド名(値ではない)を正しくマスキングするためには、ASCII形式であることが必要です。

カスタム・ヘッダーとCookie

ヘッダー名はHTTPプロトコルで必要とされるため、すべてのヘッダー名はASCIIでエンコードする必要があります。ヘッダーの内容に含まれるすべての非ASCII文字は、プレースホルダに置き換えられます。

ユーザーIDのマッチング

RUEIでは、ユーザー識別は最初にHTTP認可フィールドから取得されます。ユーザー識別が見つからない場合は、アプリケーションのユーザー識別スキームが使用されます。ユーザー識別スキームでは、URL、Cookie、リクエスト・ヘッダーまたはレスポンス・ヘッダーあるいはXPath式によってユーザーを指定できます。この詳細は、8.3.14項「ユーザー識別の定義」に記載されています。

name=valueのペアで1つのURL引数となるため、nameの部分をユーザーIDの読取り元となるソース引数として指定します。valueの部分は抽出され、ユーザーIDとしてレポートされます。指定するソース引数には、データのマスキングですでに説明した要件が必要となります。ただし、ペアになるvalue部分は、サポートされている任意のエンコーディングで指定できます。RUEIは、valueを本来のエンコーディング(Shift-JISなど)からUTF-8に変換して、ユーザー・インタフェース内で本来の言語(日本語など)でレンダリングできるようにします。

ただし、valueの本来のエンコーディングが不明な場合は、ユーザーIDがユーザー・インタフェース内で正しくレンダリングできず、レポートされる値が文字化けします。HTTPプロトコルの制限のため、一部のWebサイトでは、ユーザーIDが要求どおりにレンダリングされない場合があります。この場合、コレクタ・エンコーディングを指定して使用することをお薦めします。この詳細は、G.4項「URL引数およびコレクタ・エンコーディングの指定」に記載されています。この設定に指定したエンコーディングは、URLおよびPOST引数のみに適用されます。コンテンツベースのレポート(関数エラーなど)はこの設定による影響を受けません。これは、すべての値が正しくレンダリングされることを保証するものではありません。したがって、Webサイトの定義を確認したり、すべてのユーザーIDがASCIIのみであることを確認する必要があります。

G.3 コンテンツ・チェックの指定

ページ・コンテンツ・チェックを指定する場合、クライアント・ブラウザ内でレンダリング(およびエンドユーザーに表示)されるコンテンツは、基となるHTMLページ・ソースとは異なる場合があります。これは、基となるフォント、書式設定、リンクの各タグ、およびエンティティ定義などに原因があります。したがって、クライアント・ブラウザ内でレンダリングされたページからテキストの一部を単にコピーして貼り付けるのみでは、必ずしも要求どおりに機能しない場合があります。

通常、この問題を解決するには、クライアント・ブラウザのソース表示機能でコピーと貼付けを行います。ただし、UTF-8以外のエンコーディングを使用するページの場合、ブラウザがInternet Explorer 6または7であると、この方法は機能しません。これは、IEでは、UTF-8のみをサポートするメモ帳がソース・ビューアとして使用されるためです。その結果、ソースが文字化けして表示される場合があり、RUEIにコピーおよび貼り付けることの意味がなくなります。

Mozilla Firefoxでは内部のHTMLソース・レンダリング・ツールが使用されるため、UTF-8以外のエンコーディングでもHTMLソースは常に正確にレンダリングされます。このため、このブラウザをコンテンツベース・チェックのベースとして使用することをお薦めします。また、HTMLソースの正確なレンダリングが必要な場合もこのブラウザを使用することをお薦めします。

G.4 URL引数およびコレクタ・エンコーディングの指定

RUEIが監視しているネットワーク・トラフィックに関して正確にレポートするには、そのトラフィック内で使用されているエンコーディングを認識している必要があります。RUEIでは、様々なキャラクタ・エンコーディング標準のデータを含むネットワーク・トラフィックを監視できます。RUEIでサポートされているすべてのエンコーディング標準は、表G-1を参照してください。

一般的に、RUEIは最初に、対応するHTMLドキュメントについて指定されているドキュメントのエンコーディングを使用しようとします。これは自動検出です。このエンコーディングで満足できる結果が得られなかった場合には、URL引数およびポストされたフォーム引数をデコードするために、コレクタ・エンコーディング(指定されている場合)が使用されます。

コレクタ・エンコーディングは、ドキュメント・エンコーディングを手動で上書きするものではありません。むしろ、ドキュメントのエンコーディングがURL引数を満足できる形でデコードできなかったときに、RUEIによって自動的に使用されるエンコーディングを指定するものです。コレクタ・エンコーディングでも満足できる結果が得られなかった場合、引数は元の(デコードされていない)形式でレポートされます。

URL引数およびコレクタ・エンコーディング

URL引数とコレクタ・エンコーディングを指定する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「コレクタ・エンコーディング」の順に選択します。図G-1に示すパネルが表示されます。

図G-1 コレクタ・エンコーディング

2. 目的のコレクタ・プロファイルに現在定義されているコレクタ・エンコーディングをクリックします。デフォルトでは、コレクタ・エンコーディングは定義されていません。図G-2に示すダイアログが表示されます。

図G-2 コレクタ・エンコーディングの編集ダイアログ

3. 「コレクタ・エンコーディング」メニューを使用して、自動検出が失敗したときに、選択したコレクタ・プロファイルのコレクタによってアプリケーション・フィルタのURL引数のために使用されるエンコーディングを指定します。使用可能なエンコーディングのリストは、表G-1に示すリストと等価です。
次に、「保存」をクリックします。この設定は、変更すると、ほぼ即座に有効になります。

重要:

この機能を使用する場合には、次の点に特に注意する必要があります。

- この設定が適用されるのは、アプリケーション定義内のURL引数のデコードのみです(8.3項「アプリケーションの定義」を参照)。コンテンツベースのレポート(関数エラーなど)はこの設定による影響を受けません。また、選択したコレクタ・エンコーディングは、選択したプロファイルのコレクタによって監視されているアプリケーション、ページ、ドメインのすべてに適用されます。

- Webサイト内で各国語のキャラクタ・セットを使用する場合には、Webサイトのコンテンツとそこで使用されているエンコーディングを注意して確認することをお薦めします。また、すべてのURL引数のレポートを定期的に調べて、それらの引数が正しいことを確認する必要があります。

H WebLogic Portal(WLP)のサポート

この付録では、WebLogic Portal (WLP)ベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

H.1 概要

RUEIでは、追加設定なしでWLPアプリケーションを監視することができます。自動的にWLP Webアプリケーションを検出して、ネットワーク・オブジェクトをビジネス機能に変換します。このサポートを使用すると、個々のユーザー・アクションが正しいWebアプリケーション、デスクトップ、ポータル、ブックおよびページと自動的に一致し、コンテキスト分析を得られます。

RUEIでは、ファイルベース・ポータルとストリーミング・ポータルの監視がサポートされます。ストリーミング・ポータルの場合は、ディスク・フレームワークを有効にする必要があります。ディスク・フレームワークが有効でない状態でファイルベース・ポータルを監視するには、監視対象ポータルの構成に関する追加の情報をアップロードする必要があります。この詳細は、H.3項「RUEIとWLP環境の同期化」に記載されています。ディスク・フレームワークを使用しないストリーミング・ポータルの監視はサポートされないことに注意してください。

この付録でこれから説明する監視のサポートは、WLPバージョン10.3に基づくアプリケーションについて検証されています。

H.2 WLPスイート定義の作成

WLPベースのアプリケーションのスイート定義を作成できます。作成方法は、サポートされている他のOracle Enterpriseアーキテクチャの場合と同じです。スイートを作成する手順は、10.1項「スイートの使用」に記載されています。

H.3 RUEIとWLP環境の同期化

監視対象スイート・インスタンスがファイルベース・ポータルで、ディスク・フレームワークが有効でない場合、ポータルが環境にどのように実装されているかをRUEIが認識する必要があります。次を実行します。

1. create_WLP_info.plスクリプトをRUEI_DATA/processor/local/downloadディレクトリから、スクリプトを実行する予定の場所にコピーします。監視対象アプリケーションで使用される.portalファイルを同じ場所にコピーします。

2. create_WLP_info.plスクリプトをレポータ・システムで実行します。このスクリプトによって、監視対象環境の実装に関する情報が生成されます。このスクリプトは次の必須パラメータを指定して実行してください。

perl create_WLP_info.pl -portal file.portal

fileは、監視対象アプリケーションで使用される.portalファイルの名前です。

複数インスタンス環境では、目的のインスタンスごとにスクリプトを実行し、作成される.txtファイルを別に保存します。10.1.1項「スイート定義の作成」で説明するように、各インスタンスに別のスイート定義を作成します。

3. 10.1.2項「構成ファイルのアップロード」で説明している手順を実行し、生成されたファイルをレポータ・システムにアップロードします。

H.4 Cookieテクノロジの指定

WLPスイート・インスタンスを作成すると、WLP環境用の事前定義済Cookieが自動的に作成されます。これは、JSESSIONIDという名前のカスタムCookieとして実装されます。WLPはWebLogicテクノロジに基づいているため、事前定義済CookieはWLPアプリケーションに適しています。ただし、環境の構成によってはこのCookieを変更する必要があります。また、RUEIによって、完了したセッションのユーザーを監視および追跡するには、Cookieのパスを「/」に設定する必要があります。Cookie構成の詳細は、12.2項「セッション・トラッキング・メカニズムの指定」を参照してください。

H.5 ユーザー認証の構成

RUEIでは、RESTフレームワークに基づくユーザー認証を利用するWLPアプリケーションを追加設定なしで監視することができます。ただし、監視対象ポータルで他のユーザー認証メカニズムが使用される場合には、構成する必要があります。この手順は、8.3.14項「ユーザー識別の定義」に記載されています。

H.6 スイート定義のマッピング

WLPアプリケーションはホスト名で識別できます。一般的に、WLPスイートにアクセスする方法は2つあります。ホスト名のみを使用する方法、または完全修飾ホスト名(ドメインを含む)を使用する方法です。通常はドメインのみを指定してください。

H.7 データ・アイテム

表H-1に示すWLP固有のデータ・アイテムがRUEIでレポートされます。

表H-1 WLP固有のデータ・アイテム

項目

説明

WLPアクション

アクションの名前。WebLogicアクションはページで実行され、ポートレットを伴うことがあります。後者の場合、第2レベルにポートレットが表示されます。

WLPブック

ポートレットがあるページを含むWebLogicブックの名前。

WLPデスクトップ

WebLogicデスクトップの名前。これをWebLogicポータル、WebLogic Webアプリケーションおよびスイートの名前(「構成」の「スイート」で定義)と組み合せると、RUEIでのアプリケーション名になります。

WLPページ

WebLogicページの名前。ポートレットはページに含まれます。ページそのものはWebLogicブックに含まれます。

WLPポータル

WebLogicポータルの名前。これをWebLogicデスクトップ、WebLogic Webアプリケーションおよびスイートの名前(「構成」の「スイート」で定義)と組み合せると、RUEIでのアプリケーション名になります。

WLPポートレット

WebLogicポートレットの名前。

WLP Webアプリケーション

WebLogic Webアプリケーションの名前。これをWebLogicポータル、WebLogicデスクトップおよびスイートの名前(「構成」の「スイート」で定義)と組み合せると、RUEIでのアプリケーション名になります。

H.8 既知の制限事項

現在、RUEIではWLPのすべての機能はサポートされません。特に次の制約事項がすでに判明しています。

- レポートは、最後にアクティブになった部分に基づいて行われます。したがって、1人のエンド・ユーザーが複数のブラウザ・ウィンドウで同時に参照しているとき、レポートされるページ名に間違った情報が含まれることがあります。

- ポートレット・レベルのレポートは非常に限られています。ストリーミング・ポータルの場合、アクションにポートレット(「move portlet on page」など)が含まれ、ポートレット定義ラベルがレスポンス・コンテンツまたはアクションのURLで検出されると、ポートレット定義ラベルがWLPグループでレポートされます。「すべてのページ」グループではポートレットはレポートされません。
ファイルベース・ポータルの場合、アクションにポートレットが含まれるときはインスタンス・ラベルがレポートされます。ファイルベース・ポータルにはポートレット定義ラベルがないためです。ファイルベースのポートレット・インスタンス・ラベルがレポートされるのは、ポータル構成ファイルがアップロードされる場合のみです(H.3項「RUEIとWLP環境の同期化」を参照)。

- ディスク・フレームワークが有効になっていないストリーミング・ポータルの監視はサポートされません。

- リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。

I Oracle ADFのサポート

この付録では、Oracle Application Development Framework (ADF)ベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

I.1 概要

RUEIでは、追加設定なしでOracle ADFアプリケーションを監視することができます。自動的にOracle ADFアプリケーションを検出して、ネットワーク・オブジェクトをビジネス機能に変換します。このサポートを使用すると、個々のユーザー・アクションが正しいWebアプリケーション、タスク・フローおよびビューと自動的に一致します。

ADFアプリケーションおよびFusionアプリケーションでは、ADF監視サービスを利用すると、ネットワーク収集から受信したデータを、ADF監視サービスから受信した追加のデータ(ユーザー名など)によって拡充できます。これには、ADF監視サービスのデプロイと構成が必要です(『Oracle Real User Experience Insightインストレーション・ガイド』を参照)。

この付録でこれから説明する監視のサポートは、Oracle ADFバージョン11gに基づくアプリケーションについて検証されています。

I.2 Oracle ADFスイート定義の作成

Oracle ADFベースのアプリケーションのスイート定義を作成できます。スイートを作成する手順の詳細は、10.1.1項「スイート定義の作成」に記載されています。

I.3 ADFアプリケーションの監視の有効化

adf-faces-databinding-rt.jarファイルによって、ExecutionContextProvider(oracle.adfinternal.view.faces. context.AdfExecutionContextProvider)クラスのDMSベースの実装が提供されます。実装クラスは.jarファイルで事前に定義されていますが、機能が有効になるのは、次のアプリケーション・コンテキスト・パラメータをweb.xmlファイルに指定したときです。

<context-param>
<description>This parameter notifies ADF Faces that the ExecutionContextProvider
service provider is enabled. When enabled, this will start
monitoring and aggregating user activity information for the client
initiated requests. By default, this param is not set or is false.
</description>  <param-name>oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER</param-name>
<param-value>true</param-value>
</context-param>

I.4 Cookieテクノロジの指定

Oracle ADFはJavaテクノロジに基づいているため、Oracle ADFアプリケーションは多くの場合JSESSIONID状態Cookieを使用します。また、RUEIによって、完了したセッションのユーザーを監視および追跡するには、Cookieのパスを「/」に設定する必要があります。Oracle ADFアプリケーションが、状態の追跡のために別のCookie名を使用する場合は、それを反映するようにアプリケーション定義を更新する必要があります。また、ユーザー名の認識はj_username構造に基づくことに注意してください。Cookie構成の詳細は、12.2項「セッション・トラッキング・メカニズムの指定」を参照してください。

I.5 ADFのレポート

ADFのレポートの作成において、RUEIはヘッダーとして提供されるAdf-View-IDに大きく依存しています。そのため、ADF開発者がビューIDにそれ相応の値を設定しておくことが重要です。デフォルトでは、コンテンツを生成したjspxの名前を基にビューIDが設定されます。

動的なリージョンでは、特別なコーディングを行わなくても常にUIShell.jspxが表示されます。次のようなコードを実装することをお薦めします。

jsfフェーズのリスナー

FacesContext context = FacesContext.getCurrentInstance();
Object response = context.getExternalContext().getResponse();
if (response instanceof HttpServletResponse) {
HttpServletResponse httpResponse = (HttpServletResponse)
response;
httpResponse.setHeader(<PageInfoBean>._VIEW_ID_HEADER_NAME, <relevant
viewID>);
}

クライアントが閲覧したコンテンツの生成元Javaコード・ブロックを、ビューIDからおおよそ推測できるようにしておく必要があります。Fusionの場合、これは製品のコンテキストで意味を持つため、範囲は個々のリージョンよりも広くなります。

I.6 ADFページおよびセッション診断

ADFページは、セッション診断機能を使用したリプレイ・ビューアでは使用できない可能性があるか、リッチ・インターネット・アプリケーション(RIA)に基づくページの場合は、文字化けする可能性があります。RIAフレームワークの例には、Ajax、Curl、GWT、Adobe Flash/Adobe Flex/AIR、Java/JavaFX、MozillaのXUL、OpenLaszloおよびMicrosoft Silverlightがあります。

再生したページに何も表示されない場合は、対象のページ内でoracle.adf.view.rich.security.FRAME_BUSTINGコンテキスト・パラメータの使用を中止することを検討してください。このセキュリティ・パラメータは、悪意のあるWebサイトが別のドメインのページをフレームに引き出して偽のページで覆い隠すクリックジャックという攻撃を防止するときに使用します。

I.7 データ・アイテム

表I-1に示すADF固有のデータ・アイテムがRUEIでレポートされます。

表I-1 ADF固有のデータ・アイテム

項目

説明

ADFスイート/コード

構成定義で定義されたADFフレームワーク・スイートのコード。このデータを使用して、監視対象の様々なADFフレームワーク・スイートを区別することができます。

ADFスイート/名前

構成定義で定義されたADFフレームワーク・スイートの名前。このデータを使用して、監視対象の様々なADFフレームワーク・スイートを区別することができます。

ADFアクション/名前

このヒットによってトリガーされたアクション(表示、アクション、ダイアログ、フォーカス、ディスクロージャ、起動、問合せ、ソート、valueChangeなど)。

ADFアプリケーション/名前

ADFフレームワークにおけるアプリケーション・モジュールの名前。

ADFコンポーネント・クライアントID/名前

エンドユーザーが(前の)ページでクリックした構成要素の一意のID。

ADFコンポーネント表示名/名前

(前の)エンドユーザー・アクションによってアクティブになった構成要素の表示名。

ADFコンポーネント・タイプ/名前

(前の)エンドユーザー・アクションによってアクティブになった構成要素の種類。

ADFリージョン/名前

(前の)エンド・ユーザー・アクションが実行された直前のアクティブ・リージョン名。

ADFビューID/名前

(前の)エンドユーザー・アクションが行われた画面(の一部)のID。

詳細情報

Oracle ADFのアーキテクチャおよび機能の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。これは次の場所から入手できます。

http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/title.htm

J WebCenter

この付録では、Oracle WebCenter PortalおよびOracle WebCenter Sitesのアプリケーションの正確な監視のために使用可能なサポートについて詳しく説明します。

J.1 WebCenterスイート定義の作成

WebCenterベースのアプリケーションのスイート定義は、サポートされている他のOracle Enterpriseアーキテクチャの場合と同様の方法で作成できますが、WebCenterスイートには次の2つのタイプがあります。

- WebCenter Portal

- WebCenter Sites

スイートを作成する手順の詳細は、10.1.1項「スイート定義の作成」に記載されています。

WebCenter Portalスイートの動作は、ADFスイートの動作と似ています(付録I「Oracle ADFのサポート」を参照)。

WebCenter Sitesスイートを使用するには、WebCenterクイック・スタート・ガイドの説明に従って、WebCenterとともに提供されるテンプレート、または次のようなデモンストレーション・アプリケーションから提供されるテンプレートを適用する必要があります。

http://www.oracle.com/technetwork/middleware/webcenter/avitek-sample-portal-086834.html

以前のリリースのRUEIでは、(PortalまたはSitesの指定ではなく) WebCenterスイートの作成がサポートされていました。このオプションは引き続き使用可能ですが、使用しても同じレベルのレポートは提供されません。

J.2 すべてのWebCenter Sitesディメンションのレポートの確認

すべてのWebCenter Sitesディメンションのレポートを確実に行うには、要素/Head_MPテンプレートを編集して次の行を追加します。

<render:callelement elementname="Utilities/RUEI/HttpHeaders" args="c,cid,site,siteLocale,d"/>

この行は、<render:calltemplate tname='Head${args.sitepfx}'args="c,cid,p,siteLocale,d,deviceid,packedargs" style="element"/>を含む行の前に追加する必要があり、この要素の最後の部分は次のようになります。

<render:callelement elementname="Utilities/RUEI/HttpHeaders"  args="c,cid,site,siteLocale,d"/>
<render:calltemplate tname='Head${args.sitepfx}' args="c,cid,p,siteLocale,d,deviceid,packedargs" style="element"/>
</cs:ftcs>

J.3 WebCenter Portalアプリケーションの監視の有効化

Oracle WebCenter Portalアプリケーションを監視する場合は、adf-faces-databinding-rt.jarファイルによってExecutionContextProvider(oracle.adfinternal.view.faces. context.AdfExecutionContextProvider)クラスのDMSベース実装が提供されることに注意してください。実装クラスは.jarファイルで事前に定義されていますが、機能が有効になるのは、次のアプリケーション・コンテキスト・パラメータをweb.xmlファイルに指定したときです。

<context-param>
<description>This parameter notifies ADF Faces that the ExecutionContextProvider
service provider is enabled. When enabled, this will start
monitoring and aggregating user activity information for the client
initiated requests. By default, this param is not set or is false.
</description>  <param-name>oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER</param-name>
<param-value>true</param-value>
</context-param>

J.4 Cookieテクノロジの指定

Oracle WebCenterはJavaテクノロジに基づいているため、Oracle WebCenterアプリケーションは多くの場合JSESSIONID状態Cookieを使用します。また、RUEIによって、完了したセッションのユーザーを監視および追跡するには、Cookieのパスを「/」に設定する必要があります。Oracle WebCenterアプリケーションが、状態の追跡のために別のCookie名を使用する場合は、それを反映するようにアプリケーション定義を更新する必要があります。また、ユーザー名の認識はj_username構造に基づくことに注意してください。Cookie構成の詳細は、12.2項「セッション・トラッキング・メカニズムの指定」を参照してください。

J.5 データ・アイテム

WebCenter固有のデータ・アイテムの詳細は、表V-13「WebCenterアプリケーション」を参照してください。

詳細情報

Oracle ADFのアーキテクチャおよび機能の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。これは次の場所から入手できます。

http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/title.htm

K PeopleSoftのサポート

この付録では、PeopleSoftベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。このサポートの対象となるのは、有効なApplication Management Suite for PeopleSoftライセンスを所有している場合に限られることに注意してください。詳細は、オラクル社の担当者に問い合せてください。

K.1 概要

このバージョンで提供される監視のサポートは、PeopleToolsバージョン8.48および8.49に基づくPeopleSoftアプリケーションに対して検証されています。テストは行っていませんが、これよりも前のバージョンにも対応できる場合があります。

K.2 監視の有効範囲の検証

多くの場合、PeopleSoftソフトウェアは標準以外のポート(800など)を使用するように構成されます。PeopleSoftインストールが実行しているポートを確認するには、ログインURLを調べてください。これは次の形式になっています。

http(s)://hostname:portnumber/pspt/...

portnumberが定義済ポートの1つとして構成されていることを確認します(HTTPまたはHTTPS)。また、HTTPSポートが指定される場合は、WebサーバーのSSL秘密鍵のコピーをコレクタ・システムにインポートするようにしてください。

K.3 PeopleSoftスイート定義の作成

PeopleSoftベースのアプリケーションのスイート定義を作成できます。作成方法は、サポートされている他のOracle Enterpriseアーキテクチャの場合と同じです。スイートを作成する手順は、10.1.1項「スイート定義の作成」に記載されています。

K.4 create_PSFT_info.shスクリプトの実行

ご使用の環境でRUEIがPeopleSoftのビジネス・ロジックを正しく変換できるようにする手順は、次のとおりです。

1. create_PSFT_info.shスクリプトをPSFTサーバーのホーム・ディレクトリにコピーします。これはRUEIシステムのRUEI_DATA/processor/local/downloadディレクトリにあります。

2. PSFTサーバーで任意のユーザーとしてcreate_PSFT_info.shスクリプトを実行します。脚注1 このスクリプトは、環境で識別されたページIDにIDを割り当てます。create_PSFT_info.shスクリプトは次の必須パラメータを指定して実行してください。

create_PSFT_info.sh connect-string

connect-stringは、PeopleSoftデータベースに対するスクリプトのアクセスを許可するために使用する文字列です。スクリプトはAPPLSYSスキーマを読み取り、現在のディレクトリに.txtファイルを生成します。次に例を示します。

create_PSFT_info.sh "APPS/APPS@dliild-PSFT-:1522/dli03"
create_PSFT_info.sh "APPS/APPS@PSFT"

複数インスタンス環境では、目的のインスタンスごとにスクリプトを実行し、作成される.txtファイルを別に保存します。また、10.1項「スイートの使用」で説明するように、各インスタンスに別のスイート定義を作成します。

3. 10.1.2項「構成ファイルのアップロード」で説明している手順を実行し、生成されたファイルをレポータ・システムにアップロードします。

K.5 Cookieテクノロジの確認

PeopleSoftスイート・インスタンスを作成すると、PeopleSoft環境用の事前定義済Cookieが自動的に作成されます。これは、PS_TOKENという名前のカスタムCookieとして実装されます。多くの場合、このCookieはご使用のPeopleSoft環境に適しています。ただし、環境の構成によってはこのCookieを変更する必要があります。また、RUEIによって、完了したセッションのユーザーを監視および追跡するには、Cookieのパスを「/」に設定する必要があります。

Cookieの構成の確認

Cookieの構成を確認する手順は、次のとおりです。

1. ブラウザですべてのCookieを消去します。

2. PeopleSoftアプリケーションに(再)ログインします。

3. PeopleSoftでいくつかのページを表示します。

4. ログアウトします。

5. 少なくとも10分間待機します。

6. RUEIレポータ環境を開きます。

7. 「データの参照」を選択し、「すべてのセッション」グループを開いて「セッション診断」を選択します。記録されたセッション(ユーザーID別または時間別)を探します。アプリケーションについてフィルタリングできます。

8. セッションを開いて、次の点を確認します。

- ログイン以外のページ・ビューがレポートされていること。これで、セッションIDがログイン後に保存されていることが確認されます。

- 少なくともある程度のPeopleSoftアプリケーション・アクティビティが記録されていること。

すべてのヒットが同じCookieに関連していない場合(これらは匿名ページとしてレポートされる)、問題がある場所を調べて、適切な方法で解決することをお薦めします。たとえば、Cookieのドメインまたはパスのオプションを調べます。

K.6 ホスト名およびURL接頭辞

PeopleSoftの実装およびPeopleSoftのインスタンスはホスト名で識別できます。一般的に、PeopleSoftスイートにアクセスする方法は2つあります。ホスト名のみを使用する方法、または完全修飾ホスト名(ドメインを含む)を使用する方法です。通常はドメインのみを指定してください。

K.7 データベース表

次のPeopleSoftデータベース表は、カスタマイズに関する情報を取得するためにcreate_PSFT-Info.shスクリプトで使用されます。

- PSPRSMDEFN: portal_name、portal_prntobjectname、portal_objname、portal_labelおよびportal_urltextが、PSFT_object2portallabeltree.txtファイルとPSFT_porturltext2portallabeltree.txtファイルに移入されます。

- PSPNLFIELD: PSFT_pnlfield2label.txtファイルに移入されます。

- PSPNLGROUP: PSFT_pnl2itemlabel.txtファイルに移入されます。

K.8 データ・アイテム

表K-1に示すPeopleSoft固有のデータ・アイテムがRUEIでレポートされます。

表K-1 ディメンション

項目

説明

PeopleSoftコンテンツ・コード

このリクエストのコンテンツ。

PeopleSoft終了ノード・コード

PeopleSoftの終了ノード。

PeopleSoftフォルダ・パス・コード

このリクエストのフォルダ・パス。

PeopleSoft ICaction

実行されたアクションの名前。

PeopleSoft ICactionコード

実行されたアクションのID。

PeopleSoftノード

このリクエストのコンテンツを含むノードの名前。

PeopleSoftノード・コード

このリクエストのコンテンツを含むノードのID。

PeopleSoftパネル・アイテム

PSPNLGROUPと呼ばれるターゲット環境表から作成されるPSFT_pnl2itemlabelのマッピングに基づいたこのリクエストのパネル・アイテム。

PeopleSoftパネル・アイテムID

'Page'パラメータに基づいたパネル・アイテム。

PeopleSoftポータル

エンド・ユーザーが参照したポータルの名前。ポータル定義には、コンテンツ(テンプレート、ページレットなど)の表示方法を記述するメタデータが含まれています。

PeopleSoftポータル・コード

エンド・ユーザーが参照したポータルのID。ポータル定義には、コンテンツ(テンプレート、ページレットなど)の表示方法を記述するメタデータが含まれています。

PeopleSoftサイト

PeopleSoft Pure Internet Architecture設定で指定されたサイト名。これを使用すると、1つの物理Webサーバー上に複数のサイトを設定できます。サイト名は、最終的にWebサーバーによって適切な構成プロパティ・ファイルにマッピングされます。

PeopleSoftサイト・コード

PeopleSoft Pure Internet Architecture設定で指定されたサイト名。これを使用すると、1つの物理Webサーバー上に複数のサイトを設定できます。サイト名は、最終的にWebサーバーによって適切な構成プロパティ・ファイルにマッピングされます。

K.9 リソース

次の資料が役に立つ場合があります。

- OracleアプリケーションでSSLを使用するためのHTTPサーバーの構成(ノート341904.1)。

K.10 既知の制限事項

現在、RUEIはPeopleSoftのすべての機能には対応していません。特に次の制約事項がすでに判明しています。

- レポートは、最後にアクティブになった部分に基づいて行われます。したがって、1人のエンド・ユーザーが複数のブラウザ・ウィンドウで同時に参照しているとき、レポートされるページ名に間違った情報が含まれることがあります。

- 現在、create_PSFT_info.shスクリプトはUNIX PeopleSoftサーバーでしか実行できません。

- create_PSFT_INFO.shスクリプトを実行するときに無効な接続文字列が指定されていても、エラーがすぐにはレポートされません。[Enter]を数回押すとエラーがレポートされます。

- リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。

脚注

脚注1:このスクリプトは、本番環境と同じであれば検収環境でも実行できます。

L Siebelのサポート

この付録では、Siebelアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。このサポートの対象となるのは、有効なApplication Management Suite for Siebelライセンスを所有している場合に限られることに注意してください。詳細は、オラクル社の担当者に問い合せてください。

L.1 概要

提供される監視のサポートは、Siebel 7.7以上のHIアプリケーション(Callcenter、Sales、Service、Marketing、PRMManagerなど)をサポートするように設計されています。

RUEIのリリースに伴い、Siebel Open UIもサポートされています。

L.2 Siebelスイート定義の作成

Siebelベースのアプリケーションのスイート定義を作成できます。作成方法は、サポートされている他のOracle Enterpriseアーキテクチャの場合と同じです。スイートを作成する手順は、10.1.1項「スイート定義の作成」に記載されています。

L.3 Cookieテクノロジの確認

Siebelスイート・インスタンスを作成すると、Siebel環境用の事前定義済Cookieが自動的に作成されます。これは、_snという名前のカスタムCookieとして実装されます。多くの場合、これはSiebelアプリケーションに適しています。ただし、環境の構成によってはそれを変更する必要があります。Cookie構成の詳細は、12.2項「セッション・トラッキング・メカニズムの指定」を参照してください。

L.4 ユーザー・ログオンの取得

場合によっては、ビジターのログオンが簡単に取得できません。たとえば、Webレイヤーの外で代替ビジター・ログオンを行うSingle Sign-On(SSO)構成などが原因です。このような場合は、ビジターが監視対象のSiebelアプリケーションを開始するときにアクセスするWebテンプレート・ページに、次のJavaScriptコードを追加します。

<SCRIPT LANGUAGE="JavaScript">   var loginname = top.theApplication().GetProfileAttr("Login Name");   document.cookie = 'siebeluserid='+loginname  </SCRIPT>

目的のWebテンプレート・ファイルを識別する手順は、次のとおりです。

1. Siebelアプリケーションによって現在使用されている関連するWebページを判別します。Siebel Tools Object Explorerで「Application」をクリックし、監視するSiebelアプリケーション(たとえば、Siebel Public Sector)を問い合せます。フィールドの値(たとえば、ログオンWebページの「Login Web Page」)を書き留めます。

2. Siebel Tools Object Explorerで「Web Page」をクリックして、前の手順で書き留めたWebページを問い合せます。「Web Template」フィールドの値を書き留めます。これはページのレンダリングに使用されるWebテンプレートです。

3. Siebel Tools Object Explorerで「Web Template」をクリックして、前の手順で書き留めたWebテンプレートを問い合せます。Object Explorerの「Web Template」アイコンを展開し、「Web Template File」をクリックします。「Filename」フィールドの値を書き留めます。これがWebテンプレート・ファイルです。

4. 確認されたWebテンプレート・ファイルを更新して、上記のJavaScriptコードを含むようにします。

L.5 ホスト名およびURL接頭辞

Siebel実装は、Webサーバーとクライアント間を通過するすべてのトラフィックを検証することによって分析されます。クライアントは、ビジター・ブラウザまたはSiebel Enterprise Application Integration(EAI)インタフェースにアクセスするソフトウェアです。

このトラフィックの構造は次のとおりです。

http://server:port/application_language/start.swe?parameters

L.6 セッション

個々のビジター・セッションはセッションのCookieに基づいて認識されます。デフォルトで使用されるセッションCookieは_snです。このCookieが使用されない場合は削除できます。カスタムCookieを必要な名前で定義します。URLのパラメータを使用してCookieを認識できないことに注意してください。

ビジター・セッションを追跡するためには、Cookie名をRUEIで正しく指定することを強くお薦めします。

L.7 アクションとページ

ユーザーによって実行されるアクションがRUEIによって追跡されます。アクションは、Siebelサーバーへのコールごとに認識されます(コールでは既知のパラメータのリストが使用されます)。1ユーザーのセッションを表示するとき、すべてのヒットが時間順に設定されます。認識されたヒットはユーザー・アクションとしてマークされ、それ以外はそのアクションの要素(images/objects/activeX-component loading/javascript-library-loadingなど)としてマークされます。レポートされるページごとのロード時間は、アクションに基づいて計算され、すべての要素を含みます。

L.8 関数エラーの認識

事前定義済のコンテンツ・メッセージは、すべての標準SBLエラー・メッセージに自動的に提供されます。SBL-で開始する場合、ページ要素として認識されます。たとえば、SBL-EAI-04117のように指定します。デフォルトでは、このようなエラーは関数エラーとしてレポートされます。詳細は、8.3.13.1項「コンテンツ・メッセージの説明の定義」を参照してください。記載されている例はアプリケーションに関するものですが、この例はスイートにも該当し、リストに文字列が記載されています。

L.9 データ・アイテム

表L-1に示すSiebel固有のデータ・アイテムがRUEIでレポートされます。

表L-1 Siebel固有のデータ・アイテム

項目

説明

Siebelアプレット

エンド・ユーザーがナビゲートしたアプレット。アプレットを使用すると、作成のためにデータにアクセスできます。

Siebelコマンド

エンド・ユーザーが実行した技術アクション(ある場合)。

Siebelメソッド

ユーザーのアクションが実行された技術領域(ある場合)。

Siebelモジュール

エンド・ユーザーが参照したSiebelモジュール。たとえば、Callcenter、HR、MarketingおよびCRMです。

Siebel画面

スイートで使用された画面。画面はビューの論理的な集合です。画面そのものは表示用の構成要素ではなく、メニュー・バーやビュー・バーによって表示されるビューの集合です。

Siebelビュー

表示されたSiebelビューと似ています。ビューは、画面に同時に表示されるアプレットの集合です。

L.10 Siebelログイン・データの解釈

Siebelユーザー・インタフェースでは、画面アクティビティが常にRUEIにレポートされるとは限りません。成功したログインの合計数をRUEIレポートから直接取得できない場合もあります。測定が、不適切なログインやブラウザのリフレッシュなどのアイテムによる影響を受けることもあります。他のRUEI機能を使用して次の手順を実行することにより、この問題を回避できます。

1. 第9章「ユーザー・フローの使用」の説明に従って新規のユーザー・フローを作成し、次のユーザー・フロー・ステップを作成します。

- 第一(ログイン)画面
たとえば、次のようにステップを作成します。

User Group != users

- ホームページ(「ようこそ」ユーザー・ページ)
たとえば、一部のアプリケーションでは次のように指定する必要があります。

User Group = users AND page = Homepage

Siebelでは次のように指定する必要があります。

User Group = users AND Siebel View = *Home Page*

- アプリケーション内部のクリック
たとえば、一部のアプリケーションでは次のように指定する必要があります。

Action = click OR page != Homepage

Siebelでは次のように指定する必要があります。

Siebel Command != (no value)

2. このユーザー・フローを使用し、完了したフローの数をカウントして、ログインしたユーザーの正確な数を判断します。

L.11 既知の制限事項

現在、RUEIはSiebelのすべての機能には対応していません。特に次の制約事項がすでに判明しています。

- RUEIは、判読可能な形式でURLをレポートしようとします。つまり、レポートされるURLが実際のURLのように見えても、ブラウザのアドレス・バーにコピーして貼り付けることができない場合があります。RAW形式(Webサーバーで受信)と判読可能な形式(RUEIでレポート)を区別することはできません。これは、Siebel URLの場合に特に重要です。Siebel URLに含まれる可能性がある次の引数の例と、RUEIでのレポート方法について考えてください。

&SWEView=Program Expense Trend Analysis View
&SWEView=Program+Expense+Trend+Analysis+View

最初のURLは、おそらく次のように回線で送られました。

&SWEView=Program%20Expense%20Trend%20Analysis%20View

ただし、2番目のURLは次のいずれかとして回線で送られた可能性があります。

&SWEView=Program+Expense+Trend+Analysis+View
&SWEView=Program%2bExpense%2bTrend%2bAnalysis%2bView

2つ目のURLは、2つ目の形式で書き換えられていなければ、値がWebサーバーによって正しく解釈されていない可能性があります。

- リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。通常、Siebel SIベースのアプリケーションは、HIベースのアプリケーションよりも制限が少なくなります。

M Oracle FLEXCUBEのサポート

この付録では、Oracle FLEXCUBE Universal BankingまたはDirect Bankingアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。このサポートの対象となるのは、有効なApplication Management Suite for Oracle FLEXCUBEライセンスを所有している場合に限られることに注意してください。詳細は、オラクル社の担当者に問い合せてください。

M.1 概要

監視するWeb環境にOracle FLEXCUBE Universal BankingまたはDirect Bankingアプリケーションが含まれる場合、このサポートを利用することを強くお薦めします。RUEIでのOracle FLEXCUBEアプリケーションの構成にかかる時間が短縮され、これらのアプリケーションの互換性が高くなるだけではなく、Oracle FLEXCUBEアプリケーションを正しく監視できるようになります。便宜上、この付録は両方の環境に対応するように作成されています。ただし、一方の環境のみに関連する情報については明記しています。

RUEIで提供される監視のサポートは、Oracle FLEXCUBE Universal Bankingリリース10.3および11g、Oracle FLEXCUBE Direct BankingリリースFC V.DB5.0からFC V.DB5.4に対して動作が確認されています。

M.2 監視の有効範囲の検証

多くの場合、Oracle FLEXCUBEソフトウェアは標準以外のポート(9000または9082など)を使用するように構成されます。Oracle FLEXCUBEインストールが実行しているポートを確認するには、アプリケーションのURLを調べてください。

Oracle FCUBインストールの場合、通常、URLは次の形式です。

http(s)://hostname:portnumber/FCJNeoWeb...

Oracle FCDBインストールの場合、通常、URLは次の形式です。

http(s)://hostname:portnumber/B001/Internet...

portnumberが定義済ポートの1つとして構成されていることを確認します(HTTPまたはHTTPS)。また、HTTPSポートが指定されている場合には、WebサーバーのSSL秘密鍵のコピーがコレクタ・システムにインポートされていることを確認してください。ポート番号を確認するには、13.3項「ネットワーク・ベース監視の有効範囲の管理」に記載されている手順を実行します。

M.3 Oracle FLEXCUBEスイート定義の作成

Oracle FLEXCUBEベースのアプリケーションのスイート定義を作成できます。作成方法は、サポートされている他のOracle Enterpriseアーキテクチャの場合と同じです。スイートを作成する手順は、10.1項「スイートの使用」に記載されています。

M.4 create_FCUB_info.shおよびcreate_FCDB_info.shスクリプトの実行

ご使用の環境でRUEIがFLEXCUBEのビジネス・ロジックを正しく変換できるようにする手順は、次のとおりです。

1. create_FCUD_info.shスクリプトまたはcreate_FCDB_info.shスクリプト(あるいは両方)をOracle FCUBサーバーおよびFCDBサーバーのホーム・ディレクトリにコピーします。スクリプトはRUEIシステムのRUEI_DATA/processor/local/downloadディレクトリにあります。

2. Oracle FLEXCUBEサーバーで任意のユーザーとしてcreate_FCUD_info.shスクリプトまたはcreate_FCDB_info.shスクリプト(あるいは両方)を実行します。脚注1 これらのスクリプトは、環境で識別されたページIDにIDを割り当てます。これらのスクリプトは次の必須パラメータを指定して実行してください。

create_FCUB_info.sh connect-string
create_FCDB_info.sh connect-string

connect-stringは、Oracle FLEXCUBEデータベースへのスクリプトのアクセスを許可するために使用する文字列です。スクリプトはスキーマを読み取り、現在のディレクトリに.txtファイルを生成します。次に例を示します。

create_FCDB_info.sh "sys/oracle@dliild-jde:1522 as sysdba"create_FCDB_info.sh "fcdbuser@fcdbdatabase"

接続文字列がsys as sysdbaを使用する場合、スクリプトは使用される様々な表の正しいスキーマを検出しようとします。それ以外の場合、ユーザーはデフォルトのスキーマ・ユーザーとみなされます。

3. 10.1.2項「構成ファイルのアップロード」で説明している手順を実行し、生成されたファイルをレポータ・システムにアップロードします。

M.5 Cookieテクノロジの確認

Oracle FLEXCUBEスイート・インスタンスを作成すると、FCUBおよびFCDB環境用の事前定義済Cookieが自動的に作成されます。これは、JSESSIONIDという名前のカスタムCookieとして実装されます。多くの場合、このCookieはご使用のOracle FLEXCUBE環境に適しています。ただし、環境の構成によってはこのCookieを変更する必要があります。また、RUEIによって、完了したセッションのユーザーを監視および追跡するには、Cookieのパスを「/」に設定する必要があります。

Cookieの構成の確認

Cookieの構成を確認する手順は、次のとおりです。

1. ブラウザですべてのCookieを消去します。

2. Oracle FLEXCUBEアプリケーションに(再)ログインします。

3. Oracle FLEXCUBEアプリケーションでいくつかのページを表示します。

4. ログアウトします。

5. 少なくとも10分間待機します。

6. RUEIレポータ環境を開きます。

7. 「データの参照」を選択し、「すべてのセッション」グループを開いて「セッション診断」を選択します。記録されたセッション(ユーザーID別または時間別)を探します。アプリケーションについてフィルタリングできます。

8. セッションを開いて、次の点を確認します。

- ログイン以外のページ・ビューがレポートされていること。これで、セッションIDがログイン後に保存されていることが確認されます。

- 少なくともある程度のOracle FLEXCUBEアプリケーション・アクティビティが記録されていること。

すべてのヒットが同じCookieに関連していない場合(これらは匿名ページとしてレポートされる)、問題がある場所を調べて、適切な方法で解決することをお薦めします。たとえば、Cookieのドメインまたはパスのオプションを調べます。

M.6 FCDBポータルの認識

Oracle FLEXCUBE Direct Bankingは、ポータル名がアプリケーションURLに表示されないように構成できます。この場合、RUEIによってサーバーのIPアドレスまたはOracle FLEXCUBE Direct Banking Webサーバーの仮想ホスト名(完全修飾されたホスト名)を正しいポータル名に変換するためには、構成ファイルをアップロードする必要があります。この構成ファイルにはFCDB_hostnameorserverip2portalcode.txtという名前を付け、ホスト名/IPと変換のためのポータル・コードをタブ区切りで入力します。このようなポータル・コードはデータベースに含まれています。create_FCDB_info.shスクリプトを実行すると、FCDB_portalcode2portalname.txtファイルには、データベースで検出された有効なポータル・コードが含まれます。

次に、有効なホストおよびIPアドレスに対応するポータルの構成例を示します。

# This translation file is used to identify the portal when the portal information
# is not available in the URL. Fill this file with either hostname -> portal or
# server IP -> portal information. The description will be extracted from the
# FCDB database.
# Format example:
#myhost.mybank.com      B004
#10.72.11.89            B007
www.oraclebanking.com              B001
192.168.32.78                              B002

create_FCDB_info.shスクリプトで作成されたzipファイルにこのファイルを追加してから、RUEIにアップロードする必要があります。

M.7 ホスト名およびURL接頭辞

Oracle FLEXCUBEの実装およびFCDBまたはFCUBインスタンスはホスト名で識別できます。一般的に、Oracle FLEXCUBEスイートにアクセスする方法は2つあります。ホスト名のみを使用する方法、または完全修飾ホスト名(ドメインを含む)を使用する方法です。通常はドメインのみを指定してください。

M.8 データベース表

この項では、カスタマイズ情報を取得するためにOracle FLEXCUBE環境で使用されるデータベース表について説明します。

M.8.1 FCDBのカスタマイズ

次のOracle FLEXCUBEデータベース表は、カスタマイズに関する情報を取得するためにcreate_FCDB_Info.shスクリプトで使用されます。

- MSTUSERTYPE(ID_ENTITY、IDCHANNEL、USERTYPE、IDTXN、TOKEN2)と、表MSTTXN(IDTXN)およびAPPLDATA(IDDEVICE、DATAVALUE、DATANAME)の組合せから、ファイルFCDB_identityidtxnidchannelusertype2menulevel1.txt、FCDB_identityidtxnidchannelusertype2menulevel2.txt、FCDB_identityidtxn2menulevel1.txtおよびFCDB_identityidtxn2menulevel2.txtが生成されます。

- MSTUSERTYPES(TYPEUSER、DESCRIPTION)から、FCDB_usertypecode2usertypedescription.txtが生成されます。

- APPLDATA(DATANAME、DATAVALUE)から、FCDB_portalcode2portalname.txtおよびFCDB_channelcode2channelname.txtが生成されます。

M.8.2 FCUBのカスタマイズ

次のOracle FLEXCUBEデータベース表は、カスタマイズに関する情報を取得するためにcreate_FCUB_info.shスクリプトで使用されます。

- FBTBMSG(MSGCODE、MSGDESCRIPTION)から、FCUB_ec2desc.txtが生成されます。

- SMTBFUNCDESC(FUNCTION_ID、DESCRIPTION)から、FCUB_fnid2desc.txtが生成されます。

- GWTMFCJUNC(FUNCTION_ID、ACTION、OPERATION_CODE)から、FCUB_fnidac2adesc.txtが生成されます。

- SMTBMENUNAME(FUNCTION_ID、MODULE)から、FCUB_fnid2moduleid.txtが生成されます。

- SMTBMENUNAME(FUNCTION_ID)とSMTBMODULES(MODULE_ID、MODULE_DESC)から、FCUB_fnid2moduledesc.txtが生成されます。

- STTMBRANCH(BRANCH_CODE、BRANCH_NAME)から、FCUB_brcd2brnm.txtが生成されます。

M.9 データ・アイテム

表M-1に示すOracle FLEXCUBE固有のデータ・アイテムがRUEIでレポートされます。

表M-1 ディメンション

項目

説明

FC Direct Bankingチャネル

セッション中にユーザーが使用したFLEXCUBE Direct Bankingチャネルの名前

FC Direct Bankingチャネル・コード

セッション中にユーザーが使用したFLEXCUBE Direct Bankingチャネルのコード

FC Direct Bankingポータル

セッション中に使用されたFLEXCUBE Direct Bankingポータルの名前

FC Direct Bankingポータル・コード

セッション中に使用されたFLEXCUBE Direct Bankingポータルのコード

FC Direct Bankingユーザー・タイプ

ユーザーのFLEXCUBE Direct Bankingユーザー・タイプの名前

FC Direct Bankingユーザー・タイプ・コード

ユーザーのFLEXCUBE Direct Bankingユーザー・タイプのコード

FC Universal Bankingアクション

画面または従属画面で実行されたFLEXCUBE Universal Bankingアクションの名前

FC Universal Bankingアクション・コード

画面または従属画面で実行されたFLEXCUBE Universal Bankingアクションのコード

FC Universal Bankingブランチ

表示中にアクティブであったFLEXCUBE Universal Bankingブランチの名前

FC Universal Bankingブランチ・コード

表示中にアクティブであったFLEXCUBE Universal Bankingブランチのコード

FC Universal Bankingモジュール

画面または従属画面が属するFLEXCUBE Universal Bankingモジュールの名前

FC Universal Bankingモジュール・コード

画面または従属画面が属するFLEXCUBE Universal Bankingモジュールのコード

FC Universal Banking画面

表示されたFLEXCUBE Universal Banking画面の名前

FC Universal Banking画面コード

表示されたFLEXCUBE Universal Banking画面のコード

FC Universal Banking従属画面

表示されたFLEXCUBE Universal Banking従属画面の名前

FC Universal Banking従属画面コード

表示されたFLEXCUBE Universal Banking従属画面のコード

M.10 既知の制限事項

現在、RUEIはOracle FLEXCUBEのすべての機能には対応していません。特に次の制約事項がすでに判明しています。

- レポートは、最後にアクティブになった部分に基づいて行われます。したがって、1人のエンド・ユーザーが複数のブラウザ・ウィンドウで同時に参照しているとき、レポートされるページ名に間違った情報が含まれることがあります。

- 現在、create_FCDB_info.shスクリプトおよびcreate_FCUB_info.shスクリプトは、UNIX Oracle FLEXCUBEサーバーでしか実行できません。

- create_FCDB_info.shまたはcreate_FCUB_info.shスクリプトを実行するときに無効な接続文字列が指定されていても、エラーがすぐにはレポートされません。[Enter]を数回押すとエラーがレポートされます。

- 現在、トラフィック・サマリー機能(「システム」→「ステータス」→「データ処理」を選択)は、アプリケーション・ロジックに基づいてます。したがって、FCDBとFCUBのトラフィックは処理概要には表示されません。

- リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。

脚注

脚注1:このスクリプトは、本番環境と同じであれば検収環境でも実行できます。

N Oracle FormsおよびOracle E-Business Suiteのサポート

この付録では、Oracle E-Business Suite(EBS)およびOracle Formsベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。詳細は、オラクル社の担当者に問い合せてください。

N.1 概要

RUEIで提供される監視のサポートはEBS R12に対して検証されています。ただし、古いバージョンのForms(11.2より前のリリース)については、正しくないフォーム名が使用されます。

デフォルトでは、レポートされるForms名は、構成スクリプトでアップロードされたマッピングに基づいて、Formsウィンドウ・タイルから導出されます。ただし、環境変数FORMS_RUEI_SEND_FORM_NAMEが設定されている場合、Formsサーバーは、ウィンドウ作成メッセージとともにFormsモジュール名を送信します。

環境情報はdefault.envファイルに設定されます。別のファイル名を使用できますが、これをformsweb.cfgファイルに指定する必要があります。これには、次のような利点があります。

- 同じウィンドウ・タイトルのトラフィック内の複数のForms名を区別できます。

- Formsを追加作成した場合でも、構成スクリプトを再実行する必要がありません。

Oracle Forms環境を拡張してテクニカルなフォーム名が送信されるようにするには、次の表内の該当するパッチを適用します。

表N-1 Formsのパッチおよび変数

E-Businessのバージョン

Formsのバージョン

FormsのパッチおよびRUEI対応

使用するForms変数

11i

6.0.8

パッチ16542522

FORMS60_RUEI_SEND_FORM_NAME

12

10.1.2.3

パッチ16784403

FORMS_RUEI_SEND_FORM_NAME

12

11.1.2

デフォルトの機能

FORMS_RUEI_SEND_FORM_NAME

Oracle Formsのサポート

Oracle Formsは、サーブレットとソケットという2つのモードで構成できます。サーブレット・モードでは、Javaサーブレット(Forms Listenerサーブレット)がForms JavaクライアントとOracleAS Formsサービスの通信を管理します。ソケット・モードではデスクトップ・クライアントがFormsサーバーに直接アクセスします。RUEIではサーブレット・モードとソケット・モードの両方がサポートされます。サーブレット・モードおよびソケット・モードでのOracle Formsの操作と構成の詳細は、次のサイトを参照してください。

http://metalink.oracle.com/metalink/plsql/ml2_documents.showNOT?p_id=384241.1

Oracle Formsが構成されているモードを確認する方法は、N.8項「ソケット・モードとサーブレット・モードのチェック」を参照してください。

Formsのみのユーザー

このマニュアルで提供する情報はすべてのEBSユーザーに関連するものです。ただし、情報がEBSユーザーまたはFormsのみのユーザーに固有の場合は明記しています。

N.2 Formsのみの環境の使用

Formsのみの環境を使用するユーザーは、この項で説明する点に特に注意する必要があります。

RUEIでEBSベース・アプリケーションについての正確なレポートを行うには、本番環境の情報が必要です。特に、機能領域とレポートされる名前をマッピングする必要があります。これは、N.7項「RUEIとEBS本番環境の同期化」で説明するようにcreate_EBS_info.pl Perlスクリプトを実行して行います。このスクリプトを実行して、生成される.txtファイルを.zipファイルに含めてアップロードすることを、Formsのみの環境のユーザーにお薦めします。

機能マッピングの手動作成

create_EBS_info.plスクリプトは、いくつものEBSデータベース表を使用して、Oracle Formsインスタンスのインストールと構成に関する情報を取得します。使用される正確なデータベース表をN.10項「データベース表」に示します。

ただし、このスクリプトで使用されるAPPLSYS.FND_APPLICATION、APPLSYS.FND_APPLICATION_TL、APPLSYS.FND_FORM、APPLSYS.FND_FORM_TLおよび他の表は、Formsのみの環境には存在しません。このため、RUEIで提供されるデフォルト(テンプレート)のマッピング(この項で後から説明)を利用するか、対応する.txtファイルを手動で作成することで必要なマッピングを指定できます。

これらのファイルを手動で作成するときは、次のタブ区切りファイルが必要です。

- EBS_formname2details.txt: 各フォームの機能の説明を指定します。このファイルの各行は次のような形式です。

formname{TAB}form_description

次に例を示します。

ADSAPCRD        Credit Card Expense Transaction Entry
ADSAPPRC        Procurement Card Transaction Entry
ADSCONC         Running Jobs
ADSCONC         Tax Locations
ADSCSCRC        Healthcare CC
ADSMAILI        Mail InformationADSRSETUP       ADS Repurpose Setup
ADSSOE          Custom Order EntryADSSOE          View Person Life Event Information
AKDAPREG        Application Module Parameters Registry

- EBS_formname2appshort.txt: 各フォームが含まれているアプリケーション名の短縮形(3文字)を指定します。このファイルの各行は次のような形式です。

formname{TAB}short_application_name

次に例を示します。

ADSAPCRD        ads
ADSAPPRC        ads
ADSCONC         ads
ADSCSCRC        ads
ADSMAILI        ads
ADSRSETUP       ads
ADSSOE          ads
AKDAPREG        ak
AKDATTRS        ak
AKDFLOWB        ak

- EBS_appsort2appname.txt: 短縮形(3文字)のアプリケーション名と完全なアプリケーション名のマッピングを指定します。このファイルは次のような形式です。

short_application_name{TAB}application_name

次に例を示します。

abm     Activity Based Management (Obsolete)
ad      Applications DBA
ads     Applications Demonstration Services
ads_dev ADS Development
ahl     Complex Maintenance Repair and Overhaul
ahm     Hosting Manager(Obsolete)
ak      Common Modules-AK
alr     Alert
ame     Approvals Management
amf     Fulfillment Services (Obsolete)

作成した構成ファイルは、目的のスイートごとに.zipファイルに含めてアップロードする必要があることに注意してください。.zipファイルには、空でない.txtファイルしか含めることができません。また、これらのファイルはすべてルート・ディレクトリに存在する必要があります。つまり、サブディレクトリは許可されていません。実際の本番環境に基づいた適切な構成ファイルを目的のスイート用にアップロードする必要があります。構成ファイルの更新の手順は、N.7項「RUEIとEBS本番環境の同期化」に記載しています。

デフォルト(テンプレート)マッピングの利用

必要なマッピングの手動作成が現実的ではない場合は、すでにRUEIに構成されているデフォルト(テンプレート)マッピングを利用できます。この方法で適切なレベルのレポートを得られますが、次の制限事項があります。

- form_name: 通常、これは、機能の説明に変換される8文字のテクニカル名です。ただし、説明がない場合は、8文字のテクニカル名がかわりにレポートされます。

- app: 通常、これは、フォーム名とアプリケーションを関連付けるマッピング・ファイルから導出されます。ただし、導出されない場合は、フォーム名の先頭3文字がかわりにレポートされます。

- application_name: 通常、これはマッピング・ファイルから導出されます。ただし、導出されない場合は、かわりにappがレポートされます。

最新の一致情報

一般的にFormsのみの環境は時間とともに変化するため、マッピング情報を定期的に確認することを強くお薦めします。上記の制限は、最後にcreate_EBS_info.plスクリプトを実行してから、またはマッピング・ファイルを手動で作成してから環境に追加されたすべてのフォームに適用されることに注意してください。

Formsベース環境のメモリー要件

Formsベース・トラフィックの監視には、大容量のメモリーが必要になることに注意してください。たとえば、10,000件の同時Formsセッションの監視には、約10GBのコレクタ・メモリーが必要になります。このため、Formsベース・トラフィックをリモート・コレクタとして監視するコレクタには、少なくとも16GBのRAMをデプロイすることをお薦めします。または、単一サーバー・デプロイメントを使用している場合、サーバーには少なくとも32GBのRAMが必要です。

さらに、コレクタで使用できるシステム・メモリーのレベルを確認することをお薦めします。24GBのRAMを備えた単一サーバー・デプロイメントでは50%に設定する必要があります。32GBのRAMでは40%に設定する必要があります。使用できるコレクタのメモリー量を増やす方法の詳細は、次の場所を参照してください。

https://support.oracle.com/CSP/ui/flash.html#tab=KBHome%28page=KBHome&id=%28%29%29,%28page=KBNavigator&id=%28from=BOOKMARK&bmDocType=PROBLEM&bmDocTitle=Remote%20Collector%20not%20able%20to%20run%20due%20to%20memory%20restrictions&bmDocDsrc=KB&bmDocID=762361.1&viewingMode=1143%29%29

N.3 監視の有効範囲の検証

多くの場合、EBSソフトウェアは標準以外のポート(8000など)を使用するように構成されます。EBSインストールが実行しているポートを確認するには、ログインURLを調べてください。これは次の形式になっています。

https(s)://hostname:portnumber/OA_HTML/AppsLogin

portnumberが定義済ポート(後で説明)の1つとして構成されていることを確認します。また、HTTPSポートが指定される場合は、WebサーバーのSSL秘密鍵のコピーをコレクタ・システムにインポートするようにしてください。モードとポート番号の識別方法の詳細は、N.8項「ソケット・モードとサーブレット・モードのチェック」を参照してください。ポート番号を確認するには、13.3項「ネットワーク・ベース監視の有効範囲の管理」に記載されている手順を実行します。

N.4 EBSスイート定義の作成

EBSベースのアプリケーションのスイート定義を作成できます。作成方法は、サポートされている他のOracle Enterpriseアーキテクチャの場合と同じです。スイートを作成する手順は、10.1項「スイートの使用」に記載されています。

Formsを使用するEBSスイートの場合は、「拡張」セクションを選択し、その他タブをクリックすることに注意します。スイートの概要が、図N-1に示されるように変わります。

図N-1 拡張スイート構成セクション

これらの設定の使用方法は次の項に記載されています。

N.5 追跡テクノロジの指定

RUEIではセッション情報はCookieに基づいています。Cookieは、ヒットを特定のアクセスに結び付けるために使用されます。一般的にCookieはユーザー・ログイン・ページにも結び付けられるため、RUEIは同じCookieを持つ後続のすべてのヒットにユーザー名を含めることができます。EBSにはいくつものCookieがあります。ただし、これらは通常は使用できません。主な問題点は、一意性が不十分であること(たとえばoracle.uix)および用途が狭すぎることです(たとえば、JSESSIONIDはWebサイトの/OA_HTML/部分にしか使用できません)。

クライアント側のCookieメカニズムを実装することをお薦めします。この手順は、12.2項「セッション・トラッキング・メカニズムの指定」に記載されています。

注意:
Formsのみの環境では、ビジターがForms内のアプリケーションにログオンすると、Formsログオン・ページのユーザーIDが自動的に追跡されます。

N.5.1 カスタムCookieの構成

Cookieを次のように構成します。

1. EBSサーバーの$OA_HTMLディレクトリにファイル(ruei_cookie.htmなど)を作成します。

2. このファイルに次のJavaScriptコードを挿入します。

<SCRIPT LANGUAGE="JavaScript">
if(document.cookie.indexOf('RUEItrack=')==-1)
{
document.cookie='RUEItrack='+
parseInt(Math.random()*2147418112)+
new Date().getTime()+
';path=/;domain=.oracle.com';
}
</SCRIPT>

.oracle.comはEBSインスタンスのドメイン名に置き換えてください。

3. SYSADMINユーザーとしてEBSにログインし、機能管理者職責オプションを選択します。

図N-2 EBS Oracleアプリケーション

4. 「パーソナライズ」タブに移動してパス/oracle/apps/fnd/sso/login/webuiを入力し、「移動」をクリックしてドキュメントを取得します。

図N-3 EBSの「パーソナライズ」画面

5. 図N-3に示すように、MainLoginドキュメントの「ページのパーソナライズ」アイコンを選択します。

6. パーソナライズ・コンテキストの選択画面でデフォルトを受け入れ、「適用」をクリックします。有効範囲が/oracle/apps/fnd/sso/login/webui/MainLoginPGになったことに注意してください。

7. 完全ビュー・オプションを選択し、「ページ・レイアウト」行のアイテムの作成アイコンをクリックします(図N-4を参照)。

図N-4 EBSの完全ビュー

8. 続く画面(図N-5)で、次の手順を実行します。

- 「アイテム・スタイル」を「URLを含める」に設定します。

- 「ID」に名前(RUEI_COOKIEなど)を入力します。

- 「ソースURI」を/OA_HTML/ruei_cookie.htmに設定します。

- 「適用」をクリックして変更を保存します。

図N-5 EBSのアイテム詳細

「パーソナライズ」ページに、前述の手順を使用して追加したURLを含めるアイテムが表示されます。

N.5.2 EBSからのCookie構成の確認

Cookieの構成を確認する手順は、次のとおりです。

1. EBSからログアウトします。

2. EBSログイン・ページで、右クリックして「ページ・ソースの表示」を選択します。

3. 「ruei」を検索します。ruei_cookie.htmに挿入されたテキストが表示されます。次に例を示します。

<div></div><SCRIPT LANGUAGE="JavaScript">if(document.cookie.indexOf('RUEItrack=')==-1){document.cookie='RUEItrack='+parseInt(Math.random()*2147418112)+new Date().getTime()+';path=/;domain=.acme.com';}</SCRIPT><div></div>

N.5.3 RUEIからのCookie構成の確認

Cookieの構成を確認する手順は、次のとおりです。

1. ブラウザですべてのCookieを消去します。

2. EBSアプリケーションに(再)ログインします。

3. Oracle Formsをロードする操作を実行します。

4. Oracle Formsでいくつかの操作を実行します。

5. ログアウトします。

6. 少なくとも10分間待機します。

7. RUEIレポータ環境を開きます。

8. 「データの参照」を選択し、「すべてのセッション」グループを開いて「セッション診断」を選択します。記録されたセッション(ユーザーID別または時間別)を探します。アプリケーションについてフィルタリングできます。

9. セッションを開いて、次の点を確認します。

- ログイン以外にページ・ビューがあること。これで、セッションIDがログイン後にOAフレームワークに保存されていることが確認されます。

- 少なくともある程度のOracle Formsアクティビティが未定義アクションとして記録されていること。これで、サーブレット・コールが正しく記録されていることが確認されます。

- データ・ブラウザでレポートされるページ名に、図N-6でのハイライト表示部分のようなイベントが示されること。

図N-6 ページ名の例

すべてのヒットが同じCookieに関連していない場合、問題がある場所を調べて(たとえば、Cookieのドメインまたはパス・オプション)、適切な方法で解決することをお薦めします。

N.5.4 セッションの追跡、相関変数およびセッションURL引数

相関変数とセッションURL引数に関して指定する必要がある追跡メカニズムは、いくつかのフロー・チャートを使用して決定することをお薦めします。

Formsセッション・パラメータ

図N-7に、セッション・パラメータを決定する方法を示します。ソケット・モードで実行している場合、この設定は対応していません。そうでない場合は、各Formsセッションに一意の値を提供する引数をForms URLで調べる必要があります。通常、この引数はURLでセミコロンまたは疑問符の後にあります。たとえば、jsessionidまたはJServSessionIdformsです。指定したパラメータがURLで見つからない場合、Cookieが検索されます。

図N-7 Formsセッション・パラメータ

相関変数

相関変数を使用すると、セッション(TCP上のソケット・モード)を1つのエンドユーザー・セッションにマージできます。図N-8に、相関変数を決定する方法を示します。

図N-8 相関変数

一意のクライアントIPアドレスが使用される場合、この設定は対応していません。ソケット・モードで実行している場合、HTTPトラフィックとソケットモード・トラフィックの両方で得られる相関変数(「INDEX_INITIAL_CMDLINE」に含まれる)の値がセッションの注釈として付けられます。EBS環境の場合、これは常にicx_ticket変数を含みます。EBS以外の環境の場合、他の変数を指定する必要があります。HTTPレイヤーにおいて、Formsの初期化コールの問合せ部分で、またはgp1=....&gv1=...のような構文で、この変数が見つかります。ここで、gp1に値の名前を示します。

HTTPレイヤーにおいて、次のように確認できる場合があります。

/OA_HTML/frmservlet?…&gp15=icx_ticket&gv15=255. 184.210.99jE82BtqiYLHJ8T6-bLxTLw…

または、次のように確認できます。

/OA_HTML/frmservlet?…&env=NLS_LANG='AMERICAN_AMERICA'+…+icx_ticket='255.184.210.99.jE82BtqiYLHJ8T6-bLxTLw..'+…

Formsレイヤーでは、変数INDEX_INITIAL_CMDLINEがコレクタのログ・ファイルで確認できることに注意してください。次に例を示します。

&Runform-001.INDEX_INITIAL_CMDLINE=server module=/oracle/r12/VIS12/apps/apps_st/appl/fnd/12.0.0/forms/US/FNDSCSGN fndnam=APPS  config='VIS12'
icx_ticket='255.184.210.99.jE82BtqiYLHJ8T6-bLxTLw..' resp='FND/APPLICATION_DEVELOPER' secgrp='STANDARD' start_func='FND_FNDPOMPO' other_params=…

セッション・トラッキングCookie

図N-9に、セッション・トラッキングCookieを決定する方法を示します。

図N-9 セッション・トラッキングCookie

一意のクライアントIPアドレスが識別される場合は、デフォルトのクライアントIPベースの追跡を使用できます。または、ホスト全体に対して一意の値を持つCookieが使用可能な場合は、JavaScriptを使用してこのCookieを作成できます。その他の場合は、デフォルトのEBS(JSESSIONID)追跡スキームを使用する必要があります。

たとえば、セッションCookieを追加するためにログイン・ページを変更できない場合があるとします。その場合は、Forms以外のトラフィックの別のEBS Cookie(たとえばJSESSIONID)を選択できます。相関関数を使用して、Forms以外のトラフィックをFormsベースのトラフィックに結び付けることができます。このとき、Forms以外のヒットはJSESSIONIDを使用して識別され、共有ヒットはJSESSIONIDと相関引数の組合せで識別され、Formsヒットはセッション・トラッキング変数jsessionidと最初のコマンド行の相関引数の組合せで識別されます。

N.6 Formsサーバー・モードのタイムアウトの指定

Formsソケット・モードでは、アクティブなソケットモード・セッションが非アクティブになってから数分間は、コレクタがセッションを廃棄できないように設定できます。この設定はFormsソケット・モードのみに対応することに注意してください。デフォルトでは10分に設定されています。

N.7 RUEIとEBS本番環境の同期化

ご使用の環境でEBSフレームワークがどのように実装されているかをRUEIで認識するための手順は、次のとおりです。

注意:
この項の内容は、Forms名のレポート機能が有効になっている環境には該当しません。詳細は、N.13項「Forms名のレポート」を参照してください。以前のリリースへのバックポートが済んでいるため、将来的にはすべてのEBS/Formsユーザーがforms名のレポート機能を有効にすると考えられます。

1. create_EBS_info.plスクリプトをEBSサーバーのホーム・ディレクトリにコピーします。これはRUEIシステムのRUEI_DATA/processor/local/downloadディレクトリにあります。
スクリプトの前提条件を次に示します。

- Perl 5.8.1以上がインストールされていること。

- PerlモジュールArchive::Zip (手作業によるzip操作を軽減)。

formsのデプロイメントの前提条件を次に示します。

- formsコンパイラ(f60genやfrmcmpなど) (パス内)。

- fmbファイルへのアクセス(-dirパラメータで場所を指定)。

EBSのデプロイメントの前提条件を次に示します。

- sqlplus(パス内)。

- EBSリポジトリ(読取専用)にアクセスするための接続文字列。

- JTT環境(EBS内)については、jttファイルへのアクセス(-dirパラメータで場所を指定)が必要です。

2. create_EBS_info.plスクリプトをEBSサーバーで任意のユーザーとして実行します脚注1。このスクリプトにより、環境内で識別されたページIDにIDが割り当てられます。create_EBS_info.plスクリプトは次の構文で実行してください。

create_EBS_info.pl -part=all|DB|JTT|FORM [-connectstring=connectstring] [-debug] [-exeloc=exedir] [-dir=dir1,dir2]

構造の各要素の意味は、次のとおりです。

- partオプションには、生成されるファイルのサブセットを指定します。次のように指定できます。

- all: すべてのファイルが生成されます。これはデフォルトです。以下の3つのオプションを組み合せたものです。

- DB: このオプションは主としてEBS環境用です。構成ファイルのサブセットが生成されます。このオプション(またはallオプション)を使用する場合は、-connectstringパラメータを指定する必要があります。また、-exelocパラメータも指定する必要があります。これには、SQLPlus実行可能ファイルの場所を指定してください(PATHのいずれかのディレクトリにない場合)。

- JTT: このオプションは主としてEBS環境用です。すべてのJavaベース・ファイルが生成されます。Javaファイルの場所はAPPL_TOP設定に基づきます。設定がない場合、-dirパラメータで指定されるディレクトリが使用されます。

- FORM: このオプションは主としてFormsベース環境用です。すべてのFormsベース・ファイルが生成されます。このオプション(またはallオプション)を指定する場合は、-exelocパラメータを指定する必要があります。これには、frmcmpまたはfrmcmp_batch実行可能ファイルの場所を指定してください(PATHのいずれかのディレクトリにない場合)。Forms(.fmb)ファイルの場所はAPPL_TOP設定に基づきます。設定がない場合、-dirパラメータで指定されるディレクトリが使用されます。

- connectstringには、データベースにアクセスできるようにSQLPlusに渡す文字列を指定します。これは、Formsのみの環境では必要ありません。

- debugは、デバッグ・モードを有効にする必要があることを示します。

- execlocは、実行可能ファイルがPATHのディレクトリのいずれかに存在しないこと、exedirディレクトリを検索する必要があることを示します。複数のディレクトリを指定するには、カンマで区切るか-exelocオプションを複数指定する必要があることに注意してください。

- dir1、dir2などには、JavaまたはForms関連の情報を検索するディレクトリを指定します。複数のディレクトリを指定するには、カンマで区切るか-dirオプションを複数指定する必要があることに注意してください。

スクリプトはAPPLSYSスキーマを読み取り、現在のディレクトリに.txtファイルを生成します。次に例を示します。

perl create_EBS_info.pl -part=all -connectstring=APPS/APPS@linux-ebs-r12-pc:1522/VIS12
perl create_EBS_info.pl -part=all -connectstring=APPS/APPS@VIS12

複数インスタンス環境では、目的のインスタンスごとにスクリプトを実行し、作成される.txtファイルを別に保存します。また、インスタンスごとに別のスイート定義を作成します。

注意:
EBSアプリケーションに新たなカスタマイズを行う(または既存のカスタマイズを変更する)場合は、スクリプトを再実行して、生成されるzipファイルを再インポートする必要があります。

3. スクリプトを実行すると、実行したディレクトリにいくつかの.txtファイルが作成されます。関連するすべての.txtファイルは、.zipファイルにまとめて格納されます。RUEIレポータ・システムへのファイルのアップロードに使用できる場所に、この.zipファイルをコピーします。

4. 10.1.2項「構成ファイルのアップロード」で説明している手順を実行し、生成されたファイルをレポータ・システムにアップロードします。

注意:
create_EBS_info.plスクリプトの実行中に警告またはエラー・メッセージを受け取った場合は、N.20.4項「create_EBS_info.plスクリプトでFRM-91500エラーがレポートされる」にある重要なトラブルシューティング情報を参照してください。

Perlインタプリタ

デフォルトではPerlインタプリタはMicrosoft Windowsには同梱されていません。多くの場合、Oracleデータベースおよび他のOracle製品の一部としてインストールされます。PerlインタプリタをMicrosoft Windowsシステムで探すには、「スタート」→「検索」→「ファイルやフォルダ」を選択して、perl.exeを入力します。見つかった実行可能ファイルを使用して、構成スクリプトを実行します。

Perl実行可能ファイルがない場合は、RUEIシステムで上記の問合せのDBの部分を実行できます(システムからEBSデータベースへの接続が可能な場合)。これは、リモート・ホストのEBSデータベースのAPPSスキーマを参照するconnectstringの-part=DBオプションを使用して実現できます。データベースベースのEBSカスタマイズのみが生成されることに注意してください(JTT/JavaベースのカスタマイズまたはFormsベースの変更は生成されません)。

create_EBS_info.plスクリプトの実行を省略した場合でも、RUEIによってEBSおよびFormsアクティビティのレポートは行われます。ただし、レポートされる名前はカスタマイズを反映しません。たとえば、職責が職責名ではなく職責キーでレポートされ、Formsがフォームの機能説明ではなくフォーム名でレポートされます。ほとんどカスタマイズが行われていない環境ではこれは問題になりません。

N.8 ソケット・モードとサーブレット・モードのチェック

この項では、Oracle Formsサーバーがサーブレット・モードとソケット・モードのどちらで実行しているかをチェックする方法を説明します。

Oracle Applicationsリリース12

Oracle Applicationリリース12は、デフォルトの構成ではサーブレット・モードで実行します。

次のコマンドを使用します。

$ grep connectMode FORMS_WEB_CONFIG_FILE

現在の接続モードがレポートされます。

connectMode=servlet

または、次のコマンドを使用します。

$ grep frmConnectMode CONTEXT_FILE

現在の接続モードがレポートされます。

<forms_connect oa_var="s_frmConnectMode">servlet</forms_conr....

Oracle Applicationsリリース11

Oracle Applicationリリース11は、デフォルトの構成ではソケット・モードで実行します。

次のコマンドを使用します。

$ grep connectMode FORMS60_WEB_CONFIG_FILE

現在の接続モードがレポートされます。

connectMode=socket

次のコマンドを使用します。

$ grep xsport FORMS60_WEB_CONFIG_FILE

目的のポート番号が必要です。

xsport=9095

または、次のコマンドを使用します。

$ grep socket CONTEXT_FILE

現在の接続モードがレポートされます。

<forms_connect oa_var="s_frmConnectMode">socket</forms_conr....

HTMLソースのチェック

最後に、Oracle Formsアプリケーションの起動に使用するページのHTMLソースもチェックできます。Internet Explorerで行う場合は、「表示」→「ソース」を選択します。図N-10に示すように接続モードが含まれています。

図N-10 起動ページの詳細例

関連する接続モードの情報をハイライト表示しています。

N.9 ホスト名およびURL接頭辞

EBSの実装およびEBSのインスタンスはホスト名で識別できます。場合によっては、URL接頭辞で識別できます。一般的に、EBSスイートにアクセスする方法は2つあります。ホスト名のみを使用する方法、または完全修飾ホスト名(ドメインを含む)を使用する方法です。通常は、URL接頭辞なしでドメインのみを指定してください。特に設定を行っていないアプリケーションはデフォルトの場所でアクセスされます。

formsのソケット・モードでは、server-ipを指定する必要があります。サーバーが複数ある場合、formsソケット・モードを正常に機能させるため、各サーバーのserver-ip/portの組合せを指定する必要があります。

N.10 データベース表

次のEBSデータベース表は、カスタマイズに関する情報を取得するためにcreate_EBS_info.plスクリプトで使用されます。

- APPLSYS.FND_FORM_FUNCTIONS
Function_id、application_id。

Function_idは、EBS_function_id2*.txtファイルにデータを移入するために使用されます。

- APPLSYS.FND_FORM_FUNCTIONS
User_function_name。

- APPLSYS.JDR_PATHS
名前およびツリー構造。

Path_nameは、EBS_pathname2*.txtファイルにデータを移入するために使用されます。

- APPLSYS.FND_APPLICATION
アプリケーション短縮名。

Application_nameは、EBS_appshort2*.txtファイルにデータを移入するために使用されます。

- APPLSYS.FND_APPLICATION_TL
アプリケーション名

- APPLSYS.FND_FORM
Form_name、application_id

Form_nameは、EBS_formname2*.txtファイルにデータを移入するために使用されます。

- APPLSYS.FND_FORM_TL
User-form-name。

- APPLSYS.FND_RESPONSIBILITY
職責キー

- APPLSYS.FND_RESPONSIBILITY_TL
職責の説明

- APPLSYS.JDR_ATTRIBUTES

- APPLSYS.FND_NEW_MESSAGES
MESSAGE_NUMBER、MESSAGE_TEXTおよびTYPE列を使用して、EBS_msgid2details.txtファイルに移入します。

容易に取得できるように、select文ではJDR_UTILSおよびJDR_MDS_INTERNALパッケージが使用されます。

N.11 アクション、ページおよびオブジェクト

各EBSフレームワークを分析して、すべてのヒットがオブジェクト・ヒットまたは、アクション・ヒットおよびページ・ヒットとして分類されるように正しい構成を得る必要があります。フレームワーク固有の考慮事項を次に示します。

OA

OAフレームワークは、M-V-C(Model-View-Controller)モデルを使用して構築されます。コントローラはHTTPレベルで確認できる部分であるため、RUEIに関連するのはコントローラのみです。コントローラは、特定のページを表示するか、またはそのページを構築する別の場所にビジターをリダイレクトするかを内部的に決定します。リダイレクトはRUEIの標準機能であり、自動的に認識されます。

URLパラメータに基づいてページ名が定義されます(リダイレクトの場合は、前のページのパラメータを含む元のURLではなく、リダイレクト先URLのURLを使用する必要があります)。コントローラの他に、このフレームワークには固定URL(OALogout.jspのようなコントローラをバイパスする)も含まれます。このようなファイルはJTTベース・ファイルと一緒に認識されます。

JTT

JTTフレームワークは、M-V-C(Model-View-Controller)モデルを使用して構築されます。すべてのアプリケーションに1つのコントローラがあるのではなく、アプリケーションごとに1つ(または複数)のコントローラがある点で、OAフレームワーク定義とは異なります。つまり、関連する.jspファイルの数が多く、関連するすべての.jspファイルの調査が必要になります。.jspファイルをサーバー側で分析すると、アプリケーション定義の判別が可能です(.jspファイルの場所に基づいて)。

N.12 関数エラー

デフォルトのRUEIインストールでは様々なタイプのエラーを認識できます。8.3.13.1項「コンテンツ・メッセージの説明の定義」を参照してください。これらはネットワーク・エラーおよびHTTPエラーです。また、事前定義済のコンテンツ・メッセージがすべての標準FRMおよびメッセージ・ディクショナリ・アイテム(つまり、接頭辞「APP_」を使用したメッセージ)に自動的に提供されます。デフォルトでは、タイプ「エラー」のメッセージのみがエラーとしてレポートされ、他のすべてのメッセージ・タイプ(「注意」や「ヒント」など)が通知としてレポートされます。Oracle Formsトラフィックの場合、個々のforms要素交換ですべての読取可能テキスト文字列から指定のコンテンツ・メッセージが検索されます。

メッセージ・ディレクトリのカスタマイズを作成した場合、create_EBS_info.plスクリプトを実行してRUEIインストールにマージすることをお薦めします。

運用上の理由で、メッセージID(APP-FND-01702など)が正規化されます(つまり、先頭のゼロが無視されます)。文字列の比較を実行する場合、このことを考慮する必要があります。

Oracle Formsエラーの原因

Formsセッション中に発生するエラーは、様々なレイヤーが原因となっている可能性があります。

- ネットワーク・エラーは、すべてのアプリケーションと同じ方法でRUEIでレポートされます。

- HTTPサーバー・エラー(500、404など)は、すべてのアプリケーションと同じ方法でRUEIでレポートされます。

- Formsサーブレット・エラー(サーブレット接続エラー)は、対応するifErrorコードと一緒にレポートされます。これは、Formsフレームワークで発生する内部通信エラーです。

N.13 Forms名のレポート

デフォルトでは、レポートされるForms名は、構成スクリプトでアップロードされたマッピングに基づいて、Formsウィンドウ・タイルから導出されます。ただし、環境変数FORMS_RUEI_SEND_FORM_NAMEが設定されている場合、Formsサーバーは、ウィンドウ作成メッセージとともにFormsモジュール名を送信します。デフォルトでは、環境情報がdefault.envファイルに設定されます。別のファイル名を使用できますが、これをformsweb.cfgファイルに指定する必要があります。これには、次のような利点があります。

- 同じウィンドウ・タイトルのトラフィック内の複数のForms名を区別できます。

- 追加のFormsの作成では、構成スクリプトの再実行が必要ありません(N.7項「RUEIとEBS本番環境の同期化」を参照)。

N.14 追加メッセージのレポート

Oracle Forms 11gリリース2(以上)では、MESSAGEビルトインの使用をサポートします。これにより、カスタマイズした文字列をフォームに含むことができます。これは、特にデバッグの目的に役立ちます。RUEI監視トラフィックでは、2つの定数をMESSAGEビルトインのuser_responseパラメータ内で使用できます。これらは、RUEI_BEGINおよびRUEI_ENDです。次に例を示します。

MESSAGE('my message1', RUEI_BEGIN);
...
...
MESSAGE('my message1' RUEI_END);

FormsサーバーがMESSAGEビルトインを処理する場合、RUEIがメモに含まれる情報を通知するため、メッセージを送信します。この情報は、セッション診断内に表示できます(第4章「セッション診断機能の使用」を参照)。メッセージはクライアントに表示されないので注意してください。

N.15 OAフレームワークでのページ名の推定

OAフレームワークの詳細は、次のサイトを参照してください。

http://www-apps.u s.oracle.com:1100/fwk/fwksite/510/devguide/ess/ess_state.htm

OAベースのトラフィックは次のようにRUEIにマッピングされます。

- コントローラは、ユーザーが開始するアクションのキー・インジケータとして使用されます。コントローラに密接に関連するヒットは、そのページの構成要素と仮定されます。OAフレームワークには、OA.jspとRF.jspという2つのコントローラがあります。

- ページの名前は、コントローラに送られるパラメータに基づいて付けられます。function_id、_rc、akRegionCode、OAFunc、pageおよびregionというパラメータが考慮されます。(新しい)フォームまたは職責への参照を含まないページは、前のページのフォーム名または職責を保ちます。

パラメータのマッピング

マッピングが可能なのは、監視対象のデプロイメントと一致するIDがEBS_*.txtファイルに含まれる場合のみであることに注意してください。正しい構成ファイルを取得するには、スクリプト(N.7項「RUEIとEBS本番環境の同期化」を参照)を使用してデプロイメント環境から正しい情報を取得します。

このスクリプトでは、関連する情報を取得するために次の2つの方法が使用されます。

- ローカルJSPファイルを分析して、すべてのJSPファイルの名前をJTT環境から取得します。これは、$APPL_TOPディレクトリでfind文を実行して行います。

- create_EBS_info.plスクリプトの一連のSQL文が、データベースからOAフレームワークの機能名を取得します。詳細設定は次の各項で説明します。

N.16 ページ・コンテキスト

すべてのアクションがページに関連するとは限りません。このため、この項ではアクション(HTTPリクエストなど)がどのようにページ・ビューとしてレポートされるかを説明します。

ページについてのリクエストが受信されるたびに、OAフレームワークはOAPageContextを作成します。これは新しいページの処理が完了するまで存続します。特に、OAPageBean(ページ処理の中心機能)によってOAPageContextが作成されます。

RUEIでのレポートは、HTTPレベルで確認されるリクエストに基づくことに注意してください。ページが1つのリクエスト内で変化する場合、計測された時間は元のページに対してレポートされます。

N.16.1 リクエストとページの境界

Webアプリケーションの作業ユニットは、リクエスト/レスポンスのペアです。ブラウザによってリクエストが送信され、サーブレットによってリクエストが処理され、レスポンスが戻されます。レスポンスの送信は、1つのリクエストの終了、または完了したリクエストと新規リクエストの間の境界を表します。同様に、OAPageBeanがあるページの処理を完了したとき、これは現在のページと新しいページの「境界」です。したがって、次のシナリオでユーザーがページXからページAに、次にページBにナビゲートする場合、ページXとページAの間およびページAとページBの間に2つのリクエスト境界があります。また、ページ境界も、ページXとページAの間およびページAとページBの間という概念的に同じ場所にあります。また、ページXとページA、およびページAとページBの間の概念上同じ場所に、2つのページ境界があります。図N-11にこれを示します。

図N-11 同じリクエスト境界とページ境界

異なるリクエスト境界とページ境界

ただし、状況によっては、リクエストとページの境界は同じではありません。次のJSP Forwardのケースについて考えてみます。

- 図N-11に示すようにユーザーがページXからページAにナビゲートします。

- ページAでユーザーが選択するコントロールが、レスポンスで表示するページを決める前にページAのコードを評価する必要があるというものです。このため、ブラウザはリクエストをページAに発行し、OAフレームワークがリクエストを処理します(ページのためのOAPageContextの作成など)。ページAで処理が完了すると、図N-12に示す最初のページ境界に到達します。

- ページAのコード内では、ユーザーがどのコントロールを選択したかを開発者が評価して、JSP ForwardをページBに発行します。OAフレームワークは、ページAを再表示しないためにこの時点ではHTTPレスポンスを送らず、ページBの処理を開始します(このページのための新しいOAPageContextの作成など)。ページBで処理が終了すると、2番目のページ境界に到達します。

- ここでページBをユーザーに表示する必要があるため、HTTPレスポンスがブラウザに送信されます。このときにリクエスト境界に到達します。

図N-12 異なるリクエスト境界とページ境界(JSP Forward)

N.17 データ・アイテム

表N-2に示すEBS固有のデータ・アイテムがRUEIでレポートされます。

表N-2 EBS固有のデータ・アイテム

項目

説明

1ページ当たりのデータベース時間(ミリ秒)

1ページ当たりのデータベース時間。

合計データベース時間(ミリ秒)

合計データベース処理時間。

EBSアクション

ユーザーによって実行されたアクションの説明(これは、フレームワークに基づいて決定されます)

EBSコンポーネント

アクティブ・コンポーネントの説明(このフレームワークで決定できる場合)

EBSフォーム階層

測定されたアクティビティ中にOracle Formsプロトコル内でアクティブだった要素のコンポーネント階層。

EBSフォーム・メッセージ

Oracle Formsメッセージの開始/終了を示す特定のプログラムされたメッセージに関連する情報。

EBSフォーム名

アクティビティに関連するOracle Formsの名前。

EBSフォーム名の説明

アクティブだったOracle Forms名の説明。

EBSフレームワーク

使用されるEBSフレームワーク。たとえば、FORMS (Oracle Forms traffic)、OA (Oracle Applicationフレームワーク)、JTT (JTTフレームワーク)、servlet (サーブレット)、other-traffic (未分類ページ設定が選択されている場合にのみ表示されます。実際のURLを表示するにはpage-URLを使用します)です。

EBS JSPファイル名

使用されるJSPベース・ファイルの名前。たとえば、ログインイベントまたはrunformsなどのアクションが含まれることがあります。

EBS Javaクラス

ユーザー・アクティビティに対してアクティブだったコンポーネントのクラス名。

EBSモジュール

エンド・ユーザーがナビゲートしていた場所のEBSモジュール。

EBSモジュール・コード

エンド・ユーザーがナビゲートしていた場所のEBSモジュール。

EBS職責

アクティビティ中にアクティブだった職責。

EBS職責ID

アクティビティ中にアクティブだった職責ID。

EBSユーザー入力

識別できる場合、アクティビティ中にユーザーが入力したリテラル・テキスト。

N.18 リソース

次の資料が役に立つ場合があります。

- OracleアプリケーションでSSLを使用するためのHTTPサーバーの構成(ノート341904.1)。

- Oracle Forms Service 10g: SSLでのトランスポート・レイヤー・セキュリティの構成(ホワイト・ペーパー)

- Oracle Application Server Forms Services利用ガイド10gリリース2(10.1.2)、5.11 Oracle Forms ServicesおよびSSL

- JPIクライアント(Sunプラグイン)のためにSSLを有効にする方法(ノート307429.1)。

N.19 既知の制限事項

現在、RUEIはEBSのすべての機能には対応していません。特に次の制約事項がすでに判明しています。

- Formsフレームワークにはレポートを作成する機能が含まれます。この機能ではユーザーが高度な構成を行うことができます。結果として、レポートを自動的に追跡することができません。また、レポートのために関連するビジネス指向名が含まれる便利な変換用の表もありません。解決方法としては、判明しているレポートURLを変換ファイルに基づいて正しいレポート名に記述し直すことしかできません。
この問題に関する補足情報ですが、一部のユーザーがjobs機能を使用してレポートを作成していることに注意してください。この方法は安全ではありません。前後の番号を簡単に推測できるため、権限を持たないユーザーがレポートを表示できる可能性があるためです。名前(数字のみ)がランダムであるため、このようなタイプのレポートの使用時にレポートに関するレポートを生成しても役に立ちません。

ここで説明した問題のために、Formsのレポートは監視されません。

- レポートは、最後にアクティブになった部分に基づいて行われます。したがって、1人のエンドユーザーが複数のブラウザ・ウィンドウで同時に参照しているとき、レポートされるページ名には正しくない情報が含まれることがあります。

- 現在、OAおよびJTTフレームワークに基づくアプリケーションしかサポートされません。このため、Oracle Applications Manager(OAM)やOracle Portalのようなパッケージは現時点ではサポートされていません。

- リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。これは、Oracle Formsベース・アプリケーションの場合に特に見られます。

N.20 トラブルシューティング

この項では、EBSアプリケーションを監視するときに特によく発生する問題について説明します。カスタマ・サポートに問い合せる前に、この項の内容を確認してください。

N.20.1 ネットワーク・トラフィックが測定されていないように見える

予期されるネットワーク・トラフィックがレポートされないように見える場合は、次の点を確認することをお薦めします。

- RUEIが、OA、JTT、PLS、Oracle Formsおよびサーブレット・フレームワークに基づくEBSアプリケーションを監視できること。一般的に、スイートはインストールごとに異なる特定のポートで実行するように構成されます。これもRUEIに指定する必要があります。「構成」→「セキュリティ」→「プロトコル」を選択します。定義されたポート設定を確認し、EBSアプリケーションの要件を満たすようにします。

- RUEIシステムでデータの受信が開始しても、自動的にレポートされないこと。最小でも1つのアプリケーションを定義する必要があります。このアプリケーションは、少なくとも関連するドメイン名と、そのドメイン内の一意のページIDスキームを含む必要があります。

- 監視対象のトラフィックにVLANカプセル化トラフィックが含まれる場合は、そのトラフィックがRUEIで構成されていることを確認します。「システム」→「構成」→「セキュリティ」→「ネットワーク・フィルタ」→「VLANトラフィック」を順に選択して、定義済の設定を確認します。この機能の使用方法の詳細は、13.4.2項「VLANフィルタの定義」に記載されています。

- EBSには、追加設定せずにセッション・トラッキングのために使用可能なCookieはないことに注意してください。したがって、Cookieはログイン・ページで作成される必要があります。このCookieがアプリケーション全体に対応します。デフォルトでは、Jession Cookieはアプリケーション・リンクのみに対応し、イメージ、CGIおよびライブラリには対応しません。oracle.uix Cookieはすべてのヒットに対応しますが、ビジターごとに一意ではありません。

- トラフィック・サマリー機能(「システム」→「ステータス」→「データ処理」の順に選択)はアプリケーション・ロジックに基づいているため、トラフィックの概要にはアプリケーション以外(スイート、サービス、SSOなど)のトラフィックは示されません。

EBSスイート定義を構成した後で、EBSアプリケーションにログインし、アプリケーションでクリティカル・パスを実行することを強くお薦めします。その後、RUEI内で記録されたアクションを検索し、セッション診断機能を使用して、アクションが正しくレポートされていることを確認します。具体的には、次のとおりです。

- 説明がレポートされ、コードはレポートされないことを確認します。アプリケーション名のかわりにコードまたはページグループ名のかわりにページグループ・レベルがレポートされる場合、create_EBS_info.plスクリプトから導出された情報が正常にアクティブ化されていません。

- 短いセッションが多数レポートされる場合は、Formsトラフィックが測定されていません。

- .jspファイルが多数レポートされる場合は、手動ページ・ネーミングの必要性を示します(ユーザーが必要とする場合)。

N.20.2 識別されないアクションが多数レポートされる

レポートされるトラフィックの大部分を識別されないアクションが占める場合、Formsの追跡が正常に機能していません。次の項目に注意する必要があります。

- ステータス・バーやテキストフィールドなど(図N-6を参照)が表示されない場合は、監視対象トラフィックの特定の特性が取得されていません。この場合は、カスタマ・サポートに問い合せてください。

- N.3項「監視の有効範囲の検証」の説明に従って、サーバー・ポートが正しく構成されていることを確認します。特に、これは通常のHTTPポートとしてではなく、Formsサーブレット・モード・ポートとして構成されている必要があります。

N.20.3 Formsのみの環境におけるuser-id識別の構成

formsプロトコルは通常のhttpトラフィック(RUEIのネイティブ)と同じではないため、formsのみの環境にuser-idソースを構成する場合は多少の知識が必要になります。この項では、このような環境でuser-idを構成する方法について説明します。

使用できるソースのタイプは2種類で、これらがクライアント・リクエストとして構成されている必要があります。

- Oracle Formsクライアント要素
formsの階層構造によって送信されるforms要素内の値です。

- Oracle Formsクライアント・プロパティ
user-idが含まれる、一意の名前を持つプロパティ。

user-idの構成に必要な情報はコレクタのログ(場所は次の例を参照)から取得されます。

$RUEI_DATA/processor/data/c_localhost/http/20130207/proc1/

このディレクトリにナビゲートし、すべてのファイルを対象にしてログイン・アクションを実行したユーザーを検索します。次はこのコマンドの例です。

zgrep paul http-201*.gz

次のような出力が生成されます。

2013/01/30:10:31:33:205   3       -        235.174.222.186 2949    -   10.161.124.51   80      POST    /forms/lservlet;jsessionid=1510821202615f4b6f7d688710fdd8f6c47
d629bcea4f11bfaf296ba87eda0c9.e3mLchuRax4Ne3eSc3yQbh4Mbi1ynknvrkLOlQzNp65In0      1.1     -
ORA_TAHITI_PREFS=86910bc3181a2b82;ORA_UCM_INFO=65241d61bd16d97d;ORA_UCM_VER=19df918e29822249;ORA_UCM_SRVC=0753cd488af8cbcb; WEB2000userid=fffcec715cd9b15b;scouser=dc87defb85e08290;
__utma=af4005efe0fdbb6f;__utmz=abb9352a6918ccb5;__qca=85a88405530a5b63;loginCookieDate=726b29c7e447ad61;checkerStorage=25660f1ee2708d50;s_nr=c6802213d9578355;s_cc=0036758e0041e45f;
s_sq=220c178208c68ade;ORASSO_AUTH_HINT=056febb7e15cabf6;gpv_p24=f252faefe6be2601;gpw_e24=f252faefe6be2601;ORA_ML_STATE=53b69c923b02dfdc;
ORA_ML_CLUSTER=7a0d1d9745276966;ORA_CSM_MODE=05cfeff006960dea;ORA_CSM_LOCALE=00000ca900000d42    nllx012.nl.oracle.com   -       -       Java1.3.1.26-internal   1376    31      0       0       1       200     application/octet-stream        -
Oracle-Application-Server-10g/10.1.2.2.0 Oracle-HTTP-Server     -       268     59189   127     366     494     3       -       -       -       -       -       -       0       0       2:0:3:51645090  -       -       &Pragma=6&User-Agent=Java1.3.1.26-internal&Content-Length=31    -       -       &cl_enc=X-none&sv_enc=X-none&url_enc=none
&LogonDialog.INDEX_LOGON_USERNAME_VALUE={val:paul;frm:no-form;hier:;class:LogonDialog;seqno:0039;name:;
i:INDEX_LOGON_USERNAME_VALUE}&LogonDialog.INDEX_LOGON_DATABASE_VALUE={val:;frm:no-form;hier:;class:LogonDialog;seqno:0039;name:;
i:INDEX_LOGON_DATA}   &hitinfo=no-selected-properties&form=Copyright (c) 1995-2009, Oracle Corporation&formtitle=Copyright (c) 1995-2009,
Oracle Corporation&form=Copyright (c) 1995-2009, Oracle Corporation&FormStatusBar.INDEX_STBAR_REMOVE_LAMPS={val:1;frm:no-form;hier:FormWindow-2.FormCanvas-3.;
class:FormStatusBar;seqno:4;name:;i:INDEX_STBAR_REMOVE_LAMPS} -       no-reply-body   other   274
dynamic -       235.174.222.186 -       -

要素とプロパティの区別

通常は前述の例で示したプロパティ要素の構成で間に合います。これは、user-idが含まれる引数(INDEX_LOGON_USERNAME_VALUE)をその他の要素(一般的にはINDEX_VALUE)と区別できるためです。プロパティ用の構成を行うには、次を設定します。

- ソース: Oracle Formsクライアント・プロパティ

- 値: INDEX_LOGON_USERNAME_VALUE

user-idが入力されるフィールドに一般名が付与されている場合があります。この場合、コレクタはこれをINDEX_VALUEというプロパティ名で記録します。これは次の例で確認できます。

2013/02/04:13:06:24:655    9    -    10.173.25.160    62439    -    10.62.38.50    8888    POST    /forms/lservlet;jsessionid=Bm1cRPkXdrdXTKYS9zy2nPjQCQn3WQY
FGHm1gWSCthY8ngWTxqty!1966339776    -    -    -    fefr1atp08.ods:8888    -    -
Mozilla/4.0 (Windows 7 6.1) Java/1.6.0_24    372    34    0    0    1    200    application/octet-stream    -    -    -    325    19    362    1    -    4    -    -    -    -    -    -    0    0    -    -    -    &Pragma=6&Content-Length=34    &X-ORACLE-DMS-ECID=004pEJg2tBjFs1l6wvjc6G0003gD00RG0X    -
&cl_enc=X-none&sv_enc=X-none&url_enc=none    &TextFieldItem.INDEX_VALUE={val:paul;frm:RE_FM_INICIO;hier:RE_FM_INICIO.FormCanvas-2.FormCanvas-3.;class:TextFieldItem;seqno:4;name:Enter value for Username;i:INDEX_VALUE}&TextFieldItem.INDEX_SELECTION=
{val:point_6_6;frm:RE_FM_INICIO;hier:RE_FM_INICIO.FormCanvas-2.FormCanvas-3.;
class:TextFieldItem;seqno:4;name:Enter value for Username;i:INDEX_SELECTION}&TextFieldItem.INDEX_CURSOR_POSITION={val:6;frm:RE_FM_INICIO;
hier:RE_FM_INICIO.FormCanvas-2.FormCanvas-3.;
class:TextFieldItem;seqno:4;
name:Enter value for Username;
i:INDEX_CURSOR_POSITION}&TextFieldItem.INDEX_SKEY={val:point_9_0;
frm:RE_FM_INICIO;hier:RE_FM_INICIO.FormCanvas-2.FormCanvas-3.;
class:TextFieldItem;seqno:4;
name:Enter value for Username;
i:INDEX_SKEY}    &TextFieldItem.INDEX_AUTOSCROLL={val:void;frm:RE_FM_INICIO;hier:RE_FM_INICIO.FormCanvas-2.FormCanvas-3.;
class:TextFieldItem;seqno:4;
name:Enter value for Username;
i:INDEX_AUTOSCROLL}&TextFieldItem.INDEX_AUTOSCROLL={val:***;frm:RE_FM_INICIO;
hier:RE_FM_INICIO.FormCanvas-2.FormCanvas-3.;
class:TextFieldItem;seqno:5;
name:Enter value for Password;
i:INDEX_AUTOSCROLL}    -    no-replay    other    62    dynamic    -    10.73.5.60    -    -    -

この場合は要素構成アイテムを使用する必要があります。入力されている値はforms内でのその要素までの階層パスです。

この値を検索するときには、次の例のような'sed'コマンドを使用すると便利です。

USER=paul; zgrep $USER http-201* |sed "s,^.*={val:${USER};[^}]*;hier:\([^};]*\);class:\([^};]*\);seqno:\([^;}]*\)[^}]*;i:INDEX_\([^;}]*\)[;}].*,found elem: \\1\\2-\\3.INDEX_\\4,g"
found elem: RE_FM_INICIO.FormCanvas-2.FormCanvas-3.TextFieldItem-4.INDEX_VALUE

構造の各要素の意味は、次のとおりです。

- USERは、事前に検出した完全ログイン名です。

- zgrep $USER http-201*は読み取るファイルの名前です。

- found elemは結果です。

このパラメータに次の値を設定します。

- ソース: Oracle Formsクライアント要素

- 値: RE_FM_INICIO.FormCanvas-2.FormCanvas-3.TextFieldItem-4.INDEX_VALUE

N.20.4 create_EBS_info.plスクリプトでFRM-91500エラーがレポートされる

create_EBS_info.plスクリプトをUNIXシステムで実行すると、次のエラーが複数回レポートされます。

FRM-91500: Unable to start/complete the build.

これは、frmbatchスクリプトがユーザー・インタフェースにアクセスできないために発生します。次の項目に注意する必要があります。

- DISPLAY変数が正しく設定されていることを確認します。これはxclockまたはxeyesなどX Window Systemのツールを使用して確認できます。また、別のサーバーのX Windows Systemを使用できるようにするSSHのXフォワードも検討してください。

- frmcmp_batchスクリプトは、X Windows Systemなしで機能しようとします。これは、create_EBS_info.pl構成スクリプトで使用される最初のスクリプトです。次のコマンドを使用して表示モードを設定します。

$ set ORACLE_TERM=vt220; export ORACLE_TERM

N.20.5 PerlのZip機能が使用できない

一部のシステムではzip機能はPerlパッケージと一緒にインストールされません。この場合は次のメッセージが表示されます。

The Archive::Zip package is not available on this system.

このメッセージの後で、サンプル・コマンドによってアーカイブの作成方法が示されます。アーカイブには空のファイルを含めないこと、およびファイルをディレクトリに入れないことに注意してください。これらに違反すると、RUEIにアップロードできません。または、適切なディレクトリでコマンドzip EBS_*txtを実行することもできます。

N.20.6 frmcmp_batchスクリプトが失敗する

frmcmp_batchスクリプトが不明なエラーで失敗し、次のようなレポートが生成されます。

execution of 'frmcmp_batch module=XXX/XXX/XXX.fmb module_type=form batch=yes logon=no forms_doc=yes strip_source=yes build=no output_file=/tmp/XXX.txt' failed: 11. Ignoring /XXX/XXX/XXX.fmb

これは、レポートされた.fmbファイルが.txt形式に変換できなかったこと(おそらくは破損のため)を示しています。すべての.fmbファイルのうち少数のみがレポートされる場合は、問題ありません。実際、レポートされたフォームは本番環境で機能しない可能性が高いためです。ただし、レポートされたフォームをWebサイトのビジターが頻繁に使用しており、異常がないことがわかっている場合は、この問題をレポートしてください。このとき、関連する.fmbファイルと一緒に、EBS環境でのファイルのデプロイ方法がわかる情報も提供してください。

N.20.7 create_EBS_info.plスクリプトで警告/エラーが生成される

create_EBS_info.plスクリプトを実行しているときにエラーまたは警告(あるいは両方)を受け取った場合は、エラーや警告の種類に応じて次のようにします。

- データベース関連:

- 次のコマンドを発行して、create_EBS_INFO.plスクリプトに指定されているconnectstringを確認します。

sqlplus connectstring @temporarysqlfile

- Forms関連:

- frmcmpまたはfrmcmp_batchが正常に機能していません。この問題のトラブルシューティング情報の詳細は、「ノート266731.1」(https://support.oracle.com/CSP/ui/flash.html)を参照してください。

- frmcmpまたはfrmcmp_batchがsig 11セグメント・エラーを返します。これはGRDDHIST.fmbについて発生することがわかっています。

脚注

脚注1:このスクリプトは、本番環境と同じであれば検収環境でも実行できます。

O JD Edwardsのサポート

この付録では、JD Edwards EnterpriseOneアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。このサポートの対象となるのは、有効なApplication Management Suite for JD Edwards EnterpriseOneライセンスを所有している場合に限られることに注意してください。詳細は、オラクル社の担当者に問い合せてください。

O.1 概要

このバージョンで提供される監視のサポートは、JD Edwards Toolsバージョン8.97および8.98とJD Edwardsアプリケーション・バージョン8.12.に基づくJD Edwardsインストールに対して検証されています。ただし、このToolsバージョンで実行するJD Edwardsアプリケーション・バージョン8.11および9.0にも対応しています。

O.2 監視の有効範囲の検証

多くの場合、JD Edwardsソフトウェアは標準以外のポート(800など)を使用するように構成されます。JD Edwardsインストールが実行しているポートを確認するには、ログインURLを調べてください。これは次の形式になっています。

http(s)://hostname:portnumber/jde/...

portnumberが定義済ポートの1つとして構成されていることを確認します(HTTPまたはHTTPS)。また、HTTPSポートが指定される場合は、WebサーバーのSSL秘密鍵のコピーをコレクタ・システムにインポートするようにしてください。

O.3 JD Edwardsスイート定義の作成

JD Edwardsベースのアプリケーションのスイート定義を作成できます。作成方法は、サポートされている他のOracle Enterpriseアーキテクチャの場合と同じです。スイートを作成する手順は、10.1項「スイートの使用」に記載されています。

O.4 create_JDE_info.shスクリプトの実行

ご使用の環境でRUEIがJD Edwardsのビジネス・ロジックを正しく変換できるようにする手順は、次のとおりです。

1. create_JDE_info.shスクリプトをJD Edwardsサーバーのホーム・ディレクトリにコピーします。これはRUEIシステムの/var/opt/ruei/processor/local/download/JDEディレクトリにあります。

2. JD Edwardsサーバーで任意のユーザーとしてcreate_JDE_info.shスクリプトを実行します。脚注1このスクリプトは、環境で識別されたページIDにIDを割り当てます。create_JDE_info.shスクリプトは次の必須パラメータを指定して実行してください。

create_JDE_info.sh connect-string

connect-stringは、JD Edwardsデータベースへのスクリプトのアクセスを許可するために使用する文字列です。スクリプトはスキーマを読み取り、現在のディレクトリに.txtファイルを生成します。次に例を示します。

create_JDE_info.sh "sys/oracle@dliild-jde:1522 as sysdba"
create_JDE_info.sh "sys/oracle@JDE as sysdba"

接続文字列はデータベースに対して「sys as sysdba」として認証される必要があることに注意してください。スクリプトは、使用される様々な表の正しいスキーマを検出しようとするためです。

3. 10.1.2項「構成ファイルのアップロード」で説明している手順を実行し、生成されたファイルをレポータ・システムにアップロードします。

O.5 Cookieテクノロジの確認

JD Edwardsスイート・インスタンスを作成すると、JD Edwards環境用の事前定義済Cookieが自動的に作成されます。これは、JSESSIONIDという名前のカスタムCookieとして実装されます。多くの場合、このCookieはご使用のJD Edwards環境に適しています。ただし、環境の構成によってはそれを変更する必要があります。また、RUEIによって、完了したセッションのユーザーを監視および追跡するには、Cookieのパスを「/」に設定する必要があります。

Cookieの構成の確認

Cookieの構成を確認する手順は、次のとおりです。

1. ブラウザですべてのCookieを消去します。

2. JD Edwardsアプリケーションに(再)ログインします。

3. JD Edwardsでいくつかのページを表示します。

4. ログアウトします。

5. 少なくとも10分間待機します。

6. RUEIレポータ環境を開きます。

7. 「データの参照」を選択し、「すべてのセッション」グループを開いて「セッション診断」を選択します。記録されたセッション(ユーザーID別または時間別)を探します。アプリケーションについてフィルタリングできます。

8. セッションを開いて、次の点を確認します。

- ログイン以外のページ・ビューがレポートされていること。これで、セッションIDがログイン後に保存されていることが確認されます。

- 少なくともある程度のJD Edwardsアプリケーション・アクティビティが記録されていること。

すべてのヒットが同じCookieに関連していない場合(これらは匿名ページとしてレポートされる)、問題がある場所を調べて、適切な方法で解決することをお薦めします。たとえば、Cookieのドメインまたはパスのオプションを調べます。

O.6 ホスト名およびURL接頭辞

JD Edwardsの実装およびJD Edwardsのインスタンスはホスト名で識別できます。一般的に、JD Edwardsスイートにアクセスする方法は2つあります。ホスト名のみを使用する方法、または完全修飾ホスト名(ドメインを含む)を使用する方法です。通常はドメインのみを指定してください。

O.7 データ・アイテム

表O-1に示すJD Edwards固有のデータ・アイテムがRUEIでレポートされます。

表O-1 ディメンション

項目

説明

JD Edwardsアクション

フォームまたはアプリケーションでユーザーがアクションを実行します。これらのアクションが監視され、ここでレポートされます。(JD Edwardsのほとんどのアクションはエンコードされます)。

JD Edwardsアクション・コード

フォームまたはアプリケーションでユーザーがアクションを実行します。これらのアクションが監視され、ここでレポートされます。(JD Edwardsのほとんどのアクションはエンコードされます)。

JD Edwardsアプリケーション

使用されるJD Edwardsアプリケーションの名前。JD Edwardsのアプリケーション名は、アプリケーション・コード(P...)とJD Edwardsデータベース構成に基づきます。これにより、セッション中に監視される様々なアプリケーションを区別することができます。

JD Edwardsアプリケーション・コード

使用されるJD EdwardsアプリケーションのID。JD Edwardsのアプリケーション名は、アプリケーション・コード(P...)とJD Edwardsデータベース構成に基づきます。これにより、セッション中に監視される様々なアプリケーションを区別することができます。

JD Edwards環境

ユーザーがJD Edwardsにログインしたときに選択した環境。

JD Edwardsフォーム

使用されるJD Edwardsフォームの名前。JD Edwardsのフォーム名は、フォーム・コード(W..)とJD Edwardsデータベース構成に基づきます。これにより、セッション中に監視される様々なフォームを区別することができます。

JD Edwardsフォーム・コード

使用されるJD EdwardsフォームのID。JD Edwardsのフォーム名は、フォーム・コード(W.)とJD Edwardsデータベース構成に基づきます。これにより、セッション中に監視される様々なフォームを区別することができます。

JD Edwards製品

使用されるJD Edwards製品。JD Edwardsアプリケーションは、ここに示される製品の一部です。JD Edwards製品は、システム・コードすなわち製品コードで参照されることがあります。

JD Edwards製品コード

使用されるJD Edwards製品。JD Edwardsアプリケーションは、ここに示される製品の一部です。JD Edwards製品は、システム・コードすなわち製品コードで参照されることがあります。

O.8 既知の制限事項

現在、RUEIはJD Edwardsのすべての機能には対応していません。特に次の制約事項がすでに判明しています。

- レポートは、最後にアクティブになった部分に基づいて行われます。したがって、1人のエンド・ユーザーが複数のブラウザ・ウィンドウで同時に参照しているとき、レポートされるページ名に間違った情報が含まれることがあります。

- 現在、create_JDE_info.shスクリプトはUNIX JD Edwardsサーバーでしか実行できません。

- create_JDE_info.shスクリプトを実行するときに無効な接続文字列が指定されていても、エラーがすぐにはレポートされません。[Enter]を数回押すとエラーがレポートされます。

- ユーザーが複数のアプリケーションを同時に開始すると、起動されたアプリケーションの1つについて、アプリケーション起動ページのロード時間とサーバー時間の記録が正しくない場合があります。

- リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。

脚注

脚注1:このスクリプトは、本番環境と同じであれば検収環境でも実行できます。

P Oracle Fusion Applicationsのサポート

この付録では、Oracle Fusion Applicationsスイートの一部として使用できるアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。

P.1 概要

RUEIでは、追加設定なしでOracle Fusion Applicationsスイートの一部として使用できるモジュールおよびコンポーネントを監視することができます。たとえば、Oracle Fusion Customer Relationship Management (CRM)およびOracle Fusion Human Capital Management (HCM)などです。これらのアプリケーションを自動的に発見し、ネットワーク・オブジェクトをビジネス・ファンクションに変換します。

http://www.oracle.com/us/products/applications/fusion/index.htm

P.2 Oracle Fusion Applicationsスイート定義の作成

他のサポートされているOracle Enterpriseアーキテクチャと同様に、Oracle Fusion Applicationsアプリケーションのスイート定義を作成できます。スイートを作成する手順の詳細は、10.1.1項「スイート定義の作成」に記載されています。

デフォルトのセッション・トラッキングCookieは、デプロイメントで使用されるデフォルト・スキーマに依存しています。通常Cookieには、名前のどこかにFND_SESSIONが含まれています。また、RUEIによって、完了したセッションのユーザーを監視および追跡するには、Cookieのパスを「/」に設定する必要があります。Oracle ADFアプリケーションが、状態の追跡のために別のCookie名を使用する場合は、それを反映するようにアプリケーション定義を更新する必要があります。また、ユーザー名の認識はuserid構造に基づくことに注意してください。Cookie構成の詳細は、12.2項「セッション・トラッキング・メカニズムの指定」を参照してください。

P.3 create_FUS_info.plスクリプトの実行

ご使用の環境でRUEIがOracle Fusionビジネス・ロジックを正確に変換できるようにするために、次の手順を実行してください。

1. create_FUS_info.plスクリプトをOracle Fusionサーバーのホーム・ディレクトリにコピーします。これはRUEIシステムのRUEI_DATA /processor/local/downloadディレクトリにあります。

2. Oracle Fusionサーバーで任意のユーザーとしてcreate_FUS_info.shスクリプトを実行します。脚注1 このスクリプトは、環境で識別されたページIDにIDを割り当てます。create_FUS_info.plスクリプトは次の必須パラメータを指定して実行してください。

create_FUS_info.pl connect-string

connect-stringは、Oracle Fusionデータベースへのスクリプトのアクセスを許可するために使用する文字列です。スクリプトはスキーマを読み取り、現在のディレクトリに.txtファイルを生成します。次に例を示します。

create_FUS_info.pl "sys/oracle@myshop-fus:1522"
create_FUS_info.pl "sys/oracle@FUS"

FND_APPL_TAXONOMY_VLおよびFND_APPL_TAXONOMY_HIERARCHY表を使用して製品名を取得することに注意してください。これから製品ファミリが導出されます。レポートされるビューIDは、レスポンスのAdf-View-Id HTTPヘッダーから導出されます。このヘッダーが関連するヒットで見つからない場合、RUEIはクリックに関連するヒットのURLからビューIDの取得を試行します。

3. 10.1.2項「構成ファイルのアップロード」で説明している手順を実行し、生成されたファイルをレポータ・システムにアップロードします。

P.4 関数エラー

事前定義済のコンテンツ・メッセージは、すべての標準Oracle Fusion Applicationメッセージに自動的に提供されます。これにより、タイプ(メッセージまたはエラー)およびレポートをカスタマイズできます。表P-1に示すエラー・タイプがサポートされます。

表P-1 事前定義済のFusionエラー・タイプ

型

型

型

型

型

ADFF_BIND-

TPC-

WCS-

UIX-

SSLCFG-

BIACM-

CFGFWK-

ADF_TRIND-

OHS-

OAMAP-

FRC-

BDSS-

OID-

FRM-

ASCRS-

ADF-MNC-

DVT-

BI-DCBEANS-

BI-PLUS-

OAMCFG-

ODV-

STS-

ADFDI-

TRS-

BI-POPVD-

BI-EUL-

IAU-

TCM-

RCS-

HELP-

PKI-

OAMSSA-

BI-PDFRDR-

UCM-CS-

BI-VIEWER-

OSSOIAP-

ODSM-

RUL-

FED-

ADF_FACES-

BAM-

BI-DCWBSVC-

DMS-

DFW-

BI-SVR-

P.5 データ・アイテム

表P-2に示すOracle Fusion Applications固有のデータ・アイテムは、RUEIによってレポートされます。

表P-2 Oracle Fusion Applications固有のデータ・アイテム

項目

説明

Fusionコンポーネント

前のエンドユーザー・アクションによってアクティブになった構成要素の表示名。

FusionコンポーネントのクライアントID

エンドユーザーが前のページでクリックした構成要素の一意のID。

Fusionコンポーネント・タイプ

前のエンドユーザー・アクションによってアクティブになった構成要素の種類。

Fusionコンポーネント・タイプ・クラス

前のエンドユーザー・アクションによってアクティブになった構成要素のID。

Fusionコンテキスト・ルート

エンドユーザー・アクションでアクティブだったコンテキスト・ルート(最上位ディレクトリ)。

Fusionイベント・タイプ

このヒットによってトリガーされたアクションのタイプ(表示、アクション、ダイアログ、フォーカス、ディスクロージャ、起動、問合せ、ソート、valueChangeなど)。

Fusion製品

エンドユーザー・アクションでアクティブだったFusion製品の名前。この値は、ファイルをマップすることでviewIdから導出されます。

Fusion製品コード

エンドユーザー・アクションでアクティブだったFusion製品の短縮名。この値は、viewIdから導出されます。

Fusion製品ファミリ

エンドユーザー・アクションでアクティブだったFusion製品ファミリの名前。この値は、ファイルをマップすることで製品の短縮名から導出されます。

Fusion製品ファミリ・コード

エンドユーザー・アクションでアクティブだったFusion製品ファミリの短縮名。

Fusionリージョン

エンドユーザー・アクションでアクティブだったリージョン(タスクフローと同じソースregionViewIDから導出されます)。

Fusionタスク・フロー・コード

エンドユーザー・アクションでアクティブだったタスクフロー(リージョンと同じソースregionViewIDから導出されます)。

FusionビューID

前のエンドユーザー・アクションが行われた画面の一部のViewID識別子(部分用)。

これらのデータ・アイテムの詳細は、次の場所から入手可能な『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/title.htm

P.6 既知の制限事項

現在、RUEIではOracle Fusion Applicationsのすべての機能はサポートされません。特に次の制約事項がすでに判明しています。

- ページ・パフォーマンスをトレースするため、RUEIではPPRGETが必要です(12371586)。

- クライアントIDは、必ずしも正しくレポートされません(12944375)。

- リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。

脚注

脚注1:このスクリプトは、本番環境と同じであれば検収環境でも実行できます。

Q NATトラフィックの監視

この付録では、RUEIシステムをネットワーク・アドレス変換(NAT)デバイスの後に配置した場合に、どのようにして正確なネットワーク・トラフィック・レポートを作成できるかについて説明します。

Q.1 NATデバイスの前への配置

『Oracle Real User Experience Insightインストレーション・ガイド』で説明しているように、RUEIでネットワーク・トラフィックのコピーを確認できることは非常に重要です。これは、コピー/SPANポートまたはTAPデバイスを使用して取得できます。

図Q-1に、カスケード接続されたデバイスの代表的構成を示します。実際には、デバイス数ではこの図と異なる場合があっても、接続の順序は一般にこの図に示すとおりです。ファイアウォール、SSLオフローダ(SSL暗号化トラフィック)およびロード・バランサ機能は、1つまたは2つのコンポーネントに組み込まれています。

図Q-1 監視対象デバイスの配置

ほとんどのネットワークでは、監視対象となる位置は、ファイアウォールのすぐ後ろ(またはすぐ前)、SSLオフローダのすぐ後ろ、およびロード・バランサのすぐ後ろの3つがあります。これらを図Q-1に示します。これら3つの監視対象位置の意味を表Q-1に示します。

表Q-1 監視対象位置の特性

位置

サーバー/情報が使用可能か

クライアント/情報が使用可能か

SSL証明書が必要か

1

ヘッダーでの応答に入れる場合のみ

はい

はい脚注1

2

ヘッダーでの応答に入れる場合のみ

はい

いいえ

3

はい

NATデバイスからリクエスト・ヘッダーに入れて配信された場合のみ

いいえ

脚注1 SSLオフロード・ポイントの前に配置する場合は、SSL鍵をRUEIコレクタ・システムにアップロードする必要があります。これは、RUEIがSSLトラフィックを復号化できるようにするために必要です。

インターネット・サービスの場合、ロード・バランサは、外部クライアントがサービスにアクセスするために接続するポートをリスニングします。ロード・バランサはリクエストをバックエンド・サーバーの1つに転送し、通常、バックエンド・サーバーがロード・バランサに応答します。これにより、内部では機能が分離されていることをクライアントが認識していない場合でも、ロード・バランサがクライアントに応答できるようになります。また、クライアントによるバックエンド・サーバーへの直接アクセスを防止し、社内ネットワークの構造が隠されるため、セキュリティ上の利点もあります。

RUEIシステムをネットワーク・アドレス変換(NAT)デバイスの前に配置することをお薦めします。これにより、RUEIが即座に適用され、エンドユーザーの発信元IPアドレスをTCPレベルで確認します。図Q-1に示す構成はネットワークによって異なりますが、NATを実行するのは一般にロード・バランサ・デバイスです。

IPアドレス変換がすでに行われたネットワーク・セグメントにRUEIをデプロイしていて、次の項で説明する構成手順を実行していない場合は、NATデバイスの単一IPアドレスのみがエンドユーザーのIPアドレスとしてレポートされます。これは、レポートされるデータの正確性には悪影響を与えませんが、地理的なクライアント情報およびISPのクライアント情報が使用できなくなることを意味します。

注意:
RUEIの監視位置は常にVPN/解凍デバイスよりも後ろである必要があります。これは、RUEIが暗号化デバイスと復号化デバイスの間のHTTP以外のトラフィックを読み取ることができないためです。

注意:
デバイスが異なるとRUEIデータ収集に対する影響も異なり、監視位置によってはネットワーク・パフォーマンス・メトリックまたはサーバー・パフォーマンス・メトリックのデータが失われる場合があります。一般に、図Q-1の位置1の場合にクライアント・ネットワーク・パフォーマンス・データが最高になり、位置3の場合にサーバー・ネットワーク・パフォーマンス・データが最高になります。たとえば、RUEIの場所として位置3を使用することにした場合、ページがクライアント・ブラウザに配信される前にページ配信の測定が行われることがあります。この場合、RUEIで間違った(短すぎる)ネットワーク時間がレポートされることがあります。

Q.2 エンドユーザーのIPアドレスの取得

前述したように、発信元のエンドユーザーのIPアドレスを取得することは、正確な地理上のクライアント・レポートおよびISPによるクライアント・レポートを作成するために必要です。RUEIでは、IPアドレスは通常、クライアントから送信されたIPヘッダー・パケットから取得されます。IPパケットには、パケットの送信元および送信先の数値アドレスが含まれます。ただし、RUEIをNATデバイスの後ろに配置している場合は、このIPパケットにはエンドユーザーのIPアドレスでなくNATデバイスのIPアドレスが含まれます。

ただし、発信元の(エンドユーザー)IPアドレスは通常、NATデバイスからWebサーバーに送信されたHTTPヘッダーに保存されています。このような場合は、IPパケットでなくこのヘッダーの中でIPアドレスを検索するようRUEIに指定できます。

IPパケットではなくHTTPヘッダーを使用するように指定する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「アプリケーション」の順に選択します。目的のアプリケーションをクリックします。または、目的のスイートかサービスを選択します。概要が表示されます。

2. 「拡張」タブ→「クライアントIP」タブの順にクリックします。

3. ヘッダーが定義されていない場合は、「HTTPヘッダーの指定」項目をクリックします。または、「編集」をクリックします。図Q-2のダイアログが表示されます。

図Q-2 クライアントIPソースの編集

4. 追加するヘッダーの「タイプ」を選択します。HTTPヘッダーはHTTPリクエストから導出され、TCPヘッダーはTCPオプション・フィールドから導出されます。現在使用可能なTCPヘッダーはAkamaiのみで、SSL暗号化トラフィックの転送時に使用されます。

5. 「ヘッダー」フィールドを使用して、クライアントIPアドレスの取得元のリクエスト・ヘッダーを指定します。次に、「追加」をクリックします。ヘッダーが複数ある場合は、「上に移動」と「下に移動」コントロールを使用して、試行される順序を指定します。図Q-2に示す例では、Akamaiヘッダーが最初に検索されます。ない場合は、HTTP proxyのクライアントIPヘッダーが使用されます。次に、「保存」をクリックします。

クライアントIPアドレスを指定したリクエスト・ヘッダーから導出できない場合、IPヘッダー・パケットから取得されます。クライアントIPアドレス・ソース設定は、変更すると5分から10分後にRUEI内に表示されます。また、変更は履歴データにでなく現在収集されているデータにのみ適用されます。RUEIがNATデバイスの後ろにデプロイされている場合は、アプリケーション管理チームおよびインフラストラクチャ管理チームとともに、適切な方法でHTTPヘッダーからエンドユーザーのIPアドレスが収集されているかどうかをチェックおよび検証することをお薦めします。

Q.3 応答するWebサーバーのIPアドレスの取得

応答するサーバーのIPアドレスを確認することも、役に立つ場合があります。たとえば、サーバー・ファームでページが低速か失敗しているという問題が発生した場合、関連するサーバーのIPアドレスが即座に確認可能であれば、この問題の解決までの時間は大幅に短縮されます。

これは、ロード・バランサに返信されるヘッダーに、応答するサーバーのIPアドレス(またはその他のID情報)を挿入すると確認できます。

図Q-3にHTTPヘッダーの例を示します。これは、Mozilla FirefoxのLive HTTP headersプラグインのものであり、元のWebサーバーのID(www236)がHTTPヘッダーに移送された様子を示しています。

図Q-3 HTTPヘッダーの例

この例におけるヘッダーの要素名はxserverです。これはカスタム・ディメンションを使用して取得できます。この詳細は、3.12項「カスタム・ディメンションの使用」に記載されています。

R 監視対象ネットワーク・トラフィックの確認

この付録では、TCP診断機能を使用して、目的のすべてのネットワーク・トラフィックをRUEIが認識していることを確認する方法を説明します。ネットワークが変更された後には、収集したネットワーク・トラフィックを組織のネットワーク・エンジニアが検証することを強くお薦めします。

R.1 概要

TCP診断ユーティリティでは、選択したコレクタが認識するネットワーク・トラフィックの1分間のスナップショットを作成できます。このスナップショットを使用すると、予期していたトラフィック・フローとの差がないかどうかを判別できます。たとえば、構成されていないポート番号や、間違って指定されたVLAN IDが存在する場合があります。

TCP通信は、ポート番号やVLAN IDはもとより、クライアントやサーバーのIPアドレスおよびMACアドレス全体にわたって分析できます。ネットワーク・トラフィック情報に関する各スナップショットの有効範囲を図R-1に示します。

図R-1 ネットワーク・トポロジの例

R.2 トラフィックのスナップショットの作成

TCPトラフィックのスナップショットを作成する手順は、次のとおりです。

1. 「構成」機能でコレクタ・ステータスの表示アイコンをクリックします。または、「システム」→「ステータス」→コレクタ・ステータスの順に選択します。図R-2に示す「ネットワーク・データ・コレクタ」ウィンドウが開きます。この詳細は、Oracle Real User Experienceユーザーズ・ガイドに記載されています。

図R-2 ネットワーク・データ・コレクタ

2. 目的のコレクタをクリックします。「システム(ローカル・ホスト)」項目は、レポータ・システムで実行されているコレクタ・インスタンスを表します。ネットワーク内の他のコレクタは、IPアドレスで表します。

3. 「TCP診断」タブをクリックします。例R-0に示すようなパネルが表示されます。

図R-3 TCP診断

4. ツールバーの「新規スナップショット」アイコンをクリックします。図R-4に示すダイアログが表示されます。

図R-4 「新規TCPトラフィック・スナップショット」ダイアログ

5. 「フィルタの適用」チェック・ボックスを使用して、トラフィックのスナップショットを作成するときに、選択したコレクタで認識されるすべてのトラフィックをレポートするか、コレクタで現在定義済のフィルタに合うトラフィックのみをレポートするかを指定します(13.4項「ネットワーク・フィルタの定義」を参照)。これらのフィルタはダイアログの下半分に表示されます。ツールバーの「スナップショット・フィルタの表示」アイコンをクリックして表示することもできます。次に、「スナップショットの作成」をクリックします。

注意:
RUEIインストール内の全コレクタ・システムにわたるトラッフィック・スナップショットの最大数は15です。この最大数に達すると、一番古いスナップショットが新しく作成されたスナップショットに自動的に置き換えられます。

6. スナップショットが作成されるときに1分間の遅延があります。完了すると、新たに作成されたスナップショットの概要が表示されます。例を図R-5に示します。

図R-5 TCPトラフィック・スナップショットの概要

R.3 トラフィック情報の分析

作成されたトラフィック・スナップショットを分析する手順は、次のとおりです。

1. 目的のスナップショットをスナップショットのメニューから選択するか、TCP診断のメイン・パネル(図R-3を参照)でクリックします。フィルタを適用して作成したスナップショットは、「フィルタ済」列にチェック・マークが表示されます。チェック・マークをクリックすると適用されたフィルタを表示できます。

2. (図R-5に示すような)選択したスナップショットの概要が表示されます。選択できる項目をクリックすると、その項目についてフィルタリングできることに注意してください。たとえば、レポートされる項目のリストを、特定のサーバーIPアドレスを含むものに限定する必要がある場合などです。フィルタを削除するには、パネルのフィルタ・セクションでフィルタの横の「削除」アイコンをクリックします。
オプションとして、スナップショット・メニューの右側のソート・メニュー(図R-6を参照)を使用して、表示される項目で使用される第1列を選択します。

図R-6 ソート・メニュー

3. 図R-5に表示される「ステータス」列に、スナップショットの際に監視対象のTCPトラフィックに問題が存在していたかどうかが示されます。失敗ステータスがレポートされている場合は、「ステータス」アイコンにマウスを置くと追加情報が表示されます。考えられる問題で確認されているものを、表R-1で説明します。

表R-1 問題および考えられる原因の識別

ステータス

説明

クライアント/サーバーのパケット比率が高すぎます。

クライアント・パケット数がサーバー・パケット数に対して異常に多いように思われます。これは、コレクタがトラフィックの両方の方向を確認できない(または一方向で重複したトラフィックを認識している)ことを意味します。または、サーバーに関連する問題(たとえば、オフされている)があることを示します。

サーバー/クライアントのパケット比率が高すぎます。

サーバー・パケット数がクライアント・パケット数に対して常に多いように思われます。これは、コレクタがトラフィックの両方の方向を確認できない(または一方向で重複したトラフィックを確認している)ことを意味します。または、クライアントに関連する問題(たとえば、認識されないサーバー・パケット)があることを示します。

分析のためのサーバー・パケットとクライアント・パケットの数が不足しています。

信頼のおけるクライアントとサーバーの比率分析を実行するにはトラフィック(TCPパケット)が十分ではありませんでした。少なくとも100パケットが必要です。サーバーへの通常のトラフィック・レベルが低い可能性があります。または、RUEIでのルーティングの問題のため、ネットワーク・トラフィックの一部分を認識できない可能性もあります。

サーバーのVLAN IDがクライアントのVLAN IDと一致しません。

これは通常はルーティングの問題を示します。たとえば、クライアントからサーバーへのトラフィックがあるVLANを介してルーティングされるが、サーバーからクライアントへのトラフィックは別のVLANを介してルーティングされます。RUEIで一度に監視できるトラフィックは、1つのVLANセグメントのみであることに注意してください。

S エンリッチ・データのエクスポート機能

この付録では、エンリッチ・データ交換機能の使用方法について説明します。これには、操作の説明および使用されるデータベース表の構造が含まれます。

S.1 エンリッチ・データのエクスポート

エンリッチ・データ交換機能を使用すると、RUEIで収集されたデータを他のデータ・ソースと組み合せることができます。それには、カスタマ・リレーションシップ・マネジメント(CRM)システムやビジネス・インテリジェンス(BI)システムなどが含まれます。この機能を使用すると、独自のBIツールを使用したWeb環境のカスタマイズ分析を実現したり、RUEIで収集された様々なデータをオフライン・データと統合して、売上や収益の拡大要因について確実に把握できます。

この機能は、1分間ごとに収集されたデータをデータベースにエクスポートします。デフォルトでは、レポータが使用するものと同じデータベース・インスタンスにデータがエクスポートされます。ただし、エンリッチ・データのエクスポートには、別のデータベース・インスタンスを構成することを強くお薦めします。エクスポート・データベース内のデータへはSQLを使用してアクセスできます。その手順の詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。

エクスポートに使用できるデータとは

ネットワーク・トラフィックの監視中に取得される情報は、レポートおよびデータ・ブラウザで使用できます。概して、2つのタイプの情報(アプリケーション関連情報およびサービス関連情報)が含まれます。タイプごとに、様々なディメンションの詳細情報を使用できます。

RUEIでは、ユーザーの操作性に関するデータ収集の他に、KPIデータをカスタマイズ分析用にエクスポートすることも可能です。この機能を使用すると、ネットワーク環境およびビジネス・クリティカルなアプリケーションのパフォーマンスについて掘り下げて分析できます。

この項で後から説明するように、エクスポートされるデータの内容をカスタマイズして、RUEIでは通常収集されない情報を含めることができます。たとえば、ビジターの買い物カゴの内容または値などです。

エクスポートされたデータの利用状況の制御

エクスポート・データベースで使用可能なデータ量は、定義されたレポータのデータ保存ポリシーにおけるエンリッチ・データ交換の保存設定で制御されます。この詳細は、12.10.1項「レポータの保存ポリシーの定義」で説明します。エクスポート・データベースで使用するデータベース表の構造は、付録S「エンリッチ・データのエクスポート機能」に記載されています。アクセス

エンリッチ・データ交換を使用したBI実装の例

この項では、エンリッチ・データ交換機能を使用してデータを利用するBIソリューションの概要を示します。ここでは、Oracle Business Intelligence基盤(Oracle Fusion Middleware製品ファミリの一部)が使用されます。その構造の概略図を図S-1に示します。

図S-1 データ・ウェアハウスのステージング領域の概略図

フレームワークはOracle Warehouse Builder(OWB)に基づきます。RUEIで取得されたデータはデータベースにエクスポートされます。エクスポート・データベースから、SQLスクリプトを使用してステージング・データベースにアップロードされます。次に、本番データベースに移入されます。本番DWHにデータが移入されると、様々なレポートやダッシュボードを介してRUEIデータが使用可能になります。このようなレポートの例を図S-2に示します。

図S-2 BIダッシュボードの例

エンリッチ・データ交換の有効化および無効化

エンリッチ・データ交換機能を有効化する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「拡張データ交換」の順に選択します。図S-3に示す画面が表示されます。

図S-3 拡張データ交換

2. KPIデータ交換が有効/無効チェック・ボックスを使用して、KPIのデータをエクスポートする機能を有効化するかどうかを指定します。KPIデータ交換が有効/無効チェック・ボックスを使用して、KPIのデータをエクスポートする機能を有効化するかどうかを指定します。デフォルトでは両方とも無効になっています。エクスポート・データを使用できるかどうかは、レポータのデータ保存ポリシー(12.10.1項「レポータの保存ポリシーの定義」を参照)によって決まることに注意してください。

3. 必要に応じて、エクスポートされるエンリッチ・データに含める追加のデータ・アイテムを定義できます。一般に、これらは、RUEIでは通常収集されないクライアント・リクエスト・ヘッダーまたはサーバー・レスポンス・ヘッダー内の要素ですが、エクスポートされるデータには含めることができます。それには、新規アイテムの追加をクリックします。図S-4に示すダイアログが表示されます。

図S-4 エンリッチ・データ・エクスポート・アイテムの追加ダイアログ

4. 「ソース・タイプ」メニューを使用して、RUEIで収集されたデータ内で目的のアイテムを識別する方法を定義します。リテラル検索またはXPath式を使用してクライアント・リクエスト・ヘッダーまたはサーバー・レスポンス・ヘッダー内で検索するように指定することも、カスタムのページ・タグ付け実装内で特定のタグを検索するように指定することもできます。カスタムのページ・タグ付けスキームのサポートの詳細は、付録A「タグ付け規則」を参照してください。
「ソース値」フィールドを使用して、データ・アイテムの値の取得元にする特定の引数または要素を指定します。

「エクスポート名」フィールドを使用して、データ・アイテムに割り当てる名前を指定します。これがアイテムの要素名になります。カスタム・タグの場合は、BI__BIDATA_MASTERのCONTENT列(表S-2を参照)に、&name=value=という形式で表示されます。同様に、XPath式のアイテムは、REQUEST_HEADERS列またはREPLY_HEADERS列にレポートされます。「ソース・タイプ」メニューでヘッダー関連のオプションを選択している場合には、「エクスポート名」フィールドを使用できないことに注意してください。この場合、該当する列にはヘッダー名が使用されます。次に、「保存」をクリックします。新規アイテムが監視対象トラフィックで見つかると、5-10分以内に、レポートされるデータに表示されるようになります。

定義にXPath式を使用している場合は、「ネームスペース」タブをクリックし、その式で使用されているネームスペースを定義します。XPath式の使用は、付録F「XPath問合せの使用」に記載されています。

既存のデータ・アイテムは、図S-3内で右クリックし、「編集」を選択して変更できます。また、削除するには「削除」 を選択し、現在定義済のアイテムをすべて削除するには「すべて削除」を選択します。

ベスト・プラクティス

SQL問合せを使用して、エクスポートされたデータにアクセスすると、エクスポート・データベースに多大なパフォーマンス・オーバーヘッドがかかる可能性があります。このため、次の点に特に注意することをお薦めします。

- 1分間に実行されるSQL問合せの数を最小限に制限します。特に、同じデータを何度も問合せないようにしてください。

- 単純なSQL問合せを使用して、目的のデータにアクセスします。表の特定の列が必要ない場合は、問合せの結果から削除してください。

- 大量のデータを処理する必要がある場合は、別のエクスポート・データベースを使用するように検討することをお薦めします。別のデータベースを構成する手順の詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』の付録Bを参照してください。

S.2 エンリッチ・データ交換のデータベース表の構造

この章では、エンリッチ・データ交換用にRUEIで生成されるデータベース表の構造について説明します。KPIデータのエクスポート用に使用する表については、S.3項「KPIデータ交換のデータベース表の構造」で説明します。これらの表は、インストール済RUEIで使用するデータベース(ローカルまたはリモート)にあります。アクセスするにはSQL問合せを使用します。

概要

SQL問合せを設計する場合、関連する期間表(WG__BIDATA_PERIODやWG__BIDATA_USERFLOW_PERIODなど)を調べて、必要な期間のデータがエクスポートされているかどうかを確認することをお薦めします。使用できる場合、PROCESSOR_ID、PERIOD_IDおよびPAGEVIEW_IDの組合せを使用して、他の表にアクセスできます。KPI関連データの場合、PERIOD_IDのみが必要です。

RUEIのスケーラビリティのため、ほとんどの表にPROCESSOR_ID列が含まれます。所定の間隔のデータが指定した処理エンジン・システムから正常にエクスポートされたことを示します。KPIデータが処理エンジン・システムではなくレポータからエクスポートされるため、この列はKPI関連表に表示されません。RUEIインストールに構成された処理エンジンが含まれない場合、0とレポートされるPROCESSOR_IDとともに、間隔ごとに1つの行のみが作成されます。

STAMP列では、データ・エクスポートがトリガーされた期間を1分間隔で示します。データはデータベースからパージされるため、指定されたエンリッチ・データ交換の保存ポリシー(12.10.1項「レポータの保存ポリシーの定義」を参照)に従って、この表から行が削除されます。同様に、1分ごとに表に行が追加されます。前の1分間のエクスポート処理が完了している場合にのみ、新しい行が表示されることに注意してください。エクスポート・データを使用できるかどうかは、12.10.1項「レポータの保存ポリシーの定義」で説明しているエンリッチ・データ交換の保存設定によって決まります。

次の項に記載されている表では、タイプVARCHAR(CLIENT_REGIONなど)の列がディメンションで、タイプNUMBER(DYNAMIC_NETWORK_TIMEなど)の列がデータ・カウンタです。両方の説明は、付録E「データ・アイテムの概要」を参照してください。

WG__BIDATA_PERIOD表

WG__BIDATA_PERIOD表(表S-1)では、使用可能なエクスポートされたページ・データの概要を示します。エクスポート・データ表では参照整合性は強制されませんが、関連する他の表へのリンクがPERIOD_ID(1970 UTCからの分数)およびPROCESSOR_ID列の組合せで表示されます。

表S-1 WG__BIDATA_PERIOD表

列

型

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

STAMP

TIMESTAMP

WG__BIDATA_MASTER表

実際のエクスポート・ページ・データはWG__BIDATA_MASTER表に保持されます(表S-2を参照)。各PERIOD_IDおよびPROCESSOR_IDの組合せでは、ページ・ビューごとに1つずつ増える一意のIDをページ・ビューごとに取得します。新しいPERIOD_IDおよびPROCESSOR_IDの組合せが検出されると、PAGEVIEW_IDの番号付けが新たに1から開始されます。STAMP列は、1分間隔ではなくページ・ビューの実際のタイムスタンプを示します。他の列は、ページ・ビューのプロパティを示します。SESSION_ID列には、特定のセッション内で表示されたページへのリンクが表示されることに注意してください。

表S-2 WG__BIDATA_MASTER表

列

型

APP_VIOLATIONS

NUMBER

APPLICATION

VARCHAR2 (4000 BYTE)

BROWSER_DETAIL

VARCHAR2 (4000 BYTE)

BROWSER_TYPE

VARCHAR2 (4000 BYTE)

CLIENT_CITY

VARCHAR2 (4000 BYTE)

CLIENT_COUNTRY

VARCHAR2 (4000 BYTE)

CLIENT_IP

VARCHAR2 (4000 BYTE)

CLIENT_NETWORK

VARCHAR2 (4000 BYTE)

CLIENT_OS_CLASS

VARCHAR2 (4000 BYTE)

CLIENT_OS_VERSION

VARCHAR2 (4000 BYTE)

CLIENT_PROVIDER

VARCHAR2 (4000 BYTE)

CLIENT_REGION

VARCHAR2 (4000 BYTE)

CONTENT

VARCHAR2 (4000 BYTE)

COOKIE

VARCHAR2 (4000 BYTE)

DYNAMIC_NETWORK_TIME

NUMBER

DYNAMIC_SERVER_TIME

NUMBER

FULL_URL

VARCHAR2 (4000 BYTE)

HITS

NUMBER

HTTP_RESULT

VARCHAR2 (4000 BYTE)

NAMED_CLIENT_GROUP

VARCHAR2 (4000 BYTE)

NAMED_CLIENT_NAME

VARCHAR2 (4000 BYTE)

NAMED_SERVER_GROUP

VARCHAR2 (4000 BYTE)

NAMED_SERVER_NAME

VARCHAR2 (4000 BYTE)

PAGE_BROWSER_TIME

NUMBER

PAGE_DELIVERY_TYPE

VARCHAR2 (4000 BYTE)

PAGE_DELIVERY_VALUE

VARCHAR2 (4000 BYTE)

PAGE_DOWNLOAD_TIME

NUMBER

PAGE_GROUP

VARCHAR2 (4000 BYTE)

PAGE_LOAD_TIME

NUMBER

PAGE_NAME

VARCHAR2 (4000 BYTE)

PAGE_READ_TIME

NUMBER

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

REFERRER_URL

VARCHAR2 (4000 BYTE)

REPLY_HEADERS

VARCHAR2 (4000 BYTE)

REQUEST_HEADERS

VARCHAR2 (4000 BYTE)

SERVER_IP

VARCHAR2 (4000 BYTE)

SESSION_ID

VARCHAR2 (4000 BYTE)

SESSION_SEQ_NUMBER

NUMBER

SET_COOKIE

VARCHAR2 (4000 BYTE)

STAMP

TIMESTAMP

STATIC_NETWORK_TIME

NUMBER

STATIC_SERVER_TIME

NUMBER

SUITE_TYPE

VARCHAR2 (4000 BYTE)

TENANT_ID

VARCHAR2 (4000 BYTE)

URL_ARGUMENTS

VARCHAR2 (4000 BYTE)

URL_FILE

VARCHAR2 (4000 BYTE)

URL_PARAMS

VARCHAR2 (4000 BYTE)

URL_POST_ARGUMENTS

VARCHAR2 (4000 BYTE)

USER_ID

VARCHAR2 (4000 BYTE)

USER_VIOLATIONS

NUMBER

VHOST

VARCHAR2 (4000 BYTE)

VIOLATION_PAGEVIEWS

NUMBER

表S-2に示したレポートされるデータ・アイテムの詳細は、E項「データ・アイテムの概要」を参照してください。

WG__BIDATA_PROPERTIES表

WG__BIDATA_PROPERTIES表(表S-3)には、その他のページ・ビューのプロパティが記載されています。WG__BIDATA_MASTER表の各行は1つのページ・ビューを参照しますが、WG__BIDATA_PROPERTIES表の複数の行が同じページ・ビューを参照できることに注意してください。

表S-3に示すTYPE列は、アイテムがカスタム・ディメンションを参照していることを示します(3.12項「カスタム・ディメンションの使用」を参照)。NAME列では、カスタム・ディメンションの名前を指定します。

表S-3 WG__BIDATA_PROPERTIES表

列

型

NAME

VARCHAR2 (255 BYTE)

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

TYPE

VARCHAR2 (64 BYTE)

VALUE

VARCHAR2 (4000 BYTE)

WG__BIDATA_MASTER表でレポートされるページ・ビュー内のカスタム・アイテムに関する情報は、対応するPAGEVIEW_IDに基づいてSQL問合せを行うことにより、WG__BIDATA_PROPERTIES表から取得できます。

WG__BIDATA_USERFLOW_PERIOD

最上位レベルのWG__USERFLOW_PERIOD表(表S-4を参照)では、使用可能なエクスポートされたデータの概要を示します。エクスポート・データ表では参照整合性は強制されませんが、関連する他の表へのリンクがPERIOD_ID(1970 UTCからの分数)およびPROCESSOR_ID列の組合せで表示されます。

STAMP列では、データ・エクスポートがトリガーされた期間を1分間隔で示します。データはデータベースからパージされるため、指定されたエンリッチ・データ交換の保存ポリシー(12.10.1項「レポータの保存ポリシーの定義」を参照)に従って、この表から行が削除されます。同様に、1分ごとに表に行が追加されます。前の1分間のエクスポート処理が完了している場合にのみ、新しい行が表示されることに注意してください。エクスポート・データを使用できるかどうかは、12.10.1項「レポータの保存ポリシーの定義」で説明しているエンリッチ・データ交換の保存設定によって決まります。

表S-4 WG__BIDATA_USERFLOW_PERIOD

列

型

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

STAMP

TIMESTAMP

WG__BIDATA_USERFLOWS

実際のエクスポート・データはWG__BIDATA_USERFLOWS表に保持されます(表S-5を参照)。各PERIOD_IDおよびPROCESSOR_IDの組合せでは、ユーザー・フローごとにタイムスタンプのIDを取得します。

各ページ・ビューでは、ページ・ビューごとに1つずつ増える一意のPAGEVIEW_IDを取得します。新しいPERIOD_IDが検出されると、PAGEVIEW_IDの番号付けが新たに1から開始されます。他の列は、ユーザー・フローのプロパティを示します。

表S-5 WG__BIDATA_USERFLOWS表

列

型

説明

CATEGORY

VARCHAR2 (4000 BYTE)

ユーザー定義のユーザー・フロー・カテゴリ名。

MONETARY_VALUE

NUMBER

ユーザー・フローに割り当てられる通貨値。

NAME

VARCHAR2 (4000 BYTE)

ユーザー定義のユーザー・フロー名。

PAGEVIEW_ID

NUMBER

内部的なページ・ビューID(PERIOD_IDごとに一意)。

PERIOD_ID

NUMBER

タイムスタンプ。

PROCESSOR_ID

NUMBER

データが導出される処理エンジン。

STATUS

NUMBER

ユーザー・フローのステータス。使用可能な値は、表S-6で説明しています。

STEP

VARCHAR2 (4000 BYTE)

ユーザー定義のステップ名。

STEPNR

NUMBER

ユーザー・フロー内のステップの数。

USERFLOW_PERIOD_ID脚注1

NUMBER

タイムスタンプ。

脚注1 この列は内部的な目的のみに使用されるので無視します。

「ステータス」列は、ユーザー・フロー内の現在の位置を示します。表S-6に、使用可能な値を示します。

表S-6 ユーザー・フロー・ステータス値

ステータス

説明

started

最初のユーザー・フロー・ステップが完了しています。

move-forward

ページ・ビューがユーザー・フローの次のステップ(つまり、最初ではない)と一致し、オプション・ステップをスキップしている可能性があります。

move-back

このページ・ビューで、ユーザーがユーザー・フローの前のステップに戻っています。

active

現在のページ・ビューが現在のステップと一致しています。このため、ユーザーは前後に移動していませんが、ユーザー・フロー内にアクティビティがあります。

outside

現在のページ・ビューがユーザー・フローにない一連のページ・ビューの最初です。この一連の最初のみが表に記録されることに注意してください。

abort

現在のページ・ビューが定義された中断条件と一致しています。

back-in

前のoutsideステータスに続いて、このページ・ビューがユーザー・フロー内の最初に戻っていることを示します。outsideステータスごとにback-inステータスを持つ行が一致するため、ses-timeoutまたはcompleteステータスの直前にもレポートされます。

idle-out

ユーザー構成ステップのアイドル時間を超えて完了していないユーザー・フローのアクティビティがないことを示します。この場合、レポートされるページ・ビューはほとんどランダムで、最後に識別されたページ・ビューであり、必ずしもユーザー・フローの一部ではない可能性があります。

idle-in

前のidle-outステータスに続いて、このページ・ビューがユーザー・フロー内の最初に戻っていることを示します。各idle-outステータスごとにidle-inステータスを持つ行が一致するため、ses-timeoutまたはcompleteステータスの直前にもレポートされます。

ses-timeout

idle-outと同じですが、セッション全体がタイムアウトしていることを示します。

complete

ページ・ビューは、ユーザー・フローの最後のステップを完了しています。

WG__BIDATA_SUITES表

表S-7に示すWG__BIDATA_SUITES表では、エクスポート情報を使用可能なスイートの種類を示します。スイートの種類にスイート・インスタンスが定義されている場合にのみ、この表にスイートの種類が表示されます。

表S-7 WG__BIDATA_SUITES表

列

型

PROCESSOR_ID

NUMBER

SUITE_TYPE脚注1

VARCHAR2 (255 BYTE)

脚注1 スイート・タイプは、関連付けられているスイート固有の表名の最後の部分を使用して識別されます。たとえば、JD Edwardsスイートは表WG__BIDATA_SUITE_JDEを所有し、文字列「JDE」で識別されます。

スイート固有の表

スイートの各表は、基本的にはWG__BIDATA_MASTER表の拡張であり、ページ・ビューごとに関連するスイート固有の情報が表示されます。

表S-8 WG__BIDATA_SUITE_EBS表

列

型

EBS_ACTION

VARCHAR2 (4000 BYTE)

EBS_COMPONENT_NAME

VARCHAR2 (4000 BYTE)

EBS_FORMNAME_ID

VARCHAR2 (4000 BYTE)

EBS_FORMNAME_NAME

VARCHAR2 (4000 BYTE)

EBS_FWK_NAME

VARCHAR2 (4000 BYTE)

EBS_JSP_FILENAME

VARCHAR2 (4000 BYTE)

EBS_MODULE_ID

VARCHAR2 (4000 BYTE)

EBS_MODULE_NAME

VARCHAR2 (4000 BYTE)

EBS_REGION_ID

VARCHAR2 (4000 BYTE)

EBS_REGION_NAME

VARCHAR2 (4000 BYTE)

EBS_RESP_KEY

VARCHAR2 (4000 BYTE)

EBS_RESP_NAME

VARCHAR2 (4000 BYTE)

FORMS_CLIENT_BODY

VARCHAR2 (4000 BYTE)

FORMS_SERVER_BODY

VARCHAR2 (4000 BYTE)

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

表S-9 WG__BIDATA_SUITE_FCDB表

列

型

FCDB_CHANNEL_CODE

VARCHAR2 (4000 BYTE)

FCDB_CHANNEL_NAME

VARCHAR2 (4000 BYTE)

FCDB_PORTAL_CODE

VARCHAR2 (4000 BYTE)

FCDB_PORTAL_NAME

VARCHAR2 (4000 BYTE)

FCDB_USERTYPE_CODE

VARCHAR2 (4000 BYTE)

FCDB_USERTYPE_NAME

VARCHAR2 (4000 BYTE)

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

表S-10 WG__BIDATA_SUITE_FCUB表

列

型

FCUB_ACTION_CODE

VARCHAR2 (4000 BYTE)

FCUB_ACTION_NAME

VARCHAR2 (4000 BYTE)

FCUB_BRANCH_CODE

VARCHAR2 (4000 BYTE)

FCUB_BRANCH_NAME

VARCHAR2 (4000 BYTE)

FCUB_MODULE_CODE

VARCHAR2 (4000 BYTE)

FCUB_MODULE_NAME

VARCHAR2 (4000 BYTE)

FCUB_SCREEN_CODE

VARCHAR2 (4000 BYTE)

FCUB_SCREEN_NAME

VARCHAR2 (4000 BYTE)

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

表S-11 WG__BIDATA_SUITE_FUS表

列

型

FUS_CLIENTID_NAME

VARCHAR2 (4000 BYTE)

FUS_COMPONENT_NAME

VARCHAR2 (4000 BYTE)

FUS_COMPONENT_TYPE_ID

VARCHAR2 (4000 BYTE)

FUS_COMPONENT_TYPE_NAME

VARCHAR2 (4000 BYTE)

FUS_CONTEXT_ROOT

VARCHAR2 (4000 BYTE)

FUS_EVENTTYPE

VARCHAR2 (4000 BYTE)

FUS_PRODUCT_FAMILY_NAME

VARCHAR2 (4000 BYTE)

FUS_PRODUCT_FAMILY_NAME_SHORT

VARCHAR2 (4000 BYTE)

FUS_PRODUCT_NAME

VARCHAR2 (4000 BYTE)

FUS_PRODUCT_SHORT_NAME

VARCHAR2 (4000 BYTE)

FUS_REGION_ID

VARCHAR2 (4000 BYTE)

FUS_TASKFLOW_ID

VARCHAR2 (4000 BYTE)

FUS_VIEWID_NAME

VARCHAR2 (4000 BYTE)

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

表S-12 WG__BIDATA_SUITE_JDE表

列

型

JDE_ACTION_ID

VARCHAR2 (4000 BYTE)

JDE_ACTION_NAME

VARCHAR2 (4000 BYTE)

JDE_APPLICATION_ID

VARCHAR2 (4000 BYTE)

JDE_APPLICATION_NAME

VARCHAR2 (4000 BYTE)

JDE_ENVIRONMENT_NAME

VARCHAR2 (4000 BYTE)

JDE_FORM_ID

VARCHAR2 (4000 BYTE)

JDE_FORM_NAME

VARCHAR2 (4000 BYTE)

JDE_PRODUCT_CODE

VARCHAR2 (4000 BYTE)

JDE_PRODUCT_NAME

VARCHAR2 (4000 BYTE)

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

表S-13 WG__BIDATA_SUITE_PSFT表

列

型

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

PSFT_ICACTION_ID

VARCHAR2 (4000 BYTE)

PSFT_ICACTION_NAME

VARCHAR2 (4000 BYTE)

PSFT_NODENAME_ID

VARCHAR2 (4000 BYTE)

PSFT_NODENAME_NAME

VARCHAR2 (4000 BYTE)

PSFT_PORTALNAME_ID

VARCHAR2 (4000 BYTE)

PSFT_PORTALNAME_NAME

VARCHAR2 (4000 BYTE)

PSFT_SITENAME_ID

VARCHAR2 (4000 BYTE)

PSFT_SITENAME_NAME

VARCHAR2 (4000 BYTE)

表S-14 WG__BIDATA_SUITE_SBL表

列

型

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

SBL_APPLET_NAME

VARCHAR2 (4000 BYTE)

SBL_CMD_NAME

VARCHAR2 (4000 BYTE)

SBL_METHOD_NAME

VARCHAR2 (4000 BYTE)

SBL_MODULE_NAME

VARCHAR2 (4000 BYTE)

SBL_SCREEN_NAME

VARCHAR2 (4000 BYTE)

SBL_VIEW_NAME

VARCHAR2 (4000 BYTE)

表S-15 WG__BIDATA_SUITE_WLP表

列

型

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

WLP_ACTION_ACTION

VARCHAR2 (4000 BYTE)

WLP_BOOK_NAME

VARCHAR2 (4000 BYTE)

WLP_DESKTOP_NAME

VARCHAR2 (4000 BYTE)

WLP_PAGE_NAME

VARCHAR2 (4000 BYTE)

WLP_PORTAL_NAME

VARCHAR2 (4000 BYTE)

WLP_PORTLET_NAME

VARCHAR2 (4000 BYTE)

WLP_WEBAPP_NAME

VARCHAR2 (4000 BYTE)

表S-16 WG__BIDATA_SUITE_WCS表

列

型

PAGEVIEW_ID

NUMBER

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

WCS_CLIENTID_NAME

VARCHAR2 (4000 BYTE)

WCS_COMPONENT_NAME

VARCHAR2 (4000 BYTE)

WCS_COMPONENT_TYPE_ID

VARCHAR2 (4000 BYTE)

WCS_COMPONENT_TYPE_NAME

VARCHAR2 (4000 BYTE)

WCS_CONTENT

VARCHAR2 (4000 BYTE)

WCS_CONTENT_ID

VARCHAR2 (4000 BYTE)

WCS_CONTENT_SUBTYPE

VARCHAR2 (4000 BYTE)

WCS_CONTENT_TYPE

VARCHAR2 (4000 BYTE)

WCS_EVENTTYPE

VARCHAR2 (4000 BYTE)

WCS_FRAMEWORK

VARCHAR2 (4000 BYTE)

WCS_PAGE_NAME

VARCHAR2 (4000 BYTE)

WCS_PAGE_UPDATE

VARCHAR2 (4000 BYTE)

WCS_RECOMM_USED

VARCHAR2 (4000 BYTE)

WCS_REGION_ID

VARCHAR2 (4000 BYTE)

WCS_SITE_CHANNEL

VARCHAR2 (4000 BYTE)

WCS_SITE_NAME

VARCHAR2 (4000 BYTE)

WCS_SPACE_ID

VARCHAR2 (4000 BYTE)

WCS_SPACE_NAME

VARCHAR2 (4000 BYTE)

WCS_SPACE_TYPE

VARCHAR2 (4000 BYTE)

WCS_TASKFLOW_ID

VARCHAR2 (4000 BYTE)

WCS_TASKFLOW_NAME

VARCHAR2 (4000 BYTE)

WCS_TEMPLATE

VARCHAR2 (4000 BYTE)

WCS_USER_INPUT_NAME

VARCHAR2 (4000 BYTE)

WCS_USER_SEGMENTS

VARCHAR2 (4000 BYTE)

WCS_VIEWID_NAME

VARCHAR2 (4000 BYTE)

WG__BIDATAWS_PERIOD表

WG__BIDATAWS_PERIOD表(表S-17)では、使用可能なエクスポートされたサービス・データの概要を示します。エクスポート・データ表では参照整合性は強制されませんが、関連する他の表へのリンクがPERIOD_ID(1970 UTCからの分数)およびPROCESSOR_ID列の組合せで表示されます。

表S-17 WG__BIDATAWS_PERIOD表

列

型

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

STAMP

TIMESTAMP

WG__BIDATAWS_MASTER表

実際のエクスポート・サービス・データはWG__BIDATAWS_MASTER表に保持されます(表S-18を参照)。各PERIOD_IDおよびPROCESSOR_IDの組合せでは、ページ・ビューごとに1つずつ増える一意のIDをページ・ビューごとに取得します。新しいPERIOD_IDおよびPROCESSOR_IDの組合せが検出されると、CALL_IDの番号付けが新たに1から開始されます。STAMP列は、1分間隔ではなくページ・ビューの実際のタイムスタンプを示します。他の列は、ページ・ビューのプロパティを示します。

表S-18 WG__BIDATAWS_MASTER表

列

型

CALLS

NUMBER

CALL_ID

NUMBER

CLIENT_CITY

VARCHAR2 (4000 BYTE)

CLIENT_COUNTRY

VARCHAR2 (4000 BYTE)

CLIENT_ID

VARCHAR2 (4000 BYTE)

CLIENT_ID_GROUP

VARCHAR2 (4000 BYTE)

CLIENT_IP

VARCHAR2 (4000 BYTE)

CLIENT_NETWORK

VARCHAR2 (4000 BYTE)

CLIENT_PROVIDER

VARCHAR2 (4000 BYTE)

CLIENT_REGION

VARCHAR2 (4000 BYTE)

CLIENT_TIME

NUMBER

CONTENT

VARCHAR2 (4000 BYTE)

COOKIE

VARCHAR2 (4000 BYTE)

HTTP_RESULT

VARCHAR2 (4000 BYTE)

NAMED_CLIENT_GROUP

VARCHAR2 (4000 BYTE)

NAMED_CLIENT_NAME

VARCHAR2 (4000 BYTE)

NAMED_SERVER_GROUP

VARCHAR2 (4000 BYTE)

NAMED_SERVER_NAME

VARCHAR2 (4000 BYTE)

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

REPLY_HEADERS

VARCHAR2 (4000 BYTE)

REQUEST_HEADERS

VARCHAR2 (4000 BYTE)

SERVER_IP

VARCHAR2 (4000 BYTE)

SERVER_TIME

NUMBER

SERVICE

VARCHAR2 (4000 BYTE)

SET_COOKIE

VARCHAR2 (4000 BYTE)

STAMP

TIMESTAMP

TENANT_ID

VARCHAR2 (4000 BYTE)

TRANSFER_TIME

NUMBER

URL_ARGUMENTS

VARCHAR2 (4000 BYTE)

URL_FILE

VARCHAR2 (4000 BYTE)

URL_PARAMS

VARCHAR2 (4000 BYTE)

URL_POST_ARGUMENTS

VARCHAR2 (4000 BYTE)

VHOST

VARCHAR2 (4000 BYTE)

WS_APP_VIOLATIONS

NUMBER

WS_DELIVERY

VARCHAR2 (4000 BYTE)

WS_DELIVERY_DETAIL

VARCHAR2 (4000 BYTE)

WS_FUNCTION

VARCHAR2 (4000 BYTE)

WS_FUNCTION_GROUP

VARCHAR2 (4000 BYTE)

WS_LANGUAGE

VARCHAR2 (4000 BYTE)

WS_TERRITORY

VARCHAR2 (4000 BYTE)

WS_USER_VIOLATIONS

NUMBER

表S-18に示したレポートされるデータ・アイテムの詳細は、E項「データ・アイテムの概要」を参照してください。

WG__BIDATAWS_PROPERTIES表

WG__BIDATAWS_PROPERTIES表(表S-19)では、その他のサービス・プロパティを示します。WG__BIDATAWS_MASTER表の各行は1つのページ・ビューを参照しますが、WG__BIDATAWS_PROPERTIES表の複数の行が同じページ・ビューを参照できることに注意してください。

表S-19に示すTYPE列は、アイテムがカスタム・ディメンションを参照していることを示します(3.12項「カスタム・ディメンションの使用」を参照)。NAME列では、カスタム・ディメンションの名前を指定します。

表S-19 WG__BIDATAWS_PROPERTIES表

列

型

CALL_ID

NUMBER

NAME

VARCHAR2 (255 BYTE)

PERIOD_ID

NUMBER

PROCESSOR_ID

NUMBER

TYPE

VARCHAR2 (64 BYTE)

VALUE

VARCHAR2 (4000 BYTE)

WG__BIDATAWS_MASTER表でレポートされるコール・ビュー内のカスタム・アイテムに関する情報は、対応するCALL_IDに基づくSQL問合せを使用して、WG__BIDATAWS_PROPERTIES表から取得できます。

S.2.1 国および地域のレポート

エクスポートされたデータ内でレポートされるCLIENT_COUNTRYは、ISO 3166-1標準に基づきます。これは、2文字の略語(たとえば、オーストラリアはAU)を使用して、エンドユーザーの国の場所を示します。ただし、エンドユーザーの所在地を判別できない場合には、特殊なコードの番号がレポートされます。表S-20にこれを示します。

表S-20 ISO 3166-1国コードの例外のレポート

コード

説明

--

ホーム・ネットワークには、(最上位レベルではなく)ローカル・ドメイン名が使用されます。

A1

クライアントからの要求の中継として匿名プロキシが使用されています。

A2

クライアントのインターネットへのアクセスは、社外のISPを経由します。

EU

ヨーロッパにある社内プロキシが使用されています。

AP

アジア太平洋地域にある社内プロキシが使用されています。

米国およびカナダでは、レポートされるCLIENT_REGIONはISO 3166-2標準に基づきます。これには、国コードと地域の組合せが使用されます。たとえば、米国のテキサス州はUS-TXとレポートされます。世界の他の地域では、該当するFIPS 10-4の地域コードがレポートされます。表S-20に示す特殊な国コードでは、地域コードは00とレポートされます。たとえば、A1-00のようになります。

S.3 KPIデータ交換のデータベース表の構造

この章では、KPIデータのエクスポート用にRUEIで生成されるデータベース表の構造について説明します。これらの表は、インストール済RUEIで使用するデータベース(ローカルまたはリモート)にあります。アクセスするにはSQL問合せを使用します。

WG__BIDATAKPI_PERIOD

最上位レベルのWG__BIDATAKPI_PERIOD表(表S-21を参照)では、使用可能なエクスポートされたKPIデータの概要を示します。エクスポート・データ表では参照整合性は強制されませんが、KPIに関連するもう1つの表(WG__BIDATAKPI_MASTER)へのリンクがPERIOD_ID(1970 UTCからの分数)列に表示されます。

STAMP列では、データ・エクスポートがトリガーされた期間を1分間隔で示します。データはデータベースからパージされるため、指定されたKPI用のエンリッチ・データ交換の保存ポリシー(12.10.1項「レポータの保存ポリシーの定義」を参照)に従って、この表から行が削除されます。同様に、1分ごとに表に行が追加されます。前の1分間のエクスポート処理が完了している場合にのみ、新しい行が表示されることに注意してください。KPIデータを使用できるかどうかは、12.10.1項「レポータの保存ポリシーの定義」で説明しているKPIデータ交換の保存設定によって決まります。

表S-21 WG__BIDATAKPI_PERIOD表

列

型

PERIOD_ID

NUMBER

STAMP

TIMESTAMP

WI__BIDATAKPI_MASTER

実際のKPIデータはWG__BIDATAKPI_MASTER表に保持されます(S-22を参照)。各PERIOD_IDでは、KPIごとに一意のKPI_IDを取得します。

表S-22 WG__BIDATAKPI_MASTER表

列

型

説明

CATEGORY

VARCHAR (255 CHAR)

ユーザー - ユーザーKPIカテゴリ名。

DATA_TYPE

VARCHAR (255 BYTE)

KPIのデータ・アクセス定義(null=汎用、app=アプリケーション固有、suite=スイート固有、service=サービス固有)脚注1。

DENOMINATOR

BINARY_DOUBLE

期間の分母の値。

DESCRIPTION

VARCHAR (255 CHAR)

ユーザー定義のKPIの説明。

FILTERS

CLOB

ディメンション・レベルのフィルタ定義。

KPI_ID

NUMBER

一意の内部KPI ID。

NAME

VARCHAR (255 CHAR)

ユーザー定義のKPI名。

NUMERATOR

BINARY_DOUBLE

期間の分子の値。

PERIOD_ID

NUMBER

タイムスタンプ。

REQUIREMENTS

CLOB

メトリック・レベルの要件定義。

SPAN

NUMBER

KPI値を計算する対象期間(分単位)。

STATUS

NUMBER

KPIのステータス(-1=不明、0=失敗、1=成功)。

SUITE_TYPE

VARCHAR (255 BYTE)

データ・アクセス・スイートの種類の定義(EBSやSiebelなど)

TARGET_MAX

NUMBER

KPIターゲットの最大値。

TARGET_MIN

NUMBER

KPIターゲットの最小値。

TARGET_TYPE

NUMBER

(0=なし、1=固定、2=自動)。

VALUE

NUMBER

SPAN期間について計算された現在のKPI値。

脚注1正確な値はGUIで使用される内容に基づき、変更される可能性があります。

T HSMサポートの構成

この付録では、RUEIを構成して、HSMデバイスに格納されている秘密鍵にアクセスする方法について説明します。この機能はベータ版として提供されています。開始する前に、HSMベンダーのマニュアルを参照してください。

T.1 概要

ハードウェア・セキュリティ・モジュール(HSM)とは、サーバー・システムに接続してデジタル鍵を管理できるデバイスのことです。これらの要素を認証されていないユーザーから論理的、物理的の両面で保護します。

RUEIでのHSMのサポートはOpenSSLに基づきます。OpenSSLプロジェクトの詳細は、http://www.openssl.org/を参照してください。RUEIで提供される監視のサポートは、Thales社のnCipher製品ラインに対して検証されています。ただし、他のOpenSSLベースの実装でも機能します。

T.2 HSMベンダー・ソフトウェアのインストールおよび構成

次を実行します。

1. 必須コレクタ・システムごとにHSMベンダー・ソフトウェアをインストールします。インストール手順の詳細は、HSMベンダーのマニュアルを参照してください。

2. HSMのセキュリティ・ドメイン内で各必須コレクタ・システムを構成します。この手順の詳細は、HSMベンダーのマニュアルを参照してください。

3. 必要に応じて、ldconfigを使用するか、またはLD_LIBRARY_PATH環境変数をエクスポートして、HSMベンダー・ライブラリをOpenSSLで使用できるようにします。たとえば、Thales社のnCipher製品ラインでは、ソフトウェアがディレクトリ/opt/nfastにインストールされていることを前提とし、次のコマンドを発行して実現します。

echo /opt/nfast/toolkits/hwcrhk > /etc/ld.so.conf.d/ncipher.conf
ldconfig

T.3 コレクタ・システムの構成

必須コレクタ・システムを構成する手順は、次のとおりです。

1. レポータ・システム上で次のコマンドをRUEI_USERとして発行し、現在定義されているコレクタ・プロファイルのリストを取得します。

execsql config_get_profiles

この項で後述しているように、関連するプロファイル内のすべてのコレクタ・システムが、HSMデバイスに接続できるように構成されている必要があります。

2. HSMデバイスに格納されている秘密鍵にRUEIがアクセスするには、HSMデバイスへの接続が必要です。これは、OpenSSLエンジン(chilなど)を介して確立できます。次のコマンドを発行して、各必須コレクタ・システム上で必要なOpenSSLエンジンがサポートされているかどうかをテストします。

openssl engine -c engine

engineにはベンダーのOpenSSLエンジンを指定します。次の出力例は、cswiftエンジンのサポートを示しています。

(cswift) CryptoSwift hardware engine support
[RSA, DSA, DH, RAND]

3. 次のコマンドを発行し、選択したOpenSSLエンジンを使用してHSMデバイスに実際に接続できるかどうかをテストします。

openssl engine -c -tt engine

次のような出力内容は、OpenSSLが使用できることを示しています。

(cswift) CryptoSwift hardware engine support
[RSA, DSA, DH, RAND]
[ available ]

4. HSM実装のログ・ファイルをチェックして、コレクタ・システムからHSMデバイスに正常に接続できることを確認します。たとえば、Thales社のnCipher製品ラインでは、これは/opt/nfast/log/hardserver.logにあります。詳細は、HSMベンダーのマニュアルを参照してください。

5. レポータ・システムで次のコマンドをRUEI_USERとして発行し、各コレクタ・システムで必要なOpenSSLエンジンを構成します。

execsql config_set_profile_value wg profile ssl SSLUseEngine replace engine

profileには必須コレクタ・プロファイルを指定します。

6. 各必須コレクタを再起動します。それには、「構成」→「コレクタ・プロファイル」の順に選択します。必須コレクタ・プロファイルを選択します。選択したプロファイルに割り当てられているコレクタごとに、コンテキスト・メニューで「再起動」を選択します。

注意:
localhostによって認識されるレポータ・システム上のコレクタをHSM統合に使用しない場合や、これが環境内で無効化されている場合でも、このコレクタをHSM統合に向け準備しておく必要があります。これは、SSL鍵検証にlocalhostコレクタが使用されるためです。HSMキーのRUEIへのアップロード中に、このコレクタが有効になっていることを確認してください。キーがアップロードされた後、localhostコレクタは再び無効になる場合があります。

T.4 HSMキーの構成

HSMで暗号化されたトラフィックの復号化をRUEIで可能にするには、最初に既存のHSMキーをRUEIにインポートする必要があります。組込み形式でモジュールが保護されていることを確認する必要があります。すべての鍵がモジュールによって保護された状態でHSMデバイスに格納される必要があります。つまり、モジュールの鍵を使用して、ユーザー認証トークンを保護します。このような鍵にはパスフェーズがなく、対応するセキュリティ・ドメイン内でHSMデバイスに接続している任意のアプリケーションがアクセスできます。この説明はThales社の製品ラインに特有であることに注意してください。

既存の鍵が前述の要件を満たしていない場合は、それらをRUEIにインポートする前に再ターゲットする必要があります。この手順の詳細は、HSMベンダーのマニュアルを参照してください。

生成または再ターゲット後、HSMソフトウェアによって専用のPEMファイルが作成されます。このファイルはRUEIにインポートできます(13.5項「SSL鍵の管理」を参照)。PEMファイルには公開証明書が含まれている必要があります。生成されたPEMファイルに公開証明書が含まれていない場合は、PEMファイルに手動で追加する必要があります。実際には専用のPEMファイルにSSL鍵は含まれていませんが、HSMで格納されている鍵への参照が含まれています。

T.5 HSMベース・トラフィックの正常な監視の検証

HSMデバイスに格納されている鍵が正常に暗号化されていることを検証するには、「コレクタ統計」ウィンドウで「SSL暗号化」タブの情報を確認します。この機能の使用方法は、15.2項「コレクタのステータスの表示」に記載されています。

U 標準レポート・ライブラリ

この付録では、レポート・ライブラリに用意されている事前定義済(標準)レポートについて説明します。レポートの使用方法は、第2章「レポートの操作」に記載されています。

U.1 レポート・カテゴリ

この項では、監視対象トラフィックの項目別に専用レポートが含まれる複数のレポート・カテゴリについて説明します。レポートのタイトルにXLSと記載されている場合は、そのレポートがエクスポート書式であることを示すことに注意してください。

表U-1 「アプリケーション」カテゴリのレポート

フォルダ/レポート

説明

失敗

アプリケーションごとにWebサイト、サーバー、ネットワークおよびコンテンツの各エラーを示します。

オブジェクト・パフォーマンス詳細

アプリケーションごとにページ当たりの動的サーバー、動的ネットワーク、静的サーバーおよび静的ネットワークの各時間(ミリ秒)を示します。

オブジェクト・サイズ詳細

アプリケーションごとにページ当たりの動的コンテンツ、動的ヘッダー、静的コンテンツおよび静的ヘッダーの各サイズ(バイト)を示します。

ページのロード/読取り時間

アプリケーションごとにページ・ロードとページ読取りの各時間(秒)を示します。

ページ・ビューおよびヒット

アプリケーションごとにページ・ビューとヒット数を示します。

セッションのロード/読取り時間

アプリケーションごとにセッション・ロードとセッション読取りの各時間(秒)を示します。

セッション

ユーザー・セッションで使用されたアプリケーションを示します。

アプリケーション情報(XLS形式)

アプリケーションごとにセッション情報(セッション数、セッション継続時間、セッション当たりのページ・ビューなど)を示します。

不明ページ・オブジェクト (404) (XLS形式)

HTTP 404リターン・コードを構成するページ名、ページURLおよびオブジェクトURLの組合せを示します。これを使用すると、レンダリングに失敗したオブジェクトとそのページを特定できます。

不明参照オブジェクト(404) (XLS形式)

アプリケーションに起因しないHTTP 404リターン・コードが返されたエラー・オブジェクトを示します。

アプリケーション・ページ

失敗脚注1

ページ・グループごとにWebサイト、ネットワーク、サーバーおよびコンテンツの各エラー・ページ・ビューを示します。

オブジェクト・パフォーマンス詳細脚注1

ページ・グループごとにページ当たりの動的サーバー、動的ネットワーク、静的サーバーおよび静的ネットワークの各時間(ミリ秒)を示します。

オブジェクト・サイズ詳細脚注1

ページ・グループごとにページ当たりのオブジェクト・サイズの合計(バイト)を示します。

ページ・ロード時間の満足度

グループごとにページ・ビューを示します。

ページ・ロード時間/クライアント中断脚注1

ページ・グループごとにページ・ロード時間(秒)を示します。

ページのロード/読取り時間脚注1

ページ・グループごとにページのロードと読取りの各時間(秒)を示します。

ページ・ビュー

ページ・ビューで使用されたページ・グループを示します。

ページ情報(XLS形式)脚注1

ページ・グループごとにページ・ビューの詳細を示します。

脚注1 アプリケーション・フィルタが必要です。

表U-2 「クライアント」カテゴリのレポート

レポート

説明

1国当たりの継続時間

国ごとにセッションのロードと読取りの各時間(秒)を示します。

1国当たりのパフォーマンス

国ごとにページのロードと読取りの各時間(秒)を示します。

1国当たりの満足度

国ごとに良好、OKおよび劣悪の各ページ・ビューを示します。

1OS当たりのセッション

ユーザー・セッションで使用されたオペレーティング・システムを示します。

1ブラウザ当たりのセッション

ユーザー・セッションで使用されたブラウザの種類を示します。

1国当たりのセッション

ユーザー・セッションで使用された国を示します。

1言語当たりのセッション

ユーザー・セッションで使用されたクライアント言語を示します。

1リージョン当たりのセッション

ユーザー・セッションで使用された地域を示します。

ユーザーIDの満足度

識別されたユーザーの良好、OK、劣悪の各ページ・ビューおよびセッションを示します。

ユーザー情報(XLS形式)

ユーザーごとにセッション情報(ユーザーID、セッション数、セッション継続時間など)を示します。

表U-3 「ドメイン」カテゴリのレポート

レポート

説明

失敗

ドメインごとにWebサイト、ネットワーク、サーバーおよびコンテンツの各エラー・ページ・ビューを示します。

ページのロード/読取り時間

ドメインごとにページのロードと読取りの各時間(秒)を示します。

セッションのロード/読取り時間

ドメインごとにセッションのロードと読取りの各時間(秒)を示します。

セッションとページ・ビュー

ドメインごとにセッション数とページ・ビューを示します。

トラフィック

ユーザー・セッションで使用されたドメインを示します。

ドメイン情報(XLS形式)

ドメインごとにセッションの詳細(ユーザーID、セッション数、セッション継続時間など)を示します。

表U-4 「キー・ページ」カテゴリのレポート

レポート

説明

失敗

キー・ページごとにWebサイト、ネットワーク、サーバーおよびコンテンツの各エラー・ページ・ビューを示します。

オブジェクト・パフォーマンス詳細

キー・ページごとにページ当たりのエンド・ツー・エンド時間(ミリ秒)を示します。

オブジェクト・サイズ詳細

キー・ページごとにページ当たりの動的コンテンツ、動的ヘッダー、静的コンテンツおよび静的ヘッダーの各サイズ(バイト)を示します。

ページのロード/読取り時間

キー・ページごとにページのロードと読取りの各時間(秒)を示します。

ページ・ビューおよびヒット

キー・ページごとにページ・ビューとヒット数を示します。

表U-5 「監視」カテゴリのレポート

レポート

説明

KPIの概要

各KPIの詳細(成功率、停止時間、最大解決時間および平均値)を示します。

SLAの概要

各SLAの詳細(結果、成功率、目標達成率および停止時間)を示します。

KPI(XLS形式)

各KPIの詳細(平均値、目標値(最小、最大)、およびステータス)を示します。

表U-6 「全体」カテゴリのレポート

レポート

説明

失敗

Webサイト、ネットワーク、サーバーおよびコンテンツの各エラー・ページ・ビューを示します。

ヒットおよび合計トラフィック

ヒット数と合計トラフィック(バイト)を示します。

オブジェクト・パフォーマンス詳細

アプリケーションごとにページ当たりのエンド・ツー・エンド時間(ミリ秒)を示します。

ページ・ロード時間の詳細

ページのロードと読取りの各時間(秒)を示します。

ページ・ロード時間の満足度

良好、OKおよび劣悪の各ページ・ビューを示します。

ページのロード/読取り時間

ページのロードと読取りの各時間(秒)を示します。

セッションのロード/読取り時間

セッション数とページ・ビューを示します。

セッションとページ・ビュー

セッション数とページ・ビューを示します。

表U-7 「サーバー」カテゴリのレポート

レポート

説明

失敗率

サーバーIPアドレスの場所ごとにWebサイト、ネットワーク、サーバーおよびコンテンツの各サーバー・ページ・ビューを示します。

オブジェクト・パフォーマンス詳細

サーバーIPアドレスの場所ごとにページ当たりの動的サーバー、動的ネットワーク、静的サーバーおよび静的ネットワークの各時間(ミリ秒)を示します。

オブジェクト・サイズ詳細

サーバーIPアドレスの場所ごとにページ当たりの動的コンテンツ、動的ヘッダー、静的コンテンツおよび静的ヘッダーの各サイズ(バイト)を示します。

ページのロード/読取り時間

サーバーIPアドレスの場所ごとにページのロードと読取りの各時間(秒)を示します。

ページ・ビューおよびヒット

サーバーIPアドレスの場所ごとにページ・ビューとヒット数を示します。

サーバー・ロード

合計サーバー時間(ミリ秒)で使用されたサーバーIPアドレスの場所を示します。

トラフィック・サイズ

合計トラフィック(バイト)で使用されたサーバーIPアドレスの場所を示します。

サーバー情報(XLS形式)

サーバーIPアドレスの場所ごとにページ・ビュー情報を示します。

表U-8 「URL」カテゴリのレポート

レポート

説明

失敗したヒット

失敗したオブジェクトURLを示します。

最大オブジェクト

オブジェクトURLごとにヒット当たりのリクエスト・コンテンツ、リクエスト・ヘッダー、応答コンテンツおよび応答ヘッダーの各サイズ(バイト)を示します。

パフォーマンス低下原因

合計サーバー時間(ミリ秒)で使用されたオブジェクトURLを示します。

最低速のヒット

オブジェクトURLごとにヒット当たりのサーバー時間(ミリ秒)を示します。

失敗したヒット(XLS形式)

応答の遅いオブジェクトURLごとにオブジェクトの詳細を示します。

低速ヒット(XLS形式)

失敗したオブジェクトURLごとにヒット情報を示します。

表U-9 「ユーザー・フロー」カテゴリのレポート

レポート

説明

ユーザー・フロー完了

ユーザー・フローごとに成功率(%)を示します。

ユーザー・フロー継続時間

ユーザー・フロー当たりのページ・ロード時間(秒)と(開始された)ユーザー・フロー当たりの閲覧時間(秒)。

ユーザー・フローのステップ・ファンネル脚注1

選択したユーザー・フローのステップ・ファンネルを示します。

ユーザー・フロー・ステップのロード/読取り時間脚注1

選択したユーザー・フローのユーザー・フロー当たりのページ・ロード時間(秒)と(開始された)ユーザー・フロー当たりの閲覧時間(秒)を示します。

脚注1 ユーザー・フロー・フィルタが必要です。

U.2 スイート固有のレポート

各スイート・カテゴリ(E-Business Suite、JD Edwards、Oracle ADF、PeopleSoft、SiebelおよびWeblogic Portal)には、表U-10に示すレポートが含まれます。

表U-10 「スイート」カテゴリのレポート

レポート/フォルダ

説明

クライアント

1国当たりの継続時間

国ごとにページ・ロード時間(秒)を示します。

OS別ページ・ビュー

ページ・ビューで使用されたクライアント・オペレーティング・システムを示します。

1ブラウザ当たりのページ・ビュー

ページ・ビューで使用されたクライアント・ブラウザを示します。

1国当たりのページ・ビュー

ページ・ビューで使用された国を示します。

1言語当たりのページ・ビュー

ページ・ビューで使用されたクライアント言語を示します。

1リージョン当たりのページ・ビュー

ページ・ビューで使用されたクライアント地域を示します。

1国当たりのパフォーマンス

ページ・ビューで発生したページのロードと読取りの各時間(秒)を示します。

1国当たりの満足度

国ごとに良好、OKおよび劣悪の各ページ・ビューを示します。

ユーザーIDの満足度

識別されたユーザーの良好、OK、劣悪の各ページ・ビューおよびセッションを示します。

ドメイン

失敗

ドメインごとにWebサイト、ネットワーク、サーバーおよびコンテンツの各エラー・ページ・ビューを示します。

ページのロード/読取り時間

ドメインごとにページのロードと読取りの各時間(秒)を示します。

ページ・ビューおよびヒット

ドメインごとにページ・ビューとヒット数を示します。

トラフィック

合計トラフィック(バイト)で使用されたドメインを示します。

Overall

失敗

Webサイト、ネットワーク、サーバーおよびコンテンツの各エラー・ページ・ビューを示します。

ヒットおよび合計トラフィック

ヒット数と合計トラフィック(バイト)を示します。

オブジェクト・パフォーマンス詳細

ページごとに動的サーバー、動的ネットワーク、静的サーバーおよび静的ネットワークの各時間(ミリ秒)を示します。

ページ・ロード時間の満足度

良好、OKおよび劣悪の各ページ・ビューを示します。

ページ・ロード時間/クライアント中断

ページ・ロード時間(秒)とクライアント強制終了ページ・ビュー(%)を示します。

ページのロード/読取り時間

ページのロードと読取りの各時間(秒)を示します。

ページ・ビューおよびヒット

ページ・ビューとヒット数を示します。

セッションのロード/読取り時間

ページのロードと読取りの各時間(秒)を示します。

サーバー

失敗率

サーバーIPアドレスの場所ごとにWebサイト、ネットワーク、サーバーおよびコンテンツの各エラー・ページ・ビューを示します。

オブジェクト・パフォーマンス詳細

サーバーIPアドレスの場所ごとにページ当たりの動的サーバー、動的ネットワーク、静的サーバーおよび静的ネットワークの各時間(ミリ秒)を示します。

オブジェクト・サイズ詳細

サーバーIPアドレスの場所ごとにページ当たりの動的コンテンツ、動的ヘッダー、静的コンテンツおよび静的ヘッダーの各サイズ(バイト)を示します。

ページのロード/読取り時間

サーバーIPアドレスの場所ごとにページのロードと読取りの各時間(秒)を示します。

ページ・ビューおよびヒット

サーバーIPアドレスの場所ごとにページ・ビューとヒット数を示します。

サーバー・ロード

合計サーバー時間(ミリ秒)で使用されたサーバーIPアドレスの場所を示します。

トラフィック・サイズ

合計トラフィック(バイト)で使用されたサーバーIPアドレスの場所を示します。

サーバー情報(XLS形式)

サーバーIPアドレスの場所ごとにページ・ビューの詳細を示します。

U.3 「トランザクション」カテゴリ

リリース6.5.1では、トランザクションがユーザー・フローに名称変更され、処理やレポートの方法に重要な違いがあります。「トランザクション」カテゴリのレポートでは、ユーザー・フローの履歴データにアクセスできます。詳細は、リリース6.5.1のリリース・ノートを参照してください。

表U-11 「トランザクション」カテゴリのレポート

レポート

説明

トランザクション完了

トランザクションごとに成功率(%)を示します。

トランザクション継続時間

トランザクションごとにページ・ロード時間(秒)と閲覧時間(秒)を示します。

トランザクションのステップ・ファンネル脚注1

選択したトランザクションのステップ・ファンネルを示します。

トランザクション・ステップのロード/読取り時間脚注1

選択したトランザクションのページ・ロード時間(秒)と閲覧時間(秒)を示します。

脚注1 トランザクション・フィルタが必要です。

V データ・ブラウザ・グループ内で使用できるディメンション

この付録では、各データ・ブラウザ・グループ内で使用できるディメンションの詳細なリストについて説明します。この情報は、カスタム・レポートの設計に特に役立ちます。すべてのデータ・ブラウザ・グループで、月グループが複数日レポートに使用され、年グループが複数月レポートに使用されます。

V.1 すべてのページ、すべてのセッション、キー・ページおよびサービス・テスト・グループ

表V-1 すべてのページ、すべてのセッション、キー・ページおよびサービス・テスト・グループ

すべてのページ

キー・ページ

すべてのセッション

ディメンション

5

H

D

M

5

H

D

M

5

H

D

M

処置

名前

X

X

X

X

アプリケーション言語

値

X

X

X

X

X

X

X

X

X

X

X

X

アプリケーション・テリトリ

値

X

X

X

X

X

X

X

X

X

X

X

X

アプリケーション

名前

X

X

X

X

X

X

X

X

X

X

X

X

ページ・グループ

X

X

X

X

X

X

X

X

ページ名

X

X

X

X

X

X

X

X

クライアント・ブラウザ

型

X

X

X

X

X

X

X

X

詳細

X

X

X

X

X

X

X

クライアント・デバイス

クラス

X

X

X

X

X

X

X

X

ブランド

X

X

X

X

X

X

X

X

モデル

X

X

X

X

X

X

クライアント指定の場所

グループ

X

X

X

X

X

X

名前

X

X

X

X

X

X

IP

X

X

X

X

クライアント言語

言語

X

X

X

X

X

X

クライアント・ネットワーク

国

X

X

X

X

X

X

X

プロバイダ

X

X

X

X

X

X

ネットワーク

X

X

X

X

X

X

IP

X

X

X

X

クライアントの場所

国

X

X

X

X

X

X

X

地域

X

X

X

X

X

X

X

X

市区町村

X

X

X

X

X

X

X

X

IP

X

X

X

X

クライアントOS

クラス

X

X

X

X

X

X

X

X

バージョン

X

X

X

X

X

X

ドメイン

名前

X

X

X

X

X

X

X

X

X

X

X

X

ページ配信

型

X

X

X

X

X

X

X

X

詳細

X

X

X

X

X

X

X

X

ページURL

グループ

X

X

X

URL

X

X

完全なURL

X

X

プロトコル

型

X

X

X

X

サーバーIP

IP

X

X

X

サーバー指定の場所

グループ

X

X

X

X

X

X

名前

X

X

X

X

ユーザーID

グループ

X

X

X

X

X

X

X

X

ID

X

X

X

X

X

X

X

X

V.2 ユーザー・フロー

表V-2 ユーザー・フロー

ユーザー・フロー完了

ユーザー・フロー・アクティビティ

ディメンション

5

D

M

5

D

M

アプリケーション言語

値

X

X

X

アプリケーション・テリトリ

値

X

X

X

クライアント・ブラウザ

型

X

X

X

詳細

X

クライアント・デバイス

クラス

X

X

X

ブランド

X

モデル

X

クライアント指定の場所

グループ

X

X

名前

X

X

IP

X

クライアント言語

言語

X

X

クライアント・ネットワーク

国

X

X

X

プロバイダ

X

ネットワーク

X

IP

X

クライアントの場所

国

X

X

X

地域

X

市区町村

X

IP

X

クライアントOS

クラス

X

X

X

バージョン

X

クライアント画面解像度

値

X

X

X

ユーザー・フロー・デリバリ

型

X

X

X

詳細

X

X

X

ユーザー・フロー

グループ

X

X

X

X

X

X

名前

X

X

X

X

X

X

ステップ

X

X

X

ユーザー・フロー出口ステップ

ステップ

X

X

X

ユーザー・フロー状態

グループ

X

X

X

名前

X

X

X

ユーザーID

グループ

X

X

X

ID

X

V.3 すべての関数、失敗した関数および処理の遅い関数グループ

表V-3 すべての関数、失敗した関数および処理の遅い関数グループ

失敗した関数

すべての関数

処理の遅い関数

ディメンション

R

5

D

M

R

クライアントID

グループ

X

X

X

X

X

ID

X

X

X

X

X

クライアント指定の場所

グループ

X

X

X

X

名前

X

X

X

X

IP

X

X

X

クライアントの場所

国

X

X

X

X

X

地域

X

X

X

X

X

市区町村

X

X

X

X

X

IP

X

X

X

ドメイン

名前

X

X

X

X

X

ECID

ECID

X

X

オブジェクト・タイプ

型

X

X

X

クラス

X

X

X

拡張子

X

X

オブジェクトURL

グループ

X

X

X

X

URL

X

X

X

X

完全なURL

X

X

X

プロトコル

型

X

X

X

X

X

サーバーIP

サーバーIP

X

X

X

X

サーバー指定の場所

グループ

X

X

X

X

名前

X

X

X

X

サービス

名前

X

X

X

X

X

関数グループ

X

X

X

X

X

関数名

X

X

X

X

X

サービス・デリバリ

型

X

X

X

X

X

詳細

X

X

X

X

X

URL POST

詳細

X

X

サービス言語

値

X

X

X

X

X

サービス・テリトリ

値

X

X

X

X

X

V.4 失敗したページ

表V-4 失敗したページ

失敗した関数

ディメンション

R

処置

名前

X

アプリケーション言語

値

X

アプリケーション・テリトリ

値

X

アプリケーション

名前

X

ページ・グループ

X

ページ

X

BTMメッセージID

ID

X

クライアント・ブラウザ

型

X

詳細

X

クライアント・デバイス

クラス

X

ブランド

X

モデル

X

クライアント指定の場所

グループ

X

名前

X

IP

X

クライアント言語

言語

X

クライアント・ネットワーク

国

X

プロバイダ

X

ネットワーク

X

IP

X

クライアントの場所

国

X

地域

X

市区町村

X

IP

X

クライアントOS

クラス

X

バージョン

X

クライアント画面解像度

値

X

ドメイン

ドメイン

X

ECID

ECID

X

ページ配信

型

X

詳細

X

ページURL

グループ

X

URL

X

完全なURL

X

物理クライアント

IP

X

プロトコル

型

X

Referrer

ドメイン

X

URL

X

サーバーIP

IP

X

サーバー指定の場所

グループ

X

名前

X

URL POST

詳細

X

ユーザーID

グループ

X

ID

X

V.5 失敗したURLおよび遅いURL

表V-5 失敗したURLおよび遅いURL

失敗したURL

遅いURL

ディメンション

R

R

D

処置

名前

X

X

アプリケーション言語

値

X

X

X

アプリケーション・テリトリ

値

X

X

X

アプリケーション

名前

X

X

X

ページ・グループ

X

X

ページ名

X

X

BTMメッセージID

ID

X

X

クライアント・ブラウザ

型

X

X

X

詳細

X

X

クライアント・デバイス

クラス

X

X

X

ブランド

X

X

モデル

X

X

クライアント指定の場所

グループ

X

X

X

名前

X

X

X

IP

X

X

クライアント言語

言語

X

X

X

クライアントの場所

国

X

X

X

地域

X

X

X

市区町村

X

X

X

IP

X

X

クライアント・ネットワーク

国

X

X

X

プロバイダ

X

X

ネットワーク

X

X

IP

X

X

クライアントOS

クラス

X

X

X

バージョン

X

X

ドメイン

名前

X

X

X

ECID

ID

X

X

オブジェクト配信

型

X

詳細

X

オブジェクト・タイプ

型

X

X

X

クラス

X

X

X

拡張子

X

X

X

オブジェクトURL

グループ

X

X

X

URL

X

X

完全なURL

X

X

ページURL

グループ

X

X

X

URL

X

X

完全なURL

X

X

物理クライアント

IP

X

X

プロトコル

プロトコル

X

X

X

Referrer

ドメイン

X

X

URL

X

X

サーバーIP

サーバーIP

X

X

X

サーバー指定の場所

グループ

X

X

X

名前

X

X

X

ユーザーID

グループ

X

X

X

ID

X

X

URL POST

詳細

X

X

V.6 URL診断

表V-6 URL診断

ディメンション

R

5

処置

名前

X

X

アプリケーション

名前

X

X

ページ・グループ

X

X

ページ名

X

X

BTMサービス

名前

X

X

操作

X

X

ドメイン

名前

X

X

URL

名前

X

X

オブジェクト配信

型

X

X

詳細

X

X

オブジェクト・タイプ

型

X

X

クラス

X

X

拡張子

X

X

プロトコル

型

X

X

サーバーIP

サーバーIP

X

X

サーバー指定の場所

グループ

X

X

名前

X

X

V.7 E-Business SuiteおよびSiebel

表V-7 E-BusinessおよびSiebel

E-Business (Forms)

Siebel

ディメンション

5

H

D

M

5

H

D

M

アプリケーション言語

値

X

X

X

X

X

X

アプリケーション・テリトリ

値

X

X

X

X

X

X

クライアント・ブラウザ

型

X

X

X

X

X

X

X

X

詳細

X

X

X

X

クライアント・デバイス

クラス

X

X

X

X

X

X

X

X

ブランド

X

X

X

X

モデル

X

X

クライアント指定の場所

指定クライアント・グループ

X

X

X

X

X

X

X

X

指定クライアント

X

X

X

X

X

X

X

X

クライアントIP

X

X

クライアント言語

言語

X

X

X

X

X

X

X

X

クライアント・ネットワーク

国

X

X

X

X

X

X

X

X

プロバイダ

X

X

X

X

ネットワーク

X

X

X

X

IP

X

X

クライアントの場所

国

X

X

X

X

X

X

X

X

地域

X

X

X

X

市区町村

X

X

X

X

IP

X

X

クライアントOS

クラス

X

X

X

X

バージョン

X

X

X

X

ドメイン

名前

X

X

X

X

ページ配信

型

X

X

X

X

X

X

X

X

詳細

X

X

X

X

X

X

X

X

ページURL

グループ

X

X

X

X

URL

X

X

X

X

完全なURL

X

X

サーバーIP

IP

X

X

X

X

サーバー指定の場所

グループ

X

X

X

X

名前

X

X

X

X

ユーザーID

グループ

X

X

X

X

X

X

X

X

ID

X

X

X

X

X

X

X

X

EBSアクション

名前

X

X

EBSクラス

名前

X

EBSコンポーネント名

名前

X

X

EBSフレームワーク・アクティビティ

EBS職責

X

X

X

X

EBSコンポーネント

X

X

EBSユーザー入力

X

X

X

X

EBS Formsアクティビティ

EBSフォーム名の説明

X

X

X

EBSフォーム階層

X

EBSアクション

X

X

EBSユーザー入力

X

X

X

X

EBSフォーム・メッセージ

メッセージ

X

EBSフォーム名

名前

X

X

X

ID

X

X

X

EBSフレームワーク

名前

X

X

X

X

EBS階層

名前

X

EBS JSPファイル名

ファイル名

X

X

EBSモジュール

名前

X

X

X

X

ID

X

X

X

X

EBS職責

名前

X

X

X

X

キー

X

X

X

X

EBSユーザー入力

英数字

X

X

X

X

EBSビュー

名前

X

X

X

X

モジュール

X

X

X

X

フレームワーク

X

X

X

X

Siebelアクティビティ

Siebelアプレット

X

X

X

X

Siebelコマンド

X

X

X

X

Siebelメソッド

X

X

Siebelアプレット

Siebelアプレット

X

X

X

X

Siebelコマンド

Siebelコマンド

X

X

X

X

Siebelメソッド

Siebelメソッド

X

X

Siebelモジュール

Siebelモジュール

X

X

X

X

Siebel画面

Siebel画面

X

X

X

Siebelビュー

Siebelビュー

X

X

X

Siebelビュー

名前

X

X

X

X

Siebelモジュール

X

X

X

X

Siebel画面

X

X

X

Siebelビュー

X

X

X

V.8 ADFフレームワークおよびFusion Applications

表V-8 ADFフレームワークおよびFusion Applications

ADFフレームワーク

Fusion

ディメンション

5

H

D

M

5

H

D

M

クライアント・ブラウザ

型

X

X

X

X

X

X

X

X

詳細

X

X

X

X

クライアント・デバイス

クラス

X

X

X

X

X

X

X

X

ブランド

X

X

X

X

モデル

X

X

クライアント指定の場所

指定クライアント・グループ

X

X

X

X

X

X

X

X

指定クライアント

X

X

X

X

X

X

X

X

クライアントIP

X

X

クライアント言語

クライアント言語

X

X

X

X

X

X

X

X

クライアント・ネットワーク

クライアントの国

X

X

X

X

X

X

X

X

クライアント・プロバイダ

X

X

X

X

クライアント・ネットワーク

X

X

X

X

クライアントIP

X

X

クライアントの場所

クライアントの国

X

X

X

X

X

X

X

X

クライアントの地域

X

X

X

X

クライアントの市区町村

X

X

X

X

クライアントIP

X

X

クライアントOS

クラス

X

X

X

X

バージョン

X

X

X

X

ドメイン

名前

X

X

X

X

ページ配信

型

X

X

X

X

X

X

X

X

詳細

X

X

X

X

X

X

X

X

ページURL

グループ

X

X

X

X

URL

X

X

X

X

完全なURL

X

X

サーバーIP

IP

X

X

X

X

サーバー指定の場所

グループ

X

X

X

X

名前

X

X

X

X

ユーザーID

グループ

X

X

X

X

X

X

X

X

ID

X

X

X

X

X

X

X

X

ADFアクション

ADFアクション

X

X

X

X

ADFアクティビティ

ADFリージョン

X

X

ADFコンポーネント・タイプ

X

X

X

X

ADFコンポーネント名

X

X

X

X

ADFコンポーネントのクライアントID

名前

X

X

ADFコンポーネントの表示名

名前

X

X

X

X

ADFコンポーネント・タイプ

名前

X

X

X

X

ID

X

X

X

X

ADFイベント・タイプ

名前

X

X

X

X

ADFページ更新

名前

X

X

X

X

ADFリージョン

ID

X

X

ADFタスクフロー

名前

X

X

X

X

ID

X

X

X

X

ADFビュー

名前

X

X

X

X

アプリケーション

X

X

X

X

タスクフロー

X

X

X

X

ビューID

X

X

X

X

ADFビューID

名前

X

X

X

X

Fusionアクティビティ

地域

X

X

X

X

コンポーネント・タイプ

X

X

X

X

コンポーネント

X

X

X

X

コンポーネントのクライアントID

X

X

X

X

FusionコンポーネントのクライアントID

名前

X

X

X

X

Fusionコンポーネントの表示名

名前

X

X

X

X

Fusionコンポーネント・タイプ

名前

X

X

X

X

ID

X

X

X

X

Fusionコンテキスト・ルート

ID

X

X

Fusionイベント・タイプ

名前

X

X

X

X

Fusionページ更新

名前

X

X

X

X

Fusion製品ファミリ

名前

X

X

X

X

短縮名

X

X

X

X

Fusionリージョン

ID

X

X

X

X

Fusionタスク・フロー

名前

X

X

X

X

ID

X

X

X

X

Fusionビュー

名前

X

X

X

X

Product

X

X

X

X

タスク・フロー

X

X

X

X

ビューID

X

X

FusionビューID

FusionビューID

X

X

V.9 PeopleSoftアプリケーション

表V-9 PeopleSoftアプリケーション

PeopleSoft

ディメンション

5

H

D

M

アプリケーション言語

値

X

X

X

アプリケーション・テリトリ

値

X

X

X

クライアント・ブラウザ

型

X

X

X

X

詳細

X

X

クライアント・デバイス

デバイス

X

X

X

X

ブランド

X

X

モデル

X

クライアント指定の場所

グループ

X

X

X

X

名前

X

X

X

X

IP

X

クライアント言語

クライアント言語

X

X

X

X

クライアント・ネットワーク

国

X

X

X

X

プロバイダ

X

X

ネットワーク

X

X

IP

X

クライアントの場所

国

X

X

X

X

地域

X

X

市区町村

X

X

IP

X

クライアントOS

クラス

X

X

バージョン

X

X

ドメイン

名前

X

X

ページ配信

型

X

X

X

X

詳細

X

X

X

X

ページURL

グループ

X

X

URL

X

X

完全なURL

X

PeopleSoftコンテンツ

ID

X

X

PeopleSoft終了ノード

名前

X

X

X

X

ID

X

X

PeopleSoftフォルダ・パス

ID

X

X

PeopleSoft ICaction

名前

X

X

X

X

ID

X

X

X

X

PeopleSoftノード名

名前

X

X

X

X

ID

X

X

X

X

PeopleSoftパネル・アイテム

名前

X

X

X

X

ID

X

X

X

X

PeopleSoftポータル名

名前

X

X

X

X

ID

X

X

X

X

PeopleSoftサイト名

名前

X

X

X

X

ID

X

X

X

X

PeopleSoftビュー

名前

X

X

X

X

ポータル

X

X

X

X

ノード

X

X

X

X

コンテンツ

X

X

サーバーIP

IP

X

X

サーバー指定の場所

グループ

X

X

名前

X

X

ユーザーID

グループ

X

X

X

X

ID

X

X

X

X

V.10 FLEXCUBE Bankingアプリケーション

表V-10 FLEXCUBE DirectおよびUniversal B Fusionアプリケーション

Direct Banking

Universal Banking

ディメンション

5

H

D

M

5

H

D

M

アプリケーション言語

値

X

X

X

X

X

X

アプリケーション・テリトリ

値

X

X

X

X

X

X

クライアント・ブラウザ

型

X

X

X

X

X

X

X

X

詳細

X

X

X

X

クライアント・デバイス

クラス

X

X

X

X

X

X

X

X

ブランド

X

X

X

X

モデル

X

X

クライアント指定の場所

指定クライアント・グループ

X

X

X

X

X

X

X

X

指定クライアント

X

X

X

X

X

X

X

X

クライアントIP

X

X

クライアント言語

言語

X

X

X

X

X

X

X

X

クライアント・ネットワーク

国

X

X

X

X

X

X

X

X

プロバイダ

X

X

X

X

ネットワーク

X

X

X

X

IP

X

X

クライアントの場所

国

X

X

X

X

X

X

X

X

地域

X

X

X

X

市区町村

X

X

X

X

IP

X

X

クライアントOS

クラス

X

X

X

X

バージョン

X

X

X

X

ドメイン

名前

X

X

X

X

ページ配信

型

X

X

X

X

X

X

X

X

詳細

X

X

X

X

X

X

X

X

ページURL

グループ

X

X

X

X

URL

X

X

X

X

完全なURL

X

X

サーバーIP

IP

X

X

X

X

サーバー指定の場所

グループ

X

X

X

X

名前

X

X

X

X

ユーザーID

グループ

X

X

X

X

X

X

X

X

ID

X

X

X

X

X

X

X

X

FC Direct Bankingチャネル

名前

X

X

X

X

コード

X

X

X

X

FC Direct Bankingポータル

名前

X

X

X

X

コード

X

X

X

X

FC Direct Bankingユーザー・タイプ

名前

X

X

X

X

コード

X

X

X

X

FC Direct Bankingビュー

名前

X

X

X

X

コード

X

X

X

X

ポータル

X

X

X

X

FC Universal Bankingアクション

名前

X

X

コード

X

X

FC Universal Bankingアクティビティ

従属画面

X

X

アクション

X

X

FC Universal Bankingブランチ

名前

X

X

X

X

コード

X

X

X

X

FC Universal Bankingモジュール

名前

X

X

X

X

コード

X

X

X

X

FC Universal Banking画面

名前

X

X

X

X

コード

X

X

X

X

FC Universal Banking従属画面

名前

X

X

コード

X

X

FC Universal Bankingビュー

名前

X

X

X

X

モジュール

X

X

X

X

画面

X

X

X

X

V.11 JD Edwards EnterpriseOneアプリケーション

表V-11 JD Edwards EnterpriseOneアプリケーション

JD Edwards

ディメンション

5

H

D

M

アプリケーション言語

値

X

X

X

アプリケーション・テリトリ

値

X

X

X

クライアント・ブラウザ

型

X

X

X

X

詳細

X

X

クライアント・デバイス

デバイス

X

X

X

X

ブランド

X

X

モデル

X

クライアント指定の場所

グループ

X

X

X

X

名前

X

X

X

X

IP

X

クライアント言語

クライアント言語

X

X

X

X

クライアント・ネットワーク

国

X

X

X

X

プロバイダ

X

X

ネットワーク

X

X

IP

X

クライアントの場所

国

X

X

X

X

地域

X

X

市区町村

X

X

IP

X

クライアントOS

クラス

X

X

バージョン

X

X

ドメイン

名前

X

X

JD Edwardsアクション

名前

X

X

X

X

ID

X

X

X

X

JD Edwardsアプリケーション

名前

X

X

X

X

ID

X

X

X

X

JD Edwards環境

名前

X

X

X

X

JD Edwardsフォーム

名前

X

X

X

X

ID

X

X

X

X

JD Edwards製品

名前

X

X

X

X

コード

X

X

X

X

JD Edwardsビュー

名前

X

X

X

X

Product

X

X

X

X

アプリケーション

X

X

X

X

フォーム

X

X

X

X

ページ配信

型

X

X

X

X

詳細

X

X

X

X

ページURL

グループ

X

X

URL

X

X

完全なURL

X

JD Edwardsアクション

名前

X

X

X

X

ID

X

X

X

X

サーバーIP

IP

X

X

サーバー指定の場所

グループ

X

X

名前

X

X

ユーザーID

グループ

X

X

X

X

ID

X

X

X

X

V.12 WebLogic Portal

表V-12 WebLogic Portal

WebLogic

ディメンション

5

H

D

M

アプリケーション言語

値

X

X

X

アプリケーション・テリトリ

値

X

X

X

クライアント・ブラウザ

型

X

X

X

X

詳細

X

X

クライアント・デバイス

デバイス

X

X

X

X

ブランド

X

X

モデル

X

クライアント指定の場所

グループ

X

X

X

X

名前

X

X

X

X

IP

X

クライアント言語

クライアント言語

X

X

X

X

クライアント・ネットワーク

国

X

X

X

X

プロバイダ

X

X

ネットワーク

X

X

IP

X

クライアントの場所

国

X

X

X

X

地域

X

X

市区町村

X

X

IP

X

クライアントOS

クラス

X

X

バージョン

X

X

ドメイン

名前

X

X

ページ配信

型

X

X

X

X

詳細

X

X

X

X

ページURL

グループ

X

X

URL

X

X

完全なURL

X

サーバーIP

IP

X

X

サーバー指定の場所

グループ

X

X

名前

X

X

ユーザーID

グループ

X

X

X

X

ID

X

X

X

X

WLPアクション

アクション

X

X

X

X

WLPブック

名前

X

X

X

X

WLPデスクトップ

名前

X

X

X

X

WLPページ

名前

X

X

X

X

WLPポータル

名前

X

X

X

X

WLPポートレット

名前

X

X

X

X

WLPビュー

名前

X

X

X

X

webapp

X

X

X

X

デスクトップ

X

X

X

X

ページ

X

X

X

X

WLP Webアプリケーション

名前

X

X

X

X

V.13 WebCenterアプリケーション

表V-13 WebCenterアプリケーション

WebCenter

ディメンション

5

H

D

M

アプリケーション言語

値

X

X

X

アプリケーション・テリトリ

値

X

X

X

クライアント・ブラウザ

型

X

X

X

X

詳細

X

X

クライアント・デバイス

デバイス

X

X

X

X

ブランド

X

X

モデル

X

クライアント指定の場所

グループ

X

X

X

X

名前

X

X

X

X

IP

X

クライアント言語

クライアント言語

X

X

X

X

クライアント・ネットワーク

国

X

X

X

X

プロバイダ

X

X

ネットワーク

X

X

IP

X

クライアントの場所

国

X

X

X

X

地域

X

X

市区町村

X

X

IP

X

クライアントOS

クラス

X

X

バージョン

X

X

ドメイン

名前

X

X

ページ配信

型

X

X

X

X

詳細

X

X

X

X

ページURL

グループ

X

X

URL

X

X

完全なURL

X

サーバーIP

IP

X

X

サーバー指定の場所

グループ

X

X

名前

X

X

ユーザーID

グループ

X

X

X

X

ID

X

X

X

X

WebCenterコンポーネントのクライアントID

名前

X

X

X

X

WebCenterコンポーネントの表示名

名前

X

X

X

X

WebCenterコンポーネント・タイプ

名前

X

X

X

X

ID

X

X

X

X

WebCenter SitesコンテンツID

ID

X

X

X

X

WebCenter Sitesコンテンツ名

名前

X

X

X

X

WebCenter Sitesサブタイプ

名前

X

X

X

X

WebCenter Sitesタイプ

名前

X

X

X

X

WebCenterイベント・タイプ

名前

X

X

X

X

WebCenterフレームワーク

名前

X

X

X

X

WebCenterページ

名前

X

X

X

X

WebCenterページ更新

名前

X

X

X

X

WebCenter Portalアクティビティ

地域

X

X

X

X

コンポーネント・タイプ

X

X

X

X

コンポーネント名

X

X

X

X

コンポーネントID

X

X

X

X

WebCenter Portalビュー

名前

X

X

X

X

ビューID

X

X

X

X

WebCenter Sites推奨事項(使用中)

名前

X

X

X

X

WebCenterコンテンツ

名前

X

X

X

X

WebCenterサービス

名前

X

X

X

X

フレームワーク

X

X

X

X

WebCenter Sitesチャネル

名前

X

X

X

X

WebCenter Sites名

名前

X

X

X

X

WebCenter Sitesビュー

名前

X

X

X

X

テンプレート

X

X

X

X

コンテンツ

X

X

X

X

コンテンツID

X

X

X

X

WebCenterスペースの表示名

名前

X

X

X

X

ID

X

X

X

X

WebCenterスペース・タイプ

名前

X

X

X

X

WebCenterスペース・ビュー

型

X

X

X

X

名前

X

X

X

X

WebCenterタスクフロー

名前

X

X

X

X

ID

X

X

X

X

WebCenter Sitesテンプレート

名前

X

X

X

X

WebCenterユーザー入力

名前

X

X

X

X

WebCenter Sitesユーザー・セグメント

名前

X

X

X

X

WebCenterビューID

名前

X

X

W イベント・ログ・コードの説明

この付録では、イベント・ログにレポートされるメッセージについて説明します。イベント・ログの使用は、15.7項「イベント・ログの使用」に記載されています。

表W-1 イベント・ログ・メッセージの説明

コード

メッセージ

説明

10000

コレクタは正常に起動しました

コレクタは、システムによって正常に起動しました。

10001

コレクタは正常に終了しました

コレクタは、スケジュールされた条件(たとえば、構成設定の変更を適用する必要があるなど)で終了しました。

10002

コレクタは終了し、初期化に失敗しました

回復できない構成エラーのため、コレクタが起動中に終了しました。

10003

コレクタのメモリーが不足しています

コレクタのメモリー使用率が構成されたしきい値を超えました。

10004

コレクタは他の理由で終了しました

不明な理由によって、コレクタが予期せず終了しました。

10005

コレクタはセグメンテーション・フォルトで終了しました

プログラム・クラッシュによって、コレクタが予期せず終了しました。

10010

コレクタはウォッチドッグにより起動されました

コレクタがウォッチドッグ・プロセスによって起動しました。以前に予期せず終了した場合、この可能性が高くなります。

10011

コレクタはウォッチドッグにより停止されました

エラー条件(たとえば、プログラムがメモリー不足または停止しているなど)のため、コレクタがウォッチドッグ・プロセスによって停止しました。実際のエラーが別々にレポートされます。

10020

トラフィック収集に適したインタフェースが見つかりません

データの監視に使用できるネットワーク・インタフェースが見つからないため、コレクタを起動できません。通常、インタフェースにIPアドレスがあるためです。

10030

プライマリ・システムを使用できません: スタンバイをアクティブ化します

高可用性環境で、プライマリ・システムを使用できなくなりました。フェイルオーバー・システムがアクティブになって引き継ぎます。

10031

スタンバイ・システムを使用できません

高可用性環境で、フェイルオーバー・システムを使用できなくなりました。

10050

構成の変更がアクティブになりました

保留中の構成変更が正常に適用されました。

10051

トラフィック・フィルタの変更がアクティブになりました

ネットワーク・トラフィック・フィルタに関連する構成変更が正常に適用されました。

10052

マスキングの変更がアクティブになりました

データ・マスキングに関連する構成変更が正常に適用されました。

10053

コンテンツ・スキャンの変更がアクティブになりました

コンテンツに関連する構成の変更(たとえば、エラー文字列およびHTMLタイトルに基づくページ・ネーミング)が正常に適用されました。

10054

アプリケーション/スイート/サービス定義の変更がアクティブになりました

アプリケーション、サービスまたはスイート定義に関連する構成の変更が正常に適用されました。

10055

Oracle Formsの変更がアクティブになりました

Oracle Formsに関連する構成変更が正常に適用されました。

10056

リプレイ記憶域設定の変更がアクティブになりました

リプレイ・データ記憶域のサイズに関連する構成変更が正常に適用されました。

10060

構成の変更によってコレクタの再起動がトリガーされます

最新の一連の構成変更で、コレクタの再起動が必要です。これは、システムによってスケジュールおよび実行されます。

10061

トラフィック・フィルタの変更がアクティブになりました

トラフィック・フィルタリングに関連する構成変更が正常に適用されました。

10066

リプレイ記憶域設定の変更によってコレクタの再起動がトリガーされます

リプレイ・データ記憶域のサイズに関連する構成変更で、コレクタの再起動が必要です。

10100

コンテンツ・スキャンの構文エラー

コンテンツ・スキャンのパターン一致に関連する内部的な構文エラーが発生しました。

10101

%1$s KBのコンテンツ・スキャンは%2$s KBのメモリー制限に適合しません

コンテンツ・スキャン・パターン一致に関係するメモリー・バッファが小さすぎました。HTTPリクエスト当たりのスキャンについて表示されるイベント・ログ。

10102

%1$s KBのコンテンツ・スキャンは%2$s KBの空きコンテンツ・スキャン・メモリーに適合しません

コンテンツ・スキャン・パターン一致に関係するメモリー・バッファが小さすぎました。HTTPリクエスト当たりのスキャンについて表示されるイベント・ログ。

10103

%s KBのコンテンツ・スキャンはグローバル・メモリー制限に適合しません

コンテンツ・スキャン・パターン一致に関係するメモリー・バッファが小さすぎました。HTTPリクエスト当たりのスキャンについて表示されるイベント・ログ。

10104

コンテンツ・スキャンがロードされました

コレクタが新しいコンテンツ・スキャン構成を受け取って正常に適用したことを示す情報メッセージ。

10110

ログ・ファイルを最終名'%s'に移動できませんでした

現在のロギング期間に使用される一時的なHTTPログ・ファイルをディスクの最終的な場所に移動できませんでした。通常、これは、書込み/アクセス権限の問題か、パスのディレクトリ・コンポーネントが欠落していることが原因です。

10111

新しいHTTPログ・ファイル'%s'を開けませんでした

コレクタは、次のロギング期間の新しいHTTPログ・ファイルを開こうとしましたが失敗しました。通常、これは、書込み/アクセス権限の問題か、ディレクトリ・パスのコンポーネントが欠落していることが原因です。

10112

HTTP/Formsポートが構成されていません。

HTTP/Formsにポート構成が見つからないことを示す情報メッセージ。これを構成するには、「構成」→「セキュリティ」→「プロトコル」を選択します。

10200

コレクタは%1$s KBのメモリー制限を%2$s KB超えました

コレクタは、システムの動作の低下が生じる可能性がある大量のメモリーの消費を防ぐために使用されるメモリー制限で動作します。このメッセージは、コレクタが現在構成されているメモリー制限を超えたことを示します。この条件が検出されるたびに、このメッセージがレポートされ、コレクタが終了します。

10201

コレクタはメモリー制限値%1$s KBに近づいており、現在%2$s KBです

コレクタは、システムの動作の低下が生じる可能性がある大量のメモリーの消費を防ぐために使用されるメモリー制限で動作します。このメッセージは、コレクタで使用される現在のメモリーが構成された制限に近づいていることを示す警告です。

10300

ヒット時間%1$s: POST変数は%2$sバイトで切り捨てられました: %3$s

POSTメッセージの内容は、処理中にコレクタによってバッファされます。メッセージが現在の内部バッファ制限を超えるたびに、このメッセージがレポートされます。

10301

POSTリクエストは%1$sバイト(合計バイト%2$s)で切り捨てられました

POSTメッセージの内容は、処理中にコレクタによってバッファされます。メッセージが現在の内部バッファ制限を超えるたびに、このメッセージがレポートされます。

10400

スレッドnpa%1$s: ハートビートが見つかりません。コレクタを再起動します

内部エラーによって、コレクタのトラフィック処理スレッドがロックされました。スレッドをリセットするため、コレクタを再起動する必要があります。

10500

コレクタが受信するトラフィックが多すぎるため、新規接続を削除して負荷を低減します

コレクタは、処理の待機中のトラフィックの処理およびネットワーク・パケットのキューイングに使用されるメモリーを割り当てます。大量のトラフィックを受信すると、キューが制御できないほど大きくなる可能性があります。これを防ぐため、コレクタは、新しいTCPセッションの削除を開始します。キューを管理するため、既存のセッションがまだ処理されていることに注意してください。

10501

コレクタが受信するトラフィックが多すぎるため、すべての新規データを削除して負荷を低減します

新しいTCPセッションを削除してトラフィックの負荷を低減しましたが、キューの過負荷が軽減しませんでした。メモリー不足の実行を回避するため、コレクタは、新しいデータの処理を停止し、現在キューにあるパケットのみを処理します。

10502

コレクタの負荷がしきい値を下回っているため、通常のデータ収集を再開します

パケット・キューが十分に排出されました。コレクタは、すべてのトラフィックを再処理できます。

10601

HTTPヘッダー%sを削除します: ヘッダーが多すぎます

コレクタの構成されたカスタム・ヘッダーの数が64を超えるたびに、このメッセージがレポートされます。カスタム・ヘッダーは、HTTPヘッダー・フィールド(ユーザーID、カスタム・ディメンション、Webサイト・エラーなど)で入力されるすべてのRUEI構成アイテムによって生成されます。

10700

コレクタの処理中、最大%1$sバイトのフレームが出現しました。推奨される最大フレーム・サイズの設定は%2$s KBです。

現在の構成済フレーム・サイズより大きいパケットにコレクタが遭遇すると、このメッセージは報告されます。処置: フレーム・サイズを推奨値に構成してください。これを行うには、「構成」→「セキュリティ」→「超特大フレーム」を選択します。

19998

内部エラー(%s)

このメッセージは、汎用的な内部エラーが発生したことをレポートします。

19999

%s

このメッセージは、汎用的な内部エラーが発生したことをレポートします。

20000

メッセージのしきい値(%1$s)を超えました。

単一のプロセスが短期間に生成できるメッセージの数は、制限されています。このメッセージは、制限に達し、追加のメッセージがプロセスに対して記録されないことを示します。

20001

ジョブが終了コード%1$sで終了しました(%2$s)。

処理ジョブが失敗しました(汎用メッセージ)。

20002

コレクタ%1$s (%2$)は使用できません。

HTTPログ・ファイルをフェッチするコレクタへのSSH接続を実行できなかった場合にレポートされます。

20003

%1$sの再同期が終了コード%2$sで失敗しました(%3$s)。

コレクタのHTTPログ・ファイルのフェッチに失敗しました。

20004

データベースに接続できません。

いずれかのジョブで、データベースに接続できませんでした。

20005

ファイル%1$sを読取り用に開けません。

システム・ファイルを開けませんでした(汎用メッセージ)。

20006

ファイル%1$sを書込み用に開けません。

システム・ファイルに書き込めませんでした(汎用メッセージ)。

20007

データベース使用率はアラートしきい値(%1$s%%)未満です

データベース使用率が構成されているアラートしきい値を下回るレベルに戻りました。

20008

データベース使用率は現在のアラートしきい値(%1$s%%)を超えています。

構成されたアラートのデータベース使用率がしきい値を超えました。データベースの最大サイズを確認することをお薦めします。

20009

データベース使用率は現在の停止しきい値(%1$s%%)を超えているため、データ処理を保留します。

構成された最大のデータベース使用率がしきい値を超えました。管理メカニズムによってデータベースのサイズが許容された境界内に戻るまで、新しいデータがデータベースに書き込まれなくなります。

20010

ディスク使用率はアラートしきい値(%1$s%%)未満です

ディスク領域使用率が構成されているアラートしきい値を下回るレベルに戻りました。

20011

ディスク使用率は現在のアラートしきい値(%1$s%%)を超えています。

構成されたアラートのディスク使用率がしきい値を超えました。システムのディスク領域の可用性を確認することをお薦めします。

20012

ディスク使用率は現在の停止しきい値(%1$s%%)を超えています。

構成された最大のディスク使用率がしきい値を超えました。管理メカニズムによってディスク使用率が許容された境界内に戻るまで、新しいデータがファイル・システムに書き込まれなくなります。

20020

%1$sの再同期は、%2$s時間経過しましたが、まだ終了コード%3$sで失敗します(%4$s)。

20003と同じです。コレクタのログ・ファイルの再同期に失敗すると、毎時間繰り返されます。

20021

%1$s時間経過しましたが、まだデータベースに接続できません。

20004と同じです。データベースの接続に失敗すると、毎時間繰り返されます。

20022

コレクタ%1$s (%2$s)は、%3$s時間経過しましたが、まだ使用できません。

20002と同じです。コレクタのSSH接続に失敗すると、毎時間繰り返されます。

20030

ログ・ファイル・プロセッサでスレッドのデッドロックが検出されたため、コア・ダンプを強制実行します

内部エラーがログ・ファイルの処理で発生しました。データ処理に影響し、レポートが不正確になる場合があります。

20031

ジョブ・スケジューラが起動されました。

情報メッセージです。

20032

ログ・ファイル・プロセッサで使用されたメモリーがメモリー全体の%1$s%を超えました(%2$s MB)。

ログ・ファイル・プロセッサのメモリー制限に達し、終了しました。自動的に再起動しますが、システムの物理メモリー量を増やすため、対処する必要があります。

20033

コンテンツ・マスキング情報がコレクタ%1$s (%2$s)にロードされていません。

コレクタに正常にアップロードされていないマスキングに関係する構成の変更を示す警告メッセージ。推奨する処置は、コレクタに新規の更新を強制するために、追加のマスキング変更を行うことです。

20034

フォーム情報がコレクタ%1$s (%2$s)にアップロードされていません。

コレクタに正常にアップロードされていないEBS Formsに関係する構成の変更を示す警告メッセージ。推奨する処置は、コレクタに新規更新を強制するために、EBS Formsの追加変更を行うことです。

20035

無効なイベント・ログ・ファイル: %1$s

データ・ファイルが破損していることがわかりました。1分間のデータが失われています。

20036

コンテンツ・スキャン構成がコレクタ%1$s (%2$s)にロードされていません。

コレクタに正常にアップロードされていないコンテンツ・スキャンに関係する構成の変更を示す警告メッセージ。推奨する処置は、コレクタに新規更新を強制するために、コンテンツ・スキャンの追加変更を行うことです。

20037

レポートするヘッダーがコレクタ%1$s (%2$s)にアップロードされていません。

コレクタに正常にアップロードされていないHTTPヘッダー取得に関係する構成の変更を示す警告メッセージ。推奨する処置は、コレクタに新規更新を強制するために、HTTPヘッダー取得の追加変更を行うことです。

20038

コマンドがシグナル%1$sで終了しました(%2$s)。

システム・ジョブがエラーで終了しました。

20039

データベースへの接続が%1$s分後にタイムアウトになりました。

示された期間中に何度も試行しましたが、データベースの接続を実行できませんでした。

20040

データ処理が測定対象のトラフィック量に追いつきませんでした。

すべての処理ジョブを5分以内に完了できなかった場合にレポートされます。システムが過負荷であることを示す場合があります。頻繁に発生しない場合は無視してください。

20041

過去%1$s分間に新しいログ・ファイルがありませんでした

コレクタ・ログ・ファイルが処理エンジンに到達していないことを示します。

20044

ログ・ファイル処理が開始されました。

情報メッセージです。

20045

ログ・ファイル処理が終了ステータス%1$sで停止しました。

ログ・ファイル処理を中断したエラーがあります。このコンポーネントは自動的に再開します。

20046

ログ・ファイル・プロセッサのコア・ダンプ

ログ・ファイル・プロセッサがクラッシュしました。このコンポーネントは自動的に再開します。

20047

ログ・ファイル処理が停止しました(親プロセスが存在しません)。

内部エラーのため、ログ・ファイル処理が停止しました。このコンポーネントは自動的に再開します。

20048

ログ・ファイル・プロセッサの初期化に失敗しました。

内部エラーのため、ログ・ファイル処理を開始できません。カスタマ・サポートに問い合せることを強くお薦めします。

20049

ログ・ファイル・プロセッサの再初期化に失敗しました。再起動しています

内部エラーのため、ログ・ファイル処理を再開できません。

20050

プロファイル・リプレイ構成の更新に失敗しました。

内部エラーのため、構成変更を適用できませんでした。

20051

コマンドが終了ステータス%1$sで終了しました。

システム・ジョブに失敗しました。

20052

アプリケーション一致情報がコレクタ%1$s (%2$s)にロードされていません。

構成変更をコレクタに伝播できませんでした。レポータ・システムおよびコレクタ・システム間の接続を確認することをお薦めします。

20053

ヒット・タイプ一致情報がコレクタ%1$s (%2$s)にロードされていません。

構成変更をコレクタに伝播できませんでした。レポータ・システムおよびコレクタ・システム間の接続を確認することをお薦めします。

20054

HTTP WebDAV使用可能情報がコレクタ%1$s (%2$s)にロードされていません。

構成変更をコレクタに伝播できませんでした。レポータ・システムおよびコレクタ・システム間の接続を確認することをお薦めします。

20055

HTTPプロキシ・ヘッダー情報がコレクタ%1$s (%2$s)にロードされていません。

構成変更をコレクタに伝播できませんでした。レポータ・システムおよびコレクタ・システム間の接続を確認することをお薦めします。

20056

データベースに接続できないため、再試行します。

データベースの接続に失敗しました。自動的に再試行します。

20057

コレクタ%1$s (%2$s)への構成のアップロードに失敗しました。

構成変更をコレクタに伝播できませんでした。レポータ・システムおよびコレクタ・システム間の接続を確認することをお薦めします。

20058

コレクタ%1$s (%2$s)への構成のアップロードがタイムアウトになったため、再試行します。

構成変更をコレクタに伝播できませんでした。レポータ・システムおよびコレクタ・システム間の接続を確認することをお薦めします。

20059

%1$s回の試行後にデータベースに接続されました

データベースの接続が以前に失敗しましたが、現在は成功しています。

20060

構成はすでに最新になっているので、インスタンス%1$sに対してリクエストされた再起動は必要ありません。

以前にスケジュールしたコレクタの再起動が不要になったことが確認されました。

20061

フェイルオーバー: プライマリ・レポータが停止し、スタンバイ・レポータ(ホスト=%1$s)へのフェイルオーバーがトリガーされました。

高可用性の設定で、プライマリ・レポータ・システムに失敗し、フェイルオーバー・レポータ・システムが引き継ぎました。

20062

フェイルオーバー: プライマリ・レポータ(ホスト=%1$s): スタンバイ・レポータが停止している可能性があります。

高可用性の設定で、プライマリ・レポータ・システムがフェイルオーバー・レポータ・システムを使用できなくなったことを検出しました。

20063

%1$sを超えるCookieが定義されました: Cookie %2$sを無視します。

構成可能なセッションCookieの数の制限に達しました。セッション・トラッキング構成設定を確認することをお薦めします。

20064

数回の試行後にデータベースに接続されました。

データベースに接続する以前の試行に失敗しましたが、現在は接続に成功しています。

29006

バックアップが作成されました。

RUEIシステム構成バックアップが作成されました。

29007

バックアップがリストアされました。

RUEIシステム・バックアップがリストアされました。

29008

システムが工場出荷時のデフォルトにリセットされました。

「出荷時のデフォルトにリセット」オプションがシステム・リセット・ウィザードから選択されました。

29009

データがパージされました。

「収集したデータのパージ」オプションがシステム・リセット・ウィザードから選択されました。

29010

システム処理が再開されました。

「システム処理の再起動」オプションがシステム・リセット・ウィザードから選択されました。

29011

問題を解決するために強制的に再構成します。

システム・リセット・ウィザードから「最新構成の再適用」オプションを選択する必要があります。

29012

ホスト%1$s: タイムゾーンが異なります: %2$sであり、%3$sではありません。

レポータから異なるタイム・ゾーンを使用して、示されたホストが検出されました。すべてのシステム・ホストは、同じタイム・ゾーンを使用する必要があります。

29013

ホスト%1$s: 時刻同期されておらず、差分は%2$s秒です。

レポータとの時間差が非常に大きいため、この示されたホストが検出されました。すべてのシステム・ホストをほぼ同じシステム時間設定にする必要があります。

29014

ホスト%1$s: リプレイ・データをEPRにコピーするためにリモート・サーバーに接続できませんでした

コレクタに達することができませんでした。この結果、一部のセッション・リプレイ・データが失われました。

29998

内部エラー(%1$s)。

このメッセージは、汎用的な内部エラーが発生したことをレポートします。

29999

%1$s

汎用情報メッセージです。

X サード・パーティ・ライセンス

この付録には、このバージョンのRUEIに含まれる特定のサード・パーティ製品のライセンス情報を記載します。特に記載がないかぎり、ここに記載されたすべてのライセンスは情報提供のみを目的とします。

この付録の各項で、次のサード・パーティ・ライセンスを記載します。

- Apache Software License, Version 2.0

- OpenSSL

- PHP

- Java Runtime Environment

- MIT License (MIT)

X.1 Apache Software License, Version 2.0

Apache License

Version 2.0, January 2004

http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions."License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity.For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.

"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship.For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner.For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."

"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License.Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License.Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution.You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

- You must give any other recipients of the Work or Derivative Works a copy of this License; and

- You must cause any modified files to carry prominent notices stating that You changed the files; and

- You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

- If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear.The contents of the NOTICE file are for informational purposes only and do not modify the License.You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions.Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions.Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks.This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty.Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability.In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability.While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License.However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work.

To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information.(Don't include the brackets!)The text should be enclosed in the appropriate comment syntax for the file format.We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives.

Copyright [yyyy] [name of copyright owner]

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.See the License for the specific language governing permissions and limitations under the License.

X.2 OpenSSL

この製品には、OpenSSL Toolkitで使用するためのOpenSSL Projectの開発によるソフトウェアが含まれています(http://www.openssl.org)。

Copyright © 1998-2011 The OpenSSL Project.All rights reserved.次の場所にあるライセンスに従って配布されます。

http://www.openssl.org/source/license.html

X.3 PHP

Copyright © 1999-2013 The PHP Group.All rights reserved.

この製品には、http://php.net/software/から無償で入手可能なPHPソフトウェアが含まれています。次の場所にあるライセンスに従って配布されます。

http://creativecommons.org/licenses/by/3.0/legalcode

X.4 Java Runtime Environment

ORACLE AMERICA, INC.("ORACLE"), FOR AND ON BEHALF OF ITSELF AND ITS SUBSIDIARIES AND AFFILIATES UNDER COMMON CONTROL, IS WILLING TO LICENSE THE SOFTWARE TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS BINARY CODE LICENSE AGREEMENT AND SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT").PLEASE READ THE AGREEMENT CAREFULLY.BY SELECTING THE "ACCEPT LICENSE AGREEMENT" (OR THE EQUIVALENT) BUTTON AND/OR BY USING THE SOFTWARE YOU ACKNOWLEDGE THAT YOU HAVE READ THE TERMS AND AGREE TO THEM.IF YOU ARE AGREEING TO THESE TERMS ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE LEGAL AUTHORITY TO BIND THE LEGAL ENTITY TO THESE TERMS.IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT WISH TO BE BOUND BY THE TERMS, THEN SELECT THE "DECLINE LICENSE AGREEMENT" (OR THE EQUIVALENT) BUTTON AND YOU MUST NOT USE THE SOFTWARE ON THIS SITE OR ANY OTHER MEDIA ON WHICH THE SOFTWARE IS CONTAINED.

1. DEFINITIONS."Software" means the software identified above in binary form that you selected for download, install or use (in the version You selected for download, install or use) from Oracle or its authorized licensees, any other machine readable materials (including, but not limited to, libraries, source files, header files, and data files), any updates or error corrections provided by Oracle, and any user manuals, programming guides and other documentation provided to you by Oracle under this Agreement."General Purpose Desktop Computers and Servers" means computers, including desktop and laptop computers, or servers, used for general computing functions under end user control (such as but not specifically limited to email, general purpose Internet browsing, and office suite productivity tools).The use of Software in systems and solutions that provide dedicated functionality (other than as mentioned above) or designed for use in embedded or function-specific software applications, for example but not limited to: Software embedded in or bundled with industrial control systems, wireless mobile telephones, wireless handheld devices, netbooks, kiosks, TV/STB, Blu-ray Disc devices, telematics and network control switching equipment, printers and storage management systems, and other related systems are excluded from this definition and not licensed under this Agreement."Programs" means: (a) Java technology applets and applications intended to run on the Java Platform, Standard Edition platform on Java-enabled General Purpose Desktop Computers and Servers, and (b) JavaFX technology applications intended to run on the JavaFX Runtime on JavaFX-enabled General Purpose Desktop Computers and Servers. ”README File” means the README file for the Software set forth in the Software or otherwise available from Oracle at or through the following URL:

http://www.oracle.com/technetwork/java/javase/documentation/index.html

2. LICENSE TO USE.Subject to the terms and conditions of this Agreement including, but not limited to, the Java Technology Restrictions of the Supplemental License Terms, Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs.

3. RESTRICTIONS.Software is copyrighted.Title to Software and all associated intellectual property rights is retained by Oracle and/or its licensors.Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software.You acknowledge that the Software is developed for general use in a variety of information management applications; it is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury.If you use the Software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use.Oracle disclaims any express or implied warranty of fitness for such uses.No right, title or interest in or to any trademark, service mark, logo or trade name of Oracle or its licensors is granted under this Agreement.Additional restrictions for developers and/or publishers licenses are set forth in the Supplemental License Terms.

4. DISCLAIMER OF WARRANTY.THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.ORACLE FURTHER DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT.

5. LIMITATION OF LIABILITY.IN NO EVENT SHALL ORACLE BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR DATA USE, INCURRED BY YOU OR ANY THIRD PARTY, WHETHER IN AN ACTION IN CONTRACT OR TORT, EVEN IF ORACLE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.ORACLE'S ENTIRE LIABILITY FOR DAMAGES HEREUNDER SHALL IN NO EVENT EXCEED ONE THOUSAND DOLLARS (U.S. $1,000).

6. TERMINATION.This Agreement is effective until terminated.You may terminate this Agreement at any time by destroying all copies of Software.This Agreement will terminate immediately without notice from Oracle if you fail to comply with any provision of this Agreement.Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right.Upon termination, you must destroy all copies of Software.

7. EXPORT REGULATIONS.You agree that U.S. export control laws and other applicable export and import laws govern your use of the Software, including technical data; additional information can be found on Oracle's Global Trade Compliance web site (http://www.oracle.com/products/export).You agree that neither the Software nor any direct product thereof will be exported, directly, or indirectly, in violation of these laws, or will be used for any purpose prohibited by these laws including, without limitation, nuclear, chemical, or biological weapons proliferation.

8. TRADEMARKS AND LOGOS.You acknowledge and agree as between you and Oracle that Oracle owns the ORACLE and JAVA trademarks and all ORACLE- and JAVA-related trademarks, service marks, logos and other brand designations ("Oracle Marks"), and you agree to comply with the Third Party Usage Guidelines for Oracle Trademarks currently located at http://www.oracle.com/us/legal/third-party-trademarks/index.html.Any use you make of the Oracle Marks inures to Oracle's benefit.

9. U.S. GOVERNMENT LICENSE RIGHTS.If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation shall be only those set forth in this Agreement.

10. GOVERNING LAW.This agreement is governed by the substantive and procedural laws of California.You and Oracle agree to submit to the exclusive jurisdiction of, and venue in, the courts of San Francisco, or Santa Clara counties in California in any dispute arising out of or relating to this agreement.

11. SEVERABILITY.If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate.

12. INTEGRATION.This Agreement is the entire agreement between you and Oracle relating to its subject matter.It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement.No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party.

SUPPLEMENTAL LICENSE TERMS

These Supplemental License Terms add to or modify the terms of the Binary Code License Agreement.Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Binary Code License Agreement.These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Binary Code License Agreement, or in any license contained within the Software.

A.SOFTWARE INTERNAL USE FOR DEVELOPMENT LICENSE GRANT.Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the README File incorporated herein by reference, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce internally and use internally the Software complete and unmodified for the purpose of designing, developing, and testing your Programs.

B.LICENSE TO DISTRIBUTE SOFTWARE.Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the README File, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Oracle's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Oracle and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.The license set forth in this Section B does not extend to the Software identified in Section D.

C.LICENSE TO DISTRIBUTE REDISTRIBUTABLES.Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the README File, including but not limited to the Java Technology Restrictions of these Supplemental Terms, Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute those files specifically identified as redistributable in the README File ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified, and only bundled as part of Programs, (ii) the Programs add significant and primary functionality to the Redistributables, (iii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README File), (iv) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (v) you only distribute the Redistributables pursuant to a license agreement that protects Oracle's interests consistent with the terms contained in the Agreement, (vi) you agree to defend and indemnify Oracle and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.The license set forth in this Section C does not extend to the Software identified in Section D.

D.JAVA TECHNOLOGY RESTRICTIONS.You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "javafx", "sun", ”oracle” or similar convention as specified by Oracle in any naming convention designation.You shall not redistribute the Software listed on Schedule 1.

E.SOURCE CODE.Software may contain source code that, unless expressly licensed for other purposes, is provided solely for reference purposes pursuant to the terms of this Agreement.Source code may not be redistributed unless expressly provided for in this Agreement.

F.THIRD PARTY CODE.Additional copyright notices and license terms applicable to portions of the Software are set forth in the THIRDPARTYLICENSEREADME file set forth in the Software or otherwise available from Oracle at or through the following URL: http://www.oracle.com/technetwork/java/javase/documentation/index.html.In addition to any terms and conditions of any third party opensource/freeware license identified in the THIRDPARTYLICENSEREADME file, the disclaimer of warranty and limitation of liability provisions in paragraphs 4 and 5 of the Binary Code License Agreement shall apply to all Software in this distribution.

G.TERMINATION FOR INFRINGEMENT.Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right.

H.INSTALLATION AND AUTO-UPDATE.The Software's installation and auto-update processes transmit a limited amount of data to Oracle (or its service provider) about those specific processes to help Oracle understand and optimize them.Oracle does not associate the data with personally identifiable information.You can find more information about the data Oracle collects as a result of your Software download at http://www.oracle.com/technetwork/java/javase/documentation/index.html.

For inquiries please contact: Oracle America, Inc., 500 Oracle Parkway, Redwood Shores, California 94065, USA.

License for Archived Java SE Technologies; Last updated 13 March 2012.

X.5 MIT License (MIT)

以下の条件に従って、このソフトウェアおよび関連ドキュメント・ファイル(以下「本ソフトウェア」)の複製を取得するすべての人に対して、無償で、無制限に本ソフトウェアを扱うことを許可します。これには、本ソフトウェアの複製を使用、複写、変更、結合、公開、頒布、サブライセンス許諾および/または販売する権利、ならびに本ソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれます。

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

索引
A B C D E F G H I J K L M N O P R S T U V W X

A

AD4J, 4.6

ADF, I, P

集計, E.5

アラート

データベースの使用率, 15.4

ディスクの使用率, 15.4

電子メール, 7.5.5

エスカレーション, 7.5.2

フィルタリング, 6.3.1

リスト, 6.3

ログ, 6.1.7

プロファイル, 7.5.1, 7.5.1

SNMP, 7.5.6, C.6

システム障害, 15.3

テスト, 7.5.4

テキスト・メッセージ, 7.5.7

Apache, B Application Dependency Performance (ADP), 4.6 Application Development Framework, 「ADF」を参照 アプリケーション

コンテンツ・チェック, 8.3.19

定義, 8.3

関数エラー, 8.3.13

ロードの満足度, 8.3.11

関数領域のトラップ, 8.3.13

未分類のページ, 8.3.6

ユーザー識別, 8.3.14

引数

アプリケーションの定義, 8.3

URLにおけるフィルタリング, 12.7

ページ・ネーミング, 8.3.20

ASP, B 認可フィールド, 8.3.14, 13.6

B

バックアップ, 15.6

Business Transaction Manager (BTM), 4.6

C

カレンダ, 2.6

CAMM, 4.6

カテゴリ

KPI, 6.1

変更, 2.2

プライベート, 2.2

パブリック, 2.2

レポート, 2.1

Clicktracks, A.1, A.2 クライアント識別, 10.3 クライアントのIPアドレス, 8.3.8 クライアント, 12.4 ColdFusion, B コレクタ・エンコーディング, G.4 コレクタ

リセット, 15.12

保存ポリシー, 13.9

ステータス, 15.2

ステータスの表示, 15.2

圧縮, E.5 構成ファイル, 10.1.2 構成

メール生成, 15.11

レポート・ツリー, 2.2

テキスト・メッセージ・プロバイダ, 15.8

環境, 1.5

Cookie, 12.2, B, B, R, R Coremetrics, A.1 CSV, 3.11.2 カスタム

Cookie, B

ディメンション, 3.12

ページ・タグ付け, A.1

D

ダッシュボード

作成, 5.2

テンプレート・フィルタ, 5.4

使用, 5.1

データ

カスタム・ディメンション, 3.12

遅延, C.5

エンリッチ交換, S.1

マスキング, 13.6

レポートのエクスポート, 2.13

保存ポリシー, 12.10

構造, 3.2

データ・ブラウザ

フィルタの適用, 3.9

カスタム・ディメンション, 3.12

エクスポート, 3.11

画面の構成要素, 3.1

検索, 3.5

ソート, 3.7

ビューのグループ, 3.2

データ・アイテム, E データ処理, 12.1, 15.5 定義

アプリケーション, 8.3

クライアントの場所, 12.4

Cookieテクノロジ, 12.2

KPI, 7.2

ネットワーク・フィルタ, 13.4

ユーザー・フロー, 9

Webサーバーの場所, 12.3

ディメンション

カスタム, 3.12

ページ配信, 3.2.3

無効化

アラート・プロファイル, 7.5.1

レポート・セクション, 2.8

ユーザー, 14.3

E

ECID, 4.1

電子メール

アラート, 7.5.5

構成, 15.11

レポート, 2.3

有効化

アラート・プロファイル, 7.5.1

LDAP認証, 14.8

SSO認証, 14.9

ユーザー, 14.3

Enterprise Manager, 4.6, 4.6 エラー

イベントの記録, 15.7

アプリケーションのトラップ, 8.3.13

関数コールのトラップ, 10.3.3

エスカレーション・アラート, 7.5.2 イベント・ログ, 15.7 除外フィルタ, 3.4 エクスポート

エンリッチ・データ, S.1

データ・ブラウザから, 3.11

すべてのセッション, 4.4

データの変更, 3.11.1

レポート・データ, 2.13

PDFへのレポート, 2.12

書式の選択, 3.11.2

セッション・ページ, 4.3

F

エラー・コード, D

代替セッション・トラッキング, 12.2.2

お気に入り, 2.4

フィルタ

アラート, 6.3.1, 6.3.1

適用, 3.9

定義, 3.9.1

タイプの編集, 3.9.3

除外, 3.9

包含, 3.9

反転, 3.9.1

トラフィックの制限, 13.4.3

複数, 3.9.2, 3.9.4

ネットワーク, 13.4

削除, 3.9.1

レポート, 3.9.1

VLAN, 13.4.2

FLEXCUBE, M 書式設定, 1.5 関数

ロードの満足度, 10.3.2

エラーのトラップ, 10.3.3

未分類のコール, 10.3.1

G

データ・アイテムの用語集, E

Google, A.1, B

増加(チェック・ボックス), 3.11.1

H

ヘッダー, 2.8

ヘルプデスク・レポート, C.2

Hitbox, A.1

I

アイコン

データ・ブラウザ, 3.1

インライン・レイアウト, 2.8

ユーザーのステータス, 14.1

失敗したURLの無視, 12.6 擬似オブジェクトを含む/除外, 4.1 包含フィルタ, 3.4 情報

ユーザーのマスキング, 13.6

画面, 2.8

セキュリティ関連, 13

トラフィック, 12.1, 15.5

インライン・レイアウト, 「レポート」を参照 Intellitracter, A.1

J

JavaScript, 4.2, 8.3.22

JD Edwards EnterpriseOne, O

超特大フレーム, 13.11

JVM診断, 4.6

K

KPIの概要

ドリルダウン, 6.1.6

形式, 6.1.2

ズーム・インおよびズーム・アウト, 6.1.3

KPI

自動学習, 7.3.3

比較, 6.2, 6.2

コピー, 7.3.1

定義, 7.2

間隔, 7.5.3

概要, 7.1

変更, 7.3

概要, 6.1

名前の変更, 7.3

サンプリング間隔, 7.5.3

ターゲット, 7.3.3

不完全なデータ, 6.1.5

ズーム・インおよびズーム・アウト, 6.1.3

L

LDAPサーバー, 14.8

ローカライゼーション, 8.3.15

ログアウト, 1.6

M

メール

構成, 15.11

機能, 2.3

メーリング機能, 2.3 SSL証明書プロパティのマスキング, 13.8 ユーザー情報のマスキング, 13.6, 13.6 メタリンク, C.1, N.1 Microsoft Excel, 3.11.2 Mollie, 15.8 Moniforce, A.1, B 監視

有効範囲の管理, 13

セキュア・データ, 13.5

システムのステータス, 15.3

トラフィック, 13.4.3

My Oracle Support, 4.6

N

名前付き

クライアント, 12.4

サーバー, 12.3

各国語サポート, G ネットマスク, 13.4.1 ネットワーク

フィルタ, 13.4

トラフィックの制限, 13.4.3

トラフィック, 12.1, 15.5

O

Omnitecture, A.1

概要, 「KPIの概要」を参照

P

ページ

自動割当て, 8.3.9

ユーザー・フローの構築, 9

コンテンツ・チェック, 8.3.19

失敗の無視, 12.6

ロードの満足度, 8.3.11

詳細の検索, 8.3.17

手動識別, 8.3.20

ネーミング, 8.1

POI, 8.3.16

タグ付け規則, A

未分類, 8.3.6

パスワード

変更, 1.5

セキュリティ・ポリシー, 14.6

PDFレポート, 2.12 PeopleSoft, K, N 割合(チェック・ボックス), 3.11.1 権限, 14.2.2 PHP, B POI, 8.3.16 ポリシー

コレクタによる保存, 13.9

レポータによる保存, 12.10.1

プリファレンス, 1.5 印刷レイアウト, 「レポート」を参照 プロファイル, 7.5.1 プロトコル, 13.3

R

リアルタイム・データ, 3.2.1

削除

例外, 7.4

フィルタ, 3.9.1

監視されているポート, 13.3

レポート, 2.2

ソート, 3.7

Replay Viewer

記憶域サイズ, 13.9

使用, 4.1

レポート・ツリー

カスタマイズ, 2.2

概要, 2.1

レポート

参照, 2.8

カテゴリ, 2.1

新規作成, 2.11

日付または期間, 2.6

構成要素の有効化および無効化, 2.8

エクスポート, 2.13

PDFへのエクスポート, 2.12

フィルタ, 2.7

PDFの生成, 2.12

ヘッダー, 2.8

ヘルプデスク, C.2

「情報」画面, 2.8

インライン・レイアウト, 2.10

既存の制約の変更, 2.11

構成要素, 2.8

印刷レイアウト, 2.10

実行, 3.9.3

セクション, 2.8

ツリー, 2.1

値リスト, 2.10.2

表示, 2.10

リクエスト監視, 4.6 バックアップのリストア, 15.6 ロール

理解, 14.2

RUEI

バックアップの作成, 15.6

環境のカスタマイズ, 1.5

データ収集, E.4

データ構造, 3.2

エラー・イベント, 15.7

データのエクスポート, 2.13

障害アラート, 15.3

概要, 1.1

データのマスキング, 13.6

監視, 15.1

リセット, 15.12

バックアップのリストア, 15.6

サービス, 10.3

起動, 1.4

タグ付け規則, A

トラブルシューティング, C

ルール順序設定, 8.3.5, 12.9

S

スケジュール

アラート, 7.5

サービス・レベル, 7.4

検索

ページ, 8.3.17, 8.3.17

データ・ブラウザ, 3.5

セクション, 「レポート」を参照 セキュリティ担当者, 13 セキュリティ関連設定, 13 サーバー, 12.3 サービス, 10.3, 10.3 セッション診断, 4.1 セッションベースのデータ, 3.2.1 セッション

レポートの制御, 12.8

終了, 1.6

起動, 1.4

Siebel, B, L Single Sign-On, 「SSO」を参照 Sitestat, A.1 SLA

定義, 7.4

概要, 7.1

スケジュール, 7.4

SNMP

アラート, 7.5.6

問題, C.6

SSL鍵

管理, 13.5

有効期限の監視, 13.5.2

SSOプロファイル, 8.4, 8.4, 11.2, 11.2 SSOユーザー認証, 14.9 statistics

コレクタ, 15.2

スイート, 10.1

T

TCP診断, R

テキスト・メッセージ

アラート, 7.5.7

プロバイダの構成, 15.8

問題, C.7

サードパーティ・ライセンス, N.8, T, X タイムゾーン, C.8 Title, A.1 トラフィック

制限, 13.4.3, 13.4.3

監視, 13.4.3

サマリーの表示, 12.1, 15.5

説明, 3.12 トラブルシューティング, C TSV, 3.11.2

U

Unicodeサポート, 15.8

URL

診断, 8.3.21

エンコーディング, G.4

マスキング, 13.6

URL構文, A.1 ユーザー・フロー, 9 ユーザー

追加, 14.3

アイコン, 14.1

情報のマスキング, 13.6

メニュー, 14.4

設定の変更, 14.4

ロールの概要, 14.2

V

値リスト, 2.10.2

ビューのグループ, 「データ・ブラウザ」を参照

表示

レポート, 2.10

トラフィック・サマリー, 12.1, 15.5

ユーザーの詳細, 14.5

VLAN, 13.4.2

W

Webサーバーの場所, 12.3

Webサービス, 「サービス」を参照

WebDAV, A.2

WebLogic Portal, H

webquery, 3.11.2

WebSphere, B

Webtrekk, A.1

Webtrends, A.1

ウィザード

アプリケーション・ページ・ネーミング, 8.3

初期設定, 15.11

KPI作成, 7.2

手動ページ・ネーミング, 8.3.20

サービス構成, 10.3

システム・リセット, 15.12

X

XiTi, A.1

XPath問合せ, F, Q

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。