Hello all,

First at all say Hello to everybody, and thanks to all of you for your time, and dedication to the community.

I've just started to work for a new company which is going to handover some websphere servers, and I have to manage the monitoring of those servers, so I wanted to ask you a few questions:

  Appart from the websphere applications and OS parameters (cpu, mem, disks, and so), do you think if  I monitor the dmgr, nodeAgents appart from the httpd it will be enough??

Also I was thinking to monitor the dmgr and nodeAgents creating a watchdog which will have a look to "ps -ef" and if they can find out that the processes are running to use serverStatus.sh, do you think is good approach?? 

 

Thank you very much in advance for your help...

 

Best regards

 

Carlos.

 

 

Monitorring is always one of those topics, IMHO, that's highly debatable.  How far do you go, and where do you stop?

In my company, I've opted to monitor for the following:

1. Application Server server status - Verifies if there's a PID files, that the PID is linked to a java process, then launches the serverStatus shell script.  This is done for ALL application servers

2. Core / Heap files - look in the profile directory to see if there's a heap dump... Very helpful in understanding why your other checks may have spiked.  Besides, who wants large files consuming disk space???

3. Session Size

4. Heap Split (used, free)

5. Heap Size

6. JDBC Connection Pool size

7. Free disk space

8. General server process - Overall CPU, Memory, OS partition, Data Drive Partition

9. Don't forget to turn on Verbose GC

I monitor my HTTP deployment in a very similar fashion as well.

In my setup, I leverage Nagios, Nagios Graph, DRRaw, & NSC++ to monitor my systems, render graphs, keep 12 months of data in an RRD, and propogate alerts.

The best parts of the above approach is

1. The ENTIRE implimentation is 100% free!

2. It only took about two weeks to stand up the implimentation.

3. I have great insight into everything.

Good Luck!

Erik

Wow thanks very much Erik for your answer, I think with this I have material for investigate for a while, anyway I think I will start with, check pids links to java, for the nodeagent, DMGR and applications (I have to know more details about applications but I think they have their own "monitoring" system :) )... 

Once more Erik thanks very much for your help...

Sure thing Carlos. 

All of the monitoring of the application servers is performed with the free wasPerfServlet tht comes with the WebSphere Application Server.  It simply reads your configured PMI information, per JVM, and presents it via HTTP in an XML format.  If you write a few reusable scripts, you can parse the output and do whatever you'd like. 

I find monitoring this information (acknowledging that it's an average - read more about the servlet online) is helpful in understanding the behavior of the JVMs and the applications they are running.  If you're looking for real-time monitoring, there are other avenues to accomplish this.

Regards,

Erik

So about the was PerfServlet I did not know even about its existence  So I am afraid that my knowledge of WAS administration is under it should be...   I will have to study it fast...  So I think the next forced step is to have a look to some red books :)...

 

Thanks again for your help :)

 

Regards

If you have questions about the servlet, let us know here!  I hope I'm not the only person using this tool...

I did mistakenly give you the wrong name, it's the PerfServletApp.ear...  Below is a snippet from the IBM Docs:

"The performance servlet .ear file PerfServletApp.ear is located in the WAS_HOME/installableApps directory, where WAS_HOME is the installation path for WebSphere Application Server."

This servlet has been around since V5 and I currently use it in v6.1 & v7.0.

Below are a few links to get you started.  Hopefully you understand the PMI metrics, but if not, those of the first batch of links.  The rest are specific to how to interact with the servlet.

Enabling PMI using the administrative console
publib.boulder.ibm.com/infocenter/wasinf...

Retrieving performance data with PerfServlet
publib.boulder.ibm.com/infocenter/wasinf...

PerfServlet output
publib.boulder.ibm.com/infocenter/wasinf...

PerfServlet input
publib.boulder.ibm.com/infocenter/wasinf...

Erik

Thank you, you post me some manuals for keeping myself entertained for a while :) I think also I will have more details from the applications soon, and hopefully also I will have some feedback from the people from who we're doing the handover of the systems. :)

Thanks again for your help Eric :) I hope I will manage to get those things working...

 

Regards :)

Hi Erik
If you have any performance relates scripts
If you dont mine can you please provide me
I really appreciate your time and response
Thanks
Raji

Wow, this is a blast from the past...

Raji,

I don't have any performance scripts per say.  Nearly all of my monitoring is done using a the PerfServletApp.ear and a few other scripts that check for specific things across the cell and it's respective parts.  It's a combination of monitoring/ alert tools and this servlet.

Here's an example:
You have an application and scoped resources at the cluster level where the application is deployed.  You typically want to keep an eye on the resource utilization to ensure there isn't a bottleneck.  This could be a JDBC Connection Pool in theory.  If you see the utilization consistently high, then you might need to take corrective action.

Another example:
You intended a JVM to handle a maximum number of sessions, and you're fast approaching that threshold which will cause you to take corrective action.

The PerfServletApp.ear is your (free) insight into the metrics within WebSphere.  It handles the retrieval of data, gives you a rolling average (in some cases,) and provides a simple XML interface.

It's up to you, however, to interpret those results and integrate them into your monitoring/ alerting solution.  Think of it as the equivalent of the foundation/ footer of a house.

Hopefully this helps,
Erik