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.
Each profile is divided into a set of (one or more) time periods.
Each time period consists of a set of subscriptions (one or more).
A subscription is defined by a <filter group , alarm address> tuple.
Each filter group is in turn a combination of filters (one or more) put together using a filter group operator:
Each filter consist of one (or more) expressions on the following form:
The variables used in filter expressions typically respond to variables that describe the alert in question.
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.