As an alert and alarm administrator, you configure alerts and alarms (alarm conditions). The Questra IDM Application Suite uses alerts to notify users or other enterprise systems about alarm conditions that are raised. In order for an alert notification to be sent, an alert must be associated with an alarm condition. Multiple alerts can be associated with an alarm. A single alert may also be used for many alarms.
Currently, the supported types of alerts are:
Email
Service Request
System
An alarm event initiates the alert notification process. Depending on the alarm-alert configuration, multiple alert requests will be created. The following illustration depicts those relationships, and the individual items are described below.
Alarm
Alert
Alarm Event
NOTE: It is possible to have an alarm event that is not associated with an alert because no action is required but which a record of the alarm event is desired.
Alert Request
|
|
There are generally two approaches for defining alarms and alerts. Both are valid and have pros and cons. One model is to define the alarm and alert for the specific conditions and actions they represent, essentially having 1:1 pairs of alarms and alerts. This provides for more information for users when they view the alert summary and allows greater flexibility for configuring user alert filters, etc. It does require new configurations when new conditions are to be monitored. For example, you could define a "motor over temperature" alarm and a "motor over temperature" alert and associate them. This would show the specific information (motor over temperature) in the alert summary information, which may avoid the need for users to look at the details of the alert. Alternatively you could define and associate generic constructs, such as a "monitor rule" alarm and "monitor rule" alert, to use for all conditions that are checked via monitoring rules. The benefit of this approach is that the administration is minimized when new rules are added, but the information shown on the alert summary is generic in nature, and will require the users looking at the alert details to get specific information, such as motor over temperature. |
Consider the following example of an alarm-alert interaction. Assume there is a device status ("monitoring") rule that evaluates a device's motor temperature against a threshold. A "Motor Over Temperature" alarm is defined to represent this condition. A "Generic Email Alert" (type is Email Alert) is created so it may be used with multiple alarms, including motor over temperature.
When the motor temperature property reading is received from the device, the rule to evaluate it is invoked. If the temperature crosses the threshold, the rule triggers and the "Motor Over Temperature" alarm is raised (that is, a "Motor Over Temperature" alarm event is created). In response to the alert event creation, a Generic Email alert request is generated, and the Email alert processing begins.
For Email alerts, there is an alert escalator that processes the alert requests until either users have acknowledged them or all escalation levels are exhausted. The alert is "suppressed" by the alert escalator when the escalation levels are exhausted. At any given time, an alert is in a certain state; the alert is "suppressed" by the alert escalator when the escalation levels are exhausted. (The different alert states are illustrated and defined in Alerts and Alarms - An Overview.)
The alert escalator uses the group ownership configuration settings to determine which users are notified and the level to which the alert request is escalated. To understand the escalation mechanism, study the group and ownership configuration shown below. Assume there is a parent group called "California" and that one of its subgroups is "San Francisco." If an alarm event is submitted for Device 1, which belongs to San Francisco, that group's owner, Meg S., will be notified. If Meg does not acknowledge the alert within the escalation period (a calculated period based on how the administrator defines the alert), and the alert is configured to escalate the request, group California's owners, Allen W. and Hayao T., are notified. If an alarm event is received for Device 2, only Allen and Hayao are notified, because group California does not have any parent group.
