WebLogic SNMP Management Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Understanding the WebLogic Sever SNMP Agents and MIB

You can use Simple Network Management Protocol (SNMP) to provide monitoring data to enterprise-wide management systems.

The following sections describe the SNMP management model and how WebLogic Server implements this model:

For more information, refer to “ Use SNMP to monitor WebLogic Server” in the Administration Console Online Help.


Overview of SNMP

With SNMP, a manager sends a request for information about managed resources to an agent. The agent gathers the requested data and returns a response. You can also configure agents to issue unsolicited reports (notifications) to managers when they detect predefined thresholds or conditions on a managed resource.

To request data about a specific managed resource, a manager must be able to uniquely identify the resource. In SNMP, each type of managed resource is described in a Management Information Base (MIB) as a managed object with a unique object identifier (OID). Individual organizations define their specific managed objects in MIB modules. Both manager and agent must have access to the same MIB module to communicate about specific managed resources.


WebLogic Server SNMP Agents

WebLogic Server SNMP agents query the WebLogic Server management system and communicate the results to managers over the SNMP protocol. The WebLogic Server management system exposes management data through a collection of managed beans (MBeans). When a WebLogic Server SNMP agent receives a request from a manager, it determines which MBean corresponds to the OID in the manager’s request. Then it retrieves the data and wraps it in an SNMP response.

You can use WebLogic Server SNMP agents to:

Organizing SNMP Agents in a Domain

In each WebLogic Server domain, you can create multiple SNMP agents and organize them into a de-centralized or centralized model for SNMP monitoring and communication:

Figure 2-1 illustrates that when you create SNMP agents on individual servers in a domain, the agents query MBeans in the host server’s Runtime MBean server. This MBean server contains only the MBeans for the individual host server.

Figure 2-1 De-Centralized Model for SNMP Monitoring and Communication

De-Centralized Model for SNMP Monitoring and Communication

Figure 2-2 illustrates that when you use the SNMP agent on the Administration Server to retrieve data for Managed Servers, the agent queries MBeans in the Domain Runtime MBean server.

Figure 2-2 Centralized Model for SNMP Monitoring and Communication

Centralized Model for SNMP Monitoring and Communication

For information on creating WebLogic Server SNMP agents, see “ Create SNMP Agents” in the Administration Console Online Help.

Domain-Scoped Agent

To support domains that were created with WebLogic Server release 9.2 and earlier, you can enable and use the domain-scoped SNMP agent instead of configuring SNMP agents on the Administration Server or Managed Servers (server SNMP agents). The domain-scoped agent offers the same features as the server SNMP agent in the centralized model described above. However, its underlying implementation is different and it will eventually be deprecated. The domain-scoped agent is overridden if you target a server SNMP agent to the Administration Server.

Configuring SNMP Protocols

A WebLogic Server SNMP agent can always communicate with managers using the SNMPv3 protocol. You can configure whether the agent also supports the SNMPv1 and SNMPv2 protocols. While you cannot prevent an agent from receiving SNMPv3 requests, an agent processes only requests from known users that you configure through the WebLogic Server security realm.

For more information, see “ Create SNMP Agents” in the Administration Console Online Help.

Configuring UDP and TCP Ports

An SNMP agent communicates through a port that accepts UDP traffic and another port that accepts TCP traffic. By default, all TCP traffic uses the host server's listen port. For example, if you target this agent to a server named ManagedServer1 and ManagedServer1 listens for requests on port 7001, then the SNMP agent listens for TCP requests on port 7001. When communicating through a TCP port, WebLogic Server protects SNMP communication from denial of service (DOS) attacks.

If you want to separate SNMP TCP traffic from business traffic, you can create a custom network channel.

For more information, see “ Create SNMP Agents” and “ Create an SNMP Network Channel” in the Administration Console Online Help.

Narrowing the Scope of a Request

When an SNMP manager sends a request to an agent on the Administration Server, the agent’s response can potentially contain data that describes multiple instances of the object. For example, the object serverUptime exists for each WebLogic Server instance in a domain. If a manager sends a request for serverUptime to an agent on an Administration Server, the response contains one serverUptime instance for each server in the domain.

You can narrow the scope of a request by encoding additional information in the manager’s request. The information that you encode depends on which SNMP protocol you use:

Monitoring SNMP Agents

For each SNMP agent in a domain, the SNMP: Monitoring tab of the WebLogic Server Administration Console provides such information as how many notifications the agent has sent to managers and how many authentication attempts have failed. See Monitor SNMP Agents in Administration Console Online Help.

You can also access this monitoring information using WebLogic Scripting Tool (WLST) or a JMX client to access the new SNMPAgentRuntimeMBean. See SNMPAgentRuntimeMBean in WebLogic Server MBean Reference. For information on using WLST, see WebLogic Scripting Tool.


Security for SNMP

The security features that are available for SNMP depend on which SNMP protocol an agent uses to communicate with managers.

Community Names for SNMPv1 and SNMPv2

To ensure that an SNMP manager requesting data from the WebLogic SNMP agent has permission to obtain the data, and to verify that the agent has permission to send notifications to a target manager, SNMPv1 and SNMPv2 use clear-text passwords called community names.

When you create an SNMP agent (described in “ Create SNMP Agents” in the Administration Console Online Help), you specify the community name that the agent expects from the SNMP manager.

Disabling SNMPv1 and SNMPv2

Because SNMPv1 and SNMPv2 use clear-text passwords, the level of security is weak. If you can use SNMPv3 to communicate with managers, consider disabling SNMPv1 and SNMPv2 by disabling community based access for each SNMP agent. For more information, see “ Create SNMP Agents” in the Administration Console Online Help.

Configuring Security for SNMPv3

In the SNMPv3 protocol, both SNMP agent and manager must encode identical credentials in their PDUs for the communication to succeed. The credentials include several tokens: a user name, an SNMP engine ID, an authorization protocol, and an optional privacy password, all of which are encrypted before being transported over the network.

In WebLogic Server, SNMP agents work with the domain's security realm to secure communication. The SNMP agent decodes SNMP credentials in requests and passes the SNMP user name to the security realm. The security realm maps the SNMP user name to a WebLogic Server user, authenticates the user, and authorizes access to monitoring data in the domain. To map the SNMP credentials to a user in a WebLogic Server security realm, you create a credential map.

For information about how to configure security for SNMPv3, see “ Secure SNMPv3 Communication” in the Administration Console Online Help.

Invalidating the SNMPv3 Credential Cache

To optimize performance, an SNMP agent caches the credential maps that correlate WebLogic Server users with SNMP credentials. To make sure that the cache contains the latest set of SNMP credentials, an agent periodically invalidates its cache. After the cache is invalidated, the next time the agent requests credentials, it regenerates its cache.

Note that making a change to the credential map does not automatically update the cache for SNMP agents. Instead, the cache is updated only after it has been invalidated. For example, if you update a privacy password in an existing entry in the SNMP credential map, SNMP agents are not aware of the new password until their caches are invalidated and regenerated. An SNMP user with the old security password can still use the agents to access WebLogic Server data until the cache is invalidated.

After you modify a credential map, you can either wait for each SNMP agent to invalidate its cache, or you can invalidate it immediately.

For information on invalidating the cache immediately, see “ Invalidate an SNMP Credentials Cache” in the Administration Console Online Help.

You can configure the frequency with which an agent invalidates its cache when you create the agent. See “ Create SNMP Agents” in the Administration Console Online Help.


MIB Module for WebLogic Server

The MIB module for WebLogic Server uses Abstract Syntax Notation.1 (ASN.1) to describe the resource types that can be monitored through SNMP and the notification types that WebLogic Server SNMP agents can send to SNMP managers.

The WebLogic Server installer creates a copy of the MIB module in the following location:

where BEA_HOME is the directory in which you install WebLogic Server. With each new release, WebLogic Server appends any new managed objects to the module. The object identifiers for existing managed objects do not change from one release to the next.

The following sections describe the WebLogic Server MIB module:

Hierarchical Data Model

WebLogic Server exposes a large number of data points in its management system. To organize this data, it provides a hierarchical data model that reflects the collection of services and resources that are available in a domain. For example, a WebLogic Server domain can contain multiple servers. Each server contains (or hosts) applications, and each application contains Web applications, EJBs, and other Java EE modules.

The WebLogic Server MIB module reflects this hierarchy. For example, a WebLogic Server domain describes its overall configuration in a tabular managed object called domainTable. This tabular object refers to (contains) a collection of scalar objects, each of which describes some attribute of the domain. For example, domainTable contains a domainServers scalar object that names all servers in the domain. The serverTable object contains a serverDeployments scalar object, which describes all applications currently deployed on a server.

Tabular objects never directly contain object instances (MIB variables). Instead, tabular objects contain scalar objects, and the scalar objects contain variables. For example, if you created two Managed Servers in a domain named MS1 and MS2, the MIB contains one serverTable object, which in turn contains a serverName object. The serverName object contains two variables that contain the value MS1 and MS2. See Figure 2-3.

Figure 2-3 Hierarchy of Objects and Object Instances

Hierarchy of Objects and Object Instances

Configuration and Runtime Hierarchies

Instead of one large hierarchy for all of its management data, the WebLogic Server management data model consists of two hierarchies: one for its configuration data and another for the performance and monitoring data that are available only at runtime. All managed objects that describe runtime data contain the word “runtime” in their name; configuration managed objects do not. For example, the MIB contains a domainTable that describes a domain’s configuration and a domainRuntimeTable that describes runtime data.

Relationship of the MIB Module to the WebLogic Server MBean Data Model

WebLogic Server provides managed beans (MBeans) as part of its implementation of Java Management Extensions (JMX). JMX is a Java EE specification for programmatic access to a Web application server’s management data, and an MBean is the representation of the management data and operations. JMX’s purpose is the same as SNMP: provide standard communication of management information between agents and managers.

At the implementation level, the WebLogic Server SNMP agent and MIB form a protocol-specific layer on top of the WebLogic Server JMX implementation. If you are already familiar with the WebLogic Server JMX implementation, you will notice similarities in the data model for WebLogic Server MBeans and the organization of managed objects in the WebLogic Server MIB. However, there are some important differences:

For more information about the WebLogic Server JMX implementation, see Understanding WebLogic Server MBeans in Developing Manageable Applications with JMX.

Object Identifiers

A MIB assigns a unique, immutable number called an object identifier (OID) to each managed object that it describes. Each OID consists of a left-to-right sequence of integers. This sequence defines the location of the object in the MIB tree and specifies a unique path through the tree to the object. Each node in the path has both a number and a name associated with it.

The path . defines the private.enterprises OID and each number beneath that node on the tree represents the branches in the tree reserved for a particular vendor, for example, BEA. The BEA MIB modules are registered at the location . in the tree, and the WebLogic Server MIB module consists of all OIDs below .

OIDs for Objects and Variables

The WebLogic Server MIB module uses OIDs to reflect its hierarchical data model. For example, the OID for the serverRuntimeTable object is . The OID for the serverRuntimeState scalar object, which is contained by the serverRuntimeTable object is .

To identify an object instance (variable), the WebLogic SNMP agent generates and appends an additional set of numbers to the object’s OID. For example, the OID for a variable of serverRuntimeState would be .

The OID is persistent across instantiations of the object.

You can use the WebLogic Server SNMP MIB Reference to see the OIDs for managed objects, and the SnmpWalk or SnmpGetNext commands to see the OIDs for any variable. For more information, see WebLogic SNMP Command-Line Utility.

Browsing the MIB

To browse the contents of the WebLogic Server MIB module:


Monitoring Custom MBeans

You can configure a WebLogic SNMP agent to maintain a runtime MIB module that contains entries for all custom MBeans that have been registered in a WebLogic Server Runtime MBean Server. A custom MBean is an MBean that you create and register (see Developing Manageable Applications with JMX). You can then use SNMP managers to request information about your custom MBeans. WebLogic Server SNMP agents cannot periodically poll values of custom MBeans and generate notifications if a value crosses a threshold. Instead, SNMP managers must send requests to WebLogic Server SNMP agents.

For information on configuring and using a WebLogic SNMP agent to monitor custom MBeans, see “ Monitor Custom MBeans” in the Administration Console Online Help.

Structure of the Custom MBean MIB Module

For each custom MBean type, WebLogic Server adds a table to the MIB module. For each instance of a custom MBean, it adds a table row. For each MBean attribute, it adds a table column.

The table names for standard MBeans are based on the name of the MBean’s implementing class; table names for model MBeans are based on the name that is supplied in the MBean’s MBeanInfo object.

In addition to tables for custom MBean types, the MBean MIB module contains two tables, federatedMBeanServerDelegateTable and mBeanServerDelegateTable. These MBeans contain information about the MBean server itself (such as the vendor name and version number).

While WebLogic Server does not persist the MIB module as a file or other data structure, the OIDs in the module remain constant across server sessions.

Listing 2-1 is an excerpt of the custom MBean MIB module from the Avitek Medical Records Application (MedRec). MedRec is an end-to-end sample Java EE application that is shipped with WebLogic Server (see Sample Application Examples and Tutorials for BEA WebLogic Server). MedRec registers two custom MBeans in the WebLogic Server Runtime MBean Server:

The MIB module in Listing 2-1 contains one table for each of MedRec’s custom MBean types, adminReportTable and recordSessionEJBMBeanImplTable. Note that the table names in the MIB (adminReportTable and recordSessionEJBMBeanImplTable) match the underlying implementation classes for AdminReportMBean and RecordSessionEJBMBean (which are standard MBeans).

Listing 2-1 MIB Module for Custom MBeans in medrec Server
    LAST-UPDATED "0701101716Z"
    ORGANIZATION "BEA Systems Inc."
    CONTACT-INFO "dev2dev@bea.com"
    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
    ::= { adminReportTable-Oid 1 }
adminReportEntry OBJECT-TYPE
    SYNTAX AdminReportEntry
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION "Generated SNMP Table Entry."
    INDEX { adminReportIndex}
    ::= { adminReportTable 1 }
AdminReportEntry ::=
    adminReportIndex OCTET STRING,
    adminReportObjectName OCTET STRING,
    adminReportNewUserCount OCTET STRING
adminReportIndex OBJECT-TYPE
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION "Index column"
    ::= { adminReportEntry 1 }
adminReportObjectName OBJECT-TYPE
    MAX-ACCESS read-only
    STATUS current
    DESCRIPTION "ObjectName column"
    ::= { adminReportEntry 2 }
adminReportNewUserCount OBJECT-TYPE
    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
    ::= { recordSessionEJBMBeanImplTable-Oid 1 }
recordSessionEJBMBeanImplEntry OBJECT-TYPE
    SYNTAX RecordSessionEJBMBeanImplEntry
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION "Generated SNMP Table Entry."
    INDEX { recordSessionEJBMBeanImplIndex}
    ::= { recordSessionEJBMBeanImplTable 1 }
RecordSessionEJBMBeanImplEntry ::=
    recordSessionEJBMBeanImplIndex OCTET STRING,
    recordSessionEJBMBeanImplObjectName OCTET STRING,
    recordSessionEJBMBeanImplTotalRx OCTET STRING
recordSessionEJBMBeanImplIndex OBJECT-TYPE
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION "Index column"
    ::= { recordSessionEJBMBeanImplEntry 1 }
recordSessionEJBMBeanImplObjectName OBJECT-TYPE
    MAX-ACCESS read-only
    STATUS current
    DESCRIPTION "ObjectName column"
    ::= { recordSessionEJBMBeanImplEntry 2 }
recordSessionEJBMBeanImplTotalRx OBJECT-TYPE
    MAX-ACCESS read-only
    STATUS current
    DESCRIPTION "Attribute exposed for management"
    ::= { recordSessionEJBMBeanImplEntry 3 }

  Back to Top       Previous  Next