Trigger Properties

The Trigger page enables you to define the conditions in which an alert is sent for some traffic behavior on the object you specified in the Alert On & Filtering page. Triggers for static policies are defined in terms of discrete threshold values for one or more metrics. Triggers for adaptive policies are defined in terms of relative threshold values for one or more metrics. When an alert is sent, the corresponding trigger conditions are included in Email notifications, SNMP traps, and are shown in Alert Detail reports.

For any policy, you can compare up to three traffic metrics to alerting criteria to determine when an alert is triggered. One, two, or all three metric comparisons can be used to specify one, two, or three conditions. Possible combinations are:

◼ Use three metric comparisons to specify one condition. The results of all three comparisons must be true to trigger an alert. (The condition is the logical AND of all the metric comparisons that define it.)

◼ Use one metric comparison in each of three separate conditions. If the metric comparison in any of the three conditions is true, then that condition triggers an alert. (The policy uses the logical OR of all its conditions.)

◼ Use two metric comparisons in one condition and a third metric comparison in a second condition. An alert is triggered if either condition contains a metric comparison that is true. (This is logically the AND of two comparisons, OR'ed with a third comparison.)

1. In the Add a metric comparison section, choose a metric from the dropdown list and specify the values necessary to trigger an alert. The list includes only traffic metrics that are applicable to the type of group you specified in the Alert On & Filtering page for the policy to monitor.

2. Select the type of threshold checking to perform and specify the values for the metric that will trigger alerts. For example, a volume or rate that is only slightly problematic should trigger a minor alert, so enter that value in the Minor box.

3. If you want to add another metric comparison that must be met in order for the condition to trigger an alert, click “Add a metric comparison” to add another row. The condition is true only when all the comparisons are true. That is, the alert condition is the logical AND of all its metric comparisons.

4. If you want to add another condition that also can trigger an alert, click “Add a condition” to add another condition row. Then, add a metric comparison to that condition. If either condition is true, it triggers an alert. That is, the policy uses the logical OR of its alert condition specifications.

5. Specify the number of times over a period of minutes that a violation must occur before it triggers an alert. Refer to Alert Levels for an example of how this setting affects alerting.

6. Choose from the existing Business Hour Profiles if you want to constrain the triggering of an alert to a specific recurring time interval. (Business hour profiles are used with static comparisons, not with adaptive comparisons.)

1. In the Add a metric comparison section, choose a metric from the dropdown list and specify the values necessary to trigger an alert. This field is pre-populated with the metric you chose in the Alert On & Filtering page. The list includes only traffic metrics that are applicable to the type of group you specified in the Alert On & Filtering page for the policy to monitor. Specify Deviation factor values for the metric. These values, between 0.1 and 10, specify how many standard deviations from the mean the current measurement must be in order to trigger an alert at Minor/Major/Critical levels.

2. (Optional) Specify a minimum metric deviation value, in the metric’s units. This specifies a discrete minimum tolerance around the comparison window mean for the metric: measurements within the bounds of this value will not trigger alerts, regardless of the deviation factor values that are specified.

3. Review the river graph of the metric’s recent behavior. Specify the window of history to show (1 hour, 6 hours, 12 hours, or 1 day), and choose from the dropdown how far back from right now (the “lookback period”) you want to see that window (1 hour, 6 hours, 12 hours, 1 day, or 1 week). The graph will show that portion of the metric’s historical behavior, subject to its availability. In addition, the graph will show, in colored bands, the metric’s normal range and the deviation ranges you specified.

The default average for a window of history is based 50% on the previous instance of that window, and 50% on the total historical average for that window. Changing the lookback period changes the portion used to calculate the historical average, and may cause a period of instability (unexpected alerts or missed alerts) until the new historical data is assimilated.

4. Specify the number of times over a period of minutes that a violation must occur before it triggers an alert. Refer to Alert Levels for an example of how this setting affects alerting.

The level of an alert reported when a policy is violated is determined by conditions and metric comparisons. A condition can include one, two, or three metric comparisons.

A condition is true if all metric comparisons it contains are true. If a policy has two conditions and both are true, the policy generates an alert that is the higher of the two condition’s alert levels. For example, if one condition meets the criteria for a Minor alert and a second condition meets the criteria for a Major alert, the policy generates a Major alert.

A condition can contain one, two, or three metric comparisons. All the metric comparisons in the condition must evaluate to true for the condition to be true.

If the condition is true, its alert level is the level of the highest severity that is common to all its metric comparisons. This can be understood by asking “With what severity were the first metric comparison AND the second metric comparison violated?”

The alert level of the condition represents the highest severity at which the first metric comparison AND the second metric comparison were violated.

For example, assume that you want to monitor the load on a server. When it gets too high AND it is affecting the actual server response time, you want to be alerted. So you want to limit this policy to high server response time that is correlated with a high connection rate on the server. To do this you specify a condition that requires both metrics to exceed thresholds:

Assume that the server response time is 50, which exceeds the threshold considered to be a Major severity. Assume that the connection request rate is 200, which exceeds the Minor threshold but not the Major threshold. That is, for server response time, both the Minor and Major thresholds have been exceeded. But for connection request rate, only the Minor threshold has been exceeded.

So while it is true that server response time AND connection request rate Minor severity thresholds have been exceeded, it is not true that both server response time AND connection request rate Major severity thresholds have been exceeded. Therefore, the severity of the condition is Minor.

Regardless of what may be going on with the server response time, the correlation this policy is monitoring for (high server response time AND high connection request rate) has been detected at a Minor level.

You might have another policy for monitoring all cases of high server response time, and that policy will alert you to a server response time problem. This policy alerts you to a level of correlation you are looking for. While this correlation is something you are studying, you do not want a relatively minor level of correlation to raise a Major alert in the operations center.