機械翻訳について

1 レポートの制御

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

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

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

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

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

1. RUEI_USERユーザーとしてアクセスを取得

2. 次のコマンドを実行して、ユーザー・イベントの保存設定を変更します:

   execsql config_set_value processor db_max_user_events days
   

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

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

次の表に、userイベント情報を示します。

表1-1 C_EVENTS表

列	タイプ	説明
ID	NUMBER	ユーザー・イベントの識別に使用する一意のID。
STAMP	TIMESTAMP	イベントがユーザーによって実行された時間(UTC書式)。
USERNAME	VARCHAR2 (255 BYTE)	ユーザーのログイン名です。
CODE	NUMBER	イベント・コード。
EVENT	VARCHAR2 (4000 BYTE)	イベントの説明

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

次の表に、可能なCODEイベントとその関連説明を示します。

表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	システム・アカウントが期限ありに設定されました。

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

「失敗した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を超えるエラー・ページをマージする影響として、システムが日中の特定の時点のデータのマージを停止する場合があります。 発生するエラー・ページが増えるほど、データ・ブラウザ・グループがいっぱいになります。 これをエラー・ログ・ファイル(RUEI_DATA /processor/log/error.log)で診断するには、文字列wg_failpg_dy_*を含むエラーを、文字列no merge:で開始して検索します。

• event_max_fail設定は、失敗したページと失敗したURLs、および失敗したサービスの両方のグループによって使用されます。

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

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

1. RUEI_USERユーザーとしてレポータ・システムにログインします。

2. 次のコマンドを実行します:

   execsql config_set_value processor txn_max_steps steps
   execsql config_set_value processor txn_max_trans flows
   

   説明:

   • stepsでは、ユーザー・フローで許可される新規最大ステップ数を指定します。

   • flowsでは、定義できるユーザー・フローの新規最大数を指定します。

ノート:

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

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

デフォルトで、クライアントIPアドレスは、クライアントから送信されたIPヘッダー・パケットから取得されます。 IPパケットには、パケットの送信元および送信先の数値アドレスが含まれます。 RUEIがNATデバイス(ロード・バランサなど)の後に配置されている場合、IPパケットではなく指定されたヘッダー(NATデバイスで設定)を参照するようRUEIを構成できます。 この手順の詳細は、「Oracle Real User Experience Insightユーザーズ・ガイド」の「NATed Trafficのモニタリング」を参照してください。 ただし、監視されるクライアントがデスクトップ仮想化環境(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範囲の1つ内で、クライアント-ip (Citrix Server IP)を持つセッションが見つかった場合、RUEIでは、USER_ID-CLIENT_IPマッピング・ファイルを使用して、そのセッションから実際のクライアントip (ユーザーのcitrix-client-pc)にユーザー名をマップしようとします。

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

ノート:

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

優先クライアントIPアドレスをレポートするようにRUEIを構成するには、次の手順を実行します:

1. 再マッピングするIPアドレス範囲のリストを含むファイルを作成します。 形式10.1.1.0/24を使用して、各範囲を指定する必要があります。 ip-map-ranges-file.tsvファイルを呼び出すことをお薦めします。このファイルには、IPv6ベースのCIDR表記法も含めることができます。 たとえば:

   RANGE
   169.254.0.0/16
   172.16.0.0/12
   

2. 必要なユーザーIDおよびクライアントIPアドレスのリストを含むタブ区切りファイルを作成します。 ip-map-users-file.tsvファイルを呼び出すことをお薦めします。このファイルには、IPv6ベースのCIDR表記法も含めることができます。 たとえば:

   USER_ID\tCLIENT_IP
   JohnSmith\t10.10.10.50
   FredWhite\t10.10.10.51
   SteveBrown\t10.10.10.52
   

   前述の例の\tは、タブ文字を示しています。 両方のファイルに先頭または末尾の文字が含まれず、空白または特殊文字(/nや/rなど)のみを含む行がないことを確認します。

3. RUEI_USERユーザーとしてRUEIレポータ・システムにログオンします。

4. RUEIレポータ・システムの適切な場所に2つの作成されたファイルをインポートします。

5. 次のコマンドを使用して、import-ip-mapスクリプト(RUEI_DATA /processor/binディレクトリ内)を実行します:

   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つのファイルを作成し、前述の手順を繰り返します。

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

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

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

レポータ・システムでメモリーが不足し、スワップが開始される場合、max_age_session設定を小さくすることを検討してください。 この設定が低く、監視対象のトラフィックに非常に長いセッションが含まれる場合は、ユーザーIDsが失われることがあります。 この設定を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は、メモリーからセッション情報が消去されるまでの最大時間数を指定します。

処理の同時実行性の向上

デフォルトで、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はレポータ・システムが使用できるスレッドの数を指定します。 この設定は、レポータ・システムで使用可能なコアの数より多くしないでください。