Idea ID: 2825479

Option to have archived alarms in DB for reporting

Status : Waiting for Votes
10 months ago

Need option to have the archived alarms in another table in the event database to have it for reporting or for audit purposes

Currently the alarms are archived to a files and if required we will have to have the restore from the file to see the alarms. This becomes difficult as we will not know in which file the specific alarm has been archived.

There should be an option in the exiting EVENT schema for another table with the archived alarms from which it can be downloaded to files. In this way we can have the alarms in a table for longer period for reporting and auditing whereby no affecting the active alarms and closed alarms which are maintained for a shorter duration 


Collect Once Store Once
  • A browser for archived events with search functionality like active/closed event browser may be a good idea here

  • Excellent idea. this way we can periodically arcive events and no need to keep millions of events in the event DB. This will also improve performance when working on closed events which are still in active database.

     - Not everyone works on Unix systems and working on files is laborious.

  • The archived events are stored in an xml file and doing a grep to search for a particular criteria is difficult. If it is in the DB it is easier to query the archive DB and to get the required events. You can run advanced queries if it is in the DB rather than files. If you know the event browser you can also have filters to get a list of alarms.

    Currently in the infrastructure setting there is already and option (with drop down) as file system. You could develop the required solution to archive it to the DB and have the option for user to select whether he wants to archive to file or DB

  • Simple grep for event id in  archive folder should give you in which file an event archived.

    like grep -R "<event id>" /root/archive