Monitoring overall system health

Monitor overall system health

Monitoring overall system health is fundamentally important to understanding the health of every system involved with the system. This includes web servers, application servers, databases, back-end systems, and any other systems critical to running the web site.
If any system has a problem, it might cause the servlet is slow message to appear. IBM and several other business partners leverage the WebSphere APIs to capture performance data and to incorporate it into an overall 24-by-7 monitoring solution. WebSphere Application Server provides Performance Monitoring Infrastructure (PMI) data to help monitor the overall health of the WAS environment. PMI provides average statistics on WebSphere Application Server resources, application resources, and system metrics. Many statistics are available in WebSphere Application Server, and you might want to understand the ones that most directly measure your site's resources to detect problems.

Metric Meaning
Average response time Include statistics, for example, servlet or enterprise beans response time. Response time statistics indicate how much time is spent in various parts of WAS and might quickly indicate where the problem is (for example, the servlet or the enterprise beans).
Number of requests (transactions) Enables you to look at how much traffic is processed by WebSphere Application Server, helping you to determine the capacity that we have to manage. As the number of transactions increase, the response time of the system might be increasing, showing the need for more system resources or the need to retune your system to handle increased traffic.
Number of live HTTP sessions The number of live HTTP sessions reflects the concurrent usage of the site. The more concurrent live sessions, the more memory is required. As the number of live sessions increase, you might adjust the session time-out values or the JVM heap available.

Web server thread pools
Interpret the web server thread pools, the web container thread pools, and the Object Request Broker(ORB) thread pools, and the data source or connection pool size together. These thread pools might constrain performance due to their size. The thread pools setting can be too small or too large, therefore causing performance problems. Setting the thread pools too large impacts the amount of memory needed on a system or might cause too much work to flow downstream if downstream resources cannot handle a high influx of work. Setting thread pools too small might also cause bottlenecks if the downstream resource can handle an increase in workload.

The web and EJB thread pools
Database and connection pool size
Java virtual machine (JVM) Use the JVM metric to understand the JVM heap dynamics, including the frequency of garbage collection. This data can assist in setting the optimal heap size. In addition, use the metric to identify potential memory leaks.
CPU We must observe these system resources to ensure that we have enough system resources, for example, CPU, I/O, and paging, to handle the workload capacity.
I/O
System paging

To monitor several of these statistics, WebSphere Application Server provides the Performance Monitoring Infrastructure to obtain the data, and provides the Tivoli Performance Viewer in the administrative console to view this data.
To monitor several of these statistics, WebSphere Application Server provides the Performance Monitoring Infrastructure to obtain the data, and provides the Tivoli Performance Viewer and the optional IBM Tivoli Composite Application Manager for WebSphere Application Server in the administrative console to view this data.

Enable PMI through the administrative console to begin data collection.

Use Tivoli Performance Viewer, IBM Tivoli Optimizer for WebSphere Application Server, or some other third-party performance monitoring and management solutions to monitor performance.

Use Tivoli Performance Viewer, IBM Tivoli Composite Application Manager for WebSphere Application Server, or some other third-party performance monitoring and management solutions to monitor performance.

Extend monitoring capabilities by developing our own monitoring applications or extending PMI.

Subtopics

Performance Monitoring Infrastructure (PMI)
Third-party performance monitoring and management solutions
Custom PMI API
Enable PMI data collection
Develop our own monitoring applications
Monitor performance with Tivoli Performance Viewer
Monitor performance with ITCAM for WAS
SNMP based performance monitoring for WAS
Capture a RMF workload activity report
RMF report examples
Monitor dispatch requests
WLM Delay Monitoring

Metric	Meaning
Average response time	Include statistics, for example, servlet or enterprise beans response time. Response time statistics indicate how much time is spent in various parts of WAS and might quickly indicate where the problem is (for example, the servlet or the enterprise beans).
Number of requests (transactions)	Enables you to look at how much traffic is processed by WebSphere Application Server, helping you to determine the capacity that we have to manage. As the number of transactions increase, the response time of the system might be increasing, showing the need for more system resources or the need to retune your system to handle increased traffic.
Number of live HTTP sessions	The number of live HTTP sessions reflects the concurrent usage of the site. The more concurrent live sessions, the more memory is required. As the number of live sessions increase, you might adjust the session time-out values or the JVM heap available.
Web server thread pools	Interpret the web server thread pools, the web container thread pools, and the Object Request Broker(ORB) thread pools, and the data source or connection pool size together. These thread pools might constrain performance due to their size. The thread pools setting can be too small or too large, therefore causing performance problems. Setting the thread pools too large impacts the amount of memory needed on a system or might cause too much work to flow downstream if downstream resources cannot handle a high influx of work. Setting thread pools too small might also cause bottlenecks if the downstream resource can handle an increase in workload.
The web and EJB thread pools
Database and connection pool size
Java virtual machine (JVM)	Use the JVM metric to understand the JVM heap dynamics, including the frequency of garbage collection. This data can assist in setting the optimal heap size. In addition, use the metric to identify potential memory leaks.
CPU	We must observe these system resources to ensure that we have enough system resources, for example, CPU, I/O, and paging, to handle the workload capacity.
I/O
System paging