ヘッダーをスキップ
Oracle® Real User Experience Insightユーザーズ・ガイド
リリース11.1 for Linux x86-64
B63041-01
  目次
目次		 索引
索引
戻る
前へ 		 次へ
次へ		  

C トラブルシューティング

この付録では、RUEIの使用時に発生する最も一般的な問題を取り上げ、それらの問題を見つけて修正するための解決方法を示します。Oracleサポート・サービスに問い合せる前に、この付録の内容を確認してください。

C.1 オラクル社のWebサイト

RUEI Webサイトでは、各種トピックに関する情報を公開しています(http://www.oracle.com/enterprise_manager/user-experience-management.html)。定期的にこのサイトにアクセスしてサポートの告知を確認することをお薦めします。

さらに、Oracleサポート・サービスのWebサイトでは詳しい技術情報を公開しています(https://metalink.oracle.com)。このサイトには、使用可能なサービス・パック、FAQ、トレーニング資料、ヒントとテクニック集および最新バージョンの製品ドキュメントが含まれます。

C.2 Oracleサポート・サービスへの問合せ

RUEIの使用または操作に関して問題が発生した場合は、Oracleサポート・サービスに問い合せることができます。ただし、その前に、ご使用の構成のヘルプデスク・レポート・ファイルを作成することをお薦めします。これを実行するには、「System」→「Configuration」→「Helpdesk report」の順に選択します。ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。

C.3 一般的な(固有でない)問題

レポータ・モジュールで問題が発生したり、そのインタフェースが不安定な場合は、次の操作を実行することをお薦めします。

C.4 起動に関する問題

RUEIが開始しない場合や正しいポートをリスニングしない場合は、次の操作を実行してください。

C.5 レポートされるデータの遅延

すべての監視対象トラフィックのレポートには遅延があることを理解しておく必要があります。ダッシュボードに表示される情報(いわゆるリアルタイム・データ)では、この遅延は5分です。その他大部分のデータ・ビュー(つまり、セッションベースのデータ)では、この遅延は15分です。ただし、全ページ・ビューと失敗したURLビューの2つは例外です。これらの遅延は両方とも5分です。リアルタイム・データのレポートとセッションベースのデータのレポートの内容に、わずかな相違があることに直面したときに備えて、これらのデータの違いを理解しておくことは重要です。この詳細は、3.2.1項「リアルタイム・データとセッションベースのデータ」に記載されています。

C.6 SNMPアラートに関する問題

SNMPアラートに関する問題(必要なユーザーがアラートを受信できないなど)が発生した場合は、次の操作を実行することをお薦めします。

また、SNMPアラートのKPI名がUTF-8で指定されていること、および一部のSNMPマネージャがUTF-8を完全サポートしていないことに注意してください。詳細は、ご使用のSNMPマネージャの製品ドキュメントを参照してください。

C.7 テキスト・メッセージ・アラートに関する問題

テキスト・メッセージ・アラートに関する問題が発生した場合は、次の操作を実行することをお薦めします。

C.8 タイムゾーンに関する問題

レポータ内のレポート時間に関する問題が発生した場合は、目的のタイムゾーンが/etc/php.iniファイルの[Date]セクションに明示的に設定されていることを確認してください。この詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。また、次のコマンドを使用してApache Webサーバーを再起動(rootとしてログオン)する必要があります。 

httpd -k restart

C.9 データの監視が停止していると思われる状況

大量のトラフィックを監視している場合は、レポートされたデータから、RUEIでネットワーク・トラフィックが監視されなくなったか、遅延が発生しているように見えることがあります。例を図C-1に示します。

図C-1 レポートされたネットワーク・トラフィックの激減

図C-1の説明が続きます
「図C-1 レポートされたネットワーク・トラフィックの激減」の説明

このレポートによると、ネットワーク・トラフィックの監視が19:00に停止したことが示されています。実際、この状況はRUEIシステムの過負荷が原因で発生しています。トラフィックは継続して監視されていますが、トラフィックが大量で、対応に十分なリソースがないため、生成するコレクタ・ログ・ファイルを処理できなくなっています。

この状況を確認するには、「System」→「Maintenance」→「Data processing」の順に選択し、「Performance」タブをクリックします。レポートされたシステム・ロードが100%に近づいている場合は、システムは過負荷状態になっています。この機能の使用方法の詳細は、15.5項「トラフィック・サマリーの表示」に記載されています。

システムが恒久的に過負荷状態にならないように、RUEIでは、午前0時から約30分間、前日のすべてのコレクタ・ログ・ファイルの処理を自動的に停止します。これにより、バックログを廃棄してRUEIを標準の処理レベルに戻すことができます。

図C-1に示す状況が継続する場合は、ネットワーク・フィルタを使用して監視対象トラフィックを制限することをお薦めします。この詳細は、13.3.3項「全体のトラフィックの制限」に記載されています。また、RUEIシステムに追加リソースを割り当てることも検討してください。

C.10 コレクタがクラッシュするとコア・ダンプが生成されない

コレクタのインスタンスがクラッシュしたときは、コア・ダンプが生成されません。ただし、コア・ダンプを取得できても、ユーザーの問題にはカスタマ・サポートでしか解決できないものがあります。次を実行します。

  1. コレクタ・インスタンスが実行しているシステムで次のコマンドをmoniforceユーザーとして発行します。

    ulimit -c unlimited

  2. $APPSENSOR_HOME/wg/config/config.cfgファイルを編集し、CoreSize変数を-1に変更します。

  3. 次のコマンドをmoniforceユーザーとして発行することでコレクタを再起動します。

    appsensor restart wg

RUEIでは、$APPSENSOR_HOMEディレクトリにあるコア・ダンプは毎晩午前2:30に自動的に消去されることに注意してください。また、コア・ダンプが定期的に生成されると、ファイル・システムの領域が一杯になってしまう可能性があります。このため、目的のコア・ダンプを取得したらすぐにデフォルト構成に戻すことをお薦めします。

C.11 イベント・ログでの強制コア・ダンプのレポート

Thread deadlock detected in the log file processor; forcing a core dump.This may be caused by insufficient system memory.

このエラーがイベント・ログに記録された場合は、次を実行します。

C.12 メモリー割当てエラー

次のエラーがイベント・ビューアでレポートされます。

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
  戻る
前へ 		 次へ
次へ
  目次
目次		 索引
索引