The WebLogic Diagnostics Framework (WLDF) provides the WLDF query language for creating policy expressions.
Note:
The WLDF query language is deprecated in WebLogic Server as of version 12.2.1. Oracle recommends using Java Expression Language (EL) instead. Diagnostic system modules containing policy expressions that use the WLDF query language are supported for backward compatibility. For information about using Java EL in policy expressions, see Configuring Policies.WLDF supports policies that you can configure within the context of using the WLDF query language.
WLDF provides three main types of policies, based on what the policy can monitor:
Harvester policies monitor the set of harvestable MBeans in the local runtime MBean server.
Log policies monitor the set of messages generated into the server or domain logs.
Instrumentation (or Event Data) policies monitor the set of events generated by the WLDF Instrumentation component.
In the WLDF system resource configuration file for a diagnostic module, each type of policy is defined in a <rule-type> element, which is a child of <watch>. For example:
<watch> <rule-type>Harvester</rule-type> <!-- Other configuration elements --> </watch>
Policies with different rule types differ in two ways:
The rule syntax for specifying the conditions being monitored are unique to the type.
Log and instrumentation policies are triggered in real time, whereas Harvester policies are triggered only after the current harvest cycle completes.
WLDF provides several tool options for configuring policies.
For information about policy configuration options, see How Policies Are Configured.
WLDF provides three main types of Harvester policies that can be configured with WLDF query language-based expressions. Each policy type is based on what the policy can monitor.
Note:
If you define a policy to monitor an MBean (or MBean attributes) that the Harvester is not configured to harvest, the policy will work. The Harvester will implicitly harvest values to satisfy the requirements set in the defined policy expressions. However, data harvested in this way (that is, implicitly for a policy) is not archived. See Configuring the Harvester for Metric Collection.Harvester policies are triggered in response to a harvest cycle. So, for Harvester policies, the Harvester sample period defines a time interval between when a situation is identified and when it can be reported though an action. On average, the delay is SamplePeriod/2.
Example G-1 shows a configuration example of a Harvester policy that monitors several runtime MBeans. When the policy expression (defined in the <rule-expression> element) evaluates to true, six different actions are executed to generate the following: a JMX notification, an SMTP notification, an SNMP notification, an image action, and JMS notifications for both a topic and a queue.
The policy is a logical expression composed of four Harvester variables. The expression has the form:
( (A >= 100) AND (B > 0) ) OR C OR D.equals("active")
Each variable is of the form:
{entityName}//{attributeName}
In the preceding syntax, {entityName} is the JMX ObjectName as registered in the runtime MBean server or the type name as defined by the Harvester, and {attributeName} is the name of an attribute defined on that MBean type.
Note:
The comparison operators are qualified in order to be valid in XML.Example G-1 Sample Harvester Policy Configuration (in DIAG_MODULE.xml)
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<harvester>
<!-- Harvesting does not have to be configured and enabled for harvester
policies. However, configuring the Harvester can provide advantages;
for example the data will be archived. -->
<harvested-type>
<name>myMBeans.MySimpleStandard</name>
<harvested-instance>myCustomDomain:Name=myCustomMBean1
</harvested-instance>
<harvested-instance>myCustomDomain:Name=myCustomMBean2
</harvested-instance>
</harvested-type>
<!-- Other Harvester configuration elements -->
</harvester>
<watch-notification>
<watch>
<name>simpleWebLogicMBeanWatchRepeatingAfterWait</name>
<enabled>true</enabled>
<rule-type>Harvester</rule-type>
<rule-expression>
(${mydomain:Name=WLDFHarvesterRuntime,ServerRuntime=myserver,Type=
WLDFHarvesterRuntime,WLDFRuntime=WLDFRuntime//TotalSamplingTime}
>= 100
AND
${mydomain:Name=myserver,Type=
ServerRuntime//OpenSocketsCurrentCount} > 0)
OR
${mydomain:Name=WLDFWatchNotificationRuntime,ServerRuntime=
myserver,Type=WLDFWatchNotificationRuntime,
WLDFRuntime=WLDFRuntime//Enabled} = true
OR
${myCustomDomain:Name=myCustomMBean3//State} =
'active')
</rule-expression>
<severity>Warning</severity>
<alarm-type>AutomaticReset</alarm-type>
<alarm-reset-period>10000</alarm-reset-period>
<notification>myJMXNotif,myImageNotif,
myJMSTopicNotif,myJMSQueueNotif,mySNMPNotif,
mySMTPNotif</notification>
</watch>
<!-- Other policy-action configuration elements -->
</watch-notification>
</wldf-resource>
This policy uses an alarm type of AutomaticReset, which means that it may be triggered repeatedly, provided that the last time it was triggered was longer than the interval set as the alarm reset period (in this case 10000 milliseconds).
The severity level provided, Warning, has no effect on the triggering of the policy, but will be passed on through the actions.
Use log policies to monitor the occurrence of specific messages or strings in the server or domain log. Policies of this type are triggered as a result of a log message containing the specified data being issued.
The following example shows the configuration, in DIAG_MODULE.xml, for a server log policy:
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<enabled>true</enabled>
<log-watch-severity>Info</log-watch-severity>
<watch>
<name>myLogWatch</name>
<rule-type>Log</rule-type>
<rule-expression>MSGID='BEA-000360'</rule-expression>
<severity>Info</severity>
<notification>myMailNotif2</notification>
</watch>
<smtp-notification>
<name>myMailNotif2</name>
<enabled>true</enabled>
<mail-session-jndi-name>myMailSession</mail-session-jndi-name>
<subject>This is a log alert</subject>
<recipient>username@emailservice.com</recipient>
</smtp-notification>
</watch-notification>
</wldf-resource>
In the preceding example, note how the <rule-type> of Log causes messages or strings entered in the server log to be monitored. A <rule-type> of DomainLog monitors messages or strings in the domain log.
You use instrumentation policies to monitor the events from the WLDF Instrumentation component. Policies of this type are triggered as a result of the event being posted.
The following example shows the configuration, in DIAG_MODULE.xml, for an instrumentation policy:
<watch-notification>
<watch>
<name>myInstWatch</name>
<enabled>true</enabled>
<rule-type>EventData</rule-type>
<rule-expression>
(PAYLOAD > 100000000) AND (MONITOR = 'Servlet_Around_Service')
</rule-expression>
<alarm-type xsi:nil="true"></alarm-type>
<notification>mySMTPNotification</notification>
</watch>
<smtp-notification>
<name>mySMTPNotification</name>
<enabled>true</enabled>
<mail-session-jndi-name>myMailSession</mail-session-jndi-name>
<subject xsi:nil="true"></subject>
<body xsi:nil="true"></body>
<recipient>username@emailservice.com</recipient>
</smtp-notification>
</watch-notification>