WebLogic Server SNMPエージェントおよびMIBの理解

SNMPの概要

SNMPでは、管理対象リソースの情報に対するリクエストが、マネージャからエージェントに送信されます。エージェントはリクエストされたデータを収集し、レスポンスを返します。また、管理対象リソースに対する定義済みのしきい値または条件を検出したときに、非請求レポート(通知)をマネージャに発行するように、エージェントを構成することもできます。

特定の管理対象リソースのデータをリクエストするには、マネージャがリソースを一意に識別できる必要があります。SNMPでは、各タイプの管理対象リソースは、一意のオブジェクト識別子(OID)が指定された管理対象オブジェクトとして、管理情報ベース(MIB)内に記述されます。個々の構成で、MIBモジュール内の特定の管理対象オブジェクトが定義されます。特定の管理対象リソースについて通信するには、マネージャとエージェントが両方とも、同じMIBモジュールにアクセスできる必要があります。

WebLogic Server SNMPエージェント

WebLogic Server SNMPエージェントは、WebLogic Server管理システムに対して問合せを実行し、SNMPプロトコルを通じてその結果をマネージャに通信します。WebLogic Server管理システムは、管理対象Bean (MBean)の集合を通じて、管理データを公開します。WebLogic Server SNMPエージェントは、マネージャからのリクエストを受信すると、マネージャのリクエスト内のOIDに対応するMBeanを判断します。次に、データを取り出し、SNMPレスポンスにラップします。

WebLogic Server SNMPエージェントを使用すると、次のことができます。

WebLogic Server MBean属性の現在の値に対するSNMPマネージャからの簡単なGETリクエストに応答します。

ノート:

WebLogic Serverでは、SNMPマネージャはMBeanの値の設定とMBean処理の呼出しはできません。SNMPマネージャでは、WebLogic Serverのモニターのみを実行できます。
JMXモニターを使用してWebLogic Server MBeanを定期的にポーリングし、指定したとおりにMBean属性が変更されたときにSNMPマネージャに通知を送信します。
管理サーバーまたは任意の管理対象サーバーが起動または停止したときに、SNMPマネージャに通知を送信します。
特定のログ・メッセージをリスニングし、WebLogic Serverがそのメッセージを生成したときにSNMPマネージャに通知を送信します。
SNMPマネージャからのリクエストを同一マシン内のWebLogic以外のSNMPエージェント(Oracleデータベース・エージェントなど)に渡すプロキシ・エージェントとして機能します。

ドメイン内でのSNMPエージェントの配置

各WebLogic Serverドメインで、複数のSNMPエージェントを作成して、SNMPモニターおよび通信のために、分散型または集中型モデルとして配置できます。

分散型モデルでは、管理対象サーバーごとにSNMPエージェントを作成します。SNMPマネージャは、個々の管理対象サーバーのエージェントと通信します。図2-1を参照してください。
集中型モデルでは、管理サーバーのみにSNMPエージェントを作成します。SNMPマネージャは、管理サーバーのSNMPエージェントとのみ通信し、エージェントがドメイン内のすべての管理対象サーバーからモニター・データを収集します。図2-2を参照してください。

これは、単一のリクエストでドメイン全体のデータを取り出せる便利なモデルですが、次のような問題があります。
- 管理サーバーが利用できない場合は、SNMPによってドメインをモニターできません。
- ドメインが大きい場合、特定リソースの情報を見つけるために大量のデータをフィルタ処理する必要があリます。レスポンスでデータをフィルタ処理するかわりに、リクエストの範囲を絞り込むことが可能です。「リクエストのスコープの限定」を参照してください。
- このモデルでは、パフォーマンス・オーバーヘッドを導入しています。ドメイン内の全サーバーからデータを収集するには、管理サーバー上のエージェントがドメイン実行時MBeanサーバーに対して問合せを実行します。このMBeanサーバーは、ドメイン全体のサービスに対するMBeanを含み、管理対象サーバー上にあるMBeanへの単一のアクセス・ポイントとしても機能します。ドメイン実行時MBeanサーバーは、ドメイン内のすべての管理対象サーバーと通信するので、ネットワーク・レイテンシの影響を受けやすく、管理サーバーが使用するメモリーの量が増大します。

図2-1は、ドメイン内の個々のサーバーにSNMPエージェントを作成する際、エージェントによってホスト・サーバーの実行時MBeanサーバー内のMBeanに問合せが行われるプロセスを図示したものです。このMBeanサーバーには、個々のホスト・サーバーのMBeanのみが含まれます。

図2-1 SNMPモニターおよび通信の分散型モデル

「図2-1 SNMPモニターおよび通信の分散型モデル」の説明

図2-2は、管理サーバー上のSNMPエージェントを使用して管理対象サーバーのデータを取り出す際、エージェントによってドメイン実行時MBeanサーバー内のMBeanに対し問合せが行われるプロセスを図示したものです。

図2-2 SNMPモニターおよび通信の集中型モデル

「図2-2 SNMPモニターおよび通信の集中型モデル」の説明

WebLogic Server SNMPエージェントの作成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成に関する項を参照してください。

ドメイン・スコープのエージェント

WebLogic Serverリリース9.2以前で作成されたドメインをサポートするため、管理サーバーまたは管理対象サーバー上のSNMPエージェント(サーバーSNMPエージェント)を構成するのではなく、ドメイン・スコープのSNMPエージェントを有効にして使用することができます。ドメイン・スコープのエージェントには、上述の集中型モデルにおけるサーバーSNMPエージェントと同じ機能があります。ただし、基底の実装が違っており、いずれ非推奨となる予定です。ドメイン・スコープのエージェントは、サーバーSNMPエージェントを管理サーバーにターゲット指定すると、オーバーライドされます。

SNMPプロトコルの構成

WebLogic Server SNMPエージェントは、SNMPv3プロトコルを使用するマネージャとは常に通信可能です。エージェントが、SNMPv1およびSNMPv2プロトコルもサポートするかどうかを構成できます。エージェントがSNMPv3リクエストを受信しないようにすることはできませんが、エージェントでは、WebLogic Serverセキュリティ・レルムで構成した、既知のユーザーからのリクエストのみが処理されます。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照してください。

ノート:

SNMPv1およびv2プロトコルの使用は、このリリースのWebLogic Serverでは非推奨です。「SNMPのセキュリティ」を参照してください。

UDPポートおよびTCPポートの構成

SNMPエージェントは、UDPトラフィックを受け付けるポートと、TCPトラフィックを受け付ける別のポートを介して通信します。デフォルトでは、すべてのTCPトラフィックに、ホスト・サーバーのリスニング・ポートを使用します。たとえば、このエージェントをManagedServer1という名前のサーバーにターゲット指定し、ManagedServer1がポート7001に対するリクエストをリスニングする場合、SNMPエージェントはポート7001に対するTCPリクエストをリスニングします。TCPポートを介しての通信時には、WebLogic Serverはサービス拒否(DOS)攻撃からSNMP通信を保護します。

SNMP TCPトラフィックを、ビジネス・トラフィックから分離する場合は、カスタム・ネットワーク・チャネルを作成します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成に関する項とSNMPネットワーク・チャネルの作成に関する項を参照してください。

リクエストのスコープの限定

SNMPマネージャが管理サーバー上のエージェントに対するリクエストを送信した場合、エージェントのレスポンスには、オブジェクトの複数のインスタンスを記述するデータが含まれている可能性があります。たとえばserverUptimeというオブジェクトは、ドメイン内のWebLogic Serverインスタンスごとに存在します。マネージャがserverUptimeに対するリクエストを管理サーバー上のエージェントに送信した場合、レスポンスにはドメイン内の各サーバーにつきserverUptimeインスタンスが1つ含まれます。

マネージャのリクエスト内において追加情報をエンコードすることで、リクエストのスコープを限定することができます。エンコードする情報は、使用するSNMPプロトコルに応じて変わります。

SNMPv1またはSNMPv2プロトコルを使用するリクエストでは、次のように、リクエストと共に送信するSNMPコミュニティ名に、サーバー・インスタンス名を付加します。

community_prefix@server_name

community_prefixはSNMPコミュニティ名、server_nameは目的の管理対象サーバーの名前です。マネージャから送信されるcommunity_prefixの値は、SNMPエージェントの構成時に「コミュニティ接頭辞」フィールドで設定する値と一致する必要があります。

ドメイン内のすべてのサーバー・インスタンスの管理対象オブジェクトをリクエストするには、コミュニティ名を次の形式でWebLogic SNMPエージェントに送信します。

community_prefix
SNMPv3プロトコルを使用するリクエストでは、リクエストのコンテキスト名フィールドで管理対象サーバーの名前をエンコードします。

SNMPエージェントのモニター

WebLogic Server管理コンソールの「SNMP」→「監視」タブでは、ドメイン内の各SNMPエージェントについて、マネージャに送信した通知の数や、失敗した認証の試行回数などの情報を確認できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの監視を参照してください。

また、WebLogic Scripting Tool (WLST)またはJMXクライアントを使用してこのモニター情報にアクセスし、新しいSNMPAgentRuntimeMBeanにアクセスすることもできます。Oracle WebLogic Server MBeanリファレンスのSNMPAgentRuntimeMBeanを参照してください。WLSTの使用については、『WebLogic Scripting Toolの理解』を参照してください。

SNMPのセキュリティ

SNMPで利用できるセキュリティ機能は、エージェントがマネージャとの通信に使用するSNMPプロトコルによって異なります。

ノート:

SNMPv1およびv2プロトコルの使用は、このリリースのWebLogic Serverでは非推奨となり、デフォルトでは無効になっています。かわりに、SNMPv3プロトコルを使用することを強くお薦めします。構成属性でSNMPv1およびv2プロトコルの使用が有効になっている場合、WebLogic Serverでは起動時に非推奨の警告をログに記録します。

SNMPv1およびSNMPv2用のコミュニティ名

WebLogic SNMPエージェントからのデータをリクエストしているSNMPマネージャにデータを取得する許可が付与されていることを確認し、さらにそのエージェントにターゲット・マネージャへ通知を送信する許可が付与されていることを検証する場合、SNMPv1およびSNMPv2ではコミュニティ名というクリア・テキスト・パスワードが使用されます。

SNMPエージェントを作成する際には(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照)、エージェントにより要求されるSNMPマネージャからのコミュニティ名を指定します。

SNMPv1およびv2はクリア・テキスト・パスワードを使用するため、これらは保護されません。かわりに、SNMPv3を使用することを強くお薦めします。

SNMPv1およびSNMPv2の使用

デフォルトで、簡易ネットワーク管理プロトコル(SNMP)はWebLogic Serverで無効になっています。SNMPを有効にすると、SNMPv3プロトコルも有効になります。SNMPv1およびSNMPv2はクリア・テキストのパスワードを使用するので、セキュアではなく、SNMPサービス上で不正アクセスやサービス拒否攻撃などのセキュリティ問題が発生する可能性が生じます。デフォルトで無効になっているSNMPv1およびSNMPv2ではなくSNMPv3プロトコルを使用することを強くお薦めします。必要に応じて、各SNMPエージェントに対するコミュニティ・ベースのアクセスを有効にすることで、SNMPv1およびSNMPv2を有効にすることができます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照してください。

SNMPv3を使用できない場合、SNMPv1およびSNMPv2における弱いセキュリティの問題を限定するには、ネットワークがセキュアであることを確認し、WebLogic Server環境のポートへのアクセスを制限するようにファイアウォールを構成する必要があります。

SNMPv3のセキュリティの構成

SNMPv1およびSNMPv2ではなくSNMPv3プロトコルを使用することを強くお薦めします。

SNMPv3プロトコルでは、通信を正常に行うためにSNMPエージェントとマネージャの両方がPDUで同じ資格証明をエンコードする必要があります。資格証明には、複数のトークン(ユーザー名、SNMPエンジンID、認可プロトコル、および省略可能なプライバシ・パスワード)が含まれており、それらはすべて、ネットワーク経由でトランスポートされる前に、暗号化されます。

WebLogic Serverでは、SNMPエージェントはドメインのセキュリティ・レルムと連携して機能し、セキュアな通信を実現します。SNMPエージェントは、リクエスト内のSNMP資格証明をデコードして、セキュリティ・レルムにSNMPユーザー名を渡します。セキュリティ・レルムは、SNMPユーザー名をWebLogic Serverユーザーにマップし、ユーザーを認証し、ドメイン内のモニター・データへのアクセスを認可します。SNMP資格証明を、WebLogic Serverセキュリティ・レルム内のユーザーにマップするには、資格証明マップを作成します。

SNMPv3のセキュリティを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMP v3通信の保護に関する項を参照してください。

SNMPv3資格証明キャッシュの無効化

パフォーマンス最適化のため、SNMPエージェントは、WebLogic ServerユーザーとSNMP資格証明を相互に関連付ける資格証明マップをキャッシュします。キャッシュに、SNMP資格証明の最新セットが確実に格納されるよう、エージェントは定期的に、キャッシュを無効化します。キャッシュの無効化後、次に資格証明をリクエストしたときに、エージェントはキャッシュを再生成します。

資格証明マップに変更を加えても、SNMPエージェントのキャッシュが自動的に更新されることはありません。キャッシュが更新されるのは、無効化を経た場合のみです。たとえば、SNMP資格証明マップの既存エントリ内のプライバシ・パスワードを更新した場合、SNMPエージェントは、キャッシュが無効化されて再生成されるまで、その新しいパスワードを認識しません。キャッシュが無効化されるまでは、古いセキュリティ・パスワードを付与されたSNMPユーザーが、引続きエージェントを使用してWebLogic Serverのデータにアクセスできます。

資格証明マップの修正後は、各SNMPエージェントがキャッシュの無効化を行うのを待機することも、即座に無効化することもできます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMP資格証明のキャッシュの無効化に関する項を参照してください。

エージェントによるキャッシュ無効化の頻度は、エージェント作成時に構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照してください。

WebLogic Server用のMIBモジュール

WebLogic Server用のMIBモジュールでは、抽象構文記法1 (Abstract Syntax Notation.1: ASN.1)を使用して、SNMPを介してモニターできるリソース・タイプと、WebLogic Server SNMPエージェントがSNMPマネージャに送信できる通知タイプを記述します。

WebLogic Serverインストーラは、MIBモジュールのコピーを次の場所に作成します。ここで、WL_HOMEは、WebLogic Serverのルート・インストール・ディレクトリを示します。

WL_HOME/server/lib/BEA-WEBLOGIC-MIB.asn1

WebLogic Serverの各リリースによって、新しい管理対象オブジェクトがモジュールに追加されます。既存の管理対象オブジェクトのオブジェクト識別子は、リリースごとに変更されません。

以下の節では、WebLogic Server MIBモジュールについて説明します。

階層データ・モデル

WebLogic Serverは、その管理システム内で多数のデータ・ポイントを公開します。このデータを編成するために、ドメインで利用可能なサービスとリソースの集まりを反映した階層データ・モデルが用意されてます。たとえば、WebLogic Serverドメインには複数のサーバーを配置できます。各サーバーはアプリケーションを保持(またはホスト)し、各アプリケーションにはWebアプリケーション、EJB、および他のJava EEモジュールが含まれます。

WebLogic Server MIBモジュールは、この階層を反映しています。たとえば、WebLogic Serverドメインは、その構成全体をdomainTableという表形式の管理対象オブジェクトに記述します。この表形式のオブジェクトはスカラー・オブジェクトの集合を参照(保持)し、それぞれのオブジェクトはドメインの何らかの属性を定義します。たとえば、domainTableには、ドメインのすべてのサーバー名を定義するdomainServersというスカラー・オブジェクトがあります。serverTableオブジェクトには、serverDeploymentsというスカラー・オブジェクトがあります。これは、サーバーに現在デプロイされているすべてのアプリケーションを定義します。

表形式のオブジェクトは、オブジェクト・インスタンス(MIB変数)を直接保持しません。かわりに、表形式のオブジェクトはスカラー・オブジェクトを保持し、スカラー・オブジェクトは変数を保持します。たとえば、MS1とMS2という2つの管理対象サーバーをドメインに作成した場合、MIBにはserverTableオブジェクトが1つあり、このオブジェクトにserverNameオブジェクトが含まれます。serverNameオブジェクトには、MS1とMS2という値を保持する2つの変数が存在します。図2-3を参照してください。

図2-3 オブジェクトとオブジェクト・インスタンスの階層

「図2-3 オブジェクトとオブジェクト・インスタンスの階層」の説明

構成と実行時の階層

WebLogic Server管理データ・モデルは、そのすべての管理データを反映した1つの大規模な階層ではなく、2つの階層から構成されます。ひとつはその構成データ用で、もうひとつは実行時のみに利用可能なパフォーマンスおよびモニター・データ用です。実行時データを記述するすべての管理対象オブジェクトには、名前に「runtime」という単語が含まれますが、構成用の管理対象オブジェクトには含まれません。たとえば、MIBのdomainTableにはドメインの構成が記述され、domainRuntimeTableには実行時データが記述されます。

MIBモジュールとWebLogic Server MBeanデータ・モデルの関係

WebLogic Serverには、Java Management Extensions (JMX)の実装の一部として管理対象Bean (MBean)が用意されています。JMXはプログラミングによってWebアプリケーション・サーバーの管理データにアクセスするためのJava EE仕様であり、MBeanは管理データと管理処理を表現したものです。JMXの目的は、SNMPと同じように、エージェントとマネージャ間の管理情報の標準通信を実現することです。

実装レベルでは、WebLogic Server SNMPエージェントとMIBは、WebLogic Server JMX実装の上部のプロトコル固有レイヤーを形成します。WebLogic Server JMX実装について理解していれば、WebLogic Server MBeanのデータ・モデルとWebLogic Server MIBの管理対象オブジェクトの構成が似ていることに気がつきます。しかし、重要な相違点もいくつかあります。

WebLogic Serverでは、JMXクライアント(SNMPマネージャに類似)はドメインをモニターでき、またドメインの構成を変更できます。SNMPマネージャには、その管理システムに対する読取りアクセス権のみが付与されています。
MBeanのデータ・モデルは階層が深く、MIBのデータ・モデルは浅いです。たとえば、JMXクライアントはDomainMBeanからその子であるServerMBeansを参照し、さらに各ServerMBeanの子を参照できます。これに対し、MIBは一意の識別子を使用してオブジェクトを表現します。「オブジェクト識別子」を参照してください。
複雑なタイプや複雑なタイプの配列のMBean属性のエントリは、SNMP MIBには含まれません。Stringや簡単なタイプのMBean属性、またはStringや簡単なタイプの配列のMBean属性がMIBで定義されます。

WebLogic ServerのJMX実装の詳細は、『Oracle WebLogic Server JMXによる管理可能アプリケーションの開発』を参照してください。

オブジェクト識別子

MIBは、各管理対象オブジェクトにオブジェクト識別子 (OID)という一意で不変な番号を割り当てます。各OIDは、左から右に並べられた整数で構成されています。この数値の並び順は、MIBツリー内のオブジェクトの位置を定義し、ツリー内でのオブジェクトへの一意のパスを指定します。パス上の各ノードには、番号とその番号に関連付けられた名前があります。

パス.1.3.6.1.4.1は、private.enterprises OIDを定義しており、ツリーにおいてこのノードの下にあるそれぞれの番号は、特定ベンダー(Oracleなど)用に予約されたツリーのブランチを表しています。MIBモジュールは、ツリー内の.1.3.6.1.4.1.140で登録され、WebLogic Server MIBモジュールは.1.3.6.1.4.1.140.625の下にあるすべてのOIDから構成されます。

オブジェクトと変数のOID

WebLogic Server MIBモジュールは、OIDを使用してその階層データ・モデルを反映します。たとえば、serverRuntimeTableオブジェクトのOIDは、.1.3.6.1.4.1.140.625.360です。serverRuntimeTableオブジェクトに含まれるserverRuntimeStateスカラー・オブジェクトのOIDは、.1.3.6.1.4.1.140.625.360.1.60です。

オブジェクトのインスタンス(変数)を識別するため、WebLogic SNMPエージェントでは、一連の追加番号が生成され、オブジェクトのOIDに付加されます。たとえば、serverRuntimeStateの変数のOIDは以下のようになります。

.1.3.6.1.4.1.140.625.
360.1.60.32.102.100.48.98.101.102.100.99.102.52.98.97.48.48.49.102.57.53.51.50.
100.102.53.55.97.101.52.56.99.99.97.99.

OIDは、そのオブジェクトの複数のインスタンスにわたって不変です。

管理対象オブジェクトのOIDを参照する場合は、BEA-WEBLOGIC-MIB.asn1の内容を表示できます。また、変数のOIDを参照する場合は、SnmpWalkコマンドまたはSnmpGetNextコマンドを使用します。WebLogic SNMPコマンドライン・ユーティリティを参照してください。

MIBの閲覧

WebLogic ServerのMIBモジュールの内容を表示するには、MIBブラウザの使用をお薦めします。WebLogic Serverには付属していませんが、MIBブラウザはほとんどのSNMPユーティリティ・ベンダーによって提供されています。

MIBモジュールは、WebLogic Serverのインストール・ディレクトリの次の場所に格納されています。

WL_HOME/server/lib/BEA-WEBLOGIC-MIB.asn1

カスタムMBeanのモニター

WebLogic SNMPエージェントは、WebLogic Server実行時MBeanサーバーに登録されたすべてのカスタムMBeanに対するエントリが格納された実行時MIBモジュールを保持するように構成できます。カスタムMBeanは、作成して登録するMBeanです。その後、SNMPマネージャを使用すると、カスタムMBeanに関する情報をリクエストできます。WebLogic Server SNMPエージェントでは、しきい値に到達した値があると、カスタムMBeanの値を定期的にポーリングして通知を生成することができません。かわりに、SNMPマネージャがWebLogic Server SNMPエージェントへのリクエストを送信する必要があります。『Oracle WebLogic Server JMXによる管理可能アプリケーションの開発』を参照してください。

カスタムMBeanを監視するためのWebLogic SNMPエージェントの構成方法および使用方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタムMBeanの監視に関する項を参照してください。

カスタムMBean MIBモジュールの構造

各カスタムMBeanタイプについて、WebLogic ServerではMIBモジュールに表が追加されます。カスタムMBeanの各インスタンスについて、表の行が追加されます。各MBean属性については、表の列が追加されます。

標準MBeanの表名はそのMBeanの実装クラスの名前に基づいており、モデルMBeanの表名はそのMBeanのMBeanInfoオブジェクトで指定されている名前に基づいています。

カスタムMBeanタイプの表に加えて、MBean MIBモジュールには、federatedMBeanServerDelegateTableおよびmBeanServerDelegateTableという2つの表があります。これらのMBeanには、MBeanサーバー自体に関する情報(ベンダー名、バージョン番号など)が含まれています。

WebLogic Serverでは、MIBモジュールをファイルなどのデータ構造として永続化することはありませんが、モジュール内のOIDは複数のサーバー・セッションに渡って一定に保持されます。

例2-1に、Avitek Medical Recordsアプリケーション(MedRec)から抜粋したカスタムMBean MIBモジュールを示します。MedRecはWebLogic Serverに付属のエンドツーエンドのサンプルJava EEアプリケーションです。MedRecは、WebLogic Server実行時MBeanサーバーに、2つのカスタムMBeanを登録します。

AdminReportMBean。これはデータベースを6秒ごとにポーリングして、システムに追加する新規ユーザーを確認します。新規ユーザー数は、NewUserCountという属性に格納されます。
RecordSessionEJBMBean。これにはRecordSessionEJBがデータベースに処方箋を書き込む回数を記録する1つの属性TotalRxが含まれます。

例2-1のMIBモジュールには、MedRecのカスタムMBeanタイプごとに1つずつの表、adminReportTableおよびrecordSessionEJBMBeanImplTableが含まれます。MIB内の表名(adminReportTableおよびrecordSessionEJBMBeanImplTable)は、AdminReportMBeanおよびRecordSessionEJBMBean (標準MBean)の、基底の実装クラスに一致しています。

例2-1 MedRecサーバーにおけるカスタムMBeanのMIBモジュール

CUSTOM-MBEANS-MIB DEFINITIONS ::=
BEGIN
    IMPORTS
    wls    FROM BEA-WEBLOGIC-MIB
    OBJECT-TYPE, MODULE-IDENTITY    FROM SNMPv2-SMI
    ;
customMBeansMib MODULE-IDENTITY
    LAST-UPDATED "0701101716Z"
    ORGANIZATION "..."
    CONTACT-INFO "...."
    DESCRIPTION "MIB for custom MBeans registered in WLS RuntimeMBeanServer"
    ::= { wls 50  }
customMBeansMibTables OBJECT IDENTIFIER ::= { customMBeansMib 1  }
adminReportTable-Oid OBJECT IDENTIFIER ::= { 
  customMBeansMibTables 97 100 109 105 110 82 101 112 111 114
federatedMBeanServerDelegateTable-Oid OBJECT IDENTIFIER ::= { 
  customMBeansMibTables 102 101 100 101 114
mBeanServerDelegateTable-Oid OBJECT IDENTIFIER ::= { 
  customMBeansMibTables 109 66 101 97 110 83 101 114
recordSessionEJBMBeanImplTable-Oid OBJECT IDENTIFIER ::= {
  customMBeansMibTables 114 101 99 111 114 100
adminReportTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF AdminReportEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dynamically created table for type
      com.bea.medrec.admin.AdminReport"
    ::= { adminReportTable-Oid 1  }
adminReportEntry OBJECT-TYPE
    SYNTAX      AdminReportEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Generated SNMP Table Entry."
    INDEX { adminReportIndex}
    ::= { adminReportTable 1 }
AdminReportEntry ::=
    SEQUENCE
    {
    adminReportIndex     OCTET STRING,
    adminReportObjectName OCTET STRING,
    adminReportNewUserCount OCTET STRING
    }
adminReportIndex OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Index column"
    ::= { adminReportEntry 1  }
adminReportObjectName OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION "ObjectName column"
    ::= { adminReportEntry 2  }
adminReportNewUserCount OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION "Attribute exposed for management"
    ::= { adminReportEntry 3  }
... Definitions for federatedMBeanServerDelegateTable and
mBeanServerDelegateTable are omitted from this example ...
recordSessionEJBMBeanImplTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF RecordSessionEJBMBeanImplEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dynamically created table for type
      com.bea.medrec.controller.RecordSessionEJBMBeanImpl"
    ::= { recordSessionEJBMBeanImplTable-Oid 1  }
recordSessionEJBMBeanImplEntry OBJECT-TYPE
    SYNTAX      RecordSessionEJBMBeanImplEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Generated SNMP Table Entry."
    INDEX { recordSessionEJBMBeanImplIndex}
    ::= { recordSessionEJBMBeanImplTable 1 }
RecordSessionEJBMBeanImplEntry ::=
    SEQUENCE
    {
    recordSessionEJBMBeanImplIndex OCTET STRING,
    recordSessionEJBMBeanImplObjectName OCTET STRING,
    recordSessionEJBMBeanImplTotalRx OCTET STRING
    }
recordSessionEJBMBeanImplIndex OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Index column"
    ::= { recordSessionEJBMBeanImplEntry 1  }
recordSessionEJBMBeanImplObjectName OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION "ObjectName column"
    ::= { recordSessionEJBMBeanImplEntry 2  }
recordSessionEJBMBeanImplTotalRx OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION "Attribute exposed for management"
    ::= { recordSessionEJBMBeanImplEntry 3  }
END