IBM Tivoli Composite Application Manager for Application Diagnostics, Version 7.1.0.1
Set an Application trap using the Resident Time - Misbehaving Transaction target type
A Resident Time - Misbehaving Transaction is a target type for an Application Trap. With this target type, when the resident time of a request violates the specified level in the trap definition, the monitoring level for that specified request switches from L1/L2 to L3. For all the subsequent resident time violations for that request, method trace detail is captured.
This target type provides an efficient means of collecting method trace detail at L3 as you can configure the data collector to return to L1/L2 after the threshold is reached a certain number of times within a given time period, thereby reducing the performance cost to the data collector. This target type also provides a dynamic means of collecting method trace detail as detail is collected at the time the problem is occurring.
Set an Application trap with a Resident Time - Misbehaving Transaction target type:
- From the top navigation, click...
Problem Determination > Trap & Alert Management | Create Trap
- Select Application Trap as the trap type.
- Select Resident Time - Misbehaving Transaction as the target type.
- Click Next. The Step 2 - Define Trap page is displayed. In the Threshold field, enter a value. This value is the complete request response time expressed in milliseconds. When a transaction reaches this value, the trap is triggered.
- In the By Request field, choose Request Contains and then enter the value *. When the By Request field contains the value *, the Resident Time - Misbehaving Transaction trap will deactivate after every request has reached the specified number of occurrences as specified in the Number of occurrences of every request after which the trap will be deactivated field.
- Click Next. The Step 3 - Set Trap Alerts page is displayed. In the Severity field, select a severity level. The application monitor has three severity levels. Since the application monitor provides SNMP integration with Tivoli, map the three severity levels of the application monitor to the warning levels of Tivoli listed in the following table:
ITCAM severity level Tivoli warning level Low Harmless Medium Minor High Critical
- In the Alert Action(s) section, choose how and to whom you wish to communicate details of the trap threshold being reached. You can choose e-mail, SNMP or both.
- Select Collect Component/Method Trace.
- Click Add to add the alert to your trap. In the Name section, enter a name and a description for the trap. Click Save & Activate. The Activate page is displayed
- In the Server Selection section, select the servers you wish to monitor for this trap.
- In the Alert Suppression Settings section, enter the amount of time you want to delay alerts after the first alert is sent. Click the Trap Default radio button to use the default suppression for the trap, or click the Override Default radio button to set a specific suppression duration for this particular trap activation. If you do not want to suppress any alerts, enter a value of 0, or leave the field blank.
- In the Deactivation Settings section, there are 2 fields. Here is a description of each field:
Number of occurrences of every request after which the trap will be deactivated
The purpose of this field is to prevent the data collector from running at L3 indefinitely. The value in this field determines the number of times you want every request to reach the threshold before the trap is deactivated. Using this field enables you to capture component/method trace detail at L3 when the threshold is exceeded, and to then automatically revert to the original monitoring level, thereby reducing the performance cost to the server.
A problem can occur if this value is not reached. If the Number of occurrences of every request after which the trap will be deactivated value is not reached, then the server will remain at L3 resulting in a continuous performance cost. To prevent this from happening use the field - Number of consecutive non-violating requests after which mod level is reverted back and trap deactivated.
- Number of consecutive non-violating requests after which mod level is reverted back and trap deactivated
Once L3 is enabled, after the trap condition is violated the first time, it remains at L3 until the request violates for the predetermined number of times as set in the Number of occurrences of every request after which the trap will be deactivated field. As a result, the request in the data collector will remain at L3 if the request doesn't violate for the predetermined number of times, resulting in performance cost to the data collector. To prevent this, use this field - Number of consecutive non-violating requests after which mod level is reverted back and trap deactivated. Once the trap triggers and the monitoring level switches to L3, if the number of requests that does not reach the threshold is equal to the value in this field, then the trap is deactivated. A field for this value is also displayed in the Active Traps table in the Trap and Alert Management page. The field is Non Violating Requests Left, it indicates the number of occurrences of non violating requests before the trap is deactivated.
- Click Activate to activate the trap.
Results
Parent topic:
Trap and alert management
Related topics
Activate a trap
Set a Server Resource trap
Setting an Application Trap