1. Einleitung
Eine nützliche Besonderheit des Benachrichtigungssystems von Checkmk ist, dass Benutzer sich auch ohne Administratorrechte ihre Benachrichtigungen anpassen können. Benutzer können:
Benachrichtigungen hinzufügen, die sie sonst nicht bekommen würden („abonnieren“),
Benachrichtigungen löschen, die sie sonst bekommen würden (falls nicht gesperrt),
Parameter von Benachrichtigungen anpassen und
ihre Benachrichtigungen vorübergehend ganz abschalten.
2. Benachrichtigungen per persönlicher Regeln steuern
Der Einstieg aus Sicht des Benutzers ist das User-Menü, und dort der Eintrag Notification rules. Auf der Seite Your personal notification rules kann mit Add rule eine neue Regel erzeugt werden.
Persönliche Benachrichtigungsregeln sind inhaltlich ähnlich wie die globalen Benachrichtigungsregeln aufgebaut — mit einem Unterschied: Sie enthalten keine Kontaktauswahl. Als Kontakt ist automatisch der Benutzer selbst gewählt. Dadurch kann ein Benutzer nur für sich selbst Benachrichtigungen hinzufügen oder löschen.
Löschen kann der Benutzer Benachrichtigungen allerdings nur dann, wenn in der (globalen) Regel, die sie erzeugt, die Option Allow users to deactivate this notification aktiviert ist:
In der Reihenfolge der Benachrichtigungsregeln kommen die persönlichen Regeln immer nach den globalen Regeln und können so die bisher erzeugte Benachrichtigungstabelle anpassen. Bis auf das gerade beschriebene Sperren der Löschung gelten also die globalen Regeln immer als Standardeinstellung, die vom Benutzer angepasst werden kann.
 |
Änderungen an Benachrichtigungsregeln erfordern keine Aktivierung der Änderungen. Sie sind sofort wirksam. |
2.1. Aufbau der Benachrichtigungsregeln
Im Folgenden stellen wir den generellen Aufbau der persönlichen Benachrichtigungsregeln mit den Festlegungen zu allgemeinen Eigenschaften, Benachrichtigungsmethoden und Bedingungen vor.
Allgemeine Eigenschaften
Wie bei allen Regeln in Checkmk, können Sie hier eine Beschreibung und einen Kommentar für die Regel hinterlegen sowie die Regel temporär abschalten.
Benachrichtigungsmethode
Die Benachrichtigungsmethode legt fest, auf welchem technischen Weg benachrichtigt werden soll, z. B. mit HTML-E-Mail.
Jede Methode ist durch ein Skript realisiert. Checkmk liefert bereits einige Skripte mit aus. Sie können aber auch recht einfach eigene Skripte in beliebigen Programmiersprachen schreiben, um speziellere Anforderungen umzusetzen, z. B. die Weiterleitung der Benachrichtigungen an ein eigenes Ticketsystem.
Eine Methode kann Parameter anbieten.
Zum Beispiel erlauben es die Methoden für ASCII- und HTML-E-Mails, die Absenderadresse (From:) explizit zu setzen.
Bevor Sie hier Einstellungen in der Benachrichtigungsregel machen, sollten Sie wissen, dass Sie Parameter für die Benachrichtigungsmethoden auch in den Regeln für Hosts und Services setzen können: Unter Setup > Services > Service monitoring rules finden Sie im Abschnitt Notifications für jede Benachrichtigungsmethode einen Regelsatz, mit dem Sie die gleichen Einstellungen festlegen können — und das wie gewohnt abhängig von Host oder Service.
Parameterdefinitionen in Benachrichtigungsregeln dienen dazu, für Einzelfälle von diesen Einstellungen abzuweichen. So können Sie z. B. global einen bestimmten Betreff für Ihre E-Mail festlegen, aber in einer einzelnen Benachrichtigungsregel einen alternativen Betreff definieren.
Anstelle von Parametern können Sie auch Cancel previous notifications auswählen. Dann werden Benachrichtigungen in Form dieser Methode aus früheren Regeln wieder verworfen. Näheres dazu finden Sie beim Thema Löschen von Benachrichtigungen.
|
Für viele Benachrichtigungsmethoden zur Weiterleitung an andere Systeme erhalten Sie genauere Informationen in separaten Artikeln. Die Liste der Artikel finden Sie im Kapitel zu den Benachrichtigungsskripten. Falls Sie als Benachrichtigungsmethode ein Ticketsystem, einen Messenger oder eine Event Engine nutzen, beachten Sie zusätzlich die Hinweise zu diesen Sonderfällen. |
Bedingungen
Bedingungen legen fest, wann eine Regel Anwendung findet. Für das Verständnis ist es wichtig, sich daran zu erinnern, dass der Ausgangspunkt immer ein Monitoring-Ereignis von einem ganz konkreten Host oder Service ist.
Die Bedingungen befassen sich dabei
mit den statischen Eigenschaften des Objekts, z. B. ob der Service-Name den Text
/tmpenthält oder ein Host sich in einer bestimmten Host-Gruppe befindet,mit dem aktuellen Zustand bzw. der Änderung des Zustands, z. B. ob der Service gerade von OK nach CRIT gewechselt hat,
oder mit ganz anderen Dingen, z. B. ob die Zeitperiode „Arbeitszeit“ gerade aktiv ist.
Bei der Festlegung der Bedingungen gibt es zwei wichtige Punkte zu beachten:
Solange keine Bedingung definiert ist, greift die Regel bei jedem Monitoring-Ereignis.
Sobald Sie auch nur eine einzige Bedingung auswählen, greift die Regel nur, wenn auch wirklich alle ausgewählten Bedingungen erfüllt sind. Alle ausgewählten Bedingungen werden mit UND verknüpft. Von dieser wichtigen Regel gibt es nur eine Ausnahme, auf die wir später eingehen werden und die wir jetzt nicht betrachten.
Das heißt, dass Sie sehr genau darauf achten sollten, ob die von Ihnen gewählten Bedingungen gleichzeitig erfüllt sein können, damit eine Benachrichtigung auch für den gewünschten Fall ausgelöst wird.
Nehmen wir an, eine Benachrichtigung soll erfolgen, wenn ein Monitoring-Ereignis für einen Service, der mit dem Namen NTP beginnt, auf einem Host im Ordner Main eintritt:
Nehmen wir weiter an, dass diese Bedingung nun erweitert wird, indem auch alle Zustandsänderungen eines Hosts auf den Zustand DOWN eine Benachrichtigung auslösen sollen:
Das Ergebnis dieser Benachrichtigungsregel mit den drei Einzelbedingungen ist, dass nie eine Benachrichtigung erfolgen wird, weil kein Monitoring-Ereignis die Zustandsänderung eines Hosts und den Service-Namen mit NTP enthalten wird.
Den folgenden Hinweis geben wir in diesem Handbuch immer wieder. Im Zusammenhang mit der Konfiguration Ihrer Benachrichtigungen ist er allerdings nochmal besonders hervorzuheben: Blenden Sie die Inline-Hilfe mit Help > Show inline help ein, um Einzelheiten über die Auswirkungen der verschiedenen Bedingungen zu erfahren. Der folgende Auszug aus der Inline-Hilfe zur Option Match services verdeutlicht das Verhalten sehr gut: „Anmerkung: Auf Host-Benachrichtigungen trifft diese Regel nie zu, wenn diese Option benutzt wird.“
Die Ausnahme von der UND-Verknüpfung
Nur wenn ein Monitoring-Ereignis alle konfigurierten Bedingungen erfüllt, kommt die Benachrichtigungsregel zur Anwendung. Wie bereits erwähnt, gibt es zu dieser allgemeinen Regel eine wichtige Ausnahme: für die Bedingungen Match host event type und Match service event type:
Falls Sie nur Match host event type auswählen, wird die Regel auf kein einziges Service-Ereignis matchen. Analog gilt dies auch für die Auswahl von Match service event type und Host-Ereignisse. Falls Sie aber beide Bedingungen aktivieren, matcht die Regel, sobald der Ereignistyp in einer der beiden Checkbox-Listen aktiviert ist. In diesem Ausnahmefall werden diese beiden Bedingungen also nicht wie üblich mit einem logischen UND verknüpft, sondern mit einem ODER. So können Sie bequemer Host- und Service-Benachrichtigungen mit einer einzelnen Regel verwalten.
Ein Hinweis noch zu den Bedingungen Match contacts und Match contact groups:
Hier wird als Bedingung geprüft, ob der Host/Service, um den es geht, eine bestimmte Kontaktzuordnung hat. Damit kann man Dinge umsetzen wie „Host-bezogene Benachrichtigungen in der Kontaktgruppe Linux sollen nie per SMS versendet werden“. Das hat nichts mit der oben beschriebenen Kontaktauswahl zu tun.
2.2. Benachrichtigungen durch Regeln löschen
Wie bei der Auswahl der Benachrichtigungsmethode bereits erwähnt, finden Sie dort auch die Auswahlmöglichkeit Cancel previous notifications. Um die Funktionsweise einer solchen Regel zu verstehen, stellen Sie sich am besten die Benachrichtigungen bildlich vor.
Nehmen wir an, einige Regeln zu einem konkreten Monitoring-Ereignis wurden bereits abgearbeitet. Dadurch wurden für unseren Benutzer zwei Benachrichtigungen erzeugt, eine per E-Mail und eine per SMS.
Nun kommt die nächste Regel mit der Methode SMS und der Auswahl Cancel previous notifications. Als Ergebnis dieser Regel wird die SMS-Benachrichtigung an unseren Benutzer entfernt. Es wird also nur noch eine E-Mail erzeugt.
Sollte eine spätere Regel wieder eine SMS-Benachrichtigung definieren, so hätte diese Vorrang und die SMS-Benachrichtigung würde wieder in die Benachrichtigungen aufgenommen.
Zusammengefasst:
Regeln können gezielt Benachrichtigungen unterdrücken (löschen).
Löschregeln müssen nach den Regeln kommen, welche Benachrichtigungen erzeugen.
Eine Löschregel hebt nicht eine frühere Regel auf, sondern Benachrichtigungen, die aus (möglicherweise verschiedenen) früheren Regeln stammen.
Spätere Regeln können vormals gelöschte Benachrichtigungen wieder hinzufügen.
2.3. Synchrone Zustellung für HTML-E-Mails
Die nachvollziehbare Zustellung per SMTP können Sie für die Benachrichtigungsmethode HTML-E-Mail auswählen und konfigurieren, indem Sie den Smarthost (mit Name und Portnummer) und die Zugangsdaten und Verschlüsselungsmethode eintragen:
Im Artikel zu den globalen Benachrichtigungsregeln finden Sie genauere Informationen darüber, wie die erfolgreiche bzw. fehlgeschlagenen Zustellung in der Checkmk-Benutzeroberfläche und in Log-Dateien nachvollzogen werden kann.
Wichtig: Für Bulk-Benachrichtigungen steht die nachvollziehbare Benachrichtigung nicht zur Verfügung!
3. Bulk-Benachrichtigungen
3.1. Übersicht
Jeder, der mit Monitoring arbeitet, hat schon einmal erlebt, dass ein isoliertes Problem eine ganze Flut von (Folge-)Benachrichtigungen losgetreten hat. Mit den Parent-Hosts lässt sich dies in bestimmten Fällen vermeiden, leider aber nicht in allen.
Nehmen Sie ein Beispiel aus dem Checkmk-Projekt selbst: Einmal pro Tag bauen wir für jede unterstützte Linux-Distribution Installationspakete von Checkmk. Unser eigenes Checkmk-Monitoring ist so eingerichtet, dass wir für jede Distribution einen Service haben, der nur dann OK ist, wenn die richtige Anzahl von Paketen korrekt gebaut wurde. Nun kommt es gelegentlich vor, dass ein genereller Fehler in der Software das Paketieren verhindert und so gleichzeitig 43 Services auf CRIT gehen.
Die Benachrichtigungen sind bei uns so konfiguriert, dass in so einem Fall nur eine einzige E-Mail versendet wird, welche alle 43 Benachrichtigungen nacheinander auflistet. Das ist natürlich viel übersichtlicher als 43 einzelne E-Mails und verhindert, dass man im Eifer des Gefechts eine 44. E-Mail übersieht, die zu einem ganz anderen Problem gehört.
Die Funktionsweise dieser Bulk-Benachrichtigung ist sehr einfach. Wenn eine Benachrichtigung auftritt, so wird diese zunächst eine kurze Zeit lang zurückgehalten. Weitere Benachrichtigungen, die während dieser Zeit kommen, werden dann gleich mit in dieselbe E-Mail gepackt. Das Sammeln stellen Sie pro Regel ein. So können Sie z. B. tagsüber mit Einzel-E-Mails arbeiten, nachts aber mit einer Bulk-Benachrichtigung. Wird in einer Regel die Bulk-Benachrichtigung aktiviert, so erhalten Sie folgende Optionen:
Die Wartezeit können Sie beliebig konfigurieren. In vielen Fällen genügt eine Minute, da spätestens dann alle verwandten Probleme aufschlagen sollten. Sie können natürlich auch einen größeren Zeitraum einstellen. Dadurch entsteht aber eine grundsätzliche Verzögerung der Benachrichtigung.
Da es keinen Sinn ergibt, alles in einen Topf zu werfen, können Sie bestimmen, welche Gruppen von Problemen jeweils gemeinsam benachrichtigt werden sollen. Üblicherweise wird die Option Host gewählt, die dafür sorgt, dass nur Benachrichtigungen vom gleichen Host zusammengefasst werden.
Hier noch ein paar Fakten zur Bulk-Benachrichtigung:
Wenn das Sammeln in einer Regel eingeschaltet ist, kann es mit einer späteren Regel auch wieder ausgeschaltet werden — und umgekehrt.
Die Bulk-Benachrichtigung geschieht immer pro Kontakt. Jeder hat quasi seinen privaten „Sammeltopf“.
Sie können die Größe des Topfs begrenzen (Maximum bulk size). Bei Erreichen dieses Maximums wird die Bulk-Benachrichtigung sofort verschickt.
3.2. Bulk-Benachrichtigungen und Zeitperioden
Was geschieht, wenn eine Benachrichtigung innerhalb der Benachrichtigungsperiode liegt, die Bulk-Benachrichtigung, die diese Benachrichtigung enthält — und ja etwas später kommt — dann aber schon außerhalb der Benachrichtigungsperiode liegt? Und auch der umgekehrte Fall ist ja möglich …
Hier gilt ein ganz einfaches Prinzip: Alle Konfigurationen, die Benachrichtigungen auf Zeitperioden eingrenzen, gelten immer nur für die eigentliche Benachrichtigung. Die später folgende Bulk-Benachrichtigung wird immer unabhängig von sämtlichen Zeitperioden zugestellt.
4. Administrator-Einstellungen
4.1. Vorübergehend Benachrichtigungen abschalten
Die komplette Abschaltung der Benachrichtigungen durch einen Benutzer selbst ist mit der Berechtigung General Permissions > Disable all personal notifications geschützt, die für die Benutzerrolle user per Default auf no gesetzt ist.
Nur wenn Sie der Rolle user dieses Recht explizit zuweisen, bekommt ein Benutzer dafür in seinen persönlichen Einstellungen entsprechende Checkboxen angezeigt:
Da Sie als Administrator einfachen Zugriff auf die persönlichen Einstellungen der Benutzer haben, können Sie das Abschalten stellvertretend für den Benutzer machen — auch wenn diesem die oben genannte Berechtigung fehlt. Sie finden diese Einstellung unter Setup > Users > Users und dann in den Eigenschaften des Benutzerprofils.
Damit können Sie z. B. während eines Urlaubs eines Kollegen sehr schnell dessen Benachrichtigungen still schalten, ohne an der eigentlichen Konfiguration etwas ändern zu müssen.
4.2. Benutzerdefinierte Anpassungen verhindern
Wenn Sie ein Anpassen der Regeln durch den Benutzer ganz unterbinden möchten, können Sie der Benutzerrolle user die Berechtigung General Permissions > Edit personal notification settings entziehen.
Als Administrator können Sie sich alle Benutzerregeln anzeigen lassen, wenn Sie auf der Seite Setup > Events > Notifications im Menü Display > Show user rules wählen:
Nach den globalen Regeln werden die persönlichen Regeln aufgelistet, die Sie mit 
auch bearbeiten können.