After acknowledgement of an alarm the alarm should move from the alarm browser to an event history table (in the database).
Moving the acknowledged alarm to an alarm history table creates a 'state based browser' where the only events that are 'real and actionable' are left in the alarm browser.
Event correlation can also move events to the event history table.
Search and query should be available for the event history table, into a 'alarm history browser'.
If acknowledged alarms will be removed from active alarm list how they would be different from terminated? Idea is that alarm browser shows you all problems that are not solved yet. If your business process requires only two states, you can simply terminate alarms instead of acknowledging them.
Best regards,
Victor
The term 'acknowledged' comes from the Legacy HP OpenView Operations Manager product. When an alarm is 'acknowledged' it is moved to 'history' (a table i the database). Alarms within the 'alarm history table' can be deleted or archived.
Terminating an alarm in NetXMS deletes the alarm from the active alarm browser. We have a requirement to retrieve a list of historical alarms for any and all nodes. If the alarm is 'terminated' within NetXMS it appears that the alarm is permanently removed from NetXMS.
The ability to retrieve historical alarms provides for anomaly analysis. It would be great if a 'Node_up" alarm was recived; acknowledged the "Node_down" alarm, and both were then moved to history; keeping the active alarm browser 'state based'. State based mean that only valid alarms (needing attention) are in the active alarm browser.
Terminated alarms are kept in alarm log and cleaned by housekeeper (by default after 90 days, this period can be changed). You can access them via "Alarm Log" view or directly in database.
Best regards,
Victor