| Oracle® Oracle Fusion Middleware Oracle WebLogic Server SNMP管理ガイド 11g リリース1 (10.3.6) B61639-05 |
|
 前 |
 次 |
| Oracle® Oracle Fusion Middleware Oracle WebLogic Server SNMP管理ガイド 11g リリース1 (10.3.6) B61639-05 |
|
前 |
次 |
Simple Network Management Protocol (SNMP)を使用すると、企業全体の管理システムにモニター・データを提供できます。
以下の節では、SNMP管理モデル、およびWebLogic Serverが、このモデルを実装する仕組みについて説明します。
詳細は、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の使い方については、『Oracle WebLogic Scripting Tool』を参照してください。
SNMPで利用できるセキュリティ機能は、エージェントがマネージャとの通信に使用するSNMPプロトコルによって異なります。
WebLogic SNMPエージェントからのデータをリクエストしているSNMPマネージャにデータを取得する許可が付与されていることを確認し、さらにそのエージェントにターゲット・マネージャへ通知を送信する許可が付与されていることを検証する場合、SNMPv1およびSNMPv2ではコミュニティ名というクリア・テキスト・パスワードが使用されます。
SNMPエージェントを作成する際には(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成に関する項を参照)、エージェントにより要求されるSNMPマネージャからのコミュニティ名を指定します。
SNMPv1およびSNMPv2はクリア・テキスト・パスワードを使用するため、セキュリティ・レベルは低いものです。マネージャとの通信にSNMPv3を使用できる場合は、各SNMPエージェントに対するコミュニティ・ベースのアクセスの無効化によってSNMPv1およびSNMPv2を無効化することを検討してください。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPエージェントの作成に関する項を参照してください。
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モジュールのコピーが作成されます。
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を参照し、さらに各ServerMBeaの子を参照できます。これに対し、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.zipを使用します。また、変数のOIDを参照する場合は、SnmpWalkコマンドまたはSnmpGetNextコマンドを使用します。詳細は、第5章「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 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
