Application Options - Alerts

Field Name

Description

Alert History Depth

Set the number of rows stored in the “AlertTable”.

This option limits the size of the AlertTable to the number of rows specified. When the AlertTable goes over this limit, RTView removes cleared alerts from the table starting with the alerts that have the oldest Cleared Time.

If all cleared alerts have been removed and the specified Alert History Depth is still not reached, then RTView will remove active alerts starting with alerts that have the oldest Time value. In this case, these alerts are cleared before being removed and the cleared reason is set to ALERT HISTORY DEPTH EXCEEDED.

Time (in seconds) to Keep Cleared Alerts

Enter the time, in seconds, to control how long RTView retains cleared alerts from the Alert data source.

RTView checks for cleared alerts to remove on each update pass. If more than the specified time has elapsed since the time the alert was last cleared, then the alert will be removed.

If the value is set to 0, cleared alerts will not be removed until the specified Alert History Depth has been exceeded.

Update Count on Acknowledged Alerts

Controls whether or not acknowledged alerts are included in the value of the Count column (in the “AlertTable”). If selected, the count will increase incrementally each time an alert receives an update until that alert is cleared. If deselected, the count will stop if an alert is either cleared or acknowledged.

Update Severity on Acknowledged Alerts

Controls whether or not the severity of acknowledged alerts is updated. By default this option is off, so the severity on acknowledged alerts does not update.

Unacknowledge on Severity Change Mode

Specifies the conditions to automatically unknowledge alerts when the alert severity increases. By default this option is None.

When an alert is unacknowledged, the alert resumes renotifying if the reNotificationMode property is configured to do so. It also means that if the condition meets the specified reNofifyOnSevChangeMode property on the alert, it resumes renotifying regardless of the reNotificationMode. This unacknowledge action is not tracked in the Alert Action Audit Table because it is not a user action. There are three modes:

§        First Severity Change: Reverts acknowledged alerts to unacknowledged when the severity increases for the first time. This means that the alert will start to renotify again, that is if the reNotificationMode property is configured to do so. If the reNofifyOnFirstSevChangeFlag property is selected, then the alert will renotify once regardless of the selected reNoficationMode. Note: This option is not tracked in the Alert Action Audit Table since it is not a user initiated action.

§        All Severity Increases: Reverts acknowledged alerts to unacknowledged every time the severity increases.

§        None: Do not unknowledge alerts when the alert severity increases.

Note: When run against Application Options set from an older version of RTView where the Unacknowledge Alerts on First Severity Change was enabled, that option automatically converts to the First Severity Change mode so the behavior is the same.

Enable Alert Auditing

Enable auditing of alert actions. If selected and configured, alert actions will be stored to the specified Alert Action Audit Table Name. See Alerts>“Audit Alert Action” for details.

Alert Action Audit Database Name

Enter the name of a database, as defined on the “SQL Tab”, that contains the Alert Action Audit table. See Alerts>“Audit Alert Action” for details.

Alert Action Audit Table Name

Enter the name of a table, in the specified Alert Action Audit database, in which to store the alert actions audit information. See the Alerts>“Audit Alert Action” section for details.

Alert Action Audit Data Server

Optionally specify a Named Data Server connection (see “Data Server Tab”) to use for reading and writing alerts to the specified Alert Action Audit Database Table.

Maximum Characters Allowed in Comments

Enter a value greater than 0 to limit the number of characters in the Comments field. When enabled, new comments are added before older comments in the Comments field, and the oldest comments are trimmed if necessary to stay under the limit. Enabling this option prevents the Comment field from becoming longer than your corresponding database field can support. By default, this feature is disabled.

When disabled, the Comments field grows unbounded as new comments are appended at the end of existing comments.

This comment limit is available via a data attachment to alert-commentlimit to facilitate building a UI that will prevent users from entering comments longer than this limit. Note that the UI text entry limit should be set to 100 characters less than the comment limit in order to account for the time stamp, user name, and hard returns between comments.

Field Name

Description

Enable Alerts

Enables/disables all alerts in all active Alert Definition files

Initial Delay

Duration (in seconds) to wait after startup before evaluating alerts.

Multiple Index Delimiter

For alerts with multiple index columns, RTView creates a unique Alert Index by concatenating all of the index column values separated by the specified Multiple Index Delimiter. The value can be any string, except the following:

§        comma (,)

§        semi-colon (;) or

§        empty string.

Default is tilde (~).

Alert Definition File

File(s) that contain alert definitions. See “Overview” for information on creating Alert Definition files.

Substitutions

Optionally specify substitutions for this Alert Definition file. Substitutions must use the following syntax:

$subname:subvalue $subname2:subvalue2

If a substitution value contains a single quote, it must be escaped using a / :

$filter:Plant=/'Dallas/'

If a substitution value contains a space, it must be enclosed in single quotes. Do not escape these single quotes:

$subname:subvalue $subname2:'sub value 2'

A substitution string cannot contain the following:

: | . tab space , ; = < > ' " & / \ { } [ ] ( )

Add

Click Add and select a (.rtv) file to include in Alert Definition File list.

Note: Alert definitions are only added after you click OK, Apply, or Save.

Remove Selection

Remove the selected Alert Definition file. Alerts in this Alert Definition file will no longer execute and the alert data for these alerts will no longer be available in the Alert data source.

Note: Alert definitions are only removed after you click OK, Apply or Save.

Refresh Selection

Reload the selected Alert Definition file immediately. This option allows the data source to re-read an Alert Definition file without restarting the Display Builder.

Note: Refresh Selection is enabled when you select an Alert Definition file that has already been added and applied.

Field Name

Description

Enable Self Service Alerts

Select to enable self service alerts.

Note: If this option is selected, no alerts will be loaded into the system unless the specified Self Service Alerts Database is configured and connected.

Self Service Alerts Data Server

Enter name of a named data server connection or leave blank to use the default data server connection, if specified. See “Data Server Tab” for more information. This data server will be used when connecting to the Self Service Alerts Database.

Self Service Alerts Database Name

Name of SQL Database connection defined in the “SQL Tab” of the Application Options dialog.

Alert Settings Table Name

Name of table where your alert settings will be stored. See below for a description of the schema for this table.

Audit Table Name

Name of the table where a record of all changes to the Alert Settings Table will be stored. This value is optional. If not specified, no record of changes will be stored.

Clean Alert Settings Table on Start

Select to delete entries from the Alert Settings Table for alert names that are not defined in RTView.

Note: This is done at startup after alert configuration files are processed and all of the alerts are loaded.

Field Name

Description

Custom Alert Definition Properties

These properties are useful when you want to store additional information about an alert definition and have it be accessible in the AlertTable. For example, you might want to organize your alerts by Category. In that case, you could add a Custom Alert Definition Property named Category. When you define your alerts, you specify a value in the Category property for each alert. When the alerts are executed, there will be a Category field in the AlertTable   that you can use for sorting and/or filtering.

Once you have applied your Custom Alert Definition Property, a Custom Properties section will be added to Object Properties window that contains a property for each of your Alert Definition files. These properties can be static or attached to data. You will also see a column in the AlertTable for each Custom Alert Definition Property. The value in that column will be the value specified for the property in the corresponding alert definition.

The alert will also create a substitution for each custom property by collapsing the name into $alertXX (where XX is the name of your custom field) in camel case with spaces removed. For example, if your custom property name is my property, the corresponding substitution will be $alertMyProperty. You can use this substitution to show the value of your custom property in the alertCommand, reNotificationCommand, clearedCommand, or in the alert text.

Note: Renotification commands will update with the new value of the property if it changes, but the alert text in the table will not update after the alert is generated.

These properties can also be mapped to a column in the valueTable input for your alert if the useTabularDataFlag is on. Use the customPropertyMap property to specify which column from the valueTable contains the value to use for the custom property using the following syntax:

customPropName:valueTableColumnName;customPropName2:valueTableColumnName2

For example, if you have a custom property named My Custom Property and you want to use the value from the My Data Column column in your value table, you would specify the following:

My Custom Property:My Data Column

To add a property, click Add Custom Alert Definition Property. To edit an existing property, double-click on it in the Custom Alert Definition Properties list.

Add

Name - Name of the Custom Alert Definition Property. This will be used as the property name in the alert definition and as the column name in the “AlertTable”. This field is required and the name must be unique within both the Custom Alert Definition Properties and Custom Alert Event Attributes.

Data Type - Select the type of data for this Custom Alert Definition Property: String, Double, Integer or Boolean.

Default Value - Specify a default value for this Custom Alert Definition Property. This field is optional. If specified, this value will be used for new alert definitions.

Note: The Default Value must be of the specified Data Type.

Remove

To delete a Custom Alert Definition Property, select it from the list and click Remove Custom Alert Definition Property.

Custom Alert Event Attributes

Alert event attributes show up as columns in the AlertTable and are set via the Set Custom Alert Event Attribute command. This is useful when you want to add table information on a per-alert instance basis. For example, you might want to add a Status attribute to the alert, so that the user can indicate whether the problem is Under Investigation, Being Tested, or Resolved.

To add an attribute, click Add Custom Alert Event Attribute. To edit an existing attribute, double-click on it in the Custom Alert Event Attributes list.

Add

Name - Name of the Custom Alert Event Attribute. This will be used as the column name for this attribute in the “AlertTable” and will also be the name you will use to reference this attribute in the Set Custom Alert Event Attribute command. This field is required and the name must be unique within both the Custom Alert Event Attributes and the Custom Alert Definition Properties. See “Command Types” for more information.

Data Type - Select the type of data for this Custom Alert Event Attribute: String, Double, Integer or Boolean.

Default Value - Specify a default value for this Custom Alert Event Attribute. This field is optional. If specified, this value will be used for new alerts.

Note: The Default Value must be of the specified Data Type.

Remove

To delete a Custom Alert Event Attribute, select it from the list and click Remove Custom Alert Event Attribute.

Field Name

Description

Enable Persistence

Select to enable the persistence of alerts during fail over of an alert engine. All fields and current state of all active alerts, as well as all cleared alerts that have not been removed from the system will be stored.

Database Name

Name of SQL Database connection defined in the “SQL Tab” of the Application Options dialog. If the Database connection is unavailable at start up, then RTView will wait the amount of time specified by the Connection Time Out option before initializing the alerts with persistence disabled.

If the Database connection is lost while the alert engine is running, the alert engine will store up alerts to persist until the database becomes available.

Note: It is possible that alert events that occur between the time the database becomes unavailable and the time the alert engine is notified might not be persisted. Once the Database connection is resolved, all of the stored alerts will be persisted.

Note: Running the alert engine for an extended period of time with persistence enabled and an unavailable connection will result in memory growth until a connection is made.

Table Name

Name of the table where the alerts will be persisted.

Alert Engine Name

Enter a unique name for the alert engine. Multiple alert engines can persist their alerts to the same database, so the unique identity of each enables the alert engine to restore only alerts for a specific alert engine in the case of fail over.

Data Server

Optionally specify a Named Data Server connection to use for reading and writing alerts to/from the database. See “Data Server Tab” for more information.

SQL Response Time Out (seconds)

Specify (in seconds) the amount of time RTView will wait for a response from the database query to get the persisted alerts.

If your database connection is slow, or if you are using a data server to get your persisted alerts and its connection is slow, you should increase this value.

Note: RTView will block while waiting for this query to return.

Connection Time Out (seconds)

If the persistence database is not available at startup, specify (in seconds) the amount of time RTView will wait for the database to become available before initializing alerts with persistence disabled. Default is 60 seconds.

Note: RTView will not block while waiting for the connection to resolve.

Create Database Table If Not Found

If selected, RTView will create an alert persistence database table if one is not already found in the specified database.