Hello Dojo,
Is there any section where I could read more about the default behaviour for custom alarm properties? Are these persistent for correlated alarms, so that the value can be retrieved also when the alarm is cleared or correlated (e.g. severity increased) ?
E.G. Let's say I have a custom alarm property named "Device ID",
listing the ID of the device (could be a DVE) where the alarm originates.
Once the alarm is cleared, should the device ID be kept in the alarm entry?
Or is it expected to be cleared?
My use case is based on correlated alarms built with data retrieved through a custom protocol:
apparently, there are cases when the device ID is missing; at present I'm not sure if this might be by design or if it might depend on how the value for the base-alarm is parsed in the correlation.
I have entries that list the expected value for the property, and other alarms where the values for the correlated alarm is missing.
At a first attempt to troubleshoot this, I'd say the base alarm has always a value for the required custom alarm property, nevertheless, I can't always retrieve a value for correlated or cleared alarms:
Any steer will be helpful
Hello Alberto,
When an alarm is cleared the alarm properties are cleared with it. This is currently by design mainly to free as much memory wherever possible.
Checked internally and we’ve decided to log this feature suggestion for evaluation:
Adding a new answer just to share an additional screenshot
(hiding internal info such as element names).
It seems correlated Alarms don't have the same behaviour of single ones:
for the single alarms, we're able to keep the custom property even when the alarm is cleared (circled in green here below).
Correlated alarm would seem a bit less predictable but, based on observation,
I'd say: they seem to keep the custom property at the first correlation cycle;
they're likely to lose the custom property at the second correlation cycle;
The first correlation on the same alarm, keeps the custom property value.
In this example a correlated alarm is generated whenever multiple traps are received from the same "device ID" (Custom Alarm Property).
Correlation rules behaviour / operational requirement:
The severity of the correlated alarm matches the one of the base alarm if there are just two traps from the same device ID; the correlated severity is then increased to major if the traps received for the same device ID are at least 3.
Any base-alarm "Cleared" trap for that ID would clear the correlated alarms.
No polling of these values is currently operated (not a fan of this, but it seems a device limitation at present).
Sharing this to better understand how this can evolve in terms of what is the default behaviour - in the short term, a fix might be to use some scripting to copy the missing values and make the properties persistent.
However, based on the above answer, adding the scripting would not entirely tie up with the general design: by default, where some alarm properties can be cleared to free up as much memory as possible, we'd then need more resources on the scripting side, for each alarm to preserve this info.
Wondering if in the long term it might be worth altering the protocol so that the "ID" we need is not passed as a custom alarm property, but is then concatenated to the parameter description when the trap is received.
Thanks for this first feedback, Davy – appreciated.
I had the same impression, but I haven’t (ab)used much the alarm properties in the past and when I needed specific info to be carried across I got used to getting that piece of info embedded as part of the parameter description
(otherwise operators would need way too many columns on their console).
This post didn’t drag much attention – unfortunately.. but I actually get a random behaviour with the same alarm property sometimes being missing and some other times showing the expected value also for a cleared alarm.
Starting to think this might depend on the different way the incoming trap might be parsed … will log it with our squad.
Adding a screenshot as a separate answer