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

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

C.1 Oracle Web Sites

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

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

C.2 カスタマ・サポートへの問合せ

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

C.3 一般的な(特定されない)問題

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

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

ブラウザ内のすべてのキャッシュをクリアし、ブラウザを再起動します。
エラー・ログを調べます。これについては、「イベント・ログの使用」で説明しています。
レポータがインストールされているシステムを再起動します。

C.4 開始中の問題

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

ネットワーク・フィルタの定義を確認します。これについては、「ネットワーク・フィルタの定義」で説明しています。特に、通常のネットワーク・フィルタが適用されていないことを確認します。これは、VLANの場合に特に重要です。
RUEIが正しいプロトコルとポートをリスニングしていることを確認します。これについては、「ネットワーク・ベースのモニタリングの有効範囲の管理」で説明しています。

C.5 レポート済データの遅延

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

C.6 SNMPアラートの問題

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

SNMP通知設定を十分に確認します。特に、マネージャのアドレスが正しいこと、必要なMIB定義をダウンロードして実装していること、およびそのSNMP通知が有効化されていることを確認してください。これについては、「システム障害アラートの構成」で説明しています。
最新バージョンの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 レポートされたネットワーク・トラフィックの激減の説明

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

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

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

図C-1に示す状況が継続する場合は、ネットワーク・フィルタを使用して監視対象トラフィックを制限することをお薦めします。これについては、「全トラフィックの制限」で詳しく説明しています。また、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値を受信する複数のユーザー・セッション

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

ロード・バランシングCookie。
時間ベースCookie。
ログアウトCookie値。
ユーザー・プリファレンスが格納されるCookie(特に使用可能な値の範囲が制限される場合)。
完全なアプリケーション・ドメインに設定されていないCookie。

注意:

ユーザー・セッションのトラッキングでは、高回転のcookie値の使用を回避することをお薦めします。

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

C.14 Databaseクラッシュ後のオブジェクトのリカバリ

データベース・クラッシュが発生した場合、オブジェクトが破損する可能性があります。通常、これは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