| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic SNMP Management Guide > Using SNMP to Manage WebLogic Server |
|
WebLogic SNMP Management Guide
|
Using SNMP to Manage WebLogic Server
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:
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. (See Figure 1-1.)
For information on enabling and configuring the WebLogic SNMP Service, refer to "Setting Up the WebLogic SNMP Agent" in the Administration Console Online Help.
Figure 1-1 SNMP Management of a WebLogic Domain
You can use the WebLogic SNMP agent to do the following:
WebLogic Server Managed Resources and MBeans
Resources on WebLogic Server instances use Java Management Extensions (JMX) Managed Beans (MBeans) to expose their management functions. An MBean is a concrete Java class that is developed per JMX specifications. It can provide getter and setter operations for each management attribute within a managed resource along with additional management operations that the resource makes available.
When you configure the WebLogic SNMP agent to collect information from managed resources, you must specify the name of the MBean and MBean attribute from which you want to collect data.
WebLogic Server MBeans that expose the configuration data of a managed resource are called Configuration MBeans while MBeans that provide performance metrics and other information about the runtime state of a managed resource are called Runtime MBeans. For example, a ServerMBean Configuration MBean indicates the listen port for a server instance while the ServerRuntimeMBean Runtime MBean indicates the current lifecycle state of a server instance.
Each WebLogic Server instance hosts its own set of Runtime MBeans to report its performance metrics and runtime state.
However, to support the WebLogic Server model of centralizing management responsibilities onto the Administration Server, the Administration Server hosts Configuration MBeans for all managed resources on all server instances in the domain. In addition, each server instance hosts a local replica of its Configuration MBean that is on the Administration Server. The Configuration MBeans on the Administration Server are called Administration MBeans, and the replicas on the Managed Servers are called Local Configuration MBeans. (See Figure 1-2.)
This distribution of Configuration MBeans creates one centralized point of management for all server instances in the domain while maximizing performance.
Figure 1-2 Distribution of MBeans
Note that managed resources on server instances use the Local Configuration MBean replicas instead of initiating remote calls to the Administration Server. Because it is possible to override the configuration of an Administration MBean and directly set a value in a Local Configuration MBean, it is possible that an Administration MBean does not report the attribute value that a local managed resource is currently using. For example, assume that ManagedServerA is configured to use a listen port of 7001. Through the weblogic.Server startup command, a JMX API, or the weblogic.Admin utility, you temporarily set the listen port value for an of ManagedServerA to 8001. The Administration MBean will report a listen port of 7001, but the Local Configuration MBean will correctly report the currently used value of 8001.
For more information about MBeans on WebLogic Server, refer to the following:
Documentation for Configuration MBean APIs
To view the documentation for Configuration MBeans, do the following:
The right pane displays the package summary. (See Figure 1-3.)
Figure 1-3 Javadoc for the configuration Package
Documentation for Runtime MBean APIs
To view the documentation for Runtime MBeans, do the following:
The right pane displays the package summary. (See Figure 1-4.)
Figure 1-4 Javadoc for the runtime Package
The WebLogic Server MIB assigns a unique number called an object identifier (OID) to its MBean attributes. Each MBean attribute in the MIB is an SNMP managed object and is manageable by an SNMP management system.
The MIB creates a hierarchical relationship between managed objects and expresses the hierarchy in a tree structure, called the MIB tree or registration tree. Each OID in the MIB 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 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.
The MIB is located in a file named WL_HOME\server\lib\BEA-WEBLOGIC-MIB.asn1. For more information about the contents of the WebLogic MIB, refer to 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.
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" in the Administration Console Online Help), 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" in the Administration Console Online Help).
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" in the Administration Console Online Help).
If the SNMP manager sends a community string with the form
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).serverRuntimeTable(360).serverRuntimeEntry(1)
.serverRuntimeListenAddress(30)
The following examples use a generic tool, snmpgetnext, to provide runtime information. snmpgetnext has the following arguments:
Specifies the community string sent to the WebLogic Server SNMP agent. 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
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
