8.3 Deployment, configuration, and ARM data collection

< Day Day Up >

There are four different type of components that can deployed to a single Management Agent. It is possible of deploy all four components to the same system. They are:

Synthetic Transaction Investigator
Quality of Service
J2EE
Generic Windows

Once deployed, monitoring is activated by configuring and deploying different sets of monitoring specifications, known as policies, to one or more Management Agents. The monitoring policies include specifications directing the monitoring components to perform specific tasks, so the specific monitoring component referenced in a policy has to have been deployed to a Management Agent before the policy can be deployed.

IBM Tivoli Monitoring for Transaction Performance Version 5.2 operates with two types of policies:

Discovery policy

The discovery component of IBM Tivoli Monitoring for Transaction Performance enables identification of incoming Web transactions that may be monitored. When using the discovery process, a discovery policy is created, and within the discovery policy an area of the Web environment that is under investigation is specified. The discovery policy then samples transaction activity from this subset of the Web environment and produces a list of all received unique URI requests, including the average response times that were applied during the discovery period. The list of discovered URIs may be consulted in order to identify transactions that are candidates for further monitoring.

Listening policy

A listening policy collects response time data for transactions and subtransactions that are executed in the Web environment. Running a policy produces detailed information about transaction and subtransaction instance response times. A listening policy may be used to assess the experience of real users of your Web sites and to identify performance problems and bottlenecks as they occur.

Automatic thresholding

IBM Tivoli Monitoring for Transaction Performance Version 5.2 implements a new concept of automatic thresholding in both discovery and listening policies. Every node on a topology (group nodes as well as the final-click nodes) has a timing value associated with it. The final-click node's timings will stay the same, but the group node's timings will now be the maximum timing contained within that group.

The worst performing overall transaction is marked Most Violated. A configurable percentage (default 5%) of topology nodes is marked with the Violated interpreted status to show other potential areas of concern. If only one node in the whole topology is to be marked, it is the Most Violated node and there will be no Violated nodes.

The Topology algorithm does not rely on timing percentages to determine what is Violated and Most Violated. Instead, it compares the absolute difference between the instance and aggregate timing data while subtracting the sum of the values of the children instances. This provides for a more accurate estimate of the worst performing subtransaction, because it is an estimate of the time actually spent in the node.

The value calculated for each node is determined by the formula:

[(sum of transaction's relations instance time) - (sum of children instance time)] - [(sum of transaction's relations aggregate time) - (sum of children aggregate average)]

This will provide a value in seconds that is an approximation of time spent in the node (method).

The transaction with the greatest of these values will be the Most Violated. The top 5% (by default) of these transactions will have status Violated. The calculated values will not be shown to the user. If a node has a zero or negative value when (sum of transaction's relations instance time) - (sum of transaction's relations aggregate time) occurs, then it will not be marked. The reason for this is because a negative value implies the node performed below its average for the hour, and hence cannot be considered slow.

Intelligent event generation

Enabling this option can reduce event generation. Intelligent event generation merges multiple threshold violations into a single event, making notification and reports more useful. For example, a transaction might exceed and fall below a threshold hundreds of times during a single monitoring period. Without intelligent event generation, each of these occurrences generates a separate event with associated notification.

< Day Day Up >