1. Einleitung
Nachdem sich der Artikel Grundlagen zu Benachrichtigungen mit grundsätzlichen Dingen rund um Benachrichtigungen befasst hat, beschäftigt sich dieser Artikel nun mit Benachrichtigungen per E-Mail sowie der Erstellung von Benachrichtigungen über Regeln.
2. Die zentrale Ansicht der Benachrichtigungen
Über Setup > Events > Notification gelangen Sie zur Übersichtsseite der Benachrichtigungen. Hier sind alle entscheidenden Informationen rund um dieses Thema gebündelt:
Ein funktionierendes Benachrichtigungssystem basiert auf dem Ineinandergreifen etlicher Komponenten, die alle eingestellt sein wollen. Diese Übersichtsseite erspart Ihnen die Suche nach den einzelnen Regeln, Parametern etc. in den verschiedenen Bereichen von Checkmk. Sie können von hier aus alle Aspekte rund um das Thema Benachrichtigung erreichen.
2.1. Status der Benachrichtigungen
Im linken Bereich der Seite sehen Sie erst einmal eine Übersicht über den aktuellen Status der Benachrichtigungen:
Angezeigt werden:
Failed notifications |
Anzahl der fehlgeschlagenen Benachrichtigungen. Wenn fehlgeschlagene Benachrichtigungen existieren, so wird darunter ein Link zur entsprechenden Übersicht angezeigt. |
Total sent notifications |
Anzahl der gesendeten Benachrichtigungen. Wenn fehlgeschlagene Benachrichtigungen existieren, so wird darunter ein Link zu den Notifications of host & services, gefiltert für die letzten 7 Tage, angezeigt. Darüber können Sie einen genaueren Blick darauf werfen, welche Benachrichtigungen gesendet wurden. |
Core status of notifications |
Zeigt an, auf wie vielen Checkmk-Instanzen Benachrichtigungen aktiviert sind. Wenn sie auf einer Instanz z. B. über das Snapin Master control deaktiviert sind, wird der Instanz-Name angezeigt. Damit können Sie prüfen, ob dies beabsichtigt war. |
2.2. Benachrichtigungsregeln
Rechts neben den Statusanzeigen finden Sie Links zu allen in Checkmk existierenden Regeln rund um die Benachrichtigungen:
Von hier aus gelangen Sie sowohl zu den Regeln zur Optimierung Ihrer Benachrichtigungen als auch zu allen weiteren Regeln rund um das Thema Benachrichtigung.
 |
Die hier angezeigten Regeln kommen Ihnen möglicherweise bereits von anderen Stellen in Checkmk bekannt vor. Hier wurden keine neuen Regeln kreiert, sondern lediglich die vorhandenen übersichtlich zusammengefasst. |
2.3. Globale und vordefinierte Benachrichtigungsregeln
Den letzten Teil der Übersichtsseite bilden die bestehenden globalen Regeln.
Wenn Sie Checkmk frisch aufgesetzt haben, dann finden Sie genau eine Regel vordefiniert:
Solch eine Regel hat folgenden Aufbau:
Bedingung |
Alle Zustandswechsel von Hosts nach DOWN und UP und von Services nach CRIT, WARN und OK. |
Methode |
Versand einer E-Mail im HTML-Format (mit eingebetteten Metrikgraphen). |
Kontakt |
Alle Kontakte des betroffenen Hosts/Services. |
Wie gewohnt, können Sie die Regel 
bearbeiten, 
klonen, 
löschen oder eine neue Regel anlegen.
Sobald Sie mehr als eine Regel haben, können Sie die Reihenfolge der Regeln per Drag & Drop über das Symbol 
verändern.
|
Änderungen an Benachrichtigungsregeln erfordern keine Aktivierung der Änderungen. Sie sind sofort wirksam. |
3. Einfache Benachrichtigung per E-Mail
Aber bevor Sie sich mit komplexeren Benachrichtigungen beschäftigen, fangen Sie erst einmal mit einer ganz einfachen Form der Benachrichtigung an: einer simplen E-Mail.
Eine von Checkmk versendete Benachrichtigung per E-Mail im HTML-Format sieht etwa so aus:
Wie im Beispiel zu sehen ist, enthält die E-Mail auch die aktuellen Metriken des betroffenen Services.
Bevor Sie eine solche E-Mail von Checkmk erhalten, sind ein paar Vorbereitungen notwendig, die im Folgenden beschrieben sind.
3.1. Voraussetzungen
In der Standardkonfiguration von Checkmk erhält ein Benutzer Benachrichtigungen per E-Mail, wenn folgende Voraussetzungen erfüllt sind:
Der Checkmk-Server hat ein funktionierendes Setup für das Versenden von E-Mails.
Für den Benutzer ist eine E-Mail-Adresse konfiguriert.
Der Benutzer ist Mitglied einer Kontaktgruppe und somit ein Kontakt.
Bei einem Host oder Service, der dieser Kontaktgruppe zugeordnet ist, ereignet sich ein Monitoring-Ereignis, das eine Benachrichtigung auslöst.
3.2. Einrichten des Mailversands unter Linux
Damit das Versenden von E-Mails klappt, muss Ihr Checkmk-Server eine funktionierende Konfiguration des SMTP-Servers haben. Je nach Ihrer Linux-Distribution kann es sich dabei z.B. um Postfix, Qmail, Exim oder Nullmailer handeln. Die Konfiguration erfolgt mit den Mitteln Ihrer Linux-Distribution.
In der Regel beschränkt sich die Konfiguration auf das Eintragen eines „Smarthosts“ (auch SMTP-Relay-Server genannt), an den alle E-Mails weitergeleitet werden. Dies ist dann Ihr firmeninterner SMTP-Mailserver. Im LAN benötigen Smarthosts in der Regel keine Authentifizierung, was die Sache einfach macht. Der Smarthost wird bei manchen Distributionen schon während der Installation abgefragt. Bei der Checkmk-Appliance können Sie den Smarthost bequem über die Weboberfläche konfigurieren.
Sie können das Versenden von E-Mails auf der Kommandozeile mit dem Befehl mail testen.
Da es für diesen Befehl unter Linux zahlreiche unterschiedliche Implementierungen gibt, liefert Checkmk zur Vereinheitlichung die Variante aus dem Projekt Heirloom mailx mit aus — direkt im Suchpfad des Instanzbenutzers als ~/bin/mail.
Die zugehörige Konfigurationsdatei ist ~/etc/mail.rc.
Testen Sie also am besten als Instanzbenutzer, denn mit den gleichen Rechten laufen später auch die Benachrichtigungsskripte.
Der Inhalt der E-Mail wird von der Standardeingabe gelesen, der Betreff mit -s angegeben und die Zieladresse einfach als Argument ans Ende der Kommandozeile gestellt:
OMD[mysite]:~$ echo "content" | mail -s test-subject harry.hirsch@example.comDie E-Mail sollte ohne Verzögerung zugestellt werden.
Falls dies nicht klappt, finden Sie Hinweise in der Log-Datei des SMTP-Server im Verzeichnis /var/log (siehe Dateien und Verzeichnisse).
3.3. E-Mail-Adresse und Kontaktgruppen
E-Mail-Adresse und Kontaktgruppen eines Benutzers legen Sie in der Benutzerverwaltung fest:
Bei einer frisch erzeugten Checkmk-Instanz gibt es zunächst nur die Kontaktgruppe Everything. Mitglieder dieser Gruppe sind automatisch für alle Hosts und Services zuständig und werden bei jedem relevanten Monitoring-Ereignis per E-Mail benachrichtigt.
3.4. Sonderfälle: Ticketsystem, Messenger und Event Engine
Statt per E-Mail oder SMS können Sie Benachrichtigungen auch an ein Ticketsystem (wie Jira oder ServiceNow), einen Messenger (Slack, Mattermost) oder eine Event Engine (Event Console) schicken.
Für jeden dieser Sonderfälle gibt es eine eigene Benachrichtigungsmethode, die in der Benachrichtigungsregel ausgewählt werden kann. Allerdings müssen Sie bei der Erstellung der Regel die folgenden zwei Punkte beachten:
Sorgen Sie bei der Kontaktauswahl dafür, dass die Benachrichtigungen nur an einen Kontakt versendet werden, z. B. durch Auswahl eines einzelnen Benutzers. Bei den Benachrichtigungsmethoden zu Ticketsystemen & Co. dient die Kontaktauswahl nur dazu, festzulegen, dass benachrichtigt wird. Die Benachrichtigungen werden aber nicht an den ausgewählten Benutzer, sondern an das Ticketsystem gesendet. Beachten Sie, dass eine Kontaktauswahl über Kontaktgruppen, alle Kontakte eines Objekts oder ähnliches in den meisten Fällen mehrere identische Benachrichtigungen für ein Ereignis generiert, die dann doppelt, dreifach oder noch öfter im Ticketsystem landen.
Wenn der erste Punkt erfüllt ist, der Benutzer aber in mehreren Benachrichtigungsregeln für dieselbe Methode verwendet wird, dann greift jeweils nur die letzte Regel. Es empfiehlt sich daher, für jede dieser Benachrichtigungsregeln einen eigenen funktionalen Benutzer anzulegen.
3.5. Feineinstellungen für HTML-E-Mail
Wenn Sie HTML-E-Mails verschicken, haben Sie möglicherweise den Wunsch, zusätzliche Informationen hinzuzufügen oder flexibel eine Antwortadresse (Reply to) auf einen Kontakt für Rückfragen zu setzen. Hierfür gibt es die Regel Setup > Notifications > Parameters for notification methods > HTML Email und in Benachrichtigungsregeln die Benachrichtigungsmethode HTML-E-Mail. Mit diesen Regeln können Sie eine Reihe von Parametern wie Antwortadresse, zusätzliche Felder mit Details oder Freitext als HTML formatiert hinzufügen.
Beachten Sie, dass im Feld Custom HTML section (e.g. title, description…) aus Sicherheitsgründen nur eine kleine Menge an HTML-Tags zugelassen ist. Diese sind:
| Tag | Bedeutung | Hinweise |
|---|---|---|
|
Zugelassen, wenn es mit dem Attribut |
|
|
||
|
||
|
||
|
Abgekündigt. Nicht mehr verwenden! |
|
|
||
|
||
|
||
|
Abgekündigt. Nicht mehr verwenden! |
|
|
Leerzeichen und Einrückungen bleiben erhalten. |
|
|
||
|
||
|
||
|
Verwendung nur innerhalb der nachfolgenden Listen |
|
|
||
|
Wie bei allen Regeln in Checkmk üblich, ist eine sehr fein granulierte Anwendung möglich, so dass Sie je nach Bedarf eine detailliert zu bestimmende Menge an Benachrichtigungen zu Hosts und Services individualisieren können.
4. Benachrichtigungen per Regeln steuern
Neben den einfachen E-Mail-Benachrichtigungen können Sie mit Checkmk aber auch komplexere Benachrichtigungssysteme aufbauen.
4.1. Vereinfachte Regelerstellung
Um Ihnen die Regelerstellung für Benachrichtigungen zu vereinfachen, sieht Checkmk hier anders aus als Sie es aus anderen Bereichen gewöhnt sind. Mit Setup > Events > Notifications > Add notification rule gelangen Sie zum Einstieg in die Erstellung von Benachrichtigungen:
Hier müssen Sie sich nun entscheiden.
Wählen Sie den Guided mode, so werden Sie abschnittsweise durch die Erstellung einer Benachrichtigungsregel geführt. Jeder Abschnitt behandelt gezielt einen Aspekt der Benachrichtigung. Füllen Sie den jeweiligen Abschnitt mit den für Ihre Umgebung relevanten Daten. Beschreibungen zu den einzelnen Themen finden Sie im weiteren Verlauf dieses Artikels. Haben Sie einen Abschnitt bearbeitet, so klicken Sie auf Next step…. Ihre Angaben werden dann — soweit sie technisch zwingend erforderlich sind — verifiziert. Fehlen beispielsweise technisch relevante Daten wie die zu nutzende E-Mailadresse, so erhalten Sie eine Fehlermeldung. Nach korrekter Eingabe der wesentlichen Basisdaten gelangen Sie zum nächsten Abschnitt bis Sie am Ende eine komplette Benachrichtigungsregel vorbereitet haben. Schließen Sie die Erstellung dann entweder mit Apply & test notification rule oder Apply & create another rule ab.
Alternativ können Sie den Overview mode nutzen. Dieser ist vor allem für die gezielte Bearbeitung einzelner Parameter in einer bestehenden Benachrichtigungsregel sinnvoll. Oder auch dann, wenn Sie sich schon sehr gut mit der Regelerstellung auskennen und nicht mehr geführt werden wollen. Im Overview mode sehen Sie alle Bearbeitungsabschnitte gleichzeitig und können direkt alle Felder und Optionen bearbeiten. Die technische Verifizierung erfolgt dann einmalig und über alle Abschnitte hinweg sobald Sie auf Apply & test notification rule oder Apply & create another rule klicken.
4.2. Aufbau der Benachrichtigungsregeln
Im Folgenden stellen wir den Aufbau der Benachrichtigungsregeln mit den Festlegungen zu Bedingungen, Ereignisarten, Filtern, Benachrichtigungsmethoden, Kontakten und allgemeinen Eigenschaften vor.
Bedingungen
Bedingungen legen fest, wann eine Regel Anwendung findet. Sie sind die Grundlage für jede Regel. 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.
Ereignisarten definieren
Im folgenden Beispiel für den Aufbau einer Benachrichtigungsregel sollen zwei Zustandsänderungen Benachrichtigungen auslösen:
Hosts, die auf den Zustand DOWN wechseln und
Services, die auf den Zustand CRIT wechseln.
Dies wird in Schritt 1 festgelegt:
Die Ausnahme von der UND-Verknüpfung
Generell gilt in Checkmk: Nur wenn ein Monitoring-Ereignis alle konfigurierten Bedingungen erfüllt, kommt die Benachrichtigungsregel zur Anwendung. Zu dieser allgemeinen Regel gibt es jedoch eine wichtige Ausnahme: für die Bedingungen Host events und Service events.
Falls Sie nur Host events auswählen, wird die Regel auf kein einziges Service-Ereignis zutreffen. Analog gilt dies auch für die Auswahl von Service events und Host-Ereignisse. Falls Sie aber beide Bedingungen aktivieren, greift die Regel, sobald ein Ereignis in einer der beiden Bedingungen festgelegt 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.
Host- und Service-Filter setzen
Im 2. Schritt nutzen Sie diverse Filter, um die Hosts und Services zu bestimmen, für die die Benachrichtigungsregel gelten soll.
Angenommen, Sie würden den Filter so setzen, dass nur eine Benachrichtigung erfolgen würde, wenn ein Monitoring-Ereignis für einen Service, der mit dem Namen NTP beginnt, auf einem Host im Ordner Main einträte:
Das Ergebnis dieser Benachrichtigungsregel mit den drei Einzelbedingungen (Statusänderungen, Service-Name, Ordner) wäre, dass nur Benachrichtigungen erfolgen würden, wenn der Service NTP auf CRIT ginge — und die Zustandsänderungen des Hosts würden ignoriert, weil kein Monitoring-Ereignis die Zustandsänderung eines Hosts und den Service-Namen mit NTP enthalten würde.
Ein Hinweis zur Option Contact group filters im obigen Bild: 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 unten beschriebenen Kontaktauswahl zu tun.
Benachrichtigungsmethode
Die Benachrichtigungsmethode in Schritt 3 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.
Die passende Seite zur Einstellung der Parameter erscheint nach der Auswahl der Methode, sobald Sie auf Create klicken.
Bevor Sie hier aber Einstellungen in der einzelnen Benachrichtigungsregel machen, sollten Sie wissen, dass Sie Parameter für die Benachrichtigungsmethoden auch allgemeingültig an zwei anderen Stellen in Checkmk setzen können:
In den Parametern für Benachrichtigungsmethoden, die weiter unten in diesem Artikel beschrieben werden. In der Benachrichtigungsregel wählen Sie dann unter Select parameters die gewünschte Parameterdefinition aus, bevor Sie auf Create klicken, um die ausgewählte Parameterdefinition für diese Benachrichtigungsregel abzuändern..
In den Regeln für Hosts und Services: 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.
Ändern Sie die Parameterdefinitionen in der Benachrichtigungsregel nur dann, wenn sie für Einzelfälle von diesen Einstellungen abweichen wollen. 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 Send notification können Sie auch Suppress all previous auswählen. Dann werden Benachrichtigungen in Form dieser Methode aus früheren Regeln wieder verworfen. Näheres dazu finden Sie im Abschnitt Thema Benachrichtigungen durch Regeln löschen.
|
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. |
Kontaktauswahl
Der häufigste Fall bei der Festlegung der Kontakte ist, alle Benutzer zu benachrichtigen, die als Kontakt für den jeweiligen Host/Service eingetragen sind. Dies ist das „normale“ Verhalten und naheliegend, da über die Kontakte ebenfalls gesteuert wird, welcher Benutzer welche Objekte in der GUI zu sehen bekommt und quasi dafür zuständig ist.
Sie können bei der Kontaktauswahl mit Add recipient mehrere Optionen angeben und so die Benachrichtigung auf mehr Kontakte ausweiten. Doppelte Kontakte werden von Checkmk automatisch entfernt. Damit die Regel sinnvoll ist, muss mindestens eine Auswahl getroffen werden.
Die beiden Optionen unter Restrict previous options to arbeiten etwas anders.
Hier werden die durch die übrigen Optionen ausgewählten Kontakte wieder eingeschränkt.
Damit können Sie auch eine UND-Verknüpfung zwischen Kontaktgruppen herstellen, um z. B. alle Kontakte zu benachrichtigen, die gleichzeitig Mitglied der Gruppen Linux und Data center sind.
Durch die Angabe von E-Mail-Adressen (Explicit email addresses) können Sie Personen benachrichtigen, die überhaupt nicht als Benutzer in Checkmk hinterlegt sind. Dies ist natürlich nur bei den Benachrichtigungsmethoden sinnvoll, die E-Mails verschicken.
Falls Sie in der Benachrichtigungsmethode Suppress all previous gewählt haben, werden nur Benachrichtigungen an die hier gewählten Kontakte entfernt.
|
Falls Sie als Benachrichtigungsmethode ein Ticketsystem, einen Messenger oder eine Event Engine nutzen, beachten Sie zusätzlich die Hinweise zu diesen Sonderfällen. |
Bedingungen für den Benachrichtigungsversand
Den Schritt Sending conditions können Sie für einfache Regeln erst einmal überspringen. Diese sind primär interessant, wenn Sie Eskalationen aufbauen wollen.
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.
Mit der Option Allow users to deactivate this notification können Sie Benutzern erlauben, Benachrichtigungen „abzubestellen“, die von dieser Regel erzeugt werden. Wie das geht, zeigen wir bei den persönlichen Benachrichtigungen.
4.3. Parameter für Benachrichtigungsmethoden festlegen
Für jede Benachrichtigungsmethode können Sie separate Parameter festlegen. Diese Parameter werden in Checkmk getrennt von den eigentlichen Benachrichtigungsregeln definiert und verwaltet. Dadurch können Sie die Parameter für mehrere Regeln gleichzeitig verwenden. Auftretende Änderungen brauchen Sie nur zentral an einer Stelle vornehmen. Und Sie erhalten ein einheitliches Erscheinungsbild für alle Benachrichtigungen des gleichen Typs, unabhängig von den auslösenden Regeln.
Öffnen Sie über Setup > Events > Notifications und den Knopf Parameters for notifications methods die Übersicht aller einstellbaren Parameter:
Von hier aus können Sie die allgemeinen Parameter für jede Methode erstellen, bearbeiten und — wenn sie in keiner Regel genutzt werden — auch wieder löschen.
4.4. Benachrichtigungsregeln testen
Für den Test von Benachrichtigungsregeln bietet Checkmk mit Test notifications ein smartes Werkzeug. Mit diesem können Sie eine Benachrichtigung für einen Host oder einen Service simulieren und erkennen, welche Ihrer Benachrichtigungsregeln greifen. Zusätzlich zur Simulation können Sie die Benachrichtigung auch versenden lassen.
Sie erreichen den Benachrichtigungstest am schnellsten über Setup > Events > Test notifications. Zusätzlich gibt es noch andere Möglichkeiten zum Aufruf aus einigen Tabellenansichten im Monitoring (Service-Liste und Service-Details) und im Setup (Eigenschaften eines Hosts), jeweils im Menü Host > Test notifications.
Zuerst entscheiden Sie durch Klick auf einen der beiden Knöpfe, ob es um eine Benachrichtigung für einen Host oder einen Service geht. Welcher Host bzw. Service es denn sein soll, wählen Sie danach aus. Als Ereignis können Sie einen Zustandswechsel oder den Beginn einer Wartungszeit wählen. Eine Beschreibung des Ereignisses können Sie bei Plug-in output hinzufügen. Mit der Checkbox Send out notification for specific method legen Sie fest, ob die Benachrichtigung nur simuliert oder auch tatsächlich versendet wird.
Unter Advanced condition simulation verbergen sich abschließend zwei weitere Optionen, mit denen Sie den Zeitpunkt und die Anzahl der Benachrichtigungen festlegen können. Damit können Sie Benachrichtigungsregeln testen, die nur in einem bestimmten Zeitraum (z.B. außerhalb der Geschäftszeiten) gelten oder die nach einer festgelegten Anzahl von wiederholten Benachrichtigungen eine Eskalation starten.
Durch Klick auf Test notifications starten Sie den Test — und auch den Versand, sofern Sie diese Option ausgewählt haben. Unterhalb des Kastens Test notifications werden die Ergebnisse eingeblendet:
Zuerst kommt die Zusammenfassung.
Unter Test results erfahren Sie, wie viele Benachrichtigungsregeln greifen und wie viele Benachrichtigungen daraus resultieren.
Haben Sie den Versand gewählt, wird Ihnen hier die entsprechende Meldung notifications have been sent out angezeigt.
Das muss dann sofort zu einer E-Mail für dieses Problem führen.
Die Zeile darunter fasst die aus Ihren Eingaben erzeugten Benachrichtigungen zusammen.
Durch Klick auf das Symbol 
können Sie den Benachrichtigungskontext einblenden.
So sehen Sie die im Kontext dieser Benachrichtigung gültigen Umgebungsvariablen und ihre Werte.
Die folgenden beiden Abschnitte zeigen dann mehr Details:
Unter Predicted notifications sehen Sie, an wen und über welchen Weg Benachrichtigungen abgesetzt würden. Diese Information zur Simulation erhalten Sie auch dann, wenn Sie den Versand der Benachrichtigung nicht ausgewählt haben.
Unter Global notification rules werden die Benachrichtigungsregeln aufgelistet, die Sie hier erstellt haben.
An dieser Stelle ist nur die erste Spalte der Tabelle wichtig, die mit Symbolen anzeigt, welche der Regeln greifen 
und welche nicht 
.
|
Wie gewohnt können Sie alternativ zum Test von Benachrichtigungen via Simulation auch weiterhin Benachrichtigungen direkt über die GUI auslösen, z. B. mit den Kommandos Send custom notification und Fake check results. |
4.5. Periodisch wiederholte Benachrichtigungen und Eskalationen
Bei manchen Systemen kann es sinnvoll sein, es nicht bei einer einzelnen Benachrichtigung zu belassen, falls das Problem über einen längeren Zeitraum weiterhin besteht, z. B. bei Hosts, deren Host-Merkmal Criticality auf Business critical gesetzt ist.
Periodisch wiederholte Benachrichtigungen einrichten
Sie können Checkmk so einrichten, dass es in einem festen Intervall immer weitere Benachrichtigungen versendet, solange bis das Problem entweder 
quittiert oder behoben wurde.
Die Einstellung dafür finden Sie in den Regelsätzen Periodic notifications during host problems bzw. Periodic notifications during service problems:
Sobald diese Option aktiv ist, wird Checkmk für ein fortbestehendes Problem im konfigurierten Intervall weitere Benachrichtigungen erzeugen. Die Benachrichtigungen bekommen eine laufende Nummer, welche bei 1 (für die erste Benachrichtigung) beginnt.
Periodische Benachrichtigungen haben nicht nur den Nutzen, das Problem immer wieder in Erinnerung zu rufen (also den Operator damit zu nerven), sondern sie bilden auch die Grundlage für Eskalationen. Dies bedeutet, dass nach Ablauf einer bestimmten Zeit die Benachrichtigung an andere Personen eskaliert werden kann.
Eskalationen aufbauen und verstehen
Um eine Eskalation einzurichten, erzeugen Sie zusätzlich eine Benachrichtigungsregel, welche die Bedingung Limit notifications by count to verwendet.
Tragen Sie hier als Bereich für den Zähler 3 bis 99999 ein, so greift diese Regel ab der dritten Benachrichtigung. Diese Eskalation kann dann entweder durch die Wahl einer anderen Methode (z.B. SMS) erfolgen oder durch die Benachrichtigung von anderen Personen (Kontaktauswahl).
Mit der Option Throttling of 'Periodic notifications' können Sie die Rate der wiederholten Benachrichtigungen nach einer bestimmten Zeit reduzieren. So können Sie z.B. zunächst jede Stunde eine E-Mail senden lassen und später das Ganze auf einmal am Tag beschränken.
Mit mehreren Benachrichtigungsregeln können Sie ein Eskalationsmodell aufbauen. Aber wie läuft diese Eskalation dann ab? Wer wird wann informiert? Hierzu ein Beispiel, umgesetzt mit einer Regel für periodisch wiederholte Benachrichtigungen und drei Benachrichtigungsregeln:
Ein Service löst im Problemfall alle 60 Minuten eine Benachrichtigung, z.B. in Form einer E-Mail, aus, solange bis das Problem behoben oder bestätigt wird.
Die Benachrichtigungen eins bis fünf gehen an die zwei zuständigen Mitarbeiter.
Die Benachrichtigungen sechs bis zehn gehen zusätzlich an den betreffenden Teamleiter.
Ab Benachrichtigung elf geht stattdessen täglich eine Mail an die Firmenleitung.
Morgens um 9 Uhr tritt im Betrieb ein Problem auf. Die beiden Mitarbeiter werden benachrichtigt, reagieren aber nicht (aus welchen Gründen auch immer). So bekommen sie um 10, 11, 12 und 13 Uhr jeweils eine weitere E-Mail. Ab der sechsten Benachrichtigung um 14 Uhr bekommt nun zusätzlich auch der Teamleiter eine E-Mail — trotzdem ändert sich weiterhin nichts am Problem. So werden um 15, 16, 17 und 18 Uhr weitere E-Mails an die Mitarbeiter und an den Teamleiter verschickt.
Um 19 Uhr greift die dritte Eskalationsstufe: ab jetzt werden keine E-Mails mehr an die Mitarbeiter oder den Teamleiter verschickt. Stattdessen bekommt die Firmenleitung bis zur Problembehebung nun täglich um 19 Uhr eine E-Mail.
Sobald das Problem behoben ist und der Service in Checkmk wieder auf OK geht, wird automatisch eine „Entwarnung“ an den zuletzt benachrichtigten Personenkreis versandt: Im obigen Beispiel also bei einer Problembehebung vor 14 Uhr an die beiden Mitarbeiter, bei einer Problembehebung zwischen 14 und 19 Uhr an die Mitarbeiter und den Teamleiter und nach 19 Uhr nur noch an die Firmenleitung.
4.6. Benachrichtigungen durch Regeln löschen
Wie bei der Auswahl der Benachrichtigungsmethode bereits erwähnt, finden Sie dort auch die Auswahlmöglichkeit Suppress all previous. Um die Funktionsweise einer solchen Regel zu verstehen, stellen Sie sich am besten die Benachrichtigungstabelle bildlich vor. Nehmen wir an, einige Regeln zu einem konkreten Monitoring-Ereignis wurden bereits abgearbeitet. Dadurch wurden die folgenden drei Benachrichtigungen erzeugt:
| Wer (Kontakt) | Wie (Methode) |
|---|---|
Harry Hirsch |
|
Bruno Weizenkeim |
|
Bruno Weizenkeim |
SMS |
Nun kommt die nächste Regel mit der Methode SMS und der Auswahl Suppress all previous. Als Kontakt sind die Mitglieder der Kontaktgruppe „Windows“ ausgewählt, der auch Bruno Weizenkeim angehört. Als Ergebnis dieser Regel wird der Eintrag „Bruno Weizenkeim / SMS“ aus der Tabelle entfernt, die anschließend so aussieht:
| Wer (Kontakt) | Wie (Methode) |
|---|---|
Harry Hirsch |
|
Bruno Weizenkeim |
Sollte eine spätere Regel wieder eine SMS-Benachrichtigung für Bruno definieren, so hätte diese Vorrang und die SMS-Benachrichtigung würde wieder in die Tabelle 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.
4.7. 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:
In der Historie des betroffenen Services können Sie dann die Zustellung genau nachverfolgen. Hier ist ein Beispiel, in dem ein Service testweise von Hand auf CRIT gesetzt wurde. Folgende Abbildung zeigt die Benachrichtigungen für diesen Service, die Sie sich auf der Seite mit den Service-Details mit Service > Service Notifications anzeigen lassen können:
Sie sehen dabei die vier Einzelschritte in der zeitlichen Abfolge von unten nach oben, wie wir sie bereits im Artikel über die Grundlagen zu Benachrichtigungen im Kapitel zur Benachrichtigungshistorie vorgestellt haben.
Der wichtige Unterschied ist, dass jetzt im 
obersten Eintrag zu sehen ist, dass die E-Mail erfolgreich an den Smarthost übergeben wurde und dessen Antwort success ist.
Die einzelnen Schritte können Sie auch in der Log-Datei ~/var/log/notify.log nachverfolgen.
Die folgenden Zeilen gehören zum letzten Schritt und enthalten die Antwort des SMTP-Servers:
2021-08-26 10:02:22,016 [20] [cmk.base.notify] Got spool file d3b417a5 (mysrv;CPU load) for local delivery via mail
2021-08-26 10:02:22,017 [20] [cmk.base.notify] executing /omd/sites/mysite/share/check_mk/notifications/mail
2021-08-26 10:02:29,538 [20] [cmk.base.notify] Output: success 250 - b'2.0.0 Ok: queued as 1BE667EE7D6'Die Message-ID 1BE667EE7D6 wird in der Log-Datei des Smarthosts auftauchen.
Dort können Sie dann im Zweifel recherchieren, wo die E-Mail verblieben ist.
Auf jeden Fall können Sie so belegen, das und wann Sie von Checkmk korrekt übergeben wurde.
Wiederholen wir den Test von oben, jedoch diesmal mit einem falsch konfigurierten Passwort für die SMTP-Übergabe an den Smarthost.
Hier sieht man im Klartext die SMTP-Fehlermeldung Error: authentication failed vom Smarthost:
Doch was tun bei fehlgeschlagenen Benachrichtigungen? Diese wiederum per E-Mail zu benachrichtigen ist augenscheinlich keine gute Lösung. Anstelle dessen zeigt Checkmk einen deutlichen Warnhinweis mit roter Hintergrundfarbe im Snapin Overview an:
Hier können Sie:
durch Klick auf den Text … failed notifications zu einer Liste der fehlgeschlagenen Benachrichtigungen kommen und
durch Klick auf
diese Meldungen bestätigen und mit einem Klick auf 
Confirm in der sich öffnenden Übersicht den Hinweis wieder entfernen.
Wichtig: Beachten Sie, dass die direkte Zustellung per SMTP in Fehlersituationen dazu führen kann, dass das Benachrichtigungsskript sehr lange läuft und am Ende in einen Timeout gerät. Deswegen ist es unbedingt ratsam, dass Sie den Benachrichtigungs-Spooler verwenden und eine asynchrone Zustellung von Benachrichtigungen einstellen.
Das Verhalten bei wiederholbaren Fehlern (wie einem SMTP-Timeout) können Sie mit Global settings > Notifications > Notification spooler configuration pro Benachrichtigungsmethode einstellen:
Neben einem optionalen Timeout (Default ist 1 Minute) und einer maximalen Anzahl von Wiederholversuchen können Sie mit Maximum concurrent executions festlegen, ob das Skript mehrfach parallel laufen und so gleichzeitig mehrere Benachrichtigungen versenden darf. Ist das Benachrichtigungsskript sehr langsam, kann eine parallele Ausführung sinnvoll sein. Allerdings muss es dann auch so programmiert sein, dass eine Mehrfachausführung sauber läuft (und nicht das Skript z.B. bestimmte Dateien für sich beansprucht).
Eine mehrfache parallele Zustellung per SMTP ist unproblematisch, da der Zielserver mehrere parallele Verbindungen verwalten kann. Bei der Zustellung von SMS direkt über ein Modem ohne weiteren Spooler ist das sicher nicht der Fall und Sie sollten dann bei der Einstellung 1 bleiben.
Wichtig: Für Bulk-Benachrichtigungen steht die nachvollziehbare Zustellung per SMTP nicht zur Verfügung!
5. Bulk-Benachrichtigungen
5.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 (Max. notifications per bulk). Bei Erreichen dieses Maximums wird die Bulk-Benachrichtigung sofort verschickt.
5.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.
6. Was ist, wenn keine Regel greift?
Wer konfiguriert, kann auch Fehler machen. Ein möglicher Fehler bei der Benachrichtigungskonfiguration wäre, dass das Monitoring ein kritisches Problem entdeckt und keine einzige Benachrichtigungsregel greift.
Um Sie vor so einem Fall zu schützen, bietet Checkmk die Einstellung Fallback email address for notifications. Diese finden Sie unter Setup > General > Global settings im Abschnitt Notifications. Tragen Sie hier eine E-Mail-Adresse ein. An diese werden Benachrichtigungen verschickt, für die keine einzige Benachrichtigungsregel greift.
|
Alternativ können Sie auch einen Benutzer in seinen persönlichen Einstellungen zum Empfänger machen. Als Fallback-Adresse wird die beim Benutzer hinterlegte E-Mail-Adresse verwendet. |
Die Fallback-Adresse wird nur dann verwendet, wenn keine Regel greift, nicht wenn keine Benachrichtigung erzeugt würde! Wie wir im Abschnitt zum Löschen von Benachrichtigungen gezeigt haben, ist das explizite Löschen von Benachrichtigungen ja erwünscht und kein Konfigurationsfehler.
Die Einrichtung der Fallback-Adresse wird auf der Seite Notifications durch die folgende Warnung „empfohlen“:
Falls Sie - aus welchen Gründen auch immer - ausschließlich die Warnung loswerden, aber gleichzeitig keine E-Mails an der Fallback-Adresse erhalten wollen, so tragen Sie trotzdem zuerst eine Fallback-Adresse ein und erzeugen dann eine neue Regel als erste Regel, die alle bisherigen Benachrichtigungen löscht. Diese Regel ist für die Benachrichtigungskonfiguration wirkungslos, da ja hier noch keine Benachrichtigungen erzeugt wurden. Aber damit stellen Sie sicher, dass immer eine Regel greift und lassen somit die Warnung verschwinden.
Wir raten von diesem Vorgehen explizit ab, weil Sie so eventuell übersehen, dass Ihre Regelkette Lücken aufweist.
|
Wenn Sie Benachrichtigungen nur für sich persönlich abschalten wollen, können Sie dies über die persönlichen Benachrichtigungsregeln machen. |