IBM Tivoli Composite Application Manager for Application Diagnostics, Version 7.1.0.1

Set an Application trap


An Application trap detects metrics in a request, method, or SQL or MQI call. The system triggers the trap after the monitored server exceeds the threshold for the metric you set. When the trap is triggered, and when the action conditions are met, then any alerts you have activated (whose conditions have been met) will be sent, and any actions you have specified (whose conditions have been met) will be performed.


Set an Application trap:

  1. From the top navigation, click...

      Problem Determination > Trap & Alert Management > Create Trap > Application Trap

  2. Select one of the Target Types from the list box. Based on the target type you select, the system will dynamically generate the trap definition options in the next step. The following is a list of the Target Types:

    • Occurrence

      The number of times the specified unit occurred. The Occurrence trap has three available filters; By Request; By Method, and By SQL.

    • CPU Time

      The amount of time the CPU is executing instructions. The CPU Time trap has two available filters, By Request and By Method.

    • Wait Time

      The amount of time the CPU is idle. The Wait Time trap has two available filters, By Request and By Method.

    • Resident Time - In-flight

      Based on the resident in-flight time of a transaction, the Publish Server keeps track of all the active (in-flight) requests and their resident times and triggers the trap if the resident time of the request exceeds the time configured in the trap condition. The Resident Time - In-flight trap has one available filter, the By Request filter.

    • Resident Time - Completed

      The wall clock time for when the unit of a transaction, method, etc. ends, minus the wall clock time when it started. The Resident Time - Completed trap has three available filters; By Request; By Method, and By SQL.

    • Resident Time - Misbehaving Transaction

      This trap has one available filter, the By Request filter. With this target type, when the complete response request time violates the threshold in the trap definition, the monitoring level for the request switches from L1/L2 to L3 and component/method trace detail is captured. As switching from L1/L2 to L3 has a performance impact on the data collector, there are 2 fields you can use to deactivate the trap and return to the original L1/L2 monitoring level once the required detail has been captured:

      • 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.

      • Number of occurrences of every request that doesn't violate this trap after which mod level is reverted back and trap is 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 occurrences of every request that doesn't violate this trap after which mod level is reverted back and trap is 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. For further detail on this target type, see Set an Application trap using the Resident Time - Misbehaving Transaction target type

    • Uncaught Exception

      Capture exceptions that occur in applications and data about the failure. The Uncaught Exception trap has three available filters; By Request, Exception or Error Class Name.

    • Lock Acquisition Time - In-flight

      The in-flight transaction has not completed and might be hanging, using this type will provide data on how to fix the problem. What is being measured is the amount of time taken to obtain an acquisition. The acquisition clock starts when the class/method begins trying to acquire the lock, and ends when the lock is acquired. The Lock Acquisition Time - In-flight trap has two available filters, By Request and By Method.

    • Lock Acquisition Time - Completed

      The amount of time taken to obtain an acquisition. The acquisition clock starts when the class/method begins trying to acquire the lock, and ends when the lock is acquired. The Lock Acquisition Time - Complete trap has two available filters, By Request and By Method.

    Traps are now supported in CICS. CICS has the following trap types available: Occurrence, CPU time, Resident Time - Completed, Resident Time - In-flight, and Wait Time.

    By default, the Publish Server does not process requests which run longer than 5 minutes. Therefore, if an application trap's threshold is greater than or equal to 300 seconds, the trap will not be triggered. To change this default setting in the Publish Server, in the psX.properties file, change the TIMEOUT_LIMIT property to greater than 5 minutes as required. The properties files for the Publish Servers are located here: MS_HOME/etc/. They are named with the convention psX.properties, where X is an integer. By default, there are 2 files, ps1.properties and ps2.properties, if you add another Publish Server instance, the properties file will be called ps3.properties and for all additional instances of the Publish Server, the integer value in the properties file name will increment by 1.

  3. Click Next. The Step 2 - Define Trap page opens.

  4. Complete the rest of the fields in the Trap Definition section, which restrict which events will trigger the trap to fire.

  5. Click Next. The Set Trap Alerts page opens.

  6. For the Trap Alert settings, under Condition enter the number of times the trap will occur before the system takes an action. Specify the amount of time under Time Interval to monitor how many times the trap met its conditions.

  7. Click to select the serverity level from the list box. 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

  8. Select an action or multiple actions, such as sending an e-mail or SNMP message, for the system to take when the condition is met.

  9. Select one or all Data Actions, such as Component/Method Trace, Stack Trace, or Thread Dump (not applicable to the Windows platform), to get detailed information. We recommend that you select Component/Method Trace as the data action, since a request executes quickly and it is difficult to catch before completion. Make sure that you have selected L3 monitoring level if you choose to collect Component/Method Trace as the Data Action. When setting a trap, you can select multiple trigger conditions and alerts for each action set. Each trap is required to have at least one action but may have multiple actions set. Thread Dump is not available for CICS.

  10. Click Add to add the alert to your trap. If you select Component/Method Trace as the Data Action for an In-flight-based trap, the method trace might contain a "-1" for Depth on some events in the method trace. In-flight transactions, by definition, are incomplete transactions, so the request stacks of those transactions will be incomplete.

  11. Set the Default Suppression settings by entering the amount of time you want to delay alerts after the first alert is sent.

  12. Click Next to proceed. The Name Trap page opens.

  13. Enter a name and descriptive text for your trap.

  14. Click either Save or Save & Activate.

  15. If you click Save, the Trap and Alert Management page opens displaying your new trap.

  16. If you click Save & Activate


Parent topic:

Trap and alert management


Related topics

Activate a trap
Set a Server Resource trap