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.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
