17 Enterprise Managerの拡張

エンタープライズ環境は、OSプラットフォーム、ハードウェア、ソフトウェア、ネットワーク、ストレージ・デバイスなど、幅広いコンポーネントから構成されています。これらすべてのコンポーネントが連携して動作することによって、エンタープライズの業務を最適に遂行し、ビジネス上重要な意思決定を行うための情報を提供するために必要な重要情報および機能が提供されます。Oracle Enterprise Manager Grid Controlでは、様々なコンポーネントの監視および管理が即時利用可能ですが、環境に固有のサード・パーティ製のコンポーネントまたはカスタム・アプリケーションの監視が必要な場合もあります。たとえば、このリリースでは、WebLogicおよびWebSphereアプリケーション・サーバーをシームレスに監視できます。追加プラグインも現在開発中であり、完成次第発表の予定です。

また、オラクル社およびパートナが使用するものと同一のメカニズムでEnterprise Managerを拡張し、モジュール方式の管理プラグインを介してカスタム・コンポーネントを監視できます。プラグインの定義後は、Enterprise Manager Grid Controlコンソールを使用し、新しいプラグインをエンタープライズ環境全体にデプロイします。

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

Enterprise Manager拡張の利点
管理プラグインの開発
管理プラグインのユーザー・インタフェース

Enterprise Manager拡張の利点

追加コンポーネントを監視するためのEnterprise Managerの拡張には、次のような利点があります。

管理情報の単一コンソールへの一元化: 管理プラグインで定義されたコンポーネントは、デプロイされるとGrid Controlコンソールに自動的に表示されます。環境内のすべてのターゲットを監視可能になり、エンタープライズ全体を統合して表示でき、すべてのコンポーネントを1箇所で監視し、管理できるようになります。
Enterprise Managerの監視、管理機能のOracle以外のコンポーネントへの拡張: 新たに追加されたコンポーネントは、アラート、ポリシー、ブラックアウト、監視テンプレート、グループやシステム、構成管理、およびエンタープライズ・レポートなどのEnterprise Managerの強力な監視、管理機能を自動的に継承します。
統合的なサービスレベル管理: Enterprise Manager Grid Controlですべてのエンタープライズ・コンポーネントを管理することで、Enterprise Manager Grid Controlが提供するサービスレベル管理機能を十分に活用できます。

管理プラグインの開発

管理プラグインを使用して、Enterprise Managerが監視するコンポーネントの新たなクラスを簡単に指定できます。これにより、Oracle以外のコンポーネントをGrid Controlコンソールからシームレスに監視および管理できるようになります。新たな管理プラグインを作成後、エンタープライズ環境内の管理エージェントにデプロイできます。

Enterprise Manager拡張の完全なライフサイクルは、5つのステージから構成されます。

管理プラグインの設計。
プラグインの開発。
プラグインの検証。
ポータブルなアーカイブ・ファイルとしての、プラグインのパッケージ化。
Enterprise Manager環境全体への管理プラグインのデプロイ。

Oracle Management Agentについて

管理プラグインの開発に必要なことを理解するには、Oracle Management Agentのアーキテクチャについて学習ずることが重要です。Oracle Management Agentは各ホストにデプロイされ、ホスト上のすべてのコンポーネントの監視をします。管理エージェントからは、Oracleデータベースなどのデフォルトのターゲット・タイプの監視を即時実行可能です。特定のターゲット・タイプ監視のため、エージェントは次の2つのXMLファイルを使用します。

ターゲット・タイプのメタデータ・ファイル: このターゲット・タイプで監視する必要があるメトリック、およびそれらのメトリックを取得するメソッドを指定します。
ターゲット・タイプのデフォルト収集ファイル: 各ターゲット・メトリックのデフォルトの収集間隔およびアラートのしきい値を指定します。

各メトリックに関して、管理エージェントは fetchletを使用して適切なデータを取得します。fetchletはパラメータ化されたデータ・アクセス・メカニズムであり、入力引数を指定してフォーマット化されたデータを返します。使用可能なfetchletのリストを次に示します。

表17-1 Fetchlet

Fetchlet	説明
OSコマンド	標準アウトプット・データ・ストリームを返すOSコマンドを（個別に、またはスクリプトから）実行し、メトリック・データを取得します。
SQL	Oracleデータベース上で指定されたSQL文を、指定されたユーザーとして実行します。
JDBC	JDBCが有効な任意のデータベースに対してSQL文を実行します。
SNMP（v.1）	オブジェクト識別子（OID）のリストを指定し、対応するインスタンスに対する所定のホスト上のSNMPエージェントをポーリングします。オブジェクト識別子（OID）はMIB変数インスタンスまたは複数のインスタンスを持つMIB変数に対応します。
HTTP Data	URL上のウェブ・サーバーにアクセスし、返されたデータを解析します。
URLXML	指定されたURLのXMLコンテンツを取得し、指定されたパターンに基づいて情報を抽出します。
WBEM	CIMOMにアクセスし、指定されたCIMクラスを使用して要求された情報を取得します。
JMX	JMX対応のサーバーからデータを取得します。
Java Wrapper	Javaコードを実行し、データを返します。
SQL Timing	SQL操作のタイミングを調整します。
URL Timing	基準となるページ・ソースのみではなく、ページ内のフレームや画像のタイミングも調整し、指定されたURLのコンテンツを取得します。

エージェントはターゲット・タイプのデフォルト収集ファイルの情報を使用し、各ターゲットに対して収集の必要なメトリック、および対応する収集頻度を定義します。続いて、ターゲット・タイプのメタデータ・ファイルの情報を使用し、データの収集方法を決定します。この情報に基づいて、エージェントは適切なfetchletを使用し、監視ターゲットからデータを取得します。

管理プラグインの設計

管理プラグイン作成プロセスの設計ステージでは、新しいコンポーネントを正確に監視し、管理するための監視パラメータの定義が必要になります。次を定義します。

収集する必要があるパフォーマンス・メトリックと構成メトリックの識別。
各メトリックの収集頻度の決定。どのメトリックも、少なくとも5分に1回は収集するよう設定することをお薦めします。
顧客固有の運用慣習に基づいた、メトリックのデフォルトの警告しきい値および/またはクリティカルしきい値の指定。しきい値を超えると、Enterprise Managerはアラートを生成し、管理者に潜在的な問題の可能性を通知します。

管理プラグインの開発

設計フェーズで識別された要件に基づくプラグイン開発には、次の作業が必要となります。

各メトリックについて、メトリックの公開に適切なコンポーネントレベルのAPIを決定します。
特定のメトリックの取得に使用したメソッドを、エージェントとともに提供されたFetchletにマッピングし、メトリックの取得に適切なスクリプトを記述し、fetchletの入力パラメータを決定します。たとえば、OS fetchletにはOSスクリプトが、URL Timing fetchletにはURLパラメータが必要です。
新しいターゲット・タイプの監視にエージェントが使用する2つのXMLファイル（ターゲット・タイプ定義ファイルとデフォルト収集ファイル）を定義します。このために、指定されたXMLフォーマットでの適切なメトリック、メトリック収集メソッド、収集頻度およびメトリックのしきい値の定義を行います。

次の例は、CPU使用率収集のメトリック宣言例を示す、ターゲット・タイプのメタデータ・ファイルからの抜粋です。OSコマンドfetchletを使用し、既存のPerlスクリプトを実行してメトリック値を取得します。

例17-1 ターゲット・タイプのメタデータ・ファイルからの抜粋

<Metric NAME="Load" TYPE="TABLE"> 

   <TableDescriptor> 

       <ColumnDescriptor NAME="CPU Utilization" TYPE="NUMBER"/> 

   </TableDescriptor> 

   <QueryDescriptor FETCHLET_ID="OS"> 

<Property NAME="scriptsDir" SCOPE="SYSTEMGLOBAL"> scriptsDir     </Property> 

<Property NAME="script" SCOPE="GLOBAL"> %scriptsDir% /cpu_util.pl </Property>

</QueryDescriptor>

</Metric>

ターゲット・タイプのメタデータ・ファイル内でメトリックを定義後、メトリック収集頻度と適切なメトリックしきい値を定義します。次に、MyDatabaseターゲット・タイプのコレクション・ファイル例を示します。この例では、CPU使用率は10分ごとに収集され、メトリック値が90パーセントより大きい（GT）場合にクリティカル・アラートが生成されます。

例17-2 ターゲット・タイプのデフォルト収集ファイル

<TargetCollection TYPE="MyDatabase">

  <CollectionItem NAME="Load">

    <Schedule>

        <IntervalSchedule INTERVAL="10"/>

    </Schedule>

    <Condition column_name ="CPU Utilization" critical="90" operator="GT"/>

  </CollectionItem>

</TargetCollection>

プラグインの検証

Enterprise Managerフレームワークを使用した新しいターゲット・タイプの統合には、XMLが正確であることがきわめて重要です。つまり、ターゲット・タイプのメタデータ・ファイルおよびデフォルト収集ファイルが構文と構造の両方で正しいものであることが重要です。また、新しいターゲット・タイプのランタイム・データ収集のシミュレーションを行い、正しいデータが収集されることと、パフォーマンスへの悪影響がないことを確認する必要があります。検証プロセスを簡略化するために、Enterprise ManagerはILINTというツールを提供しています。

プラグインのパッケージ化

管理プラグインに関連したすべてのファイル（メタデータ・ファイル、監視スクリプト、レポート・ファイル）を、EMCLIを使用して管理プラグイン・アーカイブ（MPA）としてパッケージ化します。MPAは、1つ以上の管理プラグインを含む.jarファイルです。これにより、プラグインのインポートおよびエキスポートを簡単に実行できます。

EMCLIを実行するには、EMCLIクライアントがインストールされているマシンでターミナル・ウィンドウを開き、add_mp_to_mpa動詞を実行します。次に、動詞の使用例を示します。

例17-3 EMCLIを使用した管理プラグイン・アーカイブの作成

 emcli add_mp_to_mpa

       -mpa="/my_dir/my_new_type.jar"

       -mp_version="2.0"

       -ttd="/my_dir/ttd/new_type.xml"

       -dc="/my_dir/dc/new_type.xml"

       -file="MONITORING_SCRIPT:/my_dir/script1.pl"

       -file="MONITORING_SCRIPT:/my_dir/script2.pl"

       -func_desc="Management Plug-in to define target type new_type"

1つ以上の管理プラグインをアーカイブ・ファイルに追加すると、プラグインをエンタープライズの管理エージェントにデプロイする準備が整います。

管理プラグインのデプロイ

管理プラグイン・アーカイブ・ファイルの作成後、Enterprise Managerを使用して新しい管理プラグインを簡単にデプロイできます。デプロイ操作はGrid Controlコンソールから直接実行可能で、次の3つの手順で実行されます。

管理プラグインをGrid Controlコンソールにインポートします。

図17-1 管理プラグインのインポート・ページ

「図17-1 管理プラグインのインポート・ページ」の説明

インポート後、プラグインは「管理プラグイン」ページに表示され、複数の管理プラグインに同時にデプロイできます。同時にデプロイする管理プラグインの数に上限はありません。

図17-2 「管理プラグイン」ページ

「図17-2 「管理プラグイン」ページ」の説明
管理プラグインを適切なエージェントにデプロイします。

管理プラグインは、本番環境を停止することなく、複数のエージェントに同時にデプロイできます。デプロイするエージェント数に上限はありません。Enterprise Managerは適切なメタデータ・ファイルと監視スクリプトを、選択されたエージェントに自動的にコピーします。

図17-3 「管理プラグインのデプロイ」ページ

「図17-3 「管理プラグインのデプロイ」ページ」の説明

管理プラグインのデプロイ後、管理エージェントは新しいタイプのターゲットを監視できるようになります。
エージェントの管理プラグインを検出します。

管理プラグインのデプロイ後は、エージェントは新しいターゲット・タイプの監視方法を認識します。この時点で残っている作業は、エージェントに新しいターゲット・タイプの1つ以上のインスタンスを監視するよう指示することです。これには、「エージェント」ホームページで、データベースのSIDやユーザー名など少数のターゲット・プロパティを指定してターゲットを検出することが含まれます。

管理プラグインのユーザー・インタフェース

Enterprise Managerが管理する各ターゲットにはデフォルトのホームページがあります。このページには情報が統合されており、状態とパフォーマンス・ステータスが一目でわかるようになっています。このホームページからは、構成情報、およびブラックアウト、監視構成、アラート履歴などの管理および監視機能に直接アクセスできます。この機能豊富なユーザー・インタフェースは、カスタム・コードなしで、管理プラグインから即時利用可能です。

図17-4 ターゲットのデフォルト・ホームページ

「図17-4 ターゲットのデフォルト・ホームページ」の説明

ターゲットのデフォルト・ホームページのリアルタイム・レポートによる拡張

Enterprise Managerは、情報パブリッシャと呼ばれる強力なレポート・フレームワークを提供しており、このフレームワークを使用して次の操作を実行できます。

Grid Controlコンソールを使用するか、情報パブリッシャのPL/SQL APIを使用して管理リポジトリに対するカスタム・レポートを作成できます。
スケジュールに基づいてレポートを生成し、ユーザー・コミュニティ全体でこれを共有します。
即時利用可能な監視、構成およびサービスレベルのレポートを作成できます。

管理プラグインの開発時には、Information PublisherのPL/SQL APIを使用して管理レポート定義を開発することによって、ターゲットのデフォルト・ホームページで使用可能な情報を拡張できます。これらのレポート定義は、プラグインとともにパッケージ化でき、ターゲットのデフォルト・ホームページの「レポート」タブから使用可能です。