WebLogic SNMP Management Guide
Simple Network Management Protocol (SNMP) enables enterprise-wide management systems to manage heterogeneous software and hardware environments from a single manager. Typically, the manager includes a user interface provided by a third-party SNMP management system. The WebLogic SNMP agent is a WebLogic Server® subsystem that gathers WebLogic management data (managed objects), converts it to SNMP communication modules (trap notifications), and forwards the trap notifications to third-party SNMP management systems. The WebLogic SNMP agent can also respond to direct requests from a manager using PDU format. The WebLogic SNMP agent supports the SNMPv1 and SNMPv2 protocols. All managed objects that WebLogic Server exposes for management through SNMP are defined in the WebLogic Server Management Information Base (MIB).
SNMP management is based on the agent-manager model described in the network management standards defined by the International Organization for Standardization (ISO). In this model, any system or network resource that is manageable through the exchange of information is a managed resource. This resource could be a software resource such as a Java Database Connectivity (JDBC) data source, or a hardware resource such as a router.
An agent gathers and sends data about managed resources in response to a request from a manager. Agents can also issue unsolicited reports to managers when they detect certain predefined thresholds or conditions on a managed resource. In SNMP terminology, these unsolicited event reports are called trap notifications.
To request and receive data from an agent, a manager relies on a database that describes the properties of managed resources and the services that the agent supports. This database is called a Management Information Base (MIB), and the properties that it describes are called managed objects. If an agent adds managed objects to its MIB, the manager must reload the corresponding MIB to discover the new objects.
Each WebLogic Server domain contains a single SNMP agent that runs on the Administration Server. The agent provides a single point of contact for an SNMP manager to get information about managed objects on all server instances in the domain. See Figure 2-1. (For more information about domains, refer to "Understanding WebLogic Server Domains" in Configuring and Managing WebLogic Server.)
To enable and configure the WebLogic SNMP agent, refer to "Configure the SNMP Agent" in the Administration Console Online Help.
The BEA WebLogic SNMP MIB uses Abstract Syntax Notation.1 (ASN.1) to describe the resources that can be monitored through SNMP and the trap notifications that its SNMP agent can send to SNMP managers.
BEA_HOME is the directory in which you install WebLogic Server. With each new release, WebLogic Server appends any new managed objects to the MIB. The object identifiers for existing managed objects do not change from one release to the next.
WebLogic Server exposes thousands 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 J2EE modules.
The WebLogic Server MIB 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. Instead, tabular objects contain scalar objects, and the scalar objects contain object instances. For example, if you created two Managed Servers in a domain named
MS2, the MIB contains one
serverTable object, which in turn contains a
serverName object. The
serverName object contains two object instances that contain the value
MS2. See Figure 2-2.
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.
WebLogic Server provides hundreds of managed beans (MBeans) as part of its implementation of Java Management Extensions (JMX). JMX is a J2EE 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:
DomainMBeanto its child
ServerMBeans, and then to the children of each
ServerMBean, and so on. The MIB, on the other hand, represents objects using unique identifiers. See Object Identifiers.
For more information about the WebLogic Server JMX implementation, see Understanding WebLogic Server MBeans in Developing Manageable Applications with JMX.
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.
.18.104.22.168.4.1 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 MIBs are registered at the location
.22.214.171.124.4.1.140 in the tree, and the WebLogic Server MIB consists of all OIDs below
The WebLogic Server MIB uses OIDs to reflect its hierarchical data model. For example, the OID for the
serverRuntimeTable object is
.126.96.36.199.188.8.131.525.360. The OID for the
serverRuntimeState scalar object, which is contained by the
serverRuntimeTable object is
To identify a specific instance of an object, the WebLogic SNMP agent generates and appends an additional set of numbers to the object's OID. For example, the OID for an instance of
serverRuntimeState would be
You can use the WebLogic Server SNMP MIB Reference to see the OIDs for managed objects, and the
snmpgetnext commands to see the OIDs for any managed object instance. For more information, refer to "WebLogic SNMP Agent Command-Line Reference" in the WebLogic Server Command Reference.
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 trap notifications to a target manager, SNMP uses textual passwords called community names.
When you set up the SNMP agent capability of the Administration Server (described in "Use SNMP to Monitor WebLogic Server" in the Administration Console Online Help), you specify the community name that the agent expects from the SNMP manager. If the agent receives an SNMP request with an incorrect community name, it generates an
authenticationFailure trap and sends it to the source of the request.
Because a WebLogic Server domain can have multiple server instances concurrently active, a request from an SNMP manager that specifies only a managed object is potentially ambiguous. For example, the object
serverUptime exists for each WebLogic Server instance in a domain.
To request a managed object on a specific Managed Server, when you send a request from an SNMP manager append the name of the server instance to the SNMP community name that it sends with the request as follows:
community_prefix is the SNMP community name and
server_name is the name of the targeted Managed Server. The
community_prefix value sent by the manager must match the value that you set in the Community Prefix field when you configure the SNMP agent.