faqThe topic has popped up in a few of our conversations recently, and we realized how little known the methods of monitoring Java Enterprise Edition may be. Being fans of the guys from ConSol , we’d thought we’d share the less known but noteworthy alternative.
To start, the typical way to monitor a Java based client is via JSR-160 connectors and check_jmx. This enables you to monitor a bunch of JMX attributes in Nagios through the JMX interface, since the JMX is embedded in Java. These include memory, threads, operating system, garbage collector parameters and various application server attributes.
Check_jmx works well, but takes a while. Though Java itself runs quickly, JVM is slow to start up. This has a noticeable effect when running checks, which can heavily load the server with each round.
An alternative method is via jmx4perl. We like it because it runs checks much faster, accessing JMX without launching JVM or needing a Java installation on the Nagios host. Using a perl library, its proxy approach is straightforward and efficient, making it also fitting for large environments. Apart from being faster, it supports relative and incremental measurements, and accesses deeper to more complex Java bean attributes.
Check_jmx is useful, if you are familiar with the default jmx monitoring settings and are monitoring just a few systems. For the larger environments however, we give our thumbs up to check_jmx4perl, because with more speed you can do more checks.
As always, both plugins are available for download at MonitoringExchange.org:
Check_jmx
Check_jmx4perl