Using SNMP to Manage WebLogic Server


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| Download Documentation \| Contact \| Glossary

\| WebLogic Server Doc Home \| WebLogic SNMP Management Guide \| Previous Topic \| Next Topic \| Contents \| Index \| View as PDF

WebLogic Server software includes the ability to communicate with enterprise-wide management systems using Simple Network Management Protocol (SNMP). The WebLogic Server SNMP capability enables you to integrate management of WebLogic Servers into an SNMP-compliant management system that gives you a single view of the various software and hardware resources of a complex, distributed system.

This section discusses the following topics:

The SNMP Agent/Manager Model

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, a network/systems manager exchanges monitoring and control information about system and network resources with distributed software processes called agents.

Any system or network resource that is manageable through the exchange of information is a managed resource. This could be a software resource such as a Java Database Connectivity (JDBC) connection pool or a hardware resource such as a router.

Agents function as "collection devices" that typically gather and send data about the managed resource in response to a request from a manager. In addition, agents often have the ability to 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.

A manager relies upon a database of definitions and information about the properties of managed resources and the services the agents support — this makes up the Management Information Base (MIB). When new agents are added to extend the management reach of a manager, the manager must be provided with a new MIB component that defines the manageable features of the resources managed through that agent. The manageable attributes of resources, as defined in an SNMP-compliant MIB, are called managed objects. Defining the heterogeneous components of an enterprise's distributed systems within a common MIB on the management station provides a unified perspective and single access point for managing system and network resources.

The SNMP Agent Role in a WebLogic Domain

An inter-related set of WebLogic Server resources managed as a unit is called a domain. A domain includes one or more WebLogic Servers, and may include WebLogic Server clusters.

Within each WebLogic domain one server is the Administration Server; other servers in the domain are Managed Servers. A typical J2EE application may include components distributed across multiple Managed Servers. The Administration Server provides the central point of control for configuring and monitoring the entire WebLogic domain. For more on WebLogic domains, see the WebLogic Server Administration Guide.

The WebLogic Administration Server also has the ability to run the SNMP Service. When the SNMP Service is enabled for a WebLogic domain, the Administration Server is functioning as the SNMP agent for that WebLogic domain.

Figure 1-1 SNMP Management of a WebLogic Domain

You can use the WebLogic SNMP agent to do the following:

Respond to simple GET requests from an SNMP manager for the current value of WebLogic attributes.
Send trap notifications to SNMP managers when the Administration Server comes up and when any Managed Server goes up or down.
Send trap notifications to SNMP managers when messages are logged in a Managed Server that satisfy criteria that you specify.
Send trap notifications to SNMP managers when a WebLogic configuration attribute that you specify has changed value.
Offload polling of WebLogic attributes to the WebLogic Administration Server using standard Java Management Extension (JMX) monitors, based on thresholds and polling intervals that you define. A trap notification is sent to the SNMP manager when the criteria you specify are satisfied.
Act as a proxy agent that passes requests from an SNMP manager to other SNMP agents (such as an Oracle database agent) on the same machine.

SNMP MIB for WebLogic

Extending the management reach of an SNMP manager to encompass a WebLogic domain requires a MIB that defines the manageable WebLogic attributes ("managed objects" in SNMP terminology) for the SNMP management system. The WebLogic MIB is defined in an SNMP-compliant file written in Abstract Syntax Notation One (ASN.1). This file is BEA-WEBLOGIC-MIB.asn1. This file is located under the following directory: WL_HOME\wlserver6.1\lib.

A MIB is based on a hierarchical relationship between managed objects. This hierarchical relationship is a tree structure, called the MIB tree or registration tree. Each managed object in the MIB is assigned a unique number called an object identifier (OID). An OID consists of a left-to-right sequence of integers. This sequence defines the location of the object in the MIB tree. By specifying a unique path through the tree to the object, the OID allows the object to be identified uniquely. Each node in the path defined in an OID 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.

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.140.625. For each manageable WebLogic attribute the WebLogic MIB defines a corresponding OID. For example, .1.3.6.1.4.1.140.625.360.1.60 is the OID for serverRuntimeState. When an SNMP manager requests the current value of a WebLogic attribute, it indicates the attribute by specifying the corresponding OID. For more information about the contents of the WebLogic MIB, see the WebLogic Server SNMP MIB Reference.

Note: The enterprise OID for the SNMP agent for WebLogic 6.1 differs from the enterprise OID for WebLogic used with the WebLogic 5.1 SNMP agent. The enterprise OID for WebLogic 6.1 is .1.3.6.1.4.140.625. The textual name of the WebLogic Server node in the registration tree is now wls.

SNMP Community Names

To ensure that the entity 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 WebLogic Administration Server (described in Setting Up the WebLogic SNMP Agent), one of the things you must specify is the community name that the agent expects from the SNMP manager. If the agent receives an SNMP request with an incorrect community name, it automatically generates an authenticationFailure trap that is sent to the source of the request.

Specifying the Target Server in Management Requests

In order to retrieve any attribute of any WebLogic Server in a domain, the SNMP manager must send the request to the Administration Server, acting as the SNMP agent for the domain. Because the same attribute, such as serverUptime, may exist on each of the WebLogic Servers, there needs to be a way to determine which WebLogic Server the manager is requesting data for.

In order to accomplish this, the target server name is appended to the SNMP password (community) as part of the community string sent with that request.

To specify a particular Managed Server, the SNMP manager sends to the WebLogic SNMP agent a community string that has the following form:

community_prefix@server_name

where community_prefix is the actual SNMP community name and server_name is the name of the target 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 (as described in Setting Up the WebLogic SNMP Agent).

To send a management request for the attributes of the Administration Server, the SNMP manager must send a community string to the WebLogic SNMP agent that has the following form:

community_prefix

where community_prefix is the actual SNMP community name. 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 (as described in Setting Up the WebLogic SNMP Agent).

If the SNMP manager sends a community string with the form

community_prefix@domain_name

the Administration Server returns the values of the specified attribute for every server in the domain.

How to Access Runtime Information

Note: Consult the vendor information for specific information on how to configure your SNMP Management system to access runtime information.

This section provides an example of how to obtain runtime information on the serverRuntimeListenAddress for an administration server (myserver) and a managed server (clusterServer1). The MIB definition for serverRuntimeListenAddress is:

 
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).bea(140).wls(625).se
rverRuntimeTable(360).serverRuntimeEntry(1).serverRuntimeListenAddress(30)

The following examples use a generic tool, snmpgetnext, to provide runtime information. snmpgetnext has the following arguments:

Argument	Description
-c communitystring	Specifies the community string sent to the WebLogic Server SNMP agent.
host	Name of the host.
OID	Object Identifier for the runtime information you wish to access.

To get the serverRuntimeListenAddress for a managed server:

 snmpgetnext  -c public@clusterServer1 localhost .1.3.6.1.4.1.140.625.360.1.30

To get the serverRuntimeListenAddress for an administration server, use one of the following methods:

 snmpgetnext  -c public@myserver      localhost  .1.3.6.1.4.1.140.625.360.1.30

 snmpgetnext  -c public               localhost  .1.3.6.1.4.1.140.625.360.1.30

 snmpgetnext                          localhost  .1.3.6.1.4.1.140.625.360.1.30

Setting Up the WebLogic SNMP Agent

To make your WebLogic domain manageable via SNMP, do the following:

Load the WebLogic MIB (the file BEA-WEBLOGIC-MIB.asn1) into the SNMP management system.
To figure out how to do this you may need to consult the vendor documentation for your SNMP management system.
Define the destinations where the WebLogic SNMP agent will send trap notifications:
- With the Administration Server running, invoke the Administration Console, if it isn't running already.
- Select SNMP—>SNMP Trap Destinations on the left panel. This invokes the SNMP Trap Destinations table.
- Select the link Create a new SNMP Trap Destination which invokes the Trap Destination configuration page.
- Fill in the Name field. This is a user-defined name of this particular destination.
- Fill in the Community field with the Community string that the target SNMP management station expects for incoming trap notifications.
- Enter the hostname or IP address of the SNMP management station in the Host field.
- Enter the Port number on which the SNMP management station expects to receive trap notifications. The default is 162.
- Click Apply to create your new SNMP trap destination table entry.
  You can create additional entries in the SNMP trap destination table if you want traps to be sent to multiple targets.
Set up the SNMP agent for the WebLogic domain.
To do this, do the following:
- With the Administration Server running, invoke the Administration Console, if it isn't running already.
- Select domain_name—>Configuration—>SNMP on the left panel (where domain_name is the name of the domain the SNMP service will manage).
- Check the Enabled box so that the agent is activated. (By default the agent is off.)
  The SNMP agent functionality is activated only if this value is set to true.
- In the SNMP Port field type the number of the port on which the SNMP manager will be sending requests. The default is 161.
- The number in the MIB Data Refresh Interval field is the interval (in seconds) at which the SNMP Service will update its cache of current WebLogic attribute values. The minimum valid value is 30 seconds.
  The SNMP Service responds to SNMP manager requests for WebLogic attribute values with the value in its cache. It does not check the managed resource itself each time it receives a management request. The MIB Data Refresh Interval is therefore the most frequent interval at which the manager can get a real update of the attribute value. If this interval is set to a very small value, this may have an adverse performance impact as the Administration Server will be doing a GET on every WebLogic attribute in the MIB at this interval.
- Set the Server Status Check Interval Factor.
  The SNMP Service automatically checks to determine if WebLogic Managed Servers are up or down. If the SNMP Service finds that a Managed Server which was up is now down, it sends a serverShutDown enterprise-specific trap to the targets defined in the SNMP Trap Destination table. A serverStart trap is sent if a server that was down is now up.
  
  The most frequent interval at which server status can be checked is the interval defined for MIB Data Refresh Interval. If you want that interval to be the same as the MIB Data Refresh Interval, enter 1 in the Server Status Check Interval Factor field. Only integer values can be used in this field. The value is multiplied times the MIB Data Refresh Interval to determine the interval at which server status is checked.
- Enter the SNMP community (password) that the manager will be using for requests sent to the WebLogic SNMP agent in the Community Prefix field. The default value is public. However, to secure access to the values of the WebLogic attributes, it is recommended that you set Community Prefix to some value other than public.
- The integer value in the Debug Level field determines whether internal messages are generated indicating what the agent code is doing. The maximum value is 3. The default is 0, which generates no debug messages.
  Click Apply to implement your changes to the SNMP agent configuration. For these changes to actually take effect, you will need to reboot the Administration Server.