Synthetic metrics, rules, and events
TrueSight Synthetic Monitor generates events based on a system of metrics and metric rules. The metrics measure the results of a transaction. Metric rules use the metrics to define thresholds for issuing events. Four global metric rules, applicable to all transactions, are included out-of-the-box, and more specific metric rules can be defined on application, Execution Plan, transaction, and location levels. TrueSight Synthetic Monitor also includes a less-robust event generation mechanism using SLAs.
This topic describes the following:
Metrics are measurements of a transaction. TrueSight Synthetic Monitor continuously measures the results of your synthetic transactions and compiles statistics for each metric. You can then use these statistics data to set event thresholds for the metrics.
TrueSight Synthetic Monitor includes two types of metrics:
- Error metrics - Count the number of errors of a certain type that occurred during the transaction. Error types include Availability, Accuracy, and Execution. It is not possible to define additional error metrics.
- Performance metrics - Measure latency of the entire transaction or the latency of a specific timer defined in the script.
The following table describes the four basic metrics that are available for all transactions:
|Performance||End-to-end latency of the transaction measured in seconds|
Number of availability errors in the transaction
Availability errors occur when the application does not respond, or when the application responds with an error that indicates it is unavailable. The number of Availability errors provides information regarding whether the application is running and whether it provides basic responsiveness to client requests.
Number of accuracy errors in the transaction
Accuracy errors are calculated with the assumption that monitored applications are working as designed and that the information transmitted to clients is correct. Functions that can be evaluated to determine accuracy include link checking, content validation, title validation, and response data verification. If a monitoring script contains customized functions that are used to ascertain system accuracy, those functions are factored in as well.
Number of execution errors in the transaction
An execution error indicates that there were problems with the script execution. It does not indicate anything about the health of the application.
If you have Execution errors configures to be counted as Availability errors (see Reclassifying Synthetic Monitor Execution errors and Accuracy errors as Availability errors for more details), this metric is irrelevant.
In addition to the basic metrics, page timers and custom timers that are defined in your scripts are measured. You can define rules based on the results measured for the timers. Page timer and custom timer metrics are measured in seconds. The Execution Plan must have run at least once for the timers defined for that Execution Plan to be available as metrics.
A metric rule is a set of definitions for generating events. Based on the events generated by the metric rules, notifications are issued, the status of the application is updated accordingly, and the events can be viewed on the Synthetic Health tab.
Status in the Application View tab is not updated based on synthetic metric rules.
A metric rule consists of a metric, thresholds, and scope.
- Metrics are defined in the previous section of this topic. When you select a metric for your metric rule, you can see the historic satistics for the metric to help you set realistic thresholds for the metric rule.
- Thresholds are the levels beyond which events are generated. Thresholds consist of a measured level and a number of consecutive occurrences. For example, a threshold for a Performance metric rule may be latency of 10s for two consecutive executions of a transaction.
There are two levels of thresholds, minor and critical. Defined critical thresholds must always be higher either in measurement or in consecutive executions than minor thresholds.
- The scope of the metric rule consists of the application, Execution Plan, transaction, and location to which it is applied.
For all levels except for application you can apply metric rules to a single entity or Any. User-defined metric rules must be set to a specific application.
For example, if you select Any Execution Plan, a breach of the defined threshold by any Execution Plan of the selected application generates an event. If you select a specific Execution Plan, only that Execution Plan generates an event.
There are four global metric rules, that correspond to the basic metrics. The four global metric rules are automatically applied to Any application, Any Execution Plan, Any transaction, and Any location. This cannot be modified.
The following global metric rules are included out-of-the-box:
You can modify the thresholds, and notification settings of the global metric rules, or activate/deactivate them. You cannot delete global metric rules.
You can define more specific metric rules at the application, Execution Plan, transaction, or location level. More specific metric rules always override more general metric rules, and only one metric rule is applied to a given transaction for each metric. For example, if you define an Availability metric rule for a specific application, the global Availability metric rule is no longer applied to that application. If you define an additional Availability metric rule for one of the application's Execution Plans. Only the Execution Plan-level Availability metric rule is applied to that Execution Plan. The application-level metric rule is applied to all other Execution Plans for that application, and the global Availability metric rule is applied to other applications.
Each metric rule must apply to a unique combination of application, Execution Plan, transaction, metric, and location.
For example, if you define a metric rule that measures Performance for:
- Execution Plan:
You cannot define another Performance metric rule for the same combination of
You can deactivate or activate any metric rules, including the global metric rules. Deactivating a metric rule means that no events are generated and no notifications are issued by the deactivated metric rule. If a metric rule is deactivated, and a more general metric rule covering the same metric is active, the more general metric rule takes effect. For example, if an Execution Plan-level Availability matric rule is disabled, an application-level metric rule may be applied instead.
TrueSight Synthetic Monitor includes SLA definitions that can generate events.
- SLAs generate events for the basic metrics: Performance, Availability, Accuracy, and Execution. SLAs cannot be defined for page timers or custom timers.
- SLAs generate events based on a percentage of executions that have a particular kind of error within the defined time frame. SLAs do not generate events based on a single execution or a specific number of executions.
- SLAs can be defined at the application level, and the Execution Plan level only.
- No historic data is stored based on the SLAs.
- SLAs do not include the ability to generate an event for consecutive occurrences of a threshold breach.