Rising, falling and reset thresholds

In most events, you define a threshold value, which indicates when an event should start. For example – in case of service it defines how slow a service can be before it triggers an event.

In case of some event types you also have to define the “reset” threshold for the event. This is important – otherwise an alert would be generated every time the condition is met. That could cause the same alert to be repeated every minute. The measured value must first fall below the reset threshold before the next alert is generated.

The red line indicates the alert threshold. When the response time or packet loss rate rises above this threshold, an alert will be generated. But for the next alert to be generated, this value must fall below the reset threshold. This prevents repeated alerts for the same event.

Rising and falling thresholds

The threshold discussed above is called rising, because it is generated when a measured value rises above it. But you can also define an event when a value should stay above a threshold. Then an event is generated when this value falls under a threshold and such threshold is called falling.

Note

•The reset threshold may not be higher than the alert threshold for rising thresholds and lower for falling thresholds.