Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース3 (12.1.0.4) for Linux x86-64 E49732-01 |
|
![]() 前 |
![]() 次 |
この付録では、RUEIの使用時に発生する最も一般的な問題を取り上げ、それらの問題を見つけて修正するための解決方法を示します。Oracleサポート・サービスに問い合せる前に、この付録の内容を確認してください。
様々なトピックの詳細は、RUEI Webサイト(http://www.oracle.com/enterprise_manager/user-experience-management.html
)を参照してください。定期的にこのサイトにアクセスしてサポートの告知を確認することをお薦めします。
さらに、Oracleサポート・サービスのWebサイトでは詳しい技術情報を公開しています(https://metalink.oracle.com
)。このサイトには、使用可能なサービス・パック、FAQ、トレーニング資料、ヒントとテクニック集および最新バージョンの製品ドキュメントが含まれます。
RUEIの使用または操作に関して問題が発生した場合は、Oracleサポート・サービスに問い合せることができます。ただし、その前に、ご使用の構成のヘルプデスク・レポート・ファイルを作成することをお薦めします。これを実行するには、「システム」→「構成」→「ヘルプデスク・レポート」の順に選択します。ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。
レポータ・モジュールで問題が発生したり、そのインタフェースが不安定な場合は、次の操作を実行することをお薦めします。
ブラウザ内のすべてのキャッシュをクリアし、ブラウザを再起動します。
エラー・ログを調べます。この詳細は、15.7項「イベント・ログの使用」に記載されています。
レポータがインストールされているシステムを再起動します。
RUEIが開始しない場合や正しいポートをリスニングしない場合は、次の操作を実行してください。
ネットワーク・フィルタ定義を確認します。この詳細は、13.4項「ネットワーク・フィルタの定義」に記載されています。特に、通常のネットワーク・フィルタが適用されていないことを確認してください。これは、VLANの場合に特に重要です。
RUEIが正しいプロトコルとポートをリスニングしていることを確認します。この詳細は、13.3項「監視の有効範囲の管理」に記載されています。
すべての監視対象トラフィックのレポートには遅延があることを理解しておく必要があります。ダッシュボードに表示される情報(いわゆるリアルタイム・データ)では、この遅延は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システムの過負荷が原因で発生しています。トラフィックは継続して監視されていますが、トラフィックが大量で、対応に十分なリソースがないため、生成するコレクタ・ログ・ファイルを処理できなくなっています。
この状況を確認するには、「システム」→「メンテナンス」→「データ処理」の順に選択し、「パフォーマンス」タブをクリックします。レポートされたシステム・ロードが100%に近づいている場合は、システムは過負荷状態になっています。この機能の使用方法の詳細は、15.5項「トラフィック・サマリーの表示」に記載されています。
システムが恒久的に過負荷状態にならないように、RUEIでは、午前0時から約30分間、前日のすべてのコレクタ・ログ・ファイルの処理を自動的に停止します。これにより、バックログを廃棄してRUEIを標準の処理レベルに戻すことができます。
図C-1に示す状況が継続する場合は、ネットワーク・フィルタを使用して監視対象トラフィックを制限することをお薦めします。この詳細は、13.4.3項「全体のトラフィックの制限」に記載されています。また、RUEIシステムに追加リソースを割り当てることも検討してください。
コレクタのインスタンスがクラッシュしたときは、コア・ダンプが生成されません。ただし、コア・ダンプを取得できても、ユーザーの問題にはカスタマ・サポートでしか解決できないものがあります。コレクタ・システムのコア・ダンプを有効にする手順は、Oracle Real User Experience Insightアドバンスト管理者ガイドに記載されています。
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
8.2.12項「ユーザー識別の定義」に記載しているように、RUEIは、Cookieを使用してユーザー・セッションを追跡します。多くの同時ユーザーが監視対象のWebサイトを訪問し、制限された一意のCookie値を選択できる場合、異なるユーザー・セッションに同じCookie値を割り当てる可能性があるので注意してください。これが発生する場合、予期しないレポートになる可能性があります。このため、次のCookieおよびCookie値をセッション・トラッキングに対して使用しないことを強くお薦めします。
ロード・バランシングCookie。
時間ベースCookie。
ログアウトCookie値。
ユーザー・プリファレンスが格納されるCookie(特に使用可能な値の範囲が制限される場合)
完全なアプリケーション・ドメインに設定されていないCookie。
重要: トラッキング・ユーザー・セッションに対して高速回転のCookie値の使用を回避することを強くお薦めします。 |
また、構成されたCookieテクノロジがすべての監視対象ヒットに対応し、ヒットの複数の一致Cookieが回避されるようにすることをお薦めします。
データベース・クラッシュが発生した場合、オブジェクトが破損する可能性があります。通常、これはORA-00376で表示され、同様のエラーがイベント・ログにレポートされます。
重要:
次の場所のナレッジ・ベース記事の情報を注意深く確認してください。
https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1303180.1
特に、ロギングを強制するために示された表領域が設定されていることを確認してください。
データベース表の確認
次のコマンドを使用して、データベース表のステータスを表示できます。
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
データ列にゼロ値が含まれるか、多くのゼロまたはダッシュがある場合、破損したデータベース表を示します。この場合、次のナレッジ・ベース記事に記載されているスクリプトを使用して、データベースをリストアする必要があります。
https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=556733.1
また、次のコマンドを発行してRUEI構成およびテンプレート表の更新を強制することをお薦めします。
makedatabase @ modr -fn all