For the intermediate level application server administrator like me, "knowing" that I can manage my tomcat containers remotely using jmx is a lot different than actually writing some useful script that utilizes it. The problem with jmx, in my opinion, is that it's a systems administration technology built into the Java Virtual Machine that is marketed to Developers, not Systems Administrators. Monitoring and Management is probably the last thing on a developer's mind and sometimes I think that the cost in terms of time learning jmx is too high. The payoff in portability from one job to another is probably better than it was having to learn Tcl to write BigIP iRules but probably not much higher. Many sysadmins I've talked to have never heard of it and when they do find out what it is, the need to learn Java first is usually the first barrier that gets thrown up. When you're supporting hundreds of servers and you use a combination of shell scripts and perl scripts most of the time to manage the entire server and not just the VM, learning Java is one of those things that would be nice to learn but who has the time?

While sifting through the keywords reports in this site's google analytics data over this long holiday weekend, I came across Jmx4Perl and I'm really glad I took the time to look it up. Previously, I had heard about JMX4R, which required JRuby and a JVM but all that Jmx4Perl requires is Perl. Installation via 'cpan' is probably the easiest way to do it. Simply open up a cpan shell and then type " install JMX::Jmx4Perl " and you're all set.

The edge that Jmx4Perl has over other JMX implementations, in my systems administrator opinion, is the inclusion of j4p, a small (approximately 92K) web application that you deploy to your app server container webapps directory, which proxies jmx requests on your behalf. This is a lot easier to deploy and protect, especially on Windows systems where securing the jmxremote.password file can be incredibly difficult. Jmx4Perl includes 'out-of-the-box' support for many popular open sourced application server containers, including JBoss, Tomcat, Jetty, and GlassFish as well as the two main commercial application server offerings WebLogic and WebSphere.

Once you have copied j4p.war to your application server's deployment directory and deployed the application, you can begin to use it. No additional firewall ports are needed—heck, you don't even need to enable JMX within your tomcat container to use it with the j4p proxy. Just keep in mind that securing it the way you would secure any web application you don't want others to be able to use would make your security guys happy.

To make things even easier, Jmx4Perl contains a list of aliases that allow you to get off and running writing some useful jmx scripts without having to learn the verbose jmx syntax for getting attributes or invoking methods on management beans, which can differ across app server platforms. For example, to get the version number of your app server on JBoss, you would get the attribute VersionNumber of the MBean jboss.system:type=Server , but on Jetty you would get attribute version from MBean org.mortbay:jetty=default . With Jmx4Perl, you simply get_attribute(SERVER_VERSION) and the correct, corresponding MBean and attribute will be utilized for whichever app server you are using. Aliases for most of the common server operations are included within Jmx4Perl but you can also use the native JMX naming syntax as well.

The sample script below provides the number of currently executing threads on my test tomcat container, to give you an idea how easy it is to begin interacting with Jmx4Perl.

Running this script from the command line provides me with the current number of executing threads within my tomcat container, which is almost always asked by development on phone calls during problems. My next batch of Tomcat Management articles will look into Jmx4Perl further because this seems like such a useful module!



Other posts within this series: