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:
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