What is alarm debouncing?

Overview

Bouncing alarms, or flapping alarms, occur when an alarm is raised and cleared several times by the network within a short period of time. For example, an alarm can be generated several thousand times in a 24–hour period. When an alarm is generated, the alarm is typically cleared very shortly after being raised.

Alarm debouncing using the NFM-P allows you to detect and reduce the number of deleted, or cleared, alarms that are logged in the historical database, while allowing alarm events and related statistics to be kept up to date.

You can configure debouncing on alarm policies for implicitly cleared alarms only, that is, alarms which are automatically cleared by the NFM-P when a condition is met. You can configure alarm debouncing only on policies for which the auto-deletion rule cannot be configured, in which case “N/A” appears under the Auto Deletion Rule column on the Policies tab of the Alarms Settings form. Alarm debouncing is not configurable for policies for which No Deletion Rule or a configured deletion rule appears under the Auto Deletion Rule column on the Policies tab of the Alarm Settings form.

Although alarm events that occur are processed normally when alarm debouncing is enabled, alarm clear events that occur are not processed immediately. The alarm clear events are held in a separate cache until the hold period, which you configure in the debouncing policy, has elapsed. If another clear event occurs before the hold period has elapsed for the previous clear event of the same alarm, the more recent clear event replaces the older clear event in the cache. After the hold period has elapsed, the alarm clear event is removed from the cache, queued and processed.

If an alarm clear event is on hold in the cache and an alarm raise event for that same alarm is received, the clear event is removed from the cache and dropped. Because the alarm was not cleared and not raised again, the raise event is processed as an update event and the existing alarm instance is updated.

When an escalation policy uses the “Delete Alarms when Cleared” default option for the Automatic Alarm Deletion Settings parameter, the escalation policy is not applied, unless alarm debouncing is enabled for the particular alarm type. See How do I configure alarm severity and deletion behavior? for more information about how to configure escalation policies.

See How do I configure alarm debouncing ? for information about how to configure alarm debouncing policies.

Note: E-mail notifications that you can configure send E-mails for alarm create events. However, if you have enabled E-mail notifications for alarm events and alarm debouncing is also enabled, any new alarms that are raised within the debounce interval are handled as an update and not a create event, and no E-mail is sent.

Purging the debouncing cache

By default, up to 5000 clear events for different alarms can be held in the debouncing cache at one time.

When the alarm debouncing cache reaches capacity with excess bouncing alarms, the NFM-P raises the AlarmDebouncingThresholdReached alarm. When this occurs, alarm debouncing is temporarily disabled and at least 70% of the alarm clear events that are being debounced are processed immediately. Alarm debouncing is re-enabled after the processing of cached events completes.

XML API and alarm debouncing

When debouncing is enabled, JMS listeners handle alarm events received differently from when debouncing is disabled. For example, when a raise/clear raise/clear raise/clear sequence occurs when debouncing is not enabled, JMS listeners receive and handle one update event, but the three clear events are processed by the NFM-P, and three historical alarms are logged. When this sequence occurs when debouncing is enabled, JMS listeners receive and handle a raise, update, update, clear, and only one clear event is processed by the NFM-P.