| Oracle Real User Experience Insightユーザーズ・ガイド リリース6.5.1 for Linux x86-64 B61012-01 |
|
 戻る |
 次へ |
この章では、管理者が実行するタスクについて説明します。これには、システムのステータスの監視、バックアップおよびアップグレードの実行、イベント・ログの処理、システム・ユーザーの管理、データ保存ポリシーの構成が含まれます。
管理者は、システムの状態を確認し、ステータス・ページで自動ステータス監視メッセージを受信できます。このページにアクセスするには、「System」→「Status」を選択します。例を図9-1に示します。
Status・ページでは、接続されているコレクタのステータス、ログ・ファイル処理、システムにおける現在の処理レベル、ユーザーのデータベース表領域に十分な領域があるかどうか、およびイベント・ログを確認できます。また、システム・ステータス・エラーに関する通知を受け取るユーザー（およびその方法）を構成することもできます。
図9-1に示したシステム・ステータス・インジケータが更新されるのは、ブラウザ画面のリフレッシュ時のみです。1つ以上のシステム・プロセスで障害が発生していることが検出されたときにシステム・アラートを生成するように設定できます（9.4項「システム障害アラートの構成」を参照）。このため、1つのプロセスに一時的に障害が発生していることが（赤いxによって）示されるが、アラートは生成されないという状況が生じる場合があります。これは、システム・プロセスがチェックされる時点までにシステム・ステータス・インジケータが正常状態に戻っていたことが原因です。
このような設計のため、アラートがトリガーされた場合は、システム障害が発生し始めているという警告とみなすことをお薦めします。障害は、デフォルトの境界よりもシステム遅延の方が長くなった結果、発生する場合があります。たとえば、監視対象の行がヒットした時点と、このヒットに基づく情報がレポータで使用可能になる時点との間の待機時間がそれほど長くない場合です。この待機時間が、トラフィックが多い環境における境界を超えている可能性があります。また、障害は、トラフィックが一時的にピークを示した結果である場合もあります。ただし、この状況が続く場合は、監視対象のトラフィック・レベルを確認することをお薦めします。
システムに接続された各コレクタのステータスを表示するには、「System」→「Status」→「Collector status」を選択します。これにより、Network data collectorsウィンドウが開きます。例を図9-2に示します。
「System (localhost)」は、レポータ・システム上のコレクタ・インスタンスを表します。ネットワーク内の他のコレクタは、IPアドレスによって示されます。コレクタごとに、次のメニュー・オプションを使用できます。
View statistics: コレクタによって監視されるトラフィックの詳細なレポートを表示します。例を図9-3に示します。この詳細は、次の項に記載されています。
Configure: 選択したコレクタのセキュリティ関連設定を構成できるサブメニューを開きます。この詳細は、第8章「セキュリティ関連情報の管理」に記載されています。
Edit description: コレクタの登録時に指定された簡単な説明を変更できます（9.2.2項「新規コレクタの接続」を参照）。これは、コレクタ・システムに関する追加情報を提供するために役立ちます。たとえば、組織ネットワーク内でコレクタにパッチが適用される場所、またはシステム管理者の連絡先を指定できます。
Unregister: 接続されているコレクタをレポータ・システムから削除します。コレクタの削除を確認するように求められます。
このウィンドウ（図9-3）に表示される情報は、選択したコレクタについて午前0時以降またはカウンタのリセット以降に監視されたトラフィックを示します。ウィンドウの左下にある「Uptime」フィールドは、コレクタが稼働している時間を示します。コレクタが構成を更新するために再起動されると、この稼働時間はリセットされます。ウィンドウに表示されているすべてのHTTPリクエスト・カウンタをリセットするには、「View」メニューで「Reset counters」を選択します。このカウンタが自動的にリセットされるのは、ネットワーク・パケットが次回検出されたときです。このため、ネットワーク・トラフィックが行われていないインストール環境の場合、カウンタはリセットされません。この表示は2秒ごとに自動的にリフレッシュされます。
ウィンドウの左上部分にあるタブにより、選択したコレクタによって監視されたトラフィックの詳細なブレークダウンを確認できます。これについて表9-1で説明します。
表9-1 「Collector statistics」レポートのタブ
| タブ | 説明 |
|---|---|
|
Interfaces |
データ収集に使用可能なネットワーク・インタフェースについての情報を提供します。インタフェースの数とステータスはシステム構成によって異なります。標準的に構成されるインタフェースは表示されません。使用可能なインタフェースごとに、名前（ |
|
Ethernet |
監視対象のポートを介して送信されるRAWパケット・データのブレークダウンを、そのプロトコル（IPv4やARPなど）および測定されたフレーム数として表示します。「Truncated」リストは、フレームが破損しているか削除されていることを示します。 |
|
TCP |
TCPストリームの分析結果を示します。レポートされるカウンタは、次のとおりです。
次のネットワーク・エラー・メーターも表示されます。
これらいずれかのメーターで問題が示されるときは、TCP診断機能を使用して可能性のある原因を特定することをお薦めします。 |
|
TCP diagnostics |
この機能の使用方法の詳細は、付録P「監視対象ネットワーク・トラフィックの確認」に記載されています。 |
|
HTTP |
監視したHTTPストリームの分析結果を示します。特に、ストリームに含まれるリクエストのタイプ（GETやPOSTなど）を示します。 |
|
SSL connections |
暗号化されたデータのパケットに使用されている暗号化メソッドをレポートします。具体的には、次のとおりです。
SSL鍵管理に関するエラーがレポートされます。具体的には、次のとおりです。
（現時点で）サポートされていない暗号化メソッドは、次のとおりです。
復号化エラー・ゲージは、復号化できなかった接続の数を示します。これには、マスター鍵を復号化できなかった、セッション鍵の計算が間違っていた、またはセグメントを復号化できなかったなどの複数の理由があります。 |
|
SSL encryption |
監視対象の暗号化データのブレークダウンを、採用された暗号化アルゴリズムの観点から示します。「Used」列は、暗号化アルゴリズムを使用した監視対象のSSL暗号化トラフィック（割合）を示します。「Errors」列は、失敗した（読み取ることができなかった）測定対象のSSL暗号の割合を示します。 |
|
Performance |
コレクタに対する影響をレポートします。ピークの負荷が100%に近づいた場合は、データがコレクタによって削除されないようにするためのアクションを即座に実行する必要があります。トラフィックのサンプリングは、8.2.2項「全体のトラフィックの制限」を参照してください。これでも問題が解決されない場合は、Oracleサポート・サービスに連絡することも必要になってきます。コレクタのメモリー使用率も示されます。最大メモリーしきい値は、レポータとコレクタが両方ともあるシステムの場合は30%、コレクタのみのシステムの場合は70%です。 |
SSLトラフィックおよびFormsトラフィックの監視
SSLトラフィックおよびOracle Formsトラフィックは、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。
したがって、各コレクタが信頼性の高いネットワーク・デバイス（TAPなど）に接続されることを確認する必要があります。また、Collector Statisticsウィンドウに表示される情報を定期的に調べて、TCPパケット・ストリームが正常な状態であることを確認するように強くお薦めします。TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。
システムに新規コレクタを接続するには、「Configuration」メニューから「Register remote Collector」を選択します。図9-4に示す「Register Collector」ダイアログが表示されます。
新規システムのIPアドレスと簡単な説明（オプション）を指定します。たとえば、システム管理者の連絡先を指定します。次に、「Register」をクリックします。コレクタ・システムの構成要件の詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。
|
注意: この機能は、「System」→「Status」→「Collector status」の順に選択してアクセスすることもできます。管理者として認可されていないユーザーの場合、このインタフェースの読取り専用バージョンが表示されることに注意してください。 |
RUEIが監視しているネットワーク・トラフィックに関して正確にレポートするには、そのトラフィック内で使用されているエンコーディングを認識している必要があります。RUEIでは、様々なキャラクタ・エンコーディング標準のデータを含むネットワーク・トラフィックを監視できます。RUEIでサポートされているすべてのエンコーディング標準は、表G-1を参照してください。
一般的に、RUEIは最初に、対応するHTMLドキュメントについて指定されているドキュメントのエンコーディングを使用しようとします。これは自動検出です。このエンコーディングで満足できる結果が得られなかった場合には、URL引数およびポストされたフォーム引数をデコードするために、コレクタ・エンコーディング（指定されている場合）が使用されます。
コレクタ・エンコーディングは、ドキュメント・エンコーディングを手動で上書きするものではありません。むしろ、ドキュメントのエンコーディングがURL引数を満足できる形でデコードできなかったときに、RUEIによって自動的に使用されるエンコーディングを指定するものです。コレクタ・エンコーディングでも満足できる結果が得られなかった場合、引数は元の（デコードされていない）形式でレポートされます。
URL引数およびコレクタ・エンコーディング
URL引数とコレクタ・エンコーディングを指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced」→「Collector encoding」を順に選択します。図9-5に示すようなパネルが表示されます。
目的のコレクタに現在定義されているコレクタ・エンコーディングをクリックします。デフォルトでは、コレクタ・エンコーディングは定義されていません。図9-6に示すダイアログが表示されます。
「Collector encoding」メニューを使用して、自動検出が失敗したときに、アプリケーション・フィルタのURL引数のために使用されるエンコーディングを指定します。使用可能なエンコーディングのリストは、表G-1に示すリストと等価です。
次に、「Save」をクリックします。この設定は、変更すると、ほぼ即座に有効になります。
重要:
この機能を使用する場合には、次の点に特に注意する必要があります。
この設定が適用されるのは、アプリケーション定義内のURL引数のデコードのみです（6.2項「アプリケーションの定義」を参照）。コンテンツベースのレポート（関数エラーなど）はこの設定による影響を受けません。また、選択したコレクタ・エンコーディングは、選択したコレクタによって監視されているアプリケーション、ページ、ドメインのすべてに適用されます。
Webサイト内で各国語のキャラクタ・セットを使用する場合には、Webサイトのコンテンツとそこで使用されているエンコーディングを注意して確認することをお薦めします。また、すべてのURL引数のレポートを定期的に調べて、それらの引数が正しいことを確認する必要があります。
KPIおよびSLAの違反に関する通知を受信できるのみでなく、システム障害のアラートを構成することもできます。構成を強くお薦めします。システム・アラートを使用すると、システムの問題（コレクタの障害など）に際してすぐにアクションを実行できるだけでなく、外部の深刻な問題（DoS攻撃など）を示すためにも役立ちます。それには、「System」→「Status」→「Status notification」の順に選択します。表示されるダイアログは、5.5.1項「アラート・プロファイル」に示したダイアログに似ています。
基本的に、図9-1に示すインジケータ（1つまたは複数）が警告またはエラーのステータスをレポートするイベントによって、システム・アラートがトリガーされます。たとえば、コレクタ・ステータスのアラートは、コレクタが使用できないかコレクタの障害が発生していることを示します。
重要:
特に次の点に注意することをお薦めします。
構成された受信者には、データベース領域およびディスク領域の使用率の警告とエラーも通知されます（9.5項「データベースおよびディスクの領域制限とアラートの構成」を参照）。
システム・ステータスのアラートでは、アラートのスケジュールやエスカレーション・レベルは考慮されません。アラートを構成するときは、受信者のすべての情報（電子メール・アドレスや電話番号など）を正しく指定してください。また、システム・ステータスのチェックが10分ごとに実行されることにも注意してください。このため、図9-1のページにシステム障害が表示された場合、その障害に関するアラートをすぐには受信せず、スケジュールされたシステム・チェックが実行されたときに受信することがあります。
イベント・ログのアラートの場合、9.9項「イベント・ログの使用」で説明するように、レポートされたイベントを確認することをお薦めします。イベント・ログ・インジケータのステータスを「OK」に戻すためには、イベント・ログの警告またはエラーを読取り済みとしてマーキングする必要があることに注意してください。
コレクタ・ステータスのアラートの場合、Collector Statisticsウィンドウ（9.2.1項「Collector Statisticsウィンドウの使用」を参照）を使用して問題をトラブルシューティングすることをお薦めします。
他のエラーまたは警告の際（あるいはエラーや警告が長く続く場合）は、カスタマ・サポートに連絡してください。
システムが中断しないで運用されるようにするために、使用可能なデータベース領域およびディスク領域の使用率に上限を設定します。データベースの使用率が上限に達すると、管理メカニズムによってデータベースのサイズが許容された境界内に戻るまで、新しいデータが書き込まれなくなります。同様に、ディスク領域使用量が最大レベルに達すると、管理者が既存ファイルの削除処理を行うまで、（ログ形式やエンリッチ・データ交換ファイルの）データはファイル・システムに書き込まれません。さらに、これらのいずれかの問題が発生しそうな場合にアラートを生成するように設定することも可能です。
|
重要: RUEIを熟知していて、これらの設定の用途と効果を明確に理解している場合にのみ、デフォルト設定を変更することをお薦めします。 |
データベース領域またはディスク領域のしきい値を定義する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Database/disk space usage」の順に選択します。図9-7に示すしきい値選択パネルが表示されます。
目的のしきい値を選択します。図9-8に示すようなダイアログが表示されます。
アラートのしきい値の場合には、このダイアログを使用してデータベース領域またはディスク領域の最大使用率を指定し、その使用率を超えたらアラートが生成されるようにします。生成されたアラートは同じ受信者に送信され、システム障害アラートに定義した通知メカニズム（9.4項「システム障害アラートの構成」を参照）と同じ通知メカニズムが使用されます。停止のしきい値の場合には、データベース領域またはディスク領域の最大使用率を指定し、その使用率を超えたらデータベース処理またはデータ収集が停止するようにします。次に、「Save」をクリックします。指定した変更は、即座に有効になります。
しきい値の定義
しきい値を定義するときには、次の点に注意してください。
データベース領域またはディスク領域の使用を停止するために指定可能な最大設定は、95%です。これは、使用可能なディスク領域が完全に（100%）いっぱいになった場合、システム上の他のコンポーネントが動作しなくなることがあるためです。また、システムへのリモート・ログオンができなくなる可能性もあります。同様に、データベースが完全にいっぱいになることを許可した場合には、そのサイズを削減するための管理メカニズムが動作できなくなります。
指定したしきい値は、RUEIで使用されるすべてのパーティションに適用されます。つまり、/var/opt/ruei、およびその下にマウントされたすべてのパーティションです。少なくとも1つのパーティションが指定されたしきい値に達すると、アラート・メカニズムおよび停止メカニズムがトリガーされます。
定義されたしきい値のチェックは、絶えず実行されるのではなく、10分ごとに実行されます。したがって、チェックが実行されてアラートが発行されるまでに、データベース領域またはディスク領域の使用率が指定されたしきい値をすでに上回っている場合もあります。そのため、しきい値は、意図したターゲットより少し低く設定することをお薦めします。たとえば、ディスク領域の停止しきい値は95%でなく93%か94%に設定します。
アラート通知しきい値は、関連する停止しきい値より高い値に設定することはできません。たとえば、データベースの停止しきい値が95%の場合には、アラートしきい値をそれより高い値に設定することはできません。
デフォルトでは、アラートしきい値は85%、停止しきい値は95%です。
Linuxオペレーティング・システムでも、ディスク領域使用率の制限は95%です。この制限に達すると、ディスクに書き込めるのはrootユーザーのみとなります。RUEIにはこの権限がないため、ディスク領域をそれ以上使用できなくなります。
データ・ブラウザ内に特定データとそのデータに基づくレポートを表示できるかどうかは、コレクタ・システムおよびレポータ・システムで使用可能なディスク領域の量、およびレポータ・システムで使用可能なデータベース領域の量によって異なります。図9-9にこれを示します。
監視中に収集されたデータは、まず、コレクタ・システムに格納されているログ・ファイルに書き込まれます。これらのファイルはレポータにコピーされて処理され、データ・ブラウザおよびレポートで表示可能な多次元のデータ構造を持つデータベースに移入されます。これらの一時ログ・ファイルは、3日後にはコレクタ・システムから自動的に削除され、ポータ・システムからは7日後に削除されます（デフォルト）。データ・マスキング・オプション（8.4項「ユーザー情報のマスキング」を参照）を指定すると、機密情報のログを省略することができます。
ログ・ファイルは、セッション完全再生（FSR）データ・ストアを作成するために使用されます。これらのファイルは、定期的にフィルタリングされ、エラー・ページ再生（EPR）データ・ストアが作成されます。EPRファイルには、失敗したイベント（失敗したページ、オブジェクトおよび関数コール）に関する情報のみが格納されます。FSRデータとEPRデータの両方がコレクタ・システムに保持されます。
レポータ・システムのデータベース・ユーザー割当て制限のサイズは、インストール時に構成可能です。デフォルトでは、このサイズは200GBに設定されます。レポータで定義した保存ポリシーでデータが不要になるとそのデータが統合されることを理解しておくことは重要です。たとえば、デフォルトでは、直前の32日間の日単位の情報が保存されます。この期間より古い日単位の情報は、月単位の情報に統合されます。同様に、月単位の情報は年単位の情報に統合されます。最後に、拡張データ交換機能が有効になっている場合には（9.19項「エンリッチ・データのエクスポート」を参照）、エクスポート・ファイルが5分ごとに作成されます。XMLベースのエクスポート・ファイルは、デフォルトでは7日間保存されます。
デフォルトでは、RUEIには、日単位レベルで32日、月単位レベルで13か月、年単位レベルで5年間の情報が保持されます。したがって、たとえば、最も古い日単位情報は32日が経過したら削除されます。また、一時ログ・ファイルは、約7日間ファイル・システムに保持されます。新しいインストール済RUEIは、最初の32日間に最も急成長を遂げます。その期間が過ぎると、成長率は低下します。もちろん、成長率は、監視されているトラフィック・レベルによって異なります。
デフォルトでは、失敗したURL、ページおよびサービス・コールに関する情報は15日間保持されます。その情報が残っている場合、セッション診断の再生機能で表示できます（3.10項「診断機能の使用」を参照）。
この項の残りの部分で説明する設定により、業務上の要件を満たすように、インストール済RUEIのディスクおよびデータベースの使用率を最適化できます。
レポータ・システムで使用するデータ保存ポリシーを指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Reporter data retention policy」の順に選択します。図9-10に示すような画面が表示されます。
図9-10に表示されるように、データベースに影響があるすべての設定には、対応する「Database usage」のリストがあります。このリストは、その項目に現在使用中の合計データベース領域（GB）と、それがデータベースの最大許容サイズに対して占める比率を表します。推定されるデータベース使用率（監視対象トラフィックのレベルに基づく）も示されます。ディスク領域使用率の情報は、個別設定のダイアログ・ボックスに表示されます。
目的の設定を選択します。次の設定が可能です。
Maximum database size: データベースに格納できるデータの最大量を（GB単位で）指定します。この設定を変更するには、データベースのSYSTEMユーザー・パスワードを指定する必要があることに注意してください。
Daily data retention: 日単位の情報を使用可能にする期間を指定します。デフォルトは直前の32日間です。日単位データの最大保持期間は月の設定によって異なる場合があります。
Monthly data retention: 月単位の情報を使用可能にする期間を指定します。デフォルトは直前の13か月です。月単位データの最大保持期間は年の設定によって異なる場合があります。
Yearly data retention: 年単位の情報を使用可能にする期間を指定します。デフォルトは直前の5年間です。この最小設定は日の設定によって異なり、最小数は月の設定によって異なります。
Failed event data retention: 失敗したURL、ページおよびサービス・コールに関する情報を使用可能にする期間を指定します。デフォルトは直前の15日間です。セッション診断の再生で情報が使用可能にならない場合には、この設定を確認できます。この設定は、エラー・ページ再生の記憶領域サイズ設定（9.6.2項「コレクタのデータ保存ポリシーの定義」を参照）に関連していることに注意してください。失敗したイベントのデータ保存設定値を大きくする場合は、適切に動作するように、エラー・ページ再生の記憶領域サイズ設定値も大きくすることをお薦めします。また、この設定はディスク領域使用率に大きな影響を与えるため、変更する場合は、予想されるネットワーク・トラフィックの観点から慎重に検討する必要があります。
Session diagnostics retention: セッション診断情報を使用可能にする最大日数を指定します。この機能の詳細は、3.10項「診断機能の使用」に記載されています。デフォルトは直前の7日間で、最小値は直前の2日間です。この設定は、データベース領域およびディスク領域の使用率に影響を与えます。レポートされるディスク領域使用率には、レポートされるデータベース使用率は含まれていません。
XML enriched data exchange retention: XMLエンリッチ・データ交換を使用可能にする最大日数を指定します。この機能の詳細は、9.19項「エンリッチ・データのエクスポート」に記載されています。デフォルトは直前の7日間で、最小値は直前の24時間です。1日に設定すると、その前日のデータは午前0時頃に削除され、当日は限定された量の情報しか使用可能になりません。午前0時を過ぎても前日のデータをダウンロードできるようにするには、最大値として少なくとも2日を指定することをお薦めします。この最大値は、使用可能なデータベース領域およびディスク領域によって異なります。ファイルの場所は、ディレクトリ/var/opt/ruei/processor/xml-events/wg/xml-sespageです。ここには、1日分のデータ用として、名前がyyyymmddという形式の専用のディレクトリがあります。
図9-11に示すようなダイアログが表示されます。
このダイアログのコントロールを使用して、選択したオプションの保存ポリシーを指定します。
ほとんどの設定では、「Calculate」をクリックすることで、データベース使用率とディスク領域使用率のうち、該当する方に対するユーザーの選択の影響を表示できます。
次に、「Save」をクリックします。ディスク領域割当ての変更は約10分で有効になりますが、データベース割当ての変更は午前0時を過ぎるまで有効にならないことに注意してください。
|
注意: 保持されるデータの量を増やすには、まず下位レベルのデータ保存設定、次に上位レベルのデータ保存設定を変更することをお薦めします。保持されるデータの量を減らす場合は、まず上位レベルのデータ保存設定、次に下位レベルのデータ保存設定を変更します。 |
必要な日数、月数および年数の計算
上位、中位および下位のデータ保存設定を指定するときには、保存される日数、月数および年数間の依存関係を理解しておくことが重要です。次のルールを使用して、必要な設定値を計算します。
1か月は30日と想定されています。指定した日数に対応して保存が必要な月数は、日数を30で割った数（次の整数に切上げ）に1を加えたものとなります。たとえば、33日の場合、33/30（1.1となり、切り上げて2）に1を加えたものが必要となるため、3か月になります。
指定した月数に対応する必要な年数は、月数を12で割った数（次の整数に切上げ）に1を加えたものとなります。たとえば、11か月の場合は1年が必要となり、13か月の場合は2年が必要となります。
例: 900日、31か月および3年。
コレクタ・システムで使用するデータ保存ポリシーを指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Collector data retention policy」の順に選択します。図9-12に示すパネルが表示されます。
「View」メニューを使用して、目的のコレクタを選択します。「System (localhost)」は、レポータ・システムで実行されているコレクタを表します。
現時点で定義されている各アプリケーション、スイートまたはサービスについて、「Oldest data」列は、表示されるストレージ・アイテムのデータがどれくらい前の分からあるか（秒、時、分または日）を示します。通常、最も古いエントリが10分とレポートされる場合は、10分よりも前のデータを格納できないほどシステムがビジーであることを意味します。「Newest entry」列は、表示されるストレージ・アイテムのデータがどれだけ前に書き込まれたかを示します。
「Log files」項目は、一時ログ・ファイルを格納するためにコレクタで使用されているディスク領域の容量を示します。ローカル・コレクタの場合、これは常に0になることに注意してください。
各アプリケーション、スイートまたはサービスについて、「Options」列のチェック・ボックスを使用して、再生データの作成を有効にするかどうかを指定します。デフォルトでは、再生データは有効化されています。行った変更を確認するように求められます。また、コレクタを再起動するように求められます。
変更するアプリケーションの「Error page replay store」または「Full session replay storage」オプションをクリックします。図9-13に示すようなダイアログが表示されます。
選択したコレクタで、指定したアプリケーション、スイートまたはサービスについて、FSRまたはEPRデータのために予約しておくディスク領域の最大容量を指定します。
「未分類の」アプリケーションのストレージ・アイテムは、特定のアプリケーション、スイートまたはサービスに関連付けられないネットワーク・トラフィックのために予約するディスク領域の最大容量を使用することに注意してください。
次に、「Save」をクリックします。
オプションとして、「View security URL masking policies」項目をクリックします。図9-14に示すダイアログが表示されます。現時点で定義されているURL接頭辞のマスキング・アクションとデフォルトのマスキング・アクションが示されます。
または、個々のアプリケーション、スイートおよびサービスのFSRデータ・ストアおよびEPRデータ・ストアのサイズを指定するかわりに、「Set Full session replay store size for all applications」または「Set Error page replay store size for all applications」アイコンをクリックできます。図9-15に示すようなダイアログが表示されます。
選択したコレクタ・システムで、各アプリケーション、スイートまたはサービスについて、FSRまたはEPRデータのために予約しておくディスク領域の最大容量を指定します。次に、「Save」をクリックします。
コレクタを再起動するように求められます。コレクタの再起動は、変更を有効にするために必要です。また、選択したコレクタを再起動するには、図9-12に示す「Restart Collector」アイコンをクリックします。
アプリケーション、スイートまたはサービスが削除されるとき、関連するFSRおよびEPRデータはコレクタ・システムから自動的に削除されません。引き続き表示することができます。これらのデータを削除する場合は、「Status」列に表示される「Remove」アイコンをクリックする必要があります。データの削除を確認するように求められます。
重要:
次の点に注意してください。
アプリケーションで使用可能な再生用のディスク領域を、現在使用中の容量よりも減らすと、再生データ・ストアのサイズを調整するために、ストアの最も古いデータが削除されます。たとえば、アプリケーションのFSRデータ・ストアを20GBから10GBに減らすように指定し、現在14GBが使用されているとします。この場合、ストアのサイズを調整するために、現在のFSRデータ・ストアの最も古い4GB分が削除されます。
EPRデータ・ストアに、失敗したイベント・データの設定を超える日数のデータが保持されている場合は、余分な量のデータにはGUIからアクセスできません。逆に、EPRのサイズ設定が、失敗したイベント・データの日数を下回る場合は、余分な期間のReplay Viewerデータにはアクセスできません。ただし、データの他のビューには、他のデータ・ブラウザ・グループから通常どおりアクセスできます。
FSRデータ設定が15分未満に設定されると、エラー再生機能が正常に実行されない場合があります。また、0に設定されると、EPRサイズ設定を変更できなくなります。
監視対象のネットワーク・トラフィックの概要を開くには、「System」→「Status」→「Data processing」の順に選択します。これにより、ヒット、ページ、セッション処理およびシステム・ロードに関する情報が即座に表示されます。例を図9-16に示します。
「Performance」タブの「Available resource usage (%)」項目は、現在の処理レベルを示します。この値が100%に近づくと、データの処理に遅延が発生し始め、データをリアルタイムで処理できなくなります。
この機能はアプリケーション・ロジックに基づいているため、表示されるレポートには非アプリケーション（スイート、サービス、SSOなど）のトラフィックは示されません。
|
重要: RUEIが監視しているトラフィックに関して正確にレポートするには、このトラフィック・サマリーを定期的に確認することをお薦めします。必要であれば、RUEIの構成を確認して適切なものにしてください。たとえば、他のCookieテクノロジを追加します。また、システムでセッションを追跡できない場合は、ユーザー・フローも適切に追跡できません（ユーザー・フロー・レポートではセッションの追跡が必要になるため）。 |
システムの現在の構成のバックアップを作成したり、必要に応じてそのバックアップをリストアできます。バックアップは定期的に作成することをお薦めします。バックアップにはシステム設定のみが含まれることに注意してください。セキュリティ上の理由により、SSL鍵と収集されたデータは含まれません。
バックアップを作成またはリストアする手順は、次のとおりです。
「System」→「Maintenance」→「Backup and restore」の順に選択します。図9-17に示すダイアログが表示されます。
ラジオ・ボタンを使用して、必要な操作を選択します。次に、「Next」をクリックします。
ブラウザの構成方法によって異なりますが、zipファイルの保存場所の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。
|
重要: 生成されるバックアップ・ファイルには、Oracleサポート・サービス専用の大量の情報が含まれます。このファイルの内容を変更しないでください。リストアを実行するときは、現在のすべての設定がリストアされる設定で上書きされることに注意してください。 |
RUEIでは、9.1項「システムのステータスの監視」で説明されているステータス情報の他に、イベント・ログが保持されます。これには、すべてのシステム・イベントのレコードが含まれます。ユーザーもカスタマ・サポートも、イベント・ログを使用することで、RUEIインストールで発生する可能性のある問題をすぐに特定して解決できます。
イベント・ログの内容を定期的に確認することをお薦めします。イベント・ログに未読のエラー・メッセージが含まれる場合、「Status」パネルの項目「Event log」項目にエラー・アイコンが表示されます。ほとんどのイベントはすぐにレポートされますが、コレクタ関連のイベントはレポートされるまで最大で5分かかることに注意してください。
イベント・ログを確認する手順は、次のとおりです。
「System」→「Status」→「Event log」の順に選択します。図9-18に示すようなダイアログに最近のイベントが表示されます。
ツールバーのコントロールを使用して、イベントのリストをスクロールします。表示される各ログ・ページには、レポートされるイベントが最大100件まで含まれます。デフォルトでは、すべてのイベント・タイプが表示されます。ただし、「Severity」メニューを使用すると、選択したカテゴリのみに制限してリストを表示できます。イベントの潜在的な影響は次の重大度によって示されます。
Info: ユーザーが開始したアクションを示します。たとえば、コレクタの再起動、新規ユーザー・アカウントの作成、構成のバックアップまたはリストアがあります。
Warning: RUEIインストールの障害を引き起こす可能性があるイベントを示します。たとえば、レポータ・システムのディスク領域が不足しかけている、またはログ・ファイルの処理でバックログが増えている場合です。
Error: RUEIインストールが完全には作動しなくなるイベントを示します。たとえば、リモート・コレクタが使用できなくなる場合です。
また、「Status」メニューを使用すると、レポートされるすべてのイベントを表示したり、新しい（未読）イベントのみに表示リストを制限したりできます。
|
注意: 5分間の期間内に同じイベントが複数回発生した場合は、レポートされるイベント内にリピート・カウンタが表示されます。 |
オプションとして、「Event」メニューで次のオプションを選択できます。
Mark all events as read: 新しい（未読）イベントが太字で表示されます。読んだ後ではハイライト表示は解除されます。このオプションを使用して、イベント・リスト内のすべてのハイライトを消去し、「Status」パネルの「Event log」項目のステータスを「OK」にリセットします。
Reload: 表示されたイベント・リストを、ログを開いてから発生したイベント情報を使用して更新します。ツールバーの「Reload」アイコンをクリックしても同じ操作を実行できます。
Close: イベント・ログを閉じます。
表示されているイベントをクリックすると、その詳細を表示できます。図9-19に示すようなダイアログが表示されます。
このダイアログでは、完全なイベント・テキストと関連するイベント・コードが表示されます。カスタマ・サポートに問い合せるときには、これら両方を指定する必要があることに注意してください。リモート・コレクタの場合、レポートされるソースはコレクタのIPアドレスです。
RUEIでは、テキスト・メッセージ通知の使用がサポートされています。この機能を使用するには、使用するすべてのテキスト・メッセージ・プロバイダを構成してシステムに認識させる必要があります。プロバイダ情報を管理するには、「System」→「Maintenance」→「Text message providers」の順に選択します。図9-20に示すダイアログが表示されます。
テキスト・メッセージ・プロバイダを構成する手順は、次のとおりです。
「«Add new account»」をクリックして、新規テキスト・メッセージ・プロバイダを定義します。図9-21に示すダイアログが表示されます。
リストから目的のテキスト・メッセージ・プロバイダを選択します。リストには、サポートされている事前定義済のサービスが多数用意されています。これらの各サービスを使用するには、該当するプロバイダのアカウントが必要です。次に、「Next」をクリックします。図9-22に示すようなダイアログが表示されます。
|
重要: 「Local GSM modem」を指定する場合は、システムにGSMモデムを装着しておく必要があります。装着が必要なローカル・モデムは、USBまたはシリアルGSM ETSI 07.05準拠のモデムです。 |
ダイアログに表示される正確なフィールドは、図9-21で選択したプロバイダによって異なります。たとえば、「Local GSM modem」を選択した場合は、ローカル・ポートとモデムのボー・レートを指定する必要があります。不明な場合は、自動検出を使用できます。オプションで、SIM PINも指定できます（必要な場合）。
事前定義済のMollieまたはClickatellサービスを選択した場合は、アカウントのユーザー名、パスワード、作成者、API IDおよびプロトコル送信メソッドを指定する必要があります。これらの情報は、アカウント・プロバイダによって提供されます。次に、「Save」をクリックします。図9-20に示すダイアログ・ボックスに戻ります。
リストでプロバイダを右クリックし、「Move up」および「Move down」オプションを使用してリスト内のプロバイダの位置を制御します。プロバイダは、リストでの順序どおりに試行されます。つまり、最初のアカウントが試行され、それが失敗すると2番目のアカウントが試行されます（それ以降についても同様）。
次に、「Close」をクリックしてダイアログを閉じます。
テキスト・メッセージではUnicodeがサポートされていますが、多数の制限事項があることを認識しておく必要があります。ローカルに装着したモデムの場合では、7ビットGSM 3.38アルファベットを使用してメッセージが送信されます。サポートされていない文字が元のメッセージに含まれる場合は、疑問符（?）文字に置換されます。外部サービス・プロバイダの場合は、マルチバイト・キャラクタ・セットのサポートに関してサービス・プロバイダに問い合せることをお薦めします。ローカルに装着したモデムと外部サービス・プロバイダの両方で、テキスト・メッセージは160文字に制限されます。
RUEIの使用または操作に関して問題が発生した場合は、Oracleサポート・サービスに問い合せることができます。ただし、その前に、ご使用のシステムのヘルプデスク・レポート・ファイルを作成することをお薦めします。それには、「System」→「Configuration」→「Helpdesk report」の順に選択します。ファイルのダウンロード先となる場所を指定するように求められます。
ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。
このファイルにはソフトウェアの所有権情報が含まれていることに注意してください。そのコンテンツは変更しないでください。
ネットワーク・データ・コレクタのステータスを表示したり、新規コレクタを追加するには、「System」→「Maintenance」→「Network Data Collectors」の順に選択します。この機能の使用方法は、9.2項「コレクタのステータスの表示」で説明されている方法と同じです。
原因不明の問題が発生した場合は、処理が適切に動作して同期化されるように、処理をリセットできます。ただし、このオプションを選択すると、データの可用性と監視に一時的な遅延が発生します。
最後の手段として、収集されたすべてのデータをシステムから削除できます。また、すべてのパラメータ（作成されたユーザーや環境パラメータなど）をデフォルト値にリセットできます。
システムをリセットする手順は、次のとおりです。
「System」→「Maintenance」→「System reset」の順に選択します。図9-23に示すダイアログが表示されます。
次のうち必要なオプションを選択します。
Restart system processing: システム処理を再アクティブ化します。このオプションがデフォルトです。
Purge collected data: 収集されたすべてのデータをシステムから削除します。
Reset to factory defaults: 収集されたすべてのデータとSSL鍵を削除し、すべてのシステム・パラメータをデフォルト値にリセットします。
次に、「Next」をクリックします。
|
注意: 「Purge collected data」および「Reset to factory defaults」オプションは、実行すると取消しできません。収集されたすべてのデータが消去されます。「Reset to factory defaults」の場合、すべてのシステム設定も元の状態に戻ります。したがって、レポータ・インタフェースにアクセスするには、初期構成をすべて（およびset-admin-password.shスクリプトを使用したadminユーザー・パスワードの定義）行うことが必要になります。以前にバックアップを作成している場合（9.8項「構成バックアップの作成とリストア」を参照）は、初期構成後にそのバックアップをリストアできます。この初期構成の手順は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。 |
2.2項「メーリング機能の使用方法」で説明されているように、RUEIでは要求されたレポートの自動電子メールを送信できます。この機能では、初期構成フェーズ（『Oracle Real User Experience Insightインストレーション・ガイド』を参照）で指定した情報が使用されます。ただし、「System」→「Maintenance」→「Mail setup」の順に選択して、この構成を変更できます。図9-24に示すダイアログが表示されます。
このダイアログを使用して、次の情報を指定します。
Return address: 失敗した電子メールまたは問題が発生した電子メールのレポート先となる電子メール・アドレスを指定します。このアドレスを定期的にチェックすることをお薦めします。
From address: 受信者のメール・クライアントに表示されるアドレスを指定します。
Reply-to address: ユーザーが電子メール内でクリックして返信できるアドレスを指定します。このアドレスを指定しない場合は、「From address」設定が使用されます。
Mail size limit: 電子メールの最大許容メッセージ・サイズ（KB単位）を指定します。電子メールにこの制限を超えるレポートが含まれる場合は、この制限に対応するために、レポートが個別の電子メールに分割されます。個別に送信するには大きすぎるレポートは送信されず、ユーザーに問題が通知されます。デフォルトのメール・サイズ制限は5000KBです。
Reporter URL: 電子メールの受信者がレポータ・システムに接続するために必要となる詳細なURLを指定します。通常、このURLは、RUEIユーザーがレポータ・システムにアクセスするために使用するURLと同じです。
1.6項「環境のカスタマイズ」で説明されているとおり、ユーザーはセッションで使用される書式設定をカスタマイズできます。ユーザーは、小数点に使用する文字、3桁区切りに使用する文字、および使用する日付書式を指定できます。管理者が、システム全体にわたるこれらの設定のデフォルト値を指定することもできます。それには、「System」→「Maintenance」→「Formatting preferences」の順に選択します。
特定の期間の完全なデータが得られないイベントが発生することがあります。たとえば、コレクタの再起動ではネットワーク・データが記録されない短い期間が生じる場合があります。RUEIを構成して、情報メッセージと一緒に、影響を受ける期間を示すことができます。例を図9-25に示します。
ハイライト表示されるのはイベントがいつ発生したかという情報のみです。影響を受けるデータ分野の包括的な分析は提供されません。したがって、時間ベースの情報しか得られません。また、この画面の上部に表示される情報メッセージは、特定の期間に表示されるインジケータとともに、データ・ブラウザのエクスポート画面とレポート画面に表示されますが、エクスポートされるデータには含まれません。
必要なしきい値を指定して、このハイライトの表示を制御できます。つまり、現在選択されている期間でどれくらいのデータが影響を受けたらハイライト表示するかを指定します。指定したしきい値が組織のレポート要件に合っていることをよく確認してください。たとえば、しきい値を5%に設定した場合を考えます。期間が3時間であればそのうち1時間分の損失は33%です。ただし、選択された期間が1日であれば同じ1時間分でもおよそ4%です。デフォルトではしきい値は2%です。
ハイライト表示のしきい値の設定
ハイライト表示のしきい値を指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Data visualization」→「Data reliability threshold」を順に選択します。図9-26に示すダイアログが表示されます。
「Enabled」チェック・ボックスを使用して、データの信頼性に関する警告の表示を有効にします。
現在選択されている期間で完全なデータが得られないことをハイライト表示するために使用されるしきい値を指定します。デフォルトは2%です。
次に、「Save」をクリックします。この設定は、変更すると、即座に有効になります。
デフォルトでは、最新の（未完了）期間の情報は、選択されている期間の現時点の分までが常に表示されます。グラフではこの部分は点線で表示されます。例を図9-27に示します。
未完了期間のレポート時期の指定
未完了の期間をいつレポートするかを指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Data visualization」→「Current period reporting」を順に選択します。図9-28に示すダイアログが表示されます。
最新期間をレポートするときに使用する視覚表現を選択します。次のオプションがあります。
Enabled: すべての未完了期間をすべてのグラフでレポートすることを指定します。値リスト、レポートおよびエクスポートにも含めます。このオプションがデフォルトです。
Disabled: 未完了期間はレポートしないことを指定します。
Specified: 未完了期間は特定の視覚表現のみでレポートすることを指定します。「Value list」オプションには、データ・ブラウザの値リストだけでなく、レポートとエクスポートも含まれることに注意してください。
次に、「Save」をクリックします。この設定は、変更すると、即座に有効になります。
ユーザー定義の処理を開始するには、「System」→「User management」の順に選択します。図9-29に示す画面が表示されます。
この画面には、現在定義されているシステム・ユーザーが表示されます。ユーザーごとに、アカウント名、フルネーム、電子メール・アドレスおよび認証メカニズムが表示されています。ユーザーのロールとステータスは、図9-30に示すカラー・コードを使用して表示されます。
ユーザー認証
システム・ユーザーの認証は、RUEIそのものがデータベースに格納されているユーザー情報を使用して実行することも、外部の認証サーバーによって実行することもできます。現在、RUEIでは2つの外部認証メカニズムがサポートされています。LDAPサーバーを使用する方法とOracle Single Sign-On（SSO）サーバーを使用する方法です。いずれの場合も、サーバーがRUEIと一緒に機能するように構成されている必要があります。LDAPサーバーを構成する手順の詳細は、9.18.5項「LDAPサーバーのユーザー認証の構成」に記載されています。Oracle SSOサーバーを構成する手順の詳細は、9.18.6項「Oracle Single Sign-On（SSO）のユーザー認証の構成」に記載されています。
新規ユーザーを作成する手順は、次のとおりです。
「System」→「User management」の順に選択し、タスクバーの「Add new user」コマンド・ボタンをクリックします（図9-29を参照）。LDAPサーバー接続が構成されている場合（9.18.5項「LDAPサーバーのユーザー認証の構成」を参照）は、図9-31に示すダイアログが表示されます。そうでない場合は、図9-32に示すようなダイアログが表示されるため、手順3に進んでください。
図9-31に示したラジオ・ボタンを使用して、新規ユーザー・アカウントの作成とその関連ユーザー設定を、インストール済RUEIでの設定（デフォルト）または構成済のLDAPサーバーのどちらと照合して認証するかを指定します。次に、「Next」をクリックします。LDAPサーバーが構成されている場合は、図9-32に示したダイアログが表示されます。構成されていない場合は、図9-35に示すようなダイアログが表示されます。
図9-32に示すダイアログを使用して、新規ユーザーに関する次の情報を指定します。
インストール済RUEI内でユーザーを識別するユーザー名。この名前は一意である必要があります。ユーザー名は大/小文字が区別されます。Oracle SSOサーバーのユーザー認証が有効になっている場合、ユーザーは自動的にOracle SSOユーザーとして作成されることに注意してください。この場合、指定されるユーザー名はOracle SSOサーバーに定義されたユーザー名と同じであることが必要です。
ユーザーのフルネーム。
ユーザーの電子メール・アドレス。これがレポートと電子メール・アラートの送信先アドレスになります。正しいアドレスであることを確認してください。
ユーザーをインストール済RUEIでのローカルの設定と照合して認証する場合は、新規ユーザーのパスワードを指定および確認入力しておく必要があります。パスワード要件の詳細は、9.18.4項「パスワード・セキュリティ・ポリシーの強制」を参照してください。新規パスワードはユーザーが7日以内に変更する必要があります。変更しないと、ユーザーがロックされます。
必要に応じて、「Disabled」チェック・ボックスを使用して、当座の間ユーザーを無効化できます。無効化したユーザーは後で有効化することもできます。
図9-31で構成済のLDAPサーバーに対してユーザーを認証するように選択した場合は、「Get user data from LDAP」ボタンをクリックして、構成済のLDAPサーバーからユーザーの設定を取得できます。
次に、「Next」をクリックして続行します。図9-33に示すダイアログが表示されます。
チェック・ボックスとメニューを使用して、新規ユーザーに割り当てるロールと権限を指定します。これらについては、1.4項「ユーザー・ロールと権限の概要」で説明します。新規ユーザーに割り当てられる権限が「Full」アクセス・レベル権限を下回る場合は、「Authorize for」メニューを使用して、ユーザーが情報を見ることができる特定のアプリケーション、スイートおよびサービスを指定する必要があります。「Finish」をクリックして、ユーザー定義を作成します。図9-29に示したユーザー・リストに戻ります。
|
注意: 前述の設定の他に、多数の追加設定（言語やメーリング・タイプなど）があります。これらはユーザーの作成時にデフォルト値に設定されます。これらの追加設定は、1.6項「環境のカスタマイズ」に説明されている手順を使用して変更することもできます。 |
ユーザー定義を変更するには、「System」→「User management」の順に選択します。図9-29に示す「User management」パネルが表示されます。目的のユーザーを右クリックします。図9-34に示すコンテキスト・メニューが表示されます。
次のオプションがあります。
Edit: ユーザーの定義を変更できます。この詳細は、9.18.3項「ユーザーの設定の変更」に記載されています。
Enable/Disable account: 当座の間、ユーザー・アカウントを有効化または無効化できます。現時点で定義されているすべてのユーザーは、SSO認証が有効化されると無効になります。また、すべてのSSOユーザー・アカウントはSSO認証が無効化されると無効になることに注意してください。
Switch to: 選択したユーザーに一時的に切り替えることができます。このオプションは、そのユーザーに表示権限があるモジュールやレポートを表示する場合に役立ちます。自身のロールに戻るには、「View」メニューから「Switch back」を選択します。選択したユーザー・アカウントが無効の場合には、このオプションは使用できないことに注意してください。
Remove: 選択したユーザーをシステムのユーザー管理から削除します。そのユーザーが作成したプライベート・レポートも削除されるため、注意してください。ただし、そのユーザーが作成したパブリック・レポートは引き続き他のユーザーから使用できます。
既存のユーザーの設定を変更する手順は、次のとおりです。
図9-29に示したユーザー・リスト内で目的のユーザーを選択し、「Edit」を選択します。LDAPサーバー接続が構成されている場合（9.18.5項「LDAPサーバーのユーザー認証の構成」を参照）は、図9-31に示したようなダイアログが表示されます。そうでない場合は、図9-35に示すダイアログが表示されるため、手順3に進んでください。
ラジオ・ボタンを使用して、ユーザーの設定を、インストール済RUEIでの設定（デフォルト）または構成済のLDAPサーバーのどちらと照合して認証するかを指定します。次に、「Next」をクリックします。LDAPサーバーが構成されている場合は、図9-32に示したダイアログが表示されます。そうでない場合は、図9-35に示すダイアログが表示されます。
必要に応じて、表示された任意の情報を変更します。赤のアスタリスクが付いているフィールドは必須であることに注意してください。つまり、空白にはできません。
SSOユーザーのアカウントを変更しているときに、SSO認証が無効になると、そのアカウントはローカル認証アカウントに自動的に変換されることに注意してください。したがって、ユーザーのパスワードの指定と確認が必須になります。
「Disabled」チェック・ボックスを使用して、ユーザーによるこのアカウントの使用を無効化できます。無効化したユーザーは後で有効化することもできます。この機能も役立ちます。前述のように、現時点で定義されているすべてのユーザー・アカウントは、SSO認証が有効化されると無効になり、すべてのSSOユーザー・アカウントはSSO認証が無効化されると無効になるためです。
ユーザーが正しいパスワードの入力を5回連続して失敗すると、ユーザー・アカウントは自動的にロックされます。このような場合は、「Locked」チェック・ボックスの選択を解除してロックをリセットできます。パスワード・セキュリティの詳細は、9.18.4項「パスワード・セキュリティ・ポリシーの強制」に記載されています。このチェック・ボックスを使用して、ユーザーのアカウントのロックを解除できます。次に、「Next」をクリックします。図9-36に示すダイアログが表示されます。
|
注意: ユーザーのパスワードがこのインタフェースで変更された場合、ユーザーはパスワードを自分で7日以内に変更する必要があります（1.6項「環境のカスタマイズ」に記載されている手順を使用）。そうしないと、アカウントがロックされます。 |
必要に応じて、次の設定を変更できます。
Mailing type: ユーザーが受け取るレポートを複数の電子メール（レポートごとに1つ）で送信するか、単一の電子メールにバンドルするかを指定します。デフォルトは複数の電子メールです。
Startup module: ユーザーがセッションを開始するモジュールを指定します（たとえば、「Reports」、「System」または「User management」）。デフォルトはダッシュボードです（1.7項「ダッシュボードの使用」を参照）。
次に、「Next」をクリックします。図9-33に示すようなダイアログが表示されます。
オプションとして、チェック・ボックスとメニューを使用して、ユーザーに割り当てるロールと権限を指定します。これらについては、1.4項「ユーザー・ロールと権限の概要」で説明します。新規ユーザーに「Full」アクセス・レベル権限が割り当てられない場合は、「Authorize for」メニューを使用して、そのユーザーが表示できる特定のアプリケーション、スイートおよびサービスを指定する必要があります。次に、「Finish」をクリックして、変更を有効にします。
スーパー管理者パスワードのリセット
adminユーザーのパスワードをリセットする必要がある場合は、set-admin-password.shスクリプトを使用してリセットできます。この詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。新しいパスワードは7日以内に変更する必要があることに注意してください（9.18.3項「ユーザーの設定の変更」の手順を使用します）。
各ユーザーを定義してRUEIを使用できるように認可する必要があります。この手順の詳細は、9.18項「ユーザーと権限の管理」に記載されています。インストール環境のセキュリティを最適化するために、パスワード設定機能を使用して組織のセキュリティ・ポリシーを強制できます。具体的には、ユーザー・パスワードの最大長、ユーザーがパスワードを変更する必要がある頻度、新規ユーザー・アカウント作成後のパスワードの変更期限、およびユーザー・アカウントがロックされるまでのログオン試行の失敗回数を制御できます。
インストール環境のパスワードの強制を設定する手順は、次のとおりです。
「System」→「User management」→「Password settings」をクリックします。図9-37に示すダイアログが表示されます。
「Minimum length」フィールドを使用して、ユーザー・パスワードとして必要な最小文字数を指定します。8〜255文字を指定する必要があります。デフォルトは8文字です。
「Expiration age」フィールドを使用して、パスワード変更をユーザーに要求する頻度を指定します。デフォルトは60日です。0に設定すると、パスワードが無期限になります。最大の有効期限は999日です。
「Initial expiration age」フィールドを使用して、新規ユーザー・アカウントを作成した後で初期パスワードを変更する必要がある期限を指定します。これには1〜30日を指定する必要があります。これによって、管理者がユーザーのパスワードをリセットした後にユーザー自身がパスワードを変更する必要がある期限も指定されます。デフォルトは7日です。
「Allowed login attempts」フィールドを使用して、ユーザー・アカウントがロックされるログイン試行の失敗回数を指定します。これには1〜10回を指定する必要があります。デフォルトは5回です。
次に、「Save」をクリックします。
パスワードの強制
ユーザーを作成して認可すると、次のルールが自動的に強制されます。
指定の回数の試行が失敗すると、ユーザー・アカウントがロックされます。ユーザーが再度ログオンできるようにするには、アカウントのロックを解除する必要があります（9.18.3項「ユーザーの設定の変更」を参照）。ただし、ロックされたユーザーにも、メール送信されるレポートやアラートが引き続き届きます。
パスワードの有効期限を0に設定し、後で0以外の値に再設定した場合（またはその逆の場合）、新しく指定した方のパスワード有効期限が既存のすべてのユーザー・アカウントに適用されます。
ユーザー・パスワードの最小長は8文字です。ユーザー・パスワードには、英数字以外の文字（$、@、&、!など）を少なくとも1文字含める必要があります。
パスワードには、定義済のユーザー名またはその姓や名を含めることはできません。また、ユーザーの直前の3つのパスワードも記憶され、再使用できません。
パスワードは大/小文字が区別されます。
セキュリティを強化するために、インストール済RUEIのローカルでの設定を使用せずにLDAPサーバーを使用してユーザー認証を有効化するようにRUEIを構成できます。LDAPサーバー接続が構成されている場合は、定義済のユーザーごとに、使用する認証方式を指定できます。adminユーザーは事前定義済であり、そのパスワードは初期構成時に設定されるため（『Oracle Real User Experience Insightインストレーション・ガイド』を参照）、管理者ユーザーにはローカル認証のみを使用できます。
LDAP認証を使用する場合は、ユーザー・アカウントを作成する前にLDAP接続を定義することをお薦めします。これは、以前に指定したユーザー設定の変更を不要にするためです。
LDAPサーバー接続の構成
LDAPサーバー認証を有効化する手順は、次のとおりです。
「System」→「User management」→「Configure LDAP connection」をクリックします。LDAPサーバー接続がすでに構成されている場合、最後のオプションは「Modify LDAP connection」として表示されます。図9-38に示すダイアログが表示されます。
「Allow LDAP authentication」チェック・ボックスを使用して、ユーザー認証にLDAPサーバーを使用できるようにするかどうかを指定します。デフォルトでは選択されていません（無効化されています）。
「Server name」フィールドを使用して、使用するLDAPサーバーのホスト名またはIPアドレスを指定します。サーバー名にはプロトコル情報（LDAP://など）を含めないでください。
「Connection type」メニューを使用して、LDAPのバージョンと接続方法を指定します。デフォルトはV2（非セキュア）です。
「Port number」フィールドを使用して、LDAPサーバーがリスニングするポートを指定します。この情報については、必要に応じてシステム管理者に問い合せてください。デフォルト・ポートは389または636（SSL暗号化用）です。
「Search base」フィールドを使用して、ディレクトリ構造内でユーザーIDが一意である場所を指定します。この場所には有効なDNを指定する必要があります。パフォーマンス上の理由により、この場所にはできるかぎり深いディレクトリを指定してください。デフォルトはディレクトリ・ツリーのルートです。
「Anonymous」チェック・ボックスを選択して、匿名ユーザーを使用してLDAPサーバー参照を実行するかどうかを指定します。選択しない場合は、有効な識別名（DN）を指定する必要があります。このユーザーのパスワードは、新規ユーザーとして作成される際に要求されます。デフォルトでは、匿名参照が使用されます。
「User ID」、「Email address」および「Full name」の各フィールドを使用して、LDAPサーバーからユーザー設定を抽出するために使用する属性を指定します。デフォルトは標準のLDAP機能に基づいています。これらの属性については、必要に応じてLDAP管理者に問い合せてください。
必要に応じて、「Test」をクリックして、LDAPサーバーに対して、機能する接続を確立できるかどうかを検査できます。この詳細は次の項に記載されています。
次に、「Save」をクリックします。
LDAP構成設定に対して指定した変更は即座に有効になります。
LDAPサーバーのテスト
前述のように、LDAPサーバーに対する接続はテストできます。次を実行します。
セキュリティを強化するために、LDAPサーバーまたはインストール済RUEIのローカルでの設定を使用せずに、Oracle Single Sign-On（SSO）サーバーを使用してユーザー認証を有効化するようにRUEIを構成できます。
これを有効化すると、RUEIユーザー（adminユーザー以外）は自動的にOracle SSOログオン・ページにリダイレクトされます。ユーザーは、RUEIログイン・ダイアログ（図1-1を参照）ではなく、このページからRUEIにログオンします。adminユーザーは事前定義済であり、そのパスワードは初期構成時に設定されるため（『Oracle Real User Experience Insightインストレーション・ガイド』を参照）、adminユーザーにはローカル認証のみを使用できます。管理者権限を持つ他のユーザーも、Oracle SSOサーバーからログオンする必要があることに注意してください。
SSOサーバーのアクティブ化
SSOサーバーをアクティブにする手順は、次のとおりです。
「System」→「User management」→「Configure SSO connection」をクリックします。Oracle SSOサーバー接続がすでにアクティブになっている場合、最後のオプションは「Modify SSO connection」として表示されます。図9-40に示すようなダイアログが表示されます。
図9-40 「Oracle Single Sign-On (SSO) Settings」ダイアログ
「Enable/Disable Oracle SSO」チェック・ボックスを使用して、ユーザー認証にSSOサーバーを使用できるようにするかどうかを指定します。デフォルトでは選択されていません（無効化されています）。次に、「Save」をクリックします。
Oracle SSOサーバーを有効化または無効化した後では、RUEIからログアウトして再びログオンすることをお薦めします。こうすることで、RUEIインストールが確実に変更を反映します。
Oracle SSO認証の有効化
ユーザー認証にOracle SSOサーバーを使用するときは、次の点に注意することが重要です。
複数のSSO登録アプリケーションにユーザーがログオンしているとき、1つのアプリケーションからログアウトすると、RUEIを含む他のすべてのSSO登録アプリケーションからもログアウトします。同様に、ユーザーがRUEIからログアウトすると、SSOセッションからもログアウトします。
SSO認証が有効化されているとき:
LDAP認証は自動的に無効化されます。
レポータ・インタフェースでユーザーのパスワードを変更することはできません。ただし、adminユーザーのパスワードは引き続き変更できます。前述のように、このパスワードはローカルで認証されるためです。
現時点で定義されているすべてのRUEIユーザーは無効になります。これには管理者権限を持つユーザーも含まれます（adminユーザーを除く）。
Oracle SSO以外の既存のユーザー・アカウントを変更すると、ユーザー・アカウント名が小文字に変換されます。
現時点で定義されているパスワード・ポリシー設定（9.18.4項「パスワード・セキュリティ・ポリシーの強制」を参照）は、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章を参照してください。
エンリッチ・データ交換機能を使用すると、RUEIで収集されたデータに対して他の分析を行うことが可能になります。特に、RUEIで収集されたデータと他のデータ・ウェアハウスのデータを組み合せることができます。他のデータ・ウェアハウスとは、カスタマ・リレーションシップ・マネジメント（CRM）システムやビジネス・インテリジェンス（BI）システムなどです。この機能を使用すると、収集されたデータから様々な組合せ（製品名、買い物カゴの値およびアドレス情報など）を抽出できます。外部ツールは、Unicode（UTF-8）形式のデータを認識できるものである必要があります。
2.11項「レポート・データのエクスポート」で説明されている機能はデータのレポートに限定されていますが、エンリッチ・データ交換機能ではページベースのすべてのデータをエクスポートできます。また、レポート・データのエクスポートではHTTPS転送を使用しますが、エンリッチ・データ交換ではSFTPファイル転送を使用します。後述のように、RUEIで通常収集されないヘッダー情報を含めるように、エクスポートされるデータのコンテンツをカスタマイズすることもできます。エクスポートされるデータはページベースであるため、使用可能なデータはアプリケーション・データに制限され、サービス関連のデータは含まれません。
エンリッチ・データ交換を使用したBI実装の例
この項では、エンリッチ・データ交換機能を使用してデータを利用するBIソリューションの概要を示します。このソリューションでは、Oracle Business Intelligence基盤（Oracle Fusion Middleware製品ファミリの一部）が使用されます。その構造の概略図を図9-41に示します。
フレームワークはOracle Warehouse Builder（OWB）に基づきます。RUEIで取得されたデータはロード・データベースにアップロードされます。このデータベースからステージング・データベースを介して、本番データベースにデータが移入されます。本番DWHにデータが移入されると、様々なレポートやダッシュボードを介してRUEIデータが使用可能になります。このようなレポートの例を図9-42に示します。
エンリッチ・データ交換の有効化および無効化
エンリッチ・データ交換を有効化する手順は、次のとおりです。
「Configuration」→「Applications」→「Enriched data exchange」の順に選択します。図9-43に示す画面が表示されます。
「Enabled」チェック・ボックスを使用して、エンリッチ・データ交換機能を有効化または無効化します。デフォルトでは、有効化されています。
必要に応じて、エクスポートされるデータに含める追加のデータ・アイテムを定義できます。一般に、これらのデータ・アイテムは、RUEIでは通常収集されないクライアント・リクエスト・ヘッダーまたはサーバー・レスポンス・ヘッダー内の要素ですが、エクスポートされるデータには含めることができます。それには、「«Add new data item»」をクリックします。図9-44に示すダイアログが表示されます。
「Source type」メニューを使用して、RUEIで収集されたデータ内で必要な項目を識別する方法と検索範囲を定義します。リテラル検索またはXPath式を使用してクライアント・リクエスト・ヘッダーまたはサーバー・レスポンス・ヘッダー内で検索するように指定することも、カスタムのページ・タグ付け実装内で特定のタグを検索するように指定することもできます。カスタムのページ・タグ付けスキームのサポートの詳細は、付録A「タグ付け規則」を参照してください。
「Source value」フィールドを使用して、データ・アイテムの値の取得元にする特定の引数または要素を指定します。
「Export name」フィールドを使用して、データ・アイテムに割り当てる名前を指定します。これが項目の要素名になります。たとえば、productという名前を指定すると、一致するすべてのデータが<product>というエクスポート・ファイルにエクスポートされます。「Source type」メニューでヘッダー関連のオプションを選択した場合、このフィールドは使用できません。
次に、「Save」をクリックします。新規データ・アイテムが監視対象のトラフィックから見つかった場合、そのデータ・アイテムは5分〜10分以内でエクスポート・ファイルにレポートされ始めます。
既存のデータ・アイテムを変更するには、図9-43で項目を右クリックして「Edit」を選択します。また、「Remove」を選択して項目を削除したり、「Remove all」を選択して現在定義されているすべての項目を削除できます。
データはページ・ビューに基づき、XML形式でエクスポートされます。そのため、エクスポートされたデータは様々なシステムに即座にインポートできます。エクスポートされるXMLの構造は、XSDファイルで定義されます。XMLスキーマを図9-45に示します。
スキーマに用意されている標準のデータ・アイテムの詳細は、付録D「データ・アイテムの概要」を参照してください。
ファイルの場所とネーミング構造
エンリッチ・データのエクスポート機能を有効化すると、エクスポート・ファイルが5分ごとに作成されます。ファイルはUnicode（UTF-8）でエンコードされます。ファイルの場所は、ディレクトリ/var/opt/ruei/processor/xml-events/wg/xml-sespageです。このディレクトリ内の各ファイルには、次のネーミング構造が使用されます。
yyyymmdd-hhmmss-nnnn[L|M].xml.gz
構造の各要素の意味は、次のとおりです。
nnnnは、ファイル順序を示します。エクスポート・ファイルは5分ごとに作成されるため、1日当たり288ファイルを作成できます。ファイル順序の範囲は0001〜0289まであります。
Lは、その日の最後のファイルであることを示します。このファイルのファイル順序は常に289になります。このファイルは、24時間後に開いていたセッションを収集するために使用されます。
Mは、このファイルの後にもファイルが続くことを示します。
デフォルトでは、エクスポートの保存期間は7日であり、それを過ぎると自動的に削除されます。ただし、この設定は構成できます。構成方法の詳細は、9.5項「データベースおよびディスクの領域制限とアラートの構成」に記載されています。これらのファイルにアクセスするには、レポータ・システムに対する正常なFTPファイル転送接続が必要です。この機能の詳細は、システム管理者に問い合せてください。
必要に応じて、シンボリック・リンク定義を使用して、ファイルのエクスポート先とする場所を変更できます。この機能の使用方法の詳細は、システム管理者に問い合せてください。
セキュリティに関する考慮事項
エンリッチ・データ交換機能によって生成されたデータへのアクセスはオペレーティング・システム・レベルで複数の異なる方法で制御できますが、エクスポートされたデータを含むディレクトリには最小限のアクセス権しか持たないOSユーザーを別に、SCP/SFTPを使用して作成しておくことをお薦めします。次に、scpコマンドを使用して、データをローカル・システムにコピーできます。次に例を示します。
scp -r <OS user>@Reporter:/var/opt/ruei/processor/xml-events/wg/xml-sespage/ 20080903 .
