| Oracle Enterprise Manager SNMPサポート・リファレンス・ガイド 10gリリース2（10.2） E05922-01 |
|
 戻る |
 次へ |
この章では、Oracle SNMPサポートの概要について説明します。内容は、次のとおりです。
Simple Network Management Protocol（SNMP）は、ネットワークの管理に使用するプロトコルです。SNMPを使用すると、1つのアプリケーションで情報を取り出した後、基礎となるハードウェアに関わりなく、広範なシステム間に新しい情報をプッシュできます。
Oracle SNMPサポートは、主にデータベース、ネットワークおよびシステムの各管理者向けに設計されており、Oracle製品の管理を、普及している既存の各種管理システムに統合します。この機能によって、中央のノードで稼働中の管理ステーションから、企業のネットワーク上の任意の場所で稼働している主要なOracle製品を検索、識別および監視できます。このための方法とツールは、これまでネットワーク自体のアクティビティの監視に使用していたものとほぼ同じです。この結果、データベース管理者とネットワーク管理者の作業が統合され、両者が同じツールを使用し、それぞれの作業を効率的に統合できます。従来より、SNMPを使用したツールには、ネットワーク・コンポーネントを監視するための強力な機能があります。Oracleはこの機能を拡張し、一部のOracle製品のSNMPによる監視を可能にしています。
Oracle SNMPサポートの主な利点は、次のとおりです。
主要なOracle製品の監視機能を、SNMPに基づいた任意の管理フレームワークに迅速に統合します。
これらのOracle製品を、任意の規模の企業ネットワーク全体でリアルタイムに検索、識別および監視します。
管理者は、ネットワーク・マップでOracle製品を表す標準のOracleアイコンを参照できます。このマップは、動的にカスタマイズできます。実際に、管理者は目的に応じて様々なネットワーク・マップを定義およびカスタマイズできます。
管理者は、Oracle製品の現在のステータスを、管理情報ベース（MIB）で製品ごとに定義されている数種類のステータス変数で参照したり、それらのステータスごとに表示する要素を選択できます。
管理者は、しきい値とアラートを定義することによって、例外的な条件の発生を予測し、特別な状況に発生と同時に対応したり、自動的に対応できます。
管理者は、データベースのサイズ、ユーザー数、アクティビティ・レベルなどのOracleオブジェクトの主要な特性を簡単に判別できます。
管理者は、SNMPを通じて取得した履歴データを保存し、分析できます。
SNMPはオープンな標準であるため、管理アプリケーションのプロバイダは、Oracleユーザー向けにカスタマイズしたソリューションを容易に構築できます。
厳密に言えば、Oracle SNMPサポートの目的は、Oracle製品の管理よりも、監視に重点が置かれています。Oracle SNMPサポートは、Oracle Applicationsのネットワーク全体のステータスを追跡するのに非常に役立ちます。最初は通常の操作を確認し、潜在する問題が検出されると、ただちにその問題を見つけて対応します。ただし、問題によっては、Oracle SQL *Plus Worksheetなどの他のOracleツール製品の方が、調査と解決に適している場合もあります。これは、他のツール製品がシステム・パラメータを設定または調整するように設計されているのに対して、Oracle SNMPサポートは、システム・パラメータの変更ではなく、ステータスを問い合せるように設計されているためです。
|
注意: Oracle SNMPは、HP OpenVMSプラットフォームではサポートされていません。 |
SNMPは、ネットワーク内の特定のノード、つまり、管理ステーションや管理ノードから、他のネットワーク・コンポーネントやアプリケーションに対して、ステータスとアクティビティに関する情報を問合せできるようにする標準のインターネット・プロトコルです。このような問合せは、SNMPポーリングと呼ばれます。ポーリングされる側は、管理対象の要素と呼ばれます。管理対象の要素は、ブリッジ、ルータ、データベースなどのネットワーク・コンポーネントです。
管理ステーションで使用されるソフトウェアは、管理フレームワークまたは管理プラットフォームと呼ばれます。管理フレームワークが、SNMPプロトコルを使用して管理対象ノード上のエージェントに情報を要求すると、これらのエージェントは適切な応答を返信します。エージェントからは、フレームワークとは関係なく、特定のイベントに応じてトラップと呼ばれるメッセージを、予約済のアドレスに送信することもできます。これは、トラップによって示される特定の条件に、迅速かつできるかぎり自動的に対応できるようにするための機能です。
特定のネットワーク・ノードに送信されたすべての要求は、同じマスター・エージェントによって処理されます。このエージェントでは、場合によってはサブエージェントを使用して、ノード上の適切な管理対象の要素に要求をリダイレクトします。これに使用されるプロトコルはまだ標準化されておらず、またSNMPではありません。SNMPで取得できる情報は、管理対象の要素のノード上にある管理情報ベース（MIB）と呼ばれる構造体に記述されています。
図1-1に、管理ステーションと管理対象ノード（サンプル）のコンポーネントを示します。
図1-1のコンポーネントについては、後続の各項で説明します。
管理ステーションとは、SNMPプロトコルを使用して管理対象の要素を監視するノードのことです。これは通常、管理対象の要素と同じネットワーク上にあるスタンドアロン・ワークステーションです。このマニュアルでは一貫して管理ステーションという用語を使用しますが、この他に管理コンソール、管理システムまたは管理ノードという用語も使用されます。
管理ステーションにOracle SNMPサポートを実装するには、次のコンポーネントが必要です。
管理プラットフォームまたは管理フレームワーク。少なくとも1つの汎用管理アプリケーションが必要です。
レポート、表示またはアカウント管理のために、システム・アクティビティに関する履歴データを格納するリポジトリ。一部のフレームワークでは、Oracleデータベースがリポジトリとして提供されますが、それ以外の場合はリポジトリの形式が設定されます。
サード・パーティの専門化された各種管理アプリケーション。これらの管理アプリケーションはオプションのアドイン・コンポーネントで、多くの場合、フレームワークと統合され、特定のデバイスやアプリケーションの詳細な管理を可能にします。
|
注意: これらのコンポーネントは、Oracle SNMPサポートには含まれません。 |
管理ステーションにある管理フレームワークは、SNMPを使用して、他のノードに管理情報を要求します。フレームワークによって、そのSNMPデータが収集およびグラフ表示され、場合によってはそのデータに基づいた処理が行われ、履歴の分析とレポート用に、そのデータの一部またはすべてがリポジトリに保存されます。管理フレームワークには、多数のツールとオプションがあります。管理対象ノードに情報を直接要求する機能に加え、フレームワークでは通常、一連の特定条件に応じて1つの管理対象ノードからトラップが送信されると、デーモンを使用して管理対象ノードにアラートが出されます。このトラップは、管理アプリケーションの起動にも使用できます。
|
注意: Oracleでは、管理フレームワークは提供されません。 |
ほとんどのフレームワークでは、通信の基礎としてSNMPが使用されるため、SNMPをサポートするOracle製品は事実上すべての管理フレームワークに統合できます。このようなフレームワークの例には、CA Unicenter、HP OpenView、Tivoli NetView、Aprisma Spectrum、Sun Solstice、Castle Rock SNMPc Network Managerなどがあります。
今日のほとんどの管理フレームワークには、次のようなグラフィカル・オブジェクトも用意されています。これらのグラフィカル・オブジェクトを管理アプリケーションで使用することで、次のような特別なニーズを満たすGUIを構築できます。
論理または物理ネットワーク・トポロジを表すマップ
個々のネットワーク・コンポーネントを表すアイコン
管理情報変数を効率的に監視するための文字盤、棒グラフ、折れ線グラフなどのグラフ作成ツール
管理アプリケーションは、専門化されたネットワークまたはデータベース作業を行うために、管理フレームワークと統合されたツールです。これらのアプリケーションには、事実上、ネットワーク管理に関連する高度な論理がすべて含まれています。
カスタマイズされた管理アプリケーションは、（異なる管理ステーション上の）1つ以上のフレームワークとともに使用したり、独立して実行することができます。Oracle SNMPサポートには、どのようなタイプのプロバイダも等しくアクセスできるため、アプリケーションでは様々な方法で利用できます。
基本的な管理アプリケーションは、多くの場合、管理フレームワークにデフォルトで付属しています。この基本的な管理アプリケーションでは、ネットワーク・トポロジを検出し、検出した各ネットワーク・エンティティまたはサービスに関する基本的な識別情報の一部を収集できます。たとえば、サブネット内のすべてのホストを、そのベンダー、場所およびステータスとともに検出できます。管理アプリケーションでは、後でこの情報を使用して環境の論理マップを構築できます。
マスター・エージェントは管理対象ノード上のプロセスです。このプロセスでは、管理フレームワークからの問合せ（「ポーリング」とも言います）を受け入れ、その問合せに応答するために管理対象の要素と通信します。マスター・エージェントは、特定の条件に応じて、SNMPトラップを個別に送信することもできます。各管理対象ノードに配置できるマスター・エージェントは1つのみです。マスター・エージェントが存在しないノードでは、SNMP要求に応答できませんが、ネットワーク上の他のノードによる応答が妨げられることはありません。つまり、通常はネットワーク上のすべてのノードがSNMPに応答できるのが望ましい状態ですが、必ずしもこのような状態である必要はありません。
マスター・エージェントは、モノリシックでも拡張可能でもかまいません。モノリシックの場合、マスター・エージェントは、管理対象の要素と直接通信します。このような管理エージェントでは同一ノード上の複数の要素を管理できますが、管理できる一連の要素は管理エージェントの作成時に固定化されます。これは、モノリシック・エージェント自体が管理対象の要素とのインタフェースの役割を果たすためです。
これに対し、拡張可能なマスター・エージェントの場合は、管理する必要がある要素ごとに特定のサブエージェントが使用されます。このサブエージェントは、その要素とのインタフェースの役割を果たします。この場合、マスター・エージェントには新規のサブエージェントをいつでも登録できるため、新しい管理対象の要素を動的に追加できます。
一部のオペレーティング・システムでは、モノリシック・エージェントのみ提供されます。この場合、Oracleでは、そのモノリシック・マスター・エージェントをサブエージェントとして効率的に処理できるマスター・エージェントを提供し、新しい管理対象の要素をノードに動的に追加できるようにします。
サブエージェントは、特定の管理対象の要素に対する問合せをマスター・エージェントから受け取り、適切な応答をマスター・エージェントに返信するプロセスです。管理対象ノード上の管理対象要素ごとに1つのサブエージェントが存在します（1つのサブエージェントで、同一ノード上の複数のOracleデータベース・インスタンスを処理できる場合を除く）。サブエージェント（複数可）とマスター・エージェントは、マスター・エージェントが指定した多重化プロトコルを使用して通信します。この接続に対する標準のプロトコルはありません。普及しているプロトコルはいくつかありますが、標準として指定されているプロトコルはありません。
SNMPは、フレームワークと管理対象ノード間のコネクションレス通信に基づいています。ほとんどの管理情報に、信頼性の高い配信は要求されないため、SNMPパケットはあるノードから別のノードの予約済のアドレスに送信されますが、無事に届いたかどうかは確認されません。軽量なコネクションレスSNMP通信の後処理は、管理アプリケーションによって行われます。つまり、管理アプリケーションでは、SNMPトランザクションが適切な時間内に正常に完了したことを確認する必要があります。SNMPパケットがネットワーク内で失われた場合、管理アプリケーションでは、関連のトランザクションを取り消し、たいていの場合は再実行します。
SNMPの最も一般的な実装には、インターネット・プロトコル（IP）でのユーザー・データグラム・プロトコル（UDP）を使用しますが、Novell社のInternetwork Packet Exchange（IPX）やApple社のAppleTalkなどの他のプロトコルによる実装もあります。
Enterprise ManagerのWebベースのアーキテクチャでは、全体的にスケーラブルでデプロイが容易な監視および管理フレームワークが提供されます。SNMPによって、Enterprise Managerの監視機能は、管理対象の環境内のSNMP対応エンティティまで拡張されます。Enterprise Managerの機能とアーキテクチャの詳細は、『Oracle Enterprise Manager概要』を参照してください。
Enterprise Managerの通知システムを使用すると、HP OpenViewなど、SNMP対応のサード・パーティのアプリケーションを利用できます。たとえば、特定のメトリックがしきい値を超えた場合は、サード・パーティのアプリケーションにEnterprise Managerから通知を送信できます。通知システムではSNMPトラップの使用は容易で、SNMPトラップを使用する通知メソッドを定義するのみです。SNMPトラップを使用した通知メソッドの設定については、次の章で説明します。
fetchletはパラメータ化されたデータ・アクセス・メカニズムで、管理対象の要素の関連データをEnterprise Managerのメトリック形式にマップするために利用できます。標準の領域にあるEnterprise Managerは現在、SNMP fetchletを使用して、管理対象の環境内のSNMP対応エンティティから情報をフェッチしています。
SNMP fetchletメカニズムは、metadata.xml構成ファイルの「query descriptor」セクションに定義されています。例1-1に、metadata.xml構成ファイルのサンプルを示します。このファイルには、メトリック情報を収集するために定義されたSNMP fetchletが含まれています。
例1-1 metadata.xml構成ファイルで使用されるSNMP fetchlet
<Metric NAME="Load" TYPE="TABLE">
<Display>
<Label NLSID="cisco_router_load">Load</Label>
</Display>
<TableDescriptor>
<ColumnDescriptor NAME="busyPer" TYPE="NUMBER" IS_KEY="FALSE">
<Display>
<Label NLSID="cisco_router_load_busyPer">CPU Busy in the last 5 seconds
(%)</Label>
</Display>
</ColumnDescriptor>
<ColumnDescriptor NAME="avgBusy1" TYPE="NUMBER" IS_KEY="FALSE">
<Display>
<Label NLSID="cisco_router_load_avgBusy1">CPU Busy in the last
minute(%)</Label>
</Display>
</ColumnDescriptor>
<ColumnDescriptor NAME="avgBusy5" TYPE="NUMBER" IS_KEY="FALSE">
<Display>
<Label NLSID="cisco_router_load_avgBusy5">CPU Busy in last 5 minutes
(%)</Label>
</Display>
</ColumnDescriptor>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="Snmp">
<Property NAME="NAME" SCOPE="INSTANCE">NAME</Property>
<Property NAME="hostname" SCOPE="INSTANCE">agentHost</Property>
<Property NAME="TABLE" SCOPE="GLOBAL">FALSE</Property>
<Property NAME="OIDS" SCOPE="GLOBAL">1.3.6.1.4.1.9.2.1.56.0
1.3.6.1.4.1.9.2.1.57.0
1.3.6.1.4.1.9.2.1.58.0
</Property>
</QueryDescriptor>
</Metric>
Enterprise Manager 10g Grid Controlリリース2以下（10.2.0.2または10.2.0.1）の場合、サード・パーティのSNMPエージェントから収集できるのは整数値と文字列値のみです。これは、SNMPバージョンv1のみがfetchletでサポートされるためです。そのため、SNMP v1を使用してサード・パーティのSNMPエージェントから収集された整数値は32ビットで適応されます。
Enterprise Manager 10g Grid Controlリリース3以降では、使用するmetadata.xmlファイルでcounter64データ型オブジェクトを使用して、32ビットの整数値と文字列値のみでなく、64ビットの整数値も収集できます。
このため、SNMPエージェントは主に次の2つのカテゴリに大きく分類できます。
SNMP v1の問合せにのみ応答するSNMP v1エージェント
SNMP v1およびv2の問合せに応答するSNMP v2エージェント
このようなcounter64の値を収集するには、VERSIONと呼ばれるquery descriptorのプロパティをmetadata.xmlファイルに追加する必要があります。このプロパティを追加することで、fetchletは適切なバージョンのSNMPでリクエストを行い、SNMPターゲットからデータをフェッチします。
たとえば、fetchletでサード・パーティのSNMPターゲットからifHCInOctets（64ビットの値）属性を収集する必要がある場合、metadata.xmlファイルのquery descriptor定義は次のようになります。
<QueryDescriptor FETCHLET_ID="Snmp">
<Property NAME="NAME" SCOPE="INSTANCE">NAME</Property>
<Property NAME="hostname" SCOPE="INSTANCE">NAME</Property>
<Property NAME="COMMUNITY" SCOPE="INSTANCE"
OPTIONAL="TRUE">CommunityString</Property>
<Property NAME="VERSION" SCOPE="GLOBAL">V2c</Property>
<Property NAME="OIDS" SCOPE="GLOBAL">1.3.6.1.2.1.31.1.1.1.6 </Property>
</QueryDescriptor>
VERSIONプロパティの値をV1に設定するか、またはquery descriptorにVERSIONプロパティを記述しない場合、fetchletはSNMP v1の問合せのみを行い、メトリックの値を収集します。つまり、32ビットの整数値および文字列値のみが収集されます。
これに対し、SNMP v1エージェントとSNMP v2エージェントの両方から、それぞれいくつかのメトリック列をfetchletで収集する必要が生じることもあるでしょう。その場合は、メトリック定義内で、SNMPターゲットの各バージョンに応じた処理をするためのValidIfタグを使用します。つまり、SNMPバージョンが!= v1の場合はcounter64データ型のプロパティをメトリック定義に含め、そうでない場合はこのプロパティを無視するように指定します。このとき、SNMPターゲットのバージョンは動的プロパティを使用して識別させることができます。
たとえば、SNMP v1エージェントのスイッチ・デバイスからは1.3.6.1.2.1.31.1.1.1.5（Integer型）を収集し、SNMP v2エージェントのスイッチからは1.3.6.1.2.1.31.1.1.1.5（Integer型）および1.3.6.1.2.1.31.1.1.1.6（Counter64型）を収集する必要がある場合、メトリックの定義は次のようになります。
<Metric NAME="Table" TYPE="TABLE">
<ValidIf>
<CategoryProp NAME="SnmpAgentVerision" CHOICES="V1"/>
</ValidIf>
<Display>
<Label NLSID="SwithIfTable">SwitchInterface</Label>
</Display>
<TableDescriptor>
<ColumnDescriptor NAME="Column1" TYPE="NUMBER">
<Display>
<Label NLSID="Column1">Column1 Value</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="TABLE" SCOPE="GLOBAL">TRUE</Property>
<Property NAME="VERSION" SCOPE="GLOBAL">V1</Property>
<Property NAME="OIDS" SCOPE="GLOBAL"> 1.3.6.1.2.1.31.1.1.1.5 </Property>
</QueryDescriptor>
</Metric>
<Metric NAME="Table" TYPE="TABLE">
<ValidIf>
<CategoryProp NAME="SnmpAgentVerision" CHOICES="V2"/>
</ValidIf>
<Display>
<Label NLSID="SwithIfTable">SwitchInterface</Label>
</Display>
<TableDescriptor>
<ColumnDescriptor NAME="Column1" TYPE="NUMBER">
<Display>
<Label NLSID="Column1">Column1 Value</Label>
</Display>
</ColumnDescriptor>
<ColumnDescriptor NAME="Column2" TYPE="NUMBER">
<Display>
<Label NLSID="Column2">Column2 Value</Label>
</Display>
</ColumnDescriptor>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="Snmp">
<Property NAME="NAME" SCOPE="INSTANCE">NAME</Property>
<Property NAME="hostname" SCOPE="INSTANCE">NAME</Property>
<Property NAME="COMMUNITY" SCOPE="INSTANCE"
OPTIONAL="TRUE">CommunityString</Property>
<Property NAME="TABLE" SCOPE="GLOBAL">TRUE</Property>
<Property NAME="VERSION" SCOPE="GLOBAL">V2c</Property>
<Property NAME="OIDS" SCOPE="GLOBAL"> 1.3.6.1.2.1.31.1.1.1.5
1.3.6.1.2.1.31.1.1.1.6
</Property>
</QueryDescriptor>
</Metric>
この場合、SnmpAgentVersionは、次の動的プロパティ定義を使用して計算されています。
<DynamicProperties NAME="SnmpVersionConfig" FORMAT="ROW" OPT_PROP_LIST="SnmpVersionIdentifier> <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="VERSION" SCOPE="GLOBAL">V1</Property> <Property NAME="OIDS" SCOPE="GLOBAL"></Property> 1.3.6.1.6.3.1.1.6.1.0 </QueryDescriptor></DynamicProperties> <DynamicProperties NAME="SnmpVersionValues" FORMAT="ROW" PROP_LIST="SnmpAgentVersion"> <QueryDescriptor FETCHLET_ID="VersionRangeComputer"> <Property NAME="Version" SCOPE="INSTANCE" OPTIONAL="TRUE">SnmpVersionIdentifier</Property> <Property NAME="DefaultRange" SCOPE="GLOBAL">V1</Property> <Property NAME="V2" SCOPE="GLOBAL">0;</Property> </QueryDescriptor> </DynamicProperties>
この例ではまず、SnmpVersionIdentifierが、SNMP v2 MIBの標準OIDである1.3.6.1.6.3.1.1.6.1.0に基づいて計算されます。バイリンガルの標準エージェントは、すべてこのOIDを実装している必要があります。
そのため、このOIDに対応する値をV1の要求を介して収集しようとした場合、エージェントがSNMP v2エージェントであれば整数値（範囲は0〜2147483647）が取得されます。しかし、エージェントがSNMP v1エージェントだと、この要求に対してnosuchnameエラーが返されます。
最後に、解釈可能な形式のSnmpAgentVersion値（v1またはv2）が、SnmpVersionIdentifierの値に基づき、VersionRangeComputer fetchletを使用して計算されています。
|
注意: この例では、SnmpAgentVersionの検出に、他の任意のアプリケーションの固有OID（1.3.6.1.6.3.1.1.6.1.0以外のOID）を指定することもできます。ただし、ターゲットのSNMPエージェントに特定のOIDが実装されていて、かつそのOIDによってSNMPエージェントのv1とv2を区別できることが条件となります。 |
|
注意: fetchletの詳細は、次のサイトから入手可能な『Oracle Enterprise Manager拡張ガイド』を参照してください。 |
管理対象の環境でサード・パーティのエンティティを監視している間に、サード・パーティ・ネットワーク要素のステータスが使用不可になった場合、あるいはそのメトリック重大度条件（メトリックしきい値）が一致したか、超えた場合は、そのサード・パーティ・ネットワーク要素のSNMPエージェントによって、通知がOracle Management Agentに送信されます。これらの通知は、SNMPトラップの形式の場合があります。この形式は、パフォーマンスしきい値への到達時に、Oracle Management Agentからの要求なしに非同期でトリガーされます。
これらのトラップはSNMPに基づいているため、Oracle Management Agentは、SNMP receiveletを使用して、これらのSNMPトラップを受信し、Oracle Management Serviceと互換性のある形式に変換します。
SNMPトラップを受信した後、SNMP receiveletは、metadata.xml構成ファイルの「push descriptor」セクションに定義されているオブジェクトID（OID）に関連する情報のみ（Enterprise Managerによる監視が必要なサード・パーティ・ネットワーク要素に関する情報のみ）を抽出します。例1-2に、metadata.xml構成ファイルでのSNMP receiveletの定義方法を示します。
例1-2 metadata.xml構成ファイルで定義されるSNMP receivelet
<Metric NAME="Load" TYPE="TABLE">
<Display>
<Label NLSID="cisco_router_load">Load</Label>
</Display>
<TableDescriptor>
<ColumnDescriptor NAME="busyPer" TYPE="NUMBER" IS_KEY="FALSE">
<Display>
<Label NLSID="cisco_router_load_busyPer">CPU Busy in the last 5 seconds (%)</Label>
</Display>
</ColumnDescriptor>
<ColumnDescriptor NAME="avgBusy1" TYPE="NUMBER" IS_KEY="FALSE">
<Display>
<Label NLSID="cisco_router_load_avgBusy1">CPU Busy in the last minute(%)</Label>
</Display>
</ColumnDescriptor>
<ColumnDescriptor NAME="avgBusy5" TYPE="NUMBER" IS_KEY="FALSE">
<Display>
<Label NLSID="cisco_router_load_avgBusy5">CPU Busy in last 5 minutes (%)</Label>
</Display>
</ColumnDescriptor>
</TableDescriptor>
<PushDescriptor RECVLET_ID="SNMPTrap">
<Property NAME="MatchEnterprise" SCOPE="GLOBAL">1.3.6.1.4.1.529</Property>
<Property NAME="MatchGenericTrap" SCOPE="GLOBAL">6</Property>
<Property NAME="MatchSpecificTrap" SCOPE="GLOBAL">50</Property>
<Property NAME="MatchAgentAddr" SCOPE="INSTANCE">AdminAddress</Property>
<Property NAME="EventbusyPerOID" SCOPE="GLOBAL">1.3.6.1.4.1.9.2.1.56.0</Property>
<Property NAME="SeverityCode" SCOPE="GLOBAL">CRITICAL</Property>
</PushDescriptor>
</Metric>
しきい値への到達時にSNMPエージェントがSNMPトラップを送信すると、SNMP receiveletは、そのSNMPエージェントの構成に基づいてこれらのトラップを受信し、Enterprise Managerで理解できる形式（push descriptor情報に基づいたイベントやデータ・ポイントなど）に変換して、その情報をアップロード・ディレクトリに（XMLファイルで）格納します。Upload Managerは、アップロード・ディレクトリ内の新規ファイルをチェックし、これらのファイルをOracle Management Serviceにアップロードします。次に、Enterprise ManagerはOracle Management Serviceにアクセスし、収集された情報を抽出して、ユーザーに表示します。
|
注意: receiveletの詳細は、次のサイトから入手可能な『Oracle Enterprise Manager拡張ガイド』を参照してください。 |
Enterprise Manager 9.x以前のリリースでは、Enterprise Manager SNMP Subagentの機能はOracle Management Agent（以前はIntelligent Agentと呼ばれていました）と統合されていました。Enterprise Managerリリース10.xでは、SNMPサブエージェントの機能は、Oracle Management Agentとともにインストールされる、独立した実行可能ファイルになっています。Enterprise Manager SNMP Subagentは、SNMP要求をリスニングし、データベースに問い合せてサブエージェントから結果を取得します。
管理アプリケーションは、サポートされているプラットフォームでSNMPプロトコルを使用し、Enterprise Manager SNMP Subagentと直接通信できます。Enterprise Manager SNMP Subagentは、Oracleのデータベース管理情報ベース（MIB）変数へのアクセスを提供します。
Oracle SNMPサポートは、次の製品に提供されています。
Oracle Database Server
Oracle Network Listener Server
Oracle Enterprise Manager
Oracle Management AgentとEnterprise Manager SNMP Subagentは別々のプロセスであるため、Enterprise Manager SNMP SubagentはSNMPトラップを送信できません。したがって、9.x以前のIntelligent Agentのバージョンでは可能であった、アラートとSNMPトラップの送信の関連付けはできません。ただし、Enterprise Manager SNMP Subagentは、データベース停止時に標準のRDBMSトラップを送信します。
SNMPを使用すると、Enterprise Managerではサード・パーティのSNMP対応アプリケーションに情報を送信できますが、SNMP対応アプリケーションでEnterprise Managerから情報を取得する必要がある場合があります。これを実施するには、MIB変数を利用し、SNMPトラップの登録を行います。
|
重要: Enterprise ManagerのMIB変数を使用するには、有効なDiagnostic Packのライセンスが必要です。 |
MIBはASN.1表記法で記述されたテキスト・ファイルで、SNMPでアクセスできる情報を含む変数が記述されています。MIB内に記述されている変数は、MIBオブジェクトとも呼ばれ、SNMPを使用して監視できます。監視する要素ごとに1つのMIBがあります。各モノリシック・エージェントまたはサブエージェントは、取出し可能な変数とその特性を識別するために、それぞれのMIBを調べます。この情報をMIB内にカプセル化することで、マスター・エージェントは新規のサブエージェントを動的に登録できます。つまり、サブエージェントについてマスター・エージェントが認識しておく必要がある情報は、すべてそのMIBに含まれています。管理フレームワークと管理アプリケーションも、同じ目的でMIBを調べます。MIBは、標準（パブリックとも呼ばれます）または専用（プライベートまたはベンダーとも呼ばれます）のいずれでもかまいません。
変数の実際の値はMIBには含まれていませんが、「組込み」と呼ばれるプラットフォーム依存のプロセスによって取り出されます。すべてのSNMP通信で1つ以上のMIBオブジェクトが参照されるため、MIBの概念は非常に重要です。フレームワークに送信される内容は、基本的にはMIB変数とその現在の値です。
実際に、すべてのMIBは1つの大きな階層構造の一部です。この構造は、各変数の一意のID、データ型およびアクセス権を含むリーフ・ノードと、分類を示すパスで構成されています。プライベート・サブツリーには、複数のブランチが含まれた標準的なパス構造があります。この構造の一部を図1-2に示します。
変数名が説明的なものであるのに対して、OIDはその変数に到達するまでツリーでたどるパスを記述する数値です。たとえば、sysContactという名前の変数は、OID 1.3.6.1.2.1.1.4（iso.org.dodなどの意味）によって識別され、基盤となるシステムの管理者に関する接続情報が含まれた読み書き用の文字列変数です。
図1-2のmgmtというブランチの下にあるすべてのオブジェクト（つまり、OIDが1.3.6.1.2で始まるすべてのオブジェクト）は標準とみなされ、Internet Engineering Task Force（IETF）によって厳密に規定されます。たとえば、標準のRDBMS MIBはmgmtブランチの下に位置し、SNMP対応のすべてのリレーショナル・データベース・サーバーによってサポートされています。Oracleでは、Oracle製品をより管理しやすくするため、プライベートのブランチの下にさらに独自のMIBオブジェクトを追加しています。次のMIBは、Oracleサービスに固有で、{private.enterprise.oracle}というブランチの下にあります。
Oracle Database MIB
OracleリスナーMIB
このツリーの各リーフでは、1つのMIB変数に関する情報が提供されます。
MIBの詳細は、第3章「Oracle MIBの概要」および第4章「MIB変数の説明の解釈」を参照してください。
