| Oracle® Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス 13c リリース3 E98540-02 |
|
 前 |
 次 |
プラグインがEnterprise Manager Cloud Controlによる監視と管理を許可するターゲット・タイプを定義するには、XMLメタデータ・ファイルが2つ必要です。
ターゲット・タイプの定義には、主に、管理エージェントがターゲットに対して収集する必要のあるメトリックが含まれます。ファイルには、ターゲット・タイプに対して収集されるすべてのメトリックのリスト、および各メトリックの計算方法の詳細が含まれます。
詳細は、「ターゲット・タイプ・メタデータ・ファイルの作成」を参照してください。
このファイルは、メトリック・データが収集される間隔、またはターゲットから受信する間隔を定義します。各メトリックのオプションのアラートしきい値および対応するオプションのアラート・メッセージを指定できます。Cloud Controlユーザーは、デフォルトの収集間隔をオーバーライドできますが、デフォルト値はこのファイルに指定する必要があります。
詳細は、「デフォルトの収集ファイルの作成」を参照してください。
この章では、プラグイン・ターゲットの構成データの収集に必要なメタデータ定義についても説明します。これは高度な機能ですが、多くのプラグインで便利です。詳細は、「構成定義ファイルについて」を参照してください。
後続の項には、ターゲット・タイプおよびデフォルトの収集メタデータ・ファイルの作成方法のサマリーと、ターゲット構成データ収集の概要が記載されています。
ターゲット・タイプ・メタデータ・ファイルは、取得するデータ、およびこのターゲット・タイプについてそのデータを取得する方法をOracle Management Agentに指示します。
表3-1で説明するように、最上位の定義レベルでは、ターゲット・タイプ・メタデータ・ファイルは4つの主要XML要素から構成されます。
表3-1 ターゲット・タイプ・メタデータ・ファイルの主要要素
| 要素 | 説明 |
|---|---|
|
名前やバージョンなど、プラグインの情報を指定します。 |
|
1つ以上のメトリックが含まれ、そのそれぞれがターゲットから収集されるデータの特定部分を定義する、メトリック・グループを定義します。 |
|
ターゲット・インスタンスの作成時に移入されるプロパティを定義します。 |
|
ターゲット・インスタンスとの認証でプラグインにより必要とされる資格証明を指定します。 |
Enterprise Managerには、最も一般的なターゲット・タイプを扱う事前定義済ターゲット・タイプ・メタデータ・ファイルが付属しています。事前定義済ターゲット・メタデータ・ファイルが、監視する必要のあるターゲットのタイプに適合しない場合は、次のいずれかを実行します。
ターゲット・タイプ・メタデータ・ファイルを作成し、新しいターゲット・タイプを定義
事前定義済メタデータ・ファイルのいずれかを、新しいターゲット・タイプを定義するためのテンプレートとして使用し、ファイルを新規プラグインとして再パッケージ化
この項では、ターゲット・タイプ・メタデータ・ファイルの構造を簡単に説明します。ターゲット・タイプ・メタデータ・ファイルの完全な例は、EDKを参照してください。
edk/samples/plugins/SampleHost/oms/metadata/targetType/demo_hostsample.xml
このディレクトリ・パスで、edkは、EDKアーカイブを展開したディレクトリを表しています。EDKアーカイブの詳細は、「拡張開発キット(EDK)」を参照してください。
ターゲット・タイプ・メタデータ・ファイルの作成の詳細は、「ターゲット・メタデータの作成のガイドライン」を参照してください。
次の例は、ターゲット・タイプ・ファイルに含まれている必要がある最低限の必須情報を示しています。
例: ターゲット・タイプ・ファイル
<TargetMetadata META_VER="2.0" TYPE="demo_hostsample">
<Display>
<Label NLSID="hs_displayname">Demo Plugin Sample Host</Label>
</Display>
<Metric NAME="Response" TYPE="TABLE">
<Display>
<Label NLSID="hs_response_displayname">Response</Label>
</Display>
<TableDescriptor>
<ColumnDescriptor NAME="Status" TYPE="NUMBER">
<Display>
<Label NLSID="hs_response_status">Status (up/down)</Label>
</Display>
</ColumnDescriptor>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="OSLineToken">
<Property NAME="scriptsDir" SCOPE="SYSTEMGLOBAL">scriptsDir</Property>
<Property NAME="fake" SCOPE="INSTANCE"
OPTIONAL="TRUE">USE_FAKE_DATA</Property>
<Property NAME="perlBin" SCOPE="SYSTEMGLOBAL">perlBin</Property>
<Property NAME="script" SCOPE="GLOBAL">%scriptsDir%/emx/demo_hostsample/datacollector.pl --collect Response --fake %fake%</Property>
<Property NAME="startsWith" SCOPE="GLOBAL">em_result=</Property>
<Property NAME="delimiter" SCOPE="GLOBAL">|</Property>
</QueryDescriptor>
</Metric>
<InstanceProperties>
<InstanceProperty NAME="SAMPLE_DATA" CREDENTIAL="FALSE" OPTIONAL="TRUE">
<Display>
<Label NLSID="EMPLOYEE_ID_iprop">Employee ID</Label>
</Display>
</InstanceProperty>
</InstanceProperties>
</TargetMetadata>
後続の項では、前述の例で示したXML定義の詳細を説明します。
新しいターゲット・タイプを追加する際は、Enterprise Managerのネーミング規則に従うことお薦めします。このネーミング規則により、複数のベンダーの類似する製品が使用されている環境で、ファイルのネーミングが一貫性を持つようになります。ターゲットのネーミング規則は、vendorID_productID_PluginTagという形式に従います。
次に例を示します。
test_demo_targetType.xml
ターゲット定義ファイルのヘッダーの後の最初の行は、ターゲット・タイプを識別します。次の引用では、メタデータ・バージョン(META_VER="2.0")およびターゲット・タイプ(TYPE="test_demo_targetType")を定義しています。
<TargetMetadata META_VER="2.0" TYPE="test_demo_targetType">
TargetMetadata要素のTYPE属性およびMETA_VER属性は、デフォルトの収集メタデータ・ファイルのTargetCollection要素のTYPE属性およびMETA_VER属性と一致している必要があります。デフォルトの収集メタデータ・ファイルの詳細は、「デフォルトの収集ファイルの作成」を参照してください。
管理エージェントごとに使用可能なメタデータ・バージョンは1つのみですが、メタデータをバージョニングすることにより、管理対象環境内に同じターゲット・タイプ・メタデータの異なるバージョンを同時に存在させることが可能になります。ターゲット・メタデータ・ファイルを更新するたびに、メタデータのバージョンを更新する必要があります。
メタ値の構文は、MajorNumber.MinorNumberです。MinorNumberの値は1桁または2桁にできます。MinorNumberに1桁または2桁を使用し、プラグインのライフサイクル全体を通してその構文を引き続き使用することを決めることが重要です。
1桁のMinorNumberは最大9回まで更新でき、その後MajorNumber値を増やす必要があります。次に例を示します。
1.0, 1.1, 1.2, ...,1.9, 2.0, 2.1
2桁のMinorNumberは最大99回まで改訂できます。次に例を示します。
1.01, 1.02, 1.09, ..., 1.10, 1.11, ..., 1.99, 2.01
1桁形式と2桁形式を組み合せることはできません。たとえば、バージョンを1.9から1.10に上げることは有効ではありません。
プラグインの開発中に1つ以上のメトリックのメタデータを変更するか、資格証明を変更するか、ターゲット・プロパティ・ファイルを更新する場合、TargetMetadata要素のMETA_VER属性の値を次の桁値に増分してください。たとえば、現在のバージョンが1.0の場合、メトリック・データを変更するときはその値を1.1に設定してください。
<TargetMetadata META_VER="1.1" TYPE="demo_hostsample">
メトリックを変更するたびに、引き続きバージョンを増分させます。そうしないと、前のバージョンがデプロイされていた同じ開発またはテスト用インストールにプラグインがデプロイされると、NullPointerExceptionエラーが発生することがあります。
プラグインの開発が完了したら、META_VER値は安全に実際の本番バージョンに設定できます。
ほとんどの場合、データの収集やジョブの実行を行う各ターゲット・インスタンスとの認証にはプラグインが必要です。認証の有効化に必要な資格証明タイプおよび資格証明セットは、ターゲット・タイプ・メタデータ・ファイル内のCredentialInfo要素に定義されます。
詳細は、「資格証明の定義」を参照してください。
ターゲットの資格証明情報には、資格証明フィールド(列)とターゲット・タイプに固有の資格証明セットが含まれ、定義されます。Enterprise Managerのセキュリティ・フレームワークには、これらの資格証明を管理し、様々な管理機能を実行する際に使用するための機能が用意されています。
拡張フレームワークでは、タイプ・プロパティを使用して、フレームワーク処理のターゲット・タイプを内部的に分類します。これはエンド・ユーザーには表示されません。対応するサブシステムでは、ターゲット・タイプの機能を有効化する際や、適切な検証チェックを実行する際に、タイプ・プロパティが使用されます。
タイプ・プロパティ・レベルに設定された値は、特定のターゲットにのみ適用されるインスタンス・プロパティとは異なり、そのタイプのすべてのターゲットとあらゆるメタバージョン全体に適用されます。
次の例では、ターゲット・タイプがターゲットのシステム・クラスであることを指定しています。拡張フレームワークではこの設定を使用して、すべてのシステム・ページのターゲットを表示します。
<TypeProperties> <TypeProperty PROPERTY_NAME="is_system" PROPERTY_VALUE="1"/> </TypeProperties>
表3-2に、使用可能なタイプ・プロパティを説明します。
表3-2 タイプ・プロパティ
| プロパティ名 | 説明 |
|---|---|
|
システム・タイプのモデリングとしてタイプを指定します。この値は、すべてのシステム・タイプに設定する必要があります。
注意: |
|
サービスのモデリングとしてタイプを指定します。 注意: |
|
この値は、Enterprise Managerにより自動的に設定されます。変更しないでください。 |
|
使用しないでください |
|
使用しないでください |
|
この値は、インストール・ホームの管理可能なエンティティ(Oracleホームなど)に設定します。 |
|
この値は、存在のみの状態で検出されたエンティティ、つまり、検出されたがまだOracleによって管理できないエンティティに設定します。 使用可能な値:
注意: エンティティがOracleの管理対象エンティティになった場合は、このエントリをターゲット・タイプ・メタデータ・ファイルから削除し、ターゲット・タイプを再度登録する必要があります。 |
|
このプロパティは権限の伝播に使用され、権限の伝播モードを指定します。 使用可能な値は次のとおりです。
|
|
特定のターゲット・タイプ(冗長性グループの無効化が設定されている)の冗長性グループを無効化するために、冗長性グループ機能によって使用されます。冗長性グループにこのタイプをメンバーとして含めることを許可するかどうかを指定します。 使用可能な値:
|
|
ターゲット・タイプを指定されたmember_target_typeにロックするために、冗長性グループ機能によって使用されます。 |
|
(すべてのターゲット・ページおよびプラグイン資格証明の)ターゲット・タイプのターゲット・バージョンを表す、インスタンスまたは動的プロパティの名前を指定します。 注意: ターゲット・タイプを定義する場合にこのプロパティを含めることをお薦めします。 |
例: タイプ・プロパティの定義
<TargetMetadata META_VER="1.1" TYPE="oracle_dbsys" CATEGORY_PROPERTIES="" RESOURCE_BUNDLE_PACKAGE="oracle.sysman.db.rsc">
<Display>
<Label NLSID="oracle_dbsys_nlsid">Database System</Label>
</Display>
<TypeProperties>
<TypeProperty PROPERTY_NAME="is_system" PROPERTY_VALUE="1"/>
<TypeProperty PROPERTY_NAME="priv_propagation_mode" PROPERTY_VALUE="2"/>
</TypeProperties>
<MonitoringMode MEDIATOR="Repository"/>
</TargetMetadata>
インスタンス・プロパティは、ターゲット・インスタンスの作成時に移入されます。ターゲット・タイプ・メタデータ・ファイル内のInstanceProperties記述子は、この特定のターゲット・タイプの新規ターゲット・インスタンスを追加する際に管理者がEnterprise Manager Cloud Controlコンソールで指定する必要のあるプロパティを定義します。
InstancePropertiesセクションは、ターゲット・タイプ・メタデータ・ファイル内の様々な場所に定義できますが、一貫性を維持するために、このセクションをファイルの最後に定義することをお薦めします。ターゲット・タイプ・メタデータ・ファイルで定義されるインスタンス・プロパティは、ターゲット・タイプ・メタデータ・ファイル内のこれらのインスタンス・プロパティに対して指定される値に解決されます。
ターゲット・インスタンス・プロパティは、名前の付いた値であり、ターゲットのメトリックの計算、またはターゲットのホームページでの表示に使用できます。ターゲット・インスタンス・プロパティのリストをメタデータで指定して、データ駆動のユーザー・インタフェースがターゲットを登録できるようにすること、またOracle Management Agentがターゲット・インスタンスの完了を検証できるようにすることができます。
インスタンス・プロパティは、ターゲット・インスタンスの作成時に移入されます。この例では、プロパティは必須(OPTIONAL="FALSE)であり、資格証明プロパティです。
<InstanceProperties> <InstanceProperty NAME="password" OPTIONAL="FALSE" CREDENTIAL="TRUE"> <Display> <Label NLSID="USER_PASSWORD">User Password</Label> </Display> </InstanceProperty> </InstanceProperties>
動的なインスタンス・プロパティの値は、ターゲット・インスタンスからデータを収集している管理エージェントによって戻されます。通常、メトリック収集を実行するfetchletに渡すプロパティを定義するために、QueryDescriptor内で使用されます。QueryDescriptor要素の詳細は、表3-4を参照してください。fetchletの詳細は、「fetchletの使用」を参照してください。
次の例のプロパティは、「基本レスポンス・メトリック・グループの定義」で説明されています。
<InstanceProperties> <DynamicProperties NAME="AruidInfo" FORMAT="ROW" OPT_PROP_LIST="ARUID"> <QueryDescriptor FETCHLET_ID="OSLineToken"> <Property NAME="scriptsDir" SCOPE="SYSTEMGLOBAL">scriptsDir</Property> <Property NAME="perlBin" SCOPE="SYSTEMGLOBAL">perlBin</Property> <Property NAME="command" SCOPE="GLOBAL">%perlBin%/perl</Property> <Property NAME="script" SCOPE="GLOBAL">%scriptsDir%/hostaruid.pl</Property> <Property NAME="startsWith" SCOPE="GLOBAL">em_result=</Property> <Property NAME="delimiter" SCOPE="GLOBAL">|</Property> </QueryDescriptor> </DynamicProperties> </InstanceProperties>
動的プロパティを使用すると、特定のプロパティの値を正しく指定するようユーザーに要求するかわりにそのプロパティを計算できるため、ターゲットの構成に関連する作業が削減されます(たとえば、データベースのVersionプロパティは特定のアドレッシング情報を確実に計算できます)。
動的プロパティは、XMLファイルで定義されている順番で計算されるため、順番の遅い動的プロパティでは、必要な場合には、XMLファイルのそれより前の動的プロパティの値を使用することが可能です。
管理エージェントは、ターゲットの再起動が検出されるたび(ターゲット・ステータスが「稼働中」に変化するたび)にプロパティを再計算することで、これらの動的プロパティを正常に計算するにはターゲットが稼働している必要があるという事実に対応しています。
注意:
一部のプロパティは、ターゲットにアクセスせずに計算できるため、ターゲットが停止している場合でも、動的プロパティを計算できる場合があります。
ターゲットの停止中に動的プロパティを計算するには、次の属性を含めます。
COMPUTE_WHEN_DOWN="TRUE"
メトリックは、Cloud Controlのターゲット監視機能の中核です。様々なターゲットを監視および管理するCloud Controlの機能を説明する際、実際に説明するのは、ターゲット・メトリックを収集、処理、表示する機能についてです。
メトリックは、ターゲットから収集されたデータの特定部分を参照します。
メトリックには、2つの基本的なタイプがあります。
このモデルでは、プラグインにより、デフォルトの収集ファイルに指定された頻度でメトリック・データのターゲットがポーリングされます。これが、プラグインにより使用される最も一般的なタイプのメトリックです。
このタイプのメトリックでは、入力として引数(たとえば、スクリプト、SQL文、ターゲット・インスタンスのプロパティ)を受け取り、書式設定されたデータを返すパラメータ化されたデータ・アクセス・メカニズムであるfetchletを使用する必要があります。
プラグインで使用できるよう、事前定義済のfetchletが用意されています。使用可能なfetchletのリストおよびその使用方法の詳細は、「fetchletの使用」を参照してください。
このモデルでは、プラグインは、リクエストなしでターゲットから非同期で送信される通知を受信します。このタイプのメトリックには、プラグインでのそのような通知の受信を可能にするreceiveletが必要です。fetchlet同様、事前定義済のreceiveletが用意されています。receiveletの使用方法の詳細は、「receiveletの使用」を参照してください。
ターゲット・メタデータでは、プラグインで収集する各タイプのメトリック、メトリック・データの収集方法と時期、およびCloud Control内で生成されるインシデントをトリガーするメトリックしきい値の種類を定義する必要があります。
注意:
Cloud Control UIから表示できるすべてのメトリックは、適切な表示ラベルおよびNLSIDを持つ必要があります。
メトリック・グループおよび個々のメトリックのメタデータは、プラグインにパッケージ化されている2つのメタデータ・ファイルに定義されます。
ターゲット・タイプ・メタデータ・ファイルの内容は、主にメトリック定義、資格証明情報およびターゲット・プロパティで構成されています。メトリックが使用するfetchletまたはreceiveletは、ターゲット・タイプ・メタデータ・ファイル内のQueryDescriptorまたはPushDescriptor要素に定義されます。
主なメトリック定義要素の詳細は、「主なメトリック・メタデータ要素の概要」を参照してください。
各メトリックに対してデータが収集される頻度は、デフォルトの収集メタデータ・ファイルに定義されます。各メトリックのメトリック・アラート・イベント条件とそのようなアラートの表示メッセージも、このファイルで定義されます。
デフォルトの収集メタデータ・ファイルの詳細は、「デフォルトの収集ファイルの作成」を参照してください。
事実上、各ターゲット・タイプの次のメトリックを含む、1つ以上のResponseメトリック・グループを指定することをお薦めします。
ターゲットの可用性を示すステータス・メトリック(すべてのターゲット・タイプに必要)
対応するデフォルトの収集ファイルでは、ターゲットのステータスを起動または停止で表すStatusメトリックにクリティカルの条件を定義する必要があります。詳細は、「基本のメトリック収集の定義」を参照してください。
次の例(レスポンス・メトリック)では、Statusメトリックを定義します。Statusの戻り値は次のとおりです。
0: ターゲットのステータスは停止です。
1: ターゲットのステータスは起動です。
メトリック・データが収集されるプロセスは、QueryDescriptor要素に定義されます。この記述子は、OSLineToken fetchletでPerlスクリプト(emrepresp.pl)を起動してデータを収集することを指定します。Perlスクリプトは、収集されたデータを含む標準の出力(stdout)データ・ストリームをfetchletに戻します。
OSLineToken fetchlet実行に渡される各プロパティは、QueryDescriptor要素のPropertyタグに指定されます。
OSLineToken fetchletでは、commandというGLOBALプロパティが実行されるコマンドに設定されている必要があります。通常、それぞれのトークンには固有の必須プロパティがあります。OSLineToken fetchletの詳細は、「OSコマンドfetchlet」を参照してください。
管理エージェントにプラグインがデプロイされると、プラグイン・アーカイブの/agent/scriptsディレクトリにパッケージ化されている関連付けられたスクリプトまたはバイナリが、管理エージェントの次のディレクトリに書き込まれます。ここで、AGENT_HOMEは、管理エージェントのプラグイン・ホーム・ディレクトリで、plugin_nameはプラグインの名前です。
AGENT_HOME/plugins/plugin_name
scriptsDirプロパティは、この場所を定義するトークンです。
注意:
Enterprise Manager 11g以前では、プラグインにバンドルされたスクリプトは、管理エージェントの下位のスクリプト・ディレクトリにコピーされていました。ただし、このリリースでは、プラグインに含まれるスクリプトは直接使用されます。これにより、QueryDescriptor要素内のscriptsDirプロパティの動作が変わります。以前は、管理エージェントの下位のディレクトリを参照していましたが、現在はプラグインの下位のディレクトリを参照しています。管理エージェントの下位のスクリプト・ディレクトリを参照する必要がある場合は、sdkScriptsDirプロパティを使用してください。
scriptプロパティは、実行するスクリプト(data_collector.pl)を指定します。
EDKには、このスクリプトのサンプルがあります。
edk/samples/plugins/HostSample/demo_hostsample/stage/agent/scripts/emx/demo_hostsample
startsWithおよびdelimiterプロパティは、実行されるスクリプトのSTDOUTの形式を指定します。この場合、スクリプトは次のような単一の行を戻します。
em_result="value for Load|value for Status"
例: レスポンス・メトリック
<Metric NAME="Response" TYPE="TABLE">
<TableDescriptor>
<ColumnDescriptor NAME="Status" TYPE="NUMBER">
<Display>
<Label NLSID="oracle_emrep_resp_status">Status</Label>
</Display>
</ColumnDescriptor>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="OSLineToken">
<Property NAME="perlBin" SCOPE="SYSTEMGLOBAL">perlBin</Property>
<Property NAME="scriptsDir" SCOPE="SYSTEMGLOBAL">scriptsDir</Property
<Property NAME="command" SCOPE="GLOBAL">%perlBin%/perl</Property>
<Property NAME="script" SCOPE="GLOBAL">%scriptsDir%/emrepresp.pl</Property>
<Property NAME="startsWith" SCOPE="GLOBAL">em_result=</Property>
<Property NAME="delimiter" SCOPE="GLOBAL">|</Property>
</QueryDescriptor>
</Metric>
これらの要素の詳細は、「主なメトリック・メタデータ要素の概要」を参照してください。
CPUパフォーマンス・データを収集するメトリックや、別のメトリックの値から値が計算されるメトリックなど、さらに複雑なメトリックを定義できます。EDKには、そのような拡張メトリックまたは複雑なメトリックの定義例を参照できる、サンプルのターゲット・タイプ・メタデータ・ファイルが用意されています。
edk/samples/plugins/HostSample/demo_hostsample/stage/oms/metadata/targetType/demo_hostsample.xml
次の例は、CPUパフォーマンス・データを収集するメトリックを含むメトリック・グループを示しています。前述の例のように、QueryDescriptor要素には、OSLineToken fetchletでdata_collector.plスクリプトを起動してデータを収集することが指定されています。
例: 拡張メトリックの定義
<Metric NAME="CPUProcessesPerf" TYPE="TABLE">
<Display>
<Label NLSID="hs_cpuprocessesperf_displayname">Host Process CPU Performance
Statistics</Label>
</Display>
<TableDescriptor>
<ColumnDescriptor NAME="ProcPID" TYPE="NUMBER" IS_KEY="TRUE">
<Display>
<Label NLSID="hs_cpuprocessesperf_procpid">PID</Label>
</Display>
</ColumnDescriptor>
<ColumnDescriptor NAME="ProcUser" TYPE="STRING" IS_KEY="FALSE">
<Display>
<Label NLSID="hs_cpuprocessesperf_procuser">User</Label>
</Display>
</ColumnDescriptor>
<ColumnDescriptor NAME="ProcCPU" TYPE="NUMBER" IS_KEY="FALSE">
<Display>
<Label NLSID="hs_cpuprocessesperf_proccpu">CPU Usage (%)</Label>
</Display>
</ColumnDescriptor>
<ColumnDescriptor NAME="ProcCmd" TYPE="STRING" IS_KEY="FALSE">
<Display>
<Label NLSID="hs_cpuprocessesperf_proccmd">Command</Label>
</Display>
</ColumnDescriptor>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="OSLineToken">
<Property NAME="scriptsDir" SCOPE="SYSTEMGLOBAL">scriptsDir</Property>
<Property NAME="perlBin" SCOPE="SYSTEMGLOBAL">perlBin</Property>
<Property NAME="command" SCOPE="GLOBAL">%perlBin%/perl</Property>
<Property NAME="script" SCOPE="GLOBAL">%scriptsDir%/emx/demo_hostsample/data_
collector.pl</Property>
<Property NAME="startsWith" SCOPE="GLOBAL">em_result=</Property>
<Property NAME="delimiter" SCOPE="GLOBAL">|</Property>
</QueryDescriptor>
</Metric>
次の例は、テスト・メトリックを示しています。管理エージェントは、一部のメトリックをチェックして、有効なインスタンス・プロパティを使用してターゲットが正しく指定されているかどうかを判断できます。IS_TEST_METRIC属性をTRUEに設定すると、ターゲット・インスタンスの追加時にテスト・ボタンが表示されます。
例: テスト・メトリックの定義
<Metric NAME="Ping" TYPE="TABLE" IS_TEST_METRIC="TRUE" USAGE_TYPE="HIDDEN">
<Display>
<Label NLSID="label_metrics_ping">Ping Test</Label>
</Display>
<TableDescriptor>
<ColumnDescriptor NAME="tcpIpPing" TYPE="NUMBER">
<Display>
<Label NLSID="test_ping">TCP Ping, Milliseconds</Label>
</Display>
</ColumnDescriptor>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="OSLineToken">
<Property NAME="perlBin" SCOPE="SYSTEMGLOBAL">perlBin</Property>
<Property NAME="scriptsDir" SCOPE="SYSTEMGLOBAL">scriptsDir</Property>
<Property NAME="command" SCOPE="GLOBAL">%perlBin%/perl
%sdkScriptsDir%/osresp.pl</Property>
<Property NAME="ENVEM_TARGET_NAME" SCOPE="INSTANCE">hostName</Property>
<Property NAME="startsWith" SCOPE="GLOBAL">em_result=</Property>
<Property NAME="delimiter" SCOPE="GLOBAL">|</Property>
</QueryDescriptor>
</Metric>
デフォルトでは、管理エージェントがメトリックを収集しますが、リポジトリ・メトリックを定義することができます。リポジトリ・メトリックは管理リポジトリで収集されます。
リポジトリ・メトリックを定義するには、メトリック要素を定義する際、REPOSITORY属性を使用する必要があります。メトリック要素の詳細は、表3-4を参照してください。
次の例は、リポジトリ・メトリックが定義されているターゲット・メタデータXMLファイルからの抽出を示しています。
注意:
リポジトリ・メトリックを定義する際、メトリックのTYPE属性をTABLEに設定する必要があります。RAWはリポジトリ・メトリックでサポートされていません。
例: リポジトリ・メトリックの定義
<Metric NAME="Response"
TYPE="TABLE"
REPOSITORY="TRUE">
<Display>
<Label NLSID="REPOS_SQL">REPOS_SQL</Label>
</Display>
<TableDescriptor>
<ColumnDescriptor NAME="Status" TYPE="NUMBER">
<Display>
<Label NLSID="Status">Status</Label>
</Display>
</ColumnDescriptor>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="REPOSITORY_SQL">
<Property NAME="Type">SQL</Property>
<Property NAME="Source">SELECT target_guid, 1 as Status from mgmt_targets where target_type='tvmrtm200'</Property>
</QueryDescriptor>
</Metric>
メトリックのカテゴライズの目的は、収集されるデータの性質を定義することです。これは、Cloud Controlコンソールの「すべてのメトリック」ページに表示されるメトリックに対してのみです。
メトリック・カテゴリを定義する場合は次のガイドラインを使用することをお薦めします。
Cloud Controlコンソールの「すべてのメトリック」ページで、ユーザーに表示されるすべてのメトリックおよびメトリック・グループをカテゴライズします。
表3-3に記載されている公開済のカテゴリ値のみを使用します。
メトリック・グループ内のすべてのメトリックが同じカテゴリに属する場合、メトリック・グループ・レベルでカテゴリを設定し、メトリック・レベルでカテゴリを空のままにしておくことができます。グループ内のすべてのメトリックは、このカテゴリを継承します。メトリック・グループ・レベルでは1つのカテゴリのみを設定できます。例は、「メトリック・グループ・レベルでのカテゴリの定義」を参照してください。
メトリック・グループ内のメトリックが様々なカテゴリを持つ場合、メトリック・グループ・レベルでカテゴリを設定しないでください。このような場合は、メトリック・レベルでカテゴリを設定します。各メトリックはカテゴリを1つのみ持つことができます。例は、「メトリック・レベルでのカテゴリの定義」を参照してください。
メトリック・フレームワークは、Defaultメトリック・クラスと、このクラス内にメトリック・カテゴリのセットを持ちます。表3-3に、使用可能なメトリック・カテゴリのリストを示します。Defaultメトリック・クラス内の適切なカテゴリにメトリックをカテゴライズできます。
表3-3 メトリック・カテゴリ
| カテゴリ | 説明 |
|---|---|
Availability |
ターゲットまたはコンポーネントが稼働しているかどうかを知ることができます。主にResponseまたはStatusメトリックで使用されます。 |
Capacity |
何か持つ量を定義します。 |
Fault |
コンポーネントの非動作、メモリの破損またはデータの破損を招く重大なエラーです。 |
ロード |
エンティティに実行が求められている作業量です。 |
LoadType |
エンティティが実行を求められている作業の特性を示します。 |
Response |
どれだけ迅速にシステムが応答するかです。 |
BusinessKPI |
ビジネスの点で成果を測定します。 |
Utilization |
エンティティが使用しているものの割合 |
Security |
セキュリティ問題に関するレポート。 |
次の例では、MyMetricGroup内でDefaultというメトリック・クラスとLoadというメトリック・カテゴリを持つすべてのメトリックをカテゴライズします。
例: メトリック・グループ・レベルでのカテゴリの定義
<Metric NAME="MyMetricGroup" TYPE="TABLE">
<Display> <Label>MyMetricGroup</Label> </Display>
<CategoryValue CLASS="Default" CATEGORY_NAME="Load"/>
<TableDescriptor>
<ColumnDescriptor NAME="MyMetric1" TYPE="NUMBER"> </ColumnDescriptor>
<ColumnDescriptor NAME="MyMetric2" TYPE="NUMBER"> </ColumnDescriptor>
</TableDescriptor> </Metric>
次の例では、Defaultというメトリック・クラスとLoadというメトリック・カテゴリを持つMyMetric1メトリックと、Defaultというメトリック・クラスとLoad Typeというメトリック・カテゴリを持つMyMetric2メトリックをカテゴライズします。
例: メトリック・レベルでのカテゴリの定義
<<Metric NAME="MyMetricGroup" TYPE="TABLE">
<Display>
<Label>MyMetricGroup</Label>
</Display> <TableDescriptor>
<TableDescriptor>
<ColumnDescriptor NAME="MyMetric1" TYPE="NUMBER">
<Display>
<Label>MyMetric1</Label>
</Display>
<CategoryValue CLASS="Default" CATEGORY_NAME="Load"/>
</ColumnDescriptor>
<ColumnDescriptor NAME="MyMetric2" TYPE="NUMBER">
<Display>
<Label>MyMetric2</Label>
</Display>
<CategoryValue CLASS="Default" CATEGORY_NAME="Load Type"/>
</ColumnDescriptor>
</TableDescriptor>
</Metric>
Enterprise Managerには、問題なく適応できるメトリックしきい値を統計学的に計算するオプションが用意されており、このオプションはすべてのターゲットに使用できます。
適応しきい値の詳細は、Oracle Enterprise Manager管理ガイドを参照してください。
ターゲット・タイプに名前付き構成を指定できます。このクイック構成には、事前構成済のメトリック値と計算メカニズムが含まれています。
クイック構成を定義する手順は次のとおりです。
表3-4 メトリックの定義に使用される主な要素
| 要素 | 説明 |
|---|---|
|
必須。それぞれが
|
|
メトリックの |
|
収集される単一のメトリックを定義します。次の属性があります。
|
|
注意: <Property NAME="perlBin" SCOPE="SYSTEMGLOBAL">perlBin</Property> <Property NAME="command" SCOPE="GLOBAL">%perlBin%/perl</Property> 要素には、リクエストの処理に使用されるfetchletのメカニズムを識別する 次に、プラグイン開発者が一般的に使用するfetchletを示します。
使用可能なfetchletの完全なリストおよびその使用方法の詳細は、「fetchletの使用」を参照してください。 SCOPEプロパティは、プロパティ値を取得する場所を定義します。次の有効範囲オプションを使用できます。
|
|
オブジェクト識別子(OID)を定義します。管理エージェントはSNMP receiveletを使用して、ターゲット・タイプの管理情報ベース(MIB)での定義に従ってSNMPトラップをリスニングします。
注意: <Property NAME="MatchSpecificTrap" SCOPE="GLOBAL">50</Property> <Property NAME="MatchAgentAddr" SCOPE="INSTANCE">AdminAddress</Property> 要素には、リクエストの処理に使用されるreceiveletのメカニズムを識別する SNMP receiveletは、プラグイン開発者が一般的に使用する唯一のreceiveletです。SNMP receiveletの詳細は、「receiveletの使用」を参照してください。 SCOPEプロパティは、プロパティ値を取得する場所を定義します。次の有効範囲オプションを使用できます。
|
|
集計メトリックの計算に使用されます。メトリック評価の実行計画を指定します。管理エージェントは、定義された順序で計画の各文を実行し、メトリックの結果を作成します。実行計画の最後の文の評価結果として生成されたメトリックの結果が戻されます。 |
表3-4では、メトリックを定義する主な要素を説明します。メトリックの定義の詳細は、「ターゲット・メタデータの作成のガイドライン」を参照してください。
この項では、メトリック定義で問題が発生した場合のトラブルシューティングのヒントについて説明します。
特定のターゲット・タイプのメトリックをSQL*Plusセッションから一覧表示するには、次のように入力します。
select * from mgmt_metrics where target_type=target_typeand type_meta_ver=max_type_meta
メトリック・ロードの問題があるかどうかをSQL*Plusセッションから確認するには、次のように入力します。
select * from sysman.mgmt_system_error_log where module_name='METRIC_LOAD'
メタデータのロード中に収集の問題があるかどうかをSQL*Plusセッションから確認するには、次のように入力します。
select * from sysman.mgmt_system_error_log where module_name='MGMT_COLLECTION.Collection Subsystem'
特定のターゲットについて何を収集するかをSQL*Plusセッションから確認するには、次のように入力します。
select * from sysman.gc_metric_values where entity_type=target_typeand entity_name=target_name
ターゲット・タイプのデフォルトの収集メタデータ・ファイルでは、次を定義します。
ターゲットから収集され、管理リポジトリに書き込まれるメトリック・データ(構成収集メトリック・データを含む)
このメトリック・データが収集される頻度
超過した場合に、メトリック・アラート・イベントが発生する原因となるしきい値
しきい値を超過した場合に表示されるオプションのメッセージ
注意:
デフォルトの収集ファイルには、ターゲット・タイプ・メタデータ・ファイルと同じファイル名を使用する必要があります。
たとえば、HostSampleプラグインのoms/metadata/targetType/demo_hostsample.xmlに存在するターゲット・タイプ・メタデータ・ファイルは、これに対応する同じ名前のデフォルトの収集ファイルがoms/metadata/default_collection/demo_hostsample.xmlに存在している必要があります。
ターゲット・タイプ・メタデータ・ファイルのネーミングの詳細は、「ターゲット・タイプ・メタデータ・ファイルのネーミング」を参照してください。
デフォルトの収集メタデータ・ファイルのTYPE属性およびMETA_VER属性の値は、これらの間に関連付けを作成するために、ターゲット・タイプ・メタデータ・ファイルに定義されているTYPEおよびMETA_VERの値と一致する必要があることに注意してください。
前述のとおり、各メトリックに、Enterprise Manager Cloud Control内でインシデントとして発生するメトリック・アラート・イベントの条件を指定することもできます。そのようなイベントは、このファイルに指定されたしきい値を超えた場合に生成されます。たとえば、CPU使用率が容量の90%に達した場合に、警告のアラートを生成できます。アラート・イベントがトリガーされた場合に、Enterprise Manager Cloud Controlに表示されるメッセージ・テキストを指定することも可能です。
EDKの次の場所には、デフォルトの収集ファイルのサンプルが含まれています。
/samples/plugins/HostSample/stage/oms/metadata/default_collection/demo_hostsample.xml
デフォルトの収集ファイルに要素を定義する方法の詳細は、「デフォルトの主な収集メタデータ要素の概要」および「ターゲット・メタデータの作成のガイドライン」を参照してください。
効率を高めるため、メトリックは通常、収集用にグループ化されており、特定のメトリックを同時または同じ頻度で収集することが可能です。別のメトリックの結果に依存するメトリックがある場合は、メトリックの実行順序が重要になるため、それが保証されて便利です。
一緒に収集するメトリックの各グループは、デフォルトの収集ファイル内のCollectionItemに定義します。グループの収集スケジュールは、Schedule要素に定義します。CollectionItemは、メトリックを有効または無効にし、収集スケジュールを変更するための最大限の制御手段をエンド・ユーザーに提供します。
グループに含まれる各メトリックは、CollectionItem内のMetricColl要素に順番に定義します。(「基本レスポンス・メトリック・グループの定義」に示されているResponseメトリックの例のように、CollectionItemに含まれるメトリックが1つのみの場合は、MetricCollタグを指定する必要がないことに注意してください。)
CollectionItemのUPLOAD値が6に設定されており、収集が6回目になるたびにデータが管理リポジトリに書き込まれることを意味しています。IntervalScheduleでデータの収集が5分ごとに指定されているため、データは30分ごと(つまり、6回目のデータ収集ごと)に管理リポジトリに書き込まれます。
<TargetCollection> ... <CollectionItem NAME="Perf" UPLOAD="6"> <Schedule> <IntervalSchedule INTERVAL="5" TIME_UNIT="Min"/> </Schedule> <MetricColl NAME="CPUProcessesPerf"> ... </MetricColl> <MetricColl Name="MemoryPerf"> ... </MetricColl> </CollectionItem> ... </TargetCollection>
次のいずれかが該当する場合は、メトリックをCollectionItemにグループ化することを検討してください。
すべてのメトリックがパフォーマンスに関連しているなど、メトリックが論理的に関連している場合
5分ごとに収集するすべてのメトリックなど、メトリックを同じ頻度で収集する必要がある場合
ピーク時以外に収集するメトリックなど、おおよそ同じ時間にメトリックを収集する必要がある場合
指定されているすべてのメトリックを同時に収集、または収集しない場合
オンデマンドで収集されるメトリックがある場合は、それらをグループ化すると、パフォーマンスが向上し、ターゲットからメトリック・データを収集して戻す際に行われる管理エージェントとOracle Management Service間の通信が低減されます。
様々な収集間隔を提供すると、各メトリックを個々にスケジュールするうえで最大の柔軟性が得られます。必要なメトリックを無効化せずにグループ内の少数のメトリックの収集のみをオフにすることはできないため、関連のないメトリックのグループ化はお薦めしません。
次に、Statusメトリックを含む、基本のResponseメトリック・グループのCollectionItemエントリを示します。これは、このメトリックのデータを5分ごと(このタイプのメトリックの標準的な収集間隔)に収集する必要があることを指定しています。
条件は、Statusメトリックに設定されています。アラート条件の詳細は、「デフォルトの収集ファイルの作成」および表3-5を参照してください。
CollectionItemに含まれるメトリックが1つのみ(Status)であるため、単一のメトリックにMetricCollタグを含める必要がないことに注意してください。
<TargetCollection META_VER="2.0" TYPE="test_demo_targetType"> ... <CollectionItem NAME="Response"> <Schedule> <IntervalSchedule INTERVAL="5" TIME_UNIT="Min"/> </Schedule> <Condition COLUMN_NAME="Status" CRITICAL="0" OPERATOR="EQ" CLEAR_MESSAGE_NLSID="Response_Status_clearalertmessage" MESSAGE="Failed to connect to database instance: %oraerr%."MESSAGE_NLSID="Response_Status_alertmessage"/> </CollectionItem> ... </TargetCollection>
次の例では、指定されたWARNINGおよびCRITICALのしきい値を超えた場合にメトリック・アラートを生成する、より高度なメトリックの収集を説明しています。これらのしきい値、およびそれを超えた場合にCloud Controlに送信するメッセージは、Condition要素に定義します。
各メトリックのデータは、この例に示すように、CollectionItem内のMetricColl要素に指定します。この例の要素の説明は、表3-5を参照してください。
例: 拡張メトリック収集の定義
<TargetCollection>
...
<CollectionItem NAME="Perf" UPLOAD="6">
<Schedule>
<IntervalSchedule INTERVAL="5" TIME_UNIT="Min"/>
</Schedule>
<MetricColl NAME="CPUProcessesPerf">
<Condition COLUMN_NAME="ProcCPU" WARNING="75" CRITICAL="90" OPERATOR="GE"
OCCURRENCES="2"
MESSAGE="The value for %columnName% is %value%%%, which is above the
critical (%critical_threshold%%%) or warning (%warning_threshold%%%)
threshold."
CLEAR_MESSAGE="The value for %columnName% is %value%%%, which is
below the critical (%critical_threshold%%%) or warning (%warning_
threshold%%%) threshold." />
</MetricColl>
</CollectionItem>
...
</TargetCollection>
WARNINGまたはCRITICALのしきい値を超えた場合にEnterprise Managerに送信するメッセージに加え、CLEAR_MESSAGE属性には、アラート条件が存在しない場合に送信されるすべてクリアのメッセージも定義されています。
その他のあらゆるメトリックと同じように、構成メトリック・データが収集される頻度は、デフォルトの収集ファイルに定義します。ターゲット構成収集のサイズと変更率が低いことを考慮し、これらのメトリックは、ピーク以外の時間に、24時間ごとに収集するのが理想的です。
構成メタデータ・ファイルにあるルートのMETADATA SNAP_TYPE属性のTARGET_TYPE属性の値は、デフォルトの収集ファイルにあるTargetCollectionのTYPE属性と同じであることが必要です。
次の例では、HostConfigメトリックの収集頻度を定義しています。
<TargetCollection>
...
<CollectionItem NAME="HostSampleSnap" CONFIG="TRUE">
<Schedule OFFSET_TYPE="INCREMENTAL">
<IntervalSchedule INTERVAL="24" TIME_UNIT="Hr"/>
</Schedule>
<MetricColl NAME="HostConfig" />
</CollectionItem>
...
</TargetCollection>
表3-5に、デフォルトの収集メタデータ・ファイルに含まれる主な要素を説明します。
表3-5 デフォルトの収集メタデータ・ファイル内の要素
| 要素 | 説明 |
|---|---|
|
必須。ファイルのルート要素。ターゲット・タイプ・メタデータ・ファイルの |
|
一連のメトリックの収集頻度としきい値を定義します。含まれる
|
|
CollectionItemの収集頻度を定義する
注意: レスポンス・メトリックは頻繁に収集する必要があります。1分から5分の間の値で収集間隔を定義します。他のメトリックの収集の頻度は下げる必要があります。通常は15分の間隔で十分です。ただし、大量のデータを収集するメトリックを定義する場合は、30分または1時間の間隔を検討してください。 |
|
ターゲット・タイプ・メタデータ・ファイルのMetric要素に定義されている単一のメトリック・グループに対応する、1つ以上のCondition要素が含まれます。各条件は、指定された単位と、しきい値を上げる値の%value%プレースホルダを備えたメトリック記述を含む、関連付けられたアラート・メッセージを持つ必要があります。 この要素のNAME属性は、対応するMetric要素のNAME属性と一致する必要があります。 |
|
メトリック・アラート条件を定義します。これには次に示す、オプションの属性が含まれます。
|
新しいプラグインのターゲット・タイプ定義ファイルを開発する際には、特定のターゲット・タイプを監視する方法を入念に検討する必要があります。ターゲット・タイプの監視方法は、Enterprise Managerのパフォーマンスに大きく影響します。システム・パフォーマンスを最適化するには、次に示す、ターゲット・メタデータおよび収集を定義するための一般ガイドラインに従ってください。
メタデータは、データに関するデータです。一般に、この用語はネットワーク・エンティティの識別、記述および特定を支援するために使用されるデータを表します。Enterprise Managerターゲットのターゲット・メタデータは、ユーザーが公開するメトリックと、これらのメトリックの計算に使用されるメソッドから構成されます。
注意:
表示可能なすべてのメトリックがカテゴライズされていることを確認します。最低でも、しきい値を持つメトリックはカテゴライズして、生成されるインシデントがカテゴライズされるようにする必要があります。カテゴライズの詳細は、メトリックのカテゴライズに関する説明を参照してください。
メタデータ・バージョン
ターゲット・メタデータが変更されるたびに、メタデータ・バージョン(META_VER)を増やします。詳細は、ターゲット・タイプ・メタデータの定義に関する説明を参照してください。
リアルタイムのみのメトリック
パフォーマンス・メトリックは、パフォーマンス傾向を追跡するために計算する必要のあるメトリックと、特定の時点での詳細を取得するためのドリルダウンに役立つその他のメトリックに分類されます。リアルタイムのみのメトリックには、さらに診断を行うために、システムの特定のサブセットに関する詳細情報(特定のプロセスのリソース使用率など)を返すためにコンテキスト情報を必要とするメトリックが含まれます。
キー列の選択
メトリックのキー列は、軸上のパフォーマンス・データの傾向(データベース表領域ごとの表領域使用率など)を調べるために管理リポジトリで使用されます。キーベースのメトリックは、ターゲットの監視目的にしろターゲットの診断目的にしろ、意味のあるメトリック・データを収集する必要のあるターゲットのサブコンポーネントをモデル化するために使用する必要があります。したがって、ターゲット・サブコンポーネントの論理識別子であるキー列のみはメトリックに含める必要があります。
多数のターゲットにわたって収集された明確な値の数に対してキー列を含めると、管理リポジトリに格納されるキー値の数が過剰になる可能性があることに注意してください。たとえば、タイムスタンプ(またはデータベースSCNまたはUNIX ctimeなどの同等物)をキー値として使用すると、各ターゲットの各収集は新しい値になるため、お薦めしません。
キー列の組合せを含めることも問題になる可能性があります。たとえば、メトリックに3つのキー列を含めると、各キーは、ターゲットの数をかけた10のターゲット固有の値(10 X 10 X 10)の1つをとることができ、1つのターゲット当たり1000のキーのデータを収集することになります。一握り以上のターゲットを管理する場合、これは過剰とみなされることがあります。
ターゲットと時間にわたって、共有不可能で永続性のあるキーを持つメトリックを定義しないでください。
キー列を使用する必要はありませんが、問合せ記述子は単一行を返す必要があります。
注意:
メトリックの作成後に、キー列、つまり順序、データ・タイプまたは数を変更しないでください。
場合によっては、メトリック列を使用して、より重要な他のメトリック列の値を計算できます。元の列が不要な場合は、これらの列を一時としてマークすれば管理リポジトリにアップロードされないので、領域を節約することができます。
持続時間に依存するメトリックはアップロードしないでください。これらのタイプのメトリックは一時としてマークしてください。これには、リクエスト・プロセス(最後の収集間隔)などのデルタ・メトリックが含まれます。
メトリックには、最近のアクティビティのデータ値を含める必要があります。多くの場合、これを行うには、既存のメトリックから率メトリックを作成する必要があります。COMPUTE_EXPR属性(表3-4で定義)には、列の値を計算するための式を指定します。次のリストは、計算式についてサポートされている文法を示しています。
expression := (cond_expr | (cond_expr ? cond_expr : cond_expr)
cond_expr := (string_expr |
(string_expr == string_expr) |
(string_expr < string_expr) |
(string_expr > string_expr) |
(string_expr <= string_expr) |
(string_expr >= string_expr) |
(string_expr __contains string_expr) |
(string_expr __beginswith string_expr) |
(string_expr __endswith string_expr) |
(string_expr __matches string_expr) |
(string_expr __delta string_expr))
string_expr := (simple_expr |
(simple_expr __leadingchars simple_expr) |
(simple_expr __trailingchars simple_expr) |
(simple_expr __substringpos simple_expr))
simple_expr := (term |
(simple_expr + term ) |
(simple_expr - term) )
term := (unary_expr |
(term * unary_expr ) |
(term / unary_expr ) )
unary_expr := (factor |
(__is_null factor) |
(__length factor) |
(__to_upper factor) |
(__to_lower factor) |
(__ceil factor) |
(__floor factor) |
(__round factor) )
factor := ( identifier |
string_literal |
number |
'(' expression ')' )
string_literal := '\'' (character | "\\'" )* '\''
既存のメトリックから率メトリックを作成するには、次のメトリックを定義します。
デルタの計算
requests.completed.delta = (requests.completed > _requests.completed) ? (requests.completed - _requests.completed) : 0
requests.completedの現在の値が前の値より大きい場合、現在の値と最後の値の差を求めてデルタを得ます。それ以外の場合は0が返されます。
率の計算
requests.completed (per minute) = (requests.completed > _requests.completed) ? (requests.completed - _requests.completed) *60 /__interval: 0
requests.completedの現在の値が前の値より大きい場合、現在の値と最後の値の差を求めて60を掛け、それを2つの収集間の間隔で割ってデルタを得ます。それ以外の場合は0が返されます。
メトリックおよびMicrosoft Windows
カスタム・ターゲットのメトリックを作成する際には、追加のオペレーティング・システム(OS)プロセスを作成するコスト(CPU使用率)を考慮することが重要です。このことは、LinuxやOracle SolarisなどのUNIXベース・システムに比べてプロセス作成にCPUを大量に使用するMicrosoft Windowsを実行しているシステムに当てはまります。CPU使用率は、子プロセスの作成に対して線形に増加します。プロセス作成を最小化するために、メトリック収集スクリプトからOSプログラムまたはコマンドを実行することは避けてください。たとえば、Perlスクリプトを作成する場合、システム関数またはバッククォート(``)を使用してOSコマンドを実行することは避けてください。
ターゲットのプロパティ(静的および動的)
ターゲット・プロパティは、名前の付いた値であり、ターゲットのメトリックの計算、またはターゲットのホームページでの表示に使用できます。ターゲット・プロパティのリストをメタデータで指定して、データ駆動のユーザー・インタフェースがターゲットを登録できるようにすること、また管理エージェントがターゲット・インスタンスの完了を検証できるようにすることが可能です。
静的インスタンスのプロパティ: これらは、ターゲットのtargets.xmlエントリでターゲットに対して値を指定する必要のあるプロパティです。プロパティが指定されていなくてもターゲット宣言が完了したとみなされる場合は、インスタンス・プロパティをオプションとして指定できます。ターゲット・プロパティのメタデータ指定では、構成ユーザー・インタフェースで使用するデフォルト値も提供できます。
動的インスタンスのプロパティ: 管理エージェントでは、ターゲット・インスタンスのプロパティを計算することもできます。このようなプロパティは、メトリックで使用されるのと非常によく似たQueryDescriptorを使用して計算されます。
動的プロパティを使用すると、特定のプロパティの値を正しく指定するようユーザーに要求するかわりにそのプロパティを計算できるため、ターゲットの構成に関連する作業が削減されます(たとえば、データベースのVersionプロパティは特定のアドレッシング情報を確実に計算できます)。
管理エージェントは、ターゲット・バウンスが検出されるたび(ターゲット・ステータスが「稼働中」に変化するたび)にプロパティを再計算することで、これらの動的プロパティを正常に計算するにはターゲットが稼働している必要があるという事実に対応しています。
メトリック
管理エージェントとの関連でのメトリックの概念は、構成およびパフォーマンス情報を示すために使用できます。
構成メトリック: 構成メトリックは、ターゲットの構成を示すターゲット・プロパティに似たデータを収集します。この情報は、定期的にリフレッシュされ、ターゲットの設定の変更を追跡するために使用できます。このようなメトリックの収集間隔は、通常は約24時間です。
パフォーマンス・メトリック: パフォーマンス・メトリックを使用して、ターゲットの応答性を追跡します。これらのメトリックは、通常は構成メトリックよりも頻繁に収集されますが、一部のパフォーマンス・メトリックの間隔は他のパフォーマンス・メトリックと大きく異なる場合があります。また、パフォーマンス・メトリックには、通常、ターゲットのパフォーマンス・アラートの基礎であるしきい値が付属しています。
すべてのターゲットの必須メトリックは、条件が指定された「ステータス」列から構成されるレスポンス・メトリックです。このメトリックは、ターゲットの可用性の追跡に使用されます。
Enterprise Managerユーザー・インタフェースの多くの部分はデータ駆動であるため、メトリックのネーミングに使用される規則は非常に重要です。たとえば、実際のメトリック列ラベルとキー値は、ページ・タイトル、指示テキストまたは列見出しの一部になる場合があります。具体的には、これらの要素は、Enterprise Managerユーザー・インタフェース内の「すべてのメトリック」ページ、メトリックと収集の設定ページ、「イベント・ルール」ページ、グループ・チャート・ページおよびその他のページに表示されます。このため、次のメトリック・ネーミング規則をお薦めします。
メトリックの列名はできるだけ明確なものにしてください。列名にはcountを含めないでください。名前の長さが増え、エンド・ユーザーに値が提供されないためです。次に例を示します。
エラー(/分)
注意: エラー件数(/分)は使用しないでください。
すべてのメトリック名(ラベル)は、特定のターゲット・タイプおよびバージョン内で一意である必要があり、ユーザーが簡単に理解できる必要があります(必要に応じてメトリック単位が使用されます)。メトリックが測定単位を指す場合、カッコ内のメトリック・ラベルに単位を含めます。次に例を示します。
ネットワーク・インタフェース合計I/Oレート(MB/秒)
処理済のリクエスト(/分)
コミット済のトランザクション(%)
起動時にリセットされる値を増やすメトリックはアップロードしないでください。これらのメトリックは一時的なものとしてマークし、起動時からカッコ内のメトリック・ラベルに含めます。次に例を示します。
処理時間(起動時以降)
エラー(起動時以降)
リクエスト(起動時以降)
平均実行時間(ミリ秒 - 起動時以降)
すべてのメトリック列名(ラベル)は、メトリック名に依存せずに自己説明的である必要があります。次に例を示します。
表領域使用率(%)
キー列名は自己説明的である必要があります。メトリックしきい値を指定する場合または通知を構成する場合に、Enterprise Managerではこれらの名前を使用します。読みやすくするために、キー列名の名前が「すべてのキー列名オブジェクト」という句で調和しやすくする必要があります。次に例を示します。
すべての(表領域)オブジェクト
ターゲット・バージョン間で、同じ列は同じラベルを使用する必要があります。これにより、メトリック列や短縮名などの列は、異なるターゲット・バージョンでも同じNLS IDを持ちます。
コレクションは、管理エージェントが定期的にターゲットのメトリックを計算し、管理リポジトリにデータをアップロードするメカニズムです。ターゲット・タイプのコレクションを作成する際に覚えておく必要のある最も重要なことは、余分なデータで管理リポジトリに過剰な負荷をかけないことです。何百もの管理エージェントと何千ものターゲットが存在する大規模なエンタープライズにおいて、スケーラビリティの鍵は、リポジトリにアップロードされたターゲットに関して収集されるデータの量を制限することです。RAWデータは24時間保持されるため、ロールアップの利点が生じるのはその時点を超えてからのみであることは特に重要です。
アラート・メッセージは、何か問題がある場合にユーザーに通知します。これらのメッセージは、ユーザーによる問題の解決も支援します。アラート・メッセージを作成する際には、次のコンテンツ・ガイドラインに従うことをお薦めします。
アラート・メッセージは意味のあるものにし、メトリック表示名、メトリック値、およびアラートを発生させるしきい値を含める必要があります。
メッセージの最も重要な部分は、メッセージ・テキストの最初の60文字以内でカバーする必要があります。その理由としては、メッセージの最初の部分は、電子メールによる通知、アラート・メッセージを含んだインシデント表などでは、ユーザーの目に最も見えるためです。
アラート・メッセージには、警告しきい値および重大なしきい値を含めます。
ターゲット停止メッセージでは、ターゲットが停止していることを示すのに加えて、ターゲットの停止について考えられる理由を示す情報を含める必要があります。
可能な場合は、エラー・コードおよびエラー・メッセージを含めます。
次はアラート・メッセージの良い例です。
CPU Load (Run Queue Length averaged over 15 minutes) is %value%, crossed warning (%warning_threshold%) or critical (%critical_threshold%) threshold.
問題の解決または診断の方法に関する情報は、アラート・メッセージに含める必要がないことに注意してください。かわりに、インシデント・マネージャの「ガイドされた解決」セクションに、この内容を指定する必要があります。詳細は、「ガイドされた解決」リージョンでの内容の指定に関する説明を参照してください。
メトリック収集の失敗を回避するために、メトリック評価順序に注意することが重要です。たとえば、ターゲットが停止している場合に収集の失敗を回避するためには、Responseメトリックを最初に評価する必要があります。また、メトリック収集エラーが一貫していることを確認します。たとえば、メトリックが収集されるたびに新しいメッセージが表示されるというようなことです。
収集の定義にCollectionItemタグが使用されている場合は、収集項目を含むすべてのメトリックが、管理エージェントにより順番に評価されます。ただし、収集項目はそれぞれ独立して実行されます。
注意:
管理エージェントのプログラム・ロジックは、メトリック評価を分散して、各評価が約10秒間隔になるようにします。
一般に、5分より短い間隔で情報を収集する適切な理由はほとんどありません。データ・バリエーションがより小さい粒度で発生し、管理者にできるだけ早く通知する必要があるというまれなケースでは、管理エージェントは、短い収集間隔を使用してメトリックおよびしきい値情報を計算する一方、データのアップロードをnn回の計算サイクルごとに1回のみ行う機能を用意しています。
ターゲット・メタデータをローカライズするには、次の項を参照してください。
ターゲット・メタデータはオプションでローカライズされた文字列(ターゲット・タイプの表示名、メトリックおよびメトリック列ラベル)をサポートし、各Enterprise Managerユーザーの言語とロケールでEnterprise Managerにラベルを表示できるようにします。この機能をサポートするには、ターゲット・メタデータ・ファイルがTargetMetadataタグにRESOURCE_BUNDLE_PACKAGEプロパティを含んでいる必要があります。RESOURCE_BUNDLE_PACKAGEプロパティは、ローカライズされたターゲット文字列を含むリソース・プロパティの場所を指定します。TargetMetadataタグの詳細は、「ターゲット・タイプ・メタデータ・ファイルの作成」を参照してください。
リソース・バンドル用に選択されたパッケージが後に続く3つの部分から構成されるプラグインIDを使用します。たとえば、プラグインIDがtest.group.domainの場合、リソース・バンドル・パッケージを次のように定義します。
RESOURCE_BUNDLE_PACKAGE=test.group.domain.rsc
前述の例では、rscがリソース・バンドル用に選択されたパッケージです。パッケージ名には、任意の英数字の文字列を使用できますが、特殊文字は使用できません。
リソース・プロパティ・ファイルに外部化できるターゲット・メタデータに含まれた文字列は、ターゲット・タイプ、メトリックおよび列項目に関連付けられたLabelタグです。
注意:
リソース・プロパティがロードできない場合、Labelタグは表示されるデフォルト値を持ち、NLSIDプロパティはユーザーのロケールにロードされる文字列リソースのロードに使用されるキーを指定します。
target_typeMsg.propertiesというリソース・プロパティ・ファイルに、ターゲット・メタデータに定義したすべての文字列を配置する必要があります。リソースのデプロイメント時に、対応するディレクトリにこのファイルを含めます。詳細は、「リソース・バンドルのパッケージ化」を参照してください。
次の例では、プラグインIDはtest.group.domainで、ターゲット・タイプはdomain_widgetです。
例: ターゲット・メタデータ・ローカリゼーション用のリソース・バンドル・パッケージの定義
<TargetMetadata META_VER="1.0" TYPE="domain_widget" RESOURCE_BUNDLE_PACKGE="test.group.domain.rsc"> <Display> <Label NLSID="dom_widget">Domain Widget</Label> </Display>
このプラグイン・デプロイメントの場合、test.group.domain.rsc.domain_widgetMsg.propertiesというリソース・プロパティ・ファイルを持つ必要があります。このファイルはターゲット・メタデータのすべての文字列を含んでおり、次のようになります。
# Strings for the domain_widget target type within the test.group.domain plug-in dom_widget = Domain Widget
デフォルトの収集メタデータ・ファイルでは、メトリック収集条件としてメッセージ・アラートとクリア・メッセージに次のプロパティを指定できます。
| NLSID | 説明 |
|---|---|
MESSAGE 条件が一致した場合の、デフォルト・メッセージ(英語)を指定します。 |
MESSAGE_NLS_ID ターゲット・タイプ・メタデータに関連付けられたリソース・プロパティ・ファイル内の変換済バージョンのメッセージの検索に使用されるリソース識別子を指定します。 |
CLEAR_MESSAGE アラート条件が存在しなくなった場合に送信されるクリア・メッセージを指定します。 |
CLEAR_MESSAGE_NLS_ID ターゲット・タイプ・メタデータに関連付けられたリソース・プロパティ・ファイル内の変換済バージョンのクリア・メッセージの検索に使用されるリソース識別子を指定します。 |
次の例は、アラート・メッセージおよびクリア・メッセージのリソース識別子を含むメトリック定義の例を示しています。
例: ローカリゼーション・プロパティを含むメトリックの定義
<MetricColl NAME="CPUPerf">
<Condition COLUMN_NAME="non_nice" WARNING="NotDefined" CRITICAL="NotDefined"
OPERATOR="GE"
MESSAGE="The value for %columnName% is %value%%%. It has risen above the critical (%critical_threshold%%%) or warning (%warning_threshold%%%) threshold."
MESSAGE_NLS_ID="dhs_non_nice_cond_msg"
CLEAR_MESSAGE="The value for %columnName% is %value%%%. It has fallen below the critical (%critical_threshold%%%) or warning (%warning_threshold%%%) threshold."
CLEAR_MESSAGE_NLS_ID="dhs_non_nice_clear_msg" />
リソース・バンドルをパッケージ化する前に、「リソース・プロパティ・バンドルのコンテンツについて」を確認し、パッケージのコンテンツが正しくフォーマットされていることを確認します。
これらすべてのリソース・プロパティ・ファイルは、適切なJavaリソース・プロパティ・バンドルとしてフォーマットされる必要があります。ファイル名に次のJava仕様に応じて、適切な国およびロケールを含めます。
http://docs.oracle.com/javase/7/docs/api/java/util/PropertyResourceBundle.html
文字エンコーディングはターゲット・メタデータ、ジョブなどに使用されるリソース・プロパティ・バンドルのJava言語仕様に従って文字エンコーディングする必要があります。
Flexリソース・プロパティ・ファイルのエンコーディングは、Java言語仕様とは異なります。このため、Flex UI (MPCUI)に表示されるすべての文字列リソースを個別のリソース・プロパティ・バンドルに分ける必要があります。詳細は、次の場所からFlexドキュメントを参照してください。
http://www.adobe.com/support/documentation/en/flex/1/internationalization_flex_short/internationalization_flex_short9.html
リソース・バンドルをパッケージ化するには、次の手順を実行します。
注意:
リソース・プロパティ・バンドルの例については、次のJavaチュートリアルのページを参照してください。
http://docs.oracle.com/javase/tutorial/i18n/resbundle/propfile.html
新しいターゲット・タイプを登録する前に、次のリストをチェックします。
ターゲット・タイプ名
ターゲット・タイプ名が次のネーミング形式に従っていることを確認します。pluginはプラグイン名を表し、typeはターゲット・タイプ名を表します。
oracle_plugin_type
たとえば、oracle_vt_zoneやoracle_emas_forms_serverなどです。
モデル
ターゲットが管理可能なエンティティであること、または監視できることを確認します。また、ターゲット・タイプのモデル化はビジネス上の意味があることを確認します。
ターゲット・タイプにはレスポンス・メトリックおよび他の数量化可能な数値メトリックを備えてください。
ターゲット・タイプは必要なターゲットであり、Enterprise Managerがインストールされていなくても識別可能な存在であることを確認します。
ターゲット・タイプが属する管理可能なエンティティ・クラスを特定し、プロパティを正しく設定します。
Responseメトリックには、Statusと呼ばれる数値メトリック列が1つのみあることを確認します。
バージョン
メタデータ・バージョンは正しく定義してください。メタデータ・バージョン番号の詳細は、ターゲット・タイプ・メタデータの定義に関する説明を参照してください。
アソシエーション
抽象的なアソシエーション・タイプは使用しないでください。次に例を示します。
select assoc_type from mgmt_assoc_types where is_abstract=1
コア・アソシエーション・タイプを使用してください。次に例を示します。
select assoc_type from mgmt_assoc_types where category=1
provided_by/relies_on_key_componentの許容ペアを定義しないでください。Serviceフレームワークはサービスを自動的に追加します(provided_by/relies_on_key_componentの許容ペア)。
プロパティ
ユーザー名やパスワードなどの資格証明をターゲット・プロパティに格納しないでください。
ターゲットのみの監視に使用するプロパティをターゲット・プロパティに含めます。データが管理エージェントによって活発に使用されていない場合、このデータはターゲット・プロパティではありません。
ターゲット・バージョン・プロパティを追加してターゲット・バージョンを取得します。デフォルトではEnterprise Managerは、TargetVersionプロパティを使用してターゲット・バージョンを表します。このプロパティの詳細は、表3-2を参照してください。
メトリック・ブラウザを使用して、新しいターゲット・タイプ定義をテストします。メトリック・ブラウザは、管理エージェントの重要部分である開発ユーティリティです。管理エージェントのサブシステムとして、Enterprise Managerフレームワークの管理リポジトリまたはその他のコンポーネントのオーバーヘッドを発生させることなく、管理エージェントにより監視されるターゲットのメトリック値への迅速なアクセスを可能にします。
Enterprise Manager Cloud Controlコンソールを使用せずにメトリックをデバッグするように管理エージェントのメトリック・ブラウザを構成するには、次のようにします。
または、emctlコマンドを使用し、次のようにしてメトリック・ブラウザをアクティブ化することも可能です。
emctl setproperty agent -name _enableMetricBrowser -value true
ターゲット・インスタンスがtargets.xmlファイルに追加され、新しい情報がリロードされた後で、使用可能なターゲットおよびメトリックをメトリック・ブラウザで表示できます。任意のWebブラウザを使用して、次のURLにアクセスします。
http://host:port/emd/browser/main
ヒント:
管理エージェントで使用されるポート番号を調べるには、$AGENT_HOME/sysman/config/emd.propertiesファイルを開き、EMD_URL行を検索します。
注意:
メトリック・ブラウザにログインするには、管理エージェントのオペレーティング・システム資格証明を使用する必要があります。
ターゲット・メタデータ・ファイルが正しく定義されていることを検証するには、EDKのbinディレクトリから次のコマンドを入力します。
empdk validate_plugin -stage_dir plugin_stage
前述のコマンドのplugin_stageは、プラグインのステージング・ディレクトリを示します。
EDKの詳細は、「拡張開発キット(EDK)」を参照してください。empdkコマンドおよびその使用方法の詳細は、「プラグインの検証」を参照してください。
この項では、ターゲットで問題が発生した場合のトラブルシューティングのヒントを説明します。
ターゲットがEnterprise Managerに追加されない
ターゲットが追加されていない場合は、次を実行します。
Oracle Management Serviceのトレース・ファイル(emoms.trc)に例外があるかどうかを確認します。OMSのトレース・ファイルは、EM_INSTANCE_BASE/em/OMS_NAME/sysman/log/ディレクトリにあります。ここで、EM_INSTANCE_BASEは、OMSインスタンス・ベース・ディレクトリです(このディレクトリは、デフォルトで、Oracleミドルウェア・ホームの親ディレクトリの下位に存在します)。
grep –i EntityManager.createEntities * grep –i EntityUtil *
ターゲットが管理リポジトリには追加されているが、管理エージェントには追加されていない場合は、agentStateDir/sysman/logディレクトリに移動し、管理エージェントのログ・ファイル(gcagent_mdu.log)を確認してください。このログ・ファイルは、管理エージェントに対するメタデータの更新を追跡します。
ターゲットのステータスが保留中のままになる
ターゲットが管理エージェントの監視対象で、ステータスが保留中のままである場合は、次を実行します。
管理エージェントが現在もターゲットを監視しているかどうかを確認します。
管理エージェントで監視されている、各ターゲットの名前およびタイプをリストする手順は、次のとおりです。
ディレクトリを、AGENT_HOME/binディレクトリ(UNIX)またはAGENT_HOME\binディレクトリ(Windows)に変更します。
次のコマンドを入力します。
emctl config agent listtargets
ターゲットの出力を確認します。
次のログ・ファイルを確認して、管理エージェントにプラグインがデプロイされていることをチェックします。
agent_inst/sysman/registry.xml
管理エージェントが、ターゲット追加のリクエストを受信したことを確認します。agentStateDir/sysman/logディレクトリに移動し、管理エージェントのログ・ファイル(gcagent_mdu.log)を確認してください。
SQL*Plusセッションから、次のようなtgtinfo.sqlスクリプトを実行します。
@tgtinfo oracle_database orcl
tgtinfo.sqlスクリプトには、次が含まれます。
SELECT type_meta_ver, ':'||category_prop_1||':'||
category_prop_2||':'||
category_prop_3||':'||
category_prop_4||':'||
category_prop_5||':' category_prop,
target_guid,
TO_CHAR(load_timestamp,'DD_MON-YY HH24:MI:SS'),
timezone_region,owner,host_name,emd_url,broken_reason,broken_str,manage_status,
promote_status,
dynamic_property_status
FROM sysman.em_targets
WHERE target_type='&&1'
AND target_name='&&2'
/
注意:
スクリプトの実行に問題がある場合は、スクリプトを編集して&&1をターゲット・タイプで置換し、&&2をターゲット名で置換します。
スクリプトの出力には、次の情報が含まれます。
TARGET_TYPE
oracle_databaseなど、ターゲットの名前です。
TYPE_META_VER
メタデータのバージョン番号です。ターゲットに対するメタデータのバージョンが正しいことを確認してください。
CATEGORY_PROP_1
カテゴリ・プロパティを使用することで、異なる構成に基づいて様々なメトリック定義を区別できます。ターゲットに対する値が正しいことを確認してください。
BROKEN_REASON
この値が0より大きい場合はターゲットが破損(ターゲットを保存できない、または必須プロパティが不足しているなど)しています。BROKEN_STR値は、ターゲットが破損した理由を示します。
MANAGE_STATUS
ターゲットの管理ステータスです。使用可能な値は次のとおりです。
0: 無視されます
1: まだ管理されていません
2: 管理対象です
3: 管理対象のターゲット・コンポーネントです
PROMOTE_STATUS
ターゲットの昇格ステータスです。使用可能な値は次のとおりです。
0: (存在のみのエンティティは)昇格できません。
1: 昇格可能です
2: 昇格が進行中です
3: 管理エージェントに昇格されました。
4: 昇格が進行中ですが、ターゲットは以前、管理エージェントに追加されています。
DYNAMIC_PROPERTY_STATUS
動的プロパティのステータスです。使用可能な値は次のとおりです。
0: 動的プロパティが管理エージェントによってアップロードされていません。
1: 動的プロパティが管理エージェントによってアップロードされています。
