JMX probes

Those probes connects to any JVM with JMX actived to collect info. It can then collect any values accessible in MBeans than can be reach using a simple path declaration. The path loosely follow the idea given in RESTful Access to JMX Instrumentation

An easy (but not very secure) way to activate JMX access on a JVM is to add the following arguments :

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Blogs about JMX was once found at JMX Blogs, but since everyone left Oracle, not a lot of blogs are still alive.

The home page for JMX at Oracle is http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html. JMX is part of JDKM (Java Dynamic Management Kit). The home page of OpenDMK is https://opendmk.java.net. A complete document for the latest version of JDMK is http://docs.oracle.com/cd/E19698-01/816-7609/.

The connection

JMX probes are connected probes

The connection class for this probe is jrds.probe.JMXConnection.

Attributes

Name Default value Description
port The jxm connection port
protocol rmi The protocol used for the jmx connection
user A user for connection authentication
password A password for connection authentication
url The exact URL of the connexion, usually something like service:jmx:rmi:/jndi/rmi:localhost:10001/rmi

JMX Protocols

JMX can use different protocol to carry requests. The default one is RMI, but it can be really difficult to use it through firewall and NAT. The simpler jmxmp can be used instead. There is not a lot informations about it, but it's described on this blog. To use it, one needs to put jmxremote_optional.jar it the class path. This jar is include in the JMX Remote API Reference Implementation, that can be downloaded at http://www.oracle.com/technetwork/java/javase/tech/download-jsp-141676.html (or what ever place Oracle choose to move it). An alternate solution it to use opendmk_jmxremote_optional_jar.

To make this protocol always available on Linux hosts using alternatives, this jar can be put in /etc/alternatives/jre/lib/ext. For jrds using tomcat6, the jar should be installed in /usr/share/java/tomcat6/.

Jolokia

Both RMI are brittle, heavy and complicated protocols. Using Jolokia is recommended. It needs a little setup on remote side, that is explained at Jolokia's Agents. The parameter serializeException should be set to true.

If deployed using war, it's as simple as adding the following file in /etc/tomcat/Catalina/localhost/jolokia.xml

<Context cookies="false"
         displayName="jolokia"
         docBase="/path/to/jolokia-war-1.3.4.war"
         >
	<Parameter name="serializeException" value="true"/>
</Context>

And a host configuration to use it will be:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE host PUBLIC "-//jrds//DTD Host//EN" "urn:jrds:host">
<host name="tomcatserver" dnsName="tomcatserver">
    <!-- Tomcat -->
    <connection type="jrds.probe.JMXConnection" name="tomcat">
        <attr name="port">8443</attr>
        <attr name="protocol">jolokia</attr>
        <attr name="ssl">true</attr>
    </connection>
    <probe type="JMXParallelGC8" label="tomcat" connection="tomcat"/>
    <probe type="JMXThread" label="tomcat" connection="tomcat"/>
    <probe type="TomcatGRP" label="tomcat" connection="tomcat">
        <attr name="index">ajp-bio-8009</attr>
    </probe>
</host>

Garbage Collector choice

A Sun JVM can used different code of GC algorithm.

If not GC is given, the GC used and the probe to be used is given by looking in java.lang:type=GarbageCollector

Garbage collectors GC kind
name=Copy name=MarkSweepCompact SerialGC
name=ParNew name=ConcurrentMarkSweep ConcMarkSweep
name=ParNew name=MarkSweepCompact ParNewGC was deprecated in 8, failed in 9, removed in 10
name=PS Scavenge name=PS MarkSweep Parallel or ParallelOld
name=G1 Young Generation name=G1 Old Generation G1GC
name=Shenandoah Major name=Shenandoah Minor Shenandoah
name=ZGC ZGC

Java 6 introduced G1GC as a technology preview in Java 6 u 14.

Java 8 removed Permanent generation, so all previous probes are unusable with it.

Java 9 removed the code cache memory pool and splitted it at two code heap: profiled and non profiled nmethods.

Java 8 deprecated ParNewGC. Java 9 failed using it. It was removed in Java 10.

OpenJDK 12 introduced Shenandoah GC. It's available in some OpenJDK 11 (Redhat distribution for example).

Java 11 introduced ZGC in Linux plateform only.

A good summary can be found at http://www.fasterj.com/articles/oraclecollectors1.shtml.

 
sourcetype/jmx/start.txt · Last modified: 2019/06/12 12:26 by root     Back to top