![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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).
The following sections describe the SNMP management model and how WebLogic Server implements this model:
For more information, refer to:
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.)
You can use the WebLogic SNMP agent to:
Note: | WebLogic Server does not enable SNMP managers to set the values of managed objects or invoke management operations. SNMP managers can be used only to monitor 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.
The WebLogic Server installer creates a copy of the MIB in the following location:BEA_HOME/weblogic90/server/lib/BEA-WEBLOGIC-MIB.asn1
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 MIB. The object identifiers for existing managed objects do not change from one release to the next.
The following sections describe the WebLogic Server MIB:
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 MS1
and 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 MS1
and 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:
DomainMBean
to 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.
The path .1.3.6.1.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 .1.3.6.1.4.1.140
in the tree, and the WebLogic Server MIB consists of all OIDs below .1.3.6.1.4.1.140.625
.
The WebLogic Server MIB uses OIDs to reflect its hierarchical data model. For example, the OID for the serverRuntimeTable
object is .1.3.6.1.4.1.140.625.
360. The OID for the serverRuntimeState
scalar object, which is contained by the serverRuntimeTable
object is .1.3.6.1.4.1.140.625.
360.1.60.
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 .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.
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 managed object instance. For more information, refer to "
WebLogic SNMP Agent Command-Line Reference" in the WebLogic Server Command Reference.
To browse the contents of the WebLogic Server MIB:
Because the MIB Reference uses Javascript and DHTML to provide browsing capabilities that are similar to a MIB browser, you must use one of the following Web browsers:
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
@server_name
where 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.
To request a managed object on the Administration Server, send a community name to the WebLogic SNMP agent with the following form:community_prefix
To request a managed object for all server instances in a domain, send a community string with the following form:community_prefix
@domain_name
![]() ![]() ![]() |