| Oracle® Real User Experience Insightユーザーズ・ガイド 13.3.1.0 for Linux x86-64 E98302-02 |
|
 前 |
 次 |
管理者は、システム条件を確認し、「ステータス」ページでステータス・モニタリング・メッセージを自動的に受信できます。 このページにアクセスするには、システム→ステータスを選択します。 例を図15-1に示します。
図15-1 ステータスウィンドウ
ステータス・ページでは、接続されているコレクタのステータス、ログ・ファイル処理、システムにおける現在の処理レベル、レポータおよび処理エンジンのデータベース表領域に十分な領域があるかどうか、およびイベント・ログを確認できます。 また、システム・ステータス・エラーが発生した場合に通知を受け取るユーザー(およびその方法)も構成できます。
コンポーネントの失敗の概要
図15-1に示す各コンポーネントは、現在のステータスを示しています。 通常の運用では、これはOKとレポートされます。 ただし、1つ以上のコンポーネントでErrorとレポートされる場合は、表15-1の情報を使用して、問題の特定と解決を行ってください。 この表の各エントリをクリックすると、追加の詳細を表示できます
表15-1 レポートされたエラーの原因
| コンポーネント | 考えられる原因 |
|---|---|
コレクタとレポータ間の接続 |
このコレクタには、ネットワーク認証や |
Local Databaseを使用した接続 |
このプロセッサには、ローカル・データ・データベースへの接続に関する問題があります。 エンリッチ・データ交換での接続: このレポータまたはプロセッサには、エンリッチされたデータ交換データベースとの接続に関する問題があります。 |
デーモン・ステータス |
RUEIデーモン・プロセスの1つがクラッシュしました。 リカバリしない場合は、システムのcronデーモンが正しく動作していることを確認してください。 |
データ集計 |
データ集計の遅延中です。 つまり、一部のデータ型に関して配信された最新データが予想より古いものです。 |
データ・プロセッサ出力 |
データ処理が遅延しています。 Database使用方法: 一部の表領域に使用されるデータベース割当て制限が構成済制限を超えていることを示します。 「Databaseおよびディスクの領域制限とアラートの構成」も参照してください。 |
ディスク使用量 |
一部の鍵のロケーションで使用されるディスク領域が、構成済の制限を超えていることを示します。 「Databaseおよびディスクの領域制限とアラートの構成」も参照してください。 |
エンリッチ・データ交換 |
エンリッチされたデータ交換へのエクスポートが遅延していることを示します。 |
KPIのアラート |
KPIの処理またはアラート(あるいはその両方)が遅延していることを示します。 |
ステータス・レポート自己テスト |
システム・ステータスのレポート・サブシステム自体に関する問題を示します。 |
イベント・ログ |
1つ以上の未読エラー・イベントがイベント・ログに報告されます。 |
| バッファのオーバーラン | コレクタが受信トラフィックを保持していません。 |
| CPU使用ステータス | コレクタのCPU使用率(一部のスレッド・タイプ)は非常に高くなります。 |
| インメモリー構成ステータス | コレクタは新規構成をロードしていません。 |
| ディスク上の構成ステータス | コレクタ構成の一部がコレクタ・システムに正しくプッシュされていません |
| 出力生成 | 最終ログ・ファイル生成が長すぎます。 |
図15-1に示したシステム・ステータス・インジケータが更新されるのは、ブラウザ画面のリフレッシュ時のみです。 1つ以上のシステム・プロセスで障害が発生していることがわかった場合は、システム・アラートを生成できます(「システム障害アラートの構成」を参照)。 このため、1つのプロセスに一時的に障害が発生していることが(赤いxによって)示されるが、アラートは生成されないという状況が生じる場合があります。 これは、システム・プロセスがチェックされる時点までにシステム・ステータス・インジケータが正常状態に戻っていたことが原因です。
このような設計のため、アラートがトリガーされた場合は、システム障害が発生し始めているという警告とみなすことをお薦めします。 障害は、デフォルトの境界よりもシステム遅延の方が長くなった結果、発生する場合があります。 たとえば、監視対象の行がヒットした時点と、このヒットに基づく情報がレポータで使用可能になる時点との間の待機時間がそれほど長くない場合です。 この待機時間が、トラフィックが多い環境における境界を超えている可能性があります。 また、障害は、トラフィックが一時的にピークを示した結果である場合もあります。 ただし、この状況が続く場合は、監視対象のトラフィック・レベルを確認することをお薦めします。
システムにアタッチされている各コレクタのステータスを表示するには、「システム」を選択し、「ステータス」を選択します。 このスクリーン・コレクタは、プロファイルごとに表示されます。 System (localhost)アイテムは、レポータ・システム上のローカル・コレクタを表します。他のコレクタは、IPアドレスで識別されます。 必要な「回収担当」を展開し、「コレクタ統計」を選択して、コレクタによって監視されるトラフィックの詳細レポートを表示します。 例を図15-2に示します。
図15-2 コレクタ統計ウィンドウ
このウィンドウに表示される情報は、選択したコレクタについて午前0時以降またはカウンタのリセット以降に監視されたトラフィックを示します。 ウィンドウの左下にある稼働時間フィールドは、コレクタが稼働している時間を示します。 コレクタが構成を更新するために再起動されると、この稼働時間はリセットされます。 ウィンドウに表示されているすべてのHTTPリクエスト・カウンタをリセットするには、ビューメニューでカウンタのリセットを選択します。 このカウンタが自動的にリセットされるのは、ネットワーク・パケットが次回検出されたときです。 このため、ネットワーク・トラフィックが行われていないインストール環境の場合、カウンタはリセットされません。 この表示は2秒ごとに自動的にリフレッシュされます。
コレクタ統計ウィンドウの使用
ウィンドウの左上部分にあるタブにより、選択したコレクタによって監視されたトラフィックの詳細なブレークダウンを確認できます。 これについて表15-2で説明します。
表15-2 コレクタ統計レポートのタブ
| [Tab] | 説明 |
|---|---|
インタフェース |
データ収集に使用可能なネットワーク・インタフェースについての情報を提供します。 インタフェースの数とステータスはシステム構成によって異なります。 タグ・サーバーの場合、インタフェースはIPに関連付けられ、ネットワーク・データ・コレクタはIPに関連付けられません。 標準的に構成されるインタフェースは表示されません。 使用可能なネットワーク・インタフェースごとに、名前( |
イーサネット |
監視対象のポートを介して送信されるRAWパケット・データのブレークダウンを、そのプロトコル(IPv4やARPなど)および測定されたフレーム数として表示します。 切捨てリストは、フレームが破損しているか削除されていることを示します。 |
TCP |
TCPストリームの分析結果を示します。 レポートされるカウンタは、次のとおりです。
次のネットワーク・エラー・メーターも表示されます。
これらいずれかのメーターで問題が示されるときは、TCP診断機能を使用して可能性のある原因を特定することをお薦めします。 |
TCP診断 |
この機能の使用方法は、「監視対象ネットワーク・トラフィックの確認」で説明しています。 |
HTTP |
監視したHTTPストリームの分析結果を示します。 特に、ストリームに含まれるリクエストのタイプ(GETやPOSTなど)を示します。 |
SSL接続 |
暗号化されたデータのパケットに使用されている暗号化メソッドをレポートします。 具体的には、次のとおりです。
SSLキー管理に関するエラーがレポートされます。 具体的には、次のとおりです。
(現時点で)サポートされていない暗号化メソッドは、次のとおりです。
復号化エラー・ゲージは、復号化できなかった接続の数を示します。 これには、マスター・キーを復号化できなかった、セッション・キーの計算が間違っていた、またはセグメントを復号化できなかったなどの複数の理由があります。 |
SSL暗号化 |
監視対象の暗号化データのブレークダウンを、採用された暗号化アルゴリズムの観点から示します。 使用中列は、暗号化アルゴリズムを使用した監視対象のSSL暗号化トラフィック(割合)を示します。エラー列は、失敗した(読み取ることができなかった)測定対象のSSL暗号の割合を示します。 |
パフォーマンス |
コレクタ・リソース使用率についてレポートします。 入力ドロップ・グラフには、オーバーロードが原因でコレクタによってドロップされているトラフィックの量が表示されます。これがゼロでない場合は、ただちに対処する必要があります。 メモリーとCPUグラフには、コレクタの負荷がどの程度高いかが表示されます。 メモリー使用量が、すべてのシステムで表示される制限(30%、コレクタのみのシステムでは70%)に達するか、または任意のスレッド・タイプのCPU使用率が100%になり、コレクタによってデータが削除されないようにする必要があります。 トラフィック・サンプリングについては、「全トラフィックの制限」を参照してください。 これでも問題が解決されない場合は、Oracleサポート・サービスに連絡することも必要になってきます。 |
SSLトラフィックおよびFormsトラフィックの監視
SSLトラフィックおよびOracle Formsトラフィックは、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。 これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。
したがって、各コレクタが信頼性の高いネットワーク・デバイス(TAPなど)に接続されることを確認する必要があります。 また、コレクタ統計ウィンドウに表示される情報を定期的に調べて、TCPパケット・ストリームが正常な状態であることを確認するように強くお薦めします。 TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。
KPIおよびSLAの違反に関する通知を受信できるのみでなく、システム障害のアラートを構成することもできます。 そのようにすることを強くお薦めします。 システム・アラートを使用すると、システムの問題(コレクタの障害など)に際してすぐにアクションを実行できるだけでなく、外部の深刻な問題(DoS攻撃など)を示すためにも役立ちます。 それには、システム→ステータス→ステータス通知の順に選択します。 表示されるダイアログは、「アラート・プロファイルの定義」で説明しているようになります。
基本的に、図15-1に示すインジケータ(1つまたは複数)が警告またはエラーのステータスをレポートするイベントによって、システム・アラートがトリガーされます。 たとえば、コレクタ・ステータスのアラートは、コレクタが使用できないかコレクタの障害が発生していることを示します。
重要
特に次の点に注意することをお薦めします。
構成された受信者には、データベースおよびディスク領域の使用率の警告とエラーも通知されます(「Databaseおよびディスクの領域制限とアラートの構成」を参照)。
システム・ステータスのアラートでは、アラートのスケジュールやエスカレーション・レベルは考慮されません。 アラートを構成するときは、受信者のすべての情報(電子メール・アドレスや電話番号など)を正しく指定してください。 また、システム・ステータスのチェックが10分ごとに実行されることにも注意してください。 このため、図15-1のページにシステム障害が表示された場合、その障害に関するアラートをすぐには受信せず、スケジュールされたシステム・チェックが実行されたときに受信することがあります。
イベント・ログ・アラートの場合、レポートされるイベントを確認することをお薦めします(「イベント・ログの使用」を参照)。 イベント・ログ・インジケータのステータスをOKに戻すためには、イベント・ログの警告またはエラーを読取り済としてマーキングする必要があることに注意してください。
コレクタのステータスのアラートの場合は、コレクタ統計ウィンドウを使用して、問題をトラブルシューティングすることをお薦めします(「コレクタのステータスの表示」を参照)。
他のエラーまたは警告の際(あるいはエラーや警告が長く続く場合)は、カスタマ・サポートに連絡してください。
SNMPトラップ通知
KPIおよびSLAの違反のように、SNMPトラップを使用してシステム・イベント通知を送信するように構成できます。 この場合は、イベント・ログに報告された各イベント(「イベント・ログの使用」)が個別のSNMPトラップになります。
システム・イベントに対してSNMPトラップを構成する手順は、次のとおりです。
図15-3 システム・ステータス監視ダイアログ
システムが中断しないで運用されるようにするために、使用可能なデータベース領域およびディスク領域の使用率に上限を設定します。 データベースの使用率が上限に達すると、管理メカニズムによってデータベースのサイズが許容された境界内に戻るまで、新しいデータが書き込まれなくなります。 同様に、ディスク領域使用量が最大レベルに達すると、コレクタが停止し、管理者が既存ファイルの削除処理を行うまで、(ログ形式の)データはファイル・システムに書き込まれません。 この結果、進行中のセッションの情報が失われ、フル・セッション・リプレイ(FSR)・データも同様です。 さらに、これらのいずれかの問題が発生しそうな場合にアラートを生成するように設定することも可能です。
注意:
RUEIの正常な知識があり、これらの設定の使用方法と効果を明確に理解している場合にのみ、デフォルト設定を変更することをお薦めします。
データベース領域またはディスク領域のしきい値を定義する手順は、次のとおりです。
図15-4 データベース領域とディスク領域のしきい値
図15-5 データ保存の変更
例15-1 しきい値の定義
しきい値を定義するときには、次の点に注意してください。
データベース領域またはディスク領域の使用を停止するために指定可能な最大設定は、95%です。 これは、使用可能なディスク領域が完全に(100%)いっぱいになった場合、システム上の他のコンポーネントが動作しなくなることがあるためです。 また、システムへのリモート・ログオンができなくなる可能性もあります。 同様に、データベースが完全にいっぱいになることを許可した場合には、そのサイズを削減するための管理メカニズムが動作できなくなります。
指定したしきい値は、RUEIで使用されるすべてのパーティションに適用されます。 つまり、/var/opt/ruei、およびその下にマウントされたすべてのパーティションです。 少なくとも1つのパーティションが指定されたしきい値に達すると、アラート・メカニズムおよび停止メカニズムがトリガーされます。
定義されたしきい値のチェックは、絶えず実行されるのではなく、10分ごとに実行されます。 したがって、チェックが実行されてアラートが発行されるまでに、データベース領域またはディスク領域の使用率が指定されたしきい値をすでに上回っている場合もあります。 そのため、しきい値は、意図したターゲットより少し低く設定することをお薦めします。 たとえば、ディスク領域の停止しきい値は95%でなく93%か94%に設定します。
アラート通知しきい値は、関連する停止しきい値より高い値に設定することはできません。 たとえば、データベースの停止しきい値が95%の場合には、アラートしきい値をそれより高い値に設定することはできません。
デフォルトでは、アラートしきい値は85%、停止しきい値は95%です。
Linuxオペレーティング・システムでも、ディスク領域使用率の制限は95%です。 この制限に達すると、ディスクに書き込めるのはrootユーザーのみとなります。 RUEIにはこの権限がないため、ディスク領域をそれ以上使用できなくなります。
モニター対象のネットワーク・トラフィックの概要を開くには、「システム」、「ステータス」、「レポータ統計」の順に選択します。 これにより、ヒット、ページ、セッション処理および各処理ユニットのシステム・ロードに関する情報が即座に表示されます。 例を図15-6に示します。
図15-6 データ処理ダイアログ
パフォーマンスタブの使用可能なリソース使用率(%)項目は、現在の処理レベルを示します。 この値が100%に近づくと、データの処理に遅延が発生し始め、データをリアルタイムで処理できなくなります。
この機能はアプリケーション・ロジックに基づいているため、表示されるレポートには非アプリケーション(スイート、サービス、SSOなど)のトラフィックは示されません。
注意:
RUEIが監視しているトラフィックに関して正確にレポートするには、このトラフィック・サマリーを定期的に確認することを強くお薦めします。 必要であれば、RUEIの構成を確認して適切なものにしてください。 たとえば、他のCookieテクノロジを追加します。 また、システムでセッションを追跡できない場合は、ユーザー・フローも適切に追跡できません(ユーザー・フロー・レポートではセッションの追跡が必要になるため)。
システムの現在の構成のバックアップを作成したり、必要に応じてそのバックアップをリストアできます。 バックアップは定期的に作成することをお薦めします。 バックアップにはシステム設定のみが含まれることに注意してください。 セキュリティ上の理由により、SSLキーと収集されたデータは含まれません。
バックアップを作成またはリストアする手順は、次のとおりです。
図15-7 バックアップおよびリストアダイアログ
図15-8 システム・リストアダイアログ
参照をクリックして、必要なバックアップ・ファイルを検索および選択します。
デフォルトでは、コレクタと処理エンジンに関する管理情報はリストアされません。 コレクタと処理エンジンのチェック・ボックスを使用すれば、この情報がリストアされるように指定することができます。 バックアップを作成した時点でシステムに構成されており、その後で削除されたコレクタと処理エンジンが、リストア後のシステムには追加されることに注意してください。 同じように、現在システムで構成されており、バックアップ作成時には構成されていなかったコレクタと処理エンジンは無効化されます。 準備ができたら、次へをクリックします。
例15-2 重要
次の点に注意してください。
生成されるバックアップ・ファイルには、Oracleサポート・サービス専用の大量の情報が含まれます。 このファイルの内容を変更しないでください。 リストアを実行するときは、現在のすべての設定がリストアされる設定で上書きされることに注意してください。
バックアップからリストアを実行した後、すべての必要なSSLキーをすぐにアップロードする必要があります。 これは、すべての既存のSSLキーが削除され、バックアップ・ファイルに含まれないためです。
「システムのステータスのモニタリング」で説明されているステータス情報に加えて、RUEIはイベント・ログを保持します。 これには、すべてのシステム・イベントのレコードが含まれます。 ユーザーもカスタマ・サポートも、イベント・ログを使用することで、RUEIインストールで発生する可能性のある問題をすぐに特定して解決できます。
イベント・ログの内容を定期的に確認することをお薦めします。 イベント・ログに未読のエラー・メッセージが含まれる場合、ステータスパネルのイベント・ログ項目にエラー・アイコンが表示されます。 ほとんどのイベントはすぐにレポートされますが、コレクタ関連のイベントはレポートされるまで最大で5分かかることに注意してください。
イベント・ログを確認する手順は、次のとおりです。
RUEIでは、テキスト・メッセージ通知の使用がサポートされています。 この機能を使用するには、使用するすべてのテキスト・メッセージ・プロバイダを構成してシステムに認識させる必要があります。 プロバイダ情報を管理するには、システム→メンテナンス→テキスト・メッセージ・プロバイダの順に選択します。 図15-11に示すダイアログが表示されます。
図15-11 Text Message Accountsダイアログ
テキスト・メッセージ・プロバイダを構成する手順は、次のとおりです。
図15-12 Select Text Message Providerダイアログ
注意:
ローカルGSMモデムを指定する場合は、システムにGSMモデムを装着しておく必要があります。 装着が必要なローカル・モデムは、USBまたはシリアルGSM ETSI 07.05準拠のモデムです。
図15-13 Account Detailダイアログ
例15-3 Unicodeのサポート
テキスト・メッセージではUnicodeがサポートされていますが、多数の制限事項があることを認識しておく必要があります。 ローカルに装着したモデムの場合では、7ビットGSM 3.38アルファベットを使用してメッセージが送信されます。 サポートされていない文字が元のメッセージに含まれる場合は、疑問符(?)文字に置換されます。 外部サービス・プロバイダの場合は、マルチバイト・キャラクタ・セットのサポートに関してサービス・プロバイダに問い合せることをお薦めします。 ローカルに装着したモデムと外部サービス・プロバイダの両方で、テキスト・メッセージは160文字に制限されます。
RUEIの使用または操作に関して問題が発生した場合は、Oracleサポート・サービスに問い合せることができます。 ただし、その前に、ご使用のシステムのヘルプデスク・レポート・ファイルを作成することをお薦めします。 これを実行するには、システム→メンテナンス→ヘルプデスク・レポートの順に選択します。 ヘルプデスクの作成に時間がかかる場合があります。 完了すると、ファイルのダウンロード先となる場所を指定するように求められます。
ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。
注意:
生成されたファイルには、ソフトウェアの所有権情報が含まれます。 コンテンツを変更しないでください。
デフォルトでは、内部エラーは次のような汎用エラー・メッセージでユーザー・インタフェース内に表示されます。
An internal system error has occurred. Please contact the Administrator with the error details.
しかし、エラーの詳細が必要な場合には、次の手順を実行して、セッション・デバッグを有効にすることができます。
図15-14 セッション・デバッグ・ダイアログ
注意:
セッション・デバッグオプションがヘルプメニューに表示されるのは、RUEI管理者ユーザーとしてログインした場合のみです。
有効にすると、詳細なエラー・メッセージがレポートされます。 また、メッセージ(および対応する診断情報)は指定されたログ・ファイルにも追加されます。 この設定が適用されるのは、現在のセッションのみです。
注意:
カスタマー・サポートにエラーを報告する際には、セッション・デバッグの機能を有効にすることをお薦めします。
「メーリング機能の使用」 で説明されているように、RUEIはリクエストされたレポートの自動電子メールを送信できます。 この機能では、初期構成フェーズ(『Oracle Real User Experience Insightインストレーション・ガイド』を参照)で指定した情報を利用します。 ただし、システム→メンテナンス→電子メール設定の順に選択して、この構成を変更できます。 「図15-15」に示すダイアログが表示されます。
図15-15 電子メール設定ダイアログ
「図15-15」に示されるフィールドは、「表15-5」で説明されています。
表15-5 電子メール設定のフィールド
| フィールド | 説明 |
|---|---|
返信用アドレス |
失敗した電子メールまたは問題が発生した電子メールのレポート先となる電子メール・アドレスを指定します。 このアドレスを定期的にチェックすることを強くお薦めします。 |
送信元アドレス |
受信者のメール・クライアントに表示されるアドレスを指定します。 |
返信先アドレス |
ユーザーが電子メール内でクリックして返信できるアドレスを指定します。 これが指定されていない場合は、送信元アドレス設定が使用されます。 |
メール・サイズ制限 |
電子メールの最大許容メッセージ・サイズ(KB単位)を指定します。 電子メールにこの制限を超えるレポートが含まれる場合は、この制限に対応するために、レポートが個別の電子メールに分割されます。 個別に送信するには大きすぎるレポートは送信されず、ユーザーに問題が通知されます。 デフォルトのメール・サイズ制限は5000KBです。 |
レポータURL |
電子メールの受信者がレポータ・システムに接続するために必要となる詳細なURLを指定します。 通常、このURLは、RUEIユーザーがレポータ・システムにアクセスするために使用するURLと同じです。 |
原因不明の問題が発生した場合は、処理が適切に動作して同期化されるように、処理をリセットできます。 ただし、このオプションを選択すると、データの可用性と監視に一時的な遅延が発生します。
最後の手段として、収集されたすべてのデータをシステムから削除できます。 また、すべてのパラメータ(作成されたユーザーや環境パラメータなど)をデフォルト値にリセットできます。
システムをリセットする手順は、次のとおりです。
注意:
収集したデータのパージおよび出荷時のデフォルトにリセットオプションは、実行すると取消しできません。 収集されたすべてのデータが消去されます。 出荷時のデフォルトにリセットの場合、すべてのシステム設定も元の状態に戻ります。 したがって、レポータ・インタフェースにアクセスするには、初期構成をすべて(およびset-admin-password.shスクリプトを使用したadminユーザー・パスワードの定義)行うことが必要になります。 以前にバックアップを作成している場合(「構成バックアップの作成とリストア」で説明)、初期構成後にこのバックアップをリストアできます。 この初期構成の手順は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。
特定の要件に合わせて、データ・アイテム(データ・ブラウザ・グループ、フィールド名など)をカスタマイズできます。 RUEIカタログの動作方法について正しい知識を持っている場合のみ、この機能を使用することをお薦めします。
デプロイメントで使用するデータ変換をカスタマイズするには、次の手順を実行します。
