Alert Persistence

This section contains the following:

§        “Overview” on page 1063

§        “Database Configuration” on page 1064

§        “Alert Engine Configuration” on page 1064

§        “Alert Persistence Requirements and Limitations” on page 1065

Overview

The Alert Persistence feature stores all fields and current state of all active alerts, as well as all cleared alerts that have not been removed from the system in a database. You can configure the alert engine to persist alerts directly to the database or via a data server. More than one alert engine can persist its alerts to the same database table as long as each alert engine specifies a unique Alert Engine Name (specified on the Alerts>“Alert Persistence Tab” in the Application Options dialog).

With this feature enabled, alerts are persisted as follows: If you are running the alerts in a Data Server that is configured for High Availability, you must run the backup server in warm standby mode. All active and cleared alerts that had not previously been removed from the system will be restored to the standby server when it becomes the active server.

Note: You cannot run the standby server in hot standby mode when using alert persistence since, in that case, both Data Servers will generate alerts and persist them to the database. Also, with High Availability, if your persistence database is slow or you expect a large number of alerts to change each update period, you can use the persistInitDelayTime command line option to increase the delay time for when a backup server reads the primary server alert persistence database. Otherwise, there might not be enough time for the failing Data Server to write all the alerts to the database before the backup server reads them.

Even with high availability configurations, there are cases in which some alerts might not be persisted. For example:

§        The persistence database fails. In this case, alerts cannot be written to, or read from, the database. If a failover occurs while the database is down, the backup server will not be able to read persisted alerts from the database. This will also happen if persistence is configured to use a Persistence Data Server to access the database, and the Persistence Data Server is down during failover.

§        The Alert Server is terminated in a non-orderly shutdown. Alerts are written out once per update period and once during orderly termination. If there is a non-orderly shutdown, some alerts might not be written to the database.

In cases where alerts are not persisted, the new primary Data Server generates new alerts if the data is still in an alert state. The new primary Data Server might also re-use ID's that were used by the failed Data Server.

When the alert engine starts up, it will query the database table containing the persisted alerts and will recreate them at startup in the new alert engine. The persisted alerts will show up in the alert engine after the Initial Delay time (specified on the Alerts>Alert Definitions tab in the Application Options dialog) has expired. All alerts that are configured to renotify on a timer will immediately renotify, then continue to renotify on the specified renotification time.

To clear the alerts for an alert engine from the database on startup use the purgepersistedalerts command line option. This will clear all alerts for the alert engine from the database table on startup and no persisted alerts will be loaded. If you are persisting alerts for more than one alert engine in the same database table, alerts for other alert engines will not be removed. See “Options Enabled with Alerts” for more information.

For optimization, the alert engine does not store updates to the Last Update Time column of the “AlertTable” unless there has also been another change for that alert. In many cases this column is not used by RTView applications. However if you want to restore the alerts with accurate values in the Last Update Time column, you can use the lutupdatesnewdata command line option to enable this update. See “Options Enabled with Alerts” for more information.

There are two phases of configuration necessary to enable RTView to support the persistence of alerts:“Database Configuration” and “Alert Engine Configuration”.

Database Configuration

You can either let the RTView create the database table or you can create the table. If you want to the RTView to create the table, select the Create Database Table If Not Found option (on the Alerts>Alerts Persistence tab in the Application Options dialog).

If you want to create the table yourself, table schemas for several databases are included in RTV\dbconfig\alert_persist. The README.txt file in that directory will assist you in using the schemas to create your table. If you want to create it manually, create a table with the following column names and types in the following order:

The AlertEngineName and ID fields are primary keys. If you have defined Custom Alert Definition Properties and/or Custom Event Attributes, you will need to insert columns of the correct type in the order they appear in the AlertTable before the current column.

Alert Engine Configuration

In the Display Builder, select Tools>Options to open the Application Options dialog. To configure the alert engine, select Alerts>“Alert Persistence Tab”.

Alert Persistence Requirements and Limitations

Requirements

1.     Alert definitions and options must be the same before and after failover. For example, if you are running a primary and standby Data Server in two different locations, you must confirm that both are configured with the same alert definitions and option. If your alert options have changed, persisted alerts might be incorrect after failover.

2.     If any of the following properties on your alerts are attached to data, those data attachments must be available after failover and you must specify an Initial Delay time. This will allow the alert engine restoring the persisted alerts to resolve those data attachments before finishing the processing of the persisted alerts. The Initial Delay only needs to be long enough for your data attachments to resolve. Any of these properties that use a ; (semicolon) delimited list or a tabular data attachment must include index values, such as:

•        rowEnabledTable

•        value*Alert (i.e. valueHighAlert, valueLowAlert, valueMediumAlert)

•        value*Warning (i.e. valueHighWarning, valueLowWarning)

•        value*Text (i.e. valueHighAlertText, valueHighAlertCommandText, valueMediumAlertText, valueMediumAlertCommandText, valueLowAlertText, valueLowAlertCommandText, valueHighWarningText, valueHighWarningCommandText, valueLowWarningText, valueLowWarningCommandText)

•        alertState*AlertText

•        alertState*AlertCommandText

•        alertState*Comparison

•        alertState*UpperRangeLimit

•        alertState*LowerRangeLimit

3.     The database table where the alerts are persisted must contain a column for each column in the AlertTable, along with a couple of additional columns. Therefore, if you add, edit or remove Custom Alert Definition Properties or Custom Alert Event Attributes, the database table will need to be modified.

4.     If you have multiple alert engines persisting alerts to the same database table, they must have the same Custom Alert Definition Properties and Custom Alert Event Attributes.

Limitations

1.     Alerts that attach directly or indirectly to a function that outputs a non-table value (Text or Number) may be incorrectly cleared after failover.

2.     The nonRepetitionTime for an alert restarts after failover.

3.     Depending on the frequency of data that drives the alert, it is possible that an update to an alert might be missed during failover. The likelihood of missing an update increases the longer the time is between the exit of the first engine and the startup of the second.

4.     After failover, the per-alert variables will only contain the alert indexes that were persisted in the AlertTable. The other indexes will be added after data has been received for them.