Skip navigation.

Configuring and Using the WebLogic Diagnostic Framework

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Configuring Notifications

The following topics describe the types of notifications and their configuration options:

 


About the Types of Notifications

A notification is an action that is triggered when a watch rule evaluates to true. WLDF supports four types of diagnostic notifications, based on the delivery mechanism: Java Management Extensions (JMX), Java Message Service (JMS), Simple Mail Transfer Protocol (SMTP), and Simple Network Management Protocol (SNMP). You can also create a notification that generates a diagnostic image.

In the descriptor configuration file for a diagnostic module, the different types of notifications are identified by these elements:

These notification types all have <name> and <enabled> configuration options. The value of <name> is used as the value in a <notification> element for a watch, to map the watch to its corresponding notification(s). The <enabled> element, when set to true, enables that notification. In other words, the notification is fired when an associated watch evaluates to true. Other than <name> and <enabled>, each notification type is unique.

Note: Notifications are defined programmatically using weblogic.diagnostics.watch.WatchNotification

 


Configuring JMX Notifications

For each defined JMX notification, WLDF issues JMX events (notifications) whenever an associated watch is triggered. Applications can register a notification listener with the server's WLDFWatchJMXNotificationRuntimeMBeans to receive all notifications and filter the provided output.

Listing 8-1 shows an example of a JMX notification configuration.

Listing 8-1 Example Configuration for a JMX Notification

<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/diagnostics.xsd">
  <name>mywldf1</name> 
  <watch-notification>
    <!-- One or more watch configurations -->

    <jmx-notification>
      <name>myJMXNotif</name>
      <enabled>true</enabled>
    </jmx-notification>

    <!-- Other notification configurations -->

  </watch-notification>

</wldf-resource>

An example of a JMX notification is as follows:

 Notification name: myjmx called. Count= 42.

 Watch severity: Notice

 Watch time: Jul 19, 2005 3:40:38 PM EDT

 Watch ServerName: myserver

 Watch RuleType: Harvester

 Watch Rule:   ${com.bea:Name=myserver,Type=ServerRuntime//OpenSocketsCurrentCount} > 1

 Watch Name: mywatch

 Watch DomainName: mydomain

 Watch AlarmType: None

 Watch AlarmResetPeriod: 10000

 


Configuring JMS Notifications

JMS notifications are used to post messages to JMS topics and/or queues in response to the triggering of an associated watch. In the system resource configuration file, the elements <destination-jndi-name> and <connection-factory-jndi-name> define how the message is to be delivered.

Listing 8-2 shows two JMS notifications that cause JMS messages to be sent through the provided topics and queues using the specified connection factory. For this to work properly, JMS must be properly configured in the config.xml configuration file for the domain.

Listing 8-2 Example JMS Notifications

<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/diagnostics.xsd">
  <name>mywldf1</name> 
  <watch-notification>
    <!-- One or more watch configurations -->
    <jms-notification>
      <name>myJMSTopicNotif</name>
      <destination-jndi-name>MyJMSTopic</destination-jndi-name>
      <connection-factory-jndi-name>weblogic.jms.ConnectionFactory
           </connection-factory-jndi-name>
    </jms-notification>

    <jms-notification>
      <name>myJMSQueueNotif</name>
      <destination-jndi-name>MyJMSQueue</destination-jndi-name>
      <connection-factory-jndi-name>weblogic.jms.ConnectionFactory
          </connection-factory-jndi-name>
    </jms-notification>

    <!-- Other notification configurations -->

  </watch-notification>

</wldf-resource>

The content of the notification message gives details of the watch and notification.

 


Configuring SNMP Notifications

SNMP notifications are used to post SNMP traps in response to the triggering of an associated watch. To define an SNMP notification you only have to provide a notification name, as shown in Listing 8-3. Generated traps contain the names of both the watch and notification that caused the trap to be generated. For an SNMP trap to work properly, SNMP must be properly configured in the config.xml configuration file for the domain.

Listing 8-3 An Example Configuration for an SNMP Notification

<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/diagnostics.xsd">
  <name>mywldf1</name> 
  <watch-notification>
    <!-- One or more watch configurations -->
    <snmp-notification>
      <name>mySNMPNotif</name>
    </snmp-notification>

    <!-- Other notification configurations -->

  </watch-notification>

</wldf-resource>

The trap resulting from the SNMP notification configuration shown in Listing 8-3 is of type 85. It contains the following values (configured values are shown in angle brackets "<>"):

    .1.3.6.1.4.1.140.625.100.5   timestamp (e.g. Dec 9, 2004 6:46:37 PM
                                            EST)
    .1.3.6.1.4.1.140.625.100.145 domainName (e.g. mydomain")
    .1.3.6.1.4.1.140.625.100.10 serverName (e.g. myserver)
    .1.3.6.1.4.1.140.625.100.120 <severity> (e.g. Notice)
    .1.3.6.1.4.1.140.625.100.105 <name> [of watch] (e.g.
          simpleWebLogicMBeanWatchRepeatingAfterWait)
    .1.3.6.1.4.1.140.625.100.110 <rule-type> (e.g. HarvesterRule)
    .1.3.6.1.4.1.140.625.100.115 <rule-expression>
    .1.3.6.1.4.1.140.625.100.125 values which caused rule to
        fire (e.g..State =
        null,weblogic.management.runtime.WLDFHarvesterRuntimeMBean.
        TotalSamplingTime = 886,.Enabled =
        null,weblogic.management.runtime.ServerRuntimeMBean.
    OpenSocketsCurrentCount = 1,)
    .1.3.6.1.4.1.140.625.100.130 <alarm-type> (e.g. None)
    .1.3.6.1.4.1.140.625.100.135 <alarm-reset-period> (e.g. 10000)
    .1.3.6.1.4.1.140.625.100.140 <name> [of notification]
                                   (e.g.mySNMPNotif)

 


Configuring SMTP Notifications

SMTP notifications are used to send messages (e-mail) over the SMTP protocol in response to the triggering of an associated watch. To define an SMTP notification, you must provide the configured SMTP session using sub-element <mail-session-jndi-name>, and provide a list of at least one recipient using sub-element <recipients>. An optional subject and/or body can be provided using sub-elements <subject> and <body> respectively. If these are not provided, they will be defaulted.

Listing 8-4 shows an SMTP notification that causes an SMTP (e-mail) message to be distributed through the configured SMTP session, to the configured recipients. For this to work properly, the SMTP session must be properly configured in the config.xml configuration file for the domain.

In this notification configuration, a custom subject and body are provided. If a subject and/or a body are not specified, defaults are provided, showing details of the watch and notification.

Listing 8-4 Example Configuration for SMTP Notification

<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/diagnostics.xsd">
  <name>mywldf1</name> 
  <watch-notification>
    <!-- One or more watch configurations -->
    <smtp-notification>
      <name>mySMTPNotif</name>
      <mail-session-jndi-name>MyMailSession</mail-session-jndi-name>
      <subject>Critical Problem!</subject>
      <body>A system issue occurred. Call Winston ASAP.
           Reference number 81767366662AG-USA23.</body>
      <recipients>administrator@myCompany.com</recipients>
    </smtp-notification>

    <!-- Other notification configurations -->

  </watch-notification>

</wldf-resource>

The content of the notification message gives details of the watch and notification.

 


Configuring Image Notifications

Image notifications are used to cause a diagnostic image to be generated in response to the triggering of an associated watch. The user provides a single piece of information, the directory into which the image is to be placed, relative to the server's root directory. The relative directory name is specified in the configuration file using the sub-element <image-directory>.

Listing 8-5 shows an image notification that causes an image file of a standard name to be generated into the provided directory.

Listing 8-5 Example Configuration for Image Notification

<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/diagnostics.xsd">
  <name>mywldf1</name> 
  <watch-notification>
    <!-- One or more watch configurations -->
    <image-notification>
      <name>myImageNotif</name>
      <enabled>true</enabled>
      <image-lockout>2</image-lockout>
      <image-directory>images</image-directory>
    </image-notification>

    <!-- Other notification configurations -->

  </watch-notification>

</wldf-resource>

The directory name specified is relative to the servers root directory for the domain. For example, in this case, image files will be generated into DOMAIN_NAME\servers\SERVER_NAME, where DOMAIN_NAME is the name of the domain's home directory and SERVER_NAME is the name of the server. The default directory is DOMAIN_NAME\servers\SERVER_NAME\logs\diagnostic-images.

You can specify a lockout, or timeout, period, to control how often an image is taken during a sequence of server failures and recoveries

Image file names are generated using the current timestamp (e.g. diagnostic_image_myserver_2005_08_09_13_40_34.zip), so this notification can fire many times, resulting in a separate image file each time.

For more information about Diagnostic Images, see Configuring and Capturing Diagnostic Images.

 


 

Skip navigation bar  Back to Top Previous Next