[checkmk-commits] Check_MK Git: check_mk: Various spelling fixes, plus rewording for clarity

Module: check_mk Branch: master Commit: 23738c436e06c6d59200f28084270bc6c603e61d URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=23738c436e06c6… Author: Götz Golla <gg(a)mathias-kettner.de> Date: Tue Nov 5 14:56:08 2013 +0100 Various spelling fixes, plus rewording for clarity --- doc/drafts/README.rule_based_notifications | 31 ++++++++++++++-------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/doc/drafts/README.rule_based_notifications b/doc/drafts/README.rule_based_notifications index c091102..cea719b 100644 --- a/doc/drafts/README.rule_based_notifications +++ b/doc/drafts/README.rule_based_notifications @@ -2,27 +2,28 @@ Starting point: Check_MK's "Flexible Notifications" are to a decent degree more flexible than Nagios' builtin notification system. There are some situations, however, where even more flexiblity is desirable. Furthermore - if you have a larger number of users - the configuration of the notification -profiles for each user is very inconveniant. +profiles for each user is very inconvenient. -This white pager suggest a new notification system that tackles these problems -and is easily extendable for the future. +This white paper suggests a new notification system that tackles these problems +and is easily extendable in the future. RULE BASED NOTIFICATIONS ------------------------ The basic idea is that notifications are processed by a rule based engine - very similar to the "Event Console". A notifcation is in the first place -independent of an actual user. It goes as follows: +independent of an actual user. It is handled as follows: 1. The monitoring Core (Nagios/Icinga/CMC) creates a host or service *Alert*. -2. That alert is being notified by a general global contact calles "checkmk-notify". +2. The monitoring core notifies the global contact called "checkmk-notify" + about the alert. -3. That contact has "cmk --notify" configured as its notification command. By +3. This contact has "cmk --notify" configured as its notification command. By means of an environment variable it gets the list of contacts of the object for later reference. The actual contacts themselves have notifications disabled. - This avoid duplicate notifications. + This avoids duplicate notifications. -4. Now the notifications goes through a chain of notification rules, which +4. Now the notification goes through a chain of notification rules, which can be edited via WATO (similar to the one in the Event Console). One difference to the EC is, that in the notification system *all* rules will be applied, even if a previous rule already matched. That is important in order to have @@ -31,27 +32,27 @@ independent of an actual user. It goes as follows: RULES ----- -The rules have a structure similar to those in the Event Console. There are -being edited by a dedicated WATO mdule. Each rule consits of a condition +The rules have a structure similar to those in the Event Console. They are +edited by a dedicated WATO module. Each rule consist of a condition and a notification action. The condition can be formed of: -* whether a certain timeperiod is currenlty active +* whether a certain timeperiod is currently active * the notification number (i.e. phase of escalation) * the service level (a number that can be attached to each host/service) * the event type (up, down, ok, crit, etc.) * a host specification like in WATO rules (using host tags, etc.) * a service specification using regular expressions (like in WATO rules) -Further kinds of conditions that we can think of are: +Further conditions that we can think of are: * The original state or the complete state transition (e.g. CRIT -> WARN vs. OK -> WARN) * the type of the check plugin, e.g. only checks of type "if" or "if64" * whether the host or service is contained in a certain host/service group * whether it's contained in a certain contact group * whether it has a certain contact -* the value of a certain user defined custom variable +* the value of a certain user-defined custom variable -When all conditions of a rule are fullfilled, then it matches +If all conditions of a rule are fullfilled, it matches and its action is executed. The action consist of: * Who should be notified? @@ -66,7 +67,7 @@ and its action is executed. The action consist of: * The parameters of that plugin Note: the action is not immediately executed but added to the list of planned -notifications. This list contains of triples of the following strucute: +notifications. This list consists of triples of the following structure: Contact, Plugin, Parameters