what is the difference between jolokia & jmxtrans ? When to choose one over the other? [closed]

Question

I am looking for a JMX querying tool. I have come across jolokia & jmxtrans, both support JSON based querying. JMXtrans has writers to monitoring tools which I think is missing in Jolokia. I googled, but I didn't get much info comparing the two. But I have read positive blog posts wrt both tools. If anyone has used these earlier,pls share ur experiences...

Answer 1

I'm the author of jmxtrans. I considered Jolokia before I developed jmxtrans. I choose to develop with jmxtrans because I had a different usecase in mind.

Jolokia runs as a war in Tomcat. It is similar to jmxtrans in that it allows you to query a JMX server, but that is about where the similarity ends. You would need to implement the rest of jmxtrans on top of Jolokia in order to have feature parity.

On the other hand, jmxtrans is standalone with no requirements on Tomcat. My target audience is the netops/devops role. It is configured with a relatively simple JSON based structure so it doesn't require an engineering degree to configure and use it.

The thought is that you use jmxtrans to continuously monitor services which expose statistics via jmx. You use jmxtrans to 'transform' data from jmx to whatever output format you want. Generally, devops people want to integrate their JVMs with some sort of monitoring solution like Graphite/Ganglia so I provided output writers for those tools.

jmxtrans is also very smart about how it does queries against jmx servers and there is a bit of optimization in there for that. There is also a lot of work to allow you to do things like parallelize requests to many servers to enable to you scale jmxtrans to continuously query hundreds of servers with a single jmxtrans instance.

I hope that clarifies things a bit. If you have any specific questions, I'm happy to answer them.

Answer 2

Indeed, jmxtrans and Jolokia have a different focus. Jmxtrans is a full monitoring solution with a scheduler which queries JMX request periodically and sent the results to a backend like graphite or rrdtool. It uses standard JSR-160 (RMI based) communication for querying JMX enabeled Java servers

Jolokia on the other hand is an HTTP/JSON-JMX Adaptor, which allows for easy access for non-Java clients and adds some unique features which are not available for a pure JSR-160 implementation. For integration into a monitoring platform yet another piece of software is needed. For Nagios, there is Jmx4Perl which provides a full featured Nagios Plugin for querying Jolokia agents.

Since I'm the Jolokia author, let me allow to stress some highlights of Jolokia

• Many requests can be send at once as a single bulk requests. This allow for querying hundreds of attributes with a single HTTP turn around. This really makes a huge difference in large environments.
• Due to the usage of HTTP Jolokia allows easy querying across firewall boundaries (which is a nightmare when using standard JMX connectors)
• Fine grained authorization is easily possible by using a plain XML policy file
• Agents are available not only for Tomcat or any other Java EE container but also for any Java 6 application (e.g. ActiveMQ or Camel)
• A nice suite of command lines tools (e.g. a readline based JMX shell with context sensitive command completion) comes with Jmx4Perl.
• Access libraries from Perl, Javascript, Python, ... are available.
• .... For more info, please refer to www.jolokia.org

To summarize, I think you should use jmxtrans when you need a complete monitoring solution based on JSR-160 remoting (however, you could use Nagios and check_jmx4perl, too) and Jolokia when you need to overcome JSR-160 limitations or can benefit of one of its unique features. One could even imagine to integrate Jolokia into jmxtrans for the communication to the servers to monitor, which then would go over JSON/HTTP instead of JSR-160 RMI (maybe this also clarify the difference focus and supported use case).

Answer 3

let me put one more project on the table - https://github.com/dimovelev/metrics-sampler it queries JMX data using regular expressions and variable substitution and also supports JDBC queries as metric sources (mostly to monitor our oracle db stats) and mod_qos for the apache mod_qos stuff. We only need graphite as output and that is the only output it currently supports.

By the way, IMHO the JMX ports are problematic with firewalls just because hotspot picks a random ephemeral port upon startup. With jrockit it can be specified (to the same port as the registry) with a standard jvm option. To do this on the hotspot you need to code it yourself (or reuse code e.g. from the tomcat jmx connector). The nice part is that it is okay to set both ports to the same value thus needing just one firewall rule.

Cheers Dimo