Introduction to the WebLogic Diagnostics Framework (WLDF)

Abstract

The WebLogic Diagnostics Framework (WLDF) gives administrators and IT managers the ability to analyze their server operating environment using a set of components that generate information from WebLogic servers and the resources, including applications, deployed on the servers. The resulting data can then be gathered for analysis, and later persisted for long-term storage. This information (usually generated by MBeans) can be used to diagnose and resolve issues, monitor and maintain a history of events, carry out performance tuning, and perform many other useful tasks for a system administrator.

The WLDF is a new addition to BEA WebLogic Server 9.0. This article provides an introduction to each components of the WebLogic Diagnostics Framework and how the components work to help you create a better WebLogic server environment.

Editor's note: Check out the related webinar, Deploying Services in BEA WebLogic Server: Explore the Power of WebLogic Diagnostic Framework

What Does WLDF Do for You?

In previous versions of WebLogic Server, you had out-of-the-box log files and various monitoring pages in the administration console you could use to track what was going on in your environment. The log files offer a lot of information but are hard to slog through. The monitoring pages were scattered about the console and didn't always have the information you were looking for. If you wanted to take it a step farther you could develop your own JMX-based monitoring tools or you could purchase a third-party product.

The new WebLogic Diagnostics Framework has enhanced the tools available for monitoring a WebLogic Server environment out of the box. WLDF falls somewhere between the old way of monitoring the environment and the fancy third-party JMX and SNMP monitoring tools. It provides the means to track specific elements in your environment, to be notified when something particular happens, to take a snapshot of the environment at a given moment, to filter log messages, and to save all the information gathered for analysis at a later date.

WLDF Components

The WebLogic Diagnostics Framework is made up of several components. The major pieces consist of:

These components work together to generate, gather, access, and persist data that will help you monitor your environment and analyze issues you may have with resources. The following sections examine these components and their place in your WebLogic environment.

Generating Data

You have two primary mechanisms for generating data for WLDF: using runtime MBeans, and using instrumentation of the server and/or application. Let's look at each of these in more detail.

MBeans as data generators

To monitor your environment, data needs to be generated by the various systems. Two main pieces in WLDF generate data that will later be collected, accessed, and archived. The primary data generators are the runtime MBeans for each part of the WebLogic server environment. Runtime MBeans exist only on the managed servers that deploy the managed resources. Each instance of the resource running on the server will have a runtime MBean, and each MBean has a set of attributes with data that can be gathered by WLDF. Runtime data held by a runtime MBean is transient; there is no persistent definition of their runtime state. When a server is stopped, all its runtime MBeans are destroyed. For more information on the different types of runtime MBeans and their attributes, see the WebLogic Server MBean Reference guide.

Instrumentation

The second way in which data is generated for WLDF is through the Instrumentation component. Instrumentation is a way to define an action that occurs when a point, usually a method, is reached in a body of code. That action can occur before the point is reached, after it has passed the point, or while that point is running, for example, while the body of a method is executing. The action that occurs when that point is reached is simply another piece of code with instructions on what to do. The benefit of instrumentation is you do not have to touch the actual business logic code to add functionality like logging and tracing. Adding this functionality is achieved outside the code and then woven into the code by a special compiler. WLDF instrumentation is based on AspectJ, the Java implementation of aspect-oriented programming. Aspect-oriented programming allows a developer to insert functionality across all parts of an application without modifying the actual application code. This is known as "crosscutting." Some common terminology in AspectJ is:

• Join point - The location in the business logic code where you want to insert added functionality.
• Pointcut - An expression that captures a set of join points and defines the weaving rules. Weaving is accomplished when the AspectJ compiler combines the business logic code and the aspect-oriented code.
• Advice - Defines what you want to happen when a join point is reached. In WLDF, advice is referred to as actions.

WLDF provides a predefined set of diagnostic actions that can occur when the defined point in the code is reached; this is how data is generated. Actions can gather method arguments or return values, trace events, the time it takes to perform a method, stack dumps, and thread dumps. At this point, you cannot create your own actions or customize the existing ones.

In WLDF, instrumentation acts as a data provider and a data publisher. Data providers are data creators that are sampled at regular intervals to gather current values. Data publishers are data creators that synchronously generate events. Both the server and an application can be instrumented. These are called "diagnostic monitors."

There are three kinds of diagnostic monitors: standard, delegating, and custom. A standard monitor performs specific, predefined diagnostic actions at specific, predefined pointcuts and locations. A delegating monitor has its scope, pointcuts, and locations hardcoded in the monitor, but you select the actions the monitor will perform. With a custom monitor you assign a name, define the pointcut and the diagnostics location the monitor will use, and then assign actions from the set of predefined diagnostic actions.

The following instrumentation deployment descriptor defines two diagnostic monitors for an application. The first monitor is a delegating monitor with a predefined pointcut, before an entity EJB method is executed, and an action that will generate a trace event. The second monitor is a custom monitor that will generate data containing the amount of time it took to execute any methods in any classes that begin with FindBy, take a string parameter, and return an Enumeration.

<instrumentation>

 <enabled>true</enabled> 

 <wldf-instrumentation-monitor> 

 <name>EJB_Before_EntityEjbMethods</name> 

 <enabled>true</enabled> 

 <action>TraceAction</action> 

 </wldf-instrumentation-monitor>



 <wldf-instrumentation-monitor> 

 <name>FindBy</name> 

 <enabled>true</enabled> 

 <action>TraceElapsedTimeAction</action> 

 <location>around</location> 

 <pointcut>

 execution(Enumeration * findBy*(java.lang.String));

 </pointcut>

 </wldf-instrumentation-monitor> 

</instrumentation>

So, as you can see, there are two main components of the diagnostics framework that focus on generating data. With the exception of custom runtime MBeans, you do not need to do anything special to runtime MBeans to have them generate data; they do it naturally. Instrumentation requires some setup, with the server-scoped instrumentation requiring less work than application-scoped instrumentation. However, you have more flexibility with application-scoped instrumentation. Your next challenge will be to decide on the means of gathering all the data that interests you.