The JNRPE server provides an open source Java implementation of the Nagios Remote Plugin Executor (NRPE). This is much more efficient for performing JMX checks than regular NRPE as you only need to start one JVM rather than a JVM instantiation per check (as performed by check_jmx invoking java -jar JMXQuery.jar).

However this efficiency gain comes with a few compromises, it doesn’t handle composite data as well as other variants of check_jmx and doesn’t support performance data. It would be nice to see some community action to produce a definitive check_jmx.

Luckily with Opsview, you can work around the lack of performance data using the map.local file so you can get performance graphs to assist with correlation or view rate of change over time.

In JNRPE version 0.6.3 there is also an integer overflow bug in the check_jmx base plugin.

The maximum value for a Java Integer is 2^31 - 1 (or 2,147,483,647) - if a number exceeds this, as an Integer is a signed number, it will wrap around to a negative number. For example on a JVM set with a 5GB heap, we saw the following output:

JMX OK - HeapMemoryUsage.used is -2037300184

Amusingly with the initial warning/critical threshold values set too low, this caused the state to flap between OK (when the heap was larger than a 32 bit number and hence negative) and CRITICAL after garbage collection had brought it beneath 2GB.

This has been raised with the JNRPE project as issue 3131380 - though unfortunately having raised it without signing in, I now can’t attach the following simple patch to the parseData method.

Index: CCheckJMX.java

===================================================================

--- CCheckJMX.java (revision 243)

+++ CCheckJMX.java (working copy)

@@ -334,7 +334,7 @@

- private int parseData(Object o)

+ private long parseData(Object o)

{

if (o instanceof Number)

- return ((Number) o).intValue();

+ return ((Number) o).longValue();

else

- return Integer.parseInt(o.toString());

+ return Long.parseLong(o.toString());

}