IBM Tivoli Composite Application Manager for Application Diagnostics, Version 7.1.0.1
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 have been 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:
- Response time data for application server requests from the ITCAM for J2EE data collector
- Resource data from the Performance Monitoring Infrastructure (PMI) of J2EE
- J2EE Application Server log messages
- Garbage-collector activity recorded by the JVM's verboseGC trace
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 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. Similarly, those attributes that collect request and application trace data require you to complete several configuration steps. To collect this data, use one of these methods to reconfigure data collection:
- Complete configuration steps
- Issue Take Action commands, with which you can take specific action against your J2EE application server using the Tivoli Enterprise Portal.
- Use Manage Tivoli Enterprise Services (as explained in the various IBM Tivoli Monitoring installation manuals and the ITCAM Agent for J2EE installation and customization guide).
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:
- If some time has passed since the baselining process for an application, its response times might have changed because of configuration alteration, database growth, changing load patterns, and so on. In this case, you may need to run the baselining process again. It is good practice to do it after any configuration or infrastructure change.
- If the thresholds are incorrect immediately after the baselining process has been completed, you may need to adjust the auto threshold settings.
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
- Workspaces for ITCAM Agent for J2EE
- Attributes for ITCAM Agent for J2EE
- Situations for ITCAM Agent for J2EE
- Take Action commands for ITCAM Agent for J2EE
- Glossary for ITCAM Agent for J2EE
Parent topic:
User Guide