tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: [OT] Inspecting JMX
Date Sat, 28 Jan 2012 13:51:12 GMT
On 26.01.2012 19:32, Christopher Schultz wrote:

> Now I'm trying to get similar information using a command-line tool
> that is very simple called check_jmx -- it's a plug-in for Nagios. It
> appears that this tool does not support the "attach" API and so it
> looks like I'll have to enable "remote JMX", so I've followed the
> instructions on Tomcat's monitoring page to enable remote JMX [3]:

> 3. Should I just give up and use the manager app's jmxproxy? I don't
>     currently deploy the manager app, and I'd like to avoid doing that
>     if possible. But, it may be a slightly cleaner solution.
> 4. Should I hack the code for check_jmx to use the Attach API and
>     try to avoid all of this stupid port business? Getting the PID
>     of the Tomcat process shouldn't be hard as long as I use
>     CATALINA_PID and get the value from there.

Note that the naive check_jmx attempt will not scale. Monitoring JVMs 
using JMX by starting a new JVM on the polling server for each poll and 
each monitored instance will soon killk your monitoring server.

You either need to use an agent running in the target JVM and providing 
access via a simpler non-Java protocol, or you need a long running Java 
based gateway, which does the JMX communication with the target JVMs and 
gets itself queried with something simpler.

In that sense the Tomcat Manager can act as an agent via its jmxproxy 
feature, making JMX data available for each HTTP client that can parse 
simle text output.

Another a bit more sophisticated approach which can be well integrated 
with Nagios is Jmx4Perl as a client in combination with Jolikia as the 
agent (all Open Source).

Of course there are many more options available.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message