Module: check_mk
Branch: master
Commit: 9ae4b09f29ed73054627f4c561d8c0005370267a
URL:
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=9ae4b09f29ed73…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Mon Sep 30 13:20:33 2013 +0200
Added draft for possible rule based notifications
---
doc/drafts/LIESMICH.rule_based_notifications | 165 ++++++++++++++++++++++++++
1 file changed, 165 insertions(+)
diff --git a/doc/drafts/LIESMICH.rule_based_notifications
b/doc/drafts/LIESMICH.rule_based_notifications
new file mode 100644
index 0000000..6a81979
--- /dev/null
+++ b/doc/drafts/LIESMICH.rule_based_notifications
@@ -0,0 +1,165 @@
+Ausgangspunkt: die "Flexible Notifications" von Check_MK sind einigermaßen
+flexibel und bieten schon mehr Möglichkeiten, als das Standard-Nagios.
+Allerdings gibt es etliche Situationen, in denen man noch mehr Flexibilität
+braucht. Ferner ist es so, dass bei einer größeren Zahl von Benutzern es
+sehr umständlich ist, für jeden Benutzer diese korrekt einzurichten.
+
+Das folgende Konzept soll diese Probleme lösen und für die Zukunft
+ausbaubar sein.
+
+REGELBASIERTE NOTIFIKATIONEN
+----------------------------
+Grundidee: Notifikationen werden - ganz ähnlich zur Event Console -
+von einem Regelwerk abgearbeitet, dass zunächst unabhängig von einem
+konkreten Benutzer ist. Der Ablauf ist dann wie folgt:
+
+1. In Nagios/CMC geschieht ein Host/Service-Alert.
+
+2. Über einen Sammelbenutzer "checkmk-notify", der von allem Kontakt ist,
+ wird eine Notifikation ausgelöst.
+
+3. Diese ruft wie gehabt "cmk --notify" auf. Dabei wird in einer
Umgebungsvariable
+ vom Core auch die Liste der (eigentlichen) Kontakte für diesen Service
+ mitgeteilt. Bei diesen Kontakten selbst sind die Notifikationen ausgeschaltet,
+ damit sie nicht doppelt versendet werden. Dafür sorgt WATO in der Benutzerverwaltung.
+
+4. Jetzt durchläuft das Ereignis eine Regelkette, die man mit WATO editieren kann.
+ *Jede* Regel, die greift, wird ausgeführt. Dadurch wird festgelegt, welcher Benutzer
+ über welches Plugin notifiziert wird.
+
+REGELN
+------
+Die Regeln sind ähnlich aufgebaut, wie bei der Event Console und werden ähnlich
+über ein eigenes WATO-Modul gepflegt. Jede Regel hat eine Bedingung und eine
+daraus resultierende Aktion.
+
+Die Bedingung kann formuliert werden über:
+
+Wie bei bestehenden "Flexible Notifications":
+* Ob eine bestimmte Timeperiod gerade aktiv ist
+* Eskalationsnummer
+* Service Level
+* Host/Service Event-Typ (down,up,unreach,OK,CRIT,etc.)
+* Host-Bedingung wie bei den WATO-Regeln, mit Tags und expliziten Ausnahmen
+* Service-Bedingungen wie bei den WATO-Regeln mit Regexen
+
+Neu kommt dazu:
+* Eventuell: Bedingung über den Typ des Checks (z.B. nur df)
+* Eventuell: enthalten in bestimmter Host oder Servicegruppe
+* Eventuell: enthalten in bestimmter Kontaktgruppe
+* Eventuell: bestimmter Kontakt ist zuständig
+* Eventuell: Wert von bestimmter Custom-Variable
+
+Wenn die Bedingung zutrifft, legt die Regel eine Aktion fest:
+
+* Wer soll Notifiziert werden?
+ a) alle Kontakte des Hosts/Services
+ b) explizite Liste von Kontakten
+ c) Mitglieder einer bestimmten Kontaktgruppe
+ d) Email/Pager-Adressen, die nicht Kontakt sind
+ e) alle Kontakte
+
+* Mit welchem Plugin soll notifiziert werden?
+
+* Die Parameter dieses Plugins
+
+Die Aktion wird aber nicht sofort ausgeführt, sondern zunächst in
+einer Aktionsliste gespeichert. Diese ist eine Liste von Tupeln
+mit dem Aufbau
+
+ Kontakt, Plugin, Parameter
+
+
+AUSSCHLUSS-REGELN
+-----------------
+Um besser Ausnahmen behandeln zu können, kann man Ausschluss-Regeln
+definieren. Hierzu wird die Regel wie gehabt aufgebaut, nur wird
+jetzt festgelegt, wer *nicht* notifiziert werden kann. Dabei ist die
+Reihenfolge der Regeln entscheidend. Beispiel:
+
+Regel 1 ...
+Regel 2 ...
+Regel 3 -> löst Notifikation an A und B mit Plugin P aus
+Regel 4 ...
+Regel 5 -> legt fest, dass B *nicht* über Plugin P notifiziert wird
+
+--> Nur A wird mit P notifiziert.
+
+Achtung: Da - anders als z.B. bei der Event Console - immer *alle* Regeln
+ausgewertet werden, muss man hier die Ausnahmen *nach* den allgemeinen
+Regeln definieren. So können spätere Regeln frühere immer wieder revidieren.
+
+Auch bei Sperrregeln kann man ein Plugin auswählen. Dann werden nur die
+Notifikationen mit diesem Plugin gelöscht (um z.B. keine SMS zu bekommen)
+
+
+BENUTZER-REGELN
+---------------
+Damit trotz allem Benutzer individuell etwas konfigurieren können, kann
+jeder Benutzer eigenen Regeln definieren. Diese sind analog aufgebaut.
+Allerdings ist bei der Frage *wer* notifiziert werden soll, nur der
+eigene Kontakt auswählbar. Ausschlussregeln sind aber möglich. Die Benutzer-Regeln
+werden immer *nach* den globalen Regeln ausgewertet.
+
+Der Benutzer kann somit:
+
+- Notifikationen hinzufügen
+- durch globale Regeln erzeugte Notifikationen abklemmen
+
+Merke: Der Benutzer kann so auch Notifikationen "abbonieren" für
+Hosts/Services, für die er im Nagios kein Kontakt ist!
+
+
+FALLBACK
+--------
+Wenn auf eine Notifikationsereignis keine einzige Regel greift, so wird
+stattdessen eine Email ein eine global einstellbare Default-Adresse
+versendet.
+
+
+UMSETZUNG IN WATO
+-----------------
+Im WATO sieht das ganze neue Konzept dann so aus:
+
+* Über eine neue globale Option werden die regelbasierten
+ Notifikationen eingeschaltet. Diese sind zunächst per Default aus,
+ später (1.4.0) dann an.
+
+* Wenn sie an sind, dann ändert sich der Notifikations-Abschnitt
+ bei den Benutzereinstellungen. Der aktuelle Block verschwindet
+ komplett. Anstelle dessen kommt man über einen neuen Knopf auf
+ eine eigene neue Seite, in der man die individuellen Regeln des
+ Benutzers festlegen kann. Ein-/Ausschalten kann man die Notifikationen
+ hier nicht. Das geht dann bei Bedarf über eine Regel.
+
+* Wenn bereits flexible Notifications konfiguriert waren, werden
+ diese nicht automatisch in regelbasiert konvertiert. Die Einstellungen
+ bleiben aber latent vorhanden für den Fall, dass man wieder zurückschaltet.
+
+* Ein neues WATO-Modul zeigt die globalen Notifikations-Regeln. Das
+ gleiche Modul wird auch für die Benutzer-Individuellen Regeln leicht
+ aberwandelt verwendet.
+
+ In diesem Modul kann man Regeln anlegen, ändern, löschen und umsortieren -
+ analog zur Event Console. Eventuell könnte man ein Simulationsfeld machen,
+ mit dem man eine Notifikation ausprobieren kann. Das ist allerdings deutlich
+ aufwendiger, als bei der EC, weil eine Notifikation deutlich mehr Datenfelder
+ hat und die Logik dann in der GUI dupliziert werden muss.
+
+
+UMSETZUNG IN CHECK_MK
+---------------------
+Das cmk --notify muss automatisch erkennen, dass es die regelbasierte
+Notifikation verwendet werden soll. Das kann z.B. am Kontaktnamen
+checkmk-notify festgemacht werden. Es führt dann das Regelwerk aus. Dieses
+ist zum einen in einer main.mk-Variable gespeichert, zum anderen in den
+individuellen contacts-Einstellungen. Es müssen bei jeder Notifikation
+alle Regeln aller Kontakte ausgeführt werden!
+
+im notify.log muss man bei entsprechendem Level wie bisher auch genau
+erklärt bekommen, warum jetzt welche Notifikation erzeugt oder verhindert
+wurde.
+
+Bei der Konfigerzeugung für Nagios/CMC muss man einen speziellen
+Benutzer anlegen, der für alles Kontakt ist.
+