Understanding WebLogic Server Trap Notifications

You can configure the WebLogic SNMP agent to detect certain thresholds or conditions within a managed resource and send a report (trap notification) to one or more SNMP managers. The WebLogic SNMP agent can generate traps that conform to the SNMPv1 or SNMPv2 protocols.

The following sections describe the trap notifications that the WebLogic SNMP agent can generate:

To configure or delete WebLogic Server trap notifications, refer to " Use SNMP to monitor WebLogic Server" in the Administration Console Online Help.

Format of WebLogic Trap Notifications

The WebLogic SNMP agent sends each trap notification to SNMP managers in the form of a protocol data unit (PDU) that contains the fields shown in Figure 3-1.

PDU type— Identifies the packet as a trap notification.
enterprise — Contains .1.3.6.1.4.140.625, which indicates the trap is generated by the WebLogic SNMP agent.
agent address — IP address of the Administration Server. (All traps are generated and sent from the Administration Server even if an event occurs on a Managed Server.)
generic trap type — Contains an integer in the range of 0 to 6. Table 3-1 lists the values that the different types of WebLogic SNMP traps supply for the generic trap type field.

Table 3-1 Values for the Generic Trap Type Field
`generic trap type` Value	Generated When
0	The Administration Server starts. This is called a `coldStart` trap.
4	An SNMP manager sends an incorrect community string. The community string prefix is the actual password and must match the value that you set in the Community Prefix field of the Administration Console. (See Community Names for WebLogic Server.) This is called an `authenticationFailure` trap.
6	All other WebLogic SNMP traps.

Traps with a generic trap value of 6 are called enterpriseSpecific traps and are accompanied by a value in the specific trap type field.

specific trap type — Number that further qualifies an enterpriseSpecific trap. Table 3-2 lists the values that the different types of WebLogic SNMP traps supply for the specific trap type field.

Table 3-2 Values for the Specific Trap Type Field
`specific trap type` Value	Generated When
60	A server instance logs a message that matches user-defined criteria for sending a log notification trap.
65	A Managed Server that was down is now up. This is called a `serverStart` trap.
70	A Managed Server that was up is now down. This is called a `serverShutDown` trap.
75	A user-defined JMX monitor detects the crossing of a threshold or occurrence of an event.
80	An attribute selected by the user has changed in value.

timestamp — Length of time between the last re-initialization of the WebLogic SNMP agent and the time at which the trap was issued.
variable bindings — Consists of name-value pairs that further describe the trap notification. Later sections describe the name-value pairs for each type of trap notification:

Automatically Generated WebLogic SNMP Traps

If you enable the SNMP service for a domain, the WebLogic SNMP agent automatically generates the trap notifications described in Table 3-3. Some of these traps include name-value pairs in the PDU to further describe the event.

Table 3-3 Automatically Generated Trap Notifications
Trap	Generated When	Variable Bindings
`coldStart`	The Administration Server starts.	none
`authenticationFailure`	An SNMP manager sends an incorrect community string. The community string prefix is the actual password and must match the value that you set in the Community Prefix field of the Administration Console. (See Community Names for WebLogic Server.)	none
`serverStart`	A Managed Server that was down is now up.	Contains two name-value pairs to identify server start time and the server name.
`serverShutDown`	A Managed Server that was up is now down.	Contains two name-value pairs to identify server down time and the server name.

Log Message Traps

Subsystems and deployable modules (such as applications) on a WebLogic Server instance generate log messages to communicate status or other operational data.

Each server instance saves these messages in a local log file and then broadcasts them as JMX notifications. You can set up the WebLogic SNMP agent to listen for all of these messages, or you can set up a filter based on criteria such as:

Message severity level
Name of the subsystem that generated the message
User ID under which the subsystem is running
Unique message ID
String within the message text

For example, you can specify that only messages from the Security Service of severity level ERROR or higher are sent to the SNMP agent. For information on setting up the SNMP agent to listen for messages, refer to " Create SNMP Log Filters" in the Administration Console Online Help.

When the agent receives a message, it generates an SNMP log notification trap. (See Figure 3-2.)

Variable Bindings in Log Message Traps

This section describes the name-value pairs that the log message traps pass to the SNMP manager in the variable bindings field:

trapTime — Time the trap is generated.
trapServerName — Name of the server instance on which the log message was generated.
trapMachineName — Name of the machine on which the server instance is running.
trapLogThreadId — Thread ID from the log message.
trapLogTransactionId — Transaction ID, if any, from the log message. Transaction ID is present only for messages logged within the context of a transaction.
trapLogUserId — User ID from the log message. The user ID indicates the security context in which the log message was generated.
trapLogSubsystem — Subsystem that generated the log message.
trapLogMsgId — Log message ID from the log message.
trapLogSeverity — Message severity level from the log message.
trapLogMessage — Text of the log message.

For more information on log messages and the WebLogic Server logging subsystem, refer to " Understanding WebLogic Logging Services" in Configuring Log Files and Filtering Log Messages.

Monitor Traps

To periodically check the value of WebLogic resources for changes, you set up JMX monitors and configure the SNMP agent to listen for notifications from these monitors.

JMX is a J2EE specification for exposing management data; it is the foundation for the WebLogic Server management system. In the JMX specification, management data and operations are made public through managed beans (MBeans). The managed objects in the WebLogic Server MIB correspond to MBeans and MBean attributes. See Relationship of the MIB to the WebLogic Server MBean Data Model.

JMX monitors poll the WebLogic Server MBeans that are represented in the MIB at a specified interval and send notifications to the WebLogic SNMP agent when an event that you specify occurs, such as the crossing of a threshold. The SNMP agent generates a trap notification and sends it to the SNMP managers. (See Figure 3-3.)

You can configure three types of JMX monitors, depending on the data type of the attribute that you want to observe (the WebLogic Server MBean Reference describes the type of data that an attribute returns):

Variable Bindings in Monitor Traps

A JMX monitor polls for a specified threshold or condition and the agent generates a monitor trap when the specified threshold is crossed, or the specified condition occurs. The WebLogic SNMP agent includes the following name-value pairs in the variable bindings of each monitor trap:

trapTime — Time at which the trap was generated.
trapServerName — Local server whose attribute value generated the trap.
trapMonitorType — Either CounterMonitor, StringMonitor, or GaugeMonitor.
trapMonitorThreshold — ASCII representation of the threshold that triggered the trap.
trapMonitorValue — ASCII representation of the value that triggered the trap.
trapMBeanName — Name of the MBean that contained the attribute being monitored.
trapMBeanType — Type of the MBean that contained the attribute being monitored.
trapAttributeName — Name of the attribute whose value triggered the trap.

Attribute Change Traps

While you can use JMX monitors to periodically poll WebLogic Server resources for changes to attributes that exceed the bounds of specific thresholds, you can also configure the SNMP agent to send a trap immediately after an attribute is changed in any way. For example, you can use a JMX monitor to poll for changes in the current number of active JDBC connections. If the number of active connections exceeds a threshold, the SNMP agent can send a trap. You would use an attribute change trap to detect whether an attribute such as the name of a JDBC data source or the server's listen port has been changed.

For information on configuring the SNMP agent to send attribute change traps, refer to " Create attribute changes" in the Administration Console Online Help.

Variable Bindings in Attribute Change Traps

An attribute change trap notification includes the following name-value pairs in the variable bindings:

trapTime — The time at which the trap was generated.
trapServerName — The name of the Administration Server.
trapMBeanName — Name of the MBean that includes the attribute.
trapMBeanType — Type of the MBean that includes the attribute.
trapAttributeName — Name of the configuration attribute that has changed.
trapAttributeChangeType — The value can be either ADD, REMOVE, or UPDATE.
trapAttriruteOldVal — Value of the attribute before the change.
trapAttributeNewVal — Value of the attribute after the change.

WebLogic SNMP Management Guide