ヘッダーをスキップ
Oracle® Real User Experience Insightユーザーズ・ガイド
12c リリース6 (12.1.0.7) for Linux x86-64
E61771-02
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

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

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

『Oracle Real User Experience Insightインストレーション・ガイド』の「トラブルシューティング」を参照してください。

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

  • ブラウザ内のすべてのキャッシュをクリアし、ブラウザを再起動します。

  • エラー・ログを調べます。この詳細は、15.7項「イベント・ログの使用」に記載されています。

  • レポータがインストールされているシステムを再起動します。

C.4 起動に関する問題

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

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

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

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

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

  • SNMP通知設定を十分に確認します。特に、マネージャのアドレスが正しいこと、必要なMIB定義をダウンロードして実装していること、およびそのSNMP通知が有効化されていることを確認してください。この詳細は、15.3項「システム障害アラートの構成」に記載されています。

  • 最新バージョンのMIBファイルをダウンロードしてインストールしていることを確認します。

  • 受信者のネットワーク接続をチェックします。

  • 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システムの過負荷が原因で発生しています。トラフィックは継続して監視されていますが、トラフィックが大量で、対応に十分なリソースがないため、生成するコレクタ・ログ・ファイルを処理できなくなっています。

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

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

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

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

コレクタのインスタンスがクラッシュしたときは、コア・ダンプが生成されません。ただし、コア・ダンプを取得できても、ユーザーの問題にはカスタマ・サポートでしか解決できないものがあります。コレクタ・システムのコア・ダンプを有効にする手順は、Oracle Real User Experience Insightアドバンスト管理者ガイドに記載されています。

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

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

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

  • このメッセージが不定期に出現する場合は、RUEIソフトウェアのバグが原因である可能性があります。関連するイベントの詳細とともにカスタマ・サポートに問い合せてください。

  • このメッセージが毎晩(またはほぼ毎晩)出現する場合は、高レベルのメモリー・スワップが発生するときにシステムが過負荷になっていることを示す可能性があります。この場合、システムへのメモリーの追加を検討する必要があります。

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

C.13 同じCookie値を受信する複数のユーザー・セッション

8.3.14項「ユーザー識別の定義」に記載しているように、RUEIは、Cookieを使用してユーザー・セッションを追跡します。多くの同時ユーザーが監視対象のWebサイトを訪問し、制限された一意のCookie値を選択できる場合、異なるユーザー・セッションに同じCookie値を割り当てる可能性があるので注意してください。これが発生する場合、予期しないレポートになる可能性があります。このため、次のCookieおよびCookie値をセッション・トラッキングに対して使用しないことを強くお薦めします。

  • ロード・バランシングCookie。

  • 時間ベースCookie。

  • ログアウトCookie値。

  • ユーザー・プリファレンスが格納されるCookie(特に使用可能な値の範囲が制限される場合)。

  • 完全なアプリケーション・ドメインに設定されていないCookie。


重要:

トラッキング・ユーザー・セッションに対して高速回転のCookie値の使用を回避することを強くお薦めします。

また、構成されたCookieテクノロジがすべての監視対象ヒットに対応し、ヒットの複数の一致Cookieが回避されるようにすることをお薦めします。

C.14 データベース・クラッシュ後のオブジェクトのリカバリ

データベース・クラッシュが発生した場合、オブジェクトが破損する可能性があります。通常、これはORA-00376で表示され、同様のエラーがイベント・ログにレポートされます。

重要:

My Oracle Supportで(1303180.1を検索して)ナレッジ・ベース記事1303180.1をよく確認してください。

https://support.oracle.com

特に、ロギングを強制するために示された表領域が設定されていることを確認してください。

データベース表の確認

次のコマンドを使用して、データベース表のステータスを表示できます。

cop stats %period

periodは、必要な年(2012)、月(201203)または日(20120326)を示します。コマンド出力が次のように表示されます。

       STRUCTURE      PRESENTATION   DATA ROWS         DATA SIZE hash  data dims lvls  pres view   data    desc      data     desc   cube name------ ---- ---- ----  ---- ----  ------  ------   -------  -------  ----------fTq7vQ  19   11   22   133  156        0       2    0.1 MB   0.1 MB  wg_keypage_mo_201203u7q+3g   9    4    8    13    7        -     470    0.6 MB   0.1 MB  wg_kpi_mo_201203PMocAw  22    9   17   159  174        -   16960   19.0 MB   4.0 MB  wg_page_mo_201203K/p4ww  12   12   29   123  104        0       0    0.1 MB   0.1 MB  wg_service_mo_2012031S2Ggg  10   19   29    79   90        -     247    2.0 MB   0.1 MB  wg_slowurl_mo_201203lZRuxg  29    5   10   279   61        0       0    0.1 MB   0.1 MB  wg_trasta_mo_201203yuY0aQ  29   11   20   153  204        -     343    2.0 MB   0.1 MB  wg_visit_mo_201203

データ列にゼロ値が含まれるか、多くのゼロまたはダッシュがある場合、破損したデータベース表を示します。この場合、(556733.1を検索して)次のナレッジ・ベース記事556733.1に記載されているスクリプトを使用して、データベースをリストアする必要があります。

https://support.oracle.com

また、次のコマンドを発行してRUEI構成およびテンプレート表の更新を強制することをお薦めします。

makedatabase @
modr -fn all
  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引