JMX Management for fun and profit!

I have recently been tasked with the project at work to start implementing JMX to manage our production app servers. Prior to this I had heard of JMX and knew a little about what it was and it's overall purpose, but there was a great deal that I didn't understand going into the project and over the last few monthes I have learned a great deal, not only about JMX but also about Management Architecture and Systems in general.

We have, what I would refer to, as a fairly common production system architecture. We have multiple applications that run over multiple clusters of tomcat servers. Some of our production servers run clusters of tomcat servers themselves as well, which presents a whole new layer of problems.

Basically, step 1 was to implement JMX and custom MBeans into our application. I started with some low hanging fruit. Our local application cache has always been a problem child so it was a good place to 'test the waters' and see what JMX could do for us.

I should also note that this is still an ongoing project so I will also be periodically updating this blog with new things that I implement as the project matures and eventually becomes a reality.

The first step in this long ardous journey was to get JMX up and running in our app servers so that we could connect through JConsole and get access to our MBeans as we created them.

A little googling showed that this is pretty simple to do with just some command line parameters passed into the JVM.

-Dcom.sun.management.jmxremote

Setting this system property registers the JVM Instrumentation MBeans and publishes an RMI connector to allow JMX Client applications to connect to it from the same physical machine.

Close, but not quite there, I want to be to connect to the server from a different machine. So there are a few more things I need to set in the JVM to allow this.

-Dcom.sun.management.jmxremote.port=
-Dcom.sub.management.jmxremote.authenticate=false

Nice! Setting this property exposes the RMI Service on so you can connect to it remotely.

Now I can connect remotely, however, anyone else with JConsole can also connect remotely and do lots of nastiness to the server. We don't want that!

-Dcom.sun.management.jmxremote.password.file=
-Dcom.sun.management.jmxremote.access.file=

As you can probably guess, this sets the path's to a couple of files that the RMI Service will use to authenticate connections. An example of each is provided with the JDK in $JRE_HOME/lib/management.

NOTE: There is a security risk in using this form of authentication for JMX. The username and password values are sent to the server in cleartext, thus anyone sniffing packets could intercept the authentication credentials and connect to your server. That being said, if your servers are behind a firewall and you are only connecting from inside your corporate network, this may not be an issue for you, however, the safest way to go would be to use SSL Authentication with certificates to authenticate connections to your RMI Service. I will cover using SSL Certificates in a subsequent blog entry.

Awesome! I can now connect to my JMX Managed Tomcat Server from another machine and do all kinds of fun stuff to my JVM and Tomcat instance.

To connect, I simply open JConsole from a PC that has the JDK installed on it and open a connection to my remote server. In Java 6 (which has a far better version of jconsole) select Remote Process and the address and port of the server you want to connect to, as well as the username and password specified in your jmxremote.passwd file.

For example:
Remote Process: 192.168.0.100:9100 Username: Manager Password: s3cr3t

Viola!

In my next post I will cover creating custom MBeans and different things you can do with your own MBeans to make managing your small to enterprise application easy and fun!