| Oracle® Real User Experience Insightユーザーズ・ガイド リリース11.1 for Linux x86-64 B63041-01 |
|
 前へ |
 次へ |
この章では、管理者が実行するタスクについて説明します。これには、システムのステータスの監視、バックアップおよびアップグレードの実行、イベント・ログの処理、システム・ユーザーの管理、データ保存ポリシーの構成が含まれます。
管理者は、システムの状態を確認し、ステータス・ページで自動ステータス監視メッセージを受信できます。このページにアクセスするには、「System」→「Status」を選択します。例を図15-1に示します。
Statusページでは、接続されているコレクタのステータス、ログ・ファイル処理、システムにおける現在の処理レベル、ユーザーのデータベース表領域に十分な領域があるかどうか、およびイベント・ログを確認できます。また、システム・ステータス・エラーに関する通知を受け取るユーザー(およびその方法)を構成することもできます。
コンポーネントの失敗の概要
図15-1に示す各コンポーネントは、現在のステータスを示しています。通常の運用では、これは「OK」とレポートされます。ただし、1つ以上のコンポーネントで「Error」とレポートされる場合は、表15-1の情報を使用して、問題の特定と解決を行ってください。
表15-1 レポートされたエラーの原因
| コンポーネント | 考えられる原因 |
|---|---|
|
Collector status |
|
|
Log file processing |
|
|
Data processing |
|
|
Event log |
|
|
Database space available |
|
|
Disk space |
|
図15-1に示したシステム・ステータス・インジケータが更新されるのは、ブラウザ画面のリフレッシュ時のみです。1つ以上のシステム・プロセスで障害が発生していることが検出されたときにシステム・アラートを生成するように設定できます(15.3項「システム障害アラートの構成」を参照)。このため、1つのプロセスに一時的に障害が発生していることが(赤いxによって)示されるが、アラートは生成されないという状況が生じる場合があります。これは、システム・プロセスがチェックされる時点までにシステム・ステータス・インジケータが正常状態に戻っていたことが原因です。
このような設計のため、アラートがトリガーされた場合は、システム障害が発生し始めているという警告とみなすことをお薦めします。障害は、デフォルトの境界よりもシステム遅延の方が長くなった結果、発生する場合があります。たとえば、監視対象の行がヒットした時点と、このヒットに基づく情報がレポータで使用可能になる時点との間の待機時間がそれほど長くない場合です。この待機時間が、トラフィックが多い環境における境界を超えている可能性があります。また、障害は、トラフィックが一時的にピークを示した結果である場合もあります。ただし、この状況が続く場合は、監視対象のトラフィック・レベルを確認することをお薦めします。
システムに接続された各コレクタのステータスを表示するには、「System」→「Status」→「Collector status」を選択します。これにより、Network data Collectors statusウィンドウが開きます。例を図15-2に示します。
「System (localhost)」項目はレポート・システム上のコレクタ・インスタンスを示すことに注意してください。ネットワーク内の他のコレクタは、IPアドレスで表します。目的のコレクタをクリックするか、またはコンテキスト・メニューから「View statistics」を選択して、コレクタの監視対象トラフィックの詳細なレポートを表示します。例を図15-3に示します。
このウィンドウに表示される情報は、選択したコレクタについて午前0時以降またはカウンタのリセット以降に監視されたトラフィックを示します。ウィンドウの左下にある「Uptime」フィールドは、コレクタが稼働している時間を示します。コレクタが構成を更新するために再起動されると、この稼働時間はリセットされます。ウィンドウに表示されているすべてのHTTPリクエスト・カウンタをリセットするには、「View」メニューで「Reset counters」を選択します。このカウンタが自動的にリセットされるのは、ネットワーク・パケットが次回検出されたときです。このため、ネットワーク・トラフィックが行われていないインストール環境の場合、カウンタはリセットされません。この表示は2秒ごとに自動的にリフレッシュされます。
Collector Statisticsウィンドウの使用
ウィンドウの左上部分にあるタブにより、選択したコレクタによって監視されたトラフィックの詳細なブレークダウンを確認できます。これについて表15-2で説明します。
表15-2 「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%に近づいた場合は、データがコレクタによって削除されないようにするためのアクションを即座に実行する必要があります。トラフィックのサンプリングは、13.3.3項「全体のトラフィックの制限」を参照してください。これでも問題が解決されない場合は、Oracleサポート・サービスに連絡することも必要になってきます。コレクタのメモリー使用率も示されます。最大メモリーしきい値は、レポータとコレクタが両方ともあるシステムの場合は30%、コレクタのみのシステムの場合は70%です。 |
SSLトラフィックおよびFormsトラフィックの監視
SSLトラフィックおよびOracle Formsトラフィックは、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。
したがって、各コレクタが信頼性の高いネットワーク・デバイス(TAPなど)に接続されることを確認する必要があります。また、Collector Statisticsウィンドウに表示される情報を定期的に調べて、TCPパケット・ストリームが正常な状態であることを確認するように強くお薦めします。TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。
KPIおよびSLAの違反に関する通知を受信できるのみでなく、システム障害のアラートを構成することもできます。そのようにすることを強くお薦めします。システム・アラートを使用すると、システムの問題(コレクタの障害など)に際してすぐにアクションを実行できるだけでなく、外部の深刻な問題(DoS攻撃など)を示すためにも役立ちます。それには、「System」→「Status」→「Status notification」の順に選択します。表示されるダイアログは、7.5.1項「アラート・プロファイル」に示したダイアログに似ています。
基本的に、図15-1に示すインジケータ(1つまたは複数)が警告またはエラーのステータスをレポートするイベントによって、システム・アラートがトリガーされます。たとえば、コレクタ・ステータスのアラートは、コレクタが使用できないかコレクタの障害が発生していることを示します。
重要:
特に次の点に注意することをお薦めします。
構成された受信者には、データベース領域およびディスク領域の使用率の警告とエラーも通知されます(15.4項「データベースおよびディスクの領域制限とアラートの構成」を参照)。
システム・ステータスのアラートでは、アラートのスケジュールやエスカレーション・レベルは考慮されません。アラートを構成するときは、受信者のすべての情報(電子メール・アドレスや電話番号など)を正しく指定してください。また、システム・ステータスのチェックが10分ごとに実行されることにも注意してください。このため、図15-1のページにシステム障害が表示された場合、その障害に関するアラートをすぐには受信せず、スケジュールされたシステム・チェックが実行されたときに受信することがあります。
イベント・ログのアラートの場合、15.7項「イベント・ログの使用」で説明するように、レポートされたイベントを確認することをお薦めします。イベント・ログ・インジケータのステータスを「OK」に戻すためには、イベント・ログの警告またはエラーを読取り済としてマーキングする必要があることに注意してください。
コレクタ・ステータスのアラートの場合、Collector Statisticsウィンドウ(15.2項「コレクタのステータスの表示」を参照)を使用して問題をトラブルシューティングすることをお薦めします。
他のエラーまたは警告の際(あるいはエラーや警告が長く続く場合)は、カスタマ・サポートに連絡してください。
SNMPトラップ通知
KPIおよびSLAの違反のように、SNMPトラップを使用してシステム・イベント通知を送信するように構成できます。この場合、イベント・ログでレポートされる各イベント(15.7項「イベント・ログの使用」を参照)は、独立したSNMPトラップになります。
システム・イベントに対してSNMPトラップを構成する手順は、次のとおりです。
「System」→「Status」→「Status notification」の順に選択します。図7-9に示すようなダイアログが表示されます。
「SNMP」タブをクリックします。図15-4に示すダイアログが表示されます。
「Enabled」および「Event log monitoring」チェック・ボックスが選択されていることを確認してください。そうしないと、システム・イベントに対してSNMPトラップは生成されないことに注意してください。
「Event log sending limit」フィールドを使用して、1分間に送信されるSNMPトラップの最大数を指定します。この機能は、受信側のSNMPマネージャに大量のトラップが過度に送信されるのを防ぐのに役立ちます。たとえば、1分間に500件のイベントがレポートされる場合について考えます。原則として、これらはそれぞれ独立したSNMPトラップになります。ただし、送信制限が100に設定されている場合は、最も深刻な100件のイベントのみがSNMPトラップとして生成されます。
ダイアログにある別のフィールドの使用方法は、7.5.6項「SNMP通知の使用方法」を参照してください。
管理情報ベース(MIB)定義をダウンロードし、管理対象オブジェクトのアドレス帳に取り込みます。この定義には、受信したSNMPメッセージの解釈方法に関して必要な情報が含まれています。
システムが中断しないで運用されるようにするために、使用可能なデータベース領域およびディスク領域の使用率に上限を設定します。データベースの使用率が上限に達すると、管理メカニズムによってデータベースのサイズが許容された境界内に戻るまで、新しいデータが書き込まれなくなります。同様に、ディスク領域使用量が最大レベルに達すると、管理者が既存ファイルの削除処理を行うまで、(ログ形式やエンリッチ・データ交換ファイルの)データはファイル・システムに書き込まれません。さらに、これらのいずれかの問題が発生しそうな場合にアラートを生成するように設定することも可能です。
|
重要: RUEIを熟知していて、これらの設定の用途と効果を明確に理解している場合にのみ、デフォルト設定を変更することを強くお薦めします。 |
データベース領域またはディスク領域のしきい値を定義する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Database/disk space usage」の順に選択します。図15-5に示すしきい値選択パネルが表示されます。
目的のしきい値を選択します。図15-6に示すようなダイアログが表示されます。
アラートのしきい値の場合には、このダイアログを使用してデータベース領域またはディスク領域の最大使用率を指定し、その使用率を超えたらアラートが生成されるようにします。生成されたアラートは同じ受信者に送信され、システム障害アラートに定義した通知メカニズム(15.3項「システム障害アラートの構成」を参照)と同じ通知メカニズムが使用されます。停止のしきい値の場合には、データベース領域またはディスク領域の最大使用率を指定し、その使用率を超えたらデータベース処理またはデータ収集が停止するようにします。次に、「Save」をクリックします。指定した変更は、即座に有効になります。
しきい値の定義
しきい値を定義するときには、次の点に注意してください。
データベース領域またはディスク領域の使用を停止するために指定可能な最大設定は、95%です。これは、使用可能なディスク領域が完全に(100%)いっぱいになった場合、システム上の他のコンポーネントが動作しなくなることがあるためです。また、システムへのリモート・ログオンができなくなる可能性もあります。同様に、データベースが完全にいっぱいになることを許可した場合には、そのサイズを削減するための管理メカニズムが動作できなくなります。
指定したしきい値は、RUEIで使用されるすべてのパーティションに適用されます。つまり、/var/opt/ruei、およびその下にマウントされたすべてのパーティションです。少なくとも1つのパーティションが指定されたしきい値に達すると、アラート・メカニズムおよび停止メカニズムがトリガーされます。
定義されたしきい値のチェックは、絶えず実行されるのではなく、10分ごとに実行されます。したがって、チェックが実行されてアラートが発行されるまでに、データベース領域またはディスク領域の使用率が指定されたしきい値をすでに上回っている場合もあります。そのため、しきい値は、意図したターゲットより少し低く設定することをお薦めします。たとえば、ディスク領域の停止しきい値は95%でなく93%か94%に設定します。
アラート通知しきい値は、関連する停止しきい値より高い値に設定することはできません。たとえば、データベースの停止しきい値が95%の場合には、アラートしきい値をそれより高い値に設定することはできません。
デフォルトでは、アラートしきい値は85%、停止しきい値は95%です。
Linuxオペレーティング・システムでも、ディスク領域使用率の制限は95%です。この制限に達すると、ディスクに書き込めるのはrootユーザーのみとなります。RUEIにはこの権限がないため、ディスク領域をそれ以上使用できなくなります。
監視対象のネットワーク・トラフィックの概要を開くには、「System」→「Status」→「Data processing」の順に選択します。これにより、ヒット、ページ、セッション処理およびシステム・ロードに関する情報が即座に表示されます。例を図15-7に示します。
「Performance」タブの「Available resource usage (%)」項目は、現在の処理レベルを示します。この値が100%に近づくと、データの処理に遅延が発生し始め、データをリアルタイムで処理できなくなります。
この機能はアプリケーション・ロジックに基づいているため、表示されるレポートには非アプリケーション(スイート、サービス、SSOなど)のトラフィックは示されません。
|
重要: RUEIが監視しているトラフィックに関して正確にレポートするには、このトラフィック・サマリーを定期的に確認することをお薦めします。 必要であれば、RUEIの構成を確認して適切なものにしてください。たとえば、他のCookieテクノロジを追加します。また、システムでセッションを追跡できない場合は、ユーザー・フローも適切に追跡できません(ユーザー・フロー・レポートではセッションの追跡が必要になるため)。 |
システムの現在の構成のバックアップを作成したり、必要に応じてそのバックアップをリストアできます。バックアップは定期的に作成することをお薦めします。バックアップにはシステム設定のみが含まれることに注意してください。セキュリティ上の理由により、SSL鍵と収集されたデータは含まれません。
バックアップを作成またはリストアする手順は、次のとおりです。
「System」→「Maintenance」→「Backup and restore」の順に選択します。図15-8に示すダイアログが表示されます。
ラジオ・ボタンを使用して、必要な操作を選択します。次に、「Next」をクリックします。
ブラウザの構成方法によって異なりますが、zipファイルの保存場所の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。
|
重要: 生成されるバックアップ・ファイルには、Oracleサポート・サービス専用の大量の情報が含まれます。このファイルの内容を変更しないでください。リストアを実行するときは、現在のすべての設定がリストアされる設定で上書きされることに注意してください。 |
RUEIでは、15.1項「システムのステータスの監視」で説明されているステータス情報の他に、イベント・ログが保持されます。これには、すべてのシステム・イベントのレコードが含まれます。ユーザーもカスタマ・サポートも、イベント・ログを使用することで、RUEIインストールで発生する可能性のある問題をすぐに特定して解決できます。
イベント・ログの内容を定期的に確認することをお薦めします。イベント・ログに未読のエラー・メッセージが含まれる場合、「Status」パネルの「Event log」項目にエラー・アイコンが表示されます。ほとんどのイベントはすぐにレポートされますが、コレクタ関連のイベントはレポートされるまで最大で5分かかることに注意してください。
イベント・ログを確認する手順は、次のとおりです。
「System」→「Status」→「Event log」の順に選択します。図15-9に示すようなダイアログに最近のイベントが表示されます。
ツールバーのコントロールを使用して、イベントのリストをスクロールします。表示される各ログ・ページには、レポートされるイベントが最大100件まで含まれます。デフォルトでは、すべてのイベント・タイプが表示されます。ただし、「Severity」メニューを使用すると、選択したカテゴリのみに制限してリストを表示できます。イベントの潜在的な影響は、表15-3で説明している重大度によって示されます。
図15-3 イベントの重大度
| 重大度 | 説明 |
|---|---|
|
Info |
ユーザーが開始したアクションを示します。たとえば、コレクタの再起動、新規ユーザー・アカウントの作成、構成のバックアップまたはリストアがあります。 |
|
Warning |
RUEIインストールの障害を引き起こす可能性があるイベントを示します。たとえば、レポータ・システムのディスク領域が不足しかけている、またはログ・ファイルの処理でバックログが増えている場合です。 |
|
Error |
RUEIインストールが完全には作動しなくなるイベントを示します。たとえば、リモート・コレクタが使用できなくなる場合です。 |
また、「Status」メニューを使用すると、レポートされるすべてのイベントを表示したり、新しい(未読)イベントのみに表示リストを制限したりできます。
|
注意: 5分間の期間内に同じイベントが複数回発生した場合は、レポートされるイベント内にリピート・カウンタが表示されます。 |
必要に応じて、「Event」メニューで、表15-4に示すオプションを選択できます。
表示されているイベントをクリックすると、その詳細を表示できます。図15-10に示すようなダイアログが表示されます。
このダイアログでは、完全なイベント・テキストと関連するイベント・コードが表示されます。カスタマ・サポートに問い合せるときには、これら両方を指定する必要があることに注意してください。リモート・コレクタの場合、レポートされるソースはコレクタのIPアドレスです。
RUEIでは、テキスト・メッセージ通知の使用がサポートされています。この機能を使用するには、使用するすべてのテキスト・メッセージ・プロバイダを構成してシステムに認識させる必要があります。プロバイダ情報を管理するには、「System」→「Maintenance」→「Text message providers」の順に選択します。図15-11に示すダイアログが表示されます。
テキスト・メッセージ・プロバイダを構成する手順は、次のとおりです。
「Add new account」をクリックして、新規テキスト・メッセージ・プロバイダを定義します。図15-12に示すダイアログが表示されます。
リストから目的のテキスト・メッセージ・プロバイダを選択します。リストには、サポートされている事前定義済のサービスが多数用意されています。これらの各サービスを使用するには、該当するプロバイダのアカウントが必要です。次に、「Next」をクリックします。図15-13に示すようなダイアログが表示されます。
|
重要: 「Local GSM modem」を指定する場合は、システムにGSMモデムを装着しておく必要があります。装着が必要なローカル・モデムは、USBまたはシリアルGSM ETSI 07.05準拠のモデムです。 |
ダイアログに表示される正確なフィールドは、図15-12で選択したプロバイダによって異なります。たとえば、「Local GSM modem」を選択した場合は、ローカル・ポートとモデムのボー・レートを指定する必要があります。不明な場合は、自動検出を使用できます。オプションで、SIM PINも指定できます(必要な場合)。
事前定義済のMollieまたはClickatellサービスを選択した場合は、アカウントのユーザー名、パスワード、作成者、API IDおよびプロトコル送信メソッドを指定する必要があります。これらの情報は、アカウント・プロバイダによって提供されます。次に、「Save」をクリックします。図15-11に示すダイアログ・ボックスに戻ります。
リストでプロバイダを右クリックし、「Move up」および「Move down」オプションを使用してリスト内のプロバイダの位置を制御します。プロバイダは、リストでの順序どおりに試行されます。つまり、最初のアカウントが試行され、それが失敗すると2番目のアカウントが試行されます(それ以降についても同様)。
次に、「Close」をクリックしてダイアログを閉じます。
テキスト・メッセージではUnicodeがサポートされていますが、多数の制限事項があることを認識しておく必要があります。ローカルに装着したモデムの場合では、7ビットGSM 3.38アルファベットを使用してメッセージが送信されます。サポートされていない文字が元のメッセージに含まれる場合は、疑問符(?)文字に置換されます。外部サービス・プロバイダの場合は、マルチバイト・キャラクタ・セットのサポートに関してサービス・プロバイダに問い合せることをお薦めします。ローカルに装着したモデムと外部サービス・プロバイダの両方で、テキスト・メッセージは160文字に制限されます。
RUEIの使用または操作で問題が発生した場合、Oracleサポート・サービスに問い合せることができます。ただし、その前に、ご使用のシステムのヘルプデスク・レポート・ファイルを作成することを強くお薦めします。これを実行するには、「System」→「Configuration」→「Helpdesk report」の順に選択します。ファイルのダウンロード先となる場所を指定するように求められます。
ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。
このファイルにはソフトウェアの所有権情報が含まれていることに注意してください。そのコンテンツは変更しないでください。
2.3項「メーリング機能の使用方法」で説明しているように、RUEIでは要求されたレポートの自動電子メールを送信できます。この機能では、初期構成フェーズ(『Oracle Real User Experience Insightインストレーション・ガイド』を参照)で指定した情報を利用します。ただし、「System」→「Maintenance」→「E-mail setup」の順に選択して、この構成を変更できます。図15-14に示すダイアログが表示されます。
表15-5 「E-mail Setup」のフィールド
| フィールド | 説明 |
|---|---|
|
Return address |
失敗した電子メールまたは問題が発生した電子メールのレポート先となる電子メール・アドレスを指定します。このアドレスを定期的にチェックすることを強くお薦めします。 |
|
From address |
受信者のメール・クライアントに表示されるアドレスを指定します。 |
|
Reply-to address |
ユーザーが電子メール内でクリックして返信できるアドレスを指定します。これが指定されていない場合は、「From address」設定が使用されます。 |
|
Mail size limit |
電子メールの最大許容メッセージ・サイズ(KB単位)を指定します。電子メールにこの制限を超えるレポートが含まれる場合は、この制限に対応するために、レポートが個別の電子メールに分割されます。個別に送信するには大きすぎるレポートは送信されず、ユーザーに問題が通知されます。デフォルトのメール・サイズ制限は5000KBです。 |
|
Reporter URL |
電子メールの受信者がレポータ・システムに接続するために必要となる詳細なURLを指定します。通常、このURLは、RUEIユーザーがレポータ・システムにアクセスするために使用するURLと同じです。 |
原因不明の問題が発生した場合は、処理が適切に動作して同期化されるように、処理をリセットできます。ただし、このオプションを選択すると、データの可用性と監視に一時的な遅延が発生します。
最後の手段として、収集されたすべてのデータをシステムから削除できます。また、すべてのパラメータ(作成されたユーザーや環境パラメータなど)をデフォルト値にリセットできます。
システムをリセットする手順は、次のとおりです。
「System」→「Maintenance」→「System reset」の順に選択します。図15-15に示すダイアログが表示されます。
目的のオプションを選択します。これらは表15-6で説明しています。
表15-6 「System reset」のオプション
| オプション | 説明 |
|---|---|
|
Reapply latest configuration |
すべての構成変更( |
|
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ユーザー・パスワードの定義)行うことが必要になります。以前にバックアップを作成している場合(15.6項「構成バックアップの作成とリストア」を参照)は、初期構成後にそのバックアップをリストアできます。この初期構成の手順は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。 |
