release notes | Book: 2.10, 2.11, 2.12, 2.13, 2.14, 2.15, 2.16, 3.0, 3.1, 3.2 | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg

Using the Alarms Web Page

The Alarms Web Page is an admin page and thus requires authentication. You must enable HTTPS and you can give a gid (by default the gid is 1000):


For the authenticated mode you need to have a host certificate for your server host and place the hostcert.p12 in the directory /etc/dcache.

  1. The QUERY FILTER form can be used to limit the display of alarms in the table. The top three rows control an actual query to the database based on after date, before date, severity and alarm type name. (The date is the last update of the alarm, not the first arrival.) Each click of the Refresh button will reload the data from the database based on these three settings. The default behavior is ALL (unspecified properties). Placing a single date in the Beginning box will give you all alarms from that date up to today (inclusive); a single date in the Ending box will give all alarms up to that date (inclusive).
  2. The Match Expression filters in memory by appending all fields to a single string and doing a search. If the Regular Expression box is checked, the expression given is considered a regex (Java-style).
  3. The header to the table contains two checkboxes which allow you to check or uncheck the respective columns for all displayed items. Checking Delete and then clicking Refresh will actually eliminate the entry from persistent store.
  4. Closed is a way of marking the alarm as having been dealt with while maintaining a record of it. The Show Closed Alarms checkbox allows you to display them (turned off by default).
  5. All column titles appearing in white can be clicked to sort the table by that column.
  6. Notes is an editable field to be used for any special remarks.

When Refresh is clicked, any updates to Closed and Notes are first saved, then any Deletes are processed, and finally, the table is repopulated using the current query filter. The entire form is set to auto-refresh every 60 seconds.

An additional feature of the alarms infrastructure is automatic cleanup of processed alarms. An internal thread runs every so often, and purges all alarms marked as closed with a timestamp earlier than the given window. This daemon can be configured using the properties httpd.enable.alarm-cleaner, httpd.alarm-cleaner.timeout and httpd.alarm-cleaner.delete-entries-before.