この付録では、RUEIの使用時に発生する最も一般的な問題を取り上げ、それらの問題を見つけて修正するための解決方法を示します。Oracleサポート・サービスに問い合せる前に、この付録の内容を確認してください。
RUEI Webサイトでは、各種トピックに関する情報を公開しています(http://www.oracle.com/enterprise_manager/user-experience-management.html)。定期的にこのサイトにアクセスしてサポートの告知を確認することをお薦めします。
さらに、Oracleサポート・サービスのWebサイトでは詳しい技術情報を公開しています(https://metalink.oracle.com
)。このサイトには、使用可能なサービス・パック、FAQ、トレーニング資料、ヒントとテクニック集および最新バージョンの製品ドキュメントが含まれます。
RUEIの使用または操作に関して問題が発生した場合は、Oracleサポート・サービスに問い合せることができます。ただし、その前に、ご使用の構成のヘルプデスク・レポート・ファイルを作成することをお薦めします。これを実行するには、「System」→「Configuration」→「Helpdesk report」の順に選択します。ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。
レポータ・モジュールで問題が発生したり、そのインタフェースが不安定な場合は、次の操作を実行することをお薦めします。
ブラウザ内のすべてのキャッシュをクリアし、ブラウザを再起動します。
エラー・ログを調べます。この詳細は、15.7項「イベント・ログの使用」に記載されています。
レポータがインストールされているシステムを再起動します。
RUEIが開始しない場合や正しいポートをリスニングしない場合は、次の操作を実行してください。
ネットワーク・フィルタ定義を確認します。この詳細は、13.3項「ネットワーク・フィルタの定義」に記載されています。特に、通常のネットワーク・フィルタが適用されていないことを確認してください。これは、VLANの場合に特に重要です。
RUEIが正しいプロトコルとポートをリスニングしていることを確認します。この詳細は、13.2項「監視の有効範囲の管理」に記載されています。
すべての監視対象トラフィックのレポートには遅延があることを理解しておく必要があります。ダッシュボードに表示される情報(いわゆるリアルタイム・データ)では、この遅延は5分です。その他大部分のデータ・ビュー(つまり、セッションベースのデータ)では、この遅延は15分です。ただし、全ページ・ビューと失敗したURLビューの2つは例外です。これらの遅延は両方とも5分です。リアルタイム・データのレポートとセッションベースのデータのレポートの内容に、わずかな相違があることに直面したときに備えて、これらのデータの違いを理解しておくことは重要です。この詳細は、3.2.1項「リアルタイム・データとセッションベースのデータ」に記載されています。
SNMPアラートに関する問題(必要なユーザーがアラートを受信できないなど)が発生した場合は、次の操作を実行することをお薦めします。
SNMP通知設定を十分に確認します。特に、マネージャのアドレスが正しいこと、必要なMIB定義をダウンロードして実装していること、およびそのSNMP通知が有効化されていることを確認してください。この詳細は、15.3項「システム障害アラートの構成」に記載されています。
最新バージョンのMIBファイルをダウンロードしてインストールしていることを確認します。
受信者のネットワーク接続をチェックします。
SNMPマネージャの構成をチェックします。
また、SNMPアラートのKPI名がUTF-8で指定されていること、および一部のSNMPマネージャがUTF-8を完全サポートしていないことに注意してください。詳細は、ご使用のSNMPマネージャの製品ドキュメントを参照してください。
テキスト・メッセージ・アラートに関する問題が発生した場合は、次の操作を実行することをお薦めします。
テキスト・メッセージ通知設定を十分に確認します。この詳細は、7.5.7項「テキスト・メッセージ通知の使用方法」および15.3項「システム障害アラートの構成」に記載されています。
レポートされた問題についてテキスト・メッセージ・プロバイダに問い合せます。
モデムが正しく機能していることを確認します。
レポータ内のレポート時間に関する問題が発生した場合は、目的のタイムゾーンが/etc/php.ini
ファイルの[Date]セクションに明示的に設定されていることを確認してください。この詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。また、次のコマンドを使用してApache Webサーバーを再起動(root
としてログオン)する必要があります。
httpd -k restart
大量のトラフィックを監視している場合は、レポートされたデータから、RUEIでネットワーク・トラフィックが監視されなくなったか、遅延が発生しているように見えることがあります。例を図C-1に示します。
このレポートによると、ネットワーク・トラフィックの監視が19:00に停止したことが示されています。実際、この状況はRUEIシステムの過負荷が原因で発生しています。トラフィックは継続して監視されていますが、トラフィックが大量で、対応に十分なリソースがないため、生成するコレクタ・ログ・ファイルを処理できなくなっています。
この状況を確認するには、「System」→「Maintenance」→「Data processing」の順に選択し、「Performance」タブをクリックします。レポートされたシステム・ロードが100%に近づいている場合は、システムは過負荷状態になっています。この機能の使用方法の詳細は、15.5項「トラフィック・サマリーの表示」に記載されています。
システムが恒久的に過負荷状態にならないように、RUEIでは、午前0時から約30分間、前日のすべてのコレクタ・ログ・ファイルの処理を自動的に停止します。これにより、バックログを廃棄してRUEIを標準の処理レベルに戻すことができます。
図C-1に示す状況が継続する場合は、ネットワーク・フィルタを使用して監視対象トラフィックを制限することをお薦めします。この詳細は、13.3.3項「全体のトラフィックの制限」に記載されています。また、RUEIシステムに追加リソースを割り当てることも検討してください。
コレクタのインスタンスがクラッシュしたときは、コア・ダンプが生成されません。ただし、コア・ダンプを取得できても、ユーザーの問題にはカスタマ・サポートでしか解決できないものがあります。次を実行します。
コレクタ・インスタンスが実行しているシステムで次のコマンドをmoniforce
ユーザーとして発行します。
ulimit -c unlimited
$APPSENSOR_HOME/wg/config/config.cfg
ファイルを編集し、CoreSize
変数を-1に変更します。
次のコマンドをmoniforce
ユーザーとして発行することでコレクタを再起動します。
appsensor restart wg
RUEIでは、$APPSENSOR_HOME
ディレクトリにあるコア・ダンプは毎晩午前2:30に自動的に消去されることに注意してください。また、コア・ダンプが定期的に生成されると、ファイル・システムの領域が一杯になってしまう可能性があります。このため、目的のコア・ダンプを取得したらすぐにデフォルト構成に戻すことをお薦めします。
Thread deadlock detected in the log file processor; forcing a core dump.This may be caused by insufficient system memory.
このエラーがイベント・ログに記録された場合は、次を実行します。
このメッセージが不定期に出現する場合は、RUEIソフトウェアのバグが原因である可能性があります。関連するイベントの詳細とともにカスタマ・サポートに問い合せてください。
このメッセージが毎晩(またはほぼ毎晩)出現する場合は、高レベルのメモリー・スワップが発生するときにシステムが過負荷になっていることを示す可能性があります。この場合、システムへのメモリーの追加を検討する必要があります。
次のエラーがイベント・ビューアでレポートされます。
linux.c, 326,cap_dev_set_filter()]: setsockopt(): Cannot allocate memory
コレクタがトラフィックの監視のために使用している、ベースのLinuxソケット・インタフェースのメモリー割当て制限は20KBです。多数のネットワーク・フィルタ(またはVLAN定義)を構成すると、この制限を上回ることがあります。
次のコマンドをroot
ユーザーとして発行すると、実行しているシステムでベースの制限を増やすことができます。
/sbin/sysctl -w net.core.optmem_max=65535
リブートしてもこの設定が保たれるようにするには、次の行を/etc/sysctl.conf
ファイルに追加します。
net.core.optmem_max=65535