This is going to be a fairly short post, because there isn’t a huge amount to go into that we haven’t already covered!

The WLDF monitoring dashboard gives a visual representation of available metrics from WebLogic MBeans. If you know how to drag-and-drop, then you have all the technical ability you need.

In this blog post, I will refer to an annotated image with colour coded headings so you can see which part I’m talking about.

We start at the top left with the “View List” tab and the “Metric Browser” tab. The chances are, when you first go to the Monitoring Dashboard, the View List will be shown. Each view can have many charts on it; the example above is a view called “Session” with a single chart called “Sessions”. Examples of views with more charts can be seen in the Built-in Views. To keep my example simple, I stayed with one chart in a fresh view.

Once your view and charts have been created, use the green play button to start recording metric values for the selected view.You will need to press the play button on each view you want to record metrics on, and use the red stop button to stop recording for the selected view. The octagonal red button will stop all collections.

After having created a new view and added a chart, you will need to add some metrics. Because there are so many to choose from, you first need to narrow down the ones you’re concerned about.

If you’ve no idea how to know which metrics are available, I covered that in part 2 of this series on watches. In that blog post, I found the open sessions count for a web application using the following string: (${com.bea:Name=AdminServer, Type=WebAppComponentRuntime//OpenSessionsCurrentCount} >= 1)

To find the same MBean in the Metric Browser, we need to make sure we’ve selected the right server first, as shown in the “com.bea:Name” segment of the string above. The “Type” corresponds to the “Types” section in the metric browser, so I’ve selected “WebAppComponent”.

That then gives me a list of instances, so I pick _/clusterjsp, since that’s the webapp I’m interested in, and then scroll to the OpenSessionsCurrentCount metric which I can drag and drop on the empty chart.

 Once you have some metrics added to the chart, and you’ve clicked the green play button so that metrics are captured, you might find that you actually don’t want a line chart at all! Perhaps your data is much more suited to a bar chart.

To change the chart type, click the dropdown arrow next to the pencil icon. Clicking the pencil icon will allow you to change the name of the chart.

Using the same dropdown arrow, you can choose to zoom in or out on the chart, or show earlier or later values.

Another, more intuitive way is to use the “mini-map” chart in the bottom right corner. The same zoon in/out and earlier/later arrows are there, but the miniaturised view of the chart is interactive. Click and drag to highlight peaks and troughs and the chart will update to show you that period of time in more detail.

Finally, it’s important to be able to interpret the data. On my example chart, I’ve circled in blue where an event clearly happens. Hovering over any of the data points will tell you exactly what the value is, as I’ve shown with the HeapFreePercent metric (the red triangles)

We can see that there is a garbage collection event there because the red triangle data points which represent how much of the total heap is free gets down below 10% and then leaps up to about 33%.

What we can also see is that it was a young heap collection, thanks to the two half-moon shaped data points, in dark red and blue. The dark red line, which represents the total number of young heap collections since the server started, jumps up by 1; whereas the dark blue line, which represents old heap collections, stays at 0.

That’s really all there is to it! The key to making the dashboard really useful is spending the time to create meaningful charts, like a chart to monitor garbage collection and a chart to monitor a specific app.

There is a lot of power in being able to visualise data in this way. Consider the scenario: you set up a view for 10 of your critical apps. 1 – 5 might be on server A and 6-10 might be on server B. If you can see that all of apps 1 – 5 start to respond very slowly, you can look in a view of server A to see if there are any stop-the-world pauses during that time, or if the heap is running low on memory.