All started up early 2009 when my colleague Gerhard Lausser, our local Nagios guru, came up in my office and complained heavily about how damned hard it is to monitor Java EE servers with Nagios. As you might know, Nagios uses a plethora of plugins for doing the hard monitoring stuff. These are running locally on a central Nagios host contacting the watched systems mostly remotely with various techniques. For Java applications, JMX is of course the proper choice which provides JSR-160 connectors remote access to the local MBeans. At this time, indeed several JMX Nagios plugins were already present. However, they all suffer from the same problem: JSR-160 connectors are highly Java centric where its default protocol RMI is not available outside the Java universe. So, each plugin (which runs in an external process when called by Nagios) needs to start up a Java Virtual Machine. This has to be done for every check, and since there are usual hundreds of checks every five minutes this becomes easily a performance and memory bottleneck. Additionally, you need a Java installation on the Nagios host, which for many administrators poses a, let’s say 'cultural' problem.

As a Java programmer I love JMX. It is one of the oldest Java specifications, which was carefully crafted from the very beginning (especially the core API). Other Java APIs had to take a longer tour until they became widely accepted by the masses as not being painful (think "EJB" or "JSF"). However, I’m not really happy with JSR-160’s focus on Java based remote protocols. There has been some efforts to make these more friendly to the outside world (e.g. a JSR-160 WebService connector as defined in JSR-262), but it seems there is not much momentum anymore behind these. In fact, the last update on JSR-262 was in May 2008 and it is marked as "inactive". And frankly, I don’t want to use WebServices for monitoring, either (although WS-Management is an interesting approach).

That was the birth of jmx4perl in May 2009. Coming from a strong Perl background (being a SGI system administrator at university in my former life), my initial goal was to use pure Perl for accessing remote JMX information without the need of a local Java integration. In turned out that an agent based approach was the simplest way. The first agent, a Java EE webapplication, which on the frontside translates HTTP requests with a JSON payload to local JMX calls (and vice versa for the response), was really lightweight. It knew how to read and set attributes and how to execute operations. It had a list mode for looking up all registered MBeans. And it was 38kb in size.

The jmx4perl agent is now ~ 200kb 'large' with many more features (search, bulk requests, security, …​.) but I still call it lighweight ;-). The perl part consists now of a powerful Nagios plugin called check_jmx4perl, a command line tool called jmx4perl, a Perl library named JMX::Jmx4Perl and a readline based (with context sensitive tab completion on MBean names) JMX shell called j4psh.

From the feedback I got, it seems that the Nagios world is happy now. But since I think that this agent based approach provides also a good alternative to JSR-160 connectors for other platforms, it is time to move on and split the Java and Perl part of jmx4perl into two separate projects. The number of programmers who love both Java and Perl is negligible anyway ;-). The Perl part (which is approximately the same size as the Java part) remains jmx4perl, the agent part has become …​ Jolokia.

Jolokia is one of the world hottest chili pepper with a Scoville rating of at most 1,075,000. I’m a chili head and grow chilis since 2006. I love chilis as much as JMX. That’s the main reason.

The other reason is, that a chili is a good metaphore for a hot, new approach for JMX remoting. Especially when it is the hottest one ;-)

My name is Roland Huss and during the last decades, I mainly acted as Java wizard, transforming large XML documents into huge stacktraces.

Now for the obligatory legal stuff. I keep it short, only the common boilerplate.

Liability for Content

We make every effort to keep the information on our Web site current, but accept no liability whatsoever for the content provided. Pursuant to §7 par. 1 of TMG (German Tele-Media Act), the law limits our responsibility as a service provider to our own content on these Web pages. According to §§8 to 10 of TMG, we are not obligated to monitor third party information provided or stored on our Web site. However, we shall promptly remove any content upon becoming aware that it violates the law. Our liability in such an instance shall commence at the time we become aware of the respective violation.

Liability for Links

Our site contains links to third-party Web sites. We have no influence whatsoever on the information on these Web sites and accept no guaranty for its correctness. The content of such third-party sites is the responsibility of the respective owners/providers. At the time third-party Web sites were linked to ours, we found NO GROUNDS WHATSOEVER of any likely contravention of the law. We shall promptly delete a link upon becoming aware that it violates the law.

Copyrights

The content and works provided on these Web pages are governed by the copyright laws of Germany. Duplication, processing, distribution, or any form of commercialization of such material beyond the scope of the copyright law shall require the prior written consent of its respective author or creator.

Data Protection

Please be aware that there are inherent security risks in transmitting data, such as e-mails, via the Internet, because it is impossible to safeguard completely against unauthorized access by third parties. Nevertheless, we shall safeguard your data, subject to this limitation. In particular, personal information will be transmitted via the Internet only if it does not infringe upon third-party rights, unless the respective party has given its prior consent in view of such security risks. Accordingly, as the Web site provider, we shall not be held liable for any damages incurred as a consequence of such security risks or for any related acts of omission on our part. We oppose the use of any available contact information by a third party for sending unsolicited advertisements. As the Web site provider, we reserve the express right to take legal action against unsolicited mailing or e-mailing of spam and other similar advertising materials.