Exploring JMX

 

Having JMX at your fingertips is nice once you know your way around, but starting to use it may be daunting. This page shows you how to use Sun’s jconsole to explore your application and how to find and configure items that you may find useful for your monitor.


The page gives two examples; one where we graph a simple attribute on an mbean and one where we graph the value of a composite attribute.




If you do start exploring a real life application, I suggest you do this together with your counterpart. If you are a system operator, look up a Java developer to sit down and look at the application with. If you are a Java developer, find one of the system administrators who will maintain your application and sit down with him or her. This is the co-operation part that I talked about.


Warning

As a Java developer, you are probably used to a nice, clean world. All machine dependencies are operating systems specifics are hidden behind easy to use API’s and abstraction layers.


Not so with JMX. JMX exposes the gritty details of the Java memory management and operating system quirks to your application. Instead of dealing with a predictable virtual machine, you end up with code that does different things on different machines, just because they have a more processors.


I suggest that you explore the application on the actual production servers and not on test machines. If for some reason you cannot get access to the production environment, have someone verify that the monitoring actually works as planned on the production servers.


My Way of Working

The remainder of this tutorial shows you a simple way to explore your application. It is the way that I work, but that does not make it the best or even a good idea.


What I do when I encounter a Java application is to enable remote JMX on it and then use jconsole to look around inside. If I find some values that I like, I copy the bean name and the attribute name from jconsole and feed it into Zabbix as a new item to query.


Let’s walk through the whole flow of enabling remote JMX on an application, finding out what memory regions it has and adding a Zabbix item to monitor the permanent generation size. Monitoring the permanent generation size is something you’ll end up doing every time. This is where Java stores generated classes. In the current era of dynamic web services and on-the-fly code weaving you may get lots of unexpected out of memory exceptions from this area.


Step by Step

The first step is to start your application with JMX enabled. To do so, add the arguments shown below to the command line, as discussed in Sun’s description on how to enable remote access to JMX. You can add these to the start script of your application, or as a JVM argument in your Eclipse run configuration.

-Dcom.sun.management.jmxremote


Zapcat does not rely on remote JMX to work, it connects to JMX inside the JVM. You have to leave this setting in place though, otherwise the JVM does not start gathering its statistics.


With the application running, start jconsole from the command line. If you run jconsole on the same machine as the application, it will automatically pick up on the application and offer to connect to it. Select your application and click “Connect”.


You should now see a screen that resembles the screen shot below. This is an overview of the application.


If you have never used jconsole before, take a little time to look at all the tabs. Personally, I find the tabs marked “Memory” and “VM” particularly useful.


Click on the tab named “MBeans”. On the left, you see the tree of all the mbeans in your application. Again, take a little time to browse this tree and get a feel for the kind of information that JMX offers.


One particularly neat feature to try is to double-click on one of the attributes. Jconsole will then show a tiny graph of the values of that attribute over time. Here I have double-clicked on the attribute “CollectionCount” of the copying garbage collector.


Depending on your machine’s configuration you may not have the same garbage collector that I have. We are in machine-dependent territory now.


Let’s make a graph of the garbage collection count in Zabbix. One that does not disappear if you accidentally close the a window.


Jot down the name of the attribute you want to make a graph of on a scrap of paper. In this case, it is “CollectionCount”. The attribute name is case sensitive, so make sure you know which letters are upper case and which are lowercase.


Click on the tab marked “Info” and look for the field named “MBean Name”. Here it is “java.lang:type=GarbageCollector,name=Copy”.


The mbean name and the attribute name uniquely identify the data we want to graph. With these bit of information, we can create another Zabbix item.


Log into Zabbix, navigate over to the items on the host definition you created and add another item. Fill in the fields as shown below.


The complete key is shown below.

jmx[java.lang:type=GarbageCollector,name=Copy][CollectionCount]


If you leave Zabbix running for a bit, you will see something similar to the graph that I found.


Composite Attributes

If you are like me, you probably headed straight for the memory mbeans when you were looking around in jconsole. Unfortunately, the memory usage attributes are not as easy to access as most of the others. They are composite values, meaning that the attribute is an object with a number of different fields of its own.


Fortunately, Zapcat knows about composite attributes and allows you to express precisely what component of the composite attribute you’d like to have. It uses a dot-notation for that, where the attribute name and its fields are separated by a dot.


For example, is we want to make a graph of the memory usage in the tenured generation of our virtual machine, we will use the mbean named “java.lang:type=MemoryPool,name=Tenured Gen”.


On that mbean, we want to query the field “used” of the attribute “Usage”. For Zapcat, this means that the attribute should be specified as “Usage.used”. The complete key to use in Zabbix is shown below.

jmx[java.lang:type=MemoryPool,name=Tenured Gen][Usage.used]


If you use “b” or “bytes” as the data type, Zabbix understands that it should mark the scales in kilobytes or megabytes, depending on how much memory you are using.


Other Ways of Working

If you are using a JEE container such as Tomcat or JBoss, search the Internet for some of the JMX web applications that are available. They may offer a nice alternative to jconsole, with the added benefit that you don’t have to deal with the dynamic port allocation of RMI that remote JMX relies on by default.


Off You Go

I am sure that during the course of this tutorial you must have seen countless things that you want to graph and monitor. I wont keep you any longer. Please go ahead and start setting up the perfect monitor for your application. I would appreciate it if you would e-mail me the host definitions you created. You can export them from Zabbix and attach them to the e-mail.

 
photo: Benjamin Earwickerhttp://www.garrisonphoto.org/
if you find this interesting, terrible or just would like to know more, e-mail memailto:kjkoster@kjkoster.org?subject=
web statistics
download zapcathttp://sourceforge.net/project/showfiles.php?group_id=209024
http://java-monitor.com/