ITCAM for Application Diagnostics, V7.1.0.1

ITCAM Agent for WebSphere Applications


Overview

Use ITCAM Agent for WebSphere Applications to monitor WAS appservers running on the same physical node. Each appserver is configured with its own data collector.

ITCAM Agent for WebSphere Applications is a component of ITCAM for Application Diagnostics v7.1.

The Tivoli Enterprise Monitoring Agent collects four types of data through the data collector embedded in the WAS process:


Initiating data collection and reporting of data

Because of high overhead, some data items are not automatically collected and reported. The collection of some data and statistics depends upon the setting of instrumentation levels for certain attributes. If the instrumentation levels are not set appropriately, certain information will not be collected and displayed in the workspaces.

Use one of these methods to reconfigure data collection:


Automatic baselining

To display application health status, ITCAM monitors request response times (averaged over a sampling interval, by default 60 seconds) for every application. Every top-level request available in an application is monitored separately.

For every request, two thresholds are set, known as fair and bad. When at least one average request response time for an application rises over the fair threshold, a health warning (yellow) for this application is reported. In the same way, when at least one average request response time rises over the bad threshold, an application health alarm (red) is reported.

ITCAM also monitors the "nested" requests (for example, database calls) within every top-level request. In the event of a warning or alarm, it checks which of the nested requests is taking more than its usual share of time. Depending on the type of such nested requests, ITCAM shows whether the client, application, or backend tier is the likely cause of the warning/alarm. Servlet and Portal request types are assigned to the client tier; EJB and User (Custom) request types, to the application tier; all other request types (JNDI, JDBC, JCA, JMS) to the backend tier.

When ITCAM starts to monitor a new application, it automatically starts a baselining process. In this process, which normally runs for 7 days but provides updated information every hour from the beginning, ITCAM collects statistical data for all requests in this application. Once the data is collected, ITCAM sets the thresholds automatically; it also records the typical share of response time for each nested request type.

In most cases, this automatic setting is adequate. When the 7 days are past, the alarms/warnings will correspond to real problems. There is no need to adjust baselining settings when things are working normally. (The automatic thresholds usually become usable earlier, after the application has been observed through its typical load patterns). If you need to acquire thresholds, based on whatever data is available, before the hourly automatic update, you can manually update baselining.

However, in some situations the threshold levels can become inadequate. This results in either too many false alarms/warnings, or in real problems going undetected. Such situations can be broadly split into two categories:

As a last resort, you can also override the thresholds with fixed values. However, do not do this unless you know a lot about the monitored application, or unless instructed by IBM Level 3 Support.

If you need to have the thresholds set before they are updated automatically for the first time, you can trigger a baseline update. This will immediately set the thresholds based on the request data collected so far.


Additional information


Parent topic:

User Guide

+

Search Tips   |   Advanced Search