I did a bit of weekend research on the alternatives to Jolokia.
Implementing Java RMI in Go to directly hook into JVM:
RMI is highly Java-centric and it is overwhelmingly difficult to create a Go RMI client.
Java bridge to fetch JMX:
This is basically what we are doing now, using Jolokia as JMX proxy.
However, I have found a few counter-arguments to Jolokia in many forums:
- Jolokia requires a servlet container, which is cumbersome to deploy at some places.
- Jolokia needs to be configured separately as well, XML based configurations scare away a lot of people.
An alternatively can be an embedded Jolokia or a similar JAR that is shipped as a part of the "Javabeat", which can be configured directly using metricbeat configuration.
What to measure
From my experience, these metrics are often requested:
- Memory Info
- Class loader and compilation times
- GC info
- Thread info
- VM Uptime
- Application-specific data
- Some support for JMX notifications
Therefore, we may also provide a means of mapping any application specific MBeans to custom metrics. One of my projects involved montioring a Solr cluster for update handler info exposed under
We should continue to provide the existing method of logging all JMX metadata, this addition should be under a different module name.
Jmx4perl, as suggested in the GitHub issues, has some application specific MBeans that we may include as examples for the user mapping.