| Oracle® Fusion Middleware Oracle WebLogic Server SNMP 管理ガイド 11g リリース 1 (10.3.1) B55552-01 |
|
 戻る |
 次へ |
Simple Network Management Protocol (SNMP) を使用すると、企業全体の管理システムにモニタ データを提供できます。
以下の節では、SNMP 管理モデル、および WebLogic Server が、このモデルを実装する仕組みについて説明します。
詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMP を使用した WebLogic Server のモニタ」を参照してください。
SNMP では、管理対象リソースの情報に対するリクエストが、マネージャからエージェントに送信されます。エージェントは要求されたデータを収集し、応答を返します。また、管理対象リソースに対する定義済みのしきい値または条件を検出したときに、非請求レポート (通知) をマネージャに発行するように、エージェントをコンフィグレーションすることもできます。
特定の管理対象リソースのデータを要求するには、マネージャがリソースをユニークに識別できる必要があります。SNMP では、各タイプの管理対象リソースは、ユニークなオブジェクト識別子 (OID) が指定された管理対象オブジェクトとして、管理情報ベース (MIB) 内に記述されます。個々の構成で、MIB モジュール内の特定の管理対象オブジェクトが定義されます。特定の管理対象リソースについて通信するには、マネージャとエージェントが両方とも、同じ MIB モジュールにアクセスできる必要があります。
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 データベース エージェントなど) に渡すプロキシ エージェントとして機能する。
各 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-2 は、管理サーバ上の SNMP エージェントを使用して管理対象サーバのデータを取り出す際、エージェントによってドメイン実行時 MBean サーバ内の MBean に対しクエリが行われるプロセスを図示したものです。
WebLogic Server SNMP エージェントの作成方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMP エージェントの作成」を参照してください。
WebLogic Server リリース 9.2 以前で作成されたドメインをサポートするため、管理サーバまたは管理対象サーバ上の SNMP エージェント (サーバ SNMP エージェント) をコンフィグレーションするのではなく、ドメイン スコープの SNMP エージェントを有効にして使用することができます。ドメイン スコープのエージェントには、上述の集中型モデルにおけるサーバ SNMP エージェントと同じ機能があります。ただし、基底の実装が違っており、いずれ非推奨となる予定です。ドメイン スコープのエージェントは、サーバ SNMP エージェントを管理サーバに対象指定すると、オーバーライドされます。
WebLogic Server SNMP エージェントは、SNMPv3 プロトコルを使用するマネージャとは常に通信可能です。エージェントが、SNMPv1 および SNMPv2 プロトコルもサポートするかどうかをコンフィグレーションできます。エージェントが SNMPv3 リクエストを受信しないようにすることはできませんが、エージェントでは、WebLogic Server セキュリティ レルムでコンフィグレーションした、既知のユーザからのリクエストのみが処理されます。
詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMP エージェントの作成」を参照してください。
SNMP エージェントは、UDP トラフィックを受け付けるポートと、TCP トラフィックを受け付ける別のポートを介して通信します。デフォルトでは、すべての TCP トラフィックに、ホスト サーバのリスン ポートを使用します。たとえば、このエージェントを ManagedServer1 という名前のサーバに対象指定し、ManagedServer1 がポート 7001 に対するリクエストをリスンする場合、SNMP エージェントはポート 7001 に対する TCP リクエストをリスンします。TCP ポートを介しての通信時には、WebLogic Server はサービス拒否 (DOS) 攻撃から SNMP 通信を保護します。
SNMP TCP トラフィックを、ビジネス トラフィックから分離する場合は、カスタム ネットワーク チャネルを作成します。
詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「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 プロトコルを使用するリクエストでは、リクエストのコンテキスト名フィールドで管理対象サーバの名前をエンコードする。
WebLogic Server Administration Console の [SNMP: モニタ] タブでは、ドメイン内の各 SNMP エージェントについて、マネージャに送信した通知の数や、失敗した認証の試みの回数などの情報を確認できます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMP エージェントのモニタ」を参照してください。
また、WebLogic Scripting Tool (WLST) または JMX クライアントを使用してこのモニタ情報にアクセスし、新しい SNMPAgentRuntimeMBean にアクセスすることもできます。『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「SNMPAgentRuntimeMBean」を参照してください。WLST の使用方法については、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド』を参照してください。
SNMP で利用できるセキュリティ機能は、エージェントがマネージャとの通信に使用する SNMP プロトコルによって異なります。
WebLogic SNMP エージェントからのデータを要求している SNMP マネージャにデータを取得するパーミッションが付与されていることを確認し、さらにそのエージェントに対象マネージャへ通知を送信するパーミッションが付与されていることを検証する場合、SNMPv1 および SNMPv2 ではコミュニティ名というクリアテキスト パスワードが使用されます。
SNMP エージェントを作成する際には (Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMP エージェントの作成」を参照)、エージェントにより要求される SNMP マネージャからのコミュニティ名を指定します。
SNMPv1 および SNMPv2 はクリアテキスト パスワードを使用するため、セキュリティ レベルは低いものです。マネージャとの通信に SNMPv3 を使用できる場合は、各 SNMP エージェントに対するコミュニティベースのアクセスの無効化によって SNMPv1 および SNMPv2 を無効化することを検討してください。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMP エージェントの作成」を参照してください。
SNMPv3 プロトコルでは、通信を正常に行うために SNMP エージェントとマネージャの両方が PDU で同じ資格をエンコードする必要があります。資格には、複数のトークン (ユーザ名、SNMP エンジン ID、認可プロトコル、および省略可能なプライバシ パスワード) が含まれており、それらはすべて、ネットワーク経由で転送される前に、暗号化されます。
WebLogici Server では、SNMP エージェントはドメインのセキュリティ レルムと連携して機能し、セキュアな通信を実現します。SNMP エージェントは、リクエスト内の SNMP 資格をデコードして、セキュリティ レルムに SNMP ユーザ名を渡します。セキュリティ レルムは、SNMP ユーザ名を WebLogic Server ユーザにマップし、ユーザを認証し、ドメイン内のモニタ データへのアクセスを認可します。SNMP 資格を、WebLogic Server セキュリティ レルム内のユーザにマップするには、資格マップを作成します。
SNMPv3 のセキュリティをコンフィグレーションする方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMPv3 通信の保護」を参照してください。
パフォーマンス最適化のため、SNMP エージェントは、WebLogic Server ユーザと SNMP 資格を相互に関連付ける資格マップをキャッシュします。キャッシュに、SNMP 資格の最新セットが確実に格納されるよう、エージェントは定期的に、キャッシュを無効化します。キャッシュの無効化後、次に資格を要求したときに、エージェントはキャッシュを再生成します。
資格マップに変更を加えても、SNMP エージェントのキャッシュが自動的に更新されることはありません。キャッシュが更新されるのは、無効化を経た場合のみです。たとえば、SNMP 資格マップの既存エントリ内のプライバシ パスワードを更新した場合、SNMP エージェントは、キャッシュが無効化されて再生成されるまで、その新しいパスワードを認識しません。キャッシュが無効化されるまでは、古いセキュリティ パスワードを付与された SNMP ユーザが、引き続きエージェントを使用して WebLogic Server のデータにアクセスできます。
資格マップの修正後は、各 SNMP エージェントがキャッシュの無効化を行うのを待機することも、即座に無効化することもできます。
キャッシュを即座に無効化する方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMP 資格のキャッシュの無効化」を参照してください。
エージェントによるキャッシュ無効化の頻度は、エージェント作成時にコンフィグレーションできます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SNMP エージェントの作成」を参照してください。
WebLogic Server 用の MIB モジュールでは、抽象構文記法 1 (Abstract Syntax Notation.1 : ASN.1) を使用して、SNMP を介してモニタできるリソース タイプと、WebLogic Server SNMP エージェントが SNMP マネージャに送信できる通知タイプを記述します。
WebLogic Server のインストーラによって、次の場所に MIB モジュールのコピーが作成されます。
MW_HOME/WL_HOME/server/lib/BEA-WEBLOGIC-MIB.asn1
MW_HOME は、WebLogic Server のインストール先である Oracle Middleware ホーム ディレクトリです。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 を参照してください。
WebLogic Server 管理データ モデルは、そのすべての管理データを反映した 1 つの大規模な階層ではなく、2 つの階層から構成されます。ひとつはそのコンフィグレーション データ用で、もうひとつは実行時のみに利用可能なパフォーマンスおよびモニタ データ用です。実行時データを記述するすべての管理対象オブジェクトには、名前に「runtime」という単語が含まれますが、コンフィグレーション用の管理対象オブジェクトには含まれません。たとえば、MIB の domainTable にはドメインのコンフィグレーションが記述され、domainRuntimeTable には実行時データが記述されます。
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 はユニークな識別子を使用してオブジェクトを表現します。「オブジェクト識別子」を参照してください。
WebLogic Server の JMX 実装の詳細については、『Oracle Fusion Middleware 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 から構成されます。
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.zip を使用します。また、変数の OID を参照する場合は、SnmpWalk コマンドまたは SnmpGetNext コマンドを使用します。詳細については、「WebLogic SNMP コマンドライン ユーティリティ」を参照してください。
WebLogic Server MIB モジュールの内容を参照するには、以下のいずれかの方法を使用します。
MIB ブラウザを使用する。WebLogic Server には付属していませんが、MIB ブラウザはほとんどの SNMP ユーティリティ ベンダによって提供されています。
Web ブラウザを使用して、BEA-WEBLOGIC-MIB.asn1.zip を参照する。
この MIB リファレンスでは、MIB ブラウザに似せた閲覧機能を実現するために Javascript および DHTML を使用しているので、以下の Web ブラウザを使用する必要があります。
Internet Explorer (バージョン 5 以上)
Netscape Navigator (バージョン 6 以上)
Opera 7 以上
Mozilla
Phoenix
WebLogic SNMP エージェントは、WebLogic Server 実行時 MBean サーバに登録されたすべてのカスタム MBean に対するエントリが格納された実行時 MIB モジュールを保持するようにコンフィグレーションできます。カスタム MBean とは、ユーザが作成および登録できる MBean です (『Oracle Fusion Middleware Oracle WebLogic Server JMX による管理の容易なアプリケーションの開発』を参照)。その後、SNMP マネージャを使用すると、カスタム MBean に関する情報を要求できます。WebLogic Server SNMP エージェントでは、しきい値に到達した値があると、カスタム MBean の値を定期的にポーリングして通知を生成することができません。代わりに、SNMP マネージャが WebLogic Server SNMP エージェントへのリクエストを送信する必要があります。
カスタム MBean をモニタするための WebLogic SNMP エージェントのコンフィグレーション方法および使用方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「カスタム MBean のモニタ」を参照してください。
各カスタム 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
