9.6 Event Manager Alarm Server Dictionary

The Alarm Server dictionary provides information about server processing functionality and features that can be customized. To learn more about editing the custom properties file, see Section 3.4, Setting Custom Properties for Alarm Server Connectivity and Alarm Server Functions.

9.6.1 Alarm Keys

Alarm keys for the Event Manager custom properties are listed in the following:

  • HRL: Hierarchy Resource List, a composite key.

  • HRLT(Type)1‑5, HRLN(Name)1‑5, and the rule name, provide a unique key for the alarm:  

    •      HRLT1==SP HRLN1 == $MAXM (Default: Eve)
    •      HRLT2=TP HRLN2 == $EMS (Default: Agent Name)
    •      HRLT3‑5 == User defined
    •      HRLN3‑5== User defined
  • Generated Alarm Text: Any combination of rule set variables and free text display as alarm text.

  • Severity:  

    • 1: CRITICAL

    • 2: MAJOR

    • 3: MINOR

    • 4: INFORMATIONAL

    • 5: OK

    Increase the severity level by decreasing the severity number. Alarms cannot de-escalate lower than OK or escalate higher than CRITICAL.

  • Priority: Valid values: 1 – 99. Increase the priority by decreasing the priority number. Alarm priority cannot go lower than 99 or higher than 1.

  • Close Rule enhanced processing: Remove all alarms, active or delayed, from the system if the rule name specified is the Close Rule and all HRL values match the HRL values of a rule being fired.

    Wildcards:

    • Closes All Rules (*): Close all alarms, active or delayed, with matching HRLs, regardless of rule name. (Ignore rule name).

    • Close All EMSs for Rule: Close all alarms, active or delayed, with matching HRLs, except for HRLT2 and HRLN2. (Ignore HRL2).

    When both wildcard flags are used, both the rule name and HRL2 are ignored.

    Currently, t the $EMS parameter setting in the Event Manager Agent does not allow setting the $EMS globally. The workaround is to use the EMS class that is defined when the agent is created instead of using $EMS.

    The custom property flag that controls this behavior:

    com.mosol.Eve.AlarmServer.useEMSClassToClose

    If True, alarms are closed across EMS_class using the hierarchy class defined in the agent.

    If False (the default), the EMS defined as the agent’s name is used.

  • Timeout: Closes the active alarm after x minutes.

    • For nondelayed alarms, the timeout time is the initial event time + x minutes.

    • For delayed alarms and threshold alarms, the timeout time is the time the alarm became active + x minutes.

    • For active accumulated alarms, the timeout time is reset to the time of the latest accumulating event + x minutes.

    • For discard alarms, the active alarm timeout time is not updated when matching events are discarded.

    • If timeout is not selected, the active alarm never times out.

    • If timeout is selected and set to 0, closes all alarms, active or delayed, and adheres to all Close Rule parameters. However, it does not create a new alarm or perform any other alarm processing.

    The custom property flag that controls this behavior:

    com.mosol.Eve.AlarmServer.timeout.schedule

    This is the scheduled time (in milliseconds) to check for alarm timeouts. The default is 30000 (30 seconds).

  • Delay: Postpones creating an alarm for x minutes. A delayed alarm can be closed by another event before it becomes active. The timeout time is the time the alarm became active + x minutes. After the alarm is created, normal event processing applies.

    Delay and Threshold are mutually exclusive. Threshold takes precedence if both are set.

9.6.2 Custom Property Flags

The following custom property flags modify the behavior of delayed alarms for the Alarm Server:

  • com.mosol.Eve.AlarmServer. delayedAlarmsPreCloseRules: If True (the default), events that create a delayed alarm perform Close Rule functions as soon as the event arrives in the Alarm server.

    If False, Close Rule functions are not performed until the delayed alarm becomes active.

  • com.mosol.Eve.AlarmServer. resetDelayed AlarmsTime: If True, a delayed alarm’s initial date and time and its most recent date and time is set to the date and time that the alarm became active.

    If False (the default), a delayed alarm’s initial date and time is set to the date and time the event arrives in the Alarm server and its most recent date and time is set to the date and time that the alarm became active. In both cases the alarm’s date and time in Operations Center is the most recent date and time.

  • com.mosol.Eve.AlarmServer. delay.schedule: The scheduled time (in milliseconds) to evaluate delayed events. The default is 30000 (30 seconds).

  • Discard (after first): If an active alarm exists with the same rule name and HRL values, discard the incoming alarm. Only active alarms are evaluated for matches. No other alarm processing is performed. Discard and Accumulate cannot both be True. If Discard is True, Accumulate is evaluated as False.

  • Time Escalation: If an alarm has been active for x minutes since the initial date and time, increase/decrease the severity and/or priority by a rule-determined threshold amount until the upper or lower limit is reached.

    This is performed for each multiple (nx) of the threshold time. Accumulating alarms that have time escalated/de-escalated no longer have their severity or priority properties updated.

    Example: Set Escalate Time to 5, Escalate Severity by 1, Escalate Priority by 1.

    An event creates a MINOR active alarm with the counter set to 1 and a priority of 50. When the alarm has been active for 5 (x) minutes, the alarm severity is increased to MAJOR and the priority is increased to 49. (Note that a lower priority number actually sets a HIGHER priority.)

    When the alarm has been active for 10 minutes (2x), the alarm severity increases to CRITICAL and the priority increases to 48.

    The same behavior apples for each nx increment, except that the severity remains CRITICAL because it cannot go any higher. Severities can go no higher than CRITICAL nor lower than INFO using escalation. Priorities can go no higher than 1 nor lower than 99 with escalation.

    The custom property flag that controls this behavior:

    com.mosol.Eve.AlarmServer.escalation.schedule

    This is the scheduled time (in milliseconds) to evaluate time escalated alarms. The default is 30000 (30 seconds).

  • Accumulate: Updates an active alarm every time an event with a matching rule name and HRL is processed.

    Discard must be False for Accumulate to be evaluated.

    An accumulation counter is updated by N + 1 each time an alarm is accumulated. The timeout time is reset to the time of the latest accumulating event + x minutes. The alarm’s initial date and time is set to the date and time when the first alarm was created and its most recent date and time is set to the date and time that the alarm was last accumulated. The alarm’s date and time in Operations Center is the most recent date and time.

    The custom property flag that controls this behavior:

    com.mosol.Eve.AlarmServer.escalation.schedule

    If True (the default), updates all the alarm’s properties on accumulation. This includes, but is not limited to, severity, priority and alarm text.

    If False, updates only the accumulation counter, the most recent date and time, and the alarm’s timeout value.

    NOTES:

    • Accumulated alarms that have escalated/de-escalated will not have their severity or priority properties updated.

    • com.mosol.Eve.AlarmServer.updateTextOn Accumulation is obsolete and should be removed completely from the Alarm server.

9.6.3 Accumulation Subrules

The following are accumulation subrules for the Alarm Server Dictionary:

  • Quantity Escalation (Accumulate True): Accumulate must be True for this function to be evaluated.

    If the alarm quantity count of an accumulated alarm exceeds a rule-determined value x, the severity and/or priority increases or decreases by a rule-determined threshold amount until the upper or lower limit is reached. This is performed for each multiple (nx) of the threshold quantity. Alarms that have quantity escalated/de-escalated no longer have their severity or priority properties updated.

    Example: Set Quantity to 5, Escalate Severity by: 1, Escalate Priority by: 1.

    An event creates a MINOR active alarm with the counter set to 1 and a priority of 50. If subsequent alarms have the accumulation counter set between 1 and 4, there is no change to alarm severity or priority.

    When the accumulation counter increments to 5(x), the alarm severity increases to MAJOR and the priority increases to 49. (A lower priority number is a HIGHER priority.)

    Subsequent alarms that have the accumulation counter set to less than 10 experience no change to alarm severity or priority.

    When the accumulation counter increments to 10 (2x), the alarm severity increases to CRITICAL and the priority increases to 48.

    The same behavior occurs for the next increment of 5 alarms, except that the severity remains CRITICAL because it can go no higher. Severities can go no higher than CRITICAL nor lower than INFO via escalation. Priorities can go no higher than 1 nor lower than 99 with escalation.

  • Threshold Setting (Accumulate True, Delay False): Accumulate must be True and Delay must be False for this function to be evaluated.

    Delay and Threshold are mutually exclusive, with Threshold taking precedence if both are set.

    If the Alarm server receives an event with the threshold set and there is a matching active alarm, normal event processing related to an active alarm takes place.

    If there is no matching active alarm, events are kept in a pending state and evaluated on a sliding time scale each time a new event arrives. An alarm is created if the number of events matches the quantity threshold within the past threshold time in minutes. The alarm accumulation count is set to the quantity threshold setting.

    Threshold events are evaluated when the alarm server receives them and older pending events falling outside of the time threshold are discarded.

    The alarm’s initial date and time is set to the date and time the oldest threshold event and its most recent date and time is set to the date and time that the alarm became active.

    If the com.mosol.Eve.AlarmServer.updateAllFieldsOnAccumulation flag is True, the properties of the newest event are used to create the alarm. If the flag is False, the properties of the oldest event are used to create the alarm.

    Example: Set Quantity to 5 and Threshold Time to 2. To create an alarm, there must be five events in the past two minutes evaluated at the time of the most recent event. All five events are accumulated into a single alarm with an alarm count of 5. Events older than two minutes are discarded. Subsequent events increment the alarm counter as normal accumulated alarms.