Dear Dojo Community,
we have a couple of Generic Syslog Receiver elements set up in our DMS. Alarms are being triggered on these elements based on specific alarm configurations. To clear an alarm in a Syslog element typically another alarm configuration is used to set it back to alarm state "normal".
There are also a couple of Syslog devices, that send only a Syslog message in case there is an issue, e.g. a PSU failure. When the device state is normal again no “clearing” Syslog message is sent by these devices. Thus the current alarm state of the related alarm remains in the defined severity/state. Masking the alarm is not an option as this would hide a prevent the element from going into alarm state for new incoming alarm syslog messages for this alarm configuration.
Is there an option to manually clear this alarm or is it inevitable, that the source sends a clearing syslog to set the state back to normal again? The "manual override state" in the alarms table has no effect on the current alarm state of the element.
Hi Andre,
This is just a rough idea, but if you have an Automation and Correlation Module, you can use this to analyse and process the alarms from the Syslogs.
When an alarm is normalised, you can configure the device to send an Informational Syslog message to DataMiner, and the Correlation can "catch" the message every time it is received. Based on this, the Correlation can be configured to trigger an Automation Script.
In the Automation Script, the newly received Syslog message can be processed where the warning message can be compared with the previous Syslog. The script will set the table to change the severity, which can clear the alarm in DataMiner.
We solved this now in the only correct way and contacted the vendor of the Syslog source to add "Alarm clear" Syslog messages. This allows us to use the Generic Syslog Receiver element in the default way to clear active alarms.
Hi Jeeva,
many thanks for your feedback. The same would be possible with the Alarm Config Table. The issue is simply, that currently we do not get a Syslog from the Device, when an alarm condition went back to normal again. So we are missing the trigger.
A “Manual Aknowledge” of an active alarm would be ideal in such a situation.