Configuring the DyeInjection Monitor to Manage Diagnostic Contexts 12-13
but do check for the presence of the THROTTLE dye in all requests. Only those requests dyed with THROTTLE are passed to the delegating monitors for
handling. Therefore, by setting a THROTTLE_RATE andor THROTTLE_ INTERVAL in the DyeInjection monitor, you reduce the number of requests
handled by all delegating monitors. You do not have to configure dye masks for all your delegating monitors to take advantage of throttling.
■
If dye filtering for a delegating or custom monitor is enabled and the only dye set in a dye mask is THROTTLE, only those requests that are dyed with THROTTLE
are passed to the delegating monitor. This behavior is the same as when dye filtering is not enabled and THROTTLE is configured in the DyeInjection monitor.
12.7 Using weblogic.diagnostics.context
The weblogic.diagnostics.context package provides applications with limited access to a diagnostic context.
An application can use the weblogic.diagnostics.context.DiagnosticContextHelper APIs to perform the following functions:
■
Inspect a diagnostics contexts immutable context ID.
■
Inspect the settings of the dye flags in a contexts dye vector.
■
Retrieve an array of valid dye flag names.
■
Set, or unset, the DYE_0 through DYE_7 flags in a contexts dye vector. Note that there is no way to set these flag bits via XML. You can configure DyeInjection
monitor properties to set the non-application-specific flag bits via XML, but setDye is the only method for setting DYE_0 through DYE_7 in a dye vector.
■
Attach a payload a String to a diagnostic context, or read an existing payload. An application cannot:
■
Set any flags in a dye vector other than the eight flags reserved for applications.
■
Prevent another application from setting the same application flags in a dye vector. A well-behaved application can test whether a dye flag is set before setting
it.
■
Prevent another application from replacing a payload. A well-behaved application can test for the presence of a payload before adding one.
Note: The diagnostic context payload can be viewed by other code in
the same execution context; it can flow out of the process along with the Work instance; and it can be overwritten by other code running in
the same execution context. Therefore, you should ensure the following behavior in your applications:
■
Avoid including any sensitive data in the payload that, for example, could be returned by the getPayload method.
■
Do not create a dependency on any particular data being available in the context payload. For example, applications should not rely
on a particular context ID being present. If an application uses the contents of the payload, the application should first verify that the
contents match what is expected.
12-14 Configuring and Using the Diagnostics Framework for Oracle WebLogic Server
A monitor, or another application, that is downstream from the point where an application has set one or more of the DYE_0 through DYE_7 flags can set a dye mask
to check for those flags, and take an action when the flags are present in a contexts dye vector. If a payload is attached to the diagnostics context, any action taken by that
monitor will result in the payload being archived, and thus available through the accessor component.
Example 12–5 is a short example which implicitly creates a diagnostic context, prints
the context ID, checks the value of the DYE_0 flag, and then sets the DYE_0 flag.
Example 12–5 Example: DiagnosticContextExample.java
package weblogic.diagnostics.examples; import weblogic.diagnostics.context.DiagnosticContextHelper;
public class DiagnosticContextExample { public static void mainString args[] throws Exception {
System.out.println\nContextId= + DiagnosticContextHelper.getContextId;
System.out.printlnisDyedWithDYE_0= + DiagnosticContextHelper.isDyedWithDiagnosticContextHelper.DYE_0;
DiagnosticContextHelper.setDyeDiagnosticContextHelper.DYE_0, true; System.out.printlnisDyedWithDYE_0= +
DiagnosticContextHelper.isDyedWithDiagnosticContextHelper.DYE_0; }
}
13
Accessing Diagnostic Data With the Data Accessor 13-1
13
Accessing Diagnostic Data With the Data Accessor
You use the Data Accessor component of the WebLogic Diagnostics Framework WLDF to access diagnostic data from various sources, including log records, data
events, and harvested metrics.
Using the Data Accessor, you can perform data lookups by type, component, and attribute. You can perform time-based filtering and, when accessing events, filtering
by severity, source, and content. You can also access diagnostic data in tabular form.
The following sections describe the Data Accessor and describes how to use it online when a server is running and offline when a server is not running:
■
Section 13.1, Data Stores Accessed by the Data Accessor
