How to Purge Alarms? How to schedule purging of Alarms? (4289502)

Question 1: How to Purge Alarms?

Note: All procedures below remove ALL alarm types (all severity, all cleared/uncleared, all acknowledged/unacknowledged) - there is no method to selectively purge Alarm types.

Note: jmx-console usage only allows the 'foglight' user login.  Contact Support if there are difficulties accessing the jmx-console.

Purge all alarms using jmx-console:

1. http://fms_hostname:8080/jmx-console
2. service=Alarm
3. void purgeAllAlarms( )
4. Invoke

Purge alarms, date range, using jmx-console:

1. http://fms_hostname:8080/jmx-console
2. service=Alarm
3. void purgeAlarms( )
4. P1 - start datetime, P2 - end datetime

   In the format: YYYY-MM-DDThh:mm:ss.SSSZ

   Example:  2020-01-01T00:00:00.000Z (Z represents that the time is in UTC)

Purge alarms, date range, using script  & Script Editor:

Go to Admin Console | Tooling | Script Editor | paste the following into 'Script' box | click 'Run'  (note:Query or Object ID do NOT have to be filled in):

long now = System.currentTimeMillis()
Calendar threshold = Calendar.getInstance();
threshold .add(Calendar.DATE, -60)
server.get("AlarmService").purgeAlarms(new Date(0), threshold.getTime());
"done in "+(System.currentTimeMillis()-now)/1000+"s"

Purges alarms older than 60 days.  To change days, modify the "-60" above before running.

Purge alarms, date range, using script  & Command Line:

1. Place the following text into a .groovy file (simple text file).  Name it purgeAlarm.groovy and save it in the \FMS_Home\bin\  directory.....

   long now = System.currentTimeMillis()
   Calendar threshold = Calendar.getInstance();
   threshold .add(Calendar.DATE, -60)
   server.get("AlarmService").purgeAlarms(new Date(0), threshold.getTime());
   "done in "+(System.currentTimeMillis()-now)/1000+"s"

   This purges alarms older than 60 days. To change number of days, modify the "-60" above before running.

2. Run the following command at the command prompt.  Replace the '-pwd pass' and '-port port' for your environment.

   Windows OS:

   [FMS_HOME]\bin\fglcmd -usr foglight -pwd foglight -port 8080 -cmd script:run -f purgeAlarm.groovy

   Unix OS:

   [FMS_HOME]/bin/fglcmd.sh -usr foglight -pwd foglight -port 8080 -cmd script:run -f purgeAlarm.groovy

   Results will show something like  "done in 0.218s" if script ran correctly.

3. All Alarms greater than 60 days should now be gone from Alarms dashboards.  Note:  A few refreshes may be required in the Alarms dashboards for changes to be seen - alternately, sign out of Admin Console and back in, or try changing time ranges and/or filters on Alarms dashboards.

Question 2:  How to schedule Purge of Alarms?

Use the above procedure, "Purge alarms, date range, using script  & Command Line" to create a script and setup the command to run on a scheduled basis in via OS (Windows=scheduled task, Unix=cron job).  This can be done by the Operating System admin.

Question 3: Why does Support not recommend simply truncating the alarm_alarm table?

Recognizing that truncating avoids the transaction log and is much faster, Support doesn't recommend truncating the alarm_alarm table because TRUNCATE TABLE is a DDL command and it cannot check to see whether the records in the table are being referenced by a record in the child table (alarm_loc_msg). A "DELETE FROM" also doesn’t reset auto-incrementing columns. A truncate does. They are not functionally equivalent.

NOTE: In some database platforms there is a foreign key constraint on the alarm_alarm table preventing a simple truncate of the table.

This is why DELETE works and TRUNCATE TABLE doesn't: because the database is able to make sure that it isn't being referenced by another record.

If a user chooses to proceed then this should be left the customer’s DBA as the process would be considered out of scope for Support. The DBA should however consider only doing so as a one time event to clear off the backlog of alarms in the table to start fresh, not truncating every night.

Purging alarms via the system also affects additional tables and the cache.

When the purge script is run in the FMS, it runs the purgeAlarm function to delete data from the alarm_loc_msg, alarm_annotations tables, then from alarm_alarm based on a specific period of time. Then it syncs the alarm cache to make sure everything in memory matches what is on the database. This can affect what the users see in the UI.

NOTE: If there are a huge number of alarms in the system, Support recommends investigating the root cause of why so many alarms are being fired and to address any of these issues to reduce the number of alarms in the system fired each day.

Also see:

KB 4309807 - Detailed information on clearing and purging alarms

KB 4295903 - Total Alarms counter (acknowledged, cleared, current, historical) and Purge.