Differences

This shows you the differences between two versions of the page.

--- alertprofiles [2007/09/16 08:31] – faltin
+++ alertprofiles [2013/05/08 17:30] (current) – [Alert Profiles] faltin
@@ 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
+Also see [[http://www.slideshare.net/lunkwill42/nav-alert-profiles|a slideset explaining Alert Profiles]] (from 2009).
-concept.
 ====== Background ======
@@ Line 27: / Line 26: @@
 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 =====
-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
 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. 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 45: @@
 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:
@@ Line 109: / Line 104: @@
   * **In the example:** I have defined the filter group “routers up/down” as follows:
     * “routers up/down” = “all routers” //AND// “boxstate events” – “trolla-gw”
 ===== 4) Filters =====
@@ Line 120: / Line 117: @@
   * 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)
   * 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
@@ Line 142: / Line 134: @@
   * 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