Hi Dojo,
Context
A correlation rule is in place to group certain alarms under a view and generate a new base alarm.
The base alarm is then used to forward an SNMP Trap to an external system (filtering on the correlation engine source).
Base alarm behavior
The experienced behavior is that the initial alarm state remains or is sticky, even though the parameter alarm state should be normal again.
E.G. The initial alarm was generated on 'Slot 12 Demodulator 30' for the value Disabled but now the value has changed to Enabled. Expected parameter alarm state would be Normal but the parameter alarm state instead remains Criticial.
Question: is there a way to update the base alarm so the critical alarm state dissappears on the initial parameter and doesn't impact other services?
Thanks in advance!
Hi Robin,
Unfortunately, there is no straightforward way to achieve the behaviour you are looking for.
This limitation comes from how the "New Alarm" action works. As defined, it always creates a new alarm on the same parameter of the same element as the first base alarm. Since the correlation rule can group alarms from multiple parameters and elements, any subsequent alarms become linked to the same correlated alarm—still anchored to that original parameter.
As a result, when the original alarm clears, the correlated alarm remains active until the entire correlation fully clears. This is the side effect you are seeing.
The (somewhat) good news is that a new "Group Alarm" action is currently in development specifically to address this type of scenario. However, we do not yet have a confirmed availability date.
Hi João, thanks for the clarification!