Alert rules

Alert rules contain information defining what the system does with a particular alert instance when it is received. Alert rules also determine the list of receivers of email notifications for a given alert.

There are two types of alert rules:

Action rules –defining what the system does with a particular alert
Email rules –defining a list of emails of alert receivers

Each alert rule has a value. Action rules have integer values which determine what to do with an alert. The value can be one of the following:

0 - Do nothing
1 - Send email
2 - Use Call Home to open PMR
4 - Send SNMP trap
5 - Send email and SNMP trap
6 - Send SNMP trap and open PMR

For email rules, the value is a list of email addresses.

Rules can be defined on three levels (alert rule scope):

Global - apply to all alerts
Alert type - apply to all alerts of a given type
Alert reason code - apply to alerts with the given reason code

Action rules defined on lower level override action rules from higher level. Email rules defined on lower level may override (when using _to) or extend ( when using _add_to) email rules from higher level.

Alert rule name consists of the following parts:

[scope]_[suffix]

where [scope] is one of the following:

def - used for global scope
value of alert type, for example: HW_NEEDS_ATTENTION
value of reason code, for example: 101

and [suffix] is one of the following:

action - for action rules
to or add_to - for email rules

Table 1 presents all possible rule names. In place of [Type] any alert type from alerts registry can be used (for instance, HW_NEED_ATTENTION) and in place of [ReasonCode] any alert reason code from alerts registry can be used (for instance 101).

Table 1. Possible names for action rules
Level (scope)	Action Rule	Email Rule
Global defaults	`def_action`	`def_to`
For alert type	`[Type]_action`	`[Type]_add_to [Type]_to`
For reason code	`[Type]_action`	`[ReasonCode]_add_to [ReasonCode]_to`

Resolution for action rules is as follows:

If there is [ReasonCode]_action rule present for given alert reason code it will be used.
Otherwise, if there is [Type]_action rule present for given alert type it will be used.
Otherwise, if there is def_action rule present it will be used.
Otherwise, the action is ‘do nothing’.

For email rules, the resolution is similar, except that when _add_to rule is used it extends the list of emails from lower level rather than replace it.

Examples

Following is an example set of rules defined for an appliance:

def_to =[“admin1@company.com”,”admin2@company.com”]
SERVICE_RESTARTED_action = 1
HW_SERVICE_REQUESTED_action = 2
HW_NEEDS_ATTENTION_action = 1
159_add_to = [“securityadm@company.com”]
159_action = 4

Based on this set, the following action resolution is applied by the system:

Assumption: Reason code 159 is assigned to HW_NEEDS_ATTENTION on this system.

When any SERVICE_RESTARTED alert is received, an email to admin1@company.com and admin2@company.com is sent.
When any HW_SERVICE_REQUESTED alert is received, Call Home is called for opening PMR and no email is sent as action is set to 2.
When any HW_NEEDS_ATTENTION alert is received with reason code other than 159, an email to admin1@company.com and admin2@company.com is sent.
When alert with reason code 159 is received, an email to admin1@company.com, admin2@company.com and securityadm@company.com is sent, and SNMP trap is sent, as action is set to 4.
When any alert other than SERVICE_RESTARTED, HW_SERVICE_REQUESTED or HW_NEEDS_ATTENTION is received nothing is done.