Checkmk
to checkmk.com

1. Einleitung

icon notifications

Benachrichtigung bedeutet, dass Benutzer im Falle von Problemen oder anderen Ereignissen im Monitoring von Checkmk aktiv informiert werden. Im häufigsten Fall geschieht das durch E-Mails. Es gibt aber auch viele andere Methoden, wie z.B. das Versenden von SMS oder die Weiterleitung an ein Ticketsystem. Checkmk bietet eine einfache Schnittstelle, um für eigene Benachrichtigungsmethoden Skripte zu schreiben.

Ausgangspunkt für jede Benachrichtigung an einen Benutzer ist ein vom Monitoring-Kern gemeldetes Ereignis. Wir nennen dies im folgenden Monitoring-Ereignis, um Verwechslungen mit den Ereignissen zu vermeiden, die von der Event Console verarbeitet werden. Ein Monitoring-Ereignis bezieht sich immer auf einen bestimmten Host oder Service. Mögliche Typen von Monitoring-Ereignissen sind:

  • Ein Zustandswechsel, z.B. OKWARN

  • Der Wechsel zwischen einem stetigen und einem icon flapping unstetigen (flapping) Zustand

  • Start oder Ende einer icon downtime Wartungszeit

  • Die icon ack Quittierung eines Problems durch einen Benutzer

  • Eine durch ein icon commands Kommando manuell ausgelöste Benachrichtigung

  • Die Ausführung eines icon alert handlers Alert Handlers

  • Ein Ereignis, das von der icon event console Event Console zur Benachrichtigung übergeben wurde

Checkmk verfügt über ein regelbasiertes System, mit dem Sie aus diesen Monitoring-Ereignisse Benutzerbenachrichtigungen erstellen lassen können, und mit dem Sie auch sehr anspruchsvolle Anforderungen umsetzen können. Eine einfache Benachrichtigung per E-Mail — wie sie in vielen Fällen zunächst völlig ausreicht — ist trotzdem schnell eingerichtet.

2. Benachrichtigen oder (noch) nicht benachrichtigen?

Grundsätzlich sind Benachrichtigungen optional, und Sie können Checkmk durchaus auch ohne diese sinnvoll nutzen. Manche großen Unternehmen haben eine Art Leitstand, in der das Monitoring-Team die Checkmk-Oberfläche ständig im Blick hat und keine zusätzlichen Benachrichtigungen benötigt.

Wenn Sie noch im Aufbau Ihrer Checkmk-Umgebung sind, sollten Sie außerdem bedenken, dass Benachrichtigungen erst dann für Ihre Kollegen eine Hilfe sind, wenn keine oder nur selten Fehlalarme (false positives) produziert werden. Dazu müssen Sie erst einmal die Schwellwerte und alle anderen Einstellungen soweit im Griff haben, dass im Normalfall alle Zustände OK / UP sind oder mit anderen Worten: alles „grün“ ist.

Die Akzeptanz für das neue Monitoring ist schnell dahin, wenn es den Posteingang jeden Tag mit Hunderten nutzloser E-Mails flutet.

Folgendes Vorgehen hat sich bewährt:

Schritt 1: Feinjustieren Sie das Monitoring, indem Sie einerseits die durch Checkmk neu aufgedeckten, tatsächlichen Probleme beheben und andererseits Fehlalarme eliminieren. Tun Sie das, bis im Normalfall alles OK / UP ist. Im Leitfaden für Einsteiger finden Sie einige Empfehlungen, um typische Fehlalarme zu reduzieren.

Schritt 2: Schalten Sie Benachrichtigungen zunächst nur für sich selbst ein. Reduzieren Sie das „Rauschen“, welches durch sporadisch kurz auftretende Probleme verursacht wird. Passen Sie dazu weitere Schwellwerte an, nutzen Sie ggf. das prognosebasierte Monitoring, erhöhen Sie die Anzahl der Checkversuche oder versuchen Sie es mit der verzögerten Benachrichtigung. Wenn es sich allerdings um tatsächliche Probleme handelt, sollten Sie deren Ursache finden, um sie in den Griff zu bekommen.

Schritt 3: Erst wenn in Ihrem eigenen Posteingang einigermaßen Ruhe eingekehrt ist, schalten Sie die Benachrichtigungen für Ihre Kollegen ein. Richten Sie dazu sinnvolle Kontaktgruppen ein, so dass jeder nur solche Benachrichtigungen bekommt, die ihn auch wirklich etwas angehen.

Das Ergebnis ist ein sehr nützliches System, das Ihnen und Ihren Kollegen hilft, mit relevanten Informationen Ausfallzeiten zu reduzieren.

3. Einfache Benachrichtigung per E-Mail

Eine von Checkmk versendete Benachrichtigung per E-Mail im HTML-Format sieht etwa so aus:

html notification

Wie im Beispiel zu sehen ist, enthält die E-Mail auch die aktuellen Messwerte 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, Sendmail 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 "Inhalt" | mail -s Test-Betreff harry.hirsch@example.com

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

3.3. E-Mail-Adresse und Kontaktgruppe

E-Mail-Adresse und Kontaktgruppe eines Benutzers legen Sie in der Benutzerverwaltung fest:

notifications add user

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.

3.4. Test

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:

notifications fake check results

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 icon flapping 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:

notifications custom

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

4. Benachrichtigungen per Regeln steuern

4.1. Das Prinzip

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.:

  • Unterdrücken bestimmter, wenig nützlicher Benachrichtigungen.

  • „Abonnieren“ von Benachrichtigungen zu Services, für die man kein Kontakt ist.

  • Benachrichtigen per E-Mail, SMS oder Pager, abhängig von der Tageszeit.

  • Eskalieren von Problemen nach einer bestimmten Zeit ohne Quittierung.

  • Eventuell keine Benachrichtigungen für WARN oder UNKNOWN erhalten.

  • und vieles mehr …​

Checkmk bietet Ihnen über einen regelbasierten Mechanismus maximale Flexibilität bei der Umsetzung solcher Anforderungen.

Mit Setup > Events > icon notifications 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:

  • Eine Auswahl von Kontakten (Wer soll benachrichtigt werden?)

  • Eine Benachrichtigungsmethode (Wie soll benachrichtigt werden?), z.B. HTML-E-Mail, und dazu optional Parameter für die Methode

Wichtig: Anders als bei den Regeln für Host- 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:

Wer (Kontakt)Wie (Methode)Parameter der Methode

Harry Hirsch

E-Mail

Reply-To: linux.group@example.com

Bruno Weizenkeim

E-Mail

Reply-To: linux.group@example.com

Bruno Weizenkeim

SMS

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

4.2. Vordefinierte Regel

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

notifications default rule

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

Bedingung

Keine, d.h. die Regel gilt für alle Monitoring-Ereignisse.

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 icon edit bearbeiten, icon clone kopieren, icon delete 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 icon drag verändern.

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

4.3. Aufbau der Benachrichtigungsregeln

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

Generelle 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.

notifications rule part1

Die Option Overriding by users ist per Default aktiviert. Sie erlaubt Benutzern, Benachrichtigungen „abzubestellen“, die von dieser Regel erzeugt werden. Wie das geht, zeigen wir bei den benutzerdefinierten Benachrichtigungen.

Benachrichtigungsmethode

Die Benachrichtigungsmethode legt fest, auf welchem technischen Weg benachrichtigt werden soll, z.B. mit HTML-E-Mail.

notifications rule part2

Jede Methode ist durch ein Skript realisiert. Checkmk liefert bereits einige Skripte mit aus. Sie können aber 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 dieser Methode aus früheren Regeln wieder verworfen. Näheres dazu finden Sie beim Thema Löschen von Benachrichtigungen.

Hinweis: Für die folgenden Benachrichtigungsmethoden zur Weiterleitung an andere Systeme erhalten Sie genauere Informationen in separaten Artikeln: Jira, Mattermost, PagerDuty, Pushover, Opsgenie, ServiceNow, Slack, VictorOps und Cisco Webex Teams

Kontaktauswahl

notifications rule part3

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 mehrere Optionen ankreuzen 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 mit Restrict by …​ 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 Datacenter 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 als Methode Cancel previous notifications gewählt haben, werden nur Benachrichtigungen an die hier gewählten Kontakte entfernt.

Bedingungen

Bedingungen legen fest, wann eine Regel Anwendung findet. Solange keine Bedingung definiert ist, greift die Regel bei jedem Monitoring-Ereignis.

notifications rule part4

Blenden Sie die kontextsensitiven Hilfe ein mit Help > Show inline help, um Einzelheiten über die Auswirkung der verschiedenen Bedingungen zu erfahren

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 /tmp enthält), mit dem aktuellen Zustand (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).

Wenn ein Monitoring-Ereignis auch nur eine der konfigurierten Bedingungen nicht erfüllt, kommt die Regel nicht zur Anwendung. Eine Besonderheit dabei sind die Bedingungen Match host event type und Match service event type:

notifications rule part4 match event types

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, falls der Ereignistyp in einer der beiden Checkboxlisten 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:

notifications rule part4 contacts

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-Benachrichtigungen in der Kontaktgruppe Linux sollen nie per SMS versendet werden“. Das hat nichts mit der oben beschriebenen Kontaktauswahl zu tun.

4.4. 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 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

E-Mail

Bruno Weizenkeim

E-Mail

Bruno Weizenkeim

SMS

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:

Wer (Kontakt)Wie (Methode)

Harry Hirsch

E-Mail

Bruno Weizenkeim

E-Mail

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.5. 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 die werden Benachrichtigungen verschickt, auf die keine einzige Benachrichtigungsregel greift.

Die Fallback-Adresse wird nur dann verwendet, wenn keine Regel greift, nicht wenn kein 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“:

notifications warning fallback email

Falls Sie die Fallback-Adresse nicht nutzen wollen, so erzeugen Sie 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 die Warnung verschwinden.

5. Benutzerdefinierte Benachrichtigungen

5.1. Übersicht

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.

5.2. Benutzerdefinierte Benachrichtigungsregeln

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:

notifications rule part1

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:

notifications show user roles

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

5.3. Vorübergehende Abschaltung

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:

notifications edit profile disable

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

6. Wann Benachrichtigungen erzeugt werden und wie man damit umgeht

6.1. Einleitung

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.

6.2. Wartungszeiten

icon downtime

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:

  • Ist ein Host in Wartung, dann gelten automatisch auch alle seine Services als in Wartung, ohne dass man explizit eine Wartung für diese eintragen muss.

  • Endet die Wartungszeit eines Objekts, das während der Wartungszeit in einen Problemzustand gewechselt hat, dann wird dieses Problem exakt beim Ablauf der Wartung nachträglich benachrichtigt.

  • Der Beginn und das Ende einer Wartungszeit selbst ist auch ein Monitoring-Ereignis, das benachrichtigt wird.

6.3. Benachrichtigungsperioden

icon outofnot

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 icon outofnot markiert.

Monitoring-Ereignisse zu einem Objekt, das sich gerade außerhalb seiner Benachrichtigungsperiode befindet, werden nicht benachrichtigt. Benachrichtigungen werden nachgeholt, wenn die Benachrichtigungsperiode wieder aktiv wird und der Host/Service sich immer noch in einem Problemzustand befindet. Dabei wird nur der jeweils letzte Zustand benachrichtigt, 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!

6.4. Der Zustand des Hosts, auf dem ein Service läuft

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 icon stale stale.

Natürlich wäre es sehr lästig, wenn alle Probleme von aktiven Checks in so einem Zustand benachrichtigt würden. Denn wenn z.B. ein Webserver nicht erreichbar ist — und dies auch schon benachrichtigt 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.

CRE Wenn Sie die Raw Edition verwenden (oder eine der Enterprise Editions mit Nagios als Kern), dann kann es in seltenen Fällen bei einem Host-Problem trotzdem zu einer Benachrichtigung 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.

6.5. Parent-Hosts

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 Benachrichtigungen für diese werden unterdrückt. Das Problem mit dem Router selbst wird hingegen durchaus benachrichtigt.

CEE 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.

6.6. Benachrichtigungen per Regel abschalten

Über die Regelsätze Enable/disable notifications for hosts bzw. Enable/disable notifications for services können Sie Hosts und Services bestimmen, für die grundsätzliche 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.

6.7. Benachrichtigungen per Kommando abschalten

icon notif man disabled

Es ist grundsätzlich möglich, bei einzelnen Hosts und Services die Benachrichtigungen 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 von Hosts und Services mit dem Kommando Commands > Notifications abschalten (und später auch wieder einschalten):

notifications commands disable

Solche Hosts oder Services werden dann mit dem Symbol icon notif man disabled 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 icon downtime 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!

6.8. Benachrichtigungen global ausschalten

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

Snapin Master control.

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.

6.9. Benachrichtigungen verzögern

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 …​

6.10. Mehrere Check-Versuche

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.

6.11. Unstetige Hosts und Services

icon flapping

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 icon flapping 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:

  • Die Master control hat einen Hauptschalter für die Erkennung von Unstetigkeiten: Flap Detection

  • Über die Regelsätze Enable/disable flapping detection for hosts bzw. Enable/disable flapping detection for services können Sie Objekte von der Erkennung ausklammern.

  • In den CEE Checkmk Enterprise Editions können Sie mit Global settings > Monitoring Core > Tuning of flap detection die Parameter der Unstetigkeitserkennung festlegen und sie mehr oder weniger empfindlich einstellen:

notifications tuning flap detection

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

6.12. Periodisch wiederholte Benachrichtigungen und Eskalationen

Bei Systemen mit einem hohen Service-Level kann es sinnvoll sein, es nicht bei einer einzelnen Benachrichtigung zu belassen, falls das Problem über einen längeren Zeitraum weiterhin besteht. Sie können Checkmk so einrichten, dass es in einem festen Intervall immer weitere Benachrichtigungen versendet, solange bis das Problem entweder icon ack 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:

notifications periodic

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

Um eine Eskalierung einzurichten, erzeugen Sie eine zusätzliche Benachrichtigungsregel, welche die Bedingung Restrict to notification number verwendet. Tragen Sie hier als Bereich für die Laufnummern 3 bis 99999 ein, so greift diese Regel ab der dritten Benachrichtigung. Die Eskalierung kann dann entweder durch die Wahl einer anderen Methode (z.B. SMS) erfolgen oder durch die Benachrichtigung von anderen Personen (Kontaktauswahl).

notifications escalation

Mit der Option Throttle periodic notifications können Sie die Rate der wiederholten Benachrichtigungen nach einer bestimmten Zeit reduzieren und so z.B. am ersten Tag alle zwei Stunden eine E-Mail senden lassen und später das Ganze auf einmal am Tag beschränken.

7. Der Weg einer Benachrichtigung von Anfang bis Ende

7.1. Die Benachrichtigungshistorie

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:

notifications list

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:

  1. Der Monitoring-Kern protokolliert das Monitoring-Ereignis des Zustandswechsels. Dabei zeigt das icon alert crit Symbol in der 1. Spalte den Zustand an (im Beispiel CRIT).

  2. Der Monitoring-Kern erzeugt eine icon alert cmk notify Rohbenachrichtigung (raw notification). Diese wird vom Kern an das Benachrichtigungsmodul übergeben, welches die Auswertung der Benachrichtigungsregeln durchführt

  3. Die Auswertung der Regeln ergibt eine icon alert notify Benutzerbenachrichtigung (user notification) an den Benutzer hh mit der Methode mail.

  4. Das icon alert notify result Benachrichtigungsergebnis (notification result) zeigt, dass die E-Mail erfolgreich an den SMTP-Server zur Auslieferung übergeben wurde.

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

7.2. Die Komponenten

Im Benachrichtigungssystem von Checkmk sind folgende Komponenten beteiligt:

KomponenteAufgabeLogdatei

Nagios

Monitoring-Kern der CRE Checkmk Raw Edition, der Monitoring-Ereignisse erkennt und Rohbenachrichtigungen erzeugt.

var/log/nagios.log
var/nagios/debug.log

Checkmk Micro Core (CMC)

Monitoring-Kern der Enterprise Editions, der die gleiche Aufgabe erfüllt wie Nagios in der CRE Checkmk Raw Edition.

var/log/cmc.log

Benachrichtigungsmodul

Auswertung der Benachrichtigungsregeln, um aus einer Rohbenachrichtigung eine Benutzerbenachrichtigung zu erzeugen. Das Modul ruft die Benachrichtigungsskripte auf.

var/log/notify.log

Benachrichtigungs-Spooler (nur Enterprise Editions)

Asynchrone Zustellung von Benachrichtigungen und zentralisierte Benachrichtigungen in verteilten Umgebungen.

var/log/mknotifyd.log

Benachrichtigungsskript

Für jede Benachrichtigungsmethode gibt es ein Skript, welches die eigentliche Zustellung durchführt (z.B. eine HTML-E-Mail generiert und versendet).

var/check_mk/notify.log

7.3. Der Monitoring-Kern

Rohbenachrichtigungen

Wie oben beschrieben, beginnt jede Benachrichtigung mit einem Monitoring-Ereignis im Monitoring-Kern. Wenn alle Bedingungen erfüllt sind und es grünes Licht für eine Benachrichtigung gibt, erzeugt der Kern eine Rohbenachrichtigung an den internen Hilfskontakt check-mk-notify. Die Rohbenachrichtigung enthält noch keine Angabe zu den eigentlichen Kontakten oder der Benachrichtigungsmethode.

In der Benachrichtigungshistorie des Services sieht eine Rohbenachrichtigung so aus:

notifications raw
  • Das Symbol ist ein icon alert cmk notify hellgrauer Lautsprecher.

  • Als Kontakt wird check-mk-notify angegeben.

  • Als Benachrichtigungskommando wird check-mk-notify angegeben.

Die Rohbenachrichtigung geht dann an das Benachrichtigungsmodul von Checkmk, welches die Auswertung der Benachrichtigungsregeln übernimmt. Dieses Modul wird von Nagios als externes Programm aufgerufen (cmk --notify). Der CMC hingegen hält das Modul als permanenten Hilfsprozess in Bereitschaft (notification helper) und vermeidet so das Erzeugen von Prozessen, um Rechenzeit zu sparen.

Fehlerdiagnose im Monitoring-Kern Nagios

CRE Der in der CRE Checkmk Raw Edition verwendete Nagios-Kern protokolliert alle Monitoring-Ereignisse nach var/log/nagios.log. Diese Datei ist gleichzeitig der Ort, wo die Benachrichtigungshistorie gespeichert wird, welche Sie auch in der GUI abfragen, wenn Sie z.B. die Benachrichtigungen eines Hosts oder Services sehen möchten.

Interessanter sind aber die Meldungen in der Datei var/nagios/debug.log, welche Sie bekommen, wenn Sie in etc/nagios/nagios.d/logging.cfg die Variable debug_level auf 32 setzen. Nach einem Core-Neustart …​

OMD[mysite]:~$ omd restart nagios

… finden Sie nützliche Informationen über Gründe, warum Benachrichtigungen erzeugt oder unterdrückt wurden:

var/nagios/debug.log
[1592405483.152931] [032.0] [pid=18122] ** Service Notification Attempt ** Host: 'localhost', Service: 'backup4', Type: 0, Options: 0, Current State: 2, Last Notification: Wed Jun 17 16:24:06 2020
[1592405483.152941] [032.0] [pid=18122] Notification viability test passed.
[1592405485.285985] [032.0] [pid=18122] 1 contacts were notified.  Next possible notification time: Wed Jun 17 16:51:23 2020
[1592405485.286013] [032.0] [pid=18122] 1 contacts were notified.

Fehlerdiagnose im Monitoring-Kern CMC

CEE In den CEE Checkmk Enterprise Editions finden Sie in der Logdatei var/log/cmc.log ein Protokoll des Monitoring-Kerns. In der Standardeinstellung enthält dies keine Angaben zu Benachrichtigungen. Sie können aber ein sehr detailliertes Logging einschalten, mit Global settings > Monitoring Core > Logging of the notification mechanics. Der Kern gibt dann darüber Auskunft, warum er ein Monitoring-Ereignis für die Benachrichtigung an das Benachrichtigungsmodul weitergibt oder warum (noch) nicht:

OMD[mysite]:~$ tail -f var/log/cmc.log
2021-08-26 16:12:37 [5] [core 27532] Executing external command: PROCESS_SERVICE_CHECK_RESULT;heute;CPU load;1;test
2021-08-26 16:12:43 [5] [core 27532] Executing external command: LOG;SERVICE NOTIFICATION: hh;heute;CPU load;WARNING;mail;test
2021-08-26 16:12:52 [5] [core 27532] Executing external command: LOG;SERVICE NOTIFICATION RESULT: hh;heute;CPU load;OK;mail;success 250 - b'2.0.0 Ok: queued as 482477F567B';success 250 - b'2.0.0 Ok: queued as 482477F567B'

Hinweis: Das eingeschaltete Logging zu Benachrichtigungen kann sehr viele Meldungen erzeugen. Es ist aber nützlich, wenn man später die Frage beantworten will, warum in einer bestimmten Situation keine Benachrichtigung erzeugt wurde.

7.4. Regelauswertung durch das Benachrichtigungsmodul

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 jeder Benutzerbenachrichtigung folgende zusätzliche Informationen:

  • Der Kontakt, der benachrichtigt werden soll

  • Die Methode für die Benachrichtigung

  • Die Parameter für diese Methode

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.

Analyse der Regelkette

Wenn Sie komplexere Regelwerke erstellen, stehen Sie sicher gelegentlich vor der Frage, welche Regeln denn nun für eine bestimmte Benachrichtigung greifen. Dazu bietet Checkmk auf der Seite Notifications configuration eine eingebaute Analysefunktion, welche Sie mit dem Menüeintrag Display > Show analysis erreichen.

Im Analysemodus werden Ihnen standardmäßig die letzten zehn Rohbenachrichtigungen angezeigt, die das System erzeugt hat und welche die Regeln durchlaufen haben:

notifications analysis

Sollten Sie für Ihre Analyse eine größere Menge an Rohbenachrichtigungen benötigen, können Sie die Anzahl über Global settings > Notifications > Store notifications for rule analysis erhöhen:

notifications storenotifications

Für jeden dieser Rohbenachrichtigungen stehen Ihnen drei Aktionen zur Verfügung:

icon analyze

Test der Regelkette, in dem für jede Regel geprüft wird, ob das Monitoring-Ereignis alle Bedingungen der Regel erfüllen würde. Im Anschluss an die Regeln wird dann die daraus resultierende Benachrichtigungstabelle angezeigt.

icon toggle context

Anzeige des kompletten Benachrichtigungskontexts.

icon reload cmk

Wiederholung der Rohbenachrichtigung, als wäre das Monitoring-Ereignis jetzt aufgetreten. Ansonsten ist die Anzeige gleich wie bei der Analyse. Damit können Sie nicht nur die Bedingungen der Regel überprüfen, sondern auch testen, wie eine Benachrichtigung dann aussieht.

Fehlerdiagnose

Eine weitere wichtige Diagnosemöglichkeit ist die Logdatei var/log/notify.log. Während Tests mit den Benachrichtigungen bietet sich dazu der beliebte Befehl tail -f an:

OMD[mysite]:~$ tail -f var/log/notify.log
2021-08-26 17:11:58,914 [20] [cmk.base.notify] Analysing notification (heute;Temperature Zone 7) context with 71 variables
2021-08-26 17:11:58,915 [20] [cmk.base.notify] Global rule 'Notify all contacts of a host/service via HTML email'...
2021-08-26 17:11:58,915 [20] [cmk.base.notify]  -> matches!
2021-08-26 17:11:58,915 [20] [cmk.base.notify]    - adding notification of hh via mail
2021-08-26 17:11:58,916 [20] [cmk.base.notify] Executing 1 notifications:
2021-08-26 17:11:58,916 [20] [cmk.base.notify]   * would notify hh via mail, parameters: smtp, graphs_per_notification, notifications_with_graphs, bulk: no

Mit Global settings > Notifications > Notification log level können Sie die Ausführlichkeit der Meldungen in drei Stufen steuern. Wenn Sie Full dump of all variables and command auswählen, so finden Sie in der Logdatei eine komplette Auflistung aller Variablen, die dem Benachrichtigungsskript bereitgestellt werden:

notifications log level

Dies sieht dann z.B. so aus (Auszug):

var/log/notify.log
2021-08-26 17:24:54,709 [10] [cmk.base.notify] Raw context:
                    CONTACTS=hh
                    HOSTACKAUTHOR=
                    HOSTACKCOMMENT=
                    HOSTADDRESS=127.0.0.1
                    HOSTALIAS=localhost
                    HOSTATTEMPT=1
                    HOSTCHECKCOMMAND=check-mk-host-smart

7.5. Asynchrone Zustellung durch Benachrichtigungs-Spooler

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

  • Synchrone Zustellung: Das Benachrichtigungsmodul wartet, bis das Benachrichtigungsskript fertig ausgeführt wurde. Sollte dies eine längere Ausführungszeit haben, stauen sich weitere Benachrichtigungen auf. Wird das Monitoring angehalten, gehen diese Benachrichtigungen verloren. Außerdem kann sich bei vielen Benachrichtigungen in kurzer Zeit ein Rückstau bis zum Kern bilden, so dass das Monitoring dadurch ins Stocken gerät.

  • Asynchrone Zustellung: Jede Benachrichtigung wird in einer Spool-Datei unter var/check_mk/notify/spool abgelegt. Es kann sich kein Stau bilden. Bei einem Stopp des Monitorings bleiben die Spool-Dateien erhalten und Benachrichtigungen werden später korrekt zugestellt. Das Abarbeiten der Spool-Dateien übernimmt der Benachrichtigungs-Spooler.

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 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:

OMD[mysite]:~$ omd status mknotifyd
mknotifyd:      running
-----------------------
Overall state:  running

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

notifications spooling

Fehlerdiagnose

Der Benachrichtigungs-Spooler pflegt eine eigene Logdatei: var/log/mknotifyd.log. Diese verfügt über drei Log-Levels, die Sie unter Global settings > Notifications > Notification Spooler Configuration mit dem Parameter Verbosity of logging auswählen können. Der Default steht auf Normal logging (only startup, shutdown and errors. Bei der mittleren Stufe, Verbose logging (also spooled notifications), können Sie das Bearbeiten der Spool-Dateien sehen:

var/log/mknotifyd.log
2021-08-26 18:05:02,928 [15] [cmk.mknotifyd] processing spoolfile: /omd/sites/heute/var/check_mk/notify/spool/dad64e2e-b3ac-4493-9490-8be969a96d8d
2021-08-26 18:05:02,928 [20] [cmk.mknotifyd] running cmk --notify --log-to-stdout spoolfile /omd/sites/heute/var/check_mk/notify/spool/dad64e2e-b3ac-4493-9490-8be969a96d8d
2021-08-26 18:05:05,848 [20] [cmk.mknotifyd] got exit code 0
2021-08-26 18:05:05,850 [20] [cmk.mknotifyd] processing spoolfile dad64e2e-b3ac-4493-9490-8be969a96d8d successful: success 250 - b'2.0.0 Ok: queued as 1D4FF7F58F9'
2021-08-26 18:05:05,850 [20] [cmk.mknotifyd] sending command LOG;SERVICE NOTIFICATION RESULT: hh;heute;CPU load;OK;mail;success 250 - b'2.0.0 Ok: queued as 1D4FF7F58F9';success 250 - b'2.0.0 Ok: queued as 1D4FF7F58F9'

8. Sammelbenachrichtigung (Bulk notifications)

8.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 44ste E-Mail übersieht, die zu einem ganz anderen Problem gehört.

Die Funktionsweise dieser Sammelbenachrichtigung ist sehr einfach. Wenn eine Benachrichtigung auftritt, so wird dieser 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:

notifications bulk

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 Benachrichtigungen.

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:

  • Wenn das Sammeln in einer Regel eingeschaltet ist, kann es mit einer späteren Regel auch wieder ausgeschaltet werden — und umgekehrt.

  • Die Sammelbenachrichtigung geschieht immer pro Kontakt. Jeder hat quasi seinen privaten „Sammeltopf“.

  • Sie können die Größe des Topfs limitieren (Maximum bulk size). Bei Erreichen dieses Maximums wird die Sammelbenachrichtigung sofort verschickt.

8.2. Sammelbenachrichtigungen und Zeitperioden

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.

9. Nachvollziehbare Zustellung per SMTP

9.1. E-Mail ist nicht zuverlässig

CEE 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 Logdatei und versucht, an den „Absender“ eine E-Mail über die gescheiterte Zustellung zu generieren. Aber das Monitoringsystem ist kein richtiger Absender und kann auch keine E-Mails empfangen. In der Folge gehen solche Fehler dann einfach unter und Benachrichtigungen bleiben aus.

9.2. SMTP auf direktem Weg ermöglicht Fehlerauswertung

Die CEE Checkmk Enterprise Editions 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.

9.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:

notifications enable sync smtp

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:

notifications smtp success

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 icon alert notify result 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:

var/log/notify.log
2021-08-26 10:02:22,016 [20] [cmk.base.notify] Got spool file d3b417a5 (heute;CPU load) for local delivery via mail
2021-08-26 10:02:22,017 [20] [cmk.base.notify]      executing /omd/sites/heute/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:

notifications smtp failed

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:

notifications overview failed

Hier können Sie:

  • durch Klick auf den Text …​ failed notifications zu einer Liste der fehlgeschlagenen Benachrichtigungen kommen und

  • durch Klick auf icon delete diese Meldungen bestätigen und damit 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:

notifications plugin timing settings

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.

9.4. SMS und andere Benachrichtigungsmethoden

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.

10. Benachrichtigungen in verteilten Systemen

In verteilten Umgebungen — also solchen mit mehr als einer Checkmk-Instanz — stellt sich die Frage, was mit Benachrichtigungen geschehen soll, die auf Remote-Instanzen erzeugt werden. Hier gibt es grundsätzlich zwei Möglichkeiten:

  1. Lokale Zustellung

  2. Zentrale Zustellung auf der Zentralinstanz (nur Enterprise Editions)

Einzelheiten dazu finden Sie im Artikel über das verteilte Monitoring.

11. Benachrichtigungsskripte

11.1. Das Prinzip

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

  • Übergabe von Benachrichtigungen an ein Ticket- oder externes Benachrichtigungssystem

  • Versand von SMS über verschiedene Internetdienste

  • Automatisierte Anrufe

  • Weiterleitung an ein übergeordnetes Monitoringsystem

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 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 Logdatei des Benachrichtigungsmoduls var/log/notify.log.

11.2. Nachvollziehbare Benachrichtigungen

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

Exit CodeBedeutung

0

Das Skript wurde erfolgreich ausgeführt.

1

Ein temporärer Fehler ist aufgetreten. Die Ausführung soll nach kurzer Zeit erneut probiert werden, bis die konfigurierte maximale Anzahl von Versuchen erreicht ist. Beispiel: HTTP-Verbindung zu SMS-Dienst konnte nicht aufgebaut werden.

2 und höher

Ein endgültiger Fehler ist aufgetreten. Die Benachrichtigungen werden nicht wiederholt. Auf der GUI wird ein Benachrichtigungsfehler angezeigt. Der Fehler wird in der Historie des Hosts/Services angezeigt. Beispiel: der SMS-Dienst meldet den Fehler „Ungültige Authentifizierung“.

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.

11.3. Ein einfaches Beispielskript

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:

local/share/check_mk/notifications/foobar
#!/bin/bash
# Foobar Teleprompter

env | grep NOTIFY_ | sort > $OMD_ROOT/tmp/foobar.out
echo "Successfully written $OMD_ROOT/tmp/foobar.out"
exit 0

Danach machen Sie das Skript ausführbar:

OMD[mysite]:~$ chmod +x local/share/check_mk/notifications/foobar

Hier einige Erklärungen zum Skript:

  • In der ersten Zeile stehen #! und der Pfad zum Interpreter der Skriptsprache (hier /bin/bash).

  • In der zweiten Zeile steht nach dem Kommentarzeichen # ein Titel für das Skript. Dieser wird bei der Auswahl der Benachrichtigungsmethode in der Regel angezeigt.

  • Der Befehl env gibt alle Umgebungsvariablen aus, die das Skript bekommen hat.

  • Mit grep NOTIFY_ werden die Variablen von Checkmk herausgefiltert …​

  • … und mit sort alphabetisch sortiert.

  • > $OMD_ROOT/tmp/foobar.out schreibt das Ergebnis in die Datei tmp/foobar.out im Instanzverzeichnis.

  • Das exit 0 wäre an dieser Stelle eigentlich überflüssig, da die Shell immer den Exit Code des letzten Befehls übernimmt. Dieser ist hier echo und immer erfolgreich. Aber explizit ist immer besser.

11.4. Beispielskript testen

Damit das Skript verwendet wird, müssen Sie es in einer Benachrichtigungsregel als Methode einstellen. Selbstgeschriebene 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:

notifications method foobar

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 Logdatei des Benachrichtigungsmoduls var/log/notify.log sehen Sie die Ausführung des Skripts samt Parametern und der erzeugten Spool-Datei:

var/log/notify.log
2021-08-25 13:01:23,887 [20] [cmk.base.notify] Executing 1 notifications:
2021-08-25 13:01:23,887 [20] [cmk.base.notify]   * notifying hh via foobar, parameters: Fröhn, Klabuster, Feinbein, bulk: no
2021-08-25 13:01:23,887 [20] [cmk.base.notify] Creating spoolfile: /omd/sites/mysite/var/check_mk/notify/spool/e1b5398c-6920-445a-888e-f17e7633de60

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:

OMD[mysite]:~$ head tmp/foobar.out
NOTIFY_ALERTHANDLERNAME=debug
NOTIFY_ALERTHANDLEROUTPUT=Arguments:
NOTIFY_ALERTHANDLERSHORTSTATE=OK
NOTIFY_ALERTHANDLERSTATE=OK
NOTIFY_CONTACTALIAS=Harry Hirsch
NOTIFY_CONTACTEMAIL=harryhirsch@example.com
NOTIFY_CONTACTNAME=hh
NOTIFY_CONTACTPAGER=
NOTIFY_CONTACTS=hh
NOTIFY_DATE=2021-08-25

Auch die Parameter lassen sich hier wiederfinden:

OMD[mysite]:~$ grep PARAMETER tmp/foobar.out
NOTIFY_PARAMETERS=Fröhn Klabuster Feinbein
NOTIFY_PARAMETER_1=Fröhn
NOTIFY_PARAMETER_2=Klabuster
NOTIFY_PARAMETER_3=Feinbein

11.5. Umgebungsvariablen

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:

  • Das Hochschalten des Log-Levels für var/log/notify.log über Global settings > Notifications > Notification log level.

  • Bei Benachrichtigungen per HTML Email gibt es eine Checkbox Information to be displayed in the email body und dort die Option Complete variable list (for testing).

Folgendes sind die wichtigsten Variablen:

UmgebungsvariableBeschreibung

OMD_ROOT

Homeverzeichnis der Instanz, z.B. /omd/sites/mysite

OMD_SITE

Name der Instanz, z.B. mysite

NOTIFY_WHAT

Bei Host-Benachrichtigungen das Wort HOST, sonst SERVICE. Damit können Sie Ihr Skript so intelligent machen, dass es in beiden Fällen sinnvolle Informationen meldet.

NOTIFY_CONTACTNAME

Benutzername (Login) des Kontakts

NOTIFY_CONTACTEMAIL

E-Mail-Adresse des Kontakts

NOTIFY_CONTACTPAGER

Eintrag im Feld Pager des Benutzerprofils des Kontakts. Da das Feld meist nicht für einen bestimmten Zweck belegt ist, können Sie es einfach nutzen, um eine für die Benachrichtigung nötige Information pro Benutzer zu speichern.

NOTIFY_DATE

Datum der Benachrichtigung im ISO-8601-Format, z.B. 2021-08-25

NOTIFY_LONGDATETIME

Datum und Uhrzeit in der nicht-lokalisierten Standarddarstellung des Linuxsystems, z.B. Wed Aug 25 15:18:58 CEST 2021

NOTIFY_SHORTDATETIME

Datum und Uhrzeit im ISO-Format, z.B. 2021-08-25 15:18:58

NOTIFY_HOSTNAME

Name des betroffenen Hosts

NOTIFY_HOSTOUTPUT

Ausgabe des Check-Plugins des Host-Checks, z.B. Packet received via smart PING. Diese Ausgabe ist nur bei Host-Benachrichtigungen interessant, aber auch bei Service-Benachrichtigungen vorhanden.

NOTIFY_HOSTSTATE

Eines der Worte UP, DOWN oder UNREACH

NOTIFY_NOTIFICATIONTYPE

Typ der Benachrichtigung, wie in der Einleitung dieses Artikels beschrieben. Er wird durch eines der folgenden Worte ausgedrückt:
PROBLEM: Normales Host-/Service-Problem
RECOVERY: Host/Service kehrt zurück zum Zustand UP / OK
ACKNOWLEDGEMENT (…​): Quittierung eines Problems
FLAPPINGSTART: Host/Service beginnt unstetig zu sein
FLAPPINGSTOP: Ende der Unstetigkeit
DOWNTIMESTART: Beginn einer Wartungszeit
DOWNTIMEEND: Normales Ende einer Wartungszeit
DOWNTIMECANCELLED: Vorzeitiger Abbruch einer Wartungszeit
CUSTOM: Mit Kommando manuell ausgelöste Benachrichtigung
ALERTHANDLER (…​): Alert Handler-Ausführung (nur Enterprise Editions)
Bei den Typen mit (…​) stehen in der Klammer weitere Informationen über die Art de rBenachrichtigung.

NOTIFY_PARAMETERS

Alle Parameter des Skripts durch Leerzeichen getrennt

NOTIFY_PARAMETER_1

Erster Parameter des Skripts

NOTIFY_PARAMETER_2

Zweiter Parameter des Skripts, usw.

NOTIFY_SERVICEDESC

Name des betroffenen Services. Bei Host-Benachrichtigungen ist diese Variable nicht vorhanden.

NOTIFY_SERVICEOUTPUT

Ausgabe des Check-Plugins des Service-Checks (nicht bei Host-Benachrichtigungen)

NOTIFY_SERVICESTATE

Eines der Worte OK, WARN, CRIT oder UNKNOWN

11.6. Sammelbenachrichtigungen

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:

local/share/check_mk/notifications/mybulk
#!/bin/bash
# My Bulk Notification
# Bulk: yes

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:

local/share/check_mk/notifications/mybulk
#!/bin/bash
# My Bulk Notification
# Bulk: yes

cat > $OMD_ROOT/tmp/mybulktest.out

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

11.7. Mitgelieferte Benachrichtigungsskripte

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:

12. Dateien und Verzeichnisse

12.1. Pfade von Checkmk

PfadBedeutung

var/log/cmc.log

Logdatei des CMC. Falls das Debugging für Notifications eingeschaltet ist, finden Sie hier genaue Angaben, warum Benachrichtigungen (nicht) erzeugt wurden.

var/log/notify.log

Logdatei des Benachrichtigungsmoduls

var/log/mknotifyd.log

Logdatei des Benachrichtigungs-Spoolers

var/log/mknotifyd.state

Aktueller Zustand des Benachrichtigungs-Spoolers. Das ist hauptsächlich bei Benachrichtigungen in verteilten Umgebungen relevant.

var/nagios/debug.log

Debug-Logdatei von Nagios. Schalten Sie Debug-Meldungen in etc/nagios/nagios.d/logging.cfg in der Variablen debug_level ein.

var/check_mk/notify/spool/

Ablage der Spool-Dateien, die der Benachrichtigungs-Spooler bearbeiten soll.

var/check_mk/notify/deferred/

Bei temporären Fehlern verschiebt der Benachrichtigungs-Spooler die Dateien hierher und probiert es erst nach ein paar Minuten nochmal.

var/check_mk/notify/corrupted/

Defekte Spool-Dateien werden hierher verschoben.

share/check_mk/notifications

Von Checkmk mitgelieferte Benachrichtigungsskripte. Ändern Sie hier nichts.

local/share/check_mk/notifications

Ablageort für eigene Benachrichtigungsskripte. Möchten Sie ein mitgeliefertes Skript anpassen, so kopieren Sie es von share/check_mk/notifications hierher und behalten dessen Dateinamen bei.

share/doc/check_mk/treasures/notifications

Weitere Benachrichtigungsskripte, die Sie geringfügig anpassen und verwenden können.

12.2. Logdateien des SMTP-Servers

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

PfadBedeutung

/var/log/mail.log

Logdatei des SMTP-Servers unter Debian und Ubuntu

/var/log/mail

Logdatei des SMTP-Servers unter SUSE Linux Enterprise Server (SLES)

/var/log/maillog

Logdatei des SMTP-Servers unter Red Hat Enterprise Linux (RHEL)

Auf dieser Seite