Mining WebLogic Diagnostic Data with XSLT

by Philip Aston
09/19/2007

Abstract

The WebLogic Diagnostic Framework (WLDF) is a powerful subsystem that was introduced in BEA WebLogic Server 9.0. Using WLDF, you can monitor and record pretty much anything you want to about the behavior of a running WebLogic Server domain.

The standard tools can be used to extract harvested data and events from the diagnostic archive but provide little to allow you to build a composite picture from that data.

In this tutorial, I will show how to use XSLT to reformat diagnostic data and generate hierarchical HTML reports from the WLDF diagnostic data.

Introduction

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. See Introduction to the WebLogic Diagnostics Framework by Rebecca Sly (Dev2Dev, 2006) for a good introduction to WLDF.

Unfortunately, the standard tools distributed with WLDF provide little to allow you to build a composite picture from the harvested data. This tutorial changes that! I'm going to show you how to perform a number of useful transformations to these data:

• Reformat diagnostic data as a comma-separated value file so it can be easily imported into spreadsheet tools.
• Recombine raw event data into a hierarchical structure and present that data as an HTML report. In conjunction with the WLDF diagnostic context, this can be used to show the flow of events across multiple WebLogic Server instances.

The techniques I present are generally applicable to any system based on WebLogic Server 9.0 or later.

Prerequisites

This article is for advanced WebLogic users. I will not cover the complete whys and wherefores of the WebLogic Diagnostic Framework. For that, please refer to the following:

Equally, this is not a tutorial on XSLT, which can be a mind bender but shouldn't put you off. You can use the scripts I provide without needing to understand every detail of how they work.

Process Overview

I'll use a number of stylesheets to process the diagnostic data. Although each processing step is conceptually simple, you may find Figure 1 helps you understand the overall process.

As Figure 1 shows, WebLogic Server stores collected metrics and event data in its diagnostic archive. WLST can then be used to export the data into XML files; I've exported event data to events.xml and collected metrics (also known as harvested data) to harvest.xsl. This tutorial provides stylesheets that convert this exported data to comma-separated value (CSV) format ( exportToCSV.xsl) to merge two exported data files into one ( merge.xsl), to build up an XML file that is structured according to the event tree ( eventsToTree.xsl), and to produce an HTML report from the event tree ( treeToHTML.xsl).

Okay, let's get on with it.

First Step: Instrument Your System

First, configure WLDF to instrument your application code to produce event data and to regularly harvest metric data from interesting MBeans. As shown in Figure 2, WebLogic Server will store this information in its diagnostic archive.

The following sections show how to do this.

Add a weblogic-diagnostics.xml file to your application

To specify the instrumentation, add a weblogic-diagnostics.xml file to the META-INF directory of your application. Make sure you include plenty of delegating monitors or custom monitors with a diagnostic location type of around and a TraceElapsedTimeAction action. These record the time taken by a particular operation when it completes. You'll be needing this data later to build event trees. Here's an example that captures a variety of servlet and EJB operations:

<?xml version="1.0" encoding="UTF-8"?>



<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics">

  <instrumentation>

    <enabled>true</enabled>



    <wldf-instrumentation-monitor>

      <name>Trace_Servlet_Around_Service</name>

      <action>TraceElapsedTimeAction</action>

      <location-type>around</location-type>

      <pointcut>execution(* +javax.servlet.Servlet service(+javax.servlet.ServletRequest, +javax.servlet.ServletResponse))</pointcut>

    </wldf-instrumentation-monitor>

    

    <wldf-instrumentation-monitor>

      <name>Trace_EJB_Session_Business_Methods</name>

      <action>TraceElapsedTimeAction</action>

      <location-type>around</location-type>

      <pointcut>execution(* +javax.ejb.SessionBean * (...))

        AND NOT execution(* * __WL* (...))

        AND NOT execution(* * ejbCreate (...))

        AND NOT execution(* * ejbRemove ())

        AND NOT execution(* * ejbActivate ())

        AND NOT execution(* * ejbPassivate ())

        AND NOT execution(* * setSessionContext (...))

      </pointcut>         

    </wldf-instrumentation-monitor>

    

    <wldf-instrumentation-monitor>

      <name>Trace_EJB_Session_Home_Methods</name>

      <action>TraceElapsedTimeAction</action>

      <location-type>around</location-type>

      <pointcut>execution(* +javax.ejb.EJBHome * (...))

            AND execution(* *Impl * (...))

      </pointcut>         

    </wldf-instrumentation-monitor>



    <wldf-instrumentation-monitor>

      <name>Trace_EJB_Stub_Calls</name>

      <action>TraceElapsedTimeAction</action>

      <location-type>around</location-type>

      <pointcut>call(* +wldfexample.SessionEJBRemote * (...))

        AND NOT call(* *_EOImpl* * (...))

       </pointcut>

    </wldf-instrumentation-monitor>

    

  </instrumentation>

</wldf-resource>

You can see I prefer to specify monitors with my own custom pointcuts, rather than rely on the standard delegating monitors. This provides more control over precisely which events are captured. For example, the last monitor traces only EJB stubs for the test EJB I have deployed ( wldfexample.SessionEJBRemote).