1 レポートの制御

この章では、監視対象トラフィックのレポートを最適化する設定について説明します。これらには、失敗したデータ・ブラウザ・グループ内で使用可能な情報量の増加、デフォルトのユーザー・フロー制限の増加およびユーザー・イベント情報の取得が含まれます。

1.1 ユーザー・イベント情報の取得

RUEIデータベースには、ユーザー・イベント(ユーザーがレポートを開く、KPIアラート・ログを参照するまたはログオンおよびログオフする場合など)の情報が含まれます。ユーザーが特定のレポートを開くまたはダウンロードする頻度の確認または最も頻繁にアクセスするデータ・ブラウザ・グループの取得など、この情報を様々な目的に使用できます。この方法で、RUEIインストールを最適化して、ユーザーのニーズを最も満たすことができます。

ユーザー・イベントの記録は、C_config表内のuser_events_enabled設定によって制御されます。1(デフォルト)に設定すると、ユーザー・イベントが記録され、0に設定すると、ユーザー・イベントが記録されません。

デフォルトで、ユーザー・イベントの情報は、最大31日間データベースに保持されます。これは、C_config表内のdb_max_user_eventsエントリによって制御されます。この設定のいずれかを変更する手順は、次のとおりです。

RUEI_USERユーザーになり、次のコマンドを発行して、ユーザー・イベント保存設定を変更します。

execsql config_set_value processor db_max_user_events days

daysでは、ユーザー・イベント情報を格納する最大日数を指定します。この設定はデータベース使用率に影響するので注意してください。

ユーザー・イベント表の構造

表1-1に示すC_USER_EVENTS表には、ユーザー・イベント情報が含まれます。

表1-1 C_EVENTS表

列	型	説明
`ID`	NUMBER	ユーザー・イベントの識別に使用する一意のID。
`STAMP`	TIMESTAMP	ユーザーがイベントを実行した場合の時間(UTC形式)。
`USERNAME`	VARCHAR2 (255 BYTE)	ユーザーのログオン名。
`CODE`	NUMBER	これはイベント・コードです。
`EVENT`	VARCHAR2 (4000 BYTE)	イベントの簡単な説明。

イベント・コードおよび説明

使用可能なCODEイベントおよび関連付けられた説明を表1-2に示します。

表1-2 C_LANG_CATALOG_DATA表

コード	説明
0	ユーザー・ログオン。
1	ユーザー・ログアウト。
2	ダッシュボード・タブのロード/リロード。
3	追加された新規ダッシュボード(%1%s)。
4	更新されたダッシュボード(%1$s)。
5	削除されたダッシュボード(%1$s)。
6	レポート・タブのロード/リロード。
7	レポートの表示(%1$s)。
8	プレビュー・レポートのロード/リロード(%1$s)。
9	レポートの保存(%1$s)。
10	新規レポートとして保存(%1$s)。
11	レポートをPDFとしてダウンロード(%1$s)。
12	レポートをCSVとしてダウンロード(%1$s)。
13	レポートをTSVとしてダウンロード(%1$s)。
14	レポートをXLSとしてダウンロード(%1$s)。
15	レポートをXMLとしてダウンロード(%1$s)。
16	レポートをお気に入りに追加(%1$s)。
17	レポートをお気に入りから削除(%1$s)。
18	レポート%1$sメーリングの切替え(%2$s)。
19	%1$sメーリングからレポートを削除(%2$s)。
20	今すぐ%1$sメーリングを送信。
21	参照タブのロード/リロード。
22	グラフの選択(%1$s)。
23	グラフ・カテゴリの選択(%1$s)。
24	グループの選択(%1$s)。
25	診断のロード/リロード。
26	レポートの参照(%1$s)。
27	KPI概要タブのロード/リロード(%1$s)。
28	KPIの全体的なアラート・ログのロード/リロード。
29	KPI固有のアラート・ログの表示(%1$s)。
30	KPI相関のロード/リロード(%1$s)。
31	ユーザー%1$sが追加されました(%2$s、無効化: %3$d、ロック: %4$d、管理者: %5$d、セキュリティ担当者: %6$d)。
32	ユーザー%1$sが削除されました。
33	アプリケーション%1$sが追加されました。
34	アプリケーション%1$sが削除されました。
35	サービス%1$sが追加されました。
36	サービス%1$sが削除されました。
37	スイート%1$sが追加されました。
38	スイート%1$sが削除されました。
39	コレクタ・プロファイル%1$sが追加されました。
40	コレクタ・プロファイル%1$sが削除されました。
41	コレクタ%1$sがプロファイル%2$sに登録されました。
42	コレクタ%1$sがプロファイル%2$sから登録解除されました。
43	コレクタ%1$s(プロファイル%2$s)が再起動されました。
44	コレクタ%1$s(プロファイル%2$s)が無効になりました。
45	コレクタ%1$sがプロファイル%2$sに移動されました。
46	トラフィック・フィルタ(プロファイル%1$s)が%2$sに変更されました。
47	VLANフィルタ(プロファイル%1$s)が%2$sに変更されました。
48	ポート番号(%1$s)がプロファイル%2$sに追加されました。
49	ポート番号(%1$s)がプロファイル%2$sから削除されました。
50	IPフィルタ(%1$s)がプロファイル%2$sに追加されました。
51	IPフィルタ(%1$s)がプロファイル%2$sから削除されました。
52	ユーザー・アカウント%1$sが有効になりました。
53	ユーザー・アカウント%1$sが無効になりました。
54	ユーザー・アカウント%1$sがロックされました。
55	ユーザー・アカウント%1$sのロックが解除されました。
56	ユーザー・アカウント%1$sの最大ログイン試行に達しました。
57	ユーザー%1$sのパスワードの有効期限が過ぎています。
58	ユーザー%1$sの初期パスワードの有効期限が過ぎています。
59	パスワードに使用できる最小長が%1$sに変更されました。
60	最大パスワード期間が%1$s日間に変更されました。
61	レポートの削除(%1$s)。
62	URL接頭辞%1$sとアクション: %2$sが追加されました。
63	URL接頭辞%1$sとアクション: %2$sが削除されました。
64	URL接頭辞%1$sとアクション: %2$sが更新されました。
65	デフォルトのリプレイ・アクションが%1$sに変更されました。
66	リプレイIP範囲アクションが%1$sに変更されました。
67	リプレイIP範囲%1$sが追加されました。
68	リプレイIP範囲%1$sが削除されました。
69	すべてのIP範囲のリプレイが削除されました。
70	リプレイIP範囲%1$sが変更されました。
71	リプレイIP範囲がアップロードされました。
72	ソース値: %2$sとアクション: %3$sの%1$sアクションが追加されました。
73	ソース値: %2$sとアクション: %3$sの%1$sアクションが削除されました。
74	ソース値: %2$sとアクション: %3$sの%1$sアクションが更新されました。
75	%1$sのデフォルト・アクションが%2$sに変更されました。
76	ユーザー・アカウント%1$sの名前が%2$sに変更されました。
78	ユーザー・アカウント%1$sのパスワードが変更されました。
79	ユーザー・アカウント%1$sが管理者として設定されました。
80	ユーザー・アカウント%1$sの管理者としての設定が解除されました。
81	ユーザー・アカウント%1$sがセキュリティ担当者として設定されました。
82	ユーザー・アカウント%1$sのセキュリティ担当者としての設定が解除されました。
83	初期パスワード期間が%1$s日間に変更されました。
84	許可されるログイン試行回数が%1$sに変更されました。
85	プロファイル%4$s内の%2$sから%3$sまで有効なSSLキー(%1$s)が追加されました。
86	プロファイル%4$s内の%2$sから%3$sまで有効なSSLキー(%1$s)が削除されました。
87	プロファイル%1$s内のSSL証明書マスキングが%2$sに変更されました。
88	KPI %1$s (%2$s)が追加されました。
89	KPI %1$s (%2$s)が削除されました。
90	KPI %1$s (%2$s)が更新されました。
91	KPIカテゴリ%1$sが削除されました。
92	KPIカテゴリ%1$sの名前が%2$sに変更されました。
93	%1$sのネーミング・スキームが更新されました。
94	%1$sのロード満足度が更新されました。
95	システム・アカウントが期限なしに設定されました。
96	システム・アカウントが期限ありに設定されました。

1.2 失敗したグループのサイズの増加

「失敗したURL」、失敗したサービスおよび「失敗したページ」グループでは、最大グループ・サイズ設定は使用されません。かわりに、event_max_fail設定によってサイズが制御されます。この設定により、グループのメイン・データベース表に1分間に追加できる最大行数を指定します。デフォルトでは1000行です。「遅いURL」グループにはevent_max_slow設定が使用され、1分間ごとに記録される最も遅いURLの数を指定します。デフォルトでは1000行です。

event_max_failまたはevent_max_slow設定を変更する場合、daily_max_fail設定も再確認する必要があります。これは、グループの表に入る最大行数を指定します。最大行数は、1440 * event_max_failの式から導出されます。デフォルトは140万行です。

前述の設定を変更するには、次のコマンドを発行します。

execsql config_set_value processor event_max_fail 10000
execsql config_set_value processor daily_max_fail 4320000

event_max_fail設定は、最大10,000行に制限されます。

後述の手順を開始する前に、次のようにする必要があります。

1000を超えるエラー・ページがすべてのセッション・グループ内で1分間実際にレポートされていることを確認します。
リプレイ・ビューア機能が有効になっていることを確認します。これを確認するには、「構成」、「セキュリティ」、「リプレイ・ロギング・ポリシー」の順に選択して、「デフォルトのリプレイ・アクション」設定をクリックします。「完全ロギング」オプションを選択します。

重要:

デフォルトの1000のエラー・ページを変更する前に、次の点を検討する必要があります。

この制限を実際に増やす必要があるかどうかをよく検討します。通常、多くのエラー・ページが1分間にレポートされる場合、様々な問題を示すことはほとんどありません。したがって、同じページ・エラーに対して大量に記録しても、根本原因分析にほとんど役立ちません。
制限を増やすと、レポータ・システムおよびコレクタ・システムに多大なI/Oオーバーヘッドがかかります。このため、デフォルトの制限を変更する前に、これらのシステムの制限をよく検討する必要があります。
データ・ブラウザ内の各グループには、最大サイズがあります。これは、(C_CONFIG表のcube_max_sizeオプションで指定される)圧縮制限の1.5倍です。5分間で5000を超えるエラー・ページをマージする影響として、システムが日中の特定の時点のデータのマージを停止する場合があります。明らかに、エラー・ページが多く検出されると、データ・ブラウザ・グループがすぐに一杯になります。「no merge:」で始まる文字列「wg_failpg_dy_*」を含むエラーを検索して、エラー・ログ・ファイル(RUEI_DATA/processor/log/error.log)でこれを診断できます。
event_max_fail設定は、「失敗したページ」グループだけでなく「失敗したURL」グループおよび失敗したサービス・グループでも使用されます。

1.3 ユーザー・フローのデフォルトの制限の増加

ユーザー・フロー内で定義できるステップのデフォルトの最大数は、15です。txn_max_steps設定で、これを変更できます。定義できるユーザー・フローのデフォルトの最大数は、200です。txn_max_trans設定で、これを変更できます。いずれかの設定を変更するには、次のようにします。

RUEI_USERユーザーとしてレポータ・システムにログオンします。
次のコマンドを発行します。
```
execsql config_set_value processor txn_max_steps steps
execsql config_set_value processor txn_max_trans flows
```
説明:
- stepsでは、ユーザー・フローで許可されるステップの新しい最大数を指定します。
- flowsでは、定義できるユーザー・フローの新しい最大数を指定します。

重要:

いずれかのデフォルトの最大値を増やすとパフォーマンスのオーバーヘッドが発生するので注意してください。また、ユーザー・フロー内のステップの最大数が大幅に増えると、ユーザー・フローのグラフィカル・レポート(フロー・ステータスやフロー遷移など)が読みにくくなる場合があります。

1.4 デスクトップ仮想化環境内のクライアントIPアドレスの取得

デフォルトで、クライアントIPアドレスは、クライアントから送信されたIPヘッダー・パケットから取得されます。IPパケットには、パケットの送信元および送信先の数値アドレスが含まれます。RUEIがNATデバイス(ロード・バランサなど)の後に配置されている場合、IPパケットではなく指定されたヘッダー(NATデバイスで設定)を参照するようRUEIを構成できます。この手順については、『Oracle Real User Experience Insightユーザーズ・ガイド』の付録「NATトラフィックの監視」の2項を参照してください。ただし、監視されるクライアントがデスクトップ仮想化環境(Citrixサーバーなど)を使用している場合、サーバーのIPアドレスがクライアントIPアドレスとして戻ります。

次の重要な点を考慮する必要があります。

デスクトップ仮想化環境では、クライアント・マシンではなく、デスクトップ仮想化サーバー(Citrixなど)で実行しているブラウザを使用してインターネットに接続します。RUEIには、ユーザーの本当の発信元クライアントIPではなく、仮想化サーバーのIPが見えます。ただし、RUEIはユーザーIDとクライアントIPのマッピングができるため、本当の発信元クライアントIPに関するレポートを作成する方法を提供できます。このマッピングはアップロードできますが、機能が制限されていることに注意してください。
map-rangesファイルには発信元サーバーIP範囲が含まれており、ユーザーIDからクライアントIPへのマッピングがここから行われます。
map-usersファイルには、ユーザーIDから本当の発信元クライアントIPへのマッピングが含まれています。たとえば、一連のCitrixサーバーに、10.0.1.2から10.0.1.254 (10.0.1.0/24)の範囲のIPアドレスが設定されているとします。Citrixサーバーに接続するCitrixクライアントには、192.168.1.2から192.168.1.254 (192.168.1.0/24)の範囲のIPアドレスが設定されているとします。これらのCitrixクライアントのユーザーはRUEIで監視されているWebアプリケーションを使用しています。CitrixサーバーのIPではなく本当のクライアントIPに関するレポートを作成するようにRUEIを構成するには、次の構成を使用します。
```
RANGE 
10.0.1.0/24 
 
USER_ID\tCLIENT_IP 
JohnSmith\t192.168.1.10 
FredWhite\t192.168.1.10 
SteveBrown\t192.168.1.10 
 
```
RANGEファイルのIP範囲のいずれかに含まれるクライアントIP(CitrixサーバーIP)を使用するセッションが見つかるたびに、RUEIはUSER_ID-CLIENT_IPマッピング・ファイルを使用して、そのセッションのユーザー名を本当のクライアントIP(ユーザーのCitrixクライアントPC)にマップしようとします。

そのため、クライアントIPに依存するRUEIの機能またはレポート作成(データ・ブラウザ内のクライアント・ネットワーク・ビューなど)では、マップされたクライアントIPが使用されます。USER_ID\tCLIENT_IPマッピング・ファイルに一致するものがない場合、TCP/IPレイヤーまたは構成されたヘッダーから取得された元のクライアントIPが使用されます。

重要:

map-rangesファイルにクライアントIPを持っていても、ユーザーIDがmap-usersファイルにないユーザーはマッピングされません。ユーザーによってリクエストされるページは、IP "unknown"として報告されます。

RUEIを構成して優先クライアントIPアドレスを構成するには、次のようにします。

再マッピングするIPアドレス範囲のリストを含むファイルを作成します。形式10.1.1.0/24を使用して、各範囲を指定する必要があります。ファイルip-map-ranges-file.tsvを呼び出すことをお薦めします。次に例を示します。
```
RANGE
169.254.0.0/16
172.16.0.0/12
```
必要なユーザーIDおよびクライアントIPアドレスのリストを含むタブ区切りファイルを作成します。ファイルip-map-users-file.tsvを呼び出すことをお薦めします。次に例を示します。
```
USER_ID\tCLIENT_IP
JohnSmith\t10.10.10.50
FredWhite\t10.10.10.51
SteveBrown\t10.10.10.52
```
前述の例で、\tはタブ文字を示します。両方のファイルに先頭または末尾の文字が含まれず、空白または特殊文字(/nや/rなど)のみを含む行がないことを確認します。
RUEI_USERユーザーとしてRUEIレポータ・システムにログオンします。
RUEIレポータ・システムの適切な場所に2つの作成されたファイルをインポートします。
次のコマンドを使用して、(RUEI_DATA/processor/binディレクトリの)import-ip-mapスクリプトを実行します。
```
import-ip-map -r ip-map-ranges-file -u ip-map-users-file
```
ip-map-ranges-fileおよびip-map-users-fileは、前述の作成およびインポートされた2つのファイルです。

この機能によって行われたレポート変更は、約5分以内に反映されます。

デフォルト機能のリストア

デフォルトのクライアントIPアドレス・レポートをリストアするには、列ヘッダーのみを含む2つのファイルを作成して、前述の手順を繰り返します。

1.5 最大セッション継続時間およびアイドル時間の制御

デフォルトでは、ビジターの非アクティブ状態が60分を超えると、ビジター・セッションが終了したとみなされます。これは、session_idle_time設定で制御されます。また、ユーザーIDおよびカスタム・ディメンションがセッションに保持されるデフォルトの時間は、12時間です。これは、max_age_session設定によって制御されます。

session_idle_time設定を小さくすると、CPU使用率の観点からレポータ・システム・パフォーマンスが向上します。メモリー使用率には影響しません。ただし、この設定を小さくする場合の短所は、指定されたセッション・アイドル時間内に戻る識別されたビジターが匿名としてレポートされることです。

レポータ・システムでメモリーが不足し、スワップが開始される場合、max_age_session設定を小さくすることを検討してください。この設定を小さくすると、監視対象トラフィックに主に長いセッションが含まれ、ユーザーIDが失われる可能性があります。この設定をsession_idle_time設定より小さくしないでください。

次のコマンドを使用して、現在の設定値を取得します。

execsql config_get_value processor session_idle_time
execsql config_get_value processor max_age_session

次のコマンドを使用して、設定値を変更します。

execsql config_set_value processor session_idle_time idle_time
execsql config_set_value processor max_age_session max_age

説明:

idle_timeでは、ビジターが非アクティブになってからセッションが終了したとみなされるまでの秒数を指定します。
max_ageでは、セッション情報がメモリーからクリアされる最大の時間数を指定します。

1.6 処理の同時実行性の向上

デフォルトで、3つのスレッドがレポータ・システムでトラフィック処理に使用されます。lookup_threads設定で制御されます。この設定を大きくすると、(処理の追加の同時実行性によって)パフォーマンスを向上できます。この設定が小さすぎると、次の内部エラーがイベント・ログに表示されます。

Processing backlog larger than %d minutes, restarting logr (the backlog will be skipped).

レポータ・システムが受信データの処理に追いつかないことを意味します。

次のコマンドを使用して、現在の設定値を取得します。

execsql config_get_value processor lookup_threads

次のコマンドを使用して、設定値を変更します。

execsql config_set_value processor lookup_threads threads

threadsでは、レポータ・システムで使用される使用可能なスレッドの数を指定します。この設定は、レポータ・システムで使用可能なコア数より大きくしないでください。

レポータ・ユーザー・インタフェースのパフォーマンスを制御するには別の設定を使用できますが、それについては3.3項「GUIパフォーマンスの向上」に説明されています。