JMX monitoring can be used to monitor JMX counters of a Java application.
In Zabbix 1.8, if you wanted to monitor JMX counters of a Java application, your best choice would have been the Zapcat JMX Zabbix Bridge. You would either modify the source code of your application to reference the Zapcat JAR file and programmatically start a Zabbix agent, or you would install a ready-made Zapcat plugin for applications that support it (such as Jetty or Tomcat).
Zabbix 2.0 adds native support for JMX monitoring by introducing a new Zabbix daemon called “Zabbix Java gateway”.
When Zabbix server wants to know the value of a particular JMX counter on a host, it asks the Zabbix Java gateway, which in turn uses the JMX management API to query the application of interest remotely.
A Java application does not need any additional software installed, but it needs to be started with the command-line options specified below to have support for remote JMX monitoring.
As a bare minimum, if you just wish to get started by monitoring a simple Java application on a local host with no security enforced, start it with these options:
java \ -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=12345 \ -Dcom.sun.management.jmxremote.authenticate=false \ -Dcom.sun.management.jmxremote.ssl=false \ -jar /usr/share/doc/openjdk-6-jre-headless/demo/jfc/Notepad/Notepad.jar
This makes Java listen for incoming JMX connections on port 12345, from local host only, and tells it not to require authentication or SSL.
If you want to allow connections on another interface, set the -Djava.rmi.server.hostname parameter to the IP of that interface.
If you wish to be more stringent about security, there are many other Java options available to you. For instance, the next example starts the application with a more versatile set of options and opens it to a wider network, not just local host.
java \ -Djava.rmi.server.hostname=192.168.3.14 \ -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=12345 \ -Dcom.sun.management.jmxremote.authenticate=true \ -Dcom.sun.management.jmxremote.password.file=/etc/java-6-openjdk/management/jmxremote.password \ -Dcom.sun.management.jmxremote.access.file=/etc/java-6-openjdk/management/jmxremote.access \ -Dcom.sun.management.jmxremote.ssl=true \ -Djavax.net.ssl.keyStore=$YOUR_KEY_STORE \ -Djavax.net.ssl.keyStorePassword=$YOUR_KEY_STORE_PASSWORD \ -Djavax.net.ssl.trustStore=$YOUR_TRUST_STORE \ -Djavax.net.ssl.trustStorePassword=$YOUR_TRUST_STORE_PASSWORD \ -Dcom.sun.management.jmxremote.ssl.need.client.auth=true \ -jar /usr/share/doc/openjdk-6-jre-headless/demo/jfc/Notepad/Notepad.jar
Most (if not all) of these settings can be specified in /etc/java-6-openjdk/management/management.properties (or wherever that file is on your system).
Note that if you wish to use SSL, you have to modify startup.sh script by adding
-Djavax.net.ssl.* options to Java gateway, so that it knows where to find key and trust stores.
See Monitoring and Management Using JMX for a detailed description.
With Java gateway running, server knowing where to find it and a Java application started with support for remote JMX monitoring, it is time to configure the interfaces and items in Zabbix GUI.
For each JMX counter you are interested in you add an item of type JMX agent attached to that interface. If you have configured authentication on your Java application, then you also specify username and password.
The key in the screenshot below says
jmx["java.lang:type=Memory","HeapMemoryUsage.used"]. The JMX item key syntax is similar to Zapcat items, except that a comma is used for separating arguments instead of “][”. The key consists of 2 parameters:
See below for more detail on JMX item keys.
If you wish to monitor a Boolean counter that is either “true” or “false”, then you specify type of information as “Numeric (unsigned)” and data type as “Boolean”. Server will store Boolean values as 1 or 0, respectively.
An MBean object name is nothing but a string which you define in your Java application. An attribute name, on the other hand, can be more complex. In case an attribute returns primitive data type (an integer, a string etc.) there is nothing to worry about, the key will look like this:
In this example an object name is “com.example:Type=Hello”, attribute name is “weight” and probably the returned value type should be “Numeric (float)”.
Attributes returning composite data
It becomes more complicated when your attribute returns composite data. For example: your attribute name is “apple” and it returns a hash representing its parameters, like “weight”, “color” etc. Your key may look like this:
This is how an attribute name and a hash key are separated, by using a dot symbol. Same way, if an attribute returns nested composite data the parts are separated by a dot:
Problem with dots
So far so good. But what if an attribute name or a hash key contains dot symbol? Here is an example:
That's a problem. How to tell Zabbix that attribute name is “all.fruits”, not just “all”? How to distinguish a dot that is part of the name from the dot that separates an attribute name and hash keys?
Before 2.0.4 Zabbix Java gateway was unable to handle such situations and users were left with UNSUPPORTED items. Since 2.0.4 this is possible, all you need to do is to escape the dots that are part of the name with a backslash:
Same way, if your hash key contains a dot you escape it:
A backslash character should be escaped as well:
If the object name or attribute name contains spaces or commas double-quote it:
This is actually all there is to it. Happy JMX monitoring!