Hi Dojo,
I noticed something strange with the Correlation Engine for which I don't know if this is default behavior.
My setup has a Correlation Rule that executes a script when an alarm occurs on a spine switch element.
When I create 3 alarms on my element, by changing the Interfaces Admin Status, I notice that the script is only executed once.
Only when I enable option "Trigger on single events. Don't maintain active tree status." my script is executed for every change. But in that case it's also executed every time the alarm is cleared (I know that I can work around this by filtering on Alarm Severity).
My question is how far it's normal behavior that my script is only executed once while 3 unique alarms are created?
Hi Jens,
Since you are working with a table, have you tried grouping by table index?
Hi Jens,
When creating a correlation rule without any alarm grouping, all the alarms will be grouped by default in the same ‘bucket’. For that reason the correlation rule will only be triggered once. When adding alarm grouping (in your case grouped by table index) you will create a bucket for each row in the table, so actions will be executed per row
I’m so glad I found this – trying to figure out how we can leverage on this – but in that case, let’s say I have 2 different parameters in alarm on the same element, without alarm grouping, would they default to the same bucket? Or does it depend on how the filter is built?
Technically, I’d like to keep a different bucket (if it makes sense) for each different root alarm ID in the element, so that the rule can be reapplied for each new alarm on the element, but I can maintain the active tree status – not interested in having all the the different alarms, for different KPIs, grouped in the same alarm bucket, especially if my filter is built on “Parameter Description (by element)”
Hi Miguel, it works when grouping by table index. But why is that? I would expect that unique alarms have exactly the same behavior without the need of adding alarm grouping.