Using JConsole to Monitor JVM-Based Applications

We are excited to kick off a new series on the Blue Medora Blog called Engineering Talk Tuesdays. In this series, we’ll feature guest posts from our engineering team, chatting about everything from their favorite technology to what it’s like to work at Blue Medora. 

By: Daniel Mobley

Overview

As part of the Java 5.0 Standard Edition (SE) release, the Java Virtual Machine (JVM) included built-in functionality to monitor core JVM metrics, like CPU utilization. These metrics are accessible via Managed Beans or MBean objects using the Java Management Extension (JMX) API. The Java Monitoring and Management Console or JConsole application was also released to view and interact with these MBean objects.  

JConsole comes with the Java Development Kit (JDK) for Java. Once launched, JConsole can connect locally to a running JVM-based application using a Process ID (PID) or remotely using a hostname and port or a JMX connection string.  

JConsole provides a few simple historical line graphs of key JVM metrics. The metrics are collected from the start of JConsole and are not persisted across restarts of the application, although an option exists to export the data in comma separated values (CSV) format. Here is a screenshot of the ‘Overview’ page displaying historical view of ‘Heap Memory Usage’, ‘Threads’, ‘Classes’ and ‘CPU Usage’:

In addition, all published MBean objects are available via a tree-view control. Although available, this requires the user to be expert enough to navigate and interpret the desired MBean value. For example, finding the JVM Garbage Collector total collection time is easy enough, but often finding desired metric values requires digging deeper and examining complex data types. Only the current MBean value is displayed with no historical context:

Applications

In addition to the built-in JVM platform MBeans, JVM-based applications may publish their own set of MBeans. For example, RedHat’s open-source, web application server WildFly publishes MBeans attributes about deployed web applications, Java Database Connectivity (JDBC) and Java Messaging Service (JMS). These metrics are only available using the tree-view control in JConsole.

Obtaining access to these application-specific MBeans often requires modifying the JConsole classpath to include additional client jar files. Fortunately helper scripts are often available to facilitate this. WildFly comes with both jconsole.bat and jconsole.sh scripts to help launch JConsole for either Windows or Linux environments.

Alerting

It is worth noting that JConsole contains no alerting mechanism. A common feature of more sophisticated monitoring programs is to allow the creation of rule sets to alert the user when certain “threshold” metric values are crossed and to be automatically notified in some way.  

Going back to my WildFly example, watching for and alerting on slow response times for deployed web applications would be important when monitoring a web server. This data may be available using JConsole, but manual retrieval and analysis of these metrics in a live production environment would be difficult if not impossible.

Summary

To conclude, JConsole is a simple to use, easily obtainable tool for monitoring JVM-based applications. JConsole is a great tool for developer environments, but given limitations with how data is accessed and displayed as well as a lack of advanced features, it has a more limited role elsewhere.

To break it down, here are the pros and cons:

Please note that my opinions on JConsole are based on version 1.8.0_111-b14.