| Oracle® Enterprise Manager Cloud Control管理者ガイド 13c リリース2 E78869-07 |
|
 前へ |
 次へ |
サービスを作成すると、サービスの可用性定義、システムとサービスの関連付け、パフォーマンスと使用状況のメトリックの定義などが行えます。ここでは、以下の項目について説明します。
可用性定義
根本原因分析の構成
システム・アソシエーション
サービス・テストとビーコン
テストの要約
テストのモニタリング設定
使用状況メトリック
パフォーマンス・メトリック
サービス・レベル・ルールの編集
サービスの可用性は、ユーザーがいつでもサービスを使用できるかどうかを示します。何をもって可用性とするかの基準は、アプリケーションによって異なります。たとえば、カスタマ・リレーションシップ・マネジメント(CRM)・アプリケーションでは、可用性はユーザーがアプリケーションに正常にログオンして売上レポートにアクセスできることを意味します。電子メール・アプリケーションの場合は、ユーザーがアプリケーションにアクセスして電子メールを送受信できることが可用性です。
可用性を定義するサービスをクリックし、「サービス・ホーム」ページにナビゲートします。「汎用サービス」メニューから、「管理」、「可用性」の順に選択します。サービスの可用性は、次のことに基づいて判別できます。
サービス・テスト: エンド・ユーザーの重要な機能の可用性によってサービスの可用性が決定される場合、このオプションを選択します。このような重要な機能の例として、電子メールへのアクセス、販売レポートの生成、オンライン銀行業務トランザクションの実行などがあります。サービス・テストを定義する場合、ビジネス・プロセスの重要な機能に最も適したプロトコルと、ユーザー・コミュニティの場所に適したビーコンの場所を選択します。
標準プロトコルを使用して1つ以上のサービス・テストを定義し、1つ以上のサービス・テストをキー・テストとして指定できます。キー・テストは、様々なユーザー・コミュニティ内で1つ以上のキー・ビーコンによって実行されます。また、「キー・サービス・テスト」チェック・ボックスを選択し、サービス・テストがキー・テストであると指示することもできます。サービスの可用性計算には、キー・サービス・テストのみが使用されます。次にビーコンを選択し、キー・テストの実行およびサービスの可用性判断に使用できます。定義に応じて、すべてのキー・サービス・テストが成功しているか、または1つ以上のキー・サービス・テストが成功している場合にサービスが利用可能とみなされます。ビーコンの詳細とその作成方法については、「ビーコンのデプロイおよび使用」を参照してください。
どの場合にサービスを利用可能とするべきかを指定できます。
注意:
サービス・テストは、1つ以上のキー・ビーコンによって実行できる場合に使用可能であるとみなされます。キー・ビーコンがない場合、サービス・テストのステータスは不明になります。
システム: サービスの可用性は、サービスをホストしている基盤のシステムまたは選択したシステム・コンポーネントに基づいている場合もあります。可用性が選択したシステム・コンポーネントに基づく場合、サービスの実行に対して重要なコンポーネントを選択し、サービスの可用性を決定するために使用するキー・コンポーネントとして1つ以上のコンポーネントを指定します。可用性の定義に応じて、1つ以上またはすべてのキー・コンポーネントが起動して実行されているかぎり、サービスは使用可能であると判断されます。
どの場合にサービスを利用可能とするべきかを指定できます。
すべてのキー・コンポーネントが稼働中(デフォルト)
1つ以上のキー・コンポーネントが稼働中
また、1つ以上のコンポーネントを、サービスの可用性計算に使用されるキー・システム・コンポーネントとしてマークすることもできます。キー・システム・コンポーネントは、可能性のあるサービス失敗の根本原因特定で使用されます。詳細は、「根本原因分析の構成」を参照してください。
サブ・サービス: 集約サービスの場合、可用性は、サブ・サービスの可用性にも基づきます。すべてのサブサービスまたは単一のサブサービスの可用性に基づいて、可用性を判別するかを指定できます。
根本原因分析(RCA)を使用して、一連のイベントをフィルタ処理し、システム、サービスまたはアプリケーションのより高レベルな問題の原因を特定できます。RCAは、根本原因に見えるが、問題の実際の根本原因の副作用または兆候でしかない明らかなパフォーマンスの問題を排除するために役立ち、問題領域を簡単に識別できます。RCAの結果は、現在停止しているサービスのホームページまたは「トポロジ」ページ上から確認できます。トポロジ・ページでは、サービス、システムおよびコンポーネントの依存関係がグラフィカルに表示されます。トポロジ・ページでは、サービスの失敗の原因であるターゲットが強調表示されます。
RCAを実行する前に、次の内容を選択できます。
サービス失敗時に自動的に実行されるようにツールを構成します。
「分析モード」(デフォルト)を「手動」に変更してRCAを無効化します。
サービスのコンポーネント・テストおよび個々のテストのしきい値を定義します。
根本原因分析を構成する手順は、次のとおりです。
根本原因分析(RCA)は、サービスに関連する大量のデータをフィルタ処理し、サービスの可用性に影響する最も重要なイベントの発生を識別できることから、大きな価値をもたらします。Enterprise Managerで独自のサービスを構成する場合、RCAを最大活用することを考慮および計画して、サービスを定義することが重要です。
RCAを最大活用する上で最初に考慮が必要な項目は、他のサービスまたはシステム・コンポーネントに対してサービスが持つ一連の依存性です。タスクを達成するためにサービスが使用するすべてのシステム・コンポーネントを必ず識別してください。キー・コンポーネントを省略し、サービスが失敗した場合、RCAでは、そのコンポーネントを可能性のある原因として識別できなくなります。逆に、実際にはサービスが依存していないコンポーネントをサービス定義に含めると、RCAで、そのコンポーネントがサービス失敗の原因として誤って識別される場合があります。
サービス依存性を構築する場合、Enterprise Managerでサポートされている集約サービスの概念を利用することを念頭に置いてください。これにより、それぞれ独自の一連の依存性を持つ、より小さなサブサービスにサービスを分割できます。RCAはサブサービス(依存しているサービス)のステータスのみではなく、サブサービスが依存するシステム・コンポーネントまたはサービスも同様に考慮します。
RCAを最大限活用する上で次に考慮が必要な項目は、コンポーネント・テストの使用です。サービスが依存するシステム・コンポーネントを定義する際、これらのコンポーネントには、コンポーネント自体が失敗しなくても、サービス失敗となる部分が存在する場合があることを考慮します。コンポーネント・テストにより、ターゲット自体のステータスのみでなく、その主要部分のステータスもRCAでテストできます。
RCAシステムでは、キー・コンポーネントで使用可能なメトリックに基づくコンポーネント・テストを作成できます。これには、コンポーネント用に作成したユーザー定義メトリックが含まれるため、サービスが失敗した場合は、そのコンポーネントの各部分をRCAによってきわめて柔軟にテストできます。RCAは2つのモードで実行するように構成できます。サービスの失敗に基づき自動的に実行されるか、手動で実行するように構成することができます。モニター対象のサービスの予想されるサービス・レベル合意のパーセントに基づいてモードを決定できます。予想されるサービス・レベル合意のパーセントが高い場合、自動モードを選択し、発生する可能性のあるエラーや失敗の根本原因を、容易に検知できるようにする必要があります。
システムとは、相互に機能することでアプリケーションをホスティングする、一連のインフラストラクチャ・コンポーネント(ホスト、データベース、アプリケーション・サーバーなど)を指します。たとえば、電子メール・アプリケーションはデータベース、リスナー、アプリケーション・サーバー、およびこれらのコンポーネントが常駐するホストによってホスティングされています。
サービスを定義すると、システム内のコンポーネント間の接続または相互関係を論理的に表すため、コンポーネント間の関連付けを指定できます。たとえば、関連付けを定義し、データベースとリスナー間の関連を示すことができます。これらの関連付けはシステムのトポロジ・ビューアに表示されます。一部のデータ・センターには、1つのアプリケーションまたはサービス専用のシステムがあります。その他のデータ・センターのシステムは複数のサービスをホスティングします。データ・センターのセットアップ方法に基づいて、1つまたは複数のサービスをシステムに関連付けできます。
このページでは、このサービスをホストするために使用するEnterprise Managerシステムを選択できます。次の操作を実行できます。
システムの追加または選択
選択したシステムの変更または削除
システムを選択してから、1つ以上のシステム・コンポーネントをキー・コンポーネントとしてマークします。このキー・コンポーネントは、サービスの実行に不可欠です。このキー・コンポーネントを使用して、サービスの可用性の判断や、サービスの障害の原因の識別を行います。
各サービスについて、頻度(アプリケーションに対してサービスがトリガーされる頻度を決定)およびパフォーマンスしきい値を定義できます。サービスがそのパフォーマンスしきい値を超えると、アラートが生成されます。
メトリックおよびしきい値を定義するには、「汎用サービス」メニューから、「管理」、「テストのモニタリング設定」の順に選択します。「メトリックとポリシー設定」ページが表示されます。「モニタリング設定」リンクをクリックします。「モニタリング設定 - しきい値」ページが表示されます。
表示方法 - メトリック、ビーコン - この表示で、「ビーコンのオーバーライドの追加」をクリックすると、1つ以上のビーコンのデフォルトのしきい値を上書きできます。この場合、上書きのないビーコンにのみデフォルトのしきい値が使用されます。サービスに追加される新しいビーコンは、デフォルトのしきい値を使用します。「メトリックの追加」をクリックして、1つ以上のメトリックを追加します。
表示方法 - ビーコン、メトリック - この表示で、「デフォルト」アイコンをクリックすると、特定のメトリックの「編集」および「表示」モード間の切替えができます。「編集」モードでは、メトリックのパラメータを変更できます。特定のビーコンのメトリックのパラメータを変更することもできます。「表示」モードでは、メトリックのデフォルト・パラメータが使用されます。
これらの手順とは別に、Webトランザクション用にステップおよびステップ・グループのレベルでもメトリックを定義できます。次のいずれかの表示を選択できます。
表示方法: ステップ、メトリック、ビーコン: この表示で、「ビーコンのオーバーライドの追加」をクリックすると、1つ以上のビーコンのデフォルトのしきい値を上書きできます。この場合、上書きのないビーコンにのみデフォルトのしきい値が使用されます。新しくWebトランザクションに追加されるビーコンには、デフォルトのしきい値が使用されます。「メトリックの追加」をクリックして、1つ以上のメトリックのしきい値を定義します。サービス・テストについて、「データの粒度」プロパティの値が「トランザクション」に設定されている場合にのみインシデントが生成されます。Webトランザクションのプロパティの詳細は、Enterprise Managerのオンライン・ヘルプのサービス・テストの作成または編集、Webトランザクションのヘルプ・ページを参照してください。
表示方法: ステップ、ビーコン、メトリック: この表示で、「デフォルト」アイコンをクリックすると、特定のメトリックの「編集」および「ビュー」モード間の切替えができます。「編集」モードでは、特定のビーコンのメトリックのパラメータを変更できます。「表示」モードでは、メトリックのデフォルト・パラメータが使用されます。「データの粒度」プロパティの値が「ステップ」に設定されている場合のみ、インシデントが生成されます。
デフォルトの収集頻度および収集プロパティを定義するには、「モニタリング設定」ページの「収集の設定」タブをクリックします。次の操作を実行できます。
すべてのビーコンのデフォルトの収集頻度を指定します。特定のビーコンの収集頻度を上書きするには、「ビーコンのオーバーライドの追加」をクリックします。
1つ以上のビーコンの収集プロパティおよび対応する値を指定します。
収集間隔およびパフォーマンスしきい値の定義の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。
サービス・テストを追加し、これらのサービス・テストを実行する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
proxyUser、proxyPwd、proxyRealmおよび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テスト・タイプの作成について説明しています。
ビーコンは、管理エージェントがサービスをリモートでモニターできるターゲットです。ビーコンは、常に1つ以上のサービスをモニターできます。
注意:
ビーコンを作成する前に、Oracle Beacon 12.1.0.2以上のプラグインがデプロイされていることを確認する必要があります。
1つ以上のサービス・テストを実行するビーコンを作成するには、次の手順に従います。
この項では、その他のビーコン関連の構成タスクについて説明します。
ビーコンのSSL証明書の構成: HTTPS URLを使用してSecure Sockets Layer(SSL)でURLをモニターする際にビーコンを使用する場合、そのURLが存在するWebサイトで使用されている認証局を認識するようにビーコンを構成する必要があります。
ポート・チェッカ・テストでSSLオプションを使用するには、管理エージェントのモニタリング・ウォレットに証明書を追加する必要がある場合があります。追加証明書を追加するには、次の手順を実行します。
Base64encoded X.509 (.CER)形式の、b64SiteCertificate.txtファイル内の証明書を取得します。(ファイル名は構成により異なる可能性があります)。ファイルの内容の例を次に示します。
------BEGIN CERTIFICATE-------------- MIIDBzCCAnCgAw... ...... base 64 certificate content ..... ------END CERTIFICATE-----------------
ファイルは管理エージェントのホーム・ディレクトリに<AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txtファイルとして保存されています。
b64InternetCertificate.txtファイルが作成されていない場合は、エージェントのコア・ディレクトリとインスタンス・ディレクトリに作成します。
<AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txt <AGENT_BASE>/core/12.1.0.2.0/sysman/config/b64InternetCertificate.txt
両方のb64InternetCertificate.txtファイルの末尾に、Base64encoded X.509証明書を追加します。BEGIN行とEND CERTIFICATE行の両方を含めます。
管理エージェントを再起動します。
専用ビーコンの構成: エージェントのビーコン機能には、内部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トランザクション(ブラウザ)サービス・テストは同一のマシン上では再生できません。
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ユーザーズ・ガイドを参照してください。
zipファイルは自己完結で、次の内容を含んでいることを確認する必要があります。
<txn name>.jwg: 実行エンジンで実行される、コンパイル済の実行可能スクリプトを含むアーカイブ・ファイル。
script.java: 実際のスクリプトJavaソース・ファイル。
<script name>-descriptor.xml: ステップ階層を示す。
script.xml: データバンクの変数を示す。
modules.properties: エンジンに必要な内部モジュールを示す。
Assets.xml: データバンク・ファイル、サブ・スクリプト・オブジェクト・ライブラリなどを含む、ルート・スクリプトにより使用される依存するリソースを示す。
データバンク・ファイル: 様々な変数値の代入時にスクリプトにより使用されるデータバンク・ファイル。
オブジェクト・ライブラリ: ユーザー定義のオブジェクト識別ルールおよび名前を含むライブラリ。これは機能テスト・スクリプトにのみ適用されます。
依存スクリプト: 他のスクリプトをコールできるスクリプト。
ATSサービス・テストを作成するには、次の手順に従います。
注意:
コマンドライン・ユーティリティ(EM CLI)から、リポジトリで使用可能なサービス・テストを使用してATS Testインスタンスを作成し、カスタマイズする方法は、『Oracle Enterprise Managerライフサイクル管理ガイド』を参照してください。
ビーコンの領域割当てが枯渇すると、ビーコンがATSスクリプトに記録された値を再生できず、次のエラーが表示される場合があります。
ビーコンの同期化はエージェントに必要なファイルを転送しませんでした。エージェントのログを確認してください。ファイル <directory>
この問題に対処するには、emd.propertiesファイルのapplicationMetadataQuotaエージェント・プロパティに高い値を設定する必要があります。デフォルト値は500MBですが、大規模なファイルが複数アップロードされる場合はこの値を増やす必要があります。プロパティの値を変更したら、管理エージェントを再起動する必要があります。
注意:
ATSファイルは/EMSTATE/sysman/ApplicationState/beaconディレクトリにあります。
ファイルの命名規則: <Txn guid>_<beacon guid>.zip
ATS関連のログ(gcagent.log、gcagent_error.log、emagent.nohup)は、EMSTATE/sysman/logフォルダにあります。
記録されたスクリプト入力をパラメータ化し、データ駆動型テスティングを実行できます。パラメータ化できる入力の例には、ユーザー名、ログイン・ページでのパスワード、検索フィールドに入力されたデータ、記録されたナビゲーションまたはユーザー・アクションなどが含まれます。
スクリプト入力のパラメータ化にデータ・ソースとしてデータバンクを使用できます。データバンクは、スクリプト・パラメータに対する入力を指定する、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
データバンク・レコードを使用するには、次の手順に従います。
スクリプト・プロジェクトを開くか、作成します。
アセット・スクリプト・プロパティのスクリプトで使用するデータバンクを構成します。
データバンク・レコードを使用するスクリプト・ノードを選択します。
「スクリプト」メニューを選択した後、「追加」サブメニューから「その他」を選択します。
「一般」ノードを開いて、次のデータバンク・レコードの取得を選択します。「OK」をクリックします。
レコードを取得するデータバンク・ファイルを指定するデータバンクの別名avitekを選択します。
「OK」をクリックします。「GetNextDatabankRecord:databank alias」ノードがスクリプトに追加されます。Javaコード・ビューでは、次に示すように、getDatabank("データバンクの別名").getNextDataBankRecord()メソッドがスクリプト・コードに追加されます。
getDatabank("avitek").getNextDatabankRecord();
スクリプトで使用するデータバンクを構成した後、データバンク・ファイルを特定のスクリプト・パラメータにマップできます。データバンク・フィールドをスクリプト・パラメータにマップするには、次の手順に従います。
{{db.avitek.Username,fred#@golf.com}}に変更されます。{{db.avitek.Password,weblogic}}に変更されます。データバンクの設定の詳細は、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>
スクリプト内のURLに使用する変数を作成できます。スクリプトのベースURLを変更する必要がある場合、URLをパラメータ化すると、新しいURLを使用するようにスクリプトを短時間で再ベースライン化できます。
URLをパラメータ化するには、次の手順に従います。
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と入力できます。
ビーコンのオーバーライド機能を使用して、異なるビーコンで実行しているテスト用に異なる変数値を指定できます。次の手順を実行します。
Databank_Alias>."<COLUMN_NAME>"="VALUE",<Databank_Alias>."<COLUMN_NAME>"="VALUE",...
次に例を示します。
FusionCredentials."host"="fs-aufsn4x0cxf",FusionCredentials."hostlogin"="login-aufsn4x0cxf",FusionCredentials."username"="faadmin",FusionCredentials."password"="fusionfa1"
ATSテスト・スクリプトを更新するには、次の手順に従います。
.csvファイルをスプレッドシート・エディタを使用して編集し、変更内容を保存します。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())}}のようになります。
パフォーマンス・メトリックは、サービスのパフォーマンスの測定に使用されます。サービス・テストが、このサービスに対して定義されている場合、そのサービス・テストの実行の結果行われるレスポンス時間の測定値が、サービスのパフォーマンス・メトリックの基準として使用されます。もう1つの方法として、基礎となるシステム・コンポーネントからのパフォーマンス・メトリックを使用してサービスのパフォーマンスを判断できます。
パフォーマンス・メトリックは、各リモート・ビーコンに対してサービス・テストがどの程度適切に実行されているかの判別に役立ちます。一般に、ローカル・ビーコンは、Webアプリケーション・ホストに対してローカルなので、非常に有効で一貫したレスポンス時間を備えています。リモート・ビーコンは、アプリケーションのエンドユーザーの実際のレスポンス時間を反映したデータを提供します。
次の操作を実行できます。
サービス・テスト用のパフォーマンス・メトリックを追加できます。メトリックを選択後、次の内容を選択できます。
1つのビーコンからのメトリック値を使用します。サービスのパフォーマンスがある特定の場所のパフォーマンスに基づくようにする場合に、このオプションを選択します。
複数のビーコン間のメトリックを集計します。複数の場所のパフォーマンスを考慮する場合に、このオプションを選択します。このオプションを選択した場合、次の中から適切な集計関数を選択する必要があります。
表29-1 ビーコン集計関数
| 関数 | 説明 |
|---|---|
すべてのビーコン間で集計されたデータからのメトリックの最大値が使用されます。すべてのビーコン間で最もパフォーマンスの低いものを測定するには、この関数を使用します。 |
|
すべてのビーコン間で集計されたデータからのメトリックの最小値が使用されます。すべてのビーコン間で最もパフォーマンスの高いものを測定するには、この関数を使用します。 |
|
メトリックの平均値が使用されます。すべてのビーコン間で平均的なパフォーマンスを測定する場合に、この関数を使用します。 |
|
メトリック値の合計が計算されます。各ビーコン間のすべてのレスポンス時間の合計を計算する場合に、この関数を使用します。 |
サービスをホストする基礎となるシステム・コンポーネントのパフォーマンス・メトリックを追加します。ターゲットのメトリックを選択後、次の内容を選択できます。
特定のコンポーネントからメトリックを使用します。サービスのパフォーマンスがある特定のシステム・コンポーネントのパフォーマンスに基づくようにする場合に、このオプションを選択します。このオプションを選択すると、「ルール・ベース・ターゲット・リスト」を選択できます。
複数のコンポーネント間のメトリックを集計します。複数のコンポーネント間のパフォーマンスを考慮する場合に、このオプションを選択します。このオプションを選択した場合、適切な集計関数を選択する必要があります。
表29-2 システム集計関数
| 関数 | 説明 |
|---|---|
すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。 |
|
すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。 |
|
すべてのコンポーネント間のメトリックの平均値が使用されます。 |
|
すべてのコンポーネント間のメトリックの値の合計が計算されます。 |
注意:
システムが削除されると、そのシステムに関連付けられているパフォーマンス・メトリックは収集されません。
定義済のパフォーマンス・メトリックを編集します。サービス・テストベースのパフォーマンス・メトリックの場合は、メトリック値の計算に使用されるビーコン関数を変更できます。システムベースのパフォーマンス・メトリックの場合は、ターゲット・タイプ、メトリック、および集計関数を使用するかどうかの設定を変更できます。また、メトリックのクリティカルしきい値および警告しきい値も変更できます。
定義済のパフォーマンス・メトリックを削除します。
注意:
集約サービスにパフォーマンス・メトリックを定義すると、次の操作が可能です。
単一のサブ・サービスからのパフォーマンス・メトリックを追加します。
複数のメトリックの統計による集計を指定します。
メトリックを選択した後、インシデントのトリガーに使用されるしきい値を設定したり、必要がなくなったメトリックを削除できます。
ルール・ベース・ターゲット・リストは、システム・ベースのパフォーマンス・メトリックおよびシステムの直接メンバーに適用可能です。選択したシステム・コンポーネントを照合するルールを定義できます。ユーザー指定のルールに一致するシステム・コンポーネントは、メトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で追加されると、このコンポーネントもメトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で削除されると、このコンポーネントは、メトリック評価プロセスに参加しません。定義するルールは次のものに基づきます。
すべて(すべてのシステム・コンポーネント)
次を含む(指定された基準を含む任意のコンポーネント)
次で始まる(指定された基準で始まる任意のシステム・コンポーネント)
次で終わる(指定された基準で終わる任意のシステム・コンポーネント)
次と等しい(指定された基準に一致する任意のシステム・コンポーネント)
使用状況メトリックは、サービスに対するユーザーの要求の測定に使用されます。使用状況メトリックは、サービスをホストする基礎となるシステム・コンポーネントの使用状況に基づいて収集されます。特定のコンポーネントの使用状況をモニターすることも、一連のコンポーネントの平均値、最小値および最大値を統計的に計算することも可能です。たとえば、IMAPサーバーに依存する電子メール・サービスを定義する場合、IMAPサーバーの「合計クライアント接続」メトリックを使用して、この電子メール・サービスの使用状況を表すことができます。使用状況メトリックは、システムと関連付けられたサービスに対してのみ定義できます。次の操作を実行できます。
使用状況メトリックを追加します。ターゲットのメトリックを選択後、次の内容を選択できます。
特定のコンポーネントからメトリックを使用します。特定のコンポーネントの使用状況をモニターする場合に、このオプションを使用します。
複数のコンポーネント間のメトリックを集計します。複数のコンポーネント間の使用状況の統計を計算する場合に、このオプションを使用します。このオプションを選択した場合、適切な集計関数を選択する必要があります。
定義済の使用状況メトリックを編集します。
定義済の使用状況メトリックを削除します。
システム・ターゲットからのメトリックのみを使用状況メトリックとして追加できることに注意してください。テストからのメトリックは使用状況を示さないため、使用状況メトリックとして追加できません。
注意:
集約サービスに使用状況メトリックを定義すると、次の操作が可能です。
単一のサブ・サービスからの使用状況メトリックを追加します。
複数のメトリックの統計による集計を指定します。
使用状況メトリックを選択した後、インシデントのトリガーに使用されるしきい値を設定したり、必要がなくなったメトリックを削除できます。
ルール・ベース・ターゲット・リスト
ルール・ベース・ターゲット・リストは、システム・ベースのパフォーマンス・メトリックおよびシステムの直接メンバーに適用可能です。選択したシステム・コンポーネントを照合するルールを定義できます。これにより、評価のパフォーマンス・メトリックを促進できます。ユーザー指定のルールに一致するシステム・コンポーネントは、メトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で追加されると、このコンポーネントもメトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で削除されると、このコンポーネントは、メトリック評価プロセスに参加しません。定義するルールは次のものに基づきます。
すべて(すべてのシステム・コンポーネント)
次を含む(指定された基準を含む任意のコンポーネント)
次で始まる(指定された基準で始まる任意のシステム・コンポーネント)
次で終わる(指定された基準で終わる任意のシステム・コンポーネント)
次と等しい(指定された基準に一致する任意のシステム・コンポーネント)
