2 Overview of the WLDF Architecture
The WebLogic Diagnostics Framework (WLDF) consists of a number of components that work together to collect, archive, and access diagnostic information about a WebLogic Server instance and the applications it hosts. This section provides an architectural overview of those components.
Note:
Concepts are presented in this section in a way to help you understand how WLDF works. Some of this differs from the way WLDF is surfaced in its configuration and runtime APIs and in the WebLogic Server Administration Console. If you want to start configuring and using WLDF right away, you can safely skip this discussion and start with Chapter 4, "Understanding WLDF Configuration."The WLDF architecture is described in the following sections:
Overview of the WebLogic Diagnostics Framework
WLDF consists of the following:
-
Data creators (data publishers and data providers that are distributed across WLDF components)
-
Data collectors (the Logger and the Harvester components)
-
Archive component
-
Accessor component
-
Instrumentation component
-
Watch and Notification component
-
Image Capture component
-
Monitoring Dashboard
Data creators generate diagnostic data that is consumed by the Logger and the Harvester. Those components coordinate with the Archive to persist the data, and they coordinate with the Watch and Notification subsystem to provide automated monitoring. The Accessor interacts with the Logger and the Harvester to expose current diagnostic data and with the Archive to present historical data. The Image Capture facility provides the means for capturing a diagnostic snapshot of a key server state. The relationship among these components is shown in Figure 2-1.
All of the framework components operate at the server level and are only aware of server scope. All the components exist entirely within the server process and participate in the standard server lifecycle. All artifacts of the framework are configured and stored on a per server basis.
Data Creation, Collection, and Instrumentation
Diagnostic data is collected from a number of sources. These sources can be logically classified as either data providers, data creators that are sampled at regular intervals to harvest current values, or data publishers, data creators that synchronously generate events. Data providers and data publishers are distributed across components, and the generated data can be collected by the Logger and/or by the Harvester, as shown in Figure 2-2, and explained below.
Figure 2-2 Relationship of Data Creation Components to Data Collection Components
Description of "Figure 2-2 Relationship of Data Creation Components to Data Collection Components"
Invocations of the server logging infrastructure serve as inline data publishers, and the generated data is collected as events. (The logging infrastructure can be invoked through the catalog infrastructure, the debugging model, or directly through the Logger.)
The Instrumentation component creates monitors and inserts them at well-defined points in the flow of execution. These monitors publish data directly to the Archive.
Components registered with the MBean Server may also make themselves known as data providers by registering with the Harvester. Collected data is then exposed to both the Watch and Notification system for automated monitoring and to the Archive for persistence.
Archive
The past state is often critical in diagnosing faults in a system. This requires that the state be captured and archived for future access, creating a historical archive. In WLDF, the Archive meets this need with several persistence components. Both events and harvested metrics can be persisted and made available for historical review.
Traditional logging information, which is human readable and intended for inclusion in the server log, is persisted through the standard logging appenders. New event data that is intended for system consumption is persisted into an event store using an event archiver. Metric data is persisted into a data store using a data archiver. The relationship of the Archive to the Logger and the Harvester is shown in Figure 2-3.
The Archive provides access interfaces so that the Accessor may expose any of the persisted historical data.
Figure 2-3 Relationship of the Archive to the Logger and the Harvester
Description of "Figure 2-3 Relationship of the Archive to the Logger and the Harvester"
Watch and Notification
The Watch and Notification system can be used to create automated monitors that observe specific diagnostic states and send notifications based on configured rules.
A watch rule can monitor log data, event data from the Instrumentation component, or metric data from a data provider that is harvested by the Harvester. The Watch Manager is capable of managing watches that are composed of a number of watch rules. These relationships are shown in Figure 2-4.
Figure 2-4 Relationship of the Logger and the Harvester to the Watch and Notification System
Description of "Figure 2-4 Relationship of the Logger and the Harvester to the Watch and Notification System"
One or more notifications can be configured for use by a watch. By default, every watch logs an event in the server log. SMTP, SNMP, JMX, and JMS notifications are also supported.
Data Accessor
The Accessor provides access to all the data collected by WLDF, including log, event, and metric data. The Accessor interacts with the Archive to get historical data including logged event data and persisted metrics.
When accessing data in a running server, a JMX-based access service is used. The Accessor provides for data lookup by type, by component, and by attribute. It permits time-based filtering and, in the case of events, filtering by severity, source and content.
Tools may need to access data that was persisted by a currently inactive server. In this case, an offline Accessor is also provided. You can use it to export archived data to an XML file for later access. To use the Accessor in this way, you must use the WebLogic Scripting Tool (WLST) and must have physical access to the machine.
The relationship of the Accessor to the Harvester and the Archive is shown in Figure 2-5.
Figure 2-5 Relationship of the Online and Offline Accessors to the Archive
Description of "Figure 2-5 Relationship of the Online and Offline Accessors to the Archive"
Monitoring Dashboard and Request Performance Pages
WLDF provides two web pages from which diagnostic data is displayed visually:
Monitoring Dashboard
The Monitoring Dashboard displays the current and historical operating state of WebLogic Server and hosted applications by providing visualizations of metric runtime MBean attributes, which surface some of the more critical run-time performance metrics and the change in those metrics over time. Historical operating state is represented by collected metrics that have been persisted into the Archive. To view collected metrics from the Archive, you must configure the Harvester to capture the data you want to monitor.
The Monitoring Dashboard displays metric information in a series of views. A view is a collection of one or more charts that display metrics. The Monitoring Dashboard includes a predefined set of built-in views of available run-time metrics for all running WebLogic Server instances in the domain. Built-in views surface some of the more critical run-time WebLogic Server performance metrics and serve as examples of the Monitoring Dashboard's graphic capabilities.
Custom views are available only to the user who creates them. Custom views are automatically persisted and can be accessed again when you restart the Monitoring Dashboard sessions.
For more information, see Chapter 15, "Using the Monitoring Dashboard."
Diagnostics Request Performance Page
The Diagnostics Request Performance page of the WebLogic Server Administration Console shows real-time and historical views of method performance information that is captured using the Instrumentation component. To view request performance information, you must first configure the Instrumentation component to make that data available.
For more information, see Creating Request Performance Data.
Diagnostic Image Capture
Diagnostic Image Capture support gathers the most common sources of the key server state used in diagnosing problems. It packages that state into a single artifact which can be made available to support technicians, as shown in Figure 2-6. The diagnostic image is in essence a diagnostic snapshot or dump from the server, analogous to a UNIX "core" dump.
If WebLogic Server is configured with Oracle JRockit, and JRockit Flight Recorder is not disabled, the diagnostic image capture includes all available JRockit Flight Recorder data from all producers. Furthermore, if WLDF is configured to generate WebLogic Server diagnostic information captured by JRockit Flight Recorder, the JFR file includes that information as well. The JFR file can be extracted from the diagnostic image capture and viewed in JRockit Mission Control. See Chapter 3, "Using WLDF with Oracle JRockit Flight Recorder."
Image Capture support includes:
-
On-demand capture, which is the creation of a diagnostic image capture by means of an operation or command issued from the WebLogic Server Administration Console, WLST script, or JMX application
-
Image notification, which is automatically creating a diagnostic image capture in response to the triggering of an associated Harvester watch, Log watch, or Instrumentation watch rule. For example, a Harvester watch that monitors runtime MBean attributes in a running server can trigger an image notification if the metrics harvested from specific runtime MBean instances indicate a performance issue. Data in the diagnostic image capture can be analyzed to determine the likely causes of the issue.
For more information, see:
How It All Fits Together
Figure 2-7 shows how all the parts of WLDF fit together.
Figure 2-7 Overall View of the WebLogic Diagnostics Framework
Description of "Figure 2-7 Overall View of the WebLogic Diagnostics Framework"