プライマリ・コンテンツに移動
Oracle® Enterprise Manager Cloud Control Oracle Fusion Middleware管理ガイド
13cリリース1
E72552-02
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

19 Enterprise Managerを使用したミドルウェア・アプリケーションのトラブルシューティング

ここでは、Enterprise Managerを使用してミドルウェア・アプリケーションをトラブルシューティングする様々な方法を説明します。

エンタープライズ・ソフトウェアの世界が複雑化するにつれ、問題のトラブルシューティングがさらに困難になる可能性があります。Oracleミドルウェアのドキュメントに目を通すだけでも複雑になることがわかります。

https://docs.oracle.com/en/middleware/

ここでは、Enterprise Managerや関連する製品を使用してアプリケーションをトラブルシューティングする様々な方法を紹介します。これらの方法で、障害が発生したミドルウェア・コンポーネントの専門知識がトラブルシューティング担当者に求められることはありません。

この章の内容は次のとおりです。

19.1 ミドルウェア・アプリケーションのトラブルシューティングの概要

この章では、ユーザーが見逃している可能性があるEnterprise Managerの機能を紹介するとともに、Oracle Supportの経験豊かなスタッフが習得した方法を伝えます。

このガイドで使用する方法は次のようにまとめることができます。

  1. 環境を準備します。第19.2項「アプリケーションをトラブルシューティングするための環境の準備」および第19.3項「アプリケーションのトラブルシューティングに役立つ環境の構成」の説明に従って、システムを理解して、システムをモニターする準備を行います。

  2. システムが多くのミドルウェア層で構成されている場合は、問題を1つのミドルウェア層に切り分けます。第19.4.4項「複数ミドルウェア層を含む環境でのインシデントの分析」を参照してください。

  3. 1つのミドルウェア層に問題を切り分けたら、Enterprise Managerを使用してさらに問題を切り分けて解決します。第19.4.3項「単一ミドルウェア層を含む環境でのインシデントの分析」を参照してください。

  4. 必要な場合には、第19.5項「Enterprise Managerを使用した問題の解決」の説明に従って問題を解決します。


注意:

トラブルシューティングでは解決すべき問題があることが必要であるため、場合によっては人為的にシステムに負荷をかけて、Enterprise Managerにモニタリング結果を生成する必要があります。これは特にJavaの負荷に該当します。ただし、このような負荷の生成に必要な方法はこのガイドでは扱いません。

たとえば、環境に様々なサーバーの情報を使用するWebアプリケーションが構成されているとします。

図19-1 サンプル環境

図19-1の説明が続きます
「図19-1 サンプル環境」の説明'

通常は、Webアプリケーションの特定の機能に関するトラブルが発生してユーザーが問題を提示します。該当するミドルウェア層と問題の解決方法が明白なケースもたまにはあります。ただし、最新のアプリケーションは複雑であり担当者も専門化しているため、モニタリング・ソフトウェアを使用してシステムを分析するほうが有効です。こうすることで問題の根本原因を検出して正しい修正を適用できます。たとえば、本番環境をモニタリングすることによって、個別のミドルウェア層の分析ではわからない、またはテスト環境では再現できない、その環境に固有の問題が明らかになる場合があります。

この図はシステムを簡略に表したもので、Oracle Coherenceは含まれていません。Coherenceおよび管理対象Coherence (WebLogicドメインで実行するCoherence)には新機能Coherence Heat Mapが含まれます。これはCoherence Log Viewer/Searchと連動して、ミドルウェアの問題を切り分ける際に役立ちます。

また、パフォーマンスの問題はEnterprise Managerの管理外のアイテムに関連する場合もあります。したがって、パフォーマンスの問題の解決を試みる前に、アプリケーションの実行に関係するタイミングを理解することが重要です。

図19-2 Webアプリケーションの一般的なタイミング

図19-2の説明が続きます
「図19-2 Webアプリケーションの一般的なタイミング」

19.2 アプリケーションをトラブルシューティングするための環境の準備

アプリケーションのトラブルシューティングに必要な時間や作業は、決まった手順を実行して環境を準備することによって削減できます。この項では、トラブルシューティング・プロセスに役立つ、環境への追加ソフトウェアについて説明します。この項の手順をすでに実行してしまった場合や、ご使用の環境で一部の手順が実行できない場合も考えられます。そのような場合には、第19.3項「アプリケーションのトラブルシューティングに役立つ環境の構成」に進んでください。

次の表に、環境を準備するために追加のソフトウェアをインストールできる状況を示します。

表19-1 インストール・オプション

環境構成 インストール・オプション

すべて

すべてのノードに管理エージェントをインストールします。

Webアプリケーション

Oracle Real User Experience Insight (RUEI)をインストールします。

Javaアプリケーション

JVM診断(JVMD)をインストールします。

複数ミドルウェア層
(Oracle Service Busなど)

Oracle Business Transaction Management (BTM)をインストールします。


19.2.1 環境におけるシステムのトポロジのドキュメント化

このタスクの範囲はモニターする必要があるシステムによって異なります。システムが依存しる外部サービスも含めて、パフォーマンスに影響する可能性があるシステムのすべてのコンポーネントをモニターすることが重要です。

Enterprise Managerでは、最新の一般的な環境について完全なトポロジ・ドキュメントを自動的に提供できます。関連するすべてのシステムがオラクル社によって提供される場合は、Enterprise Managerがすべてのコンポーネントを確実に検出してモニタリングできます。Enterprise Managerでは、たとえばOracle System Monitoring Plug-in for Microsoft Active Directoryを使用して、オラクル製以外の多数のシステムをモニターすることもできます。

ただし、多くのシステム(依然として従来のメインフレーム・システムへの呼出しに依存しているシステムなど)には固有のコンポーネントが含まれています。複雑なシステムをトラブルシューティングするには、事前に各コンポーネントと依存関係を理解することが重要です。組織によっては、担当者が変わると依存関係がわからなくなる可能性があります。将来のトラブルシューティングを行う場合に備えてシステム・トポロジに関連するドキュメントを作成しておくことが重要です。デプロイメント・トポロジの例を次に示します。

19.2.2 環境のすべてのシステムでの管理エージェントのインストール

Oracle Management Agent (管理エージェント)は、Enterprise Manager Cloud Controlのコア・コンポーネントの1つで、Enterprise Managerシステムで管理対象外ホストを管理対象ホストに変換できます。管理エージェントはプラグインと連携することにより、管理対象ホスト上で実行されているターゲットをモニターします。

したがって、ホスト上で実行されているターゲットをモニターするにはいつでも、Oracle Management Agentをインストールして最初にこの管理対象外ホストを管理対象ホストに変換してから、モニタリングを開始するためにそのホストで実行中のターゲットを手動で検出する必要があります。

管理エージェントをインストールするには、Enterprise Manager Cloud Controlコンソールからアクセスできるホスト・ターゲットの追加ウィザード、またはEM CLIを使用します。管理エージェントを大量にデプロイするには、このウィザードまたはEM CLIの使用をお薦めします。

管理エージェントのインストールの詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド「Oracle Management Agentのインストール」の章を参照してください。

19.2.3 Javaベース・アプリケーションのトラブルシューティングに役立つJVMDのインストール

Java仮想マシン診断(JVMD)は、Enterprise Manager Cloud Controlの重要な機能の1つで、これを使用して管理者は本番環境におけるJavaアプリケーションのパフォーマンスの問題を診断することができます。問題を再現する必要性がなくなることにより、こうした問題解決に必要な時間が短縮されるため、アプリケーションの可用性とパフォーマンスが向上されます。JVMDはパフォーマンス・オーバーヘッドが最小限で、動的にデプロイできます(サーバーを再起動しません)。

JVMDをインストールするには、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド「JVM診断のインストール」の手順を使用します。

19.2.4 Webアプリケーションのトラブルシューティングに役立つRUEIのインストール

Webアプリケーションおよびサービスの利用は増え続けています。これには、マーケティング手段としてのインターネットの利用だけでなく、エクストラネットベースのサプライ・チェーンやバックオフィス統合、内部アプリケーションのイントラネット・デプロイも含まれます。明確に定義されたビジネス機能を実装したWebサービスの利用もますます増えています。RUEIは、これらすべてのデプロイ・シナリオの可用性およびパフォーマンスの測定、分析、改善のために設計されており、エンド・ユーザー・エクスペリエンスに関連する問題を切り分けることができます。これを実現するために、RUEIには、ネットワーク・トラフィックやADFサーバーからのエンド・ユーザー・データ収集や、JavaScriptブラウザ・インストゥルメンテーションを使用したエンド・ユーザー・データ収集を実行する機能が備わっています。つまり、RUEIはエンド・ユーザー・データ・モニタリング・ソリューションを提供します。

RUEIをインストールするには、RUEIのバージョンに対応するインストレーション・ガイドを使用します。

http://www.oracle.com/technetwork/apps-tech/realuserei-091455.html

注意:

RUEIのインストール後は、エンド・ユーザーのモニタリングに関連するほとんどのアクションをEnterprise Managerから実行できます。

19.2.5 複数層アプリケーションのトラブルシューティングに役立つBTMのインストール

アプリケーションの機能が拡張して複雑化が進むにつれ、そうしたアプリケーションでサポートされるビジネス・トランザクションをリアルタイムで把握することが不可欠になります。トランザクション管理において、IT組織は、トランザクションのステータスや状態の追跡、トランザクション・コンテンツに埋め込まれたビジネス・メトリックに関するレポート、トランザクション・エラーの管理など、重要な課題に取り組む必要があります。Oracle Business Transaction Management (BTM)は、トランザクションの可視性、ビジネスKPIモニタリング、プロアクティブな例外管理といった主要な分野に綿密に対応する機能を提供し、組織がこれらの課題を解決する際に役立ちます。

Oracle BTMによって、ビジネス・トランザクションの信頼性が増して業務の利益が上がるだけではなく、アプリケーション・インフラストラクチャの総所有コスト(TCO)が下がりIT部門にもメリットがあります。

BTMをインストールするには、BTMのバージョンに対応するインストレーション・ガイドを使用します。

http://docs.oracle.com/cd/E24628_01/nav/assoproducts.htm

19.3 アプリケーションのトラブルシューティングに役立つ環境の構成

この項では、トラブルシューティングに役立つ構成のオプションについて説明します。使用可能な構成オプションは環境にインストールされているソフトウェアによって異なります。たとえば、RUEIをインストールしていない場合はRUEIアプリケーションを作成できません。インストール・オプションの一覧は、表19-1「インストール・オプション」を参照してください。

19.3.1 環境のすべてのターゲットの検出

検出は、使用環境で管理対象外のホストおよびターゲットを識別するプロセスを意味します。ターゲットとは、Enterprise Manager Cloud Controlで管理およびモニター可能なホスト・マシン、データベース、Fusion Middlewareコンポーネントなどのエンティティです。問題のトラブルシューティングをできるだけ容易に行えるように、すべてのホストとターゲットがEnterprise Managerでモニターされるようにしてください。

Oracle Enterprise Manager Cloud Control管理者ガイドの説明に従い、Enterprise Managerを使用して環境のすべてのターゲットを検出します。


注意:

ターゲット(たとえばホスト)で障害が発生しても、そのターゲットが上記のように検出されていないと、問題の原因はEnterprise Managerコンソールにはまったく示されません。

19.3.2 環境へのJVMエージェントのデプロイ

Java仮想マシン診断(JVMD)は、Enterprise Manager Cloud Controlの重要な機能の1つで、これを使用して管理者は本番環境におけるJavaアプリケーションのパフォーマンスの問題を診断することができます。問題を再現する必要がないため、問題の解決に要する時間を削減できます。

JVMDエージェントは、ターゲットJVM (本番環境のWebLogic Serverを実行するJVM)にデプロイされます。リアルタイムのデータを収集してJVM診断エンジンに転送します。このデータはManagement Repositoryに格納され、収集された情報はモニタリングのためにEnterprise Manager Cloud Controlコンソールに表示されます。JVMDエンジンとJVMDエージェント(Oracle Management Servicesの組込みコンポーネント)間の通信は、セキュア(SSL)または非セキュア接続が可能です。

JVMDをインストールするには、Enterprise Manager Cloud Controlコンソールからアクセスできる「アプリケーション・パフォーマンス管理」ページを使用します。このページにアクセスするには、「設定」メニューからミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

JVM診断のインストールの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

19.3.3 複数層アプリケーションのトラブルシューティングに役立つコンポジット・アプリケーションの定義

コンポジット・アプリケーションによって、層ごとに一連のターゲットをグループ化することができ、異なる層で発生する問題を区別できるようになります。


注意:

コンポジット・アプリケーションは、複数の層(WebLogic Server、SOA Suite、Coherenceサーバーなど)を表すように定義することも、Webアプリケーション(WebLogic Serverおよびデータベース)を表すように定義することもできます。このため、様々なEnterprise Managerユーザーが様々な定義を作成して、環境に対する独自の視点を表すことができます。たとえば、アプリケーション管理者はDBAとは異なるコンポジット・アプリケーションを定義します。

コンポジット・アプリケーションの定義は、このガイドの「コンポジット・アプリケーション」の章で説明しています。

図19-1「サンプル環境」の環境を例として使用すると、次のようにコンポジット・アプリケーションを定義できます。

  1. Service 2のすべてのWebLogic ServerをEnterprise Managerのコンポジット・アプリケーションに追加します。(管理対象サーバーはコンポジット・アプリケーションのキー・メンバーになります)。

  2. サービス・ターゲットをコンポジット・アプリケーションに追加します。

  3. SLAルールを定義して、どのような場合にコンポジット・アプリケーションが停止していると見なされるかを決定します。

19.3.4 複数層アプリケーションのトラブルシューティングに役立つBTMトランザクションの定義

トランザクションは、1つの単位としてモニターおよび管理する一連のサービス操作です。通常、これはOracle Service Busを含む環境で定義されます。

トランザクションを定義する方法は、Enterprise Manager Business Transaction Managementオンライン・ヘルプで説明されています。

19.3.5 Enterprise Managerでの合成モニタリング・ビーコンの定義

合成モニタリング・ビーコンは、サービス・テストのモニター(主に異なる地理的位置からのサービスまたはビジネス機能のパフォーマンス測定)に使用されるターゲットです。

ビーコンの詳細は、Oracle Enterprise Manager Cloud Control管理者ガイドの「サービスの構成および使用」を参照してください。

19.3.6 Enterprise Managerでのしきい値の定義

定期的な(予測できる)間隔で、ターゲットに異なるワークロードが発生するモニタリング状況があります。このような状況では、静的なアラートしきい値では正確な結果が得られません。たとえば、日中はオンライン・トランザクション処理(OLTP)を実行していて、夜間にバッチ処理を実行するデータベースの正確なアラートしきい値は異なります。同様に、平日と週末など、期間が異なれば、データベースのワークロードは変わります。これらの2つの状況で、しきい値が固定された静的な値であれば、間違ったアラート・レポートが生成される可能性があります。

高度なしきい値を使用すると、適応(自己調整)または時間ベース(静的)のアラートしきい値を定義し管理できます。

適応しきい値は、ターゲットの測定された動作(メトリック)からの統計計算に基づくしきい値です。

時間ベースのしきい値は、ユーザー定義のしきい値で、ターゲットの変化するワークロードに対処するために日/週の異なる時間で使用されます。

しきい値の詳細は、Oracle Enterprise Manager Cloud Control管理者ガイドの「高度なしきい値管理」を参照してください。

19.3.7 Enterprise Managerでのコンプライアンス管理の設定

コンプライアンス管理では、構成、セキュリティおよび記憶域に関する企業のベスト・プラクティスについて、ターゲットおよびシステムのコンプライアンスを評価できます。これは、コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを定義、カスタマイズおよび管理することで実現します。また、コンプライアンス管理によって、ターゲットおよびシステムがコンプライアンスに対応するよう構成を変更する方法に関する情報が提供されます。コンプライアンス管理は、設定に対する自動ポリシー違反アラートにより、すべての層におけるセキュリティとパフォーマンスの維持に役立ちます。たとえば、ログ・レベル、JVMバージョンおよびパッチ・レベルで自動ポリシー違反アラートが保証されます。セキュリティに関する法的なコンプライアンスが必要な場合は、必要に応じてWebLogicセキュリティ技術導入ガイドライン(STIG)ルールを設定できます。

コンプライアンスの詳細は、Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイドの「コンプライアンスの管理」を参照してください。また、新しい機能である、多数のターゲット間での一貫性(統一性)を保証する構成ドリフトの詳細は、『Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイド』構成の管理に関する情報も参照してください。

19.3.8 Webアプリケーションのトラブルシューティングに役立つRUEIアプリケーションの作成

RUEIは様々なタイプのアプリケーションをモニターして、レポートのために各アプリケーションのデータを分けることができます。RUEIでは、モニター対象のサービスのセットに対応するアプリケーション、スイートまたはサービスを作成します。RUEIスイートという用語が使用されるのは、これらのアプリケーションが特定のOracle Enterpriseアーキテクチャ(Oracle E-Business Suite、Siebel、WebLogic Portalなど)に基づいている場合です。

このタスクを試行する前に、第19.2.4項「Webアプリケーションのトラブルシューティングに役立つRUEIのインストール」の説明に従ってRUEIをインストールしたことを確認します。

このソフトウェアをインストールしたら、次のタスクを実行してRUEIアプリケーションまたはスイートを作成します。

  1. ネットワークのタイミングをモニターする場合は、Oracle Real User Experience Insightインストレーション・ガイドの説明に従ってネットワーク・タップを設定する必要があります。ただし、タグベースのアプリケーションを作成する場合にはこの手順を省くことができます。このアプリケーションでjavascript (Browser JS Library)をWebテンプレートに挿入し、そのjavascriptがクライアント・ブラウザからイベントをレポートします。

  2. Oracle Real User Experience Insightインストレーション・ガイド「RUEIの構成」の説明に従ってRUEIの初期構成を実行します。

  3. ADFアプリケーションをモニターする場合は、ADF固有のタイミングがレポートされるRUEIのADFモニタリング・サービスを使用できます。詳細は、Oracle Real User Experience Insightインストレーション・ガイド「ADFモニタリングのためのRUEIの構成」を参照してください。

  4. モニター対象のコンポーネントに関連する具体的な情報は、RUEIのドキュメントを参照してください。たとえば、Oracle Access Managerを使用する環境をモニターする場合は、Oracle Real User Experience Insightインストレーション・ガイド「Oracle Access Managerの構成」を参照してください。

  5. Oracle Real User Experience Insightユーザーズ・ガイド「Webページの識別とレポート」および「スイートとWebサービスの使用」の手順を使用して、RUEIアプリケーションまたはスイートを作成します。


注意:

Enterprise Manager 13cでは、RUEIアプリケーション/スイートそれぞれに対応するエンド・ユーザー・サービス(EUS)という新しいサービス・レベル・ターゲットがあります。EUSは、RUEIアプリケーション/スイートと同じ名前が付けられ、ビジネス・アプリケーションを作成するために使用されます。詳細は、第17.7項「エンド・ユーザー・サービスのモニタリング」を参照してください。

19.3.9 RUEIサービス・レベル合意の定義

当初の要件では、RUEIレポートはRUEIユーザー・インタフェースのみで使用できます。RUEIデータをEMで使用できるようにするには、「RUEIまたはBTMシステムの登録」の説明に従ってRUEIをEMに接続する必要があります

プロシージャ・キー・パフォーマンス・インジケータおよびサービス・レベル合意は、ビジネス・ユーザーがプロセスをモニターして問題の発生時にアラートを受け取るための方法です。また、これらを使用すると、複雑な環境での問題のトラブルシューティングに役立つデータを収集することもできます。

RUEIでのKPIの定義方法の詳細は、Oracle Real User Experience Insightユーザーズ・ガイド「パフォーマンス・モニタリングの設定」を参照してください。

19.3.10 複数層アプリケーションのトラブルシューティングに役立つBTMエージェントのデプロイ

Oracle ManagementパックのコンポーネントであるBusiness Transaction Management (BTM)を使用すると、サービスとトランザクションのパフォーマンスをリアルタイムでモニターし、根本原因分析を実行して、ボトルネック、エラーおよび未完了のトランザクションを見つけることができます。

BTMを使用するには、ソフトウェアをインストールしてからBTMエージェントをデプロイする必要があります。トラブルシューティングの観点でBTMの最大のメリットは、複雑な環境で問題を引き起こしているミドルウェア・コンポーネントを切り分けるために役立つ情報が提供されることです。

BTMのインストール方法の詳細は、Oracle Business Transaction Managementインストレーション・ガイドを参照してください。オブザーバのインストール後はBTMが環境のトポロジを検出できるようになりますが、問題のトラブルシューティングに合せてトランザクションを手動で定義することができます。

19.3.11 Enterprise Managerでのビジネス・アプリケーションの作成

ビジネス・アプリケーションは論理アプリケーションを表すEnterprise Managerのターゲットであり、ユーザーにとっては管理の単位を定義するものです。ビジネス・アプリケーションはRUEIアプリケーションとBTMトランザクションで構成されます。Enterprise Manager Consoleを使用することにより、ユーザーはビジネス・アプリケーションを表示してRUEIおよびBTMのパフォーマンス・データや、アプリケーションがサポートしているインフラストラクチャ(アプリケーション・サービスが実行されているホストおよびサーバー)に関する情報にアクセスします。

ビジネス・アプリケーションの作成は、このガイドの「ビジネス・アプリケーションのモニタリング」の章で説明しています。

19.4 Enterprise Manager、BTMおよびRUEIを使用した問題の分析

Enterprise Manager、BTMおよびRUEIによって、インシデント、トランザクションおよびユーザー・エクスペリエンスの問題を分析するツールが提供されます。また、それらの方法は該当するドキュメント・セットで説明されています。ただし、この項ではこれらのツールすべてを一緒に使用して問題をトラブルシューティングする方法の要点を次のように示します。

  1. システムが多くのミドルウェア層で構成されている場合は、1つのミドルウェア層に問題を切り分けてください。

  2. 1つのミドルウェア層に問題を切り分けたら、Enterprise Managerを使用してさらに問題を切り分けて解決します。

たとえば、アプリケーションが単一の層で構成されている場合は、次のように表すことができます。

図19-3 単一層のトラブルシューティング

図19-3の説明が続きます
「図19-3 単一層のトラブルシューティング」の説明

アプリケーションが複数の層で構成されている場合は、次のように表すことができます。

図19-4 複数層のトラブルシューティング

図19-4の説明が続きます
「図19-4 複数層のトラブルシューティング」の説明

この項では、問題を分析する次のアプローチについて説明します。

19.4.1 ログ・ファイルを使用したインシデントの分析

環境の複雑さにかかわらず、Enterprise Managerではログ・ファイルのデータを使用してインシデントを迅速に分析できます。ほとんどのターゲットで次のようにします。

  1. 「エンタープライズ」メニューで「モニタリング」を選択し、さらに「ログ」を選択します。

  2. 「検索」をクリックし、分析するターゲットを選択します。

  3. 検索の基準を指定します。たとえば、最も詳しいログの場合は「トレース」を選択します。

  4. 「検索」をクリックして結果を表示します。

RUEIを使用している場合は、第17.6.5項「ログのモニタリング」を参照してください。


注意:

このリリースでは、ログ・ビューア機能を使用するためにJRFをデプロイする必要はありません。

19.4.2 ビジネス・アプリケーションを使用したインシデントの分析

第19.3.11項「Enterprise Managerでのビジネス・アプリケーションの作成」の説明に従ってビジネス・アプリケーションを作成した場合は、Enterprise Managerを使用して、RUEI、BTMおよびEnterprise Managerのすべてのモニタリング情報を1つのダッシュボードで分析できます。これには、問題の根本原因にドリルダウンする機能も用意されています。詳細は、このガイドの「ビジネス・アプリケーションのモニタリング」の章を参照してください。

図19-5 「ビジネス・アプリケーション」ダッシュボード

図19-5の説明が続きます
「図19-5 「ビジネス・アプリケーション」ダッシュボード」の説明

19.4.3 単一ミドルウェア層を含む環境でのインシデントの分析

この項では、単一ミドルウェア層でのインシデントを分析する方法を説明します。この層は、連動してサービスを提供する1つ以上のノードで構成されます。たとえば、次のものが含まれます。

  • 一連のWebLogic Server(Webサイトでは一般的なシナリオ)

  • 認証および認可サービスを提供するOracle Access Managerインストール

  • WebCenter Portal

ここで説明する手順を効果的に行うために、問題を特定のミドルウェア層に切り分けた、またはアプリケーションが単一ミドルウェア層で構成されていると仮定します。解決しようとしている問題の場所がはっきりしない場合は、第19.4.4項「複数ミドルウェア層を含む環境でのインシデントの分析」で説明するプロセスを使用します。

19.4.3.1 インシデント分析のためのEMダッシュボードのチェック

問題がレポートされた場合に最も単純なトラブルシューティング方法は次のとおりです。

  1. Enterprise Managerにログインします。

  2. ハードウェア、オペレーティング・システム、データベースまたはミドルウェア層に関連する問題についてダッシュボードを確認します。

  3. アイテムがハイライト表示されている場合は、クリックすると詳細が表示されます。

  4. 停止しているアイテムを再起動するか、Enterprise Managerによる提案に注意して問題を解決します。

Enterprise Managerでモニタリングしているターゲットのセットが非常に多いときには、この方法は実用的でない場合があります。ターゲットのサブセットのトラブルシューティングのために、タスクを管理しやすくするビジネス・アプリケーションまたはコンポジット・アプリケーションの作成を検討してください。

19.4.3.2 インシデントに影響されたページのRUEIを使用したチェック

Enterprise Manager 13cとRUEIを使用して、次のようにWebアプリケーションの問題をすぐに調べることができます。

  1. Enterprise Managerにログインします。

  2. トラブルシューティングするWebアプリケーションに関連付けられているエンド・ユーザー・サービスに移動します。「ターゲット」メニューから「サービス」を選択します。現在定義されているサービスがリストされます。エンド・ユーザー・サービスをフィルタ処理します。または、「サブサービス」タブをクリックして、ビジネス・アプリケーション・ホームページから「エンド・ユーザー・サービス」に移動することもできます。結果のリストに、「エンド・ユーザー・サービス」が含まれることがあります(ビジネス・アプリケーションにエンド・ユーザー・サービスが含まれる場合)。

  3. 関心があるエンド・ユーザー・サービスをクリックします。選択したエンド・ユーザー・サービスのホームページが表示されます。これは、図19-5のビジネス・アプリケーションのホームページによく似ています。このページでは、問題がすべてのページに影響しているか個々のページに影響しているかを判別できます

  4. 問題が個々のページのみに影響している場合は、他の方法(セッション診断など)を使用して根本原因を判別することができます。

19.4.3.3 JVMDを使用した問題の切分け

Enterprise Managerでは、「ビジネス・アプリケーション」のトランザクションを選択し、トランザクション・サマリー・ページを開くことにより、トランザクション操作のJVMD情報にアクセスできます。続いて、次のいずれかを実行します。

  • トポロジのダイアグラムでいずれかの操作ノードを右クリックし、コンテキスト・メニューからJVMD診断を選択します。

  • 操作表でいずれかの操作行を右クリックし、コンテキスト・メニューからJVMD診断を選択します。

詳細は、第16章「詳細実行情報の取得」を参照してください。

第21章「JVM診断の使用方法」の説明に従い、JVMDを使用して関連するログを表示することもできます。

19.4.3.4 しきい値とコンプライアンスを使用したインシデントの分析

しきい値とコンプライアンスの設定を事前に行った場合には、これらによってインシデント管理を実行する方法が提供されます。たとえば、問題がダッシュボード上のインシデントに対応していない場合はメモリーの問題を疑います。

  1. Oracle Enterprise Manager Cloud Control管理者ガイドで説明される手順を使用して、コンポーネント・メモリー使用量のしきい値を設定します。

  2. しきい値インシデントのタイミングとレポートされる問題に相関関係がある場合は、コンポーネントに割り当てるメモリーを増やしてみます。

  3. タイミングに相関関係がない場合は、問題がメモリーに関連するものではないと考えられるため、別の仮説を立てて新しいしきい値を設定し、プロセスを繰り返します。

19.4.4 複数ミドルウェア層を含む環境でのインシデントの分析

この項では、複数のミドルウェア層で構成される複雑な環境でのインシデントを分析する方法を説明します。各層は、連動してサービスを提供する1つ以上のノードで構成されます。たとえば、次のものが含まれます。

  • Oracle Access Managerが認証および認可サービスを提供するWebサイトをホストする一連のWebLogic Server

  • BPEL、Oracle Access ManagerおよびOracle SOA Suiteを実行するOracle Fusion Middleware環境

問題が含まれるミドルウェア層を見つけたら、第19.4.3項「単一ミドルウェア層を含む環境でのインシデントの分析」で説明するプロセスを使用します。

19.4.4.1 BTMを使用した層の切分け

この手順では、BTMにトランザクションを定義していると仮定します。BTMでトランザクションを定義していなくても、第19.4.4.3項「BTMの「依存性」タブを使用した層の切分け」の説明に従い、BTMを使用して問題をトラブルシューティングすることができます。ここで説明する方法の詳細は、このガイドの「サービスの検出とトランザクションの操作」の章を参照してください。

BTMを使用して層を切り分けるには、次の手順を実行します。

  1. 「ダッシュボード」ビューから「操作状態サマリー」を選択します。

  2. 上位10件のトランザクション・ダッシュボードで「最も遅い平均レスポンス時間」表を確認します。

  3. トランザクションを選択して詳細を表示します。「サマリー」サブタブに、トランザクションのトポロジが図として表示されます。

  4. 図に示されている参加サービスのいずれかにカーソルを置くと、そのサービスのスループット、エラーおよびレスポンス時間が表示されます。必要であれば、時間でフィルタ処理して特定の期間の詳細を表示します。

  5. パフォーマンスが最も低いサービスに注目し、第19.4.3項「単一ミドルウェア層を含む環境でのインシデントの分析」で説明した方法を使用して、問題をさらに切り分けます。

19.4.4.2 コンポジット・アプリケーションを使用したキー・メトリックのハイライト表示

この手順では、Enterprise Managerにコンポジット・アプリケーションを定義していると仮定します。コンポジット・アプリケーションを使用して層を切り分けるには、次の手順を実行します。

  1. 「ターゲット」メニューから「コンポジット・アプリケーション」を選択します。

  2. 関連するコンポジット・アプリケーションのステータスを確認し、SLAおよび署名サービスのステータスに注意します。

  3. パフォーマンスが最も低いコンポジット・アプリケーションに注目し、第19.4.3項「単一ミドルウェア層を含む環境でのインシデントの分析」で説明した方法を使用して、問題をさらに切り分けます。

19.4.4.3 BTMの「依存性」タブを使用した層の切分け

BTMでトランザクションを定義していなくても、BTMからトラブルシューティングの情報を取得することができます。

  1. ナビゲータで、「サービスからエンドポイントへ」ビューまたは「サービスから操作へ」ビューを選択します。

  2. タブ領域がまだ開いていない場合には、目的のサービスをダブルクリックしてタブ領域を開きます。開いている場合は、単に目的のサービスを選択します。

  3. 「依存性」タブを選択します。Business Transaction Managementによって、選択したサービスとそのサービスがやり取りしている他のサービスとの間の依存性が表示されます。矢印はトラフィック・フローを示します。その厚みで相対的なスループット・サイズが示されます。

  4. 表示されているサービスにカーソルを合わせると、Business Transaction Managementでそのコンポーネント・タイプを表示できます。

また、ナビゲータから「マップ」→「サービス・マップ」ビューを選択しても、サービスの依存性を表示できます。

19.5 Enterprise Managerを使用した問題の解決

Enterprise Manager (またはRUEIやBTM)を使用して問題を特定した後は、多くのケースで、Enterprise Managerを使用して問題解決に必要なタスクを実行できます。

19.5.1 構成ツールを使用した問題の解決

Cloud Controlでは、エンタープライズ全体のすべての管理対象ターゲットに関する情報が収集されます。収集された構成情報は、HTTPまたはHTTPSで管理リポジトリに定期的に送信され、Cloud Controlを介してエンタープライズ全体の最新の構成情報にアクセスできます。

Cloud Controlは、Enterprise Managerで認識されたすべての管理対象ターゲットについて収集された構成情報を表示、保存、追跡、比較、検索およびカスタマイズする機能を備えています。さらに、構成トポロジ・ビューアでは、ターゲットと他のターゲットの関係がビジュアルなレイアウトで示されます。たとえば、システムのメンバーとその相互関係を表示することで、システムの構造を判断できます。

また、新しい機能である、多数のターゲット間での一貫性(統一性)を保証する構成ドリフトの詳細は、『Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイド』構成の管理に関する情報も参照してください。

19.5.2 アプリケーション開発者またはDBAと連携したアプリケーション問題の解決

特定した問題の原因が組織内で作成されたコードにある場合は、開発者と連携してソリューションを提供する必要があります。たとえば、次の手順では典型的なシナリオについて説明します。

  1. アプリケーションWebページのロードに平均40秒かかるというチェックアウト・コードの問題が操作担当者によって識別されました(RUEIを使用)。

  2. 開発者は、開発環境で問題を再現できませんでしたが、RUEIを確認して問題の存在を受け入れました。

  3. 操作担当者と開発者が一緒にJVMDを使用して、問題の原因を切り分けます。

  4. 開発者がコードを変更し、操作担当者がKPIを設定してアプリケーションをモニターし、問題が再発した場合に見逃さないようにします。

同様に、データベースの問題が見つかった場合には、担当のDBAと連携して問題を解決することができます。

19.5.3 プロビジョニング・ツールを使用した容量問題の解決

一部の問題は、追加のリソースをプロビジョニングすることによって解決できます。Oracle Enterprise Managerではデータベースおよびミドルウェアの自動プロビジョニングが提供され、このタスクに役立ちます。Enterprise Managerを使用してプロビジョニングを実行する方法の詳細は、Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイドを参照してください。

追加ノードのプロビジョニングと追加メモリーのプロビジョニングが一般的な2つのシナリオです。追加ノードは、WebLogic ServerやOracle Real Application Clustersなどのサービスに追加できます。一部の問題は、追加のメモリーをプロビジョニングして追加の容量を提供することによって解決できます。追加メモリーは次の方法で提供できます。

  • 追加メモリーをJVMに割り当てることができます。

  • 追加メモリーを仮想マシンに割り当てることができます。

  • 追加の物理メモリーをサーバーに追加できます。