| Oracle® Real User Experience Insightインストレーション・ガイド 13.3.1.0 for Linux x86-64 E98309-03 |
|
 前 |
 次 |
Webアプリケーションおよびサービスの利用は増え続けています。 これには、マーケティング手段としてのインターネットの利用だけでなく、エクストラネットベースのサプライ・チェーンやバックオフィス統合、内部アプリケーションのイントラネット・デプロイも含まれます。 また、明確に定義されたビジネス機能を実装するwebサービスの使用率が含まれています。 アプリケーションはモバイル・デバイスからアクセスでき、また、on-premises、SaaS、hybridを含む多数のクラウド・ベース・デプロイメント・オプションがあります。 RUEIは、すべてのデプロイメント・シナリオの可用性およびパフォーマンスの測定、分析および向上のために設計されています。 これを実現するために、RUEIでは、Javascriptブラウザ・インストゥルメンテーションを使用して、ネットワーク・トラフィック、ADFサーバーおよびデータ収集からデータ収集を実行できます。
RUEIの使用に関する視覚的なデモンストレーションを表示するには、次のURLに移動し、ビデオの開始をクリックします:
https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5783,1図1-1は(以前のRUEIリリースで使用可能な)ネットワーク・データ・コレクタを示し、図1-2はタグ・データ・コレクタを示しています(このオプションを使用すると、JavaScriptを使用してデータを収集でき、ネットワーク監視の必要はありません)。
表1-1に、RUEIで使用可能な様々なデータ収集の概要を示します。
表1-1 データ収集方法
| ネットワーク | タグ | |
|---|---|---|
概要 |
このオプションは、ネットワークを通過するデータを収集するもので、以前のリリースでのデフォルト・オプションでした(ローカルまたはリモートのコレクタが必要です)。 すべてのネットワーク・トラフィックが無差別モードで監視されます。 |
このオプションは、タグ・ベースの監視とも呼ばれ、リクエストを監視して、すべてのページに挿入される特定のWeb URL (タグ)を処理することによりデータを収集します(ローカルまたはリモートのコレクタが必要です)。 ローカルIPアドレスに関連するトラフィックのみが監視されます。 |
アプリケーション |
アプリケーションを定義する必要があります。 ユーザーズ・ガイドのWebページの識別とレポート作成を参照してください。 |
OnLoadオブジェクトを定義し、生成されたJavaScriptをアプリケーションで使用する必要があります。 詳細は、「Real User Experience Insightユーザーズ・ガイド」の「Webページの識別とレポート作成」を参照してください。 |
スイート |
スイートを定義する必要があります。 ユーザーズ・ガイドのスイートおよびWebサービスの使用を参照してください。 |
タグ・ベースのデータ収集を使用して監視できるのは、WebCenter Sitesのみです。 詳細は、「Real User Experience Insightユーザーズ・ガイド」の「スイートおよびWebサービスの使用」を参照してください。 |
関連情報 |
||
ADFモニタリング |
ADFベースのアプリケーションの監視には、ADF監視サービスを含む様々なデータ収集オプションを使用できます。 このサービスを使用すると、ネットワーク・データ収集によるデータよりも多い、アプリケーション・サーバーからADFベースのアプリケーションのデータ(ユーザー名など)が収集されます。 詳細は、「ADFモニタリング用のRUEIの構成」を参照してください。 |
|
オプションについては、「ソフトウェア・インストールの計画」で詳しく説明します。
ネットワーク・データ収集方法は、ネットワーク・プロトコル分析(NPA)テクノロジに基づいています。 この方法は100%非侵入的です。 したがって、Webサーバーには負荷はかからず、パフォーマンスに影響を与えるソフトウェア・エージェントをインストールする必要もありません。 さらに、現行のアプリケーションまたはインフラストラクチャに変更を加える必要もありません。 アプリケーションの新リリースがデプロイされた場合、またはWebサーバーが増設された場合にも、RUEIの監視環境に対する変更はまったく、またはほとんど必要ありません。 通常、RUEIはWebサーバーの前、DMZ内のファイアウォールの後ろにインストールされます(図1-3)。
ビジターがオブジェクトをリクエストすると、RUEIではそのリクエストを確認し、リクエストされたオブジェクトをビジターに示すまでにWebサーバーで要する時間を測定します。 この時点で、RUEIは、ページをリクエストしたユーザー(クライアントのIP)、リクエストされたオブジェクト、オブジェクトのリクエスト元のサーバー(サーバーのIP)を知ることができます。
webサーバーが応答し、リクエストされたオブジェクトをビジターに送信します。 RUEIでは、サーバーからのレスポンスがあるかどうか、そのレスポンスが正しいかどうか、リクエストされたオブジェクトの生成にwebサーバーで要する時間、およびオブジェクトのサイズを確認できます。 また、RUEIでは、ビジターがオブジェクトを完全に受信したかどうか、またはビジターがダウンロードを中断したかどうか(つまり配信証明)も把握できます。 RUEIでは、オブジェクトがインターネットからビジターに渡るまでの時間を測定し、ビジターとサーバー間の出力(ビジターの接続速度)を計算できます。
RUEIは、図1-4に示すように、3つのレイヤーからなる製品アーキテクチャに基づいています。
図1-4 RUEIの製品アーキテクチャ
監視対象のパケットは、表1-2に示すレイヤーによって処理されます。
表1-2 製品アーキテクチャ・レイヤー
| レイヤー | 説明 |
|---|---|
データ収集 |
このレイヤーは、RAWデータの取得とデータ・プロセッサ・レイヤーへの配信を担当します。 このデータは、複数のソースから収集できます。 使用可能な接続オプションについては、この項で後述します。 |
データ処理 |
このレイヤーでは、RAWデータがOLAPデータ・セットに変換されます。 これは多次元データ構造を構成し、データ・ブラウザで表示できます。 |
データ・プレゼンテーション(レポータ) |
このレイヤーは、RUEIの分析およびレポート作成環境です。 これは、Webベースの情報ポータルで、サポートされている任意のブラウザからアクセスできます。 |
これらのレイヤーはそれぞれ、同じシステムにデプロイすることも、スケーラビリティの問題の場合は別々のシステムにデプロイすることもできます。
HTTP(S)データ・ストリームを読み取るために、専用のソフトウェア・モジュールでTCP/IPパケット・ストリームを再アセンブルします。 ネットワーク・データ・コレクタにIP番号が割り当てられていないことと、これらのデータ・コレクタを使用するソフトウェアに機能的なIPスタックがないことから、RUEIはデータ・コレクタで受信された受信トラフィックに応答できません。 これにより、RUEIは監視対象のネットワークから見えなくなり、完全にセキュアになります。
注意:
RUEIでは非侵入的な方法でデータを収集するため、測定ポートでエラーが発生しても、再転送のリクエストはできません。
データ収集は、暗号化データを記録するように構成できます。 これを容易にするには、WebサーバーのプライベートSSLキーのコピーをデータ・コレクタに設定する必要があります。 また、RUEIを構成して、フォームまたはコンテンツのPOSTリクエストの引数の機密データのロギングを省略できます(データ・マスキング(またはブラインド)と呼ばれます)。
RUEIでは、ネットワーク・トラフィックのモニタリング用にポート「脚注1」とTAP 「脚注2」の両方を使用できます(10/100 Mbpsおよび1/10 Gbps Ethernet接続がサポートされています)。 コピー・ポートとTAPは、銅回線またはファイバ・ベースのネットワーク・インフラストラクチャで使用できます。 どちらのデバイスでもネットワーク・トラフィックを大量にモニタリングできませんが、これら2つの接続のオプションには違いがあります。
SSLトラフィックおよびFormsトラフィックの監視
注意:
SSLトラフィックおよびOracle Formsトラフィックは、TCPパケット・ストリームでの混乱を特に受けます。 これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。
したがって、各コレクタがTAPなどの信頼できるネットワーク・デバイスに接続されていることを確認する必要があります。 また、コレクタ統計ウィンドウ(各コレクタ・ノードには「システム」→「ステータス」→「コレクタ統計」を選択)から入手できる情報を定期的に調べて、TCPパケット・ストリームが完全な状態であることを確認することをお薦めします。 レポートされたTCPおよびSSL接続エラーを確認します。 また、コレクタ・ソフトウェアは物理ネットワーク・インタフェースに直接アクセスする必要があり、複数のサーバーが1つの物理ネットワーク・インタフェースを共有する構成(特定のブレード・サーバー・タイプなど)が確実に動作しない構成でもあります。 構成に関連するすべての問合せについては、ハードウェア・ベンダーに問い合せてください。
コピー・ポートは、スイッチが受信するソースMACアドレスに基づいて、レイヤー2転送表を構築するスイッチです。 転送表が構築されると、MACアドレスに対して破棄されたトラフィックが対応するポートに直接転送されます。
たとえば、図1-5のWebサーバーMACが確認されると、ブラウザからWebサーバーへのユニキャスト通信は、Webサーバー・ポートにのみ転送されます。 したがって、コレクタではこの通信は確認されません。
図1-5 コピー・ポートを使用したネットワーク接続
図1-5の下の部分に示した構成では、コレクタはブラウザが送信するすべてのパケットのコピーを受信するように構成されているポートに接続されています。 このポートをコピー・ポートと呼びます。 ポートをコピーすると、任意のデータ・ポートまたはすべてのデータ・ポートから単一の未使用ポートにトラフィックをコピーし、ポート上の双方向トラフィックがネットワークへのバック・フローまたはトラフィックから保護されるのを防ぐことができます。
スイッチ上のコピー・ポートをアクティブにすると、パフォーマンスに影響を与える可能性があります。 通常、コピー・ポートでは、様々な構成オプションがサポートされます。 これらのオプションの詳細は、スイッチのドキュメントを参照するか、ベンダーに問い合せてください。
TAPは、任意の2つのネットワーク・デバイス(ルータやファイアウォールなど)の間に配置できます。 TAPに接続されたすべての監視デバイスは、すべてのエラーも含めて、インラインであるかのように同じ通信を受信します。 これは、TAPでリンク上のすべての通信を複製し、それを監視ポートに転送することにより実現します。 図1-6の例は、1つのコレクタに対する典型的なTAPのデプロイを示しています。
重要
コピー・ポートと異なり、TAPでは停電の場合にも、引き続きネットワーク・デバイス間でデータが流れます。 負荷が高い間は、コピー・ポートがパケットの損失につながる可能性があります。 TAPデバイスは、銅回線またはファイバ・ベースのインフラストラクチャに使用できます。 さらに、必要な時と場所に簡単にデプロイでき、しかもスイッチの再構成や、ネットワーク・リンクのケーブル再配線に必要なエンジニアも必要ありません。 これらの理由で、コピー・ポートよりもTAPの使用を強くお薦めします。
概して、TAPには、ネットワークTAP、再生成TAPおよび集約TAPの3タイプがあります。 RUEIでは、ネットワークTAPと再生成TAPの使用がサポートされています。 パケット・ストリーム内でパケットの順序が維持されている場合にのみ集約TAPはサポートされています。 モニター・ポートが飽和状態になり、パケット損失と不正確なタイミング情報が正確になる場合、集約タップの使用時にレポートの精度に影響することがあります。 ネットワークTAPでデータを取得する場合、カスケード式のTAP構成の使用はサポートされていません。
RUEIでは、各ネットワーク・セグメントにタップをデプロイして集中的なコレクタに接続するか、監視対象の各セグメントに1つずつ複数のコレクタをデプロイすることで、複数のネットワークからのデータを監視および処理できます。 詳細は、「スケーリング・シナリオ」を参照してください。
RUEIシステムは、レポータまたはコレクタ・オプションのいずれかを使用してインストールできます。 これらの各インストール・オプションについては、この後の項で説明します。
レポータ
レポータ・システムは、接続されたコレクタによって収集されるデータを処理します。 処理後に、このデータがレポータ・データベースと呼ばれるOracleデータベースに格納されます。 システム・ユーザーは、ブラウザベースのインタフェースを通して収集されたデータを確認できます。
RUEIでネットワーク・トラフィックを正確に監視してその結果をレポートするには、ネットワークおよびアプリケーション・インフラストラクチャに関する特定の情報が必要です。 これには、ページ、サービス関数コールおよびエンド・ユーザーの識別方法、ネットワーク環境での監視範囲、特定のKPIおよびSLAの監視、システム・ユーザーに割り当てられるロールおよび権限が含まれます。 この情報は、個別の構成データベースに保持されます。
Collector
コレクタは、データを収集し、そのデータをレポータに送信します。 複数のコレクタを同じレポータに接続することができます。 コレクタ・システムとレポータ・システムの間には直接接続が必要です。 コレクタは、「ソフトウェア・インストールの計画」で説明するように、ネットワーク・ベースまたはタグ・ベースにすることができます。
また、各レポータのインストールには、ローカル・コレクタ・インスタンスも含まれます。 レポータを構成して、このローカルのコレクタで収集される情報を処理したり、追加のコレクタから情報を受信できます。 また、レポータ・システムのローカル・コレクタ・インスタンスも、必要でない場合は無効にできます。
レポータ・システムで使用可能なデータは、レポータ・データベースと呼ばれるOracleデータベースに格納されます。 監視対象のアプリケーションおよびシステム・ユーザーの情報など、Webインフラストラクチャで正しく監視およびレポートするためにRUEIで必要な情報は、データベースの個別の構成部分に保持されます。 データベースは、ローカルのレポータ・システムに置くことも、リモート・データベース・サーバー(データベース・クラスタなど)に置くこともできます。
リモート・データベース・サーバーを使用すると、ローカルにインストールされたデータベースより潜在的に多くの利点があります。 特に、既存のセキュリティおよびバックアップのポリシーと統合しやすく、さらに専用サーバーの使用によりパフォーマンスが向上します。
現在、RUEIではOracle 11gおよび12cリリース1のデータベース・インストールがサポートされています。 Oracle 10g(または古い)データベースはサポートされていません。
この項では、使用できる様々なデプロイメント・シナリオに焦点を当てます。 最適なデプロイメント・シナリオの選択は、監視されるネットワーク・トラフィックのレベル、レポート要件およびデプロイメント・システムのハードウェア仕様によって主に決定されます。
単一サーバーのデプロイメント
これは最も単純なデプロイメントで、トラフィックが小または中程度のレベルのWeb環境の監視に適しています。 図1-7に例を示します。
このデプロイメントでは、1つのシステムがコレクタとレポータの両方として機能します。 前述の項のように、レポータ・データベースをレポータ・システムまたはリモート・データベース・サーバーにローカルに置くことができます。
複数のサーバーのデプロイメント
通信量が非常に高いレベルを監視する必要がある場合、複数のサーバーを使用することが考慮されます。 さらに、このデプロイにより、セキュリティが強化される可能性もあります。 たとえば、コレクタをオフィス・ネットワーク外に配置する一方で、レポータ・システムをネットワーク内に配置する方法です。 図1-8は、複数のコレクタのデプロイメントの例を示しています。
両方のデータ回線が同じレポート環境で監視されるデプロイメントを説明しています。 このデプロイメントでは、各行のトラフィックが相互に排他的であることを前提としています。 セキュリティ上の理由で使用されるデプロイメントも示しています。 WebサーバーAおよびBからの通信が監視され、レポートが作成されるのに対し、WebサーバーCからの通信は監視もレポート作成も行われません。 これは、コレクタがスイッチの上に配置されていない理由でもあります。 レポータ・システムのコレクタ・インスタンス(1)は無効化されています。
セキュリティ上の理由から、レポータ・システムに対するアクセスは、信頼できるIPの範囲に制限することをお薦めします。 同様に、レポータ・システムを内部ネットワークに配置して、セキュリティを最大限にすることができます。 コレクタのデータ収集ポートはDMZ内に置く必要があります。
データベースに保持されるアプリケーションおよびインフラストラクチャ構成情報は、ブラウザベースのインタフェースを通してシステム・ユーザーが提供する情報に基づいて、レポータによって維持されます。 各コレクタは、この情報を使用して、収集されるデータのレポート方法を決定します。
選択した構成(インストール・オプションで説明)に必要な最低限のシステム仕様については、この後の項で説明しています。
ネットワーク・カード
インフラストラクチャ用のネットワーク・カードの選択は、慎重に検討することをお薦めします。 「ネットワーク・データ収集の接続オプション」で選択した接続オプションに応じて、銅とファイバ・ベースの両方のネットワーク・カードが必要になる場合があります。 必要に応じて、ネットワークおよびシステムの両方の管理チームに相談してください。
結合グループ内のネットワーク・カード
結合されたグループの一部であるネットワーク・カードを使用したネットワーク・トラフィックのモニタリングはサポートされていません。
注意:
必須および推奨のシステム仕様の詳細は、Oracleサポート・サービスにお問い合せください。
表1-3 単一サーバー・システムの最低要件
| 要素 | 要件 |
|---|---|
CPU |
64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。 |
メモリー |
16 GB |
ディスク領域 |
|
ネットワーク・インタフェース |
ネットワークTapデバイス「脚注6」を使用する場合は、3つ以上のネットワーク・インタフェースが必要です:
|
GSMモデム(オプション) |
テキスト・メッセージを送信するためのGSMモデムのオプション・サポート。 モデムはGSM07.05またはGSM07.07互換であることが必要です。 シリアル・ポートまたはUSBポートを介して接続できます。 USBが使用されている場合、RUEIは使用可能な最初のポート( |
脚注 3
RUEIインストールで許容できるパフォーマンスを確保するには、サポートされているI/Oレートで70 MB/秒を最小限に抑えて、高パフォーマンスのディスク・システムを使用することをお薦めします。 大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。 (ハードウェア)RAID-10または同等の記憶域構成を強くお薦めします。
脚注 4
エンリッチ・データ交換が有効になっている場合は、これを増やす必要がある場合があります。
脚注 5
ローカル・データに対するNFSシェア(つまり、$RUEI_DATA、$RUEI_HOME)の使用はサポートされていません。 この制限は、$RUEI_DATA /processor/dataおよび$RUEI_DATA /collector/wg/REPLAYには適用されません。
脚注 6
ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成の使用はサポートされません。
表1-4 レポータ・システムの最低要件
| 要素 | 要件 |
|---|---|
CPU |
64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。 |
メモリー |
16 GB |
ディスク領域 |
|
ネットワーク・インタフェース |
1つ以上のネットワーク・インタフェースが必要。 |
GSMモデム(オプション) |
テキスト・メッセージを送信するためのGSMモデムのオプション・サポート。 モデムはGSM07.05またはGSM07.07互換であることが必要です。 シリアル・ポートまたはUSBポートを介して接続できます。 USBが使用されている場合、RUEIは使用可能な最初のポート(ttyUSB0)を使用します。 テキスト・メッセージ送信の代替方法を使用できます(http/e-mail)。 |
脚注 7
RUEIインストールで許容できるパフォーマンスを確保するには、サポートされているI/Oレートで70 MB/秒を最小限に抑えて、高パフォーマンスのディスク・システムを使用することをお薦めします。 大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。 (ハードウェア)RAID-10または同等の記憶域構成を強くお薦めします。
脚注 8
エンリッチ・データ交換が有効になっている場合は、これを増やす必要がある場合があります。
脚注 9
ローカル・データに対するNFSシェア(つまり、$RUEI_DATA、$RUEI_HOME)の使用はサポートされていません。 この制限は、$RUEI_DATA /processor/dataおよび$RUEI_DATA /collector/wg/REPLAYには適用されません。
コレクタ・システムの要件を表1-5に示します。
表1-5 コレクタ・システムの最低要件
| 要素 | 要件 |
|---|---|
CPU |
64ビットIntelまたはAMDデュアルコア・プロセッサまたは同等のもの。 |
メモリー |
8 GB |
ディスク領域 |
最小200 GB HDD空き領域「脚注10」。 |
ネットワーク・インタフェース |
ネットワークTAP 「脚注11」デバイスを使用する場合は、3つ以上のネットワーク・インタフェースが必要です:
ネットワーク・コピー・ポートを使用する場合、2つ以上のネットワーク・インタフェースが必要。
|
脚注 10
ローカル・データに対するNFSシェア(つまり、$RUEI_DATA、$RUEI_HOME)の使用はサポートされていません。 この制限は、$RUEI_DATA /processor/dataおよび$RUEI_DATA /collector/wg/REPLAYには適用されません。
脚注 11
ネットワークTapデバイスでデータを取得すると、カスケードTAPs構成を使用できなくなります。
脚注 12
ストリーム間のトラフィックのアップグレードと停止。 1行にストリームのトラフィック(つまり、リンクアグリゲーションTAPs)を統合するTAPsの使用は推奨されません。
この項では、RUEIのデプロイメントを最適化するベスト・プラクティス・フレームワークを紹介します。 次の情報を注意深く再検討することをお薦めします。
デプロイメントの計画
RUEIデプロイメント計画を決定する前に、監視対象のネットワーク環境の性質を明確に理解することが重要です。 これには、基本的なネットワーク接続性、ポート、アドレス指定および物理デバイス要件だけではなく、監視対象のアプリケーションのしっかりした理解も含まれます。
さらに、RUEIをデプロイする前に、ネットワーク内の基本的な通信フローが確認されている必要があります。 これには、トラフィックの平均ボリュームとピーク・ボリュームに関する情報を含める必要があります。 物理的なデプロイメント要件(領域制限、距離、電源計画、ラック領域とレイアウト、または配線など)をすべて特定する必要があります。
「インストール・チェックリスト」に提示されたチェックリストを使用して、情報を取得できます。
Formsベースの通信
フォームベースのトラフィックを監視する場合、メモリー要件は「サーバー要件」で説明されているものよりも高い場合があります。 この場合は、分割サーバーのデプロイを検討する必要があります。
フル・セッション・リプレイ機能
フル・セッション・リプレイ(FSR)機能を使用する予定がある場合は、追加の記憶域容量を構成する必要があります。 これについては、フル・セッション・リプレイの記憶域要件で説明しています。
暗号化通信
監視対象のトラフィックの大レベルを暗号化すると、CPUオーバーヘッドが増加する可能性があります。 この場合、CPUの追加または分割サーバー・デプロイの構成を検討することをお薦めします。
大量の通信
非常に多い量の(つまり、1日当たりのページ・ビューが1000万件を超える)通信を監視している場合、分割サーバー・デプロイを検討することを強くお薦めします。 または、リモート・データベース・サーバーの使用を検討してください。 後者には、レポート・システム上のCPUオーバーヘッドを大幅に(最大30%)減らす効果があります。 監視対象環境の1日当たりのページ・ビューが2000万件を超える場合、分割サーバー・デプロイとリモート・データベース・サーバーの両方の使用を検討する必要があります。
データ・ブラウザ内に特定データとそのデータに基づくレポートを表示できるかどうかは、コレクタ・システムおよびレポータ・システムで使用可能なディスク領域の量、およびレポータ・システムで使用可能なデータベース領域の量によって異なります。
監視中に収集されたデータは、まず、コレクタ・システムに格納されているログ・ファイルに書き込まれます。 これらのファイルは、データ・ブラウザおよびレポートで表示できる多ディメンション・データ構造を保持するデータベースに、レポータがコピーして処理します。 これらの一時ログ・ファイルは、3日後にはコレクタ・システムから自動的に削除され、レポータ・システムからは7日後に削除されます(デフォルト)。
レポータ・システムのデータベース・ユーザー割当て制限のサイズは、インストール中に設定されます。 デフォルトでは500GBに設定されます。 レポータ定義の保存ポリシーで必要なくなるとデータが統合されることを理解しておく必要があります。 たとえば、デフォルトでは直前の32日間について日単位の情報が保持されます。 これより古い日単位の情報は月単位の情報に統合されます。 同様に、月単位の情報は年単位の情報に統合されます。
RUEIではデータは複数の集計レベルで保持され、その保存は日単位で構成されます。 次に、様々な集計レベルとそのデフォルト値について説明します。
インスタンス: 8日
5分: 15日
毎時: 32日
日次: 90日
月次: 60か月
これらの数値はデータのカテゴリ(アプリケーション、スイート、サービス、SLA)ごと、および個別のタイプ(たとえば、すべてのページ、失敗したページ)ごとに微調整できます。 エンリッチ・データ交換のデフォルト値はタイプごとに8日です。
DB領域は期間ごとに約5GBです。 これは、トラフィックの負荷および多様性に大きく依存します。 特に最初の月はレポータ・データ保存画面を時々チェックし、十分なディスク領域が使用可能であることを確認する必要があります。
統計データはCLIから構成できます。 ただし、統計保存は構成できません。ユーザー・フローの完了およびFusion製品保存は、コマンドラインからのみ構成できます。
データ保存設定の最小値および最大値は自動的に決定されます。 それほど詳細ではない集計レベルには、少なくとも、より詳細なレベルと同じ程度の保存が必要です。
新しいインストール済RUEIは、最初の32日間に最も急成長を遂げます。 増加率は遅くなります。 増加率は、監視対象のトラフィック・レベルによって異なります。
フル・セッション・リプレイ(FSR)機能を使用する場合、コレクタ・システムで使用可能な記憶容量の追加が必要になる可能性があります。 これは、コレクタ・サーバーの既存のハード・ドライブのパーティションではなく、別のデバイスにし、RUEIファイル・システムにアクセスできるようにする必要があります。 この項の後半では、記憶域要件の手順およびガイダンスについて説明します。 この手順は、フル・セッション・リプレイ情報が必要なコレクタごとに繰り返す必要があります。
フル・セッション・リプレイ用追加記憶域の構成
この後説明する手順は、完全に機能しているシステムがあり、FSRが有効になっていることを前提としています。 追加の必須記憶域を構成するには、次のようにします。
デバイスをマウントします。 たとえば、/mnt/external_storageの下にマウントします。
次のコマンドを実行して一時的にコレクタを停止します:
appsensor stop wg
$APPSENSOR_HOME/wg/REPLAYディレクトリを新しいデバイスに移動します。 上の例では、これは/mnt/external_storageで、その結果、リプレイ・ファイルは/mnt/external_storage/REPLAYディレクトリに置かれるようになります。
/mnt/external_storage/REPLAYから$APPSENSOR_HOME/wg/REPLAYへのシンボリック・リンクを作成します。
次のコマンドを実行してコレクタを再起動します:
appsensor start wg
必須記憶域容量を計算します。 これを行うには、日次ページ・ビューの平均数を平均ページ・サイズで掛けます。 次に、この数にフル・セッション・リプレイ・データの希望保存日数を掛けます。 表1-6を指標として使用してください。
表1-6 フル・セッション・リプレイ記憶域の推定値
| データ量が小さいページ(10KBまで) | データ量が中程度のページ(50KBまで) | データ量が大きいページ(100KBまで) | ||||
|---|---|---|---|---|---|---|
1日当たりのページ・ビュー数(100万単位) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
0.5 |
5 |
0.1 |
25 |
0.3 |
50 |
0.6 |
2 |
20 |
0.2 |
100 |
1.2 |
200 |
2.3 |
5 |
50 |
0.6 |
250 |
2.9 |
500 |
5.8 |
10 |
100 |
1.2 |
500 |
5.8 |
1000 |
11.6 |
20 |
200 |
2.3 |
1000 |
11.6 |
2000 |
23.1 |
50 |
500 |
5.8 |
2500 |
28.9 |
5000 |
57.9 |
注意:
表1-6は、単なる指標です。 平均のページ・サイズおよび1日のページ・ビュー数を定期的に調べ、必要に応じて必須記憶域サイズを調整することを強くお薦めします。
注意:
FSR機能では、多数の非順次読込み操作が使用されることに注意してください。 I/Oパフォーマンスを最適化する方法の情報は、ハードウェアのベンダーにお問合せください。
「構成」 > 「一般」 > 「詳細設定」、「コレクタのデータ保持ポリシー」の順に選択します。 フル・セッション・リプレイ記憶域のサイズ(GB)設定をクリックします。 必須記憶域のサイズを指定(GB単位)します。 指定できる最大値は、100 TBです。 次に、保存をクリックします。
次のGNU/Linuxディストリビューションがサポートされています。
Oracle Linux
Oracle Linux 6:バージョン6.5から、64-bit、IntelとAMDの両方の互換性。
Oracle Linux 7、64-bit、IntelとAMDの両方の互換性。
RedHat Enterprise Linux
RedHat Enterprise Linux 6:バージョン6.5以降、64-bit、IntelとAMDの互換性。
RedHat Enterprise Linux 7、64-bit、IntelとAMDの両方の互換性。
次のデータベース・バージョンがサポートされています。
11gリリース2
12cリリース1
RUEIで必要な最小Oracle Databaseリリースは、11gリリース2です。 RUEI 13.3.1.0の最高のパフォーマンスは、Oracle Database 12cリリース1で達成されます。
機密データの暗号化
機密データの暗号化が必要な場合、Linuxのインストール手順におけるディスク・パーティションの段階で、ディスク構成全体を暗号化する機会があります。
すべてのサーバー・システムのクロックは、UDPポート123を使用してNTPを使用して同期化する必要があります。
TCPおよびUDPポート53でのDNS情報リクエストのサポート。
TCPポート25を使用したレポートおよび電子メール・アラートのサポート。
UDPポート161/162を使用したSNMPマネージャからのリクエストでのSNMPトラップのサポート。
RUEIユーザー・インタフェースが、HTTPSポート443を通じてアクセス可能であること。
リモート・データベース設定の場合、レポータとリモート・データベース・サーバー間でTCPポート1521へのアクセスが必要。
各リモート・コレクタ・システムに、TCPポート22を介してレポータ・システムでアクセスできなければなりません。 他のすべてのポートはブロックすることをお薦めします。
フェイルオーバー・レポータ・システムを構成する場合は(「フェイルオーバー・レポータ・システムの構成」で説明)、プライマリおよびセカンダリ・レポータ・システムがICMPを使用して相互通信可能である必要があります。
フェイルオーバー・コレクタ・システムを構成する場合は(「フェイルオーバー・コレクタ・システムの構成」で説明)、プライマリおよびセカンダリ・コレクタ・システムがICMPを使用して相互通信可能でなければなりません。
コレクタ-レポート・バンド
リモート・コレクタとレポータ・システム間で転送されるデータ量は、主としてRUEIによって監視されるネットワーク・アプリケーション通信のタイプやレベルによって決まります。 さらに、RUEIの構成(定義済の機能エラー、コンテンツ・チェック、ページ命名スキームなど)も、レポータ・システムに転送する必要のあるコレクタ・ファイルのサイズに影響を与えます。
ピーク時には、転送が必要なデータの量は、通信量の少ない期間より多くなります。 リモート・コレクタからレポータ・システムへの正確なデータ転送量は、実際のRUEIデプロイメント後のみ決定できます。
初期のデプロイには、次の簡単なルールを使用できます。1日のページ・ビュー500万件ごとに、ピーク時のピーク転送量は約125MB、1日当たり約1GBになります。 したがって、通常、コレクタによって格納され、レポータに転送される通信は、実際に監視される通信の数パーセントにすぎません。 このデータ転送量を最小限に抑える必要がある場合、RUEIで必要のない監視対象HTTP通信の量を最小限に抑えることをお薦めします。 たとえば、サブネットまたはVLANフィルタ設定ネットワークを使用します。
RUEIユーザー・インタフェースにアクセスするワークステーションには、次のいずれかのブラウザがインストールされている必要があります。
Mozilla Firefox 3.6(以上)。
Internet Explorer 7、8または9。
Safari 4および5。
Google Chrome 17(以上)。
JavaScriptを有効にする必要があります。 その他に必要なブラウザ・プラグインはありません。
また、ワークステーションの画面解像度は、1024×768(以上)が必要です。
注意:
ブラウザ内のポップアップ・ブロッカが無効になっていることを確認してください。
AJAXサポート
RUEIではAJAXを使用して、ユーザーとの対話を強化します。 Internet Explorerでは、MSXML制御を利用してAJAXの操作を容易にします。 AJAXに依存すると、厳格なセキュリティ設定を使用している場合に、セキュリティの警告が発せられる可能性があります。
脚注の凡例
脚注 1:コピー・ポートは、Ciscoスイッチの機能であるスイッチ・ド・ポート・アナライザ(SPAN)ポートとしても知られています。
テスト・アクセス・ポート(TAP)デバイスは、NetOptics Inc.などの担当者ベンダーによって提供されます。
