この章の内容は以下のとおりです。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの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 WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照してください。
WebLogic Serverリリース9.2以前で作成されたドメインをサポートするため、管理サーバーまたは管理対象サーバー上のSNMPエージェント(サーバーSNMPエージェント)を構成するのではなく、ドメイン・スコープのSNMPエージェントを有効にして使用することができます。ドメイン・スコープのエージェントには、上述の集中型モデルにおけるサーバーSNMPエージェントと同じ機能があります。ただし、基底の実装が違っており、いずれ非推奨となる予定です。ドメイン・スコープのエージェントは、サーバーSNMPエージェントを管理サーバーにターゲット指定すると、オーバーライドされます。
WebLogic Server SNMPエージェントは、SNMPv3プロトコルを使用するマネージャとは常に通信可能です。エージェントが、SNMPv1およびSNMPv2プロトコルもサポートするかどうかを構成できます。エージェントがSNMPv3リクエストを受信しないようにすることはできませんが、エージェントでは、WebLogic Serverセキュリティ・レルムで構成した、既知のユーザーからのリクエストのみが処理されます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照してください。
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プロトコルを使用するリクエストでは、リクエストのコンテキスト名フィールドで管理対象サーバーの名前をエンコードします。
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プロトコルによって異なります。
SNMPv1およびSNMPv2ではなくSNMPv3プロトコルを使用することを強くお薦めします。
WebLogic SNMPエージェントからのデータをリクエストしているSNMPマネージャにデータを取得する許可が付与されていることを確認し、さらにそのエージェントにターゲット・マネージャへ通知を送信する許可が付与されていることを検証する場合、SNMPv1およびSNMPv2ではコミュニティ名というクリア・テキスト・パスワードが使用されます。
SNMPエージェントを作成する際には(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照)、エージェントにより要求されるSNMPマネージャからのコミュニティ名を指定します。
デフォルトで、簡易ネットワーク管理プロトコル(SNMP)はWebLogic Serverで無効になっています。しかし、SNMPを有効にすると、SNMPv1およびSNMPv2プロトコルも有効になります。SNMPv1およびSNMPv2はクリア・テキストのパスワードを使用するので、セキュアではなく、SNMPサービス上で不正アクセスやサービス拒否攻撃などのセキュリティ問題が発生する可能性が生じます。SNMPv1およびSNMPv2プロトコルを無効にし、かわりにSNMPv3プロトコルを使用することを強くお薦めします。各SNMPエージェントに対するコミュニティ・ベースのアクセスを無効にすることで、SNMPv1およびSNMPv2を無効にすることができます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照してください。
SNMPv3を使用できない場合、SNMPv1およびSNMPv2における弱いセキュリティの問題を限定するには、ネットワークがセキュアであることを確認し、WebLogic Server環境のポートへのアクセスを制限するようにファイアウォールを構成する必要があります。
SNMPv1およびSNMPv2ではなくSNMPv3プロトコルを使用することを強くお薦めします。
SNMPv3プロトコルでは、通信を正常に行うためにSNMPエージェントとマネージャの両方がPDUで同じ資格証明をエンコードする必要があります。資格証明には、複数のトークン(ユーザー名、SNMPエンジンID、認可プロトコル、および省略可能なプライバシ・パスワード)が含まれており、それらはすべて、ネットワーク経由でトランスポートされる前に、暗号化されます。
WebLogic Serverでは、SNMPエージェントはドメインのセキュリティ・レルムと連携して機能し、セキュアな通信を実現します。SNMPエージェントは、リクエスト内のSNMP資格証明をデコードして、セキュリティ・レルムにSNMPユーザー名を渡します。セキュリティ・レルムは、SNMPユーザー名をWebLogic Serverユーザーにマップし、ユーザーを認証し、ドメイン内のモニター・データへのアクセスを認可します。SNMP資格証明を、WebLogic Serverセキュリティ・レルム内のユーザーにマップするには、資格証明マップを作成します。
SNMPv3のセキュリティを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPv3通信の保護を参照してください。
パフォーマンス最適化のため、SNMPエージェントは、WebLogic ServerユーザーとSNMP資格証明を相互に関連付ける資格証明マップをキャッシュします。キャッシュに、SNMP資格証明の最新セットが確実に格納されるよう、エージェントは定期的に、キャッシュを無効化します。キャッシュの無効化後、次に資格証明をリクエストしたときに、エージェントはキャッシュを再生成します。
資格証明マップに変更を加えても、SNMPエージェントのキャッシュが自動的に更新されることはありません。キャッシュが更新されるのは、無効化を経た場合のみです。たとえば、SNMP資格証明マップの既存エントリ内のプライバシ・パスワードを更新した場合、SNMPエージェントは、キャッシュが無効化されて再生成されるまで、その新しいパスワードを認識しません。キャッシュが無効化されるまでは、古いセキュリティ・パスワードを付与されたSNMPユーザーが、引続きエージェントを使用してWebLogic Serverのデータにアクセスできます。
資格証明マップの修正後は、各SNMPエージェントがキャッシュの無効化を行うのを待機することも、即座に無効化することもできます。
キャッシュを即座に無効化する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMP資格証明のキャッシュの無効化を参照してください。
エージェントによるキャッシュ無効化の頻度は、エージェント作成時に構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成を参照してください。
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を参照してください。
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は一意の識別子を使用してオブジェクトを表現します。「オブジェクト識別子」を参照してください。
複雑なタイプや複雑なタイプの配列の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から構成されます。
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コマンドライン・ユーティリティを参照してください。
WebLogic SNMPエージェントは、WebLogic Server実行時MBeanサーバーに登録されたすべてのカスタムMBeanに対するエントリが格納された実行時MIBモジュールを保持するように構成できます。カスタムMBeanとは、ユーザーが作成および登録できるMBeanです(『Oracle WebLogic Server JMXによる管理可能アプリケーションの開発』を参照)。その後、SNMPマネージャを使用すると、カスタムMBeanに関する情報をリクエストできます。WebLogic Server SNMPエージェントでは、しきい値に到達した値があると、カスタムMBeanの値を定期的にポーリングして通知を生成することができません。かわりに、SNMPマネージャがWebLogic Server SNMPエージェントへのリクエストを送信する必要があります。
カスタムMBeanを監視するためのWebLogic SNMPエージェントの構成方法および使用方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム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