| Oracle® Enterprise Manager拡張ガイド 11gリリース1（11.1.0.1） B61026-01 |
|
 戻る |
 次へ |
各管理プラグインは、Enterprise Managerで監視できる新しいターゲット・タイプを定義します。ターゲット（より具体的にはターゲット・インスタンス）は、エンタープライズ内の監視可能エンティティとして定義できます。監視可能エンティティとして、サーバー上で実行されるアプリケーション、サーバー自体、ネットワークまたはその構成要素があります。Enterprise Managerは、新規ターゲット・インスタンスをEnterprise Manager Grid Controlコンソールから管理フレームワークに追加できるようにすることで、ターゲット・インスタンスの管理を簡略化します。その時点で、Enterprise Managerの監視および管理機能を利用できます。
Enterprise Managerは、システムに対して新規ターゲット・タイプを定義する一連のXMLファイルに依存します。管理プラグインは、Enterprise Managerから特定のターゲットを監視するために必要なすべてのファイルから構成されます。
管理プラグインが定義された後で、Enterprise Managerにインポートされる管理プラグイン・アーカイブに追加する必要があります。アーカイブは、1つ以上の管理プラグインを1つのjarファイル内にカプセル化します。
管理プラグインの作成は、次の5つのステージから構成されます。
管理プラグインの設計
管理プラグインを構成する必要なターゲット・タイプ定義ファイルの開発
ターゲット・タイプ定義の検証
Enterprise Managerコマンドライン・インタフェース（EM CLI）を使用した、移植可能な管理プラグイン・アーカイブ・ファイルへのターゲット・タイプ定義ファイルのパッケージ化
Enterprise Manager環境全体への管理プラグインのデプロイ
実際のプラグイン・ファイルを作成する前に、新規コンポーネントを正確に監視および管理するためにターゲット・タイプに必要なパラメータを定義する必要があります。これには次の作業が含まれます。
収集する必要のあるパフォーマンス・メトリックおよび構成メトリックの識別。
各メトリックの収集頻度の決定。メトリックの収集頻度は5分間に1回を下回らないようにすることをお薦めします。
顧客固有の運用に基づいた、これらのメトリックに対するデフォルトの警告またはクリティカルしきい値、あるいはその両方の指定。しきい値を超えるたびに、Enterprise Managerは、考えられる問題を管理者に通知するアラートを生成します。
特定のタイプのターゲットの監視方法を決定すると、Enterprise Managerに対してこの特定のターゲット・タイプを定義する管理プラグイン・ファイルの作成を開始する準備ができます。ターゲット・タイプを作成するには、ターゲットが何であるかのみでなく、より重要な監視対象（メトリック）および監視の実行方法をEnterprise Managerに対して定義します。
ファイルの場所
次の表に、Enterprise Managerがシステム構成および拡張に使用する主要ファイルをリストします。管理プラグインがエージェントにデプロイされると、必要なファイルがそれぞれのディレクトリの場所にコピーされます。
表2-1 構成ファイルの場所
| 名前 | ディレクトリの場所 | 用途 |
|---|---|---|
|
target_type.xml（ターゲット・タイプの定義に必要） |
AGENT_HOME/sysman/admin/metadata/ |
ターゲット・タイプについて収集/計算するメトリックを定義します。 |
|
target_collections.xml（ターゲット・タイプの定義に必要） |
AGENT_HOME/sysman/admin/default_collection/ |
メトリック・データ収集間隔やデフォルトのアラートしきい値などのメトリック収集パラメータを定義します。通常、メタデータ・ファイル（target_type.xml）とデフォルトの収集ファイルの名前は同一です。 |
|
targets.xml |
AGENT_HOME/sysman/emd/ |
ユーザーがEnterprise Managerフレームワークに追加したターゲット・インスタンスをリストします。このファイルは、Enterprise Managerまたはターゲット・インスタンス・インストーラ・ユーティリティ、あるいはその両方によって生成および更新されます。このファイルは手動で編集しないでください。 |
XML構成ファイルに関連付けられているDTDファイルは、表2-2に示されている場所にあります。
表2-2 Document Type Declarationファイル
| 名前 | ディレクトリの場所 | 用途 |
|---|---|---|
|
AGENT_HOME/sysman/admin/dtds/ |
target_type.xmlファイルに関連付けられているDocumentation Type Declaration（DTD）ファイル |
|
|
AGENT_HOME/sysman/admin/dtds/ |
targets.xmlファイルに関連付けられているDTD |
|
|
TargetCollection.dtd |
AGENT_HOME/sysman/admin/dtds/ |
target_collections.xmlファイルに関連付けられているDTD |
管理プラグインをデプロイすると、Enterprise Managerによってすべてのプラグイン・ファイルが適切な場所に自動的にコピーされます。反対に、管理プラグインを更新または削除する準備ができると、プラグインのアップグレードの場合は適切なファイルが置換され、プラグインがアンデプロイされる場合はファイルが削除されます。
|
重要: 管理プラグインのデプロイ・メカニズムでは、Oracleが提供するメタデータ・ファイルの上書きは許可されていません。 |
Enterprise Managerフレームワークにターゲット・タイプを追加すると、そのターゲット・タイプの任意のインスタンスがEnterprise Manager Grid Controlコンソールからフレームワークに追加された後で、そのターゲット・インスタンスをOracle管理エージェントで監視できるようになります。Enterprise Manager Grid Controlフレームワーク内のすべてのターゲット・タイプは一意である必要があります。ターゲット・タイプを定義し、この情報をOracle管理エージェントに対して使用可能にするには、次の2つのXMLファイルを作成します。
ターゲット・タイプの定義は、公開するメトリックから主に構成されます。ファイルには、特定のターゲット・タイプについて収集されるすべてのメトリックのリスト、および各メトリックの計算方法の詳細が含まれます。
管理リポジトリにメトリック値を定期的にアップロードするか、特定の条件に照らしてこれらの値をチェックするかにかかわらず、各ターゲット・メトリックのデフォルトの収集間隔を定義する必要があります。このファイルでは、違反が発生した場合にイベントをトリガーできるように、各メトリックのアラートしきい値も指定します。ユーザーはデフォルトを上書きできますが、元の収集ファイルはターゲット・プロバイダが提供する必要があります。
次の各手順では、ターゲット・タイプ・メタデータ・ファイルおよび収集ファイルを作成し、それらをEnterprise Managerフレームワークに登録し、最後に新規ターゲット・タイプのインスタンスを監視するためにEnterprise Manager Grid Controlコンソールに追加するプロセスを説明します。
ターゲット・タイプ・メタデータは、公開するメトリックと、これらのメトリックの取得および計算に使用されるメソッドから構成されます。ターゲット・タイプ・メタデータ・ファイルは、取得するデータ、およびこのターゲット・タイプについてそのデータを取得する方法をOracle管理エージェントに指示します。ユーザーは、新しいターゲット・メタデータXMLファイルを作成し、そのファイルを$AGENT_HOME/sysman/admin/metadata/に置くことで、新しいターゲット・タイプを追加できます。
|
注意: ターゲット・メタデータXMLファイルをAGENT_HOMEメタデータ・ディレクトリに手動で配置するのは、開発を目的とする場合のみです。管理プラグインがエージェントにデプロイされる際には、ターゲット・メタデータ・ファイルがメタデータ・ディレクトリに自動的に配置されます。 |
ターゲット・タイプ・メタデータ・ファイルのネーミング規則
ターゲット・タイプ・メタデータ・ファイルの名前は任意に指定できますが、ユーザーが追加する新しいターゲット・タイプはEnterprise Managerのネーミング規則に従うことをお薦めします。このネーミング規則により、複数のベンダーの類似する製品が使用されている環境で、ファイルのネーミングが一貫性を持つようになります。ターゲットのネーミング規則は、<vendor>_<product category>という形式に従います。次に例を示します。
cisco_router.xml oracle_apache.xml bea_http.xml cisco_slb.xml f5_slb.xml nortel_slb.xml
1つの製品カテゴリに単一のベンダーの複数の製品が含まれている場合を考慮するには、次のファイル・ネーミング規則を使用することをお薦めします。
<vendor>_<category>_<brand name>
次に例を示します。
f5_slb_bigip.xml f5_slb_3dns.xml
Enterprise Managerには、最も一般的なターゲット・タイプを扱う様々な事前定義済ターゲット・タイプ・メタデータが付属しています。事前定義済ターゲット・メタデータ・ファイルが監視対象のターゲット・タイプに厳密に適合しない場合は、新しいターゲット・メタデータ・ファイルを最初から作成するか、または事前定義済メタデータ・ファイルの1つを新規ターゲット・タイプのテンプレートとして使用し、新しい管理プラグインに再パッケージ化できます。事前定義済メタデータ・ファイルは、$AGENT_HOME/sysman/admin/metadataディレクトリにあります。
最上位の定義レベルでは、ターゲット・タイプ・メタデータ・ファイルは4つの主要XML要素から構成されます。
TargetMetadata（トップレベル）
Display（Oracle内部使用）
Metric
InstanceProperties
この項ではターゲット・メタデータの定義に使用されるXML要素およびタグ・オプションの一部を簡単に紹介しますが、明示的な定義およびその他の重要な使用方法情報は、$AGENT_HOME/sysman/admin/dtdsディレクトリにあるTargetMetadata.dtdファイルを参照してください。
次の例は、Net App Filerターゲット・タイプ・メタデータ・ファイルの主要XML要素を示しています。
例2-1 ターゲット・タイプ・メタデータ・ファイル
<?xml version="1.0" ?><!DOCTYPE TargetMetadata SYSTEM "../dtds/TargetMetadata.dtd"><TargetMetadata META_VER="2.2" TYPE="netapp_filer" CATEGORY_PROPERTIES="IsClusterEnabled;IsSnapLicensed;Filer_Version"><Display> <Label NLSID="netapp_filer">Network Appliance Filer</Label></Display> <!-- ************************************************************************* --> <Metric NAME="Product" TYPE="TABLE"> <Display> <Label NLSID="netapp_filer_info">Product Information</Label> </Display> <TableDescriptor> <ColumnDescriptor NAME="productCategory" TYPE="STRING"> <Display> <Label NLSID="netapp_filer_product_category">Product Category</Label> </Display> </ColumnDescriptor> <ColumnDescriptor NAME="prodVersion" TYPE="STRING"> <Display> <Label NLSID="netapp_filer_product_version">Version</Label> </Display> </ColumnDescriptor> <ColumnDescriptor NAME="prodId" TYPE="STRING"> <Display> <Label NLSID="netapp_filer_product_id">Product ID</Label> </Display> </ColumnDescriptor> <ColumnDescriptor NAME="prodVendor" TYPE="STRING"> <Display> <Label NLSID="netapp_filer_product_vendor">Vendor</Label> </Display> </ColumnDescriptor> <ColumnDescriptor NAME="prodModel" TYPE="STRING"> <Display> <Label NLSID="netapp_filer_product_model">Model</Label> </Display> </ColumnDescriptor> <ColumnDescriptor NAME="firmwareVersion" TYPE="STRING"> <Display> <Label NLSID="netapp_filer_firmware_version">Firmware Version</Label> </Display> </ColumnDescriptor> <ColumnDescriptor NAME="prodVersionBucket" TYPE="STRING" COMPUTE_EXPR="(prodVersion __contains 'NetApp Release 7.') ? '7.X':'6.X'" TRANSIENT="TRUE"> <Display> <Label NLSID="netapp_filer_prodVersionBucket">Product Version Bucket</Label> </Display> </ColumnDescriptor> </TableDescriptor> <QueryDescriptor FETCHLET_ID="Snmp"> <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property> <Property NAME="hostname" SCOPE="INSTANCE">AgentHost</Property> <Property NAME="COMMUNITY" SCOPE="INSTANCE" OPTIONAL="TRUE">CommunityString</Property> <Property NAME="TIMEOUT" SCOPE="INSTANCE" OPTIONAL="TRUE">Timeout</Property> <Property NAME="TABLE" SCOPE="GLOBAL">FALSE</Property> <Property NAME="OIDS" SCOPE="GLOBAL">1.3.6.1.2.1.1.2.0 1.3.6.1.4.1.789.1.1.2.0 1.3.6.1.4.1.789.1.1.3.0 1.3.6.1.4.1.789.1.1.4.0 1.3.6.1.4.1.789.1.1.5.0 1.3.6.1.4.1.789.1.1.6.0 </Property> </QueryDescriptor> </Metric>. . . <InstanceProperties> <DynamicProperties NAME="ClusterConfig" FORMAT="ROW" PROP_LIST="IsClusterEnabled"> <QueryDescriptor FETCHLET_ID="Snmp"> <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property> <Property NAME="hostname" SCOPE="INSTANCE">AgentHost</Property> <Property NAME="COMMUNITY" SCOPE="INSTANCE" OPTIONAL="TRUE">CommunityString</Property> <Property NAME="TIMEOUT" SCOPE="INSTANCE" OPTIONAL="TRUE">Timeout</Property> <Property NAME="TABLE" SCOPE="GLOBAL">FALSE</Property> <Property NAME="OIDS" SCOPE="GLOBAL">1.3.6.1.4.1.789.1.2.3.1.0</Property> </QueryDescriptor> </DynamicProperties> <DynamicProperties NAME="VersionConfig" FORMAT="ROW" PROP_LIST="Filer_Version"> <ExecutionDescriptor> <GetTable NAME="Product"/> <GetView NAME="Config" FROM_TABLE="Product"> <Column NAME="prodVersionBucket"/> </GetView> </ExecutionDescriptor> </DynamicProperties> <DynamicProperties NAME="SnapMirrorConfig" FORMAT="ROW" PROP_LIST="IsSnapLicensed"> <QueryDescriptor FETCHLET_ID="Snmp"> <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property> <Property NAME="hostname" SCOPE="INSTANCE">AgentHost</Property> <Property NAME="COMMUNITY" SCOPE="INSTANCE" OPTIONAL="TRUE">CommunityString</Property> <Property NAME="TIMEOUT" SCOPE="INSTANCE" OPTIONAL="TRUE">Timeout</Property> <Property NAME="TABLE" SCOPE="GLOBAL">FALSE</Property> <Property NAME="OIDS" SCOPE="GLOBAL">1.3.6.1.4.1.789.1.9.19.0</Property> </QueryDescriptor> </DynamicProperties> <InstanceProperty NAME="AgentHost" CREDENTIAL="FALSE" OPTIONAL="FALSE"> <Display> <Label NLSID="netapp_filer_agent_host">Hostname or IP Address</Label> </Display> </InstanceProperty> <InstanceProperty NAME="CommunityString" CREDENTIAL="TRUE" OPTIONAL="TRUE"> <Display> <Label NLSID="netapp_filer_community_string">SNMP Read Community String (Default: public)</Label> </Display> public </InstanceProperty> <InstanceProperty NAME="Timeout" CREDENTIAL="FALSE" OPTIONAL="TRUE"> <Display> <Label NLSID="netapp_filer_timeout">SNMP Timeout (Default: 5 seconds)</Label> </Display> 5 </InstanceProperty> ...</InstanceProperties></TargetMetadata>
ターゲット・メタデータ・ファイルの抜粋から、ファイルはターゲット・メタデータを定義する次の機能領域から構成されることがわかります。
TargetMetadataおよびDisplay
Metric Name
インスタンス・プロパティ
TargetMetadataおよびDisplay
ターゲット定義ファイルのヘッダーの後の最初の行は、ターゲット・タイプを識別します。次の例は、Net App Filerターゲット定義ファイルからの抜粋です。
例2-2 TargetMetadataおよびDisplay XML要素
<?xml version="1.0" ?> <!DOCTYPE TargetMetadata SYSTEM "../dtds/TargetMetadata.dtd"> <TargetMetadata META_VER="2.2" TYPE="netapp_filer" CATEGORY_PROPERTIES="IsClusterEnabled;IsSnapLicensed;Filer_Version"> <Display> <Label NLSID="netapp_filer">Network Appliance Filer</Label> </Display>
これらの行は、基本仕様であるメタデータ・バージョン（META_VER="2.2"）、ターゲット・タイプ（TYPE="netapp_filer"）、ターゲットのNLS識別子（NLSID="netapp_filer"）および表示名テキスト（Network Appliance Filer）を定義します。メタデータ・バージョン管理により、同じターゲット・タイプ・メタデータの異なるバージョンが管理対象環境に同時に存在できます（管理エージェント当たり1つのメタデータ・バージョン）。メタデータ・バージョンは、ターゲット・メタデータ・ファイルを更新するたびに変更する必要があります。通常、ターゲット・タイプは、会社名とそれに続く製品名から構成されます。Display要素は、変換の目的でOracleにより内部的に使用されるもので、新規ターゲット・タイプを定義する際には不要です。Display要素は、可読性と国際化の両方を目的としてターゲット・メタデータの様々な要素とともに使用されます。
ターゲット・タイプ・メタデータ・ファイルの内容は、主にメトリック定義に集中しています。慣例として、ターゲット・タイプには少なくとも2つのメトリックを指定することをお薦めします。
ターゲットの可用性を監視するためのメトリック（すべてのターゲット・タイプに必須）
ターゲットのパフォーマンスを監視するためのメトリック（任意だが推奨）
ターゲットの可用性がデフォルトのターゲット・ホームページに正しく表示されるようにするため、Oracleでは、ターゲット・メタデータ・ファイルでNAME="Status"の列を含むNAME="Response"のメトリックを定義することを要求しています。また、デフォルトの収集ファイルで、起動または停止したターゲットを表すクリティカル条件を「ステータス」列に定義する必要があります。
次の例に示すレスポンス・メトリックは、ターゲットの可用性を監視するもので、すべてのターゲット・タイプに必要です。ターゲットのパフォーマンス・レベルを判断するにはロード・メトリックを使用します。
次の例に、Network Appliance Filerターゲット・タイプのレスポンス・メトリック定義を示します。
例2-3 レスポンス・メトリック
<Metric NAME="Response" TYPE="TABLE"> <Display> <Label NLSID="netapp_filer_resp">Response</Label> </Display> <TableDescriptor> <ColumnDescriptor NAME="Status" TYPE="NUMBER"> <Display> <Label NLSID="netapp_filer_resp_status">Status</Label> </Display> </ColumnDescriptor> </TableDescriptor> <QueryDescriptor FETCHLET_ID="Snmp"> <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property> <Property NAME="hostname" SCOPE="INSTANCE">AgentHost</Property> <Property NAME="COMMUNITY" SCOPE="INSTANCE" OPTIONAL="TRUE">CommunityString</Property> <Property NAME="TIMEOUT" SCOPE="INSTANCE" OPTIONAL="TRUE">Timeout</Property> <Property NAME="PINGMODE" SCOPE="GLOBAL">TRUE</Property> <Property NAME="OIDS" SCOPE="GLOBAL">1.3.6.1.4.1.789.1.1.3.0</Property> </QueryDescriptor> </Metric>
レスポンス・メトリックはTABLEタイプであるため、TableDescriptorおよび関連するColumnDescriptorが必要です。表定義および列定義を含むすべてのレベルのメトリックには、名前、タイプおよび表示ラベルが与えられます。前述のように、これらの要素および使用手順は、TargetMetadata.dtdファイルに記載されています。
各メトリックについて、この構造体を埋めるデータの取得方法も指定する必要があります。この処理は、fetchlet（パラメータを受け取り、指定されたターゲットに問い合せて、ターゲットからの値を返すメカニズム）を使用して行います。Enterprise Managerには、ほとんどのデータ取得ニーズを満たす一連のfetchletが用意されています。fetchletおよび使用可能なfetchletタイプの詳細は、第8章「fetchlet」および第6章「WebサービスおよびJMXを使用した監視」を参照してください。
メトリックに関連付けられるfetchletは、QueryDescriptorタグを使用して宣言されます。次の例に、Microsoft SQL Serverレスポンス・メトリックで使用されるQueryDescriptorを示します。
例2-4 QueryDescriptorの使用方法
<QueryDescriptor FETCHLET_ID="OSLineToken"> <Property NAME="emdRoot" SCOPE="SYSTEMGLOBAL">emdRoot</Property><Property NAME="command" SCOPE="GLOBAL">%emdRoot%/bin/nmefwmi</Property><Property NAME="ENVWBEM_WQL" SCOPE="GLOBAL">select name,pathname,processid,state from win32_service where pathname like '%sqlservr.exe%' or pathname like '%sqlagent%'</Property><Property NAME="ENVWBEM_WQL_COLUMN_ORDER" SCOPE="GLOBAL">name,pathname,processid,state</Property> <Property NAME="startsWith" SCOPE="GLOBAL">em_result=</Property> <Property NAME="delimiter" SCOPE="GLOBAL">|</Property> <Property NAME="NEED_CONDITION_CONTEXT" SCOPE="GLOBAL">TRUE</Property></QueryDescriptor>
FETCHLET_IDラベルは、データ取得に使用するfetchletを指定するために使用されます。前述の例では、レスポンス・メトリックはOS行トークンfetchletを使用します。その後に、fetchletで使用される必須のシステム・パラメータの定義が続きます。
oraTclHome、perlBinおよびscriptsDirプロパティにより、commandプロパティでの適切なバインディングが可能になります。その他のプロパティは、OS行トークンfetchletの入力パラメータです。各fetchletで使用されるパラメータの詳細は、第8章「fetchlet」を参照してください。
scopeプロパティは、プロパティ値を取得する場所を定義します。次の有効範囲オプションを使用できます。
SCOPE="GLOBAL": 現在のターゲット・タイプ・メタデータ・ファイル内に定義されている他の変数からプロパティ値を取得します。これには、QueryDescriptorの例で示されている"|"などの定数が含まれます。
SCOPE="INSTANCE": インスタンス・プロパティからプロパティ値を取得します。
SCOPE="SYSTEMGLOBAL": $AGENT_HOME/sysman/configディレクトリにあるemd.propertiesファイルからプロパティ値を取得します。
SCOPE="USER": コレクタまたはユーザーからプロパティ値を取得します。
InstanceProperties記述子は、この特定のターゲット・タイプの新規ターゲット・インスタンスを追加する際に管理者がEnterprise Manager Grid Controlコンソールで指定する必要のあるプロパティを定義する必須のトップレベル仕様です。
InstancePropertiesセクションは、ターゲット・タイプ・メタデータ・ファイル内の様々な場所に定義できますが、一貫性を維持するために、このセクションをファイルの最後に定義することをお薦めします。ターゲット・タイプ・メタデータ・ファイルで定義されるインスタンス・プロパティは、targets.xmlファイル内のこれらのインスタンス・プロパティに対して指定される値に解決されます。次に、Microsoft SQL Serverターゲット・タイプのインスタンス・プロパティをいくつか示します。
例2-5 インスタンス・プロパティ
<InstanceProperties> <InstanceProperty NAME="ms_sqlserver_host" CREDENTIAL="FALSE" OPTIONAL="FALSE"> <Display> <Label NLSID="ms_sqlserver_host">SQL Server host</Label> </Display> </InstanceProperty> <InstanceProperty NAME="ms_sqlserver_servername" CREDENTIAL="FALSE" OPTIONAL="FALSE"> <Display> <Label NLSID="ms_sqlserver_servername">SQL Server name</Label> </Display> </InstanceProperty> <InstanceProperty NAME="url" CREDENTIAL="FALSE" OPTIONAL="FALSE"> <Display> <Label NLSID="connectString_iprop">JDBC URL</Label> </Display> </InstanceProperty> . . . </InstanceProperties>
例のように、Oracle Databaseインスタンス・ターゲット・タイプがEnterprise Managerフレームワークに追加されると、そのターゲット・インスタンスに関する詳細情報がtargets.xmlファイルに追加されます。次の例では、Oracle Databaseインスタンス・ターゲット・タイプ・メタデータ・ファイルで定義されているOracleHome、Port、SIDなどのInstancePropertyラベルが、targets.xmlファイルのインスタンス固有の値に解決されています。
例2-6 Oracle Databaseのターゲット・インスタンス情報
<Target TYPE="oracle_database" NAME="emrep.us.oracle.com">
<Property NAME="OracleHome" VALUE="/scratch/OracleHomes/db10g"/>
<Property NAME="UserName" VALUE="f8a6d72528517730" ENCRYPTED="TRUE"/>
<Property NAME="MachineName" VALUE="stacb11.us.oracle.com"/>
<Property NAME="Port" VALUE="1521"/>
<Property NAME="SID" VALUE="emrep"/>
<Property NAME="ServiceName" VALUE="emrep.us.oracle.com"/>
<Property NAME="password" VALUE="7536910dcf78eaad" ENCRYPTED="TRUE"/>
</Target>
新しいターゲット・タイプ定義は、メトリック・ブラウザを使用してテストすることをお薦めします。メトリック・ブラウザは、Oracle管理エージェントの重要部分である開発ユーティリティです。エージェントのサブシステムとして、メトリック・ブラウザは、Enterprise Managerフレームワークの管理リポジトリまたはその他のコンポーネントのオーバーヘッドを発生させることなく、エージェントにより監視されるターゲットのメトリック値への迅速なアクセスを可能にします。
Enterprise Manager Grid Controlコンソールを使用せずにメトリックをデバッグするようにOracle管理エージェントのメトリック・ブラウザを構成するには、次のようにします。
次のファイル内のenableMetricBrowser行のコメントを外します。
$AGENT_HOME/sysman/config/emd.propertiesファイル:
#enableMetricBrowser=True
コメントを外すと、次のようになります。
enableMetricBrowser=True
Oracle管理エージェントが停止していることを確認します。
emctl stop agent
管理エージェントを再起動します。
emctl start agent
emd.propertiesファイルを開き、EMD_URL行をチェックします。
この行の形式は次のとおりです。
EMD_URL=http://<host>:<port>/emd/main
targets.xmlファイルへのターゲット・インスタンスの追加
メトリック・ブラウザでターゲット・メトリックを表示するには、その前に、管理エージェントを管理サービスと再同期せずに新しいターゲット・タイプの実際のインスタンスをtargets.xmlファイルに追加する必要があります。この作業を行うには、次のようにします。
特定のターゲットのインスタンス情報を含む新しいXMLファイルを作成します。このXMLファイルの内容は、$AGENT_HOME/sysman/admin/dtds/TargetInstance.dtdファイルに準拠している必要があります。このファイルの内容は、ターゲット・タイプ・メタデータ・ファイルで定義したインスタンス・プロパティに対して指定された実際の値から構成されます。たとえば、特定のターゲット・メタデータ・ファイルで定義されているインスタンス・プロパティについて、次の内容から構成されるtarget2add.xmlというXMLファイルを作成します。
例2-7 target2add.xmlファイル
<Target TYPE="oracle_listener" NAME="listener" VERSION="1.0">
<Property NAME="ListenerOraDir" VALUE="/myOH/oracle/network/admin"/>
<Property NAME="LsnrName" VALUE="LISTENER"/>
<Property NAME="Machine" VALUE="mymachine.us.oracle.com"/>
<Property NAME="OracleHome" VALUE="/myOH/oracle"/>
<Property NAME="Port" VALUE="15091"/>
</Target>
コマンドライン・インスタンス・インストーラを使用して、管理エージェントのtargets.xmlファイルにインスタンス情報ファイルの内容を追加し、インスタンス・データをリロードします。次の例では、管理エージェント・ホームは/em/にあり、インスタンス情報ファイルは/tmp/ディレクトリにあるtarget2add.xmlです。
新しいターゲット情報ファイルの内容をtargets.xmlファイルに追加します。
emctl config agent addtarget <file location> <Agent Home location>
次に例を示します。
emctl config agent addtarget /tmp/target2add.xml /em/
ターゲット情報が正しく追加されたことを検証します。
emctl config agent listtargets <emloc>
次に例を示します。
emctl config agent listtargets /em/
変更したターゲット情報をリロードします。この操作は、新しいターゲット・インスタンスがメトリック・ブラウザに表示されるようにするために必要です。
emctl reload
メトリックの参照
ターゲット・インスタンスがtargets.xmlファイルに追加され、新しい情報がリロードされた後で、使用可能なターゲットおよびメトリックをメトリック・ブラウザで表示できます。任意のWebブラウザを使用して、次のURLにアクセスします。
http://<host>:<port>/emd/browser/main
管理エージェントで使用されるポート番号を調べるには、emd.propertiesファイルを開き、EMD_URL行を検索します。
ターゲット・タイプ・メトリックを定義すると、そのターゲット・インスタンスに属するデータをいつでも表示できます。ただし、一部のメトリックの値を収集して、一定期間にわたるバリエーションを分析することが必要な場合もあります。特定のターゲット・タイプのデフォルトの収集ファイルを定義することにより、ターゲット・インスタンスのメトリック収集間隔を設定します。
|
注意: 収集ファイルで使用される記述子タグの完全な定義および使用方法は、$AGENT_HOME/sysman/admin/dtds/TargetCollection.dtdファイルに記載されています。 |
$AGENT_HOME/sysman/admin/default_collectionにあるターゲット・タイプのデフォルトの収集ファイル（XML）では、収集されて管理リポジトリに送信されるメトリックと、これらのスケジュール済収集の頻度を指定します。デフォルトの収集ファイルの名前を使用できますが、ターゲット・タイプ・メタデータ・ファイル名と同一のファイル名を使用するなど、収集ファイルを対応するターゲット・タイプ・メタデータ・ファイル名に簡単に関連付けることのできるネーミング規則を使用することをお薦めします。
次の例は、Microsoft SQL Serverのデフォルトの収集ファイルからの抜粋です。
例2-8 Microsoft SQL Serverのデフォルトの収集ファイル
<!DOCTYPE TargetCollection SYSTEM "../dtds/TargetCollection.dtd"[]>
<TargetCollection TYPE="microsoft_sqlserver_database">
<CollectionItem NAME="Response">
<Schedule>
<IntervalSchedule INTERVAL="5" TIME_UNIT="Min" />
</Schedule>
<Condition COLUMN_NAME="Status" CRITICAL="Running" OPERATOR="NE" />
</CollectionItem>
<CollectionItem NAME="SQLServer" UPLOAD_ON_FETCH="TRUE" CONFIG="TRUE">
<Schedule OFFSET_TYPE="INCREMENTAL">
<IntervalSchedule INTERVAL="5" TIME_UNIT="Min" />
</Schedule>
<MetricColl NAME="MSSQL_SQLServer" />
<MetricColl NAME="MSSQL_RegistrySetting" />
</CollectionItem>
.
.
.
<!-- Buffer cache hit ratio that is lower than 90% triggers warning and 80%
triggers alert -->
<!-- Cache hit ratio that is lower than 80% triggers warning and 70% triggers
alert -->
<CollectionItem NAME="MSSQL_MemoryStatistics">
<Schedule>
<IntervalSchedule INTERVAL="10" TIME_UNIT="Min" />
</Schedule>
<Condition COLUMN_NAME="buffer_cache_hit_ratio" WARNING="90" CRITIAL="80" OPERATOR="LE" />
<Condition COLUMN_NAME="cache_hit_ratio" WARNING="80" CRITIAL="70" OPERATOR="LE" />
</CollectionItem>
<CollectionItem NAME="MSSQL_Alert">
<Schedule>
<IntervalSchedule INTERVAL="20" TIME_UNIT="Min" />
</Schedule>
</CollectionItem>
<CollectionItem NAME="MSSQL_LastDatabaseBackup">
<Schedule>
<IntervalSchedule INTERVAL="10" TIME_UNIT="Min" />
</Schedule>
</CollectionItem>
</TargetCollection>
すべてのターゲット・インスタンスについて、4つのメトリックのデータ収集間隔は次のとおりです。
Response: 5分ごとに収集されます。
Load: 15分ごとに収集されます。
memPool: 15分ごとに収集されます。
Interfaces: 15分ごとに収集されます。
収集ファイルにしきい値が設定されていない場合、管理者が後でEnterprise Managerコンソールから列のしきい値を編集/追加することはできません。デフォルト値を持たないしきい値を管理者が変更できるようにするには、特定のしきい値についてNotDefinedエントリを追加します。次に例を示します。
<Condition COLUMN_NAME="db_session_osuser" CRITICAL="NotDefined"/>
一定の状況では、すべてのターゲット・インスタンスで同じ収集スケジュールを使用することが望ましくない場合があります。ターゲット・タイプの異なるインスタンスで異なる収集スケジュールを使用するように指定するには、（特定のターゲット・インスタンスの）追加の収集ファイルを$AGENT_HOME/sysman/emd/collectionsに追加します。
次の例に、2つの特定のターゲット・インスタンス（Simple Server AlphaおよびSimple Server Beta）でResponseおよびLoadという異なる収集スケジュールを使用する状況を示します。収集ディレクトリに追加する2つの収集ファイルには、次の内容が含まれます。
例2-9 Simple Server Alphaのデフォルトの収集ファイル
<TargetCollection NAME="Simple Server Alpha" TYPE="simple_server">
<CollectionItem NAME="Response">
<Schedule>
<IntervalSchedule INTERVAL="10" TIME_UNIT="Min"/>
</Schedule>
</CollectionItem>
</TargetCollection>
例2-10 Simple Server Betaのデフォルトの収集ファイル
<TargetCollection NAME="Simple Server Beta" TYPE="simple_server">
<CollectionItem NAME="Load">
<Schedule>
<IntervalSchedule INTERVAL="30" TIME_UNIT="Min"/>
</Schedule>
</CollectionItem>
</TargetCollection>
これで、Simple Server AlphaのResponseから10分ごとに結果を収集し、Simple Server BetaのLoadから30分ごとに収集することになります。
管理プラグインを開発すると、管理プラグインで定義されたターゲット・タイプに関連付けられる新しいSYSTEMレポートを追加できます。SYSTEMレポートは、Enterprise Managerコンソールから編集または削除できません。Information Publisherで提供されている即時利用可能なレポートは、すべてSYSTEMレポートです。
管理プラグインにレポート定義を追加するには、単純にレポート定義ファイルを作成してプラグインに組み込みます。レポート定義ファイルは、管理リポジトリから抽出する関連情報を指定する従来のPL/SQLブロックと、そのデータの書式設定および表示に使用されるレポート要素から構成されます。特定のターゲット・タイプに対して複数のレポートを定義できます。
レポートが管理プラグインの一部として定義され、レポートの1つ以上がターゲットのデフォルト・ホームページのコンテキストに表示されるように登録されている場合（PL*SQLファンクションのadd_reportを使用して登録されます）、この項で説明するプロセスを使用してターゲットのデフォルト・ホームページに1つ以上の関連リンクを追加できます。
関連リンクは、次のパラメータとともにDynamicPropertiesタグを使用して、ターゲット・メタデータ・ファイルに動的インスタンス・プロパティとして定義されます。
NAME="<任意の名前>"
PROP_LIST="RelatedLink_Name_#;RelatedLink_Dest_#[;...]"
#には任意の正の整数（例: 1、2、3）を指定できます。
PROP_LISTは、（大/小文字の区別を含め）ここで指定されている形式と厳密に一致する必要があります。そうしないと、関連リンクではターゲットのデフォルト・ホームページが表示されません。
また、PROP_LISTにリストされている複数のName/Destのペアを取得するQueryDescriptorタグ・ブロックも必要です。RelatedLink_Name_#は、ハイパーリンク・テキストとして表示されます。RelatedLink_Dest_#はリンク先（URLまたはJavascript）です。
例2-11は、デフォルトのターゲット・ホームページに表示される3つの関連リンクを定義するDynamicPropertiesブロックを含むターゲット・メタデータ・ファイルからの抜粋です。
例2-11 関連リンク
<InstanceProperty NAME="EMPLOYEE_ID" CREDENTIAL="FALSE" OPTIONAL="FALSE">
<Display>
<Label NLSID="EMPLOYEE_ID_iprop">Employee ID</Label>
</Display>
</InstanceProperty>
<DynamicProperties NAME="Links" PROP_LIST="RelatedLink_Name_1;RelatedLink_Dest_1;RelatedLink_Name_2;RelatedLink_Dest_2;RelatedLink_Name_3;RelatedLink_Dest_3" FORMAT="ROW">
<QueryDescriptor FETCHLET_ID="OSLineToken">
<Property NAME="id" SCOPE="INSTANCE">EMPLOYEE_ID</Property>
<Property NAME="command" SCOPE="GLOBAL">
%perlBin%/perl %scriptsDir%/emx/oracle/getLinks.pl %id%
</Property>
<Property NAME="startsWith" SCOPE="GLOBAL">em_result=</Property>
<Property NAME="delimiter" SCOPE="GLOBAL">|</Property>
</QueryDescriptor>
</DynamicProperties>
</InstanceProperties>
例2-11では、PerlスクリプトgetLinks.plを使用して3つのリンクを返しています。このスクリプトの内容を例2-12に示します。
例2-12 スクリプトgetLinks.pl
my $id = $ARGV[0];
my $name1 = "Employee: MY-PC";
my $link1 = "javascript:void window.open('http://my-pc.us.oracle.com', 'aria', 'resizable=1,menubar=1,toolbar=1,titlebar=1,status=1,scrollbars=1')";
my $name2 = "Employee: Hierarchy";
my $link2 = "javascript:void window.open('http://employee.us.oracle.com:7777/pls/oracle/f?p=8000:3:7200626882230853285::NO::PERSON_ID:$id', 'employee', 'resizable=1,menubar=1,toolbar=1,titlebar=1,status=1,scrollbars=1')";
my $name3 = "OTN";
my $link3 = "javascript:void window.open('http://otn.oracle.com', 'otn', 'resizable=1,menubar=1,toolbar=1,titlebar=1,status=1,scrollbars=1')";
print "em_result=$name1|$link1|$name2|$link2|$name3|$link3\n";
getLinks.plはサポート・スクリプトであるため、次の引数を持つEM CLIのadd_mp_to_mpa動詞を使用して管理プラグインに別ファイルとして追加します。
–file=”MONITORING_SCRIPT:<path_to>/getLinks.pl”
使用するjavascript構文には注意してください。一般的なブラウザに共通なのは構文の一部のみです。たとえば、window.openへの2番目の引数は、ウィンドウへの内部参照に使用されるウィンドウ名であり、空白は含まないでください。
ターゲット・タイプ・メタデータ・ファイルおよび収集ファイルを正常に作成するには、有効なXMLコードが必要です。有効なXMLの作成を支援するために、Enterprise Managerには、ILINTという開発ツールが用意されています。このツールを使用して、管理プラグインの開発時にコードを定義するために使用されるXMLを検証できます。ILINTの詳細は、第4章「XMLの検証」を参照してください。
新しい管理プラグインのターゲット・タイプ定義ファイルを開発する際には、特定のターゲット・タイプを監視する方法を入念に検討する必要があります。ターゲット・タイプの監視方法は、Enterprise Mangerのパフォーマンスに大きく影響します。システム・パフォーマンスを最適化するために、ターゲット・メタデータおよび収集の定義に関する一般ガイドラインに従う必要があります。
メタデータは、データに関するデータです。一般に、この用語はネットワーク・エンティティの識別、記述および特定を支援するために使用されるデータを表します。Enterprise Managerターゲットのターゲット・メタデータは、ユーザーが公開するメトリックと、これらのメトリックの計算に使用されるメソッドから構成されます。
パフォーマンス・メトリックは、パフォーマンス傾向を追跡するために計算する必要のあるメトリックと、特定の時点での詳細を取得するためのドリルダウンに役立つその他のメトリックに分類されます。リアルタイムのみのメトリックには、システムの特定のサブセット（さらに診断する特定の表領域など）に関する詳細情報を返すためにコンテキスト情報を必要とするメトリックが含まれます。
メトリックのキー列は、軸上のパフォーマンス・データの傾向（データベース表領域ごとの表領域使用率など）を調べるために管理リポジトリで使用されます。キー列を不適切に選択すると、管理リポジトリ内の収集データが非常に多くなります。たとえば、プロセス・メトリックではプロセスIDを使用してリポジトリにアップロードします。
キー列を使用しないこともできますが、問合せ記述子は単一行を返す必要があります。
場合によっては、メトリック列を使用して、より重要な他のメトリック列の値を計算できます。傾向を調べるために元の列が重要でない場合は、これらの列を一時列としてマークし、リポジトリにアップロードせず、領域を浪費しないようにします。
カスタム・ターゲットのメトリックを作成する際には、追加のオペレーティング・システム（OS）プロセスを作成するコスト（CPU使用率）を考慮することが重要です。このことは、LinuxやSolarisなどのUNIXベース・システムに比べてプロセス作成にCPUを大量に使用するMicrosoft Windowsを実行しているシステムに当てはまります。CPU使用率は、子プロセスの作成に対して線形に増加します。プロセス作成を最小化するために、メトリック収集スクリプトからOSプログラムまたはコマンドを実行することは避けてください。たとえば、Perlスクリプトを作成する場合、システム関数またはバッククォート（``）を使用してOSコマンドを実行することは避けてください。
ターゲット・プロパティは、名前の付いた値であり、ターゲットのメトリックの計算、またはターゲットのホームページでの表示に使用できます。ターゲット・プロパティのリストをメタデータで指定して、データ駆動のユーザー・インタフェースがターゲットを登録できるようにすること、またOracle管理エージェントがターゲット・インスタンスの完了を検証できるようにすることができます。
静的インスタンスのプロパティ: これらは、ターゲットのtargets.xmlエントリでターゲットに対して値を指定する必要のあるプロパティです。プロパティが指定されていなくてもターゲット宣言が完了したとみなされる場合は、インスタンス・プロパティをオプションとして指定できます。ターゲット・プロパティのメタデータ指定では、構成ユーザー・インタフェースで使用するデフォルト値も提供できます。
動的インスタンスのプロパティ: Oracle管理エージェントでは、ターゲット・インスタンスのプロパティを計算することもできます。このようなプロパティは、メトリックで使用されるのと非常によく似たQueryDescriptorを使用して計算されます。
動的プロパティを使用すると、特定のプロパティの値を正しく指定するようユーザーに要求するかわりにそのプロパティを計算できるため、ターゲットの構成に関連する作業が削減されます（たとえば、データベースのVersionプロパティは特定のアドレッシング情報を確実に計算できます）。
Oracle管理エージェントは、ターゲット・バウンスが検出されるたび（ターゲット・ステータスが「稼働中」に変化するたび）にプロパティを再計算することで、これらの動的プロパティを正常に計算するにはターゲットが稼働している必要があるという事実に対応しています。
Oracle管理エージェントとの関連でのメトリックの概念は、構成およびパフォーマンス情報を示すために使用できます。
構成メトリック: 構成メトリックは、ターゲットの構成を示すターゲット・プロパティに似たデータを収集します。この情報は、定期的にリフレッシュされ、ターゲットの設定の変更を追跡するために使用できます。このようなメトリックの収集間隔は、通常は約24時間です。
パフォーマンス・メトリック: パフォーマンス・メトリックを使用して、ターゲットの応答性を追跡します。これらのメトリックは、通常は構成メトリックよりも頻繁に収集されますが、一部のパフォーマンス・メトリックの間隔は他のパフォーマンス・メトリックと大きく異なる場合があります。また、パフォーマンス・メトリックには、通常、ターゲットのパフォーマンス・アラートの基礎であるしきい値が付属しています。
すべてのターゲットの必須メトリックは、条件が指定された「ステータス」列から構成されるレスポンス・メトリックです。このメトリックは、ターゲットの可用性の追跡に使用されます。
Enterprise Managerユーザー・インタフェースの多くの部分はデータ駆動であるため、メトリックのネーミングに使用される規則は非常に重要です。たとえば、実際のメトリック列ラベルとキー値は、ページ・タイトル、指示テキストまたは列見出しの一部になる場合があります。具体的には、これらの要素は「メトリック詳細」ページ、「メトリックしきい値の編集」ページ、「通知ルール」ページおよびEnterprise Managerユーザー・インタフェースのその他のページに表示されます。このため、次のメトリック・ネーミング規則をお薦めします。
すべてのメトリック名（ラベル）は、特定のターゲット・タイプおよびバージョン内で一意である必要があり、ユーザーが簡単に理解できる必要があります（必要に応じてメトリック単位が使用されます）。
例: 表領域の使用量（%）
すべてのメトリック列名（ラベル）は、メトリック名に依存せずに自己説明的である必要があります。
例: 使用済表領域（%）
キー列名は自己説明的である必要があります。キー列名は、メトリックしきい値の指定または通知の設定時に使用されます。次のすべての<キー値名>オブジェクトという形式を使用する必要があります。
例: すべての（表領域）オブジェクト
メトリック列に関連する短縮名（最大20文字）は、明確かつ解釈可能である必要があります。
ターゲット・バージョン間で、同じ列は同じラベルを使用する必要があります。これにより、メトリック列や短縮名などの列は、異なるターゲット・バージョンでも同じNLS IDを持ちます。
収集は、Oracle管理エージェントがターゲットのメトリックを定期的に計算し、データを管理リポジトリにアップロードするためのメカニズムです。ターゲット・タイプの収集を作成する際に最も注意する必要があるのは、管理リポジトリが過剰なデータで過負荷になるのを避けることです。数百のOracle管理エージェントと数千のターゲットのある大規模エンタープライズでは、拡張性の鍵は、リポジトリにアップロードされる、ターゲットについて収集されるデータ量を制限することです。生データは24時間メンテナンスされるため、これは特に重要です。ロールアップの利点はそれより後で生じます。
アラート・メッセージは、何か問題がある場合にユーザーに通知します。これらのメッセージは、ユーザーによる問題の解決も支援します。アラート・メッセージを作成する際には、次のコンテンツ・ガイドラインに従うことをお薦めします。
アラート・メッセージは有意である必要があります。メッセージがそのメトリックにのみ適用されるのでないかぎり、短くあいまいなメッセージの使用は避けてください。
ターゲット停止メッセージでは、ターゲットが停止していることを示すのに加えて、ターゲットの停止について考えられる理由を示す情報を含める必要があります。
可能な場合は必ずエラー・コード/メッセージを含める必要があります。
問題の解決または診断方法をユーザーに示す情報を適宜含めます。
メトリック収集の失敗を回避するために、メトリック評価順序に注意することが重要です。たとえば、ターゲットの停止時に収集の失敗を防ぐために、レスポンス・メトリックを最初に評価する必要があります。Oracle管理エージェントは、収集XMLファイルにリストされている順序に基づいてメトリックを評価します。
|
注意: Oracle管理エージェントのプログラム・ロジックは、メトリック評価を分散して、各評価が約10秒間隔になるようにします。 |
管理プラグイン・ファイルを作成したら、次の手順は管理プラグイン・アーカイブ（MPA）の作成です。MPAは、管理プラグイン・ライフサイクルの様々なステージで重要な役割を果します。次の機能があります。
開発環境とEnterprise Managerフレームワーク間の転送メカニズムとして機能します。
異なるEnterprise Managerインストール環境間の転送メカニズムとして機能します。
管理プラグインのコンテナとして機能します。MPAには複数の管理プラグインが含まれる場合があります。
管理プラグインは、Enterprise Managerコマンドライン・インタフェース（EM CLI）を使用して、前に説明したファイルをMPAに追加することで作成されます。EM CLIをコールするたびに、別の一意の管理プラグインがMPAに追加されます。各管理プラグインについて、EM CLIでは、プラグインの機能を必要とする管理エージェントのベース・バージョン、およびプラグインが管理リポジトリにインポートされるために必要なOracle管理サービスのベース・バージョンを指定できます。MPAを作成するには、次の手順を実行します。
EM CLIクライアントがインストールされているマシンでターミナル・ウィンドウを開きます。
コマンド・プロンプトで、add_mp_to_mpa動詞を発行します。次の例に、指定する必要のある動詞パラメータを示します。add_mp_to_mpa動詞の詳細は、コマンドライン・ヘルプを参照してください。
例2-13 EM CLIを使用した管理プラグイン・アーカイブの作成
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="REPORT_DEFINITION:/my_dir/report1.sql
-file="REPORT_DEFINITION:/my_dir/report2.sql
-file="MONITORING_SCRIPT:/my_dir/script1.pl
-file="MONITORING_SCRIPT:/my_dir/script2.pl
-file="MONITORING_BINARY:/my_dir/bin1
-func_desc="Management Plug-in to define target type new_type"
簡単に説明すると、動詞オプションは次のとおりです。
mpa
管理プラグインを追加する管理プラグイン・アーカイブの名前。
mp_version
作成する管理プラグインのバージョン。管理プラグインのいずれかのファイルが変更されるたびに、管理プラグイン・バージョンを増やす必要があります。
tdd
ターゲット・タイプ・メタデータ・ファイルの明示的パス。
dc
デフォルトの収集ファイルの明示的パス。
oms_version
この管理プラグインと互換性のある最小OMSバージョン。
file
追加する他の管理プラグイン・ファイルのタイプとパス。次のタイプがサポートされています。
MONITORING_BINARY
MONITORING_SCRIPT
REPORT_DEFINITION
JOB_SCRIPT
JOB_DEFINITON
func_desc
管理プラグインの機能説明。この説明は、プラグインがインポートされた後でEnterprise Managerコンソールに表示されます。
req_desc
管理プラグインの要件説明。この説明はEnterprise Managerコンソールに表示されるもので、プラグイン・デプロイ要件を指定します。
EM CLIを使用して管理プラグイン・アーカイブを作成すると、Enterprise Managerに管理プラグイン・アーカイブ・ファイルをアップロードする準備ができます。アーカイブのアップロードにより、アーカイブに含まれるすべての使用可能なプラグインを表示できます。次に、Enterprise Managerにインポートするプラグインを選択できます。管理プラグインをシステムに追加するには、スーパー管理者権限が必要です。
管理プラグイン・アーカイブをアップロードするには、次のようにします。
Enterprise Managerコンソールで、「設定」をクリックします。
左側のナビゲーション・バーで、「管理プラグイン」をクリックします。
「インポート」をクリックします。「管理プラグインのインポート」ページが表示されます。
「管理プラグイン・アーカイブの選択」セクションで、管理プラグイン・アーカイブ・ファイルを指定します。
「リスト・アーカイブ」をクリックして、アーカイブに含まれる管理プラグインを表示します。
インポートする管理プラグインを選択し、「OK」をクリックします。
インポートが正常に終了すると、「管理プラグイン」リストにプラグインが表示されます。
この時点で、管理プラグインはアーカイブ・ファイルから抽出され、管理リポジトリにインポートされています。管理プラグインは、Enterprise Manager環境の管理エージェントにデプロイする準備ができています。プラグインをデプロイするには、「デプロイ」アイコンをクリックします。Enterprise Managerにより、単純なデプロイ・プロセスが説明されます。
管理プラグインがエージェントにデプロイされると、管理プラグインで定義されたタイプの新しいターゲット・インスタンスを追加する準備ができます。ターゲット・インスタンスを追加すると、監視および管理機能がそのターゲットに自動的に拡張されます。ターゲット・インスタンスを追加するには、次のようにします。
管理エージェント・ホームページの「監視ターゲット」セクションで、「追加」ドロップダウン・メニューからプラグインを選択し、「実行」を選択することにより、定義されているターゲット・タイプを選択します。「ターゲットの追加」ページが表示されます。
必要なターゲット・プロパティを入力し、「OK」をクリックします。新規に追加したターゲットがエージェントの「監視ターゲット」リストに表示されます。
図2-3に示すように、ターゲットについて必要な情報を提供するデフォルトのターゲット・ホームページが用意されています。
デフォルトのターゲット・ホームページから、ユーザーはターゲット・タイプに対して定義されている特定のメトリックにドリルダウンできます。
次の図に、Microsoft SQL Serverインスタンスのターゲット・ホームページを示します。
この管理プラグインにはレポート定義が含まれているため、追加の「レポート」サブタブがホームページに表示されます。次の図に示すように、レポートを追加することで、管理プラグインの監視機能が大幅に向上する可能性があります。
場合によっては、管理プラグインを管理する際にエラーが発生することがあります。最も一般的な問題は次のとおりです。
デプロイに失敗する。「エージェント使用不可」
管理エージェントが起動し、稼働していることを確認します。
rootとしてログインし、管理エージェントでroot.shスクリプトを実行します。
アンデプロイに失敗する。「エージェント使用不可」
管理エージェントが起動し、稼働していることを確認します。
管理プラグインを削除できない。
管理プラグインは、前にデプロイされたすべてのエージェントからアンデプロイする必要があります。これには、現在停止しているエージェントは含まれません。
レポートにデータが表示されない。
収集間隔の設定によっては、エージェントがターゲットのメトリック・データを収集するのに時間がかかることがあります。管理リポジトリに対する問合せがロールアップされたデータに対して実行された場合と同様に、レポートで使用される管理ビューにより、データがいつ使用可能になるかを決定することもできます。
Enterprise Managerには、管理プラグインを簡単かつ効率的に開発およびテストできるコマンドライン・ツールを含む、プラグイン開発キット（PDK）が用意されています。このツールの例を次に示します。
check_mp: 管理プラグインにはすべてのメタデータ・ファイルで正しいXML構文が含まれていることを確認し、そのファイルをDTDファイルと照合して検証します。また、セマンティクス・チェックを実行して、問題がないかどうかを確認します。
collect_mp_stats: 管理プラグインのメタデータで定義されたメトリック・データを収集して、エージェントに対する管理プラグインのパフォーマンスの影響を評価する際に役立つ、HTMLベースのレポートを生成します。
PDKをEnterprise Managerコンソールから直接ダウンロードする手順は次のとおりです。
管理プラグインのホームページにナビゲートします（「設定」→「管理プラグイン」）。
「関連リンク」領域で、「PDKのダウンロード」をクリックします。PDKのダウンロード・ページに移動します。
システム要件とインストール手順を確認します。
「PDKをワークステーションにダウンロードします。」をクリックします。
