Chris, (comments inline)
----- Original Message ----- > From: Christopher Schultz <ch...@christopherschultz.net> > To: Tomcat Users List <users@tomcat.apache.org> > Cc: > Sent: Tuesday, January 31, 2012 12:29 PM > Subject: Re: [OT] Inspecting JMX > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rainer, > > On 1/28/12 8:51 AM, Rainer Jung wrote: >> 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. > > Yeah, we're using check_nrpe to invoke the check_jmx processes on the > server that is being monitored, but I expect that we will be > monitoring half a dozen JMX variables on several VMs, and that means > lots of JVMs being fired up just to connect and ask a simple question. > >> 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. > > Are you suggesting a long-running process with a persistent connection > to the JVM, so that a new JVM for each request can be avoided? Someone > has to have done that already, right? You might take a look at collectd (http://collectd.org/ ). There's a Java and JMX plugin available. You could run that, connect to your local Tomcat, gather statistics, and then send the information back to a central server with the network plugin. It appears that there is an option to encrypt the information as well. On the central server, you could equip the collectd daemon with the collectd-nagios program to inform Nagios about trouble. Unfortunately, that approach looks a little inflexible at the moment. One other issue is that collectd just generates information and sends it off (network, RRD, CSV). What you do with it after that is up to you. While there are examples given in the documentation about how to deal with the information (mostly focused on RRD), the actual work is left as an exercise for the implementer. Finally, the collectd tool is designed to run on UNIX/Linux. While this fits your clients in the cloud, it may or may not fit your server platform. There is a collectd to JMX program written in Java, but I couldn't get it to work with the later versions of collectd. I suspect that someone will have to write a collectd server that implements the bare necessities (network, RRD, CSV) if your collection / server platform is Windows. >> 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. > > I may consider doing that, though we aren't using the manager app for > anything else right now. I'll see if I can use it without allowing > access to any other services (like deploy, etc.). > >> 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). > > I'll check that out. > >> Of course there are many more options available. > > I'll document what I find on the wiki. I'm surprised that there's > little monitoring information on the Tomcat site. :( > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8oTw4ACgkQ9CaO5/Lv0PAahQCfQ2NreQ55K10o4DVJQzGRxv9R > ZlEAoJ/mc8sUL+q3CDYxJAV1+7XAUib+ > =FpZG > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > . . . . just my two cents. /mde/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
