Configuring the DyeInjection Monitor to Manage Diagnostic Contexts 12-3
12.1.3 Where Diagnostic Context Is Configured
Diagnostic context is configured as part of a diagnostic module. You use the DyeInjection monitor at the server level to configure the diagnostic context. The
DyeInjection monitor is a standard diagnostic monitor, so you cannot modify its behavior. The joinpoints where the DyeInjection monitor is woven into the code are
those locations where a request can enter the system.
The diagnostic action is to check every request against the DyeInjection monitors configuration, then create and attach a diagnostic context to the request, setting the
dye flags as appropriate. If the dye flags that are set for a request match the dye flags that are configured for a downstream diagnostic monitor, an event with the requests
associated Context ID is added to the Event Archive. So, for example, if a request has only the USER1 and ADDR1 dye flags set, and there is a diagnostic monitor
configured to trace requests with both the USER1 and ADDR1 flags set but no other flags set, an event is added to the Event Archive.
For information about diagnostic monitor types, pointcuts which define the joinpoints, and diagnostic actions, see
Chapter 11, Configuring Instrumentation.
12.2 Overview of the Process
This overview describes the configuration and use of context in a server-scoped diagnostic module.
1.
Configure a dye vector via the DyeInjection Module. See Section 12.3,
Configuring the Dye Vector via the DyeInjection Monitor.
2.
When any request enters the system, WLDF creates and instantiates a diagnostic context for the request. The context includes a unique Context ID and a dye vector.
3.
The DyeInjection monitor, if enabled at the server level within a WLDF diagnostic module, examines the request to see if any of the configured dye values in the dye
vector match attributes of the request. For example, it checks to see if the request originated from the user associated with USER1 or USER2, and it checks to see if
the request came from the IP address associated with ADDR1 or ADDR2.
4.
For each dye value that matches a request attribute, the DyeInjection monitor sets the associated dye bits within the diagnostic context. For example, if the
DyeInjection monitor is configured with USER1=weblogic, USER2=adminavitek.com, ADDR1=127.0.0.1, ADDR2=127.0.0.2, and the request
originated from user weblogic at IP address 127.0.0.2, it will set the USER1 and ADDR2 dye bits within the dye vector.
5.
As the request flows through the system, the diagnostic context which includes the dye vector flows with it as well. This 64-bit dye vector contains only flags, not
values. So, in this example, the dye vector contains only two flags that are explicitly set USER1 and ADDR2. It does not contain the actual user name and IP
address associated with USER1 and ADDR2.
6. The administrator configures a diagnostic monitor either application-scoped or
server-scoped to be active within downstream code, setting the monitors dye mask as USER1 and ADDR2. See
Section 12.4, Configuring Delegating Monitors to Use Dye Filtering,
for more information.
Note: All dye vectors also contain one of the implicit PROTOCOL
dyes, as explained in Section 12.3, Configuring the Dye Vector via the
DyeInjection Monitor.
12-4 Configuring and Using the Diagnostics Framework for Oracle WebLogic Server
7.
The diagnostic monitor will perform its associated actions if the dye flags that are set in the diagnostic contexts dye vector match the dye mask of the diagnostic
monitor. See Section 12.5, How Dye Masks Filter Requests to Pass to Monitors,
for more details. In this example, the monitor will perform its actions if the USER1 and ADDR2 flags are set in the dye vector. In addition, an event associated
with the request will be written to the Event Archive.
12.3 Configuring the Dye Vector via the DyeInjection Monitor
Kategori