This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
alertprofiles [2007/09/16 08:19] faltin Linked to the user manual |
alertprofiles [2009/01/28 14:44] faltin updated for 3.5 |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | [[TableOfContents]] | + | ====== Alert Profiles ====== |
- | ====== User manual ====== | ||
- | A complete user manual for alert profiles is supplied with NAV. Select Help from the sidebar meny and | + | {{tools:alertprofiles.png|}} 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 |
- | you will see a link to the pdf {{alertprofiles:alert-profiles-manual.pdf|}}. The user manuel goes in detail on the various choices you have in the user interface (the manuel is not quite up to date at the time of writing). | + | {{alertprofiles:alert-profiles-manual.pdf|manual of the old Alert Profiles}}. Please keep in mind that the GUI |
+ | has changed. We will in due time make an updated manual. | ||
- | This document complements tha manual and seeks to give an overall understanding of the NAV alert profile | ||
- | concept. | ||
- | |||
====== Background ====== | ====== Background ====== | ||
Line 27: | Line 24: | ||
alert has any qualified recipients and forwards the alarms. | alert has any qualified recipients and forwards the alarms. | ||
- | Read more about the EventAndAlertSystem (figure, description of processes, database doc). | + | Read more about [[eventandalertsystem|the event and alert system]] (figure, description of processes, database doc). |
===== NAV profiles ===== | ===== NAV profiles ===== | ||
- | A key design principle for the new alert profile system has been maximum flexibility. We | + | 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 | 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 | network and systems engineers have an (incredibly) wide range of opinions of how and | ||
when they would like to receive alarms. | when they would like to receive alarms. | ||
- | Alert profiles is no doubt a very general and powerful system. The alpha testing of the | + | 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. The | + | system has revealed, however, that the downside of being too general is complexity. |
- | system has been far from intuitive and has required a lot of effort to grasp. A tedious | + | Improvements have been done in the 3.5 version to overcome this. |
- | amount of work has been required for each NAV user to set up his profile. | + | |
- | As we now are entering the beta phase of NAV v3, Alert Profiles is fundamentally | ||
- | improved in terms of user friendliness (we believe). And we have not compromised on | ||
- | flexibility; we have in fact also improved this aspect. | ||
Line 50: | Line 43: | ||
The Alert Profile concept is explained with an example in the figure: | The Alert Profile concept is explained with an example in the figure: | ||
- | {{alertprofiles:alertprofiles.png|}} | + | {{alertprofiles:alertprofiles.png?800|}} |
- | + | ||
Let us explain this step by step: | Let us explain this step by step: | ||
Line 68: | Line 61: | ||
* **In the example:** “At work” has three time periods: mon-fri 8 AM-4PM , mon-fri 4PM-8AM, weekend around the clock. | * **In the example:** “At work” has three time periods: mon-fri 8 AM-4PM , mon-fri 4PM-8AM, weekend around the clock. | ||
+ | |||
+ | |||
===== 2) My subscriptions ===== | ===== 2) My subscriptions ===== | ||
Line 84: | Line 79: | ||
* **In the example:** On weekdays from 4PM to 8AM my “at work” profile has two subscriptions: | * **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'' | ||
+ | |||
- | * “routers up/down“ => send SMS to 91897xxx | ||
- | |||
- | * “critical and emergency alerts” => send email to ''john@univ.no'' | ||
===== 3) Filter groups ===== | ===== 3) Filter groups ===== | ||
Line 98: | Line 93: | ||
* Allowed operators are: | * Allowed operators are: | ||
- | |||
* Plus/OR (+) | * Plus/OR (+) | ||
- | |||
* AND (&) | * AND (&) | ||
- | |||
* Subtract (-) | * Subtract (-) | ||
- | |||
* Add Inverse | * Add Inverse | ||
Line 110: | Line 101: | ||
* **In the example:** I have defined the filter group “routers up/down” as follows: | * **In the example:** I have defined the filter group “routers up/down” as follows: | ||
- | |||
* “routers up/down” = “all routers” //AND// “boxstate events” – “trolla-gw” | * “routers up/down” = “all routers” //AND// “boxstate events” – “trolla-gw” | ||
+ | |||
+ | |||
===== 4) Filters ===== | ===== 4) Filters ===== | ||
Line 123: | Line 115: | ||
* The selection criteria vary depending on the variable in question. The two most important selection criteria are: | * The selection criteria vary depending on the variable in question. The two most important selection criteria are: | ||
- | + | * equals ( = ) <a single value> | |
- | * equals (=) <a single value> | + | |
* IN <a set of values> (in effect an OR operation) | * IN <a set of values> (in effect an OR operation) | ||
* For string variables various string selection criteria may be used, the most general being: | * For string variables various string selection criteria may be used, the most general being: | ||
- | |||
* regexp | * regexp | ||
* For IP-addresses: | * For IP-addresses: | ||
- | |||
* CIDR notation may be used ( IP address / mask) | * CIDR notation may be used ( IP address / mask) | ||
* **Examples** of two filter definitions: | * **Examples** of two filter definitions: | ||
- | |||
* “all routers” : category IN ( GSW | GW ) | * “all routers” : category IN ( GSW | GW ) | ||
- | |||
* “boxstate events” : event type = boxState | * “boxstate events” : event type = boxState | ||
Line 145: | Line 132: | ||
* Pre defined variables are: | * Pre defined variables are: | ||
- | |||
* Event type (or alert type) | * Event type (or alert type) | ||
- | |||
* Severity of the alert | * Severity of the alert | ||
- | |||
* Category (or sub category) of the equipment related to the event | * Category (or sub category) of the equipment related to the event | ||
- | |||
* Sysname or IP address of the equipment related to the event | * Sysname or IP address of the equipment related to the event | ||
- | |||
* Relevant room or location information | * Relevant room or location information | ||
- | |||
* Equipment type or vendor | * Equipment type or vendor | ||
- | |||
* Organization ownership of the equipment in question | * Organization ownership of the equipment in question | ||