This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
How do you currently monitor, diagnose, manage and resolve operational issues on the fly once a tomcat server is in production?
The problem I face is that using jmx is too coarse grained to quickly implement new operational parameters or to execute a set of tests if an issue occurs.
I would therefore like to have remote access to the runtime environment, which will allow me to have far more fine grained control, by using a dynamic language like e.g. beanshell.
Did you ever consider using shell based access or using a dynamic language to have remote access to the runtime environment? What are your best practices related to this problem?
Thanks for your input on this.
The main problem with adding a command shell to a webapp is that not only can you do more, so can anyone else who figures out how to get access to that command shell.
If you did that on a public-facing webapp, you'd likely get pwned pretty quickly. Most of the managers I've worked under wouldn't even stand for it in-house. Unless they'd done it first.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Nov 20, 2003
Good point. What would you recommend usiing as a shell when it was allowed? Groovy or beanshell or ....
Did you develop a set of best practices or knowledge base while using it in the context of monitoring, diagnosing, managing and resolving operational tomcat issues?
Actually, I just invoke an OS command shell. Go for broke. But not on an employer's server!
Joined: Nov 20, 2003
Because I don't get the type of feedback I expected to get I have added a bit more detail.
I have a web application up and running on a set of clustered tomcat production servers in dmz.
The health of the web application is monitored by Nagios and if Nagios identifies a problem, a notification is send to a sysadmin.
In an ideal situation Nagios would therefore identify all problems before clients do.
Currently jmx is used to acquire the runtime information from the application that is checked by Nagios.
I am however considering to replace jmx by a dynamic language, like groovy or beanshell, to acquire the runtime information of the application.
Based on my limited experience in this field I can see the advantage of using a dynamic language instead of jmx.
Just as an example : writing a new check will become as easy as writing a new script and once a check has failed it will be possible to add ad-hoc tests
to identify the problem on a more detailed level My experience is however limited to a few examples I can think of.
The question : I am very interested in the pros and cons of using a dynamic language to monitor, diagnose, manage and resolve operational issues
of the runtime environment of a tomcat server once it is in production. Also all best practices and problems you've faced are welcome.