On 09/22/2010 03:42 PM, Darryl Lewis wrote:
Are you trying to monitor from the same computer that tomcat is running on?
That's not a good idea. What happens if the entire system crashes...you won't
get any data/alerts. End to end uses another machine to monitor the first.
You could monitor catalina.out for errors, but I don't think you'll capture
every possibility.
What would happen if the system stops serving pages (or serves them slow)? That
won't show in the logs.
What port is your application running on? You can use (from another machine)
wget {servername}:8080.
Well, on the other hand, what happens, if the machine doing the
monitoring crashes? Again, you're out of alerts.
So, monitoring is something you build in layers. And have one point of
your monitoring infrastructure be something that is seen if it goes
down. Or alternatively, have some weird setup where two (or more)
things are monitoring each other.
As for end-to-end monitoring, it's nice for response time statistics,
but if your infrastructure is anything beyond "simple", you'll want to
monitor distinct components. Consider a situation where authentication
is done by some kind of front-end proxy. You have end-to-end monitoring
in place, so all your requests go through the front-end. Now, monitoring
shows an error. Is the error with the front-end or with the application
server? Or perhaps in the network between the two? Or in the network
between the monitoring server and the front-end? Add another layer
(database?), and you'll agani have more possibilities what could be
wrong -- and more or less, with end-to-end monitoring you'll only get a
notification that "something is wrong with this page".
Further, with end-to-end monitoring combined with redundant systems, the
alert will generate when the last piece of redundancy is gone - i.e.
when the whole redundant service is down, not when it gets degraded
(which would be the correct point to react).
So, something running on your Tomcat machine and doing requests for
"HEAD /" would be sufficient to see that the Tomcat itself is not
completely hung. When you make such a program simple enough (but at the
same time foolproof enough), and set it to run regularly using the
operating system task scheduler (cron in Unix-like systems), you'll have
a good "point solution" that tells you exactly that the Tomcat is not
working.
As to finding out what is wrong with a non-working Tomcat, I've been
pretty successful in generating thread dumps from hung Tomcat java
processes, and seeing from them what has been executing, and also rather
often what has caused the hang. For example, some versions of Oracle
JDBC drivers.. .
--
..Juha
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
