App Visibility Manager enables you to follow up on transactions that repeatedly violate performance or availability thresholds by "escalating" the transaction entry point. With the default setting, a transaction is escalated after the entry point breaches performance or availability thresholds three times in a row. The system automatically records the transaction three more times, regardless of other values that determine transaction collection. The information in the escalated transactions can help you determine the root cause of the problem.
You can modify the escalation properties.
Set the escalation behavior with the following properties.
Property | Description |
---|---|
use.runtime.escalation | Enable or disable the transaction escalation feature Default is true; if false, all other escalation properties are ignored. |
escalation.trigger.threshold | Number of consecutive transaction violations to trigger transaction escalation Transaction violations can be any combination of performance (breached thresholds) or availability (exception errors) issues, and the transactions are not limited by time. That is, if transaction violations are consecutive, it does not matter if they are over minutes, hours, or days. Default is 3 (default in the Max policy is 10) |
escalation.collection.samples | Number of recorded (persisted) transactions after escalation is triggered Transactions are recorded whether they have violations or not. Default is 3 |
escalation.modifiers | (agent for Java, only) Comma-separated list of modifiers that, when escalation is triggered, are added to rules applicable to methods in saved transactions By default, the added modifiers ensure that the Java transactions are not trimmed. Outgoing tags also mark the transaction as escalated. Default is |
escalation.disabled.period | Time, in milliseconds, to wait before another transaction escalation can be triggered Default is 300000 (5 minutes)
|