IBM Tivoli Composite Application Manager for Application Diagnostics, Version 7.1.0.1
Tune data collector performance and monitoring scope
Data collector monitoring introduces a performance overhead. When more information is gathered, performance overhead is increased.
The monitoring scope is broadly determined by the monitoring level, which the user can set as necessary.
- In the Tivoli Enterprise Portal, monitoring levels are L1 and L2.
- In the Visualization Engine, monitoring levels, known as Monitoring On Demand (MOD), are L1, L2, and L3.
This level is set independently for IBM Tivoli Monitoring and the Managing Server. For example, the user may set monitoring level L1 for IBM Tivoli Monitoring from the Tivoli Enterprise Portal, and at the same time set MOD L2 in the Managing Server Visualization Engine. In this case, only L1 data will be available in the Tivoli Enterprise Portal, but L2 information will be displayed in the Visualization Engine.
You can set the sampling rate for the Managing Server and Monitoring Agent independently. For the Managing Server, the sampling rate determines the percentage of monitored requests that are archived in the database; irrespective of the sampling rate, all data is sent to the Managing Server, so the resource usage of the data collector is not affected by it. The sampling rate is set separately for every data collector installation. Having a low sampling rate does not prevent the user from seeing requests that have hung in-flight, nor does it prevent Managing Server traps and Tivoli Enterprise Portal situations from working on all requests. Generally, a 2% sampling rate is suggested for MOD L1 Tivoli monitoring data collection in a production environment where data is often stored for 15 to 30 days or more.
For Managing Server data collection, the sampling rate does not apply to Custom Request and Nested Request monitoring.
You can also fine tune the data collector monitoring process using the properties files. This impacts the performance overhead, as well as the scope and accuracy of the monitoring. While the default configuration is broadly acceptable for common situations, you can use the properties files to reach the performance and monitoring that closely match the requirements of your environment.
See
- Data collector internal buffering and turbo mode settings
- Enable instrumentation and monitoring of RMI/IIOP requests between application servers
- Disable various types of Byte Code Instrumentation for J2EE APIs
- Lock analysis, memory leak analysis, and method profiling and tracing
- Define custom requests
- Enable Asynchronous Bean request monitoring
- Customize monitoring of custom MBeans
- Modify PMI settings
- Enable PMI settings for the Service Integration Bus
Parent topic:
Customization and advanced configuration for the data collector