Benachrichtigungen

In der Standardkonfiguration von Checkmk erhält ein Benutzer Benachrichtigungen per E-Mail, wenn folgende Voraussetzungen erfüllt sind:

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:

Die 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).

E-Mail-Adresse und Kontaktgruppe 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.

Hinweis: Falls Ihre Checkmk-Installation mit einer älteren Version erzeugt wurde, kann diese Gruppe auch Everybody heißen. Dies ist aber logisch falsch, denn diese Gruppe beinhaltet ja nicht alle Benutzer, sondern alle Hosts. Bis auf den unterschiedlichen Namen ist aber die Funktion die gleiche.

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:

Um die Benachrichtigungen zu testen, können Sie einen OK-Service einfach von Hand auf CRIT setzen. Dies geht mit dem Kommando Fake check results, das Sie in der Service-Liste im Menü Commands finden. Sollten Sie das Kommando in der Liste nicht sehen, klicken Sie bitte vorher noch auf den Knopf Show more .

Das muss dann sofort zu einer E-Mail für dieses Problem führen. Beim nächsten regulären Check sollte der Service dann wieder auf OK gehen und eine erneute Benachrichtigung auslösen (diesmal vom Typ Recovery).

Beachten Sie bei diesen Tests, dass der Service bei häufigen Wechseln nach einiger Zeit in den Zustand unstetig (flapping) gehen wird. Weitere Zustandswechsel lösen dann keine Benachrichtigungen mehr aus. Im Snapin Master control der Seitenleiste können Sie die Erkennung von Unstetigkeiten (Flap Detection) vorübergehend ausschalten.

Alternativ können Sie auch eine benutzerdefinierte Benachrichtigung (Custom notification) auslösen — ebenfalls per Kommando:

Dabei ändert sich der Status des entsprechenden Services nicht. Allerdings ist die so erzeugte Benachrichtigung dann von einem anderen Typ und kann sich — abhängig von Ihren Benachrichtigungsregeln — anders verhalten.

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 > Services > Service monitoring rules > Parameters for 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 Add HTML section above table (e.g. title, description…) aus Sicherheitsgründen nur eine kleine Menge an HTML-Tags zugelassen ist. Diese sind:

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.

Checkmk ist „ab Werk“ so eingerichtet, dass es bei einem Monitoring-Ereignis an jeden Kontakt des betroffenen Hosts oder Services eine Benachrichtigung per E-Mail versendet. Das ist sicher erst einmal sinnvoll, aber in der Praxis tauchen viele weitergehende Anforderungen auf, z. B.:

Checkmk bietet Ihnen über einen regelbasierten Mechanismus maximale Flexibilität bei der Umsetzung solcher Anforderungen. Mit Setup > Events > Notifications steigen Sie in die Konfiguration ein.

Hinweis: Wenn Sie die Seite Notification configuration das erste Mal aufrufen, wird Ihnen eine Warnung zur nicht konfigurierten „fallback email address" angezeigt. Die Warnung können Sie im Moment ignorieren. Wir gehen darauf weiter unten ein.

In der Benachrichtigungskonfiguration verwalten Sie die Kette der Benachrichtigungsregeln, welche festlegen, wer wie benachrichtigt werden soll. Bei jedem Monitoring-Ereignis wird diese Regelkette von oben nach unten durchlaufen. Jede Regel hat eine Bedingung, die entscheidet, ob die Regel überhaupt zur Anwendung kommt.

Ist die Bedingung erfüllt, legt die Regel zwei Dinge fest:

Wichtig: Anders als bei den Regeln für Hosts und Services geht die Auswertung hier auch nach einer zutreffenden Regel weiter! Die nachfolgenden Regeln können weitere Benachrichtigungen hinzufügen. Auch können Sie Benachrichtigungen wieder löschen, welche vorherige Regeln generiert haben.

Das Endergebnis der Regelauswertung ist eine Tabelle, die etwa folgenden Aufbau hat:

Nun wird pro Eintrag in dieser Tabelle das zur Methode gehörende Benachrichtigungsskript aufgerufen, welches die eigentliche Benutzerbenachrichtigung durchführt.

Wenn Sie Checkmk frisch aufgesetzt haben, dann finden Sie genau eine Regel vordefiniert:

Diese eine Regel setzt das oben beschriebene Standardverhalten um. Sie hat folgenden Aufbau:

Wie gewohnt, können Sie die Regel bearbeiten, kopieren, 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.

Hinweis: Änderungen an Benachrichtigungsregeln erfordern keine Aktivierung der Änderungen. Sie sind sofort wirksam.

Im Folgenden stellen wir den generellen Aufbau der Benachrichtigungsregeln mit den Festlegungen zu generellen Eigenschaften, Methoden, Kontakten und Bedingungen vor.

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 Benachrichtigungstabelle bildlich vor. Nehmen wir an, einige Regeln zu einem konkreten Monitoring-Ereignis wurden bereits abgearbeitet. Dadurch wurden die folgenden drei Benachrichtigungen erzeugt:

Nun kommt die nächste Regel mit der Methode SMS und der Auswahl Cancel previous notifications. 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:

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:

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.

Hinweis: 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 vorherigen Kapitel gezeigt haben, ist das explizite Löschen von Benachrichtigungen ja erwünscht und kein Konfigurationsfehler.

Die Einrichtung der Fallback-Adresse wird auf der Seite Notification configuration 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.

Eine nützliche Besonderheit des Benachrichtigungssystems von Checkmk ist, dass Benutzer sich auch ohne Administratorrechte ihre Benachrichtigungen anpassen können. Benutzer können:

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.

Benutzerdefinierte Regeln sind wie die normalen Regeln 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 Regel, die sie erzeugt, die Option allow users to deactivate this notification aktiviert ist:

In der Reihenfolge der Benachrichtigungsregeln kommen die benutzerdefinierten 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.

Wenn Sie ein Anpassen 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 im Menü Display > Show user rules wählen:

Nach den globalen Regeln werden die Benutzerregeln aufgelistet, die Sie mit auch bearbeiten können.

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.

Ein großer Teil der Komplexität im Benachrichtigungssystem von Checkmk liegt in den zahlreichen Tuning-Möglichkeiten, mit denen unwichtige Benachrichtigungen vermieden werden können. Die meisten davon betreffen Situationen, in denen bereits beim Auftreten der Monitoring-Ereignisse Benachrichtigungen verzögert oder unterdrückt werden. Auch gibt es eine im Monitoring-Kern eingebaute Intelligenz, die bestimmte Benachrichtigungen von Haus aus unterdrückt. Alle diese Aspekte wollen wir Ihnen in diesem Kapitel vorstellen.

Während sich ein Host oder Service in einer Wartungszeit befindet, sind für dieses Objekt die Benachrichtigungen unterdrückt. Das ist — neben einer korrekten Berechnung von Verfügbarkeiten — der wichtigste Grund, warum man überhaupt eine Wartungszeit im Monitoring hinterlegt. Interessant sind dabei folgende Details:

Per Konfiguration können Sie für jeden Host und Service eine Benachrichtigungsperiode festlegen. Dies ist eine Zeitperiode, welche die Zeiträume festlegt, auf die Benachrichtigungen beschränkt werden sollen.

Die Konfiguration geschieht über die Regelsätze Notification period for hosts bzw. Notification period for services, die Sie schnell über die Suche im Setup-Menü finden können. Ein Objekt, welches sich gerade nicht in seiner Benachrichtigungsperiode befindet, wird durch ein graues Pause-Zeichen markiert.

Monitoring-Ereignisse zu einem Objekt, das sich gerade außerhalb seiner Benachrichtigungsperiode befindet, lösen keine Benachrichtigungen aus. Benachrichtigungen werden nachgeholt, wenn die Benachrichtigungsperiode wieder aktiv wird und der Host/Service sich immer noch in einem Problemzustand befindet. Dabei löst nur der jeweils letzte Zustand eine Benachrichtigung aus, auch wenn es außerhalb der Periode mehrere Zustandswechsel gab.

Übrigens gibt es auch bei den Benachrichtigungsregeln die Möglichkeit, Benachrichtigungen auf eine bestimmte Zeitperiode zu beschränken. Damit können Sie die Zeiträume zusätzlich einschränken. Allerdings werden Benachrichtigungen, die durch eine Regel mit Zeitbedingung verworfen wurden, später nicht automatisch nachgeholt!

Wenn ein Host komplett ausfällt oder zumindest für das Monitoring nicht erreichbar ist, können natürlich auch die Services des Hosts nicht mehr überwacht werden. Aktive Checks werden dann in der Regel CRIT oder UNKNOWN, weil diese gezielt versuchen, den Host zu erreichen und dabei in einen Fehler laufen. Alle anderen Checks — also die überwiegende Mehrheit — werden in so einem Fall ausgelassen und verharren in ihrem alten Zustand. Sie werden mit der Zeit stale.

Natürlich wäre es sehr lästig, wenn alle Probleme von aktiven Checks in so einem Zustand Benachrichtigungen auslösen würden. Denn wenn z. B. ein Webserver nicht erreichbar ist — und dies auch schon als Benachrichtigung kommuniziert wurde — wäre es wenig informativ, wenn nun auch für jeden einzelnen HTTP-Dienst, den dieser bereit stellt, eine E-Mail generiert würde.

Um dies zu vermeiden, erzeugt der Monitoring-Kern für Services grundsätzlich nur dann Benachrichtigungen, wenn der Host den Zustand UP hat. Das ist auch der Grund, warum die Erreichbarkeit von Hosts separat überprüft wird. Wenn Sie nichts anderes konfiguriert haben, geschieht dies durch einen Smart Ping bzw. Ping.

Wenn Sie die Raw Edition verwenden (oder eine der kommerziellen Editionen mit Nagios als Kern), dann kann es in seltenen Fällen bei einem Host-Problem trotzdem zu einer Benachrichtigung aufgrund eines aktiven Services kommen. Der Grund liegt darin, dass Nagios die Resultate von Host-Checks für eine kurze Zeit in der Zukunft als gültig betrachtet. Wenn zwischen dem letzten erfolgreichen Ping an den Server und dem nächsten aktiven Check nur wenige Sekunden vergehen, kann es sein, dass Nagios den Host noch als UP wertet, obwohl dieser bereits DOWN ist. Der Checkmk Micro Core (CMC) hingegen hält die Service-Benachrichtigung solange in Wartestellung, bis der Zustand des Hosts geklärt ist und vermeidet die unerwünschte Benachrichtigung so zuverlässig.

Stellen Sie sich vor, ein wichtiger Netzwerk-Router zu einem Unternehmensstandort mit Hunderten von Hosts fällt aus. Alle Hosts sind dann für das Monitoring nicht mehr erreichbar und gehen auf DOWN. Hunderte Benachrichtigungen werden ausgelöst. Nicht sehr schön.

Um das zu vermeiden, können Sie den Router als Parent-Host der Hosts definieren. Wenn es redundante Routen gibt, kann man auch mehrere Parents definieren. Sobald alle Parents auf DOWN gehen, werden die nicht mehr erreichbaren Hosts auf den Zustand UNREACH gesetzt und die darauf basierenden Benachrichtigungen werden unterdrückt. Das Problem mit dem Router selbst löst hingegen durchaus eine Benachrichtigung aus.

Der CMC verhält sich intern übrigens geringfügig anders als Nagios. Um Fehlalarme zu vermeiden, richtige Benachrichtigungen aber korrekt abzusetzen, achtet er sehr genau auf die exakten Zeitpunkte der jeweiligen Host-Checks. Scheitert ein Host-Check, so wartet der Kern zunächst das Ergebnis des Host-Checks der Parent-Hosts ab, bevor eine Benachrichtigung erzeugt wird. Dieses Warten geschieht asynchron und ohne das übrige Monitoring zu beeinträchtigen. Benachrichtigungen von Hosts können sich dadurch geringfügig verzögern.

Über die Regelsätze Enable/disable notifications for hosts bzw. Enable/disable notifications for services können Sie Hosts und Services bestimmen, aufgrund derer grundsätzlich keine Benachrichtigungen erzeugt werden sollen. Wie oben erwähnt, unterbindet dann bereits der Kern die Benachrichtigungen. Eine Benachrichtigungsregel für ein „Abonnieren“ solcher Benachrichtigungen wäre wirkungslos, da diese ja gar nicht erzeugt werden.

Es ist grundsätzlich möglich, die Benachrichtigungen bezogen auf einzelne Hosts und Services auch per Kommando vorübergehend abzuschalten.

Voraussetzung dafür ist allerdings, dass die Berechtigung Commands on host and services > Enable/disable notifications der Benutzerrolle zugewiesen ist. Standardmäßig ist dies für keine Rolle der Fall.

Mit zugewiesener Berechtigung können Sie Benachrichtigungen auf Basis von Hosts und Services mit dem Kommando Commands > Notifications abschalten (und später auch wieder einschalten):

Solche Hosts oder Services werden dann mit dem Symbol markiert.

Da Kommandos im Gegensatz zu Regeln weder eine Konfigurationsberechtigung noch ein Aktivieren der Änderungen benötigen, können sie daher eine Lösung sein, um auf eine Situation schnell zu reagieren.

Wichtig: Im Gegensatz zu Wartungszeiten haben abgeschaltete Benachrichtigungen keinen Einfluss auf die Berechnung der Verfügbarkeit. Wenn Sie also während eines ungeplanten Ausfalls einfach nur die Benachrichtigungen abschalten, aber Ihre Verfügbarkeitsberechnung nicht verfälschen möchten, sollten Sie keine Wartungszeiten dafür eintragen!

Im Snapin Master control der Seitenleiste finden Sie einen Hauptschalter für die Benachrichtigungen (Notifications):

Dieser Schalter ist ausgesprochen nützlich, wenn Sie am System größere Änderungen vornehmen, durch die bei einem Fehler unter Umständen eine Vielzahl von Services auf CRIT geht. Sie ersparen sich so den Unmut Ihrer Kollegen über die vielen nutzlosen E-Mails. Vergessen Sie aber nicht, die Benachrichtigungen später wieder einzuschalten.

Im verteilten Monitoring gibt es diesen Schalter einmal pro Instanz. Ein Abschalten der Benachrichtigungen auf der Zentralinstanz lässt Benachrichtigungen auf den Remote-Instanzen weiterhin aktiviert — selbst wenn diese zur Zentralinstanz weitergeleitet und von dort zugestellt werden.

Wichtig: Benachrichtigungen, die angefallen wären, während die Benachrichtigungen abgeschaltet waren, werden beim Wiedereinschalten nicht nachgeholt.

Vielleicht haben Sie Services, die gelegentlich für kurze Zeit in einen Problemzustand gehen, der aber nur sehr kurz anhält und für Sie nicht kritisch ist. In solchen Fällen sind Benachrichtigungen sehr lästig, aber auch einfach zu unterdrücken. Dazu dienen die Regelsätze Delay host notifications und Delay service notifications.

Sie legen hier einen Zeitraum fest. Eine Benachrichtigung wird dann solange zurückgehalten, bis diese Zeit abgelaufen ist. Tritt vorher der OK / UP-Zustand wieder ein, so wird keine Benachrichtigung erzeugt. Natürlich bedeutet das aber dann auch, dass Sie im Falle eines wirklichen Problems erst mit einer Verzögerung benachrichtigt werden.

Viel besser als eine Verzögerung der Benachrichtigungen ist es natürlich, den eigentlichen Grund der sporadischen Probleme loszuwerden. Aber das ist eine andere Geschichte …​

Eine zur Verzögerung der Benachrichtigungen sehr ähnliche Methode ist es, mehrere Check-Versuche zu erlauben, wenn ein Service in einen Problemzustand geht. Dies geschieht über die Regelsätze Maximum number of check attempts for host bzw. Maximum number of check attempts for service.

Wenn Sie hier z. B. eine 3 einstellen, dann führt ein Check mit dem Resultat CRIT zunächst zu keiner Benachrichtigung. Man spricht dann zunächst von einem weichen CRIT-Zustand (soft state). Der harte Zustand (hard state) ist dann immer noch OK. Erst wenn drei Versuche in Folge zu keinem OK-Zustand führen, wechselt der Service den harten Zustand und eine Benachrichtigung wird ausgelöst.

Im Gegensatz zur verzögerten Benachrichtigung haben Sie hier noch die Möglichkeit, sich Tabellenansichten zu definieren, welche solche Probleme ausblenden. Auch BI-Aggregate können so gebaut werden, dass nur die harten Zustände berücksichtigt werden, nicht die weichen.

Wenn ein Host oder Service binnen kurzer Zeit mehrfach den Zustand ändert, so gilt er als unstetig (flapping). Dies ist sozusagen ein eigener Zustand. Die Idee dabei ist das Vermeiden von exzessiven Benachrichtigungen in Phasen, in denen ein Service nicht (ganz) stabil läuft. Auch in der Verfügbarkeitsberechnung können Sie solche Phasen speziell auswerten.

Unstetige Objekte werden mit dem Symbol markiert. Während ein Objekt unstetig ist, erzeugen weitere Zustandswechsel keine Benachrichtigungen mehr. Dafür wird aber jeweils eine Benachrichtigung ausgelöst, wenn das Objekt in den Zustand unstetig ein- oder austritt.

Sie können die Erkennung von Unstetigkeiten auf folgende Arten beeinflussen:

Blenden Sie die kontextsensitive Hilfe ein mit Help > Show inline help für Details zu den einstellbaren Werten.

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.

Zum Einstieg zeigen wir Ihnen, wie Sie sich in Checkmk die Historie der Benachrichtigungen auf Host- und Service-Ebene anzeigen lassen und so den Benachrichtigungsprozess nachverfolgen können.

Ein Monitoring-Ereignis, das Checkmk veranlasst, eine Benachrichtigung auszulösen, ist z. B. der Zustandswechsel eines Services. Diesen Zustandswechsel können Sie mit dem Kommando Fake check results zu Testzwecken manuell veranlassen, wie wir bereits im Kapitel zum Test einer einfachen Benachrichtigung per E-Mail gezeigt haben.

Für einen Benachrichtigungstest können Sie einen Service auf diese Weise vom Zustand OK nach CRIT versetzen. Wenn Sie sich jetzt auf der Seite der Service-Details die Benachrichtigungen für diesen Service mit Service > Service Notifications anzeigen lassen, sehen Sie die folgenden Einträge:

Der aktuellste Eintrag steht ganz oben in der Liste. Los ging es aber mit dem untersten, daher sehen wir uns die einzelnen Einträge von unten nach oben an:

Um die Zusammenhänge von allen Einstellmöglichkeiten und Rahmenbedingungen genau zu verstehen und um eine sinnvolle Fehlerdiagnose zu ermöglichen, wenn mal eine Benachrichtigung nicht wie erwartet erfolgt oder ausbleibt, beschreiben wir im folgenden alle Einzelheiten zum Ablauf einer Benachrichtigung mit allen beteiligten Komponenten.

Hinweis: Die Benachrichtigungshistorie, die wir oben für einen Service gezeigt haben, können Sie sich auch für einen Host anzeigen lassen: auf der Seite der Host-Details im Menü Host für den Host selbst (Menüeintrag Notifications of host) und auch für den Host mit all seinen Services (Notifications of host & services).

Im Benachrichtigungssystem von Checkmk sind folgende Komponenten beteiligt:

Nachdem der Kern eine Rohbenachrichtigung erzeugt hat, durchläuft diese die Kette der Benachrichtigungsregeln. Resultat ist die Benachrichtigungstabelle. Neben den Daten aus der Rohbenachrichtigung enthält jede Benutzerbenachrichtigung folgende zusätzliche Informationen:

Bei einer synchronen Zustellung wird jetzt pro Eintrag in der Tabelle das passende Benachrichtigungsskript aufgerufen. Bei einer asynchronen Zustellung wird die Benachrichtigung per Datei an den Benachrichtigungs-Spooler übergeben.

Eine mächtige Zusatzfunktion der kommerziellen Editionen ist der Benachrichtigungs-Spooler. Dieser ermöglicht eine asynchrone Zustellung von Benachrichtigungen. Was bedeutet asynchron in diesem Zusammenhang?

Eine synchrone Zustellung ist dann vertretbar, wenn das Benachrichtigungsskript schnell läuft und vor allem nicht in irgendeinen Timeout geraten kann. Bei Benachrichtigungsmethoden, die auf vorhandene Spooler zurückgreifen, ist das gegeben. Insbesondere bei E-Mail und SMS kommen Spool-Dienste vom System zum Einsatz. Das Benachrichtigungsskript übergibt eine Datei an den System-Spooler, wobei keine Wartezustände auftreten können.

Bei Verwendung der nachvollziehbaren Zustellung per SMTP oder anderer Skripte, welche Netzwerkverbindungen aufbauen, sollten Sie auf jeden Fall die asynchrone Zustellung einstellen. Dazu gehören auch Skripte, welche per HTTP Textnachrichten (SMS) über das Internet versenden. Die Timeouts bei der Verbindung zu einem Netzwerkdienst können bis zu mehrere Minuten lang sein und den oben beschriebenen Stau auslösen.

Die gute Nachricht: Die asynchrone Zustellung ist in Checkmk standardmäßig aktiviert. Zum einen wird der Benachrichtigungs-Spooler (mknotifyd) beim Start der Instanz mitgestartet, was Sie mit dem folgenden Kommando überprüfen können:

Zum anderen ist in den globalen Einstellungen (Global settings > Notifications > Notification Spooling) die asynchrone Zustellung (Asynchronous local delivery by notification spooler) ausgewählt:

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 Sammelbenachrichtigung 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 Sammelbenachrichtigung. Wird in einer Regel die Sammelbenachrichtigung 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 Sammelbenachrichtigung:

Was ist eigentlich, wenn eine Benachrichtigung innerhalb der Benachrichtigungsperiode liegt, die Sammelbenachrichtigung, die ihn enthält — die ja etwas später kommt — dann aber schon außerhalb 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 Sammelbenachrichtigung wird immer unabhängig von sämtlichen Zeitperioden zugestellt.

Das Monitoring ist nur nützlich, wenn man sich auch darauf verlassen kann. Dazu gehört, dass Benachrichtigungen zuverlässig und zeitnah ankommen. Nun ist die Zustellung von E-Mails hier leider nicht ganz ideal. Denn der Versand geschieht üblicherweise durch Übergabe der E-Mail an den lokalen SMTP-Server. Dieser versucht dann die E-Mail selbständig und asynchron zuzustellen.

Bei einem vorübergehenden Fehler (z.B. falls der empfangende SMTP-Server nicht erreichbar ist) wird die E-Mail in eine Warteschlange versetzt und später ein erneuter Zustellversuch gestartet. Dieses „später“ ist dann in der Regel frühestens in 15-30 Minuten. Aber dann kann die Benachrichtigung eventuell schon viel zu spät sein!

Ist die E-Mail gar nicht zustellbar, so erzeugt der SMTP-Server eine hübsche Fehlermeldung in seiner Log-Datei und versucht, an den „Absender“ eine E-Mail über die gescheiterte Zustellung zu generieren. Aber das Monitoring-System ist kein richtiger Absender und kann auch keine E-Mails empfangen. In der Folge gehen solche Fehler dann einfach unter und Benachrichtigungen bleiben aus.

Wichtig: Für Sammelbenachrichtigungen steht die nachvollziehbare Benachrichtigung nicht zur Verfügung!

Die kommerziellen Editionen bieten die Möglichkeit einer nachvollziehbaren Zustellung per SMTP. Dabei wird bewusst auf eine Hilfe des lokalen Mailservers verzichtet. Anstelle dessen sendet Checkmk selbst die E-Mail direkt via SMTP zu Ihrem Smarthost und wertet die SMTP-Antwort auch selbst aus.

Dabei werden nicht nur SMTP-Fehler intelligent behandelt, es wird auch eine korrekte Zustellung genau protokolliert. Es ist ein bisschen wie ein Einschreiben: Checkmk bekommt quasi vom SMTP-Smarthost (empfangender Server) eine Quittung, dass die E-Mail übernommen wurde — inklusive einer Mail-ID.

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 das 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 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 notify.log nachverfolgen. Die folgenden Zeilen gehören zum letzten Schritt und enthalten die Antwort des SMTP-Servers:

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 gescheiterten 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 Overview an:

Hier können Sie:

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.

Eine synchrone Zustellung inklusive Fehlermeldung und Nachvollziehbarkeit ist aktuell nur für HTML-E-Mails implementiert. Wie Sie in einem eigenen Benachrichtigungsskript einen Fehlerstatus zurückgeben können, erfahren Sie im Kapitel über das Schreiben von eigenen Skripten.

Benachrichtigungen können auf sehr vielfältige und individuelle Weise geschehen. Typische Fälle sind:

Aus diesem Grund bietet Checkmk eine sehr einfache Schnittstelle, mit der Sie selbst eigene Benachrichtigungsskripte schreiben können. Sie können diese in jeder von Linux unterstützten Programmiersprache schreiben — auch wenn Shell, Perl und Python zusammen hier sicher 95 % „Marktanteil“ haben.

Die von Checkmk mitgelieferten Skripte liegen unter ~/share/check_mk/notifications. Dieses Verzeichnis ist Teil der Software und nicht für Änderungen vorgesehen. Legen Sie eigene Skripte stattdessen in ~/local/share/check_mk/notifications ab. Achten Sie darauf, dass sie ausführbar sind (chmod +x). Sie werden dann automatisch gefunden und bei den Benachrichtigungsregeln als Methode zur Auswahl angeboten.

Möchten Sie ein mitgeliefertes Skript anpassen, so kopieren Sie es einfach von ~/share/check_mk/notifications nach ~/local/share/check_mk/notifications und machen dort Ihre Änderungen. Wenn Sie dabei den Dateinamen beibehalten, ersetzt Ihr Skript automatisch die Originalversion und Sie müssen keine bestehenden Benachrichtigungsregeln anpassen.

Einige weitere Beispielskripte werden unter ~/share/doc/check_mk/treasures/notifications mitgeliefert. Sie können diese als Vorlage nehmen und anpassen. Die Konfiguration wird meist direkt im Skript vorgenommen — Hinweise dazu finden Sie dort in den Kommentaren.

Im Falle einer Benachrichtigung wird Ihr Skript mit den Rechten des Instanzbenutzers aufgerufen. In Umgebungsvariablen, die mit NOTIFY_ beginnen, bekommt es alle Informationen über den betreffenden Host/Service, das Monitoring-Ereignis, den zu benachrichtigenden Kontakt und die Parameter, die in der Benachrichtigungsregel angegeben wurden.

Texte, die das Skript in die Standardausgabe schreibt (mit print, echo, etc.), erscheinen in der Log-Datei des Benachrichtigungsmoduls ~/var/log/notify.log.

Benachrichtigungsskripte haben die Möglichkeit, über den Exit Code mitzuteilen, ob ein wiederholbarer Fehler aufgetreten ist oder ein endgültiger:

Zudem wird in allen Fällen die Standardausgabe des Benachrichtigungsskripts zusammen mit dem Status in die Benachrichtigungshistorie des Hosts/Services eingetragen und ist somit über die GUI sichtbar.

Wichtig: Für Sammelbenachrichtigungen steht die nachvollziehbare Benachrichtigung nicht zur Verfügung!

Die Behandlung von Benachrichtigungsfehlern aus Sicht des Benutzers wird im Kapitel über die nachvollziehbare Zustellung per SMTP erklärt.

Als Beispiel können Sie ein Skript erstellen, das alle Informationen zu der Benachrichtigung in eine Datei schreibt. Als Sprache kommt die Bash Linux-Shell zum Einsatz:

Danach machen Sie das Skript ausführbar:

Hier einige Erklärungen zum Skript:

Damit das Skript verwendet wird, müssen Sie es in einer Benachrichtigungsregel als Methode einstellen. Selbst geschriebene Skripte haben keine Parameterdeklaration. Daher fehlen die ganzen Checkboxen, wie sie z.B. bei der Methode HTML Email angeboten werden. Anstelle dessen können Sie eine Liste von Texten als Parameter angeben, die dem Skript als NOTIFY_PARAMETER_1, NOTIFY_PARAMETER_2 usw. bereitgestellt werden. Für den Test übergeben Sie die Parameter Fröhn, Klabuster und Feinbein:

Nun setzen Sie zum Test den Service CPU load auf dem Host myserver auf CRIT — mit dem Kommando Fake check results, wie es bereits weiter oben beschrieben wurde. In der Log-Datei des Benachrichtigungsmoduls ~/var/log/notify.log sehen Sie die Ausführung des Skripts samt Parametern und der erzeugten Spool-Datei:

Die Datei ~/tmp/foobar.out enthält nun eine alphabetische Liste aller Checkmk-Umgebungsvariablen, die Informationen über die Benachrichtigung beinhalten. Dort können Sie sich orientieren, was für Werte für Ihr Skript zur Verfügung stehen. Hier die ersten zehn Zeilen:

Auch die Parameter lassen sich hier wiederfinden:

Im obigen Beispiel haben Sie einige Umgebungsvariablen gesehen, die dem Skript übergeben wurden. Welche Variablen genau bereitstehen, hängt von der Art der Benachrichtigung und auch von der verwendeten Checkmk-Version und -Edition ab. Neben dem Trick mit dem Kommando env gibt es noch zwei weitere Wege zu einer vollständigen Liste aller Variablen:

Folgendes sind die wichtigsten Variablen:

Wenn Ihr Skript Sammelbenachrichtigungen unterstützen soll, müssen Sie es speziell dafür präparieren, da hier dem Skript mehrere Benachrichtigungen auf einmal übergeben werden. Aus diesem Grund funktioniert dann auch die Übergabe per Umgebungsvariablen nicht mehr sinnvoll.

Deklarieren Sie Ihr Skript in der dritten Zeile im Kopf wie folgt, dann sendet das Benachrichtigungsmodul die Benachrichtigungen auf der Standardeingabe:

Auf der Standardeingabe werden dem Skript Blöcke von Variablen gesendet. Jede Zeile hat die Form NAME=VALUE. Blöcke werden getrennt durch Leerzeilen. Das ASCII-Zeichen mit dem Code 1 (\a) wird verwendet, um innerhalb der Texte Zeilenumbrüche (newlines) darzustellen.

Der erste Block enthält eine Liste von allgemeinen Variablen (z.B. Aufrufparameter). Jeder weitere Block fasst die Variablen zu einer Benachrichtigung zusammen.

Am besten, Sie probieren das Ganze erst einmal mit einem einfachen Test aus, der die kompletten Daten in eine Datei schreibt und sehen sich an, wie die Daten gesendet werden. Dazu können Sie z.B. das folgende Benachrichtigungsskript nutzen:

Testen Sie das Skript wie oben beschrieben und aktivieren Sie zusätzlich in der Benachrichtigungsregel die Sammelbenachrichtigung (Notification Bulking).

Im Auslieferungszustand stellt Checkmk bereits eine ganze Reihe Skripte bereit zur Anbindung an beliebte und weit verbreitete Instant-Messaging-Dienste, Incident-Management-Plattformen und Ticketsysteme. Wie Sie diese Skripte nutzen können, erfahren Sie in den folgenden Artikeln:

Die Log-Dateien des SMTP-Servers sind Systemdateien und werden hier folglich mit absoluten Pfaden angegeben. Wo die Log-Datei genau liegt, hängt von Ihrer Linux-Distribution ab.