IBM Tivoli Composite Application Manager for Application Diagnostics, Version

ITCAM Agent for J2EE

IBM Tivoli Composite Application Manager for Application Diagnostics Agent for J2EE provides a Systems Management solution for the J2EE Application Server Version 6.2 for distributed platforms. Using ITCAM Agent for J2EE, you can monitor multiple J2EE application servers running on the same physical node. Each application server must be configured with its own IBM® Tivoli® Composite Application Manager (ITCAM) for J2EE data collector.

The Tivoli Enterprise Monitoring Agent collects performance data from the following four primary sources:

Attributes within the product collect data about the inner workings of an application server and performance information about user applications running under its control.

Initiating data collection and reporting of data

Because of high processor usage, 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 is not collected and displayed in the workspaces. Similarly, those attributes that collect request and application trace data require you to complete several configuration steps. To collect this data, use one of the following 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. Similarly, 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, ITCAM 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 are assigned to the application tier. All other request types (JNDI, JDBC, JCA, JMS) are assigned to the backend tier.

When ITCAM starts to monitor a new application, it automatically starts a baselining process. This process normally runs for seven days but provides updated information every hour from the beginning. During the process, ITCAM collects statistical data for all requests in this application. When 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. During the baselining process, the baselines get updated periodically, and the alarms/warnings start to correspond to real problems. You do not have 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 split broadly 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 the thresholds set before they are updated automatically for the first time, you can trigger a baseline update. This immediately sets the thresholds based on the request data collected so far.

Additional information

For additional usage information about this agent, see: