プライマリ・コンテンツに移動
Oracle® Enterprise Manager Cloud Control管理者ガイド
12c リリース5 (12.1.0.5)
B65081-16
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

24 サービスの構成および使用

この章では、サービスの概要と、Enterprise Managerを使用してサービスを構成および監視する手順を説明します。この章の内容は、次のとおりです。

24.1 サービスの概要

今日のビジネス・アプリケーションは重要で複雑なので、IT組織が高い基準と可用性でアプリケーションのサービス・レベルを監視して管理することが非常に重要になります。エンタープライズが直面する問題には、サービスの失敗やパフォーマンスの低下があります。これらのサービスは業務上の伝達を行う上で重要な役割を果すため、サービスを監視し、業務に影響を及ぼす前に問題を迅速に解消することはすべてのエンタープライズにとって重要です。

Enterprise Managerには、概要レベルから個々のコンポーネント・レベルまでのサービスを効率的に管理できる包括的な監視ソリューションが用意されています。サービスが停止するか、そのパフォーマンスが低下した場合、Enterprise Managerの診断ツールを使用すると、問題を迅速かつ効率的に解決して、問題の特定および解決に要する管理コストを大幅に削減できます。さらに、カスタマイズされたレポートには、一定期間にわたってアプリケーションの動作を分析できる有益なメカニズムが備えられています。Enterprise Managerは、ITインフラストラクチャ内の個々のコンポーネントのみでなく、これらのコンポーネントによってホストされるアプリケーションも監視します。このため、トップダウン方式を使用して、またはエンドユーザーの観点からビジネス機能をモデル化および監視できます。サービスが適切にモデル化されると、モデル化された機能またはアプリケーションの可用性、パフォーマンスおよび使用状況を正確に測定することができます。

24.1.1 Enterprise Managerのサービスの定義

サービスは、ユーザーの役に立つ機能を提供するエンティティとして定義されます。たとえば、サービスには、CRMアプリケーション、オンライン・バンキングおよび電子メール・サービスなどがあります。比較的簡単な形式のサービスは、DNS、LDAP、POP、FTP、SMTPなどのプロトコルでサポートされるビジネス機能です。

Enterprise Managerを使用して、エンタープライズ内で実行するビジネス機能またはアプリケーションを表す1つ以上のサービスを定義できます。これらのサービスを定義するには、共通のエンド・ユーザー機能をシミュレートする1つ以上のテストを作成します。システム・ターゲットに基づいた、またはシステムとサービス・テストの両方に基づいたサービスを定義することもできます。

サービスを事前に監視するサービス・テストを作成できます。これらのテストを使用して、重要なビジネス機能のパフォーマンスと可用性を測定し、問題があるときには通知を受け取り、一般的な問題を識別し、障害の原因を診断することができます。

要件に応じて様々なタイプのサービス・モデルを定義できます。作成可能なサービス・モデルのタイプを次に示します。

  • 汎用サービス: 汎用サービスとは、Enterprise Managerで作成できる単純なサービス・モデルです。重要なビジネス機能を表すサービス・テストを関連付けること、または関連するシステム・ターゲットを関連付けること(あるいはその両方)によって、1つ以上のサービス・モデルを定義できます。

  • 集約サービス: 複数のサービスを組み合せて、集約サービスを構成できます。集約サービスにおいて、個別のサービスはサブサービスと呼ばれます。ある集約サービスが、サブサービスとして使用されて、別の集約サービスを作成することもできます。

    集約サービスには、メンバー・サービス、システムまたはテストの少なくとも1つが含まれている必要があります。メトリックは、メンバー・サービス、システムまたはテストから昇格できます。

    要件に応じて他のサービス・モデルを定義できます。

24.2 サービスの作成

サービスを作成する前に、サービス管理の概念についてよく理解する必要があります。また、次のタスクも実行する必要があります。

  • 適切なサービス・テストおよびプロトコルを使用して、管理エージェントがサービスを監視できる必要がある場所を特定します。たとえば、サービスにHTTPベースのサービス・テストまたはIMAPベースのサービス・テストが含まれる場合、ネットワーク・アーキテクチャ内の管理エージェントはそれらのテストを許可します。管理エージェントがネットワーク・セキュリティ(ファイアウォール)およびネットワーク・ルーティングのガイドラインに従って、適切な場所にインストールされていることを確認する必要があります。

    ビーコン・ターゲットは、サービス作成前に管理エージェント上ですでに作成されている必要があることに注意してください。

  • Enterprise Managerターゲットとしてリストされるように、使用中のサービスのすべてのコンポーネントを検出します。

  • サービスのベースとなるシステムを定義します。

次のサービスが作成できます。

  • 汎用サービス - テスト・ベース: ATS、CalDAV、DNS、FTPなどのサービス・テストのタイプをベースにしたサービスを作成できます。

  • 汎用サービス - システム・ベース: システムまたは1つ以上のシステム・コンポーネントをベースにしたサービスを作成できます。

  • 集計サービス: 1つまたは複数のサブサービスからなる集計サービスで、テスト・ベースまたはシステム・ベースの汎用サービスのいずれかになります。

24.2.1 汎用サービス - テスト・ベースの作成

テスト・ベースの汎用サービスを作成するには、次の手順に従います。

  1. 「ターゲット」メニューから「サービス」を選択します。「サービス」のメイン・ページが表示されます。

  2. 「作成」メニューから、「汎用サービス - テスト・ベース」を選択します。「汎用サービスの作成: 一般」ページが表示されます。

  3. サービスの名前を入力し、監視する必要があるサービスのタイムゾーンを選択します。サービスの可用性とSLAの計算は、ここで選択したタイムゾーンに基づきます。「次」をクリックします。

  4. 「汎用サービスの作成: サービス・テスト」ページが表示されます。「テスト・タイプ」ドロップダウン・リストから、テストを選択します。

    図24-1 「汎用サービスの作成: サービス・テスト」ページ

    図24-1については周囲のテキストで説明しています。

    注意:

    ATSトランザクション」テスト・タイプを選択した場合、「ATS Zipアーカイブ」セクションに、ローカル・マシンまたはテスト・リポジトリからファイルをインポートできます。ただし後者を使用するには、そのテスト・リポジトリにテスト・スクリプトをアップロードしておく必要があります。テスト・リポジトリの使用方法の詳細は、第24.8項を参照してください。

  5. 選択したテスト・タイプに応じて、このページのその他のパラメータを入力し、「次」をクリックします。「汎用サービスの作成: ビーコン」ページが表示されます。

  6. 「追加」をクリックし、サービスを監視するためのビーコンを1つ以上追加します。主要なユーザー・コミュニティに戦略的に配置されたビーコンを使用して、ビーコンが配置された場所のサービスの可用性を予防的にテストすることをお薦めします。ビーコンが存在しない場合、新規のビーコンを作成する必要があります。詳細は、「ビーコンのデプロイと使用」を参照してください。


    注意:

    • サービス・テストを監視するには、管理エージェントから単一のビーコンのみを追加する必要があります。同じ管理エージェントから1つのサービス・テストに複数のビーコンを追加することはお薦めしません。

      ビーコンは、サービス・テストの監視、主に異なる地理的位置からのサービスまたはビジネス機能のパフォーマンス測定に使用されるターゲットです。このため、同じ管理エージェントから複数のビーコンを追加しても、値が追加されません。

    • キー・ビーコンとしてマークされているビーコンを使用して、サービスの可用性が判断されます。サービスは、1つ以上のサービス・テストが少なくとも1つのキー・ビーコンから正常に実行できる場合に、使用できます。

    • サービスを作成する前にビーコンを作成することをお薦めします。


  7. 「次」をクリックします。「汎用サービスの作成: 確認」ページが表示されます。ここまでに入力した情報を確認し、「終了」をクリックしてサービスを作成します。新しく作成したサービスが、メインの「サービス」ページに表示されます。

24.2.2 汎用サービス - システム・ベースの作成

システム・ベースの汎用サービスを作成するには、次の手順に従います。

  1. 「ターゲット」メニューから「サービス」を選択します。「サービス」のメイン・ページが表示されます。

  2. 「作成」メニューから、「汎用サービス - システム・ベース」を選択します。「汎用サービスの作成: 一般」ページが表示されます。

  3. サービスの名前を入力し、サービスのタイム・ゾーンを選択します。「次」をクリックします。「汎用サービスの作成: システム」ページが表示されます。サービスがベースにするシステムを選択します。システムはサービスをホストするために使用されるインフラストラクチャを指します。システムは、ホスト、データベース、その他のターゲットといったコンポーネントで構成されます。

  4. 「次」をクリックします。「汎用サービスの作成: 確認」ページが表示されます。ここまでに入力した情報を確認し、「送信」をクリックしてサービスを作成します。新しく作成したサービスが、メインの「サービス」ページに表示されます。

24.2.3 集約サービスの作成

集約サービスは、1つ以上のサービス(サブ・サービスまたはメンバー・サービス)で構成されます。サブサービスは、Enterprise Manager Cloud Controlで作成されるサービスです。集約サービスの可用性、パフォーマンスおよび使用状況は、サービスを構成する個々のサブ・サービスの可用性、パフォーマンスおよび使用状況に依存します。集約サービスを作成する場合は、少なくともシステムまたは1つ以上のサブ・サービスが関連付けられている必要があります。必要な場合は、サブ・サービスとシステムの両方を含めることができます。

集計サービスを作成するには、次の手順に従います。

  1. 「ターゲット」メニューから「サービス」を選択します。「サービス」のメイン・ページが表示されます。

  2. 「作成」メニューから「集約サービス」を選択します。「集計サービスの作成: 一般」ページが表示されます。

  3. 集計サービスの名前を入力し、監視するサービスのタイムゾーンを選択します。監視されたデータは、選択したタイムゾーンで表示されます。「次」をクリックします。

  4. 「集計サービスの作成: サービス」ページが表示されます。「追加」をクリックし、集計サービスに含めるメンバー・サービス(サブ・サービス)を1つまたは複数選択します。1つまたは複数のテスト・ベース、システム・ベースの汎用サービス、集計サービスを追加できます。「次」をクリックします。

  5. 「集計サービスの作成: システム」ページが表示されます。サービスがベースにするシステム・ターゲットを選択します。必須ではありませんが、システムとサービスを関連付けることをお薦めします。根本原因分析などの機能は、キー・システム・コンポーネントが正しく定義されていることに依存します。

集約サービスの作成後、構成サブ・サービスの追加または削除、可用性定義の変更、およびパフォーマンスあるいは使用状況メトリックの追加または削除ができます。


警告:

集約サービスからサブサービスを削除すると、集約サービスのパフォーマンス、使用状況およびビジネスの各メトリックがサブサービスのメトリックに基づく場合に影響を受けることがあります。


24.3 サービスのモニタリング

サービスが定義されると、サービスのステータスを監視でき、可用性履歴、パフォーマンス、有効化されたSLA、トポロジなどを表示できます。この項の内容は次のとおりです。

  • 汎用サービス/集計サービス・ホームページ

  • 「パフォーマンス・インシデント」ページ

  • SLAダッシュボード

  • テストの要約

  • トポロジ

24.3.1 「汎用サービス / 集計サービス」ホームページの表示

サービスのパフォーマンス、可用性、使用量の概要を表示するには、メインのサービスのページで選択されたサービスをクリックします。選択されたサービスのホーム・ページが表示されます。次のリージョンが含まれます。

  • 一般: この領域では、現在のサービスのステータスと、過去24時間の可用性(%)を表示できます。また、可用性がサービスのテストか、システムのどちらをベースにしているかを表示することもできます。集計サービスの場合、可用性はサブ・サービスをベースにすることもできます。「可用性履歴」のグラフに、サービスが利用可能だった期間、停止したタイミング、ブラックアウト・ステータスになったタイミングなどが表示されます。

  • コンポーネントの可用性: この領域には、サービスのテストまたはサービスがベースにしているシステム・コンポーネントの可用性を表示します。キー・コンポーネントまたはテストのみを表示するには、「キー・テストのみを表示」チェック・ボックスを選択します。

24.3.2 「パフォーマンス/インシデント」ページの表示

このページでは、サービスに対して定義されたパフォーマンスおよび使用状況メトリックのグラフを表示し、ドリルダウンして追加のメトリック詳細を表示できます。

パフォーマンス・メトリックは、各リモート・ビーコンに対してサービス・テストがどの程度適切に実行されているかの判別に役立ちます。一般に、ローカル・ビーコンは、Webアプリケーション・ホストに対してローカルなので、非常に有効で一貫したレスポンス時間を備えています。リモート・ビーコンは、アプリケーションのエンドユーザーの実際のレスポンス時間を反映したデータを提供します。

使用状況メトリックは、サービスに対するユーザーの要求またはワークロードの測定に使用されます。使用状況メトリックは、サービスをホストする基礎となるシステム・コンポーネントの使用状況に基づいて収集されます。特定のコンポーネントの使用状況を監視することも、一連のコンポーネントの平均値、最小値および最大値を統計的に計算することも可能です。

「インシデントと問題」領域では、サービスに関連付けられたインシデントまたは問題を表示できます。

24.3.3 SLAダッシュボードの表示

このページでは、このサービスに対して有効になっているSLAのリストが表示されます。SLAごとに、次の情報を参照できます。

  • SLAの現在のステータスとそのSLO、およびの現在SLO期間のサービス・レベル値。

  • 「履歴」列には、過去1週間のSLAのステータスを表示します。

  • 「違反」列には、そのSLOの実績値、残存値およびSLA違反の許容回数の合計が表示されます。

24.3.4 テストの要約の表示

「テスト・レポート・ダッシュボード」には、特定のサービスで有効なすべてのテストのリストが表示されます。過去24時間のテストの実行履歴とは別に、テスト情報の最も失敗したステップ(ビーコン・レベルとテスト(集計)レベルの両方)も表示されます。

過去24時間のトランザクションに要した合計時間の傾向も表示されます。また、特定のトランザクションの実行のステップ・メトリックの内訳も表示されます。

このページでは、すべてのテストの概要をパフォーマンスおよび問題別に表示し、ビーコンごとの個々の実行にドリルダウンして、実行のトランザクション結果にドリルダウンします。

このページを使用する方法

デフォルトでは、このページアクセスすると、有効なすべてのテストが全体的なレベルで表示されます。最も失敗したステップ情報が表示され、すべての実行ビーコンでテストの最も失敗したステップが表示されます。

ツリー表でテスト・ノードを展開すると、ビーコン・レベルの実行サマリーが表示され、テストの実行履歴(過去24時間)と、最も失敗したステップの情報が表示されます。

ツリー表のテスト・ノードをクリックすすると、トランザクション診断領域がパージの下部に表示されます。親ノード(テスト(全体)ノード)が選択されている場合、下部の診断領域に、実行が成功したすべてのビーコンの集計データが表示されます。

この領域の左側の部分には、トランザクションの合計時間の傾向(過去24時間)が表示され、時間セレクタのスライダが表示されます。このスライダの目的は、トランザクション/トランザクション期間を選択して、ステップ診断領域を表示することで、このリージョンは、下部の領域の右側の部分を占めます。

24.3.5 サービス・トポロジの表示

トポロジ・ビューアには、サービスのコンポーネントがグラフィカルに表示されます。トポロジ・ビューアは、すべての従属コンポーネントとサブ・サービスをアイコンで表示し、それらの相互関係をリンクで示します。システム・コンポーネントの場合、キー・コンポーネントのみが表示されます。

次の内容を実行できます。

  • サービスとそのサービスに依存する他のサービス、システム・キー・コンポーネントなどの関係の表示。サービスの可用性を決定するすべての要素がEnterprise Manager Cloud Controlのトポロジ・ビューアに表示されます。

  • 「根本原因分析」によって特定されたサービス失敗の原因を表示します。潜在的な根本原因と停止中のターゲットがハイライトされます。コンポーネント間のハイライトされたリンクを選択して、サービス失敗の原因の詳細を表示します。詳細は、「根本原因分析について」を参照してください。SMARTS社のネットワーク・アダプタをインストールし構成している場合、この「トポロジ」ページには、障害のあったサービスのネットワーク・ステータスも表示されます。ネットワーク・マネージャ・アダプタのプラグインの詳細は、「SMARTSネットワーク・アダプタについて」を参照してください。

トポロジ・ビューアの詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

24.3.6 サブ・サービス

集約サービスは、1つ以上のサービス(サブ・サービスまたはメンバー・サービス)で構成されます。サブサービスは、汎用のテストベースまたはシステム・ベースのサービスです。集約サービスの可用性、パフォーマンスおよび使用状況は、サービスを構成する個々のサブ・サービスの可用性、パフォーマンスおよび使用状況に依存します。

このページには、集約サービスの一部であるすべてのサブサービスが表示されます。サブサービスごとに、サービスのステータス、キー・コンポーネント、インシデントなどが表示されます。

24.4 サービスの構成

サービスを作成すると、サービスの可用性定義、システムとサービスの関連付け、パフォーマンスと使用状況のメトリックの定義などが行えます。この項の内容は次のとおりです。

  • 可用性定義

  • 根本原因分析の構成

  • システム・アソシエーション

  • サービス・テストとビーコン

  • テストの要約

  • テストのモニタリング設定

  • 使用状況メトリック

  • パフォーマンス・メトリック

  • サービス・レベル・ルールの編集

24.4.1 可用性定義 (汎用サービスおよび集計サービス)

サービスの可用性は、ユーザーがいつでもサービスを使用できるかどうかを示します。何をもって可用性とするかの基準は、アプリケーションによって異なります。たとえば、カスタマ・リレーションシップ・マネジメント(CRM)・アプリケーションでは、可用性はユーザーがアプリケーションに正常にログオンして売上レポートにアクセスできることを意味します。電子メール・アプリケーションの場合は、ユーザーがアプリケーションにアクセスして電子メールを送受信できることが可用性です。

可用性を定義するサービスをクリックし、「サービス・ホーム」ページにナビゲートします。「汎用サービス」メニューから、「管理」、「可用性」の順に選択します。サービスの可用性は、次のことに基づいて判別できます。

  • サービス・テスト: エンド・ユーザーの重要な機能の可用性によってサービスの可用性が決定される場合、このオプションを選択します。このような重要な機能の例として、電子メールへのアクセス、販売レポートの生成、オンライン銀行業務トランザクションの実行などがあります。サービス・テストを定義する場合、ビジネス・プロセスの重要な機能に最も適したプロトコルと、ユーザー・コミュニティの場所に適したビーコンの場所を選択します。

    標準プロトコルを使用して1つ以上のサービス・テストを定義し、1つ以上のサービス・テストをキー・テストとして指定できます。キー・テストは、様々なユーザー・コミュニティ内で1つ以上のキー・ビーコンによって実行されます。また、「キー・サービス・テスト」チェック・ボックスを選択し、サービス・テストがキー・テストであると指示することもできます。サービスの可用性計算には、キー・サービス・テストのみが使用されます。次にビーコンを選択し、キー・テストの実行およびサービスの可用性判断に使用できます。定義に応じて、すべてのキー・サービス・テストが成功しているか、または1つ以上のキー・サービス・テストが成功している場合にサービスが利用可能とみなされます。ビーコンの詳細とその作成方法については、「ビーコンのデプロイおよび使用」を参照してください。

    どの場合にサービスを利用可能とするべきかを指定できます。

    • すべてのキー・サービス・テストが成功(デフォルト)このオプションをお薦めします。

    • 1つ以上のキー・サービス・テストが成功


    注意:

    サービス・テストは、1つ以上のキー・ビーコンによって実行できる場合に使用可能であるとみなされます。キー・ビーコンがない場合、サービス・テストのステータスは不明になります。

  • システム: サービスの可用性は、サービスをホストしている基盤のシステムまたは選択したシステム・コンポーネントに基づいている場合もあります。可用性が選択したシステム・コンポーネントに基づく場合、サービスの実行に対して重要なコンポーネントを選択し、サービスの可用性を決定するために使用するキー・コンポーネントとして1つ以上のコンポーネントを指定します。可用性の定義に応じて、1つ以上またはすべてのキー・コンポーネントが起動して実行されているかぎり、サービスは使用可能であると判断されます。

    どの場合にサービスを利用可能とするべきかを指定できます。

    • すべてのキー・コンポーネントが稼働中(デフォルト)

    • 1つ以上のキー・コンポーネントが稼働中

    また、1つ以上のコンポーネントを、サービスの可用性計算に使用されるキー・システム・コンポーネントとしてマークすることもできます。キー・システム・コンポーネントは、可能性のあるサービス失敗の根本原因特定で使用されます。詳細は、「根本原因分析の構成」を参照してください。

  • サブ・サービス: 集約サービスの場合、可用性は、サブ・サービスの可用性にも基づきます。すべてのサブサービスまたは単一のサブサービスの可用性に基づいて、可用性を判別するかを指定できます。

24.4.2 根本原因分析の構成

根本原因分析(RCA)を使用して、一連のイベントをフィルタ処理し、システム、サービスまたはアプリケーションのより高レベルな問題の原因を特定できます。RCAは、根本原因に見えるが、問題の実際の根本原因の副作用または兆候でしかない明らかなパフォーマンスの問題を排除するために役立ち、問題領域を簡単に識別できます。RCAの結果は、現在停止しているサービスのホームページまたは「トポロジ」ページ上から確認できます。トポロジ・ページでは、サービス、システムおよびコンポーネントの依存関係がグラフィカルに表示されます。トポロジ・ページでは、サービスの失敗の原因であるターゲットが強調表示されます。

RCAを実行する前に、次の内容を選択できます。

  • サービス失敗時に自動的に実行されるようにツールを構成します。

  • 「分析モード」(デフォルト)を「手動」に変更してRCAを無効化します。

  • サービスのコンポーネント・テストおよび個々のテストのしきい値を定義します。

根本原因分析を構成する手順は、次のとおりです。

  1. サービスのホームページで、「監視構成」をクリックします。

  2. 「監視構成」ページで、「根本原因分析の構成」をクリックします。

  3. 現在のモードが「自動」に設定されている場合は、「モードを手動に設定」をクリックしてRCAを無効化します。分析を手動で実行するように選択すると、サービスが停止状態の場合に「分析の実行」を選択して、いつでもサービスのホームページから分析を実行できます。現在のモードが「手動」に設定されている場合、サービスおよびそのコンポーネントの状態が変化した際に「モードを自動に設定」をクリックしてRCAを有効化します。

  4. 管理するキー・コンポーネント用の表の「コンポーネント・テスト」列のリンクをクリックします。これにより、コンポーネント・テスト・ページ上で、コンポーネント・テストの追加、削除または編集を行うことで、サービスのキー・コンポーネントを管理できます。サービスが停止したときは、キー・コンポーネントをドリルダウンして、根底にある問題を確認できます。コンポーネント・テストの定義の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。


    注意:

    RCAを無効化し、自動モードに設定を戻した場合、RCAにはこれまでの履歴結果は格納されず、今後、参照用としていずれの履歴も表示されません。

24.4.2.1 根本原因分析の最大限の活用

根本原因分析(RCA)は、サービスに関連する大量のデータをフィルタ処理し、サービスの可用性に影響する最も重要なイベントの発生を識別できることから、大きな価値をもたらします。Enterprise Managerで独自のサービスを構成する場合、RCAを最大活用することを考慮および計画して、サービスを定義することが重要です。

RCAを最大活用する上で最初に考慮が必要な項目は、他のサービスまたはシステム・コンポーネントに対してサービスが持つ一連の依存性です。タスクを達成するためにサービスが使用するすべてのシステム・コンポーネントを必ず識別してください。キー・コンポーネントを省略し、サービスが失敗した場合、RCAでは、そのコンポーネントを可能性のある原因として識別できなくなります。逆に、実際にはサービスが依存していないコンポーネントをサービス定義に含めると、RCAで、そのコンポーネントがサービス失敗の原因として誤って識別される場合があります。

サービス依存性を構築する場合、Enterprise Managerでサポートされている集約サービスの概念を利用することを念頭に置いてください。これにより、それぞれ独自の一連の依存性を持つ、より小さなサブサービスにサービスを分割できます。RCAはサブサービス(依存しているサービス)のステータスのみではなく、サブサービスが依存するシステム・コンポーネントまたはサービスも同様に考慮します。

RCAを最大限活用する上で次に考慮が必要な項目は、コンポーネント・テストの使用です。サービスが依存するシステム・コンポーネントを定義する際、これらのコンポーネントには、コンポーネント自体が失敗しなくても、サービス失敗となる部分が存在する場合があることを考慮します。コンポーネント・テストにより、ターゲット自体のステータスのみでなく、その主要部分のステータスもRCAでテストできます。

RCAシステムでは、キー・コンポーネントで使用可能なメトリックに基づくコンポーネント・テストを作成できます。これには、コンポーネント用に作成したユーザー定義メトリックが含まれるため、サービスが失敗した場合は、そのコンポーネントの各部分をRCAによってきわめて柔軟にテストできます。RCAは2つのモードで実行するように構成できます。サービスの失敗に基づき自動的に実行されるか、手動で実行するように構成することができます。監視対象のサービスの予想されるサービス・レベル合意のパーセントに基づいてモードを決定できます。予想されるサービス・レベル合意のパーセントが高い場合、自動モードを選択し、発生する可能性のあるエラーや失敗の根本原因を、容易に検知できるようにする必要があります。

24.4.3 システム・アソシエーション

システムとは、相互に機能することでアプリケーションをホスティングする、一連のインフラストラクチャ・コンポーネント(ホスト、データベース、アプリケーション・サーバーなど)を指します。たとえば、電子メール・アプリケーションはデータベース、リスナー、アプリケーション・サーバー、およびこれらのコンポーネントが常駐するホストによってホスティングされています。

サービスを定義すると、システム内のコンポーネント間の接続または相互関係を論理的に表すため、コンポーネント間の関連付けを指定できます。たとえば、関連付けを定義し、データベースとリスナー間の関連を示すことができます。これらの関連付けはシステムのトポロジ・ビューアに表示されます。一部のデータ・センターには、1つのアプリケーションまたはサービス専用のシステムがあります。その他のデータ・センターのシステムは複数のサービスをホスティングします。データ・センターのセットアップ方法に基づいて、1つまたは複数のサービスをシステムに関連付けできます。

このページでは、このサービスをホストするために使用するEnterprise Managerシステムを選択できます。次の内容を実行できます。

  • システムの追加または選択

  • 選択したシステムの変更または削除

システムを選択してから、1つ以上のシステム・コンポーネントをキー・コンポーネントとしてマークします。このキー・コンポーネントは、サービスの実行に不可欠です。このキー・コンポーネントを使用して、サービスの可用性の判断や、サービスの障害の原因の識別を行います。

24.4.4 モニタリング設定

各サービスについて、頻度(アプリケーションに対してサービスがトリガーされる頻度を決定)およびパフォーマンスしきい値を定義できます。サービスがそのパフォーマンスしきい値を超えると、アラートが生成されます。

メトリックおよびしきい値を定義するには、「汎用サービス」メニューから、「管理」「テストの監視設定」の順に選択します。「メトリックとポリシー設定」ページが表示されます。「監視設定」リンクをクリックします。「監視設定 - しきい値」ページが表示されます。

  • 表示方法 - メトリック、ビーコン - この表示で、「ビーコンのオーバーライドの追加」をクリックすると、1つ以上のビーコンのデフォルトのしきい値を上書きできます。この場合、上書きのないビーコンにのみデフォルトのしきい値が使用されます。サービスに追加される新しいビーコンは、デフォルトのしきい値を使用します。「メトリックの追加」をクリックして、1つ以上のメトリックを追加します。

  • 表示方法 - ビーコン、メトリック - この表示で、「デフォルト」アイコンをクリックすると、特定のメトリックの「編集」および「表示」モード間の切替えができます。「編集」モードでは、メトリックのパラメータを変更できます。特定のビーコンのメトリックのパラメータを変更することもできます。「表示」モードでは、メトリックのデフォルト・パラメータが使用されます。

    これらの手順とは別に、Webトランザクション用にステップおよびステップ・グループのレベルでもメトリックを定義できます。次のいずれかの表示を選択できます。

    • 表示方法: ステップ、メトリック、ビーコン: この表示で、「ビーコンのオーバーライドの追加」をクリックすると、1つ以上のビーコンのデフォルトのしきい値を上書きできます。この場合、上書きのないビーコンにのみデフォルトのしきい値が使用されます。新しくWebトランザクションに追加されるビーコンには、デフォルトのしきい値が使用されます。「メトリックの追加」をクリックして、1つ以上のメトリックのしきい値を定義します。サービス・テストについて、「データの粒度」プロパティの値が「トランザクション」に設定されている場合にのみインシデントが生成されます。Webトランザクションのプロパティの詳細は、Enterprise Managerのオンライン・ヘルプのサービス・テストの作成または編集、Webトランザクションのヘルプ・ページを参照してください。

    • 表示方法: ステップ、ビーコン、メトリック: この表示で、「デフォルト」アイコンをクリックすると、特定のメトリックの「編集」および「ビュー」モード間の切替えができます。「編集」モードでは、特定のビーコンのメトリックのパラメータを変更できます。「表示」モードでは、メトリックのデフォルト・パラメータが使用されます。「データの粒度」プロパティの値が「ステップ」に設定されている場合のみ、インシデントが生成されます。

デフォルトの収集頻度および収集プロパティを定義するには、「監視設定」ページの「収集の設定」タブをクリックします。次の内容を実行できます。

  • すべてのビーコンのデフォルトの収集頻度を指定します。特定のビーコンの収集頻度を上書きするには、「ビーコンのオーバーライドの追加」をクリックします。

  • 1つ以上のビーコンの収集プロパティおよび対応する値を指定します。

収集間隔およびパフォーマンスしきい値の定義の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

24.4.5 サービス・テストとビーコン

サービス・テストを追加し、これらのサービス・テストを実行する1つ以上のビーコンを指定できます。サービス・テストを追加、または既存のサービス・テストを変更するには、監視構成ページの「サービス・テストとビーコン」リンクをクリックします。「サービス・テストとビーコン」ページが表示されます。ドロップダウン・リストからテスト・タイプを選択し、サービス・テストを作成できます。

24.4.5.1 追加のサービス・テストの定義

プロトコルおよびビーコンの場所に基づき、異なるタイプのサービス・テストを作成できます。「サービス・テストとビーコン」ページで、次のことを実行できます。

  • サービスに1つ以上のサービス・テストを追加します。テスト・タイプを選択し、「追加」をクリックします。定義可能なテスト・タイプには、ATS、FTP、Webトランザクション、DNS、SOAPなどがあります。

  • サービス・テストを作成した後は、これを有効にする必要があります。サービス・テストが有効でない場合は、いずれのビーコンによっても実行されません。1つ以上のサービス・テストをキー・テストとして定義できます。これらのキー・テストは、サービスの可用性およびパフォーマンスの監視に使用されます。有効なサービス・テストのみ、キー・テストとして指定できます。サービス・テストをキー・テストとして設定するには、ページの下部にある「可用性定義」リンクをクリックします。

  • ビーコンを作成、追加または削除します。ビーコンの場所を識別する場合、企業内のネットワーク、またはE-Businessに重要なインターネット上の場所を選択します。通常、これらはエンドユーザーが存在する場所です。たとえば、ビジネスがカナダでホストされ、顧客がアメリカ合衆国にいる場合、アメリカ合衆国のホスト・コンピュータにインストールされたビーコンを使用して、アプリケーションの可用性およびパフォーマンスを測定します。

  • サービス・テストの作成後、「サービス・テストの検証」をクリックして、検証します。「ステータス」アイコンは、サービス・テストのステータス(キー・ビーコンが正常に実行できるかどうか)を示します。サービスにキー・ビーコンが定義されていない場合、他のビーコンがサービス・テストを実行していてもステータスは不明になります。「ステータス」をクリックすると、ステータス履歴ページに移動します。


    注意:

    • SOAP(シンプル・オブジェクト・アクセス・プロトコル)サービス・テストの定義中にアクセスするWSDL URLが企業のイントラネット外にある場合は、$OMS_HOME/sysman/config/emoms.propertiesファイルにプロキシ設定を追加する必要があります。

      たとえば、www-myproxy.myco.comをプロキシとして設定するには、次のように値を指定します。

      proxyHost=www-myproxy.myco.com

      proxyPort=80

      dontProxyFor=myco.com,mycorp.com

      proxyUserproxyPwdproxyRealmおよびproxyPropsEncryptedプロパティが、認証されたプロキシの構成に使用されます。プロキシ設定を変更した後、変更が適用されるようにするには、すべてのOMSを再起動する必要があります。

    • Formsトランザクション・テスト・タイプはEnterprise Manager 12cで非推奨になりました。前のリリースで作成されたFormsトランザクションは引き続き使用できますが、新たなFormsトランザクション・テスト・タイプは作成できません。汎用サービス・ターゲットを作成し、OATS EBS/Formsロード・テスト・スクリプトを使用してATSトランザクションを作成する必要があります。この「ATS」テスト・タイプを使用して、Oracle Formsアプリケーションを監視します。

    • 「Webトランザクション」テスト・タイプはメンテナンス・モード専用です。Webアプリケーションを監視するには、ATSロード・スクリプトを作成し、ATSトランザクション・テスト・タイプを使用してWebアプリケーションを監視することをお薦めします。詳細は、「OATSロード・スクリプトを使用したATSサービス・テストの作成」を参照してください。


    異なるタイプのサービス・テストの作成の詳細は、Enterprise Managerオンライン・ヘルプで説明しています。この章では、例としてATSテスト・タイプの作成について説明しています。

24.4.5.2 ビーコンのデプロイと使用

ビーコンは、管理エージェントがサービスをリモートで監視できるターゲットです。ビーコンは、常に1つ以上のサービスを監視できます。


注意:

ビーコンを作成する前に、Oracle Beacon 12.1.0.2以上のプラグインがデプロイされていることを確認する必要があります。

1つ以上のサービス・テストを実行するビーコンを作成するには、次の手順に従います。

  1. 「設定」メニューから、「ターゲットの追加」「ターゲットの手動追加」の順にクリックします。

  2. ターゲットの手動追加ページで、「ターゲット監視プロパティを指定して非ホスト・ターゲットを追加」オプションを選択します。

  3. 「ターゲット・タイプ」ドロップダウン・リストから「ビーコン」を選択し、「手動追加」をクリックします。

  4. ビーコンの作成ページが表示されます。

    図24-2 ビーコンの作成ページ

    ビーコンの作成
  5. 次の詳細を入力します。

    • 名前: 作成するビーコンの名前です。

    • エージェント: ビーコンが実行する管理エージェントを選択します。

    • プロキシ情報: ビーコンがファイアウォールを介してサービスにアクセス中の場合は、プロキシ・サーバー設定を次のように指定する必要があります。

      • プロキシ・ホストおよびポート: ビーコンと通信を行うプロキシ・サーバーのホストの名前。

      • プロキシ認証レルム: プロキシ・サーバーで資格証明の検証(Basic認証スキームとDigest認証スキーム)に使用される認証レルム

      • プロキシ認証ユーザー名: プロキシ・サーバー認証に使用されるユーザー名(完全修飾名)

      • プロキシ認証パスワード: プロキシ・サーバー認証で一緒に使用されるパスワード

    • メッセージIDのリクエスト・ヘッダーの有効化: WebトランザクションおよびHTTP Pingサービスのテストの実行時に発行されるHTTPリクエストに追加ヘッダーを含めるには、このチェック・ボックスを選択します。これにより、Real User Experience Insight (RUEI)は、WebトランザクションおよびHTTP Pingのテストを監視できます。

    • Webトランザクション: Windowsエージェントの場合、 Webトランザクションの再生を行うブラウザの起動時に使用するアカウント資格証明を指定します。


    注意:

    「サービス」メニューから「ビーコンの作成」オプションを起動できます。「サービス機能」メニューで、「ビーコン」を選択し、「追加」をクリックして、ビーコンの作成ページを起動します。

  6. 「作成」をクリックして、ビーコンを作成し、「ビーコンのホームページ」に戻ります。これでビーコンを使用してサービス・テストを監視できるようになりました。

  7. 「汎用サービス」メニューで、「管理」「サービス・テストとビーコン」の順に選択します。ビーコンのリストと、有効化されたサービス・テストのリストが表示されます。

  8. 監視するサービス・テストを選択し、「ビーコン」表から作成したビーコンを選択します。それがキー・ビーコンかどうかが示されます。

  9. 「サービス・テストの検証」をクリックして、選択したビーコンごとにサービス・テストを実行します。

24.4.5.3 ビーコンの構成

この項では、その他のビーコン関連の構成タスクについて説明します。

  • ビーコンのSSL証明書の構成: HTTPS URLを使用してSecure Sockets Layer(SSL)でURLを監視する際にビーコンを使用する場合、そのURLが存在するWebサイトで使用されている認証局を認識するようにビーコンを構成する必要があります。

    ポート・チェッカ・テストでSSLオプションを使用するには、管理エージェントの監視ウォレットに証明書を追加する必要がある場合があります。追加証明書を追加するには、次の手順を実行します。

    1. Base64encoded X.509 (.CER)形式の、b64SiteCertificate.txtファイル内の証明書を取得します。(ファイル名は構成により異なる可能性があります)。ファイルの内容の例を次に示します。

      ------BEGIN CERTIFICATE--------------
      MIIDBzCCAnCgAw...
      ...... base 64 certificate content .....
      ------END CERTIFICATE-----------------
      

      ファイルは管理エージェントのホーム・ディレクトリに<AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txtファイルとして保存されています。

    2. b64InternetCertificate.txtファイルが作成されていない場合は、エージェントのコア・ディレクトリとインスタンス・ディレクトリに作成します。

      <AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txt 
      <AGENT_BASE>/core/12.1.0.2.0/sysman/config/b64InternetCertificate.txt 
      
    3. 両方のb64InternetCertificate.txtファイルの末尾に、Base64encoded X.509証明書を追加します。BEGIN行とEND CERTIFICATE行の両方を含めます。

    4. 管理エージェントを再起動します。

  • 専用ビーコンの構成: エージェントのビーコン機能には、内部Java VMを使用する必要があります。Java VMの使用により、エージェントの仮想メモリー・サイズを数100MB増加できます。メモリーの制約のため、専用ホスト上で稼働するエージェント上でのみ、ビーコンを作成することをお薦めします。所定のビーコンで多数のテスト(毎分数百回)を実行する場合は、専用ホスト上へのそのビーコンのエージェントのインストールもお薦めします。専用ハードウェアを最大限に利用するには、エージェントの$ORACLE_HOME/sysman/config/emd.propertiesファイルを次のように編集します。

    applicationmetadataquota: 各アプリケーション領域に対するディスクの割当てバイト数

    • ThreadPoolModel=LARGEプロパティを設定します。これにより、エージェントで多数のスレッドを同時に実行できるようになります。

    • useAllCPUs=TRUEプロパティを設定します。これにより、複数のCPU上でエージェントを同時に実行できるようになります。

    • applicationMetadataQuota_BEACONプロパティは、ATSのzipファイルを格納するために使用できる合計サイズを指定します。ATSのzipファイルを使用する場合、またはビーコンに小規模なATSのzipファイルを多数構成する必要がある場合、applicationMetadataQuota_BEACONプロパティには大きな値を指定する必要があります。

    • @ このプロパティは、ビーコンが次のものの格納に使用できる合計サイズを指定します。

      @ ATS zipファイル。ユーザーが大規模なATS zipファイルを使用する予定の場合や、

      @ ビーコンに小規模なATS zipファイルを多数構成する必要がある場合は、このプロパティを

      @ 適宜増やす必要があります。

    • agentJavaDefinesプロパティに-Xms512m -Xmx1024mを追加します。これにより、Java VMのヒープ・サイズを1024MBに増加できます。

  • ビーコンのWebプロキシの構成: ネットワーク構成によっては、Webプロキシが使用されるようにビーコンを構成する必要がある場合があります。ビーコンのWebプロキシを構成するには、「すべてのターゲット」ページでビーコンを検索します。構成するビーコンを選択し、「構成」をクリックします。Webプロキシのプロパティを入力します。たとえば、ビーコンのWebプロキシとしてwww-proxy.example.comを設定するには、次のように値を指定します。

    Proxy Host: www-proxy.example.com
    Proxy Port: 80
    Don't use Proxy for: .example.com,.example1.com
    

    注意:

    Siebelサービス・テストとWebトランザクション(ブラウザ)サービス・テストは同一のマシン上では再生できません。

24.4.5.4 OATSロード・スクリプトを使用したATSサービス・テストの作成

Oracle Application Test Suite(OATS)を使用して、Openscriptトランザクション・サービス・テストを定義できます。このテストを使用して、Openscriptロード・テスト・スクリプトを使用したビーコン・アプリケーション・トランザクションの監視を有効にできます。OpenscriptはOATSのコンポーネントで、web/HTTP、Oracle EBS/Forms、Oracle Fusion/ADF、Siebel, Adobe Flexなど、様々なタイプのWebトランザクションを記録および再生するための拡張機能を提供します。

ATSロード・スクリプトを使用して、次のことができます。

  • アプリケーションのライフサイクル管理の一部として、本番アプリケーション・トランザクション監視用にATSテスト・スクリプトを再使用します。

  • 次のことによりビーコンの機能が拡張されます。

    • HTTPやOracle Formsアプリケーションなどのプロトコルやアプリケーション・タイプが1つのフローに混在する、複雑なアプリケーション・フローのサポート。

    • Siebelアプリケーション監視に基づくプロトコルのサポート。

    • データバンク・サポートの提供。

    • Openscriptから拡張されたスクリプトおよびデバッグ機能の組込み。

    • Enterprise Managerの更新なしでの最新のスクリプト・モジュールおよび機能の追加。

ATSサービス・テストの作成には、次の内容が含まれます。

  • Openscriptをダウンロードするには、http://www.oracle.com/technetwork/oem/app-test/index-084446.htmlにアクセスしてください。

  • インストーラを起動して、次の手順に従い、Openscriptをインストールします。

  • 次の手順に従い、新しいATSトランザクション・スクリプトを記録します。

    • Openscriptを起動し、「ファイル」メニューから「新規」を選択します。

    • 作成するスクリプトのタイプを選択し、「次へ」をクリックします。作成できるスクリプト・タイプには、Adobe Flex、Oracle Fusion / ADF、Siebel、Database、Java Code Script、Web/HTTPなどがあります。

    • スクリプトが保存される場所を選択し、スクリプト名を入力して、「終了」をクリックします。

    • Viewメニューで、「OpenScriptプリファレンス」を選択して記録プリファレンスを設定します。

    • レコード・カテゴリHTTPプリファレンスの順に選択します。「記録モード」「Web」から「HTTP」に変更します。これによりスクリプトが正しく再生されます。

    • 「スクリプト」メニューから「レコード」を選択します。記録を開始すると、ブラウザが自動的に開きます。

    • 記録を開始するWebページをブラウザにロードします。ページ・オブジェクト、アクションおよびナビゲーションを記録するWebサイトにアクセスします。ページのナビゲーションが終了したら、ブラウザを閉じて、「停止」をクリックします。

    • 「スクリプト」メニューで「再生」を選択し、スクリプトが適切に記録されたことを確認します。再生ペインに再生されているアプリケーション・フローを監視します。メッセージ・ログ・ペインにエラーや障害が発生していないことを確認します。スクリプトを保存します。

  • スクリプトが記録されたら、「ファイル」メニューから「スクリプトのエクスポート」を選択します。

    • スクリプトを保存する場所を指定します。スクリプトはレジストリまたはワークスペースに保存できます。

    • スクリプトの名前を入力し、「終了」をクリックします。スクリプト・バンドル(.zip)が作成されます。スクリプト・バンドルは自己完結していることを確認してください。「自己完結Zipファイルの作成」を参照してください。


    注意:

    スクリプト・ファイルが非常に大きい場合、「記録されたデータ」オプションはオフにしてください。

  • Enterprise Managerにログインし、スクリプト・バンドルをアップロードして、ATSサービス・テストを作成します。詳細は、「ATSサービス・テストの作成」を参照してください。

OATSの詳細は、Oracle® Functional Testing OpenScriptユーザーズ・ガイドを参照してください。

24.4.5.4.1 自己完結Zipファイルの作成

zipファイルは自己完結で、次の内容を含んでいることを確認する必要があります。

  • <txn name>.jwg: 実行エンジンで実行される、コンパイル済の実行可能スクリプトを含むアーカイブ・ファイル。

  • script.java: 実際のスクリプトJavaソース・ファイル。

  • <script name>-descriptor.xml: ステップ階層を示す。

  • script.xml: データバンクの変数を示す。

  • modules.properties: エンジンに必要な内部モジュールを示す。

  • Assets.xml: データバンク・ファイル、サブ・スクリプト・オブジェクト・ライブラリなどを含む、ルート・スクリプトにより使用される依存するリソースを示す。

  • データバンク・ファイル: 様々な変数値の代入時にスクリプトにより使用されるデータバンク・ファイル。

  • オブジェクト・ライブラリ: ユーザー定義のオブジェクト識別ルールおよび名前を含むライブラリ。これは機能テスト・スクリプトにのみ適用されます。

  • 依存スクリプト: 他のスクリプトをコールできるスクリプト。

24.4.5.4.2 ATSサービス・テストの作成

ATSサービス・テストを作成するには、次の手順に従います。


注意:

コマンドライン・ユーティリティ(EM CLI)から、リポジトリで使用可能なサービス・テストを使用してATS Testインスタンスを作成し、カスタマイズする方法は、『Oracle Enterprise Managerライフサイクル管理ガイド』を参照してください。

  1. 「ターゲット」メニューから「サービス」を選択し、「作成」メニューから「汎用サービス - テスト・ベース」を選択します。

  2. サービスの名前を入力して、タイム・ゾーンを選択します。

  3. 「次」をクリックします。汎用サービスの作成: 可用性ページで、「サービス・テスト」を選択します。

  4. 「汎用サービスの作成: サービス・テスト」で、「ATSトランザクション」として「テスト・タイプ」を選択します。

  5. サービス・テストの名前、説明、および収集頻度を入力します。

  6. 「ATS Zipアーカイブ」リージョンで、ATS Zipアーカイブのインポート元を指定します。インポート元には次を指定できます。

    • ローカル・マシンから: 「参照」をクリックし、アップロードするzipファイルをローカル・マシンから選択します。

    • テスト・リポジトリから: テスト・リポジトリ内のzipファイルを選択し、「続行」をクリックします。詳細は、「テスト・リポジトリの使用」を参照してください。

    「続行」をクリックします。アップロードされたzipファイルに基づいて、「ATS Zipアーカイブ」および「変数」セクションに移入されます。

  7. ATSサービス・テスト・ページに戻り、次の内容を指定できます。

    • 使用オプション: 必要な使用オプションを選択して、スクリプト変数値を構成できます。トランザクション中に記録された値またはデータバンクのいずれかを使用できます。データバンクは、同じスクリプトの複数の反復に対して様々な入力値を指定するためにATSスクリプトが参照できる外部CSVファイルです。たとえば、ログイン・スクリプトはlogin_credential.csvという名前のデータバンク・ファイルを使用して、反復のたびに異なるログイン資格証明を指定できます。

      次のいずれかを選択できます。

      • 記録した値の使用: トランザクションの再生時に、ビーコンはスクリプトの記録された値を使用します。

      • EMテスト・プロパティの値の使用: データバンク列に値を指定できます。これらの値はスクリプトの再生中にビーコンにより使用されます。各変数に同じ値が使用される場合、これは有用です。変数がテスト・プロパティとして定義されている場合、その値はスクリプト・バンドルまたはデータバンク・ファイルを変更する必要がなく、容易に変更できます。

      • すべてのデータバンク・レコードをループ: トランザクションの再生時に、ビーコンはスクリプトの各行を移動します。たとえば、最初の反復はすべてのデータバンクの最初の行を使用します。2番目の反復はデータの2行目を使用します(次も同様)。

    • 暗号化パスワード: ATS Openscriptを構成しており、(Openscript表示ファイル、「OpenScriptプリファレンス」、「汎用」、「暗号化」を使用して)スクリプトデータを暗号化する場合は、スクリプトを作成するときにATS Openscriptで指定したものと同じ暗号化パスワードを入力し、ビーコンがスクリプトを適切に再生できるようにする必要があります。

    • デフォルト再生オプション: ビーコンでATSスクリプトを再生するための、デフォルトの再生オプション。

    • 追加再生オプション: 追加の再生オプションを指定する必要がある場合、ここで指定できます。

24.4.5.4.3 ATSサービス・テストの再生の問題のトラブルシューティング

ビーコンの領域割当てが枯渇すると、ビーコンがATSスクリプトに記録された値を再生できず、次のエラーが表示される場合があります。

ビーコンの同期化はエージェントに必要なファイルを転送しませんでした。エージェントのログを確認してください。ファイル <directory>

この問題に対処するには、emd.propertiesファイルのapplicationMetadataQuotaエージェント・プロパティに高い値を設定する必要があります。デフォルト値は500MBですが、大規模なファイルが複数アップロードされる場合はこの値を増やす必要があります。プロパティの値を変更したら、管理エージェントを再起動する必要があります。

注意:

  • ATSファイルは/EMSTATE/sysman/ApplicationState/beaconディレクトリにあります。

  • ファイルの命名規則: <Txn guid>_<beacon guid>.zip

  • ATS関連のログ(gcagent.loggcagent_error.logemagent.nohup)は、EMSTATE/sysman/logフォルダにあります。

24.4.5.4.4 データバンクとパラメータ化

記録されたスクリプト入力をパラメータ化し、データ駆動型テスティングを実行できます。パラメータ化できる入力の例には、ユーザー名、ログイン・ページでのパスワード、検索フィールドに入力されたデータ、記録されたナビゲーションまたはユーザー・アクションなどが含まれます。

スクリプト入力のパラメータ化にデータ・ソースとしてデータバンクを使用できます。データバンクは、スクリプト・パラメータに対する入力を指定する、1つ以上の外部カンマ区切り値(CSV)またはテキスト(TXT)ファイルです。複数のデータバンク・ファイルを1つのスクリプトにアタッチすることができ、ユーザーは、スクリプト再生中にOpenScriptでデータを割り当てる方法を指定できます。

external.csvファイルからデータ入力値を選択し、変数値にデータバンクからの値を入力できます。フィールド名は、ファイルの先頭行にカンマ区切り(スペースなし)で指定します。フィールド・データは、2行目以降にカンマ区切り(1行に1レコード、カンマ前後のスペースはなし)で指定します。次に例を示します。

FirstName,LastName,Mail,Phone
John,Smith,JohnS@company.com,x993
Mary,Ellen,MaryE@company.com,x742

データバンク・レコードを使用するには、次の手順に従います。

  1. スクリプト・プロジェクトを開くか、作成します。

  2. アセット・スクリプト・プロパティのスクリプトで使用するデータバンクを構成します。

  3. データバンク・レコードを使用するスクリプト・ノードを選択します。

  4. 「スクリプト」メニューを選択した後、「追加」サブメニューから「その他」を選択します。

  5. 「一般」ノードを開いて、次のデータバンク・レコードの取得を選択します。「OK」をクリックします。

  6. レコードを取得するデータバンク・ファイルを指定するデータバンクの別名avitekを選択します。

  7. 「OK」をクリックします。「GetNextDatabankRecord:databank alias」ノードがスクリプトに追加されます。Javaコード・ビューでは、次に示すように、getDatabank("データバンクの別名").getNextDataBankRecord()メソッドがスクリプト・コードに追加されます。

    getDatabank("avitek").getNextDatabankRecord();

スクリプトで使用するデータバンクを構成した後、データバンク・ファイルを特定のスクリプト・パラメータにマップできます。データバンク・フィールドをスクリプト・パラメータにマップするには、次の手順に従います。

  1. [4] Oracle WebLogic ServerのMedical Record Sample Applicationスクリプト・ツリー・ノードを展開します。

  2. usernameInputパラメータを右クリックして、「変数の置換」を選択します。変数の置換ウィンドウが開き、データバンクのフィールド名がリストされます。

  3. 「ユーザー名」フィールドを選択し、「終了」をクリックします。パラメータ値は二重中カッコで囲まれたデータバンク変数{{db.avitek.Username,fred#@golf.com}}に変更されます。

  4. passwordInputパラメータを右クリックして、「変数の置換」を選択します。変数の置換ウィンドウが開き、データバンクのフィールド名がリストされます。

  5. 「パスワード」フィールドを選択し、「終了」をクリックします。パラメータ値は二重中カッコで囲まれたデータバンク変数{{db.avitek.Password,weblogic}}に変更されます。

  6. スクリプトを保存します。

データバンクの設定の詳細は、Oracle® Functional Testing OpenScriptユーザーズ・ガイドを参照してください。

ビーコン固有のデータバンク・ファイルの追加

ビーコン固有のデータバンク・ファイルを追加するには、emcliコマンドupload_ats_test_databank_fileを使用します。このコマンドの形式は次のとおりです。

emcli upload_ats_test_databank_file -name=<service_name> -type=<service_type> -testname=<test_name> -testtype=<test_type> -databankAlias=<databank alias> -input_file=databank:<input_file> -beaconName=<beacon_name>

24.4.5.4.5 URLのパラメータ化

スクリプト内のURLに使用する変数を作成できます。スクリプトのベースURLを変更する必要がある場合、URLをパラメータ化すると、新しいURLを使用するようにスクリプトを短時間で再ベースライン化できます。

URLをパラメータ化するには、次の手順に従います。

  1. スクリプトを記録したら、「ツール」メニューから「URLのパラメータ化」を選択します。

  2. パラメータ化するURLを選択し、そのURLに使用する変数の名前を入力します。「次」をクリックします。

  3. 変更するURLのインスタンスを指定するチェック・ボックスを選択するか、または選択を解除します。「終了」をクリックします。

  4. Javaコード・ビューで、次に示すように、getVariables().set("variable name", "value",scope);メソッドがinitialize()セクションのスクリプト・コードに追加されます。

    getVariables().set("myServerVar", "http://myServer.com",
    Variables.Scope.GLOBAL);
    
  5. スクリプトの他のURLをパラメータ化するには、これらの手順を繰り返します。

24.4.5.4.6 成功または失敗の検証

TreeViewおよびCodeViewからテキスト一致を実行できます。たとえば、Googleの検索ウィンドウで文字列「hello」を入力した場合、テキスト一致は次のようになります。

web.document("/web:window[@index='0' or @title='Google']/web:document[@index='0']").assertText("MatchText", "hello", Source.DisplayContent, TextPresence.PassIfPresent, MatchOption.Exact);

Source - enum - (Html,Display Content)

Html - Raw Html including Tags

Display Content - Html without tags

MatchOption - Not Case Sensitive

  • Exact - sensitive: ソース文字列の任意の部分に一致。たとえば、入力されたテキストがabcdefの場合、abcと入力すると、文字列は一致します。

  • ExactEntireString: 正確なソース文字列と一致。

  • RegEx - Not Case Sensitive: ソース文字列およびサブ文字列に一致。たとえば、入力されたテキストがabcdefの場合、a.*dと入力できます。

  • RegExEntireString: ソース文字列全体にのみ一致。たとえば、入力されたテキストがabcdefの場合、a.*fと入力できます。

  • Wildcard - wildcard pattern: ソース文字列およびサブ文字列に一致。たとえば、入力されたテキストがabcdefghijklmの場合、a?c*fと入力できます。

  • WildcardEntireString: ソース文字列全体に一致。たとえば、入力されたテキストがabcdefghijklmの場合、a*mと入力できます。

24.4.5.4.7 ビーコンのオーバーライドの使用

ビーコンのオーバーライド機能を使用して、異なるビーコンで実行しているテスト用に異なる変数値を指定できます。次の手順を実行します。

  1. スクリプトをデータバンク化します。

  2. EMテスト・プロパティの使用オプションを選択します。

  3. 次のように、sensitiveまたはnon-sensitiveの値を指定してビーコンを定義します。

Databank_Alias>."<COLUMN_NAME>"="VALUE",<Databank_Alias>."<COLUMN_NAME>"="VALUE",...

次に例を示します。

FusionCredentials."host"="fs-aufsn4x0cxf",FusionCredentials."hostlogin"="login-aufsn4x0cxf",FusionCredentials."username"="faadmin",FusionCredentials."password"="fusionfa1"

24.4.5.4.8 データバンク・ファイルの更新

ATSテスト・スクリプトを更新するには、次の手順に従います。

  1. 「汎用サービス」メニューで、「管理」「サービス・テストとビーコン」の順に選択します。

  2. 「サービス・テスト」表で、「ATSトランザクション」テスト・タイプを選択し、「編集」をクリックします。

  3. 「ATS Zipアーカイブ」リージョンで、「ダウンロード」をクリックします。ダウンロードされる場所を選択して「OK」をクリックします。

  4. .csvファイルをスプレッドシート・エディタを使用して編集し、変更内容を保存します。

  5. Enterprise Managerにログインし、ATSトランザクション・テスト・ページにナビゲートします。

  6. 「ATS Zipアーカイブ」リージョンで、「アップロード」をクリックして、更新されたファイルをアップロードします。

24.4.5.4.9 RUEI統合用のSLMヘッダーの使用

ATSサービスのRUEIにより監視される場合、x-oracle-slm-message-idリクエスト・ヘッダーをAdditional Playback Optionsフィールドに指定する必要があります。その書式はname1:value1;name2:value2;name3:value3です。

たとえば、x-oracle-slm-message-id: bcn=<beacon_name>; svc=<service_name>;test=<test_name>;step={{@getTopLevelStepName())}}のようになります。

24.4.6 パフォーマンス・メトリック

パフォーマンス・メトリックは、サービスのパフォーマンスの測定に使用されます。サービス・テストが、このサービスに対して定義されている場合、そのサービス・テストの実行の結果行われるレスポンス時間の測定値が、サービスのパフォーマンス・メトリックの基準として使用されます。もう1つの方法として、基礎となるシステム・コンポーネントからのパフォーマンス・メトリックを使用してサービスのパフォーマンスを判断できます。

パフォーマンス・メトリックは、各リモート・ビーコンに対してサービス・テストがどの程度適切に実行されているかの判別に役立ちます。一般に、ローカル・ビーコンは、Webアプリケーション・ホストに対してローカルなので、非常に有効で一貫したレスポンス時間を備えています。リモート・ビーコンは、アプリケーションのエンドユーザーの実際のレスポンス時間を反映したデータを提供します。

次の内容を実行できます。

  • サービス・テスト用のパフォーマンス・メトリックを追加できます。メトリックを選択後、次の内容を選択できます。

    • 1つのビーコンからのメトリック値を使用します。サービスのパフォーマンスがある特定の場所のパフォーマンスに基づくようにする場合に、このオプションを選択します。

    • 複数のビーコン間のメトリックを集計します。複数の場所のパフォーマンスを考慮する場合に、このオプションを選択します。このオプションを選択した場合、次の中から適切な集計関数を選択する必要があります。

      表24-1 ビーコン集計関数

      関数 説明

      Maximum

      すべてのビーコン間で集計されたデータからのメトリックの最大値が使用されます。すべてのビーコン間で最もパフォーマンスの低いものを測定するには、この関数を使用します。

      Minimum

      すべてのビーコン間で集計されたデータからのメトリックの最小値が使用されます。すべてのビーコン間で最もパフォーマンスの高いものを測定するには、この関数を使用します。

      Average

      メトリックの平均値が使用されます。すべてのビーコン間で平均的なパフォーマンスを測定する場合に、この関数を使用します。

      Sum

      メトリック値の合計が計算されます。各ビーコン間のすべてのレスポンス時間の合計を計算する場合に、この関数を使用します。



      注意:

      Webトランザクションを構成する場合、ソース(トランザクション、ステップ・グループまたはステップ)を指定できます。この選択に基づいて、追加するメトリックが、トランザクション、ステップ・グループまたはステップのレベルで適用可能になります。

  • サービスをホストする基礎となるシステム・コンポーネントのパフォーマンス・メトリックを追加します。ターゲットのメトリックを選択後、次の内容を選択できます。

    • 特定のコンポーネントからメトリックを使用します。サービスのパフォーマンスがある特定のシステム・コンポーネントのパフォーマンスに基づくようにする場合に、このオプションを選択します。このオプションを選択すると、「ルール・ベース・ターゲット・リスト」を選択できます。

    • 複数のコンポーネント間のメトリックを集計します。複数のコンポーネント間のパフォーマンスを考慮する場合に、このオプションを選択します。このオプションを選択した場合、適切な集計関数を選択する必要があります。

      表24-2 システム集計関数

      関数 説明

      Maximum

      すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。

      Minimum

      すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。

      Average

      すべてのコンポーネント間のメトリックの平均値が使用されます。

      Sum

      すべてのコンポーネント間のメトリックの値の合計が計算されます。



      注意:

      システムが削除されると、そのシステムに関連付けられているパフォーマンス・メトリックは収集されません。

  • 定義済のパフォーマンス・メトリックを編集します。サービス・テストベースのパフォーマンス・メトリックの場合は、メトリック値の計算に使用されるビーコン関数を変更できます。システムベースのパフォーマンス・メトリックの場合は、ターゲット・タイプ、メトリック、および集計関数を使用するかどうかの設定を変更できます。また、メトリックのクリティカルしきい値および警告しきい値も変更できます。

  • 定義済のパフォーマンス・メトリックを削除します。


注意:

集約サービスにパフォーマンス・メトリックを定義すると、次の操作が可能です。
  • 単一のサブ・サービスからのパフォーマンス・メトリックを追加します。

  • 複数のメトリックの統計による集計を指定します。

メトリックを選択した後、インシデントのトリガーに使用されるしきい値を設定したり、必要がなくなったメトリックを削除できます。


24.4.6.1 ルール・ベース・ターゲット・リスト

ルール・ベース・ターゲット・リストは、システム・ベースのパフォーマンス・メトリックおよびシステムの直接メンバーに適用可能です。選択したシステム・コンポーネントを照合するルールを定義できます。ユーザー指定のルールに一致するシステム・コンポーネントは、メトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で追加されると、このコンポーネントもメトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で削除されると、このコンポーネントは、メトリック評価プロセスに参加しません。定義するルールは次のものに基づきます。

  • すべて(すべてのシステム・コンポーネント)

  • 次を含む(指定された基準を含む任意のコンポーネント)

  • 次で始まる(指定された基準で始まる任意のシステム・コンポーネント)

  • 次で終わる(指定された基準で終わる任意のシステム・コンポーネント)

  • 次と等しい(指定された基準に一致する任意のシステム・コンポーネント)

24.4.6.2 静的ベースのターゲット・リスト

この場合、選択される依存ターゲットがメトリック評価に参加し、選択されないターゲットは含まれません。

24.4.7 使用状況メトリック

使用状況メトリックは、サービスに対するユーザーの要求の測定に使用されます。使用状況メトリックは、サービスをホストする基礎となるシステム・コンポーネントの使用状況に基づいて収集されます。特定のコンポーネントの使用状況を監視することも、一連のコンポーネントの平均値、最小値および最大値を統計的に計算することも可能です。たとえば、IMAPサーバーに依存する電子メール・サービスを定義する場合、IMAPサーバーの「合計クライアント接続」メトリックを使用して、この電子メール・サービスの使用状況を表すことができます。使用状況メトリックは、システムと関連付けられたサービスに対してのみ定義できます。次の内容を実行できます。

  • 使用状況メトリックを追加します。ターゲットのメトリックを選択後、次の内容を選択できます。

    • 特定のコンポーネントからメトリックを使用します。特定のコンポーネントの使用状況を監視する場合に、このオプションを使用します。

    • 複数のコンポーネント間のメトリックを集計します。複数のコンポーネント間の使用状況の統計を計算する場合に、このオプションを使用します。このオプションを選択した場合、適切な集計関数を選択する必要があります。

      表24-3 集計関数 - 使用状況メトリック

      関数 説明

      Maximum

      すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。

      Minimum

      すべてのコンポーネント間のメトリックの最小値が、サービスの使用状況メトリック値として使用されます。

      Average

      すべてのコンポーネント間のメトリックの平均値が使用されます。

      Sum

      すべてのコンポーネント間のメトリックの値の合計が計算されます。


  • 定義済の使用状況メトリックを編集します。

  • 定義済の使用状況メトリックを削除します。

システム・ターゲットからのメトリックのみを使用状況メトリックとして追加できることに注意してください。テストからのメトリックは使用状況を示さないため、使用状況メトリックとして追加できません。


注意:

集約サービスに使用状況メトリックを定義すると、次の操作が可能です。
  • 単一のサブ・サービスからの使用状況メトリックを追加します。

  • 複数のメトリックの統計による集計を指定します。

使用状況メトリックを選択した後、インシデントのトリガーに使用されるしきい値を設定したり、必要がなくなったメトリックを削除できます。


ルール・ベース・ターゲット・リスト

ルール・ベース・ターゲット・リストは、システム・ベースのパフォーマンス・メトリックおよびシステムの直接メンバーに適用可能です。選択したシステム・コンポーネントを照合するルールを定義できます。これにより、評価のパフォーマンス・メトリックを促進できます。ユーザー指定のルールに一致するシステム・コンポーネントは、メトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で追加されると、このコンポーネントもメトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で削除されると、このコンポーネントは、メトリック評価プロセスに参加しません。定義するルールは次のものに基づきます。

  • すべて(すべてのシステム・コンポーネント)

  • 次を含む(指定された基準を含む任意のコンポーネント)

  • 次で始まる(指定された基準で始まる任意のシステム・コンポーネント)

  • 次で終わる(指定された基準で終わる任意のシステム・コンポーネント)

  • 次と等しい(指定された基準に一致する任意のシステム・コンポーネント)

24.5 トランザクション・レコーダの使用

一連のユーザー処理およびナビゲーション・パスを自動的に記録する直感的な再生レコーダを使用して、トランザクションを記録できます。トランザクションを相互に再生し、データ・センターの内部または外部のいずれに存在するかを確認し、Webアプリケーションのすべての層におけるレスポンス時間の発生の詳細を理解して素早く診断できます。

トランザクションを記録するには、コンピュータにトランザクション・レコーダをインストールする必要があります。トランザクション・レコーダは、トランザクションの再生およびトレースにも使用されます。トランザクション・レコーダは、これらの処理の初回実行時にEnterprise Manager Grid Controlサーバーからダウンロードされます。トランザクション・レコーダを使用するには、コンピュータにいくつかのMicrosoftライブラリがインストールされている必要があります。インストール中にこれらのライブラリが存在しない場合、Microsoftのサイトから自動的にダウンロードおよびインストールが行われます。これらのファイルをダウンロードするには、ご使用のコンピュータがインターネットにアクセスできることを確認します。インストールの完了後、変更を適用するには、コンピュータを再起動する必要がある場合があります。

24.6 サービス・レベル合意の設定および使用

サービス・レベル合意(SLA)は、指定した期間における予測されるサービス品質に関する、サービス・プロバイダと顧客との間の契約です。SLAは、異なるビジネス・カレンダおよび異なるサービス期間用に、提供するサービス・レベルを定義する、1つまたは複数のサービス・レベル・オブジェクト(SLO)で構成されます。SLAを満たしているかどうかは、基礎となるSLOの評価に基づきます。サービス・レベル・インジケータ(SLI)は、SLOを測定および定量化できます。SLOには、1つ以上のSLIを使用できます。

SLOは提供されるサービス・レベルの目標を定義します。SLOは想定可能な個別のサービス・レベル・インジケータ(SLI)の論理グループです。たとえば、SLOはユーザーがサービスを使用可能な時間の割合や、応答時間またはボリュームを単位としてサービスがどの程度実行されているかなどを定義できます。サービス・レベル・インジケータ(SLI)は、定量化可能なパフォーマンスおよび使用状況メトリックで、サービスの品質を評価するのに使用できます。

SLAを作成するには、次の手順に従います。

  1. EM_ADMINISTRATORロールを持つユーザーでEnterprise Managerにログインします。

  2. 「ターゲット」メニューから「サービス」を選択します。

  3. リストで「汎用サービス」ターゲットをクリックします。「サービス・ホーム」ページが表示されます。

  4. 「汎用サービス」メニューで、「サービス・レベル合意」「構成」の順に選択します。サービス・レベル合意構成ページが表示されます。

  5. このページには、選択したサービスに対して定義されたすべてのSLAのリストが表示されます。このリストからSLAを選択し、「サービス・レベル合意の詳細」表に詳細を表示します。SLAを作成することも、既存のSLAのコピーを作成(Create Like)することもできます。

  6. 「サービス・レベル合意」リージョンで、「作成」をクリックします。サービス・レベル合意ページが表示されます。

    図24-3 サービス・レベル合意の作成: サービス・レベル合意の構成

    サービス・レベル合意の構成

    次の詳細を入力します。

    • SLAの名前と説明。

    • SLAが作成されている顧客の名前。

    • SLAのライフサイクル・ステータス。SLAの作成中は、定義ステージング内に存在します。ライフサイクル・ステータスの詳細は、「SLAのライフサイクル」を参照してください。

    • 「SLA期間」を指定します。これは、SLAがコンプライアンスに対して決定および評価される契約上の期間です(四半期、月次、週次SLAなど)。「選択」アイコンをクリックして、「毎月」、「毎週」、または「毎日」を選択します。SLAが評価される頻度と、SLAが評価される元のデータを入力します。SLAが評価されると、SLAの目標はリセットされます。

      たとえば、SLAの評価期間を「毎月」に、「頻度」を12に、日付を09/01/12に指定した場合、SLAはその日に評価され、その後、連続して11回(10月、11月、というように)評価されます。

    • SLA合意期間を指定します。これは繰り返しSLAが有効な期間の、「開始」および「終了日」です。ここで「終了日」を指定しないと、SLAの有効期限は「無期限」になります。

    • SLOはサービスにスケジュールされた計画停止またはブラックアウトのため、評価されないときがあります。「サービス・レベル合意の評価オプション」リージョンで、「サービス・レベル目標値評価にブラックアウト時間(計画ダウンタイム)を含める」チェック・ボックスを選択し、ブラックアウト時間をSLO評価に含めるかどうかを指定します。次のいずれかを選択できます。

      • 満たす条件として時間を含める

      • 満たさない条件として時間を含める

      • SLOの全体の計算で、ブラックアウト時間を除外します。

      たとえば、1週間のうちブラックアウトまたは計画停止が1日の場合、週の可用性は(7-1) / (7-1)日で、これは依然として100%の可用性です。

      デフォルトでは、「サービス・レベル目標値評価にブラックアウト時間(計画ダウンタイム)を含める」オプションは選択されていません。

  7. 「次」をクリックします。サービス・レベル目標値ページで、SLAの一部として、1つ以上のSLOを定義します。SLAの「評価条件」を次のように選択できます。

    • すべてのサービス・レベル目標値を満たす必要があります

    • 1つ以上のサービス・レベル目標値を満たす必要があります

    SLAには1つ以上のSLOが必要です。一度に複数のSLOをアクティブにできます。すべてのSLOを満たす必要がある、または1つ以上のSLOを満たす必要があるかのいずれかを指定できます。

  8. 「作成」をクリックして、新しいSLOを定義します。詳細は、「サービス・レベル目標の作成」を参照してください。

  9. SLOを追加、または定義済のSLOを編集できます。「次」をクリックします。サービス・レベル合意の有効化ページで、SLAが有効化されるときを指定できます。次のいずれかを選択できます。

    • 有効にしない: 有効化されていないSLAは定義状態であり、必要に応じて変更できます。

    • すぐに有効化: 有効化されているSLAはアクティブ状態なので変更できません。

    • 後で有効化: SLAは指定した日に、後で変更できます。

  10. 「次へ」をクリックして、SLAの詳細を確認し、「発行」をクリックします。SLAが指定した日に有効化され、サービス・レベル合意構成ページに戻ります。

24.6.1 SLAのアクション可能なアイテム・ルール

次の表に、SLAでその状態に基づき実行できるアクションのリストを示します。

SLAの状態 類似作成 編集 有効化 無効化 削除
定義 はい はい はい いいえ はい
スケジュール はい はい いいえ はい いいえ
アクティブ はい いいえ いいえ はい いいえ
撤収 はい いいえ いいえ いいえ はい

  • 状態が「スケジュール済」または「アクティブ」のSLAは直接削除できません。削除する前にSLAを無効化する必要があります。

  • 「スケジュール済」状態のSLAを編集するときは、SLAの状態は「定義」に変わります。

24.6.2 サービス・レベル目標の作成

サービス・レベル目標では、指定した測定ウィンドウに対する1つ以上のインジケータのサービス・レベルを測定します。サービス・レベル目標(SLO)は提供されるサービス・レベルを定義します。SLAが満たしているとみなす条件を指定できます。

  • すべてのサービス・レベル目標値を満たしている。

  • 1つ以上のサービス・レベル目標値を満たしている。

SLOを作成するには、次の手順に従います。

  1. サービス・レベル目標値の構成ページで「作成」をクリックします。サービス・レベル目標値の作成ページが表示されます。

    図24-4 サービス・レベル目標値の作成

    サービス・レベル目標値の作成
  2. 次の詳細を入力します。

    • 定義されるSLOの名前。

    • SLOのタイプ: SLOは可用性またはパフォーマンス・メトリックに基づくことができます。

    • 予測されるサービス・レベル(%): SLAが満たされていることを保証する、SLO条件が満たす時間の割合。

    • 警告アラート・レベル(%): SLO条件が指定したしきい値を満たしていない場合、クリティカル・アラートが生成されます。

      たとえば、「予測されるサービス・レベル(%)」が90%で、「実際のサービス・レベル(%)」が90から99%の範囲の場合、警告アラートが生成されます。「実際のサービス・レベル(%)」が90%より下の場合、クリティカル・アラートが生成されます。これはSLAが違反していることを示します。「実際のサービス・レベル(%)」が99%より上の場合、SLA条件は十分満たされていることを示します。

    • 測定ウィンドウ: SLOが有効な期間。測定ウィンドウには複数の期間を割り当てることができます。たとえば、測定ウィンドウを、月曜日から金曜日の午前9時から午後6時までを平日のピーク時間として、週末のピーク時間を午前10時から午後2時として構成することができます。

      SLOの作成時に、SLO用に複数のビジネス・カレンダを選択できます。たとえば、各SLOを午前8時から午後5時まで昼食時間(正午から午後1時)を除いて評価するとします。2つの測定ウィンドウを作成し、測定対象から昼食時間を除くことができます。

      2つの測定ウィンドウをマージする別の例は、カレンダ評価を使用して週次評価を結合する場合です。SLOを毎週月曜日と毎月の15日に評価する場合、2つの監視ウィンドウを作成し、両方のウィンドウにその条件を含めることができます。

      デフォルトでは、3つの事前定義済のビジネス・カレンダがあります。さらに、独自のカレンダを作成することもできます。詳細は「カスタムSLAビジネス・カレンダの定義」を参照してください。

  3. 「次」をクリックします。サービス・レベル・インジケータの作成ページで、SLOを測定できるようにする、1つ以上のSLIまたは条件を追加できます。

    図24-5 サービス・レベル・インジケータの作成

    サービス・レベル・インジケータの作成

    たとえば、パフォーマンスSLIを追加している場合、ページ・リード時間が3秒以下である必要があると指定できます。この条件が満たされないと、SLIは違反しているとみなされます。SLIの評価条件を指定します。

    • すべてのサービス・レベル・インジケータを満たす必要があります

    • 1つ以上のサービス・レベル・インジケータを満たす必要があります。

  4. 「追加」をクリックして、1つ以上のメトリックを追加し、値と評価条件を指定します。「発行」をクリックして、サービス・レベル目標値の構成ページに戻ります。

24.6.3 SLAのライフサイクル

次の図に、SLAのライフサイクルを示します。

図24-6 SLAのライフサイクル

SLAのライフサイクル

SLAのライフサイクルは、次のフェーズで構成されます。

  • 定義: SLAが作成されSLOが定義されるステージです。SLAがアクティブ化されるまでSLA定義を構成または編集できます。

  • スケジュール済: このステージはSLAが将来の日付に有効化されるようにスケジュールされる前の期間を表します。

  • アクティブ: スケジュール済SLAの開始日に達する、またはSLAが手動で有効化されるステージです。

  • 撤収: SLAが有効期限に達する、またはSLAが手動で無効化されるステージです。

  • 無効: SLAが有効期限に達する前に、手動で無効化できます。SLAを一度無効化すると、再度有効にすることができなくなります。「類似作成」オプションを使用して類似のSLAを作成し、有効化する必要があります。

  • 期限切れ: SLAが有効期限に達した、またはすでにアクティブでないステージです。

  • 削除済: 定義または撤収ステージのSLAは削除できます。「アクティブ」または「スケジュール済」ステージのSLAは削除できません。

24.6.4 サービスのSLAのステータスの表示

サービスのすべてのSLAのステータスを表示できます。サービスのSLAの現在のステータスを表示するには、次の手順に従います。

  1. 「ターゲット」メニューから「サービス」を選択します。

  2. リストで「汎用サービス」ターゲットをクリックします。「サービス・ホーム」ページが表示されます。

  3. 「汎用サービス」メニューで、「サービス・レベル合意」「現在のステータス」の順に選択します。サービス・レベル合意の現在のステータス・ページが表示されます。

  4. このページには、このサービスに定義されたすべてのアクティブなSLAのリストが表示されます。SLAごとに、SLAのステータス、SLA評価期間、およびサービス・レベル目標が表示されます。

  5. SLA内の詳細な情報を表示するSLAを選択します。次の詳細が表示されます。

    • ステータスのトラッキング: これはSLIの瞬時のステータスです。可用性SLOの場合、これはターゲットのステータスです。パフォーマンスSLOの場合、特定の時点のパフォーマンスまたは使用状況メトリックの値です。

    • サービス・レベル(%): SLO条件を満たすか、または「ステータスのトラッキング」がtrueの時間(現在の評価期間の最初から現在の日付まで)の割合。「実際のサービス・レベル(%)」が「予測されるサービス・レベル(%)」よりも低い場合、またはSLO条件を満たしている場合、「サービス・レベル%」グラフは緑色です。

    • タイプ: SLAに対して定義されたSLOのタイプ。これは可用性またはパフォーマンス・メトリックに基づくことができます。可用性SLOは、レスポンス・メトリック[サービス・ターゲット可用性]に基づきます。可用性の目標を満たす必要のあるときの時間の割合または量の形で指定します。パフォーマンスSLOはサービスがどれくらい効率的に実行されているかを測定します。スループットまたはワークロードといった速さおよびボリューム(応答時間、トランザクション/時など)の測定が含まれます。SLOパフォーマンスは、SLIのセット、SLO条件、および可用性の目標を満たす必要のあるときの時間の割合または量のいずれかの形で指定します。

    • SLO違反: 各SLA評価期間の許容違反。

      • 合計: 評価期間 * (予測されるサービス・レベル)の期間。

      • 実績: 評価期間中にSLOが満たされない時間。

      • 残り: SLAの違反なしでSLOを満たすことができない時間。SLOが評価期間中、常に満たされている場合は、使用される許容がなく、「実績」フィールドの値は0になります。

24.6.5 カスタムSLAビジネス・カレンダの定義

ビジネス・カレンダは、サービス・レベル目標値(SLO)を測定する特定の期間を定義する測定ウィンドウです。すぐに使用できる事前定義済のビジネス・カレンダが用意されています。それとは別に、カスタムのビジネス・カレンダを作成できます。カスタムのビジネス・カレンダを作成するには、「ターゲット」メニューから「サービス」を選択します。「サービス機能」メニューから、「ビジネス・カレンダ」を選択します。

定義されたビジネス・カレンダのリストは、ここに表示されます。次の操作を実行できます。

  • 作成: 「作成」をクリックして、ビジネス・カレンダを設定します。ビジネス・カレンダの追加/編集ページが表示されます。

  • 類似作成: カレンダを選択し、「類似作成」をクリックして、このカレンダのコピーを作成します。

  • 編集: カレンダを選択し、「編集」をクリックし、ビジネス・カレンダの追加/編集ページで必要な変更を行います。

  • 削除: カレンダを選択し、「削除」をクリックして削除します。1つ以上のSLAに関連するビジネス・カレンダは編集または削除できません。

  • 関連するサービス・レベル合意の表示: 1つ以上のSLAは、ビジネス・カレンダを使用できます。ビジネス・カレンダを選択し、「関連するサービス・レベル合意の表示」をクリックして、このカレンダに関連付けられているSLAを表示します。

24.7 サービス・ダッシュボードの使用

サービス・ダッシュボードによって、すべてのサービス関連の情報の簡単なサマリーが、1つの場所に提供されます。可用性、パフォーマンス、サービスに関連するSLA、キー・システム・コンポーネントのステータスなどのサービスの重要な側面を統合して表示します。

24.7.1 すべてのダッシュボード・ページの表示

すべてのダッシュボード・ページを表示するには、次の手順に従います。

  1. 「ターゲット」メニューから「サービス」を選択します。

  2. 「サービス機能」メニューから、「ダッシュボード」を選択します。

  3. すべてのダッシュボード・ページが表示され、作成されたすべてのダッシュボードのリストが表示されます。

  4. すべてのダッシュボード・ページで、次の操作を実行できます。

    • ダッシュボードの作成: 「ダッシュボード名」フィールドに一意の名前を入力し、「ダッシュボードの作成」をクリックします。新しく追加されたダッシュボードが表に表示されます。ダッシュボードを作成するには、「サービス・ダッシュボードの作成」権限のあるEM_ADMINISTRATORロールが必要です。

    • ダッシュボードのカスタマイズ: リストからダッシュボードを選択し、「カスタマイズ」をクリックし、サービス・ダッシュボードの編集ページで変更を行います。ダッシュボードは、作成したユーザーのみがカスタマイズできます。

    • 削除: リストからダッシュボードを選択し、「削除」をクリックします。選択したダッシュボードが削除されます。ダッシュボードは、作成したユーザーのみが削除できます。

  5. 「ダッシュボード名」リンクをクリックし、ダッシュボードの詳細ページにドリルダウンします。

24.7.2 ダッシュボードの詳細ページの表示

このページには次の詳細が表示されます。

  • サービス名: リンクをクリックして、サービスの詳細ページにドリルダウンします。

  • インシデント: 発生したインシデント。

  • パフォーマンス/使用状況メトリック: サービスで使用可能なパフォーマンスおよび使用状況メトリックの名前、各メトリックの最新値が表示されます。傾向グラフは過去24時間のメトリックの傾向を示します。傾向グラフをクリックして、傾向を詳細に表示します。

  • SLA: アクティブ、クリティカルまたは警告状態にある有効化されたSLAの数を示します。

  • キー・コンポーネント: このサービスに対して使用可能または稼働中のキー・ターゲットを表示します。

  • システム・インシデント: サービスの基礎となるシステムに発生したインシデントが表示されます。

図24-7 サービス・ダッシュボード

サービス・ダッシュボード

ダッシュボードにリストするサービスをフィルタできます。「フィルタ条件」に値を指定して「フィルタ」をクリックします。フィルタはすべてのサービスの各行に適用され、結果リストが表示されます。

1つ以上の電子メール・アドレスにダッシュボードを電子メール送信できます。「電子メール」をクリックして電子メール・アドレスとダッシュボードの件名を入力します。「送信」をクリックします。この機能はhtttpモードでのみ動作します。

24.7.3 ダッシュボードのカスタマイズおよびパーソナライズ

ダッシュボードをカスタマイズし、その変更をすべてのユーザーが使用できるようにできます。ダッシュボードをカスタマイズするには、「すべてのダッシュボード」ページで行を選択し、「カスタマイズ」をクリックします。


注意:

crには、次の権限が必要です。

1つ以上のサービスをダッシュボードに追加するには、レンチ・アイコンをクリックします。コンポーネント・プロパティ: サービス・ダッシュボード・ウィンドウが表示されます。ダッシュボードに追加するサービスのタイプを選択し、「検索」をクリックします。「使用可能なターゲット」表に、サービスのリストが表示されます。追加する1つ以上のサービスを選択し、それらを「選択したターゲット」表に移動して、「適用」をクリックします。各サービスにメトリックを追加するには、「メトリック」タブをクリックし、メトリックを追加する各サービスを選択して、「OK」をクリックします。選択したサービスおよびメトリックが、「サービス・ダッシュボード」表に表示されるようになります。

サービス・ターゲットをダッシュボードから削除するには、行を選択してレンチ・アイコンをクリックします。コンポーネント・プロパティ: サービス・ダッシュボード・ウィンドウが表示されます。ダッシュボードから削除するサービスおよびメトリックの選択を解除し、「適用」をクリックして、「OK」をクリックします。ダッシュボードに行った変更をリセットするには、ページのリセットをクリックします。ダッシュボードに行われた変更は完全に削除されます。「閉じる」をクリックして「編集」モードを終了します。

要件に合うように、ダッシュボードに特定の変更を行うことができます。「パーソナライズ」アイコンをクリックして、ダッシュボードに対する1つ以上のサービスの追加または削除を行います。変更内容を参照できるのは、それを行ったユーザーのみで、他のユーザーは変更内容を参照できません。

24.7.4 ダッシュボード・サービスの詳細ページの表示

このページには、選択したサービスの詳細情報が表示されます。

図24-8 ダッシュボードの詳細ページ

ダッシュボードの詳細ページ

次のタブがあります。

  • 概要: このタブは選択したサービスの概要を示します。「サービス」リンクをクリックし、サービス・ホーム・ページにドリルダウンします。次のリージョンがあります。

    • 一般: このリージョンには、サービスの名前、ステータス、サービスが使用可能になった日付、可用性割合、サービスのタイプ(テスト・ベースまたはシステム・ベース)、停止時間、およびエラー時間が表示されます。サービス名をクリックし、サービス・ホーム・ページにドリルダウンします。

    • コンポーネントの可用性: このリージョンには、サービスでのコンポーネントのステータスが表示されます。コンポーネントのステータス、およびサービスが起動した日付が表示されます。キー・サービス・テストのみを表示するには、「キー・テストのみを表示」チェック・ボックスを選択します。

  • SLA: このサービスで有効になっているSLAのリストが表示されます。名前、ステータス、およびSLAが適用可能になった日付が表示されます。過去7日間のSLA履歴も表示されます。

  • メトリック: このタブには、このサービスに定義されたパフォーマンスおよびメトリックのチャートが表示されます。サービスと、サービスの基礎となるシステムに発生したインシデントも表示されます。

24.8 テスト・リポジトリの使用

テスト・リポジトリは、すべてのテスト・スクリプトを保持できる一元的な場所です。テスト・リポジトリを使用するには、事前に構成されたOMSソフトウェア・ライブラリの場所を指定する必要があります。詳細は、17.7項を参照してください。

テスト・リポジトリを使用する利点は次のとおりです。

  • 以前は、テストはサービスのコンテキストでのみ作成できました。これに対し、現在は、サービスのコンテキスト外で任意の数のテスト・スクリプトを作成し、テスト・リポジトリと呼ばれる一元的な場所に保存するなど、柔軟に対応できるようになりました。テスト・スクリプトのアップロードおよびサービスの作成は、独立したイベントになりました。テスト・スクリプトがリポジトリで使用可能になると、サービスの作成中に使用できます。

  • 以前は、テスト・スクリプトの所有者のみがスクリプトのコピーを所有していました。現在は、テスト・リポジトリの導入により、スクリプトが一元的な場所に保持され、すべてのユーザーがスクリプトにアクセスできます。サービスの作成時に、ボタンをクリックするだけで、リポジトリからスクリプトをインポートできるため、ユーザーフレンドリですばやい操作が可能になりました。


注意:

現在は、ATSテスト・スクリプトを中央リポジトリに保存するサポートのみです。

ats_test_repo.gifについては周囲のテキストで説明しています。

24.8.1 テスト・リポジトリの表示

テスト・リポジトリにアップロードされたテスト・スクリプトを表示するには、次の手順に従います。

  1. 「ターゲット」メニューから「サービス」を選択します。

  2. 「サービス機能」メニューから、「リポジトリのテスト」を選択します。

  3. 「リポジトリのテスト」ページに、作成したすべてのテストの一覧が表示されます。

  4. 「リポジトリのテスト」ページから、次の操作を実行できます。

    • テストの追加: 「追加」をクリックします。「一般情報」セクションで、一意のテスト名を入力します。ATS情報セクションで、「参照」.をクリックして、ローカル・マシンからテスト・スクリプトをアップロードします。関連するファイルを選択すると、ファイル名がステップおよびモジュールの詳細とともに表示されます。「保存」をクリックして、スクリプトを保存します。

    • テストの編集: テストクリックして、「編集」をクリックします。ATSスクリプトはEnterprise Managerコンソール内では変更できません。ただし、前にアップロードしたスクリプトをダウンロードし、zipファイルをATS OpenScriptにインポートできます。ATSスクリプトのダウンロード方法および編集方法は、第24.8.2項を参照してください。

    • テストの削除: テストを選択して、「削除」をクリックすると、テスト・スクリプトが削除されます。

  5. テスト名をクリックして、テストの詳細を「テストの詳細」表に表示します。

24.8.2 ATSスクリプトの編集

スクリプト・バンドルをダウンロードして編集するには、次の手順に従います。

  • 「ダウンロード」をクリックして、指示に従ってzipファイルを保存します。

  • OpenScriptを起動し、「ファイル」メニューから「スクリプトのインポート」を選択して、zipファイルをATS OpenScriptにインポートします。

  • ATS OpenScriptでスクリプトを編集したら、「ファイル」を選択し、スクリプトのエクスポート」を選択して、新規スクリプトをエクスポートし、zipファイルを保存します。

  • Cloud Controlにログインし、ATSサービス・テスト・ページにナビゲートします。「アップロード」をクリックし、更新済のスクリプト・ファイルをEnterprise Managerにアップロードします。

24.9 サービス・レベルの設定

サービス・レベル・ルールは、サービスの品質の判断に使用される評価基準として定義されます。これにより、サービス・レベル合意で定義されているように、営業時間中にサービスが満たす必要がある可用性およびパフォーマンス基準を指定できます。たとえば、電子メール・サービスは、月曜から金曜の午前8時から午後8時までは99.99%使用可能である必要があります。

サービス・レベル・ルールは、サービスがサービス・レベル・ルールで定義されているパフォーマンスおよび可用性基準を満たしている時間の割合を指定します。デフォルトでは、規定された営業時間の85%の期間、指定された基準を満たしていることが期待されます。サービスの期待度に応じて、この割合のレベルを上下できます。サービス・レベル・ルールは次の要素に基づいています。

  • 営業時間: サービス・レベルがサービス・レベル合意の指定に基づいて計算される時間範囲です。

  • 可用性: サービスがどのような場合に使用可能であるとみなされるかを指定できます。これは、サービス・レベルの計算のみに影響し、コンソールに表示される実際の可用性状態には影響しません。サービスが次の1つ以上の状態である場合に、サービスが使用可能であるとみなされるように選択できます。

    • 稼働中: デフォルトでは、サービスは「稼働中」または使用可能であるとみなされます。

    • ブラックアウト中: このオプションにより、サービスのブラックアウト時間(サービスが技術的に使用不可であることを示す計画アクティビティ)を使用可能なサービス時間として指定できます。

    • 不明: このオプションにより、管理エージェントが使用不可であるためにサービスが監視されない時間を、使用可能なサービス時間として指定できます。

  • パフォーマンス基準: オプションで、サービスのパフォーマンスが低下している場合に、サービス・レベル違反に指定できます。たとえば、Webサイトが稼働している場合でも、1ページのロードに10秒かかる場合、サービスは使用不可であるとみなされる可能性があります。

  • ビジネス基準: ビジネス基準は、特定のサービスのビジネス・プロセスの状態を判断するのに役立ちます。必要に応じて、サービス・レベルに影響するビジネス・メトリックを定義できます。特定のビジネス・メトリックに対してクリティカル・アラートが生成されると、サービス・レベル違反が発生します。


    注意:

    「ビジネス基準」列は、1つ以上のキー・ビジネス・インジケータがサービスに関連付けられている場合にのみ表示されます。『Oracle Enterprise Manager統合ガイド』を参照してください。

  • 実際のサービス・レベル: 営業時間内で、指定された可用性、パフォーマンスおよびビジネス基準をサービスが満たしている時間の割合が計算されます。

  • 予測されるサービス・レベル: 関係する評価期間のうち、提供するサービスが満たす必要のある最低限の許容可能なサービス・レベルを表します。

各サービスには、1つのサービス・レベル・ルールのみを定義できます。サービス・レベル・ルールは、ある期間内に「実際のサービス・レベル」を評価し、それを「予測されるサービス・レベル」と比較するために使用されます。

24.9.1 サービス・レベル・ルールの定義

サービス・レベル・ルールは、サービスの品質の測定に使用される評価基準として定義されます。サービス・レベル・ルールは次の要素に基づいています。

  • ルールが適用可能な時間範囲。

  • ルールを定義するメトリック。

  • メトリック値に対するユーザーの期待値。

予測されるサービス・レベルは、サービスに対して期待する品質で、サービス・レベル・ルールのメトリックと時間範囲に基づいて定義されます。たとえば、予測されるサービス・レベルを、営業時間中にサービスが99%の時間使用可能である、とすることができます。

サービスを作成すると、デフォルトのサービス・ルールがそのサービスに適用されます。ただし、サービスに適切な評価基準を正確に定義するには、各サービスのサービス・レベル・ルールを編集する必要があります。To define a service level rule:

  1. 「ターゲット」タブをクリックし、「サービス」サブタブをクリックします。「サービス」のメイン・ページが表示されます。

  2. サービス名のリンクをクリックし、サービスのホームページに移動します。

  3. 「関連リンク」セクションで、「サービス・レベル・ルールの編集」をクリックします。

  4. 「サービス・レベル・ルールの編集」ページで、予測されるサービス・レベルと実際のサービス・レベルを指定し、「OK」をクリックします。予測されるサービス・レベルは、サービス・レベル・ルールで定義されているパフォーマンス、使用状況、可用性およびビジネス基準をサービスが満たしている時間の割合を指定します。実際のサービス・レベルは、サービスの質の定義に使用されるベースライン基準を定義するもので、営業時間、可用性、パフォーマンス基準、使用状況基準およびビジネス基準が含まれます。


注意:

スーパー管理者、サービスの所有者またはOPERATOR_TARGETターゲット権限を持つEnterprise Manager管理者が、サービス・レベル・ルールを定義または更新できます。

24.9.2 サービス・レベルの詳細の表示

次のいずれかから直接にサービス・レベル情報を表示できます。

  • Enterprise Manager Cloud Controlコンソール -任意のサービスのホームページで、「実際のサービス・レベル」をクリックして、「サービス・レベルの詳細」ページにドリルダウンできます。このページには、予測されるサービス・レベルと比較して、過去24時間、7日間または31日間において、サービスが実際に達成したサービス・レベルが示されます。さらに、サービス違反および各違反の時間の詳細がグラフィックとテキストの両方で表されます。

  • 情報パブリッシャ - 情報パブリッシャは、サービス・ダッシュボードと呼ばれる、あらゆるサービスの包括的なビューを提供する即時利用可能なレポート定義を提供します。「レポート定義」ページで、「サービス監視ダッシュボード」レポート定義をクリックし、既存のサービスの包括的なビューを生成します。デフォルトでは、サービスの可用性、パフォーマンス、ステータス、使用状況、ビジネスおよびサービス・レベルが表示されます。また、情報パブリッシャには、独自のカスタム・レポート定義の作成を可能にするサービス固有のレポート要素も用意されています。次のレポート要素が使用可能です。

    • サービス・レベルの詳細: ある期間内で達成された「実際のサービス・レベル」とそれに影響を与えた違反を表示します。

    • サービス・レベルのサマリー: 一連のサービスについて、選択した期間内に発生したサービス・レベル違反が表示されます。

    • サービス監視ダッシュボード: 一連のサービスに関して、そのステータス、パフォーマンス、使用状況、ビジネス、サービス・レベル情報が表示されます。

    • サービス・ステータス・サマリー: 1つ以上のサービスの現在のステータス、パフォーマンス、使用状況、ビジネスおよびコンポーネント・ステータスに関する情報が表示されます。

      レポート要素の詳細は、オンライン・ヘルプを参照してください。

24.10 コマンドライン・インタフェースを使用したサービスの構成

コマンドライン・インタフェースを使用して、サービス・ターゲットとテンプレートの定義、およびインシデントの設定を行うことができます。EMCLIは、エンタープライズまたはシステム管理者による、カスタマのビジネス・プロセスにワークフローを提供するスクリプト(シェル、バッチ・ファイル、perl、tcl、phpなど)の作成に使用することを意図しています。また、管理者は、オペレーティング・システム・コンソールから直接または対話的にEMCLIを使用できます。『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

WebトランザクションとATSサービス・テストを作成するEMCLIテンプレートの例を次に示します。

例24-1 Webトランザクション・サービス・テスト・テンプレート

<?xml version = '1.0' encoding = 'UTF-8'?> <transaction-template 
template_type="generic_service" xmlns="template">
   <variables>
      <variable name="HOST1" value="linuxserver26.myco.com"/>
      <variable name="PORT1" value="5416"/>
      <variable name="PROTOCOL1" value="https"/>
   </variables>
   <transactions>
      <mgmt_bcn_transaction>
         <mgmt_bcn_txn_with_props>
            <mgmt_bcn_txn description="Test for checking the availability of EM Console/Website" is_representative="true" 
                          name="EM Console Service Test" monitoring="true" txn_type="HTTP"/>
            <properties>
               <property name="readTimeout" num_value="120000.0" prop_type="2" encrypt="false"/>
               <property name="Collection Interval" num_value="5.0" prop_type="2" encrypt="false"/>
               <property name="certValidationMode" string_value="1" prop_type="1" encrypt="false"/>
               <property name="maxDownloadSize" num_value="1.0E8" prop_type="2" encrypt="false"/>
               <property name="sensitiveValuesProtection" string_value="0" prop_type="1" encrypt="false"/>
               <property name="failureStringModes" string_value="regularText" prop_type="1" encrypt="false"/>
               <property name="UserAgent" string_value="Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.1) OracleEMAgentURLTiming/3.0" prop_type="1" encrypt="false"/>
               <property name="successStringModes" string_value="regularText" prop_type="1" encrypt="false"/>
               <property name="variablesModes" string_value="urlEncode" prop_type="1" encrypt="false"/>
               <property name="content" string_value="0" prop_type="1"encrypt="false"/>
               <property name="AcceptLanguage" string_value="en" prop_type="1" encrypt="false"/>
               <property name="connectionTimeout" num_value="120000.0" prop_type="2" encrypt="false"/>
               <property name="useCache" string_value="yes" prop_type="1"encrypt="false"/>
               <property name="stringValidationMode" string_value="1" prop_type="1" encrypt="false"/>
               <property name="granularity" string_value="transaction" prop_type="1" encrypt="false"/>
               <property name="numThreads" num_value="4.0" prop_type="2" encrypt="false"/>
               <property name="retries" num_value="1.0" prop_type="2" encrypt="false"/>
               <property name="timeout" num_value="300000.0" prop_type="2" encrypt="false"/>
               <property name="retryInterval" num_value="5000.0" prop_type="2" encrypt="false"/>
            </properties>
            <per_bcn_properties/>
         </mgmt_bcn_txn_with_props>
         <steps_defn_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="1" name="1.Access Logout page" step_type="HTTP"/>
               <properties>
                  <property name="req_mode" num_value="1.0" prop_type="2" encrypt="false"/>
                  <property name="http_method" string_value="G" prop_type="1" encrypt="false"/>
                  <property name="url" string_value="{PROTOCOL1}://{HOST1}:{PORT1}/em/console/logon/logoff?event=load" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
         </steps_defn_with_props>
         <stepgroups_defn/>
         <txn_thresholds>
            <mgmt_bcn_threshold warning_threshold="6000.0" warning_operator="0" critical_threshold="12000.0" critical_operator="0" num_occurrences="1">
               <mgmt_bcn_threshold_key metric_name="http_response" metric_column="avg_response_time"/>
            </mgmt_bcn_threshold>
            <mgmt_bcn_threshold warning_threshold="0.0" warning_operator="1" critical_threshold="0.0" critical_operator="1" num_occurrences="1">
               <mgmt_bcn_threshold_key metric_name="http_response" metric_column="status"/>
            </mgmt_bcn_threshold>
         </txn_thresholds>
         <step_thresholds/>
         <stepgroup_thresholds/>
      </mgmt_bcn_transaction>
   </transactions>
</transaction-template>

例24-2 ATSサービス・テスト・テンプレート

<?xml version = '1.0' encoding = 'UTF-8'?>
<transaction-template template_type="generic_service" xmlns="template"> 
   <variables/>
   <transactions>
      <mgmt_bcn_transaction>
         <mgmt_bcn_txn_with_props>
            <mgmt_bcn_txn is_representative="true" name="ATS Page"           monitoring="true" txn_type="OATS"/>
            <properties>
               <property name="Collection Interval" num_value="5.0" prop_type="2"  encrypt="false"/>
               <property name="scriptDescription" string_value="[1] SignIn&#xA;[2] Welcome&#xA;[3] Single Sign-Off&#xA;[4] Sign In" prop_type="1"encrypt="false"/>
               <property name="fileUploadTime" string_value="2012-08-0908:47:22.0" prop_type="1" encrypt="false"/>
               <property name="OpenScriptJwgName" string_value="ATKHomepage.zip" prop_type="1" encrypt="false"/>
               <property name="usageOptions" string_value="userDefined" prop_type="1" encrypt="false"/>
               <property name="fileSize" string_value="41368" prop_type="1" encrypt="false"/>
               <property name="beaconDistributionOverride" string_value="AtsCredentials=1" prop_type="1" encrypt="false"/>
               <property name="FilePropertyValue" prop_type="7" encrypt="false"/>
               <property name="databankFilesJar" prop_type="7" encrypt="false"/>
               <property name="databankFiles" string_value="AtsCredentials,AtsCredentials.csv,3;" prop_type="1" encrypt="false"/>
               <property name="granularity" string_value="transaction" prop_type="1" encrypt="false"/>
               <property name="databankValues" string_value="people.firstname=yang.,people.lastName=wang,middle.middlename_col=x." prop_type="1" encrypt="false"/>
               <property name="modules" string_value="oracle.oats.scripting.modules.utilities;version=2.4.0&#xA;oracle.oats.scripting.modules.http;version=2.4.0&#xA;" 
                         prop_type="1" encrypt="false"/>
               <property name="databankAliasMapping" string_value="AtsCredentials=AtsCredentials.csv" prop_type="1" encrypt="false"/>
               <property name="defaultCLIOptions" string_value="-dboptions*:1:FIRST_RECORD_ONLY -jwg ATKHomepage.jwg -noReport true" prop_type="1"
                         encrypt="false"/>
            </properties>
            <per_bcn_properties/>
         </mgmt_bcn_txn_with_props>
         <steps_defn_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="1" name="[1] Sign In" step_type="OATS"/>
               <properties>
                  <property name="url" string_value="http:://www.test.com/test1" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="2" name="[2] Welcome" step_type="OATS"/>
               <properties>
                  <property name="url" string_value="http:://www.test.com/test2" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="3" name="[3] Single Sign-Off" step_type="OATS"/>
               <properties>
                  <property name="url" string_value="http:://www.test.com/test3" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="4" name="[4] Sign In" step_type="OATS"/>
               <properties>
                  <property name="url" string_value="http:://www.test.com/test4" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
         </steps_defn_with_props>
         <stepgroups_defn/>
         <txn_thresholds>
            <mgmt_bcn_threshold warning_threshold="0.0" warning_operator="1" critical_threshold="0.0" critical_operator="1" num_occurrences="1">
               <mgmt_bcn_threshold_key metric_name="openscript_response" metric_column="status"/>
            </mgmt_bcn_threshold>
         </txn_thresholds>
         <step_thresholds/>
         <stepgroup_thresholds/>
      </mgmt_bcn_transaction>
   </transactions>
</transaction-template>

24.11 サービス・テストのトラブルシューティング

この項では、FormsおよびWebトランザクションのテスト・タイプの使用時によく検出されるエラーをいくつか示します。この項では、次のトピックについて説明します。

24.11.1 Formsトランザクションの検証およびトラブルシューティング

この項では次の内容について説明します。

24.11.1.1 Formsトランザクション再生時のトラブルシューティング

この項では、Formsトランザクションの再生時によく検出されるエラーをいくつか示し、その解決方法を示します。

  1. エラー・メッセージ: Formsサーバーへの接続が失われました。agentjarsformsjarsの間でバージョンが一致しない可能性があります。

    可能性のある原因: 新しいバージョンのFormsを使用してトランザクションが記録されました。

    解決方法: 「Oracle Formsについて」オンライン・ヘルプでバージョン番号をチェックし、実行中のFormsアプリケーションのバージョンを検証します。このバージョンがサポートされていない場合は、「2.」のエラー・メッセージのステップに従ってください。

  2. エラー・メッセージ: バージョン<forms_version>はサポートされていません。

    可能性のある原因: ビーコンがインストールされているマシンに、必要なForms jarファイルが含まれていません。

    解決方法: このエラーを解決するには、次の手順に従います。

    1. Formsサーバーがインストールされているシステムにログインします。frmall.jar (Forms 10.1以上を使用している場合)またはf90all.jar(Forms 9.0.4以上を使用している場合)を$FORMS_HOME/forms/javaディレクトリ下で探します。

    2. ビーコンがデプロイされているシステムにログインし、このjarファイルを$ORACLE_HOME/jlib/forms/<version>/ディレクトリにコピーします。ここで指定するバージョンは、エラー・メッセージのバージョン文字列と同じにする必要があります。jarファイルをコピーする前に、このディレクトリが空であることを確認します。

    Oracle Applications R12を使用してこのエラーが発生した場合は、次の手順に従ってエラーを解決します。

    1. Oracle Application Serverがデプロイされているシステムにログインします。次のファイルを探します。

      $JAVA_TOP/oracle/apps/fnd/jar/fndforms.jar
      $JAVA_TOP/oracle/apps/fnd/jar/fndewt.jar
      
    2. ビーコンがデプロイされているシステムにログインし、これらのファイルを$ORACLE_HOME/jlib/forms/apps/ディレクトリにコピーします。jarファイルをコピーする前に、このディレクトリが空であることを確認します。


      注意:

      異なるバージョンのOracle Applicationsを使用した場合は、同じビーコンからの2つのOracle Applicationsのデプロイを監視できません。

  3. エラー・メッセージ: Forms URLがFormsサーブレットを指していません。

    可能性のある原因: Formsトランザクションが記録されたときに、Formsサーブレットの場所を特定できませんでした。

    解決方法: Forms URLパラメータがFormsサーブレットを指していることを確認します。Forms10gの場合はhttp://<hostname>:<port>/forms/frmservlet、Forms 9iの場合はhttp://<hostname>:<port>/forms/f90servletです。このパラメータは、Formsトランザクション・レコーダによって自動的に設定されます。ただし、設定されていない場合は、次の手順に従ってURLを特定できます。

    • Formsアプリケーションを起動します。

    • ソースHTMLファイルをFormsランチャ・ウィンドウで表示します。

    • xsurl変数を探します。URLはこの変数に格納されています。

  4. エラー・メッセージ: <マシン名>に接続できませんでした

    可能性のある原因: ビーコンがインストールされているマシンが、Formsアプリケーションにアクセスできません。

    解決方法: ビーコンがインストールされているマシンがFormsアプリケーションにアクセスでき、ファイアウォールが適切に構成されていることを確認します。プロキシ・サーバーを使用したFormsトランザクションの再生は、このリリースではサポートされていません。

  5. エラー・メッセージ: 初期メッセージに無効なモジュール・パスが含まれています。

    可能性のある原因: トランザクションが、正しく記録されていないか、破壊されている可能性があります。

    解決方法: トランザクションの記録を再度実行してみてください。

  6. エラー・メッセージ: ログイン・サーバーに接続できません。

    可能性のある原因: このエラーは、次の原因で発生する可能性があります。

    • 指定したログインURLが正しくありません。

    • ログイン・サーバーに指定したHTTPS証明書が無効です。

    解決方法:

    • ログインURLが正しいことを確認します。

    • HTTPSを使用してログイン・サーバーに接続している場合は、サーバー上の証明書がログイン・サーバーのマシン自体用であることを確認します。SSL証明書がエージェントにインポートされ、証明書のCNがログイン・サーバーのURLのホスト名に一致していることを確認します。

24.11.1.2 Formsトランザクション記録時のトラブルシューティング

この項では、Formsトランザクションが正常に記録されない場合に有効なトラブルシューティング方法をいくつか示します。

  1. Internet Explorerのインスタンスがすべて閉じられており、Javaランタイム・プログラムが1つも開かれていないことを確認します。

  2. Javaコンソールが開かれた状態で、記録を再度開始します。コンソールに例外やエラー・メッセージが表示される場合もあります。

  3. コンソールに、Forms Transaction Recorder Version: <version number>"というテキストが表示される場合もあります。このテキストが表示された場合は、ステップ5に進みます。テキストが表示されない場合は、formsRecorder.jarがFormsのアーカイブ・ディレクトリにコピーされているかをチェックします。次のいずれかの方法で、このチェックを実行できます。

    1. Formsアーカイブ・ディレクトリにナビゲートし、ディレクトリにformsRecorder.jarファイルが存在するかをチェックします。

    2. 「Formsトランザクション監視の有効化」ページにナビゲートし、該当するFormsサーバー・ターゲットを選択し、「構成」をクリックします。ホスト資格証明を入力し、このFormsサーバー上でFormsトランザクション・レコーダが構成済かを確認します。Formsのアーカイブ・ディレクトリにformsRecorder.jarが存在しない場合は、トランザクション監視を行えるようにFormsサーバーを構成する必要があります。formsRecorder.jarがFormサーバーのアーカイブ・ディレクトリ内に存在していることを確認したら、ステップ1に戻って、再度記録を試行します。

  4. Javaの.policyファイルに関する例外がJavaコンソールに表示された場合は、そのファイルをチェックし、そのファイルの内容が十分なものであり、そのファイルの場所が正しいことを確認します。エラーが検出された場合は、エラーを解決し、記録を再度試行する必要があります。

  5. それでも記録に失敗する場合、Enterprise Manager証明書がセキュアなサイトにインポートされているかどうかを確認します。証明書がインポートされていない場合は、インポートして、再度記録を試行します。

24.11.2 Webトランザクションの検証およびトラブルシューティング

この項では、Webトランザクションの記録および再生中に発生する可能性のある一般的なエラーについて説明します。

  1. シナリオ: 「サービス・テストの検証」で「接続の確立中にタイムアウトが発生しました -- http://..../」と表示されます。

    可能性のある原因: ビーコンはプロキシ・サーバーを介してのみ該当するURLにアクセスできますが、その構成が実行されていません。

    解決方法: 「すべてのターゲット」ページで、ビーコンを選択し、「構成」をクリックして、ビーコンのプロキシ設定を実行します。

  2. シナリオ: 「サービス・テストの検証」で「認証が必要です -- https://...../」と表示されます。

    可能性のある原因: Basic認証情報が自動的に記録されていません。

    解決方法: このエラーを解決するには、次の手順に従います。

    1. 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックします。

    2. Basic認証情報(ユーザー名、パスワードおよびレルム)をすべて入力します。


      注意:

      レルムは、通常、ブラウザの認証ダイアログ・ボックスの中の「ユーザー名」ラベルの上に表示されます。

  3. シナリオ: 「サービス・テストの検証」で「sun.security.validator.ValidatorException: 信頼できる証明書が見つかりません -- https://....../。」と表示されます。

    可能性のある原因: ビーコンがこのSSL証明書を認識していません。

    可能性のある解決方法: 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックします。「拡張プロパティ」で、「SSL証明書の認証」「いいえ」に設定します。

  4. シナリオ: 「サービス・テストの検証」で、「https://....../に対しタイムアウト値が300000を超えました。レスポンス時間 = 3000000」と表示されます。

    可能性のある原因: テストが複雑すぎるため、割り当てられた時間内に完了していない可能性があります。または、サーバー側に、パフォーマンスの問題が実際に存在する可能性もあります。

    可能性のある解決方法: 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックします。サーバーのパフォーマンス上の問題でない場合は、「拡張プロパティ」の下の、タイムアウト値を増やします。

  5. シナリオ: 「サービス・テストの検証」オプションによると、サービスは停止中ですが、Webアプリケーションは稼働しており、Webトランザクションを正常に再生できることが報告されます。

    可能性のある原因: 該当するWebアプリケーションは、Internet ExplorerまたはMozillaベースのブラウザとのみ互換性があります。

    可能性のある解決方法: 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックします。「拡張プロパティ」の下で、「User-Agentヘッダー」Mozilla/4.0(compatible; MSIE 6.0; Windows NT 5.1)OracleEMAgentURLTiming/3.0に設定します。


    注意:

    Enterprise Manager 10.2.0.4以上の場合、この「User-Agentヘッダー」は、Webトランザクションの記録中に自動的に設定されます。

  6. シナリオ: 「テスト・パフォーマンス」ページに、ステップ・メトリックが表示されません。

    可能性のある原因: デフォルトでは、トランザクション・レベルのメトリックのみが収集されます。

    可能性のある解決方法: 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックして、「データの粒度」を「ステップ」に設定します。