Alert Profiles was rewritten for NAV 3.5 and now resembles the look and feel found elsewhere in NAV. The functionality is with few exceptions the same as pre-3.5, so the general description given below is still representative. For reference though, you can browse through the manual of the old Alert Profiles. Please keep in mind that the GUI has changed. We will in due time make an updated manual.

Also see a slideset explaining Alert Profiles (from 2009).

NAV v3 introduces a fundamentally improved system for sending alarms to NAV users. First; we have separated the task of processing and correlating events (the event engine) from the process of sending alerts to users (the alert engine). We will not elaborate on the event engine here, but merely point out that the event engine sends alarms to the alert queue (alertq) in a preformatted fashion, based on a config file (alertmsg.conf).

Thus alert engine does not worry about the semantics of the messages that are to be delivered. Alert engine simply processes incoming alerts on the alert queue, checks if the alert has any qualified recipients and forwards the alarms.

Read more about the event and alert system (figure, description of processes, database doc).

A key design principle for the alert profile system has been maximum flexibility. We wanted a system that supports a wide range of user demands. Experience has shown that network and systems engineers have an (incredibly) wide range of opinions of how and when they would like to receive alarms.

Alert profiles is no doubt a very general and powerful system. User feedback on the system has revealed, however, that the downside of being too general is complexity. Improvements have been done in the 3.5 version to overcome this.

The Alert Profile concept is explained with an example in the figure:

Let us explain this step by step:

A NAV user can configure a set of (one or more) alert profiles.

• I.e. a profile may be for regular daytime work mode, another for around-the-clock operation, and a third for vacation mode etc. With a single click the NAV user can swap between his defined profiles (and thus select an active profile).

• In the example: My active profile is named “At work”

Each profile is divided into a set of (one or more) time periods.

• A time period (i.e. from (8 AM till 4 PM) may be defined for 7 days a week or it may be limited to weekdays or weekends only.

• In the example: “At work” has three time periods: mon-fri 8 AM-4PM , mon-fri 4PM-8AM, weekend around the clock.

Each time period consists of a set of subscriptions (one or more).

A subscription is defined by a <filter group , alarm address> tuple.

• When a new alert arrives on the alert queue alert engine will match the alert against the relevant <filter group , alarm address> tuples (i.e. the tuples that are on a matching time period of a users’ active profile).

• If the alert matches the filter group in question an alarm is sent to the configured alarm address (which may be an email address or SMS phone number, or other alarm choices in the future).

• Please note that the NAV administrator may have imposed restrictions on the set of alerts you may receive, more below (my permisssions).

• Alert Profiles also support queued alarms; i.e. a NAV user may choose to receive alarms on a daily basis only; i.e. every morning

• In the example: On weekdays from 4PM to 8AM my “at work” profile has two subscriptions:
  • “routers up/down“ ⇒ send SMS to 91897xxx
  • “critical and emergency alerts” ⇒ send email to john@univ.no

Each filter group is in turn a combination of filters (one or more) put together using a filter group operator:

• filter group = ( (<filter 1> <operator> <filter 2>) … ) <operator> <filter n>

• Allowed operators are:
  • Plus/OR (+)
  • AND (&)
  • Subtract (-)
  • Add Inverse

• A filter group may be defined by the NAV administrator (or shipped with NAV) and shared among a group of NAV users. A filter group may also be personal, defined by the NAV user himself.

• In the example: I have defined the filter group “routers up/down” as follows:
  • “routers up/down” = “all routers” AND “boxstate events” – “trolla-gw”

Each filter consist of one (or more) expressions on the following form:

• Filter = <variable> <selection criteria> < value>

• If a filter consists of more than one expression, every expression must match the alert in question!

• The selection criteria vary depending on the variable in question. The two most important selection criteria are:
  • equals ( = ) <a single value>
  • IN <a set of values> (in effect an OR operation)

• For string variables various string selection criteria may be used, the most general being:
  • regexp

• For IP-addresses:
  • CIDR notation may be used ( IP address / mask)

• Examples of two filter definitions:
  • “all routers” : category IN ( GSW | GW )
  • “boxstate events” : event type = boxState

The variables used in filter expressions typically respond to variables that describe the alert in question.

• Pre defined variables are:
  • Event type (or alert type)
  • Severity of the alert
  • Category (or sub category) of the equipment related to the event
  • Sysname or IP address of the equipment related to the event
  • Relevant room or location information
  • Equipment type or vendor
  • Organization ownership of the equipment in question

• The set of variables may be expanded by the NAV administrator. In principle any relevant variable in NAVdb may be used!

Finally; note that even though a given alert has a match for a given user profile, it still may not trigger an alarm. Each user (or rather each user group) may be restricted to a limited set of alerts that they are qualified to receive. The NAV administrator defines these permissions using the same filter group mechanism.

The figure below shows an example where the user is restricted by the administrator. With the given permissions, the user has in fact set up his profile “too optimistic”; i.e. there may be alerts that match the profile, but are not sent due to permission constraints.