appmanager | Enterprise IT Management Blog from ManageEngine

Today, Monitoring is an important task for an Administrator. Grab statistical data, reconfigure certain aspects of the server, add a new web application etc, form a part of the daily administration tasks. At the end of this blog, the administrator can effectively monitor these parameters and have answers to these questions:

1. Which Webapps has the maximum number of sessions ?
2. How much memory is the Tomcat JVM process taking up ?

Though much has been talked about monitoring tomcat application across the market, my insight here is into monitoring Tomcat Application Server through ManageEngine Applications Manager.

Metrics to monitor :

The following metrics serve as a guideline to monitor Tomcat Server through ManageEngine Applications Manager :

• Uptime & Availability
• Number of Requests received by the Server
• Used / Free Memory of the server
• Active Thread Count
• Number of Open Sessions per application
• Application Session information
• Application Response Time
• Servlet Response Time
• Servlet Requests per min
• Thread Status ( for Tomcat 5.x and above )

• Tomcat 3.x
• Tomcat 4.x
• Tomcat 5.x
• Tomcat 6.x

<Valve className="com.adventnet.appmanager.tomcatagent.ver4.valve.AdventNetHostValve"/>

http://tomcatservername:8080/manager/status?XML=true
http://tomcatservername:8080/manager/html/list
http://tomcatservername:8080/manager/jmxproxy?qry=*%3Aj2eeType%3DServlet%2c*

I am sure you should have come across any one of these messages below, in ManageEngine Applications Manager.

1. Authentication Failed. Kindly provide the correct username and password

2. SNMP Agent is not running in the system. Kindly start the SNMP Agent for Monitoring.

Well, this has been posted frequently in our forums. Customers using two or more ManageEngine products should have definitely come across this.

Why does this happen, at the first place?

All ManageEngine products have been built on the same carrier platform and all use Tomcat / JBOSS server for serving the webpages. The cookie set in the browser by these products have the same name(JSESSION_ID) and the context path. So, when you access one ManageEngine product ( say for example, OpManager ), the cookie is first set on your browser. When you access Applications Manager or ServiceDesk Plus, you will be prompted to login to the web client. The value of the cookie is now set (ie., updated) to what Applications Manager or ServiceDesk Plus server offers. However, when you try to access the OpManager pages, the value of the session cookie will now be different from what was set earlier through OpManager and hence, you are forced to relogin with a session timeout message.

You will now be interested to know how to overcome this. It is easy, though the individual products are now working to change the cookie name.

1. Access OpManager through the hostname of the server and access Applications Manager or ServiceDesk Plus through the ipaddress.

2. Install these products on different physical server or VMWare instances.

3. You can think of setting up different hostnames ( CNAME entries ) for the applications in your DNS.

I will keep you all posted when this is getting addressed.

Kevin

Every organization has its own Applications ( be it critical or non-critical ) to monitor and they have their own teams to administer these applications. Not all team members has the same level of expertise to troubleshoot the application errors. With ManageEngine Applications Manager, this is possible at any level.

[ This is a live situation that happened a few weeks ago in our Client office. We were elated to find out that with Applications Manager, there were able to find out the root cause of the issue and were able to fix it within minutes of identifying the root cause. ]

Let us take an example here to see how ManageEngine Applications Manager helps technicians to troubleshoot application errors.

Payroll System :

This system should have a frontend JSP / ASP web page and a backend MSSQL or Oracle Database. Let us fine drain this to have a JSP frontend through Tomcat Server and a MSSQL database,both the components residing on two different physical servers.

Let us say a user reports to the Payroll Administrator that the application is responding too slow that the login takes around 2-3 mins.

The Payroll Administrator has to now login into the application to validate the incident. Though it may or may not be slow to the Administrator, he has to now resolve the issue for the end user. With ManageEngine Applications Manager in place, the Administrator can get an holistic approach on the performance of the Application.

The Administrator can look for the following through ManageEngine Applications Manager while working to troubleshoot the application performance :

1. Check whether the CPU / Memory of the Server is normal.

The screenshot shows that the Memory has shot up to 94% and is always a constant at this value. This may have violated the Threshold value and indicates that there is a performance issue.

2. Now, the next area to troubleshoot is the Tomcat Server. On analyzing the tomcat server parameters, it has been found that the Used Memory of the application is 13 MB while the total memory allocated is 18 MB.

On further analysis, the administrator finds that there are 25 Current Threads for a particular connector which causes the memory to shoot up.

3. The analysis is still not complete. The Administrator drills down further to find out why the Memory used by the Tomcat Server was close to 75 %. The next area to look into is the MSSQL database.

Observing the above screenshots, the administrator concludes that the Root cause for the slow performance of the payroll application is due to 70 Active Connections per min, while the optimum value should have been at 30. There were unwanted connections by end users to the DB Instance, which has caused a degradation in the performance of the application. [ Refer my blog "Thresholds & Managing Application Performance Proactively" for more details on configuring Thresholds to various parameters ]

Now, the next question is that “Should I have to go into each of these monitors every time, an issue is reported?”. You should have guessed the answer right. The answer is “No”. 

See the various approaches which help you to be more proactive than reactive, when such incidents are reported.

1.    You can group these monitors to create a Business snapshot view. The detailed view gives an at-a-glance performance of all the monitors.

2.    You can create a dashboard view for these monitors and publish the dashboard on a plasma screen.

The below code snippet is an example to publish your dashboard view.

 <iframe src="http://servername:9090/publishPage.do?method=getPublishedDashboard&pagekey=248a855fea1f90279460dc5e0731493b" align="center" height="768" width="1024" border="0" frameborder="0"> </iframe>

The option to publish the dashboard is available through Actions -> Publish Dashboard from the Dashboard view.

3.    You can include troubleshooting documents for various errors associated with the application performance.

 
You can extend the same steps to troubleshoot any other application error through Applications Manager. Applications Manager follows a pro-active approach and helps ease out Administrator job functions by automatically correcting the errors through custom scripts or programs.

I believe this document serves as a guide to help any administrator to troubleshoot application performance and errors through ManageEngine Applications Manager.

Kevin