Alarmierung (Notifications)

Auf dieser Seite


1. Einleitung

Alarmierung bedeutet, dass Benutzer im Falle von Problemen oder anderen Ereignissen von Check_MK aktiv informiert werden. Im häufigsten Fall geschieht das durch Emails. Es gibt aber auch viele andere Methoden, wie z. B. das Versenden von SMS oder die Weiterleitung an ein Ticketsystem. Check_MK bietet eine einfache Schnittstelle, um eigene Alarmierungsmethoden zu skripten.

Ausgangspunkt für jede Alarmierung ist ein Ereignis. Dieses bezieht sich immer auf einen bestimmten Host oder Service. Mögliche Typen von Ereignissen sind:

  • Ein Zustandswechsel (z. B. OKWARN)
  • Der Wechsel zwischen einem stetigen und einem unstetigen Zustand (flapping)
  • Start oder Ende einer geplanten Wartungszeit
  • Die Bestätigung eines Problems durch einen Benutzer (Acknowledgement)
  • Eine durch ein Kommando von Hand ausgelöste Alarmierung
  • Die Ausführung eines Alerthandlers (Ab CEE Version 1.4.0i2)
  • Ein Ereignis, das von der Event Console zur Alarmierung übergeben wurde

Check_MK verfügt über ein regelbasiertes System zur Konfiguration der Alarmierung, mit dem Sie auch sehr anspruchsvolle Anforderungen umsetzen können. Eine einfache Alarmierung per Email – wie sie in vielen Fällen zunächst völlig ausreicht – ist trotzdem schnell eingerichtet.

2. Alarmieren oder (noch) nicht Alarmieren?

Grundsätzlich ist Alarmierung optional, und Sie können Check_MK durchaus auch ohne diese sinnvoll nutzen. Manche große Unternehmen haben eine Art Leitstand, in der das Operating die Konsole von Check_MK ständig im Blick hat und keine zusätzlichen Emails benötigt.

Wenn Sie noch im Aufbau Ihrer Check_MK-Umgebung sind, sollten Sie außerdem bedenken, dass Alarmierung erst dann für Ihre Kollegen eine Hilfe ist, wenn keine oder nur selten Fehlalarme produziert werden. Dazu müssen Sie erstmal die Schwellwerte und alle anderen Einstellungen soweit im Griff haben, dass im Normalfall auch alles „grün“ ist. Die Akzeptanz für das neue Monitoring ist schnell dahin, wenn es die Inbox jeden Tag mit Hunderten nutzloser Emails flutet.

Folgendes Vorgehen hat sich bewährt:

Schritt 1: Tunen Sie das Monitoring und eliminieren Sie falsche Fehlermeldungen. Beheben Sie durch Check_MK neu aufgedeckte tatsächliche Probleme. Tun Sie das, bis „normalerweise“ alles OK / UP ist.

Schritt 2: Schalten Sie die Alarmierung 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, verwenden Sie Predictive Monitoring, erhöhen Sie die Maximum number of check attempts, verwenden Sie Delay ... notifications falls nötig. Wenn es sich um tatsächliche Probleme handelt, versuchen Sie, die in den Griff zu bekommen.

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

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

3. Einfache Alarmierung per Email

3.1. Voraussetzungen

In der Defaultkonfiguration von Check_MK bekommt ein Benutzer Alarmmeldungen per Email, wenn folgende Voraussetzungen erfüllt sind:

  • Der Check_MK-Server hat ein funktionierendes Setup für das Versenden von Emails.
  • Für den Benutzer ist eine Emailadresse konfiguriert.
  • Der Benutzer ist Mitglied einer Kontaktgruppe und somit ein Kontakt.
  • Es passiert ein Ereignis bei einem Host oder Service, der dieser Kontaktgruppe zugeordnet ist.

Check_MK versendet HTML-Emails, die auch die aktuellen Messwerte des betroffenen Services enthalten:

3.2. Einrichten des Mailversands unter Linux

Damit das Versenden von Emails klappt, muss Ihr Check_MK-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 Emails 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 Check_MK-Appliance können Sie den Smarthost bequem über die Web-GUI konfigurieren.

Sie können das Versenden von Emails auf der Kommandozeile mit dem Befehl mail einfach testen. Da es für diesen Befehl unter Linux zahlreiche unterschiedliche Implementierungen gibt, liefert Check_MK zur Vereinheitlichung die Variante aus dem Projekt Heirloom mailx direkt im Suchpfad des Instanzbenutzers mit aus (als ~/bin/mail). Testen Sie also am besten als Instanzbenutzer, denn mit den gleichen Rechten laufen später auch die Alarmierungsskripten.

Der Inhalt der Email 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 harri.hirsch@example.com

Die Email sollte ohne Verzögerung zugestellt werden. Falls dies nicht klappt, finden Sie Hinweise in der Logdatei des SMTP-Server im Verzeichnis /var/log (siehe Dateien und Verzeichnisse).

3.3. Emailadresse und Kontaktgruppe

Emailadresse und Kontaktgruppe eines Benutzers legen Sie in der Benutzerverwaltung fest:

Bei einer frisch erzeugten Check_MK-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 Monitoringereignis per Email benachrichtigt.

Hinweis: Falls Ihre Check_MK-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 Alarmierung zu testen, können Sie einen OK-Service einfach von Hand auf CRIT setzen. Dies geht mit dem Kommando Fake check results. Das muss dann sofort zu einer Email führen. Beim nächsten regulären Check sollte der Service dann wieder auf OK gehen und eine erneute Alarmierung auslösen (diesmal vom Typ Recovery).

Bitte beachten Sie bei diesen Tests, dass der Service bei häufigen Wechseln nach einiger Zeit in den Zustand unstetig gehen wird. Weitere Zustandswechsel lösen dann keine Alarmierungen mehr aus. In der Master control können Sie die Erkennung von Unstetigkeiten (Flap detection) vorübergehend ausschalten.

Alternativ können Sie auch eine Custom notification versenden. Dabei ändert sich der Status des entsprechenden Services nicht. Allerdings ist der erzeugte Alarm dann von einem geringfügig anderen Typ und kann sich – abhängig von Ihren Alarmierungsregeln – anders verhalten.

4. Alarmierung per Regeln steuern

4.1. Grundprinzip

Check_MK ist „ab Werk“ so eingerichtet, dass es bei einem Ereignis an jeden Kontakt des betroffenen Hosts oder Services eine Email versendet. Das ist sicher erstmal sinnvoll, aber in der Praxis tauchen viele weitergehende Anforderungen auf, z. B.:

  • Unterdrücken bestimmter wenig nützlicher Meldungen
  • „Abonnieren“ von Meldungen zu Services, für die man kein Kontakt ist
  • Alarmierung per Email, SMS oder Pager, abhängig von der Tageszeit
  • Eskalierung von Problemen nach einer bestimmten Zeit ohne Quittierung
  • Eventuell keine Alarme für WARN oder UNKNOWN
  • und vieles mehr …

Check_MK bietet Ihnen über einen regelbasierten Mechanismus maximale Flexibilität bei der Umsetzung solcher Anforderungen. Über das WATO-Modul Notifications verwalten Sie eine Kette von Alarmierungsregeln, welche festlegen, wer wann wie benachrichtigt werden soll.

Bei jedem Monitoringereignis wird diese Regelkette von oben nach unten durchlaufen. Wie immer hat jede Regel zunächst eine Bedingung, die entscheidet, ob diese Regel überhaupt zur Anwendung kommt. Ist diese für ein bestimmtes Ereignis erfüllt, legt die Regel zwei Dinge fest:

  • Eine Auswahl von Kontakten (Wer soll alarmiert werden?)
  • Eine Alarmierungsmethode (z. B. HTML-Email) und dazu optional Parameter

Anders als bei den Regeln für Host- und Serviceparameter geht die Auswertung hier auch nach einer zutreffenden Regel weiter! Die nachfolgenden Regeln können weitere Alarmierungen hinzufügen. Auch können sie Alarmierungen 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
Harri HirschEmailReply-To: linux.group@example.com
Bruno WeizenkeimEmailReply-To: linux.group@example.com
Bruno WeizenkeimSMS

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

4.2. Vordefinierte Regel

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

Diese eine Regel setzt das oben beschrieben Defaultverhalten um. Sie hat folgenden Aufbau:

Bedingungkeine, gilt also für alle Ereignisse
MethodeVersand einer Email im HTML-Format (mit eingebetteten Metrikgraphen)
Kontaktealle Kontakte des betroffenen Hosts/Services

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

Hinweis: Änderungen an Alarmierungregeln erfordern kein Activate Changes, sondern sind sofort wirksam!

4.3. Aufbau der Alarmierungsregeln

Generelle Eigenschaften

Wie bei allen Regeln in Check_MK, können Sie hier eine Beschreibung und einen Kommentar für die Regel hinterlegen sowie die Regel temporär abschalten. Die Option allow users to deactivate this notification ist per Default aktiviert. Sie erlaubt Benutzern, Alarme, die von dieser Regel erzeugt werden, „abzubestellen“. Wie das geht, zeigen wir weiter unten.

Alarmierungsmethode

Die Alarmierungsmethode legt fest, auf welchem technischen Weg alarmiert werden soll (z. B. HTML Email). Jede Methode ist durch ein Skript realisiert. Check_MK liefert einige Skripten mit aus. Sie können aber recht einfach eigene Skripte in beliebigen Programmiersprachen schreiben, um speziellere Alar­mierungen umzusetzen (z. B. Weiterleitung der Alarme an ein eigenes Ticketsystem).

Eine Methode kann Parameter anbieten. Zum Beispiel erlauben es die Methoden für ASCII- und HTML-Emails, die Absenderadresse (From:) explizit zu setzen.

Bevor Sie hier Einstellungen direkt in der Regel machen, sollten Sie aber wissen, dass Sie Parameter für die Alarmierungsmethoden auch per Host- und Serviceregeln setzen können: Bei den Host- & Service­parameters finden Sie unter Monitoring Configuration ➳ Notifications für jede Alarmierungsmethode einen Regelsatz, mit dem Sie die gleichen Einstellungen festlegen können – und das wie gewohnt sogar abhängig von Host oder Service.

Parameterdefinitionen in Alarmierungsregeln dienen dazu, für Einzelfälle von diesen Einstellungen abzuweichen. So können Sie z. B. global einen bestimmten Betreff für Ihre Email festlegen, aber in einer einzelnen Alarmierungsregel einen alternativen Betreff definieren.

Anstelle von Parametern können Sie auch Cancel all previous notifications auswählen. Dann werden Alarme dieser Methode aus früheren Regeln wieder verworfen. Näheres dazu weiter unten.

Kontaktauswahl

Wenn die Bedingungen für eine Regel erfüllt sind, kommt als nächstes die Kontaktauswahl. Der häufigste Fall ist, alle Benutzer zu alarmieren, 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 im Abschnitt Kontaktauswahl mehrere Optionen ankreuzen und so die Alarmierung auf mehr Kontakte ausweiten. Doppelte Kontakte werden von Check_MK automatisch entfernt. Damit die Regel sinnvoll ist, muss mindestes 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 alarmieren, die gleichzeitig Mitglied der Gruppen Linux und Datacenter sind.

Durch die Angabe von expliziten Emailadressen können Sie Personen benachrichtigen, die überhaupt nicht als Benutzer in Check_MK hinterlegt sind. Dies macht natürlich nur bei den Alarmierungsmethoden Sinn, die Emails verschicken.

Falls Sie bei der Methode Cancel all previous notifications gewählt haben, werden nur Alarme 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 Ereignis. Einzelheiten über die Auswirkung der verschiedenen Bedingungen erfahren Sie aus der Onlinehilfe.

Für das Verständnis ist es wichtig, dass Sie sich daran erinnern, dass der Ausgangspunkt immer ein Ereignis von einem ganz konkreten Host oder Service ist. Die Bedingungen befassen sich dabei mit den statischen Eigenschaften des Objekts (z. B. ob der Servicename 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 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:

Falls Sie nur Match host event type auswählen, wird die Regel auf keinen einzigen Servicealarm matchen und umgekehrt. 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 Servicealarme mit einer einzelnen Regel verwalten.

Ein Hinweis noch zu den Bedingungen Match contacts und Match contact groups: Hier wird als Bedingung geprüft, ob der Host/Service, um den es geht, eine bestimmte Kontaktzuordnung hat. Damit kann man Dinge machen wie „Alarme zu Hosts in der Kontaktgruppe Linux sollen nie per SMS versendet werden“. Das hat nichts mit der oben beschriebenen Kontaktauswahl zu tun:

4.4. Löschen von Alarmen

Bei der Auswahl der Methode finden Sie auch die Möglichkeit Cancel all previous notifications. Um die Funktionsweise einer solchen Regel zu verstehen, stellen Sie sich am besten die Alarmierungstabelle bildlich vor. Nehmen wir an, die Abarbeitung der Regeln zu einem konkreten Ereignis ist teilweise gelaufen und durch etliche Regeln wurden folgende drei Alarmierungen erzeugt:

Wer (Kontakt)Wie (Methode)
Harri HirschEmail
Bruno WeizenkeimEmail
Bruno WeizenkeimSMS

Nun kommt eine Regel mit der Methode SMS und der Auswahl Cancel previous notifications. Die Kontakt­auswahl selektiert die Gruppe Windows, in der auch Bruno Weizenkeim Mitglied ist. Dann wird aus der Tabelle die Zeile Bruno Weizenkeim / SMS entfernt. Nach dem Abarbeiten der Regel sieht die Tabelle also so aus:

Wer (Kontakt)Wie (Methode)
Harri HirschEmail
Bruno WeizenkeimEmail

Sollte eine spätere Regel wieder eine SMS-Alarmierungen für Bruno definieren, so hätte diese Vorrang und die SMS würde wieder in die Tabelle aufgenommen. Zusammengefasst:

  • Regeln können gezielt Alarmierungen unterdrücken (löschen).
  • Löschregeln müssen nach den Regeln kommen, welche Alarme erzeugen.
  • Eine Löschregel hebt nicht eine frühere Regel auf, sondern Alarme, die aus (möglicherweise verschiedenen) früheren Regel stammen.
  • Spätere Regeln können vormals gelöschte Alarme wieder hinzufügen.

4.5. Was ist, wenn keine Regel greift?

Wer konfiguriert, kann auch Fehler machen. Ein möglicher Fehler bei der Alarmierung wäre, dass das Monitoring ein kritisches Problem entdeckt und keine einzige Alarmierungsregel greift.

Um Sie vor so einem Fall zu schützen, bietet Check_MK in den Global settings die Einstellung Notifications ➳ Fallback email address for rule based notifications. Tragen Sie hier eine Emailadresse ein. An diese werden Alarme verschickt, auf die keine einzige Alarmierungsregel greift.

Die Fallbackadresse wird allerdings nur dann verwendet, wenn keine Regel greift, nicht wenn kein Alarm erzeugt würde! Denn das explizite Löschen von Alarmen ist ja erwünscht und kein Konfigurationsfehler.

Ab Check_MK-Version 1.4.0i1 wird die Angabe einer Fallbackadresse optisch „empfohlen“ durch eine Warnung:

Falls Sie keinen Versand an diese Adresse wünschen, so tragen Sie einfach als erste Regel eine Regel ein, die alle bisherigen Alarmierungen löscht. Diese Regel ist für die Alarmierung wirkungslos, da ja hier noch keine Alarme erzeugt wurden. Aber damit stellen Sie sicher, dass immer eine Regel greift und lassen die Warnung verschwinden.

5. Benutzerdefinierte Alarmierung

Eine nützliche Besonderheit von Check_MKs Alarmierungssystem ist, dass Benutzer sich auch ohne Administratorrechte ihre Alarmierung anpassen können. Sie können

  • Alarme hinzufügen, die sie sonst nicht bekommen würden („abonnieren“),
  • Alarme löschen, die sie sonst bekommen würden (falls nicht gesperrt),
  • Parameter von Alarmen anpassen und
  • ihre Alarmierung vorübergehend ganz abschalten.

Benutzerdefinierte Regeln

Der Einstieg aus Sicht des Benutzers sind seine persönlichen Einstellungen. Dort befindet sich der Knopf , wo er mit neue Regeln erzeugen kann.

Benutzerdefinierte Regeln sind bis auf einen kleinen Unterschied fast wie die normalen Regeln: Sie enthalten (natürlich) keine Kontaktauswahl. Als Kontakt ist automatisch der Benutzer selbst gewählt. Dadurch kann ein Benutzer nur für sich selbst Alarme hinzufügen oder löschen.

Löschen kann der Benutzer Alarme nur dann, wenn in der Regel, die sie erzeugt, die Option allow users to deactivate this notification aktiviert ist:

Was die Reihenfolge betrifft, kommen die Benutzeregeln immer nach den globalen Regeln und sie können die bisher erzeugte Alarmtabelle anpassen. Bis auf gerade beschriebene Sperren der Löschung gelten also die globalen Regeln immer als Defaulteinstellung, die vom Benutzer angepasst werden kann.

Wenn Sie ein Anpassen ganz unterbinden möchten, können Sie der Rolle der Benutzer die Berechtigung General Permissions ➳ Edit personal notification settings entziehen.

Als Administrator können Sie sich alle Benutzerregeln anzeigen lassen, wenn Sie drücken:

Mit können Sie diese auch editieren.

Vorübergehende Abschaltung

Die komplette Abschaltung der Alarmierung durch einen Benutzer selbst ist mit der Berechtigung Disable all personal notifications geschützt, welche per Default aus ist. Nur wenn Sie dieses Recht in die Rolle des Benutzers aufnehmen, bekommt er dafür in seinen persönlichen Einstellungen eine entsprechende Checkbox:

Da Sie als Administrator einfachen Zugriff auf die persönlichen Einstellungen der Benutzer haben, können Sie das Abschalten auch stellvertretend für den Benutzer machen – auch wenn diesem oben genannte Berechtigung fehlt. Sie finden diese in den Eigenschaften des Benutzerprofils. Damit können Sie z. B. während eines Urlaubs eines Kollegen sehr schnell dessen Alarme still schalten, ohne an der eigentlichen Konfiguration etwas ändern zu müssen.

6. Wann genau Alarme erzeugt werden

6.1. Einleitung

Ein großer Teil der Komplexität im Alarmierungssystem von Check_MK liegt in den zahlreichen Tuning­möglichkeiten, mit denen unwichtige Alarme vermieden werden können. Die meisten davon betreffen Situationen, in denen bereits beim Auftreten der Ereignisse Alarme verzögert oder unterdrückt werden. Auch gibt es eine im Monitoringkern eingebaute Intelligenz, die bestimmte Alarme von Haus aus unterdrückt. Alle diese Aspekte wollen wir uns in diesem Kapitel ansehen.

6.2. Geplante Wartungszeiten

Während sich ein Host oder Service in einer geplanten Wartungszeit befindet, ist für dieses Objekt die Alarmierung 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 alarmiert.
  • Der Beginn und das Ende einer Wartungszeit selbst ist auch ein Ereignis, welches alarmiert wird.

Objekte, die sich in einer Wartungszeit befinden, werden mit einem hellblauen Mond markiert. Services, dessen Hosts sich in Wartung befinden, mit einem dunkelblauen .

6.3. Alarmierungsperioden

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

Die Konfiguration geschieht über die Regelsätze Monitoring Configuration ➳ Notification period for hosts bzw. ... services. Ein Objekt, welches sich gerade nicht in seiner Alarmierungsperiode befindet, wird durch einen weißen Mond markiert.

Ereignisse zu einem Objekt, das sich gerade nicht in seiner Alarmierungsperiode befindet, werden nicht alarmiert. Alarme werden nachgeholt, wenn die Alarmierungsperiode wieder aktiv wird und der Host/Service sich immer noch in einem Problemzustand befindet. Dabei wird nur der jeweils letzte Zustand alarmiert, auch wenn es außerhalb der Periode mehrere Zustandswechsel gab.

Übrigens gibt es auch bei den Alarmierungsregeln die Möglichkeit, eine Alarmierung auf eine bestimmte Zeitperiode zu beschränken. Damit können Sie die Zeitbereiche zusätzlich einschränken. Allerdings werden Alarme, 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 stale.

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

Um dies zu vermeiden, erzeugt der Monitoringkern für Services grundsätzlich nur dann Alarme, 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 Ping.

Wenn Sie die Raw Edition verwenden (oder die Enterprise Edition mit Nagios als Kern), dann kann es in seltenen Fällen bei einem Host-Problem trotzdem zu einer Alarmierung eines aktiven Services kommen. Der Grund liegt darin, dass Nagios die Resultate von Hostchecks 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 Checks nur wenige Sekunden vergehen, kann es sein, dass Nagios den Host noch als UP wertet, obwohl dieser bereits DOWN ist. Der CMC hingegen hält den Service-Alarm solange in Wartestellung, bis der Zustand des Hosts geklärt ist und vermeidet den ungewünschten Alarm so zuverlässig.

6.5. Parenthosts

Stellen Sie sich vor, ein wichtiger Netzwerkrouter 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 Alarmierungen werden ausgelöst. Nicht sehr schön.

Um das zu vermeiden, können Sie den Router als Parenthost der Hosts definieren. Wenn es redundante Routen gibt, kann man auch mehrere Parents definieren. Sobald alle Parents auf DOWN gehen, werden die jetzt nicht erreichbaren Hosts auf den Zustand UNREACH gesetzt und die Alarmierung für diese wird unterdrückt. Das Problem mit dem Router selbst wird selbstverständlich schon alarmiert.

Der CMC verhält sich intern übrigens geringfügig anders als Nagios. Um Fehlalarme zu vermeiden, richtige Alarme aber korrekt durchzuführen, achtet er sehr genau auf die exakten Zeitpunkte der jeweiligen Hostchecks. Scheitert ein Hostcheck, so wartet der Kern zunächst das Ergebnis des Hostchecks der Parenthosts ab, bevor ein Alarm erzeugt wird. Dieses Warten geschieht asynchron und ohne das übrige Monitoring zu beinträchtigen. Alarmierungen von Hosts können sich dadurch geringfügig verzögern.

6.6. Per Regel abgeschaltete Alarmierung

Über die Regelsätze Monitoring configuration ➳ Enable/disable notifications for hosts bzw. ... for services können Sie Hosts und Services bestimmen, für die grundsätzliche keine Alarme erzeugt werden sollen. Wie oben erwähnt, unterbindet dann bereits der Kern eine Alarmierung. Eine nachträgliche Alarmierungsregel für ein „abonnieren“ von Alarmen solcher Services wäre wirkungslos!

6.7. Manuelles Abschalten der Alarmierung

Auch ist es möglich, bei einzelnen Hosts oder Services per Kommando die Alarmierung vorübergehend abzuschalten:

Solche Hosts oder Services werden dann mit einem Icon markiert. Da Kommandos im Gegensatz zu Regeln weder Konfigurationsberechtigung noch ein Acivate changes benötigen, können sie daher eine schnelle Lösung für das Operating sein, auf eine Situation zu reagieren.

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

6.8. Alarmierung global ausschalten

In der Master control finden Sie einen Hauptschalter für die Alarmierung:

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 kritisch geht. Sie ersparen sich so den Unmut Ihrer Kollegen über die vielen nutzlosen Emails. Bitte vergessen Sie aber nicht, die Alarmierung später wieder einzuschalten.

Im verteilten Monitoring gibt es diesen Schalter einmal pro Instanz. Ein Abschalten der Alarmierung auf der Masterinstanz lässt Alarme auf den Slaves weiterhin aktiviert – selbst wenn diese zentral zum Master weitergeleitet und von dort zugestellt werden.

Alarme, die angefallen wären, während die Alarmierung abgeschaltet war, werden beim Wiedereinschalten nicht nachgeholt.

6.9. Verzögerung der Alarmierung

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

Sie stellen hier eine Dauer in Minuten ein. Ein Alarm wird dann solange zurückgehalten, bis diese Zeit abgelaufen ist. Tritt vorher der OK / UP-Zustand wieder ein, so wird kein Alarm erzeugt. Natürlich bedeutet das aber dann auch, dass Sie im Falle eines wirklichen Problems erst mit einer Verzögerung alarmiert werden.

Und noch besser als eine Verzögerung der Alarmierung ist natürlich, den eigentlichen Grund der sporadischen Probleme loszuwerden. Aber das ist eine andere Geschichte...

6.10. Mehrere Checkversuche

Eine zur Verzögerung der Alarmierung sehr ähnliche Methode ist das Erlauben von mehreren Check­versuchen, wenn ein Service in einem Problemzustand geht. Dies geschieht über die Regelsätze Monitoring configuration ➳ Maximum number of check attempts for hosts bzw. ... services.

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

Im Gegensatz zur verzögerten Alarmierung haben Sie hier noch die Möglichkeit, sich Ansichten 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

Wenn ein Host oder Service binnen kurzer Zeit mehrfach den Zustand ändert, so gilt er als unstetig. Dies ist sozusagen ein eigener Zustand. Die Idee datei ist das Vermeiden von exzessiven Alarmen in Phasen, in denen ein Dienst 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 Alarme mehr. Dafür wird aber jeweils ein Alarm 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 Monitoring configuration ➳ Enable/disable flapping detection for hosts bzw. ... services können Sie Objekte von der Erkennung ausklammern.
  • In der  Check_MK Enterprise Edition können Sie mit der globalen Option Monitoring core ➳ Tuning of flap detection die Parameter der Unstetigkeitserkennung festlegen und sie mehr oder weniger empfindlich einstellen.

Bitte konsultieren Sie die Onlinehilfe für Details zu den einstellbaren Werten.

6.12. Periodisch wiederholte Alarmierungen und Eskalationen

Bei Systemen mit einem hohen Servicelevel kann es sinnvoll sein, es nicht bei einer einzelnen Alarmierung zu belassen, falls das Problem über einen längeren Zeitraum weiterhin besteht. Sie können Check_MK so einrichten, dass es in einem festen Intervall immer weitere Alarme versendet, solange bis das Problem

  • entweder quittiert
  • oder behoben wurde.

Die Einstellung dafür finden Sie in den Regelsätzen Monitoring configuration ➳ Periodic notifications during host problems bzw. ... service problems:

Sobald diese Option aktiv ist, wird Check_MK für ein fortbestehendes Problem im konfigurierten Intervall weitere Alarmierungen erzeugen. Die Alarme bekommen eine laufende, Nummer, welche bei 1 beginnt.

Periodische Alarme 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 Alarmierung an andere Personen eskaliert werden kann.

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

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

7. Der Weg eines Alarms von Anfang bis Ende

7.1. Überblick

Um die Zusammenhänge von allen Einstellmöglichkeiten und Rahmenbedingungen genau zu verstehen und um eine sinnvolle Fehlerdiagnose zu ermöglichen, wenn mal eine Alarmierung nicht wie erwartet geschieht oder ausbleibt, beschreiben wir hier alle Einzelheiten zum Ablauf einer Alarmierung. Dabei sind folgende Komponenten beteiligt:

Komponente Aufgabe Logdatei
Nagios Monitoringkern in der  Check_MK Raw Edition. Der Kern erkennt Ereignisse und erzeugt Rohalarme. var/log/nagios.log
var/nagios/debug.log
CMC Der Check_MK Micro Core ist der Kern der  Check_MK Enterprise Edition und erfüllt die gleiche Aufgabe wie Nagios in der CRE. var/log/cmc.log
Alarmierungsmodul Das Alarmierungsmodul wertet die Alarmierungsregeln aus, um aus einem Rohalarm fertige Alarme zu erzeugen. Es ruft die Alarmierungsskripten auf. var/log/notify.log
Alarmspooler Der Alarmspooler (nur  Check_MK Enterprise Edition) dient der asynchronen Zustellung von Alarmen und dem zentralisierten Alarmieren in verteilten Umgebungen. var/log/mknotifyd.log
Alarmierungsskript Für jede Alarmierungsmethode gibt es ein Skript, welches die eigentliche Zustellung durchführt (z. B. eine HTML-Email generiert und versendet). var/check_mk/notify.log

7.2. Der Monitoringkern

Rohalarme

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

In der Monitoringhistorie des Services sieht ein Rohalarm so aus:

  • Das Symbol ist ein hellgrauer Lautsprecher.
  • Als Kontakt wird check-mk-notify angegeben.
  • Als Alarmierungskommando wird check-mk-notify angegeben.

Der Rohalarm geht dann an das Alarmierungsmodul von Check_MK, welches die Auswertung der Alarmie­rungs­regeln ü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 Monitoringkern Nagios

Der in der  Check_MK Raw Edition verwendete Nagios-Kern loggt alle Ereignisse nach var/log/nagios.log. Diese Datei ist gleichzeitig der Ort, wo die Monitoringhistorie gespeichert wird, welche Sie auch in der GUI abfragen, wenn Sie z. B. die Alarme 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 Alarme erzeugt oder unterdrückt wurden:

var/nagios/debug.log
[1479122384.210217] [032.0] [pid=17610] ** Service Notification Attempt ** Host: 'heute', Service: 'CPU utilization', Type: 0, Options: 0, Current State: 2, Last Notification: Th
[1479122384.210247] [032.0] [pid=17610] Notification viability test passed.
[1479122384.667768] [032.0] [pid=17610] 1 contacts were notified.  Next possible notification time: Mon Nov 14 12:19:44 2016
[1479122384.667785] [032.0] [pid=17610] 1 contacts were notified.

Fehlerdiagnose im Monitoringkern CMC

In der Check_MK Enterprise Edition finden Sie in der Logdatei var/log/cmc.log ein Protokoll des Monitoringkerns. In der Standardeinstellung enthält dies keine Angaben zu Alarmen. Sie können aber ein sehr detailiertes Logging einschalten, mit der globalen Option Monitoring Core ➳ Logging of the notification mechanics. Der Kern gibt dann darüber Auskunft, warum er ein Ereignis für die Alarmierung an das Alarmsystem weitergibt oder warum (noch) nicht:

OMD[mysite]:~$ tail -f var/log/cmc.log
2015-05-20 10:01:10 [5] Hard state change on 10.1.1.199;Interface 00002 to CRITICAL
2015-05-20 10:01:10 [5] Setting up notification for 10.1.1.199;Interface 00002, problem id: 47, delay: 0sec
2015-05-20 10:01:10 [5] Checking notification for 10.1.1.199;Interface 00002
2015-05-20 10:01:10 [5]  Postponing: service is currently in downtime

Bitte beachten Sie, dass dies teilweise sehr viele Meldungen erzeugen kann. Es ist aber nützlich, wenn man später die Frage beantworten will, warum in einer bestimmten Situtation kein Alarm erzeugt wurde.

7.3. Regelauswertung durch das Alarmierungsmodul

Nachdem der Kern einen Rohalarm erzeugt hat, durchläuft dieser die Kette der Alarmierungsregeln. Resultat ist eine Tabelle von Alarmen. Neben den Daten aus dem Rohalarm enthält jeder Alarm folgende zusätzliche Informationen:

  • Den Kontakt, der alarmiert werden soll
  • Die Methode für die Alarmierung
  • Parameter für diese Methode

Bei einer synchronen Zustellung wird jetzt pro Eintrag in der Tabelle das passende Alarmierungsskript aufgerufen. Bei einer asynchronen Zustellung wird der Alarm per Datei an den Alarmspooler übergeben.

Analyse der Regelkette in WATO

Wenn Sie komplexere Regelwerke erstellen, stehen Sie sicher gelegentlich vor der Frage, welche Regeln denn nun auf einen bestimmten Alarm greifen. Dazu bietet Check_MK eine im WATO-Modul Notifications eingebaute Analysefunktion, welche Sie mit dem Knopf erreichen.

Im Analysemodus werden Ihnen die letzten zehn Rohalarme angezeigt, die das System erzeugt hat und welche die Regeln durchlaufen haben:

Für jeden dieser zehn Rohalarme stehen Ihnen zwei Aktionen zur Verfügung:

Diese Aktion testet die Regelkette, in dem für jede Regel geprüft wird, ob das gewählte Ereignis alle Bedingungen der Regel erfüllen würde. Im Anschluss an die Regeln wird dann die daraus resultierende Tabelle von Alarmen angezeigt.
Diese Aktion wiederholt diesen Rohalarm, als wäre er 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 Alarmierung dann aussieht.

Logdatei des Alarmierungsmoduls

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

OMD[mysite]:~$ tail -f var/log/notify.log
2015-05-20 09:53:52 ----------------------------------------------------------------------
2015-05-20 09:53:52 Got raw notification (10.1.1.199;Interface 00012) context with 60 variables
2015-05-20 09:53:52 Global rule 'Notify all contacts of a host/service via HTML email'...
2015-05-20 09:53:52  -> matches!
2015-05-20 09:53:52    - adding notification of hh via mail
2015-05-20 09:53:52 Executing 1 notifications:
2015-05-20 09:53:52   * notifying hh via mail, parameters: (no parameters), bulk: no
2015-05-20 09:53:52      executing /omd/sites/mysite/share/check_mk/notifications/mail

Die globale option Notifications ➳ Notification log level steuert die Ausführlichkeit dieser Datei in zwei Stufen. Stellen Sie dieses auf Full dump of all variables and command, so finden Sie in der Logdatei eine komplette Auflistung aller Variablen, die dem Alarmierungsskript bereitgestellt werden.

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

var/log/notify.log
2016-11-14 15:02:23 ----------------------------------------------------------------------
2016-11-14 15:02:23 Got raw notification (myserver123;Check_MK) context with 69 variables
2016-11-14 15:02:23 Raw context:
                    CONTACTS=
                    HOSTACKAUTHOR=
                    HOSTACKCOMMENT=
                    HOSTADDRESS=127.0.0.1
                    HOSTALIAS=myserver123
                    HOSTATTEMPT=1
                    HOSTCHECKCOMMAND=check-mk-host-smart

7.4. Asynchrone Zustellung durch Alarmspooler

Synchron oder Asynchron

Eine mächtige Zusatzfunktion der CEE ist der Alarmspooler. Dieser ermöglicht eine asynchrone Zustellung von Alarmen. Was bedeutet asynchron in diesem Zusammenhang?


Synchrone Zustellung Das Alarmierungsmodul wartet, bis das Alarmierungsskript fertig ausgeführt wurde. Sollte dies eine längere Ausführungszeit haben, stauen sich weitere Alarme auf. Wird das Monitoring angehalten, gehen diese Alarme verloren. Außerdem kann sich bei vielen Alarmen in kurzer Zeit ein Rückstau bis zum Kern bilden, so dass das Monitoring dadurch ins Stocken gerät.
Asynchrone Zustellung Jeder Alarm wird in einer Spooldatei unter var/check_mk/notifify/spool abgelegt. Es kann sich kein Stau bilden. Bei einem Stop des Monitorings bleiben die Spooldateien erhalten und Alarme werden später korrekt zugestellt. Das Abarbeiten der Spooldateien übernimmt der Alarmspooler.

Eine synchrone Zustellung ist dann vertretbar, wenn das Alarmierungsskript schnell läuft und vor allem nicht in irgendeinen Timeout geraten kann. Bei Alarmierungsmethoden, die auf vorhandene Spooler zurück­greifen, ist das gegeben. Insbesondere bei Email und SMS kommen Spooldienste vom System zum Einsatz. Das Alarmierungsskript übergibt eine Datei an den Spooler, wobei keine Wartezustände auftreten können.

Bei Verwendung der nachvollziehbaren Zustellung per SMTP oder anderen Skripten, welche Netzwerk­verbindungen aufbauen, sollten Sie auf jeden Fall asynchrone Zustellung einstellen. Dazu gehören auch Skripten, 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 einen oben beschriebenen Stau auslösen.

Asynchrone Zustellung konfigurieren

Stellen Sie zunächst sicher, dass der Alarmspooler (mknotifyd) aktiviert ist. Dieser muss bei omd status angezeigt werden:

OMD[mysite]:~$ omd status
mkeventd:       running
liveproxyd:     running
mknotifyd:      running
rrdcached:      running
cmc:            running
apache:         running
crontab:        running
-----------------------
Overall state:  running

Fehlt hier der mknotifyd, so können Sie diesen aktivieren mit:

OMD[mysite]:~$ omd -f config set MKNOTIFYD on

Der zweite Schritt ist das Aktivieren der asynchronen Zustellung. Setzen Sie dazu die globale Einstellung Notifications ➳ Notification spooling auf den Wert Asynchronous local delivery by notification spooler:

Ab Version 1.4.0i3 ist der Alarmspooler immer aktiv und garnicht mehr abschaltbar. Die asynchrone Zustellung ist dort bei neu angelegten Instanzen Defaulteinstellung.

Fehlerdiagnose

Der Alarmspooler pflegt eine eigene Logdatei: var/log/mknotifyd.log. Diese verfügt über drei Loglevels, welche Sie in der globalen Option Notifications ➳ Notification spooler configuration ➳ Verbosity of logging einstellen können. Per Default werden nur Start, Ende und Fehlermeldungen geloggt. Bei der mittleren Stufe können Sie das Bearbeiten der Spooldateien stehen:

var/log/mknotifyd.log
2016-11-14 15:25:53 [5] -----------------------------------------------------------------
2016-11-14 15:25:53 [5] Check_MK Notification Spooler version 1.2.8p14 starting
2016-11-14 15:25:53 [5] Log verbosity: 2
2016-11-14 15:25:53 [5] Daemonized with PID 9815.
2016-11-14 15:26:20 [6] Detected updated configuration by WATO.
2016-11-14 15:26:20 [7] Reading configuration file /omd/sites/mysite/etc/check_mk/mknotifyd.d/wato/global.mk
2016-11-14 15:27:17 [6] Processing spoolfile: /omd/sites/mysite/var/check_mk/notify/spool/8db5dfd8-3f93-474a-9e48-22945af71fd4
2016-11-14 15:27:17 [7] process result <-1> of file /omd/sites/mysite/var/check_mk/notify/spool/8db5dfd8-3f93-474a-9e48-22945af71fd4
2016-11-14 15:27:44 [6] Processing spoolfile: /omd/sites/mysite/var/check_mk/notify/spool/f58df405-0011-46f8-a981-73a607d11705
2016-11-14 15:27:44 [7] process result <-1> of file /omd/sites/mysite/var/check_mk/notify/spool/f58df405-0011-46f8-a981-73a607d11705

8. Sammelalarmierung (Bulk notifications)

Jeder, der mit Monitoring arbeitet, hat schon einmal erlebt, dass ein isoliertes Problem eine ganze Flut von (Folge-)Alarmen losgetreten hat. Das Prinzip der Parenthosts ist ein Weg, dies in bestimmten Fällen zu vermeiden, hilft aber leider auch nicht in allen Fällen.

Nehmen wir ein Beispiel aus dem Check_MK-Projekt selbst: Einmal pro Tag bauen wir für jede unterstützte Linux-Distribution Installationspakete von Check_MK. Unser eigenes Check_MK-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 Sammelalarmierung ist bei uns so konfiguriert, dass in so einem Fall nur eine einzige Email versendet wird, welche alle 43 Alarme nacheinander auflistet. Das ist natürlich viel übersichtlicher als 43 einzelne Emails und verhindert, dass man im Eifer des Gefechts eine 44ste Email, die zu einem ganz anderen Problem gehört, übersieht.

Die Funkionsweise der Sammelalarmierung ist sehr einfach. Wenn ein Alarm auftritt, so wird dieser zunächst eine kurze Zeit lang zurückgehalten. Weitere Alarme, die während dieser Zeit kommen, werden dann gleich mit in dieselbe Email gepackt. Das Sammeln stellen Sie pro Regel ein. So können Sie z. B. tagsüber mit Einzelmails arbeiten, nachts aber mit einer Sammelalarmierung. Wird in einer Regel die Sammelalarmierung 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 das natürlich auch auf größere Zeiten einstellen. Dadurch entsteht aber eine grundsätzliche Verzögerung der Alarmierung.

Da es natürlich keinen Sinn macht, alles in einen Topf zu werfen, können Sie bestimmen, welche Gruppen von Problemen jeweils gemeinsam alarmiert werden sollen. Sehr üblich ist die Option Host, welche dafür sorgt, dass nur Alarme vom gleichen Host zusammengefasst werden.

Hier noch ein paar Fakten zur Sammelalarmierung:

  • Wenn das Sammeln in einer Regel eingeschaltet ist, kann das mit einer späteren wieder ausgeschaltet werden und umgekehrt.
  • Die Sammelalarmierung geschieht immer pro Kontakt. Jeder hat quasi seinen privaten Sammeltopf.
  • Sie können die Größe des Topfs limitieren. Bei Erreichen der Anzahl wird der Sammelalarm sofort verschickt.
  • Die Alarmierungsmethode muss Sammelalarme unterstützen. Aktuell ist das nur bei ASCII Email und HTML Email der Fall.

Sammelalarme und Zeitperioden

Was ist eigentlich, wenn ein Alarm innerhalb der Alarmierungsperiode liegt, die Sammelalarmierung, 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 Alarme auf Zeitperioden eingrenzen, gelten immer nur für den eigentlichen Alarm. Die später folgende Sammelalarmierung wird immer unabhängig von sämtlichen Zeitperioden zugestellt.

9. Nachvollziehbare Zustellung per SMTP

9.1. Email ist nicht zuverlässig

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

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

Ist die Email gar nicht zustellbar, so erzeugt der SMTP-Server eine hübsche Fehlermeldung in seiner Logdatei und versucht, an den „Absender“ eine Fehleremail zu generieren. Aber das Monitoringsystem ist kein richtiger Absender und kann auch keine Emails empfangen. In der Folge gehen solche Fehler dann einfach unter und Alarme bleiben aus.

9.2. SMTP auf direktem Weg ermöglicht Fehlerauswertung

Ab Version 1.4.0i2 der  Check_MK Enterprise Edition bietet Check_MK nun die Möglichkeit einer nachvollziehbaren Zustellung per SMTP. Dabei wird bewusst auf eine Hilfe des lokalen Mailservers verzichtet. Anstelle dessen sendet Check_MK höchstpersönlich die Email via SMTP zu Ihrem Smarthost und wertet die SMTP-Antwort 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: Check_MK bekommt quasi vom SMTP-Smarthost (empfangender Server) eine Quittung, dass die Email übernommen wurde – inklusive einer Mail-ID.

In der Historie des betroffenen Services können Sie das dann genau sehen. Hier ist ein Beispiel, in dem ein Service testweise von Hand auf CRIT gesetzt wurde. Folgende Abbildung zeigt die Ansicht :

Sie sehen dabei drei Einzelschritte:

  1. Der Monitoringkern erzeugt einen Rohalarm.
  2. Die Auswertung der Regeln ergibt einen Alarm an den Benutzer hh mit der Methode mail.
  3. Die Email wurde erfolgreich an den Smarthost übergeben. Dessen Antwort ist 250 - 2.0.0 Ok: queued as 4A2B180676.

Das Ausführen des Alarmierungsskripts und die Antwort vom SMTP-Server können Sie auch im notify.log sehen:

var/log/notify.log
2016-11-07 13:51:13 Got spool file c8c1f33a (myserver123;CPU utilization) for local delivery via mail
2016-11-07 13:51:13      executing /omd/sites/mysite/share/check_mk/notifications/mail
2016-11-07 13:51:14      Output: success 250 - 2.0.0 Ok: queued as ECB7A82019

Die Message-ID 4A2B180676 wird im Logfile des Smarthosts auftauchen. Dort können Sie dann im Zweifel recherchieren, wo die Email verblieben ist. Auf jeden Fall können Sie so belegen, das und wann Sie von Check_MK 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 vom Smarthost: (535, '5.7.8 Error: authentication failed:')

Doch was tun bei gescheiterten Alarmierungen? Diese wiederum per Email zu alarmieren ist augen­scheinlich keine gute Lösung. Anstelle dessen zeigt Check_MK einen deutlichen Warnhinweis in der Tactical Overview an:

Hier können Sie

  • durch Klick auf den Text ... failed notifications zu einer Liste der fehlgeschlagenen Zustellungen kommen und
  • durch Klick auf diese Meldungen quittieren und damit den Hinweis wieder entfernen.

Konfiguration der asynchronen Zustellung

Bitte beachten Sie, dass die direkte Zustellung per SMTP in Fehlersituationen dazu führen kann, dass das Alarmierungsskript sehr lange läuft und am Ende in einen Timeout gerät. Deswegen ist es unbedingt ratsam, dass Sie den Alarmspooler verwenden und eine asynchrone Zustellung von Alarmen einstellen.

Das Verhalten bei wiederholbaren Fehlern (wie einem SMTP-Timeout) können Sie in den globalen Einstellungen unter Notifications ➳ Notification spooler configuration pro Alarmierungsmethode einstellen:

Neben einem optionalen Timeout (Default ist 60 Sekunden) und einer maximalen Anzahl von Wiederholversuchen, können Sie festlegen, ob das Skript mehrfach parallel laufen und so gleichzeitig mehrere Alarme versenden darf (Maximum concurrent executions). Ist das Alarmierungsskript 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.

SMS und andere Alarmierungsmehoden

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

10. Alarmierung in verteilten Systemen

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

  1. Lokale Zustellung
  2. Zentrale Zustellung auf dem Master (nur CEE)

Einzelheiten dazu finden Sie im Artikel über Verteiltes Monitoring.

11. Alarmierungsskripten

11.1. Grundprinzip

Alarmierung kann auf sehr vielfältige und individuelle Weise geschehen. Typische Fälle sind:

  • Übergabe von Alarmen an ein Ticket- oder externes Alarmierungssystem
  • Versand von SMS über verschiedene Internetdienste
  • Automatisierte Anfrufe
  • Weiterleitung an ein übergeordnetes Monitoringsystem

Aus diesem Grund bietet Check_MK eine sehr einfache Schnittstelle, mit der Sie selbst eigene Alarmierungsskripten 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 Check_MK mitgelieferten Skripten liegen unter share/check_mk/notifications. Dieses Verzeichnis ist Teil der Software und nicht für Änderungen vorgesehen. Legen Sie eigene Skripten 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 Alarmierungsregeln 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 Alarmierungsregeln anpassen.

Einige weitere Beispielskripten 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 eines Alarms 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 Ereignis, den zu alarmierenden Kontakt und Parameter, die in der Alarmierungsregel angegeben wurden.

Texte, die das Skript in die Standardausgabe schreibt (print, echo, etc.), erscheinen in var/log/notify.log.

11.2. Nachvollziehbare Alarmierung

In Version 1.4.0i2 haben die Alarmierungsskripten die Möglichkeit, über den Exitcode mitzuteilen, ob ein wiederholbarer Fehler aufgetreten ist oder ein endgültiger:

Exitcode Bedeutung
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 Alarmierung wird nicht wiederholt. Auf der GUI wird ein Alarmierungsfehler angezeigt. Der Fehler wird in der Historie des Hosts/Services angzeigt. Beispiel: der SMS-Dienst meldet den Fehler „Ungültige Authentifizierung“.

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

Die Behandlung von Alarmierungsfehlern aus Sicht des Benutzers wird beim Kapitel über nachvollziehbare Zustellung per SMTP erklärt.

11.3. Ein einfaches Beispiel

Als Beispiel schreiben wir ein Skript, das alle Informationen zu dem Alarm in eine Datei schreibt. Als Sprache verwenden wir hier die Linux-Shell (BASH):

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 wir 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 Alarmierungsmethode in der Regel angezeigt.
  • Der Befehl env gibt alle Umgebungsvariablen aus, die das Skript bekommen hat.
  • Mit grep NOTIFY_ werden die Variablen von Check_MK herausgefiltert …
  • … und mit sort alphabetisch sortiert.
  • > $OMD_ROOT/tmp/foobar.out schreibt das Ergebnis in die Datei tmp/foobar.out innerhalb der Instanz.
  • Das exit 0 wäre an dieser Stelle eigentlich überflüssig, da die Shell immer den Exitcode des letzten Befehls übernimmt. Dieser ist hier echo und immer erfolgreich. Aber explizit ist immer besser.

Testlauf

Damit unser Skript verwendet wird, müssen wir es in einer Alarmierungsregel als Methode einstellen. Selbstgeschriebene Skripten haben keine Parameterdeklaration. Daher fehlen die ganzen Checkboxen, wie sie z. B. bei HTML Email angeboten werden. Anstelle dessen kann der Benutzer eine Liste von Texten als Parameter angeben, die dem Skript als NOTIFY_PARAMETER_1 usw. bereitgestellt werden. Für unseren Test übergeben wir die Parameter Fröhn, Klabuster und Feinbein:

Nun setzen wird zum Test den Service CPU load auf dem Host myserver123 auf CRIT. Im notify.log sehen wir die Ausführung des Skripts und dessen einzeilige Ausgabe „Successfully written...“:

var/log/notify.log
2016-11-15 12:30:49 executing /omd/sites/mysite/local/share/check_mk/notifications/foobar
2016-11-15 12:30:49 Output: Successfully written /omd/sites/mysite/tmp/foobar.out

Die Datei tmp/foobar.out enthält nun eine alphabetische Liste aller Check_MK-Umgebungsvariablen, die Informationen über den Alarm 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_CONTACTALIAS=Harri Hirsch
NOTIFY_CONTACTEMAIL=mk@mathias-kettner.de
NOTIFY_CONTACTNAME=hh
NOTIFY_CONTACTPAGER=
NOTIFY_CONTACTS=hh
NOTIFY_DATE=2016-11-15
NOTIFY_HOSTACKAUTHOR=
NOTIFY_HOSTACKCOMMENT=
NOTIFY_HOSTADDRESS=127.0.0.1
NOTIFY_HOSTALIAS=myserver123

Auch unsere Parameter wurden bereitgestellt:

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

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

  • Das Hochschalten des Loglevels für notify.log in den globalen Einstellungen.
  • Bei der Alarmierung per HTML Email gibt es eine Checkbox Information to be displayed in the email body und dort den Punkt Complete variable list (for testing).

Folgendes sind die wichtigsten Variablen:

OMD_ROOT Homeverzeichnis der Instanz, z. B. /omd/sites/mysite
OMD_SITE Name der Instanz, z. B. mysite
NOTIFY_WHAT Bei Hostalarmen 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 zu alarmierenden Kontakts
NOTIFY_CONTACTEMAIL Emailadresse des zu alarmierenden 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 Alarmierung nötige Information pro Benutzer zu speichern.
NOTIFY_DATE Datum des Alarms im ISO-8601-Format, also z. B. 2016-11-15
NOTIFY_LONGDATETIME Datum und Uhrzeit in der nicht-lokalisierten Defaultdarstellung des Linuxsystems, also z. B. Tue Nov 15 12:31:06 CET 2016
NOTIFY_SHORTDATETIME Datum und Uhrzeit im ISO-Format, also z. B. 2016-11-15 12:31:06
NOTIFY_HOSTNAME Name des betroffenen Hosts im Monitoring
NOTIFY_HOSTOUTPUT Ausgabe des Hostcheck-Plugins (also z. B. „Packet received via smart PING“). Diese Ausgabe ist nur bei Hostalarmen interessant, aber auch bei Servicealarmen vorhanden.
NOTIFY_HOSTSTATE Eines der Worte UP, DOWN oder UNREACH
NOTIFY_NOTIFICATIONTYPE Der Typ des Alarms (siehe in der Einleitung dieses Artikels). Er wird durch eines der folgenden Worte ausgedrückt:

PROBLEM - Normales Host- oder Serviceproblem
RECOVERY – Host-/Service geht wieder UP / OK
ACKNOWLEDGEMENT (...)Quittierung eines Problems
FLAPPINGSTART – Ein Host-/Service beginnt unstetig zu sein
FLAPPINGSTOP – Ende der Unstetigkeit
DOWNTIMESTART – Beginn einer geplanten Wartung.
DOWNTIMEEND – Normales Ende einer Wartung
DOWNTIMECANCELLED – Voreitiger Abbruch einer Wartung
CUSTOM – Alarm, der per Kommando manuell ausgelöst wurde
ALERTHANDLER (...) – Alerthandlerausführung (CEE ab 1.4.0i2)

Bei den Typen mit (...) stehen in der Klammer weitere Informationen über die Art des Alarms.

NOTIFY_PARAMETERS Alle Parameter des Skripts durch Leerzeichen getrennt
NOTIFY_PARAMETER_1 Der erste Parameter des Skripts
NOTIFY_PARAMETER_2 Der zweite Parameter des Skriptes, usw.
NOTIFY_SERVICEDESC Der Name des Services, der alarmiert wird. Bei Hostalarmen ist diese Variable nicht vorhanden.
NOTIFY_SERVICEOUTPUT Ausgabe des Checkplugins des Servicechecks (nicht bei Hostalarmen)
NOTIFY_SERVICESTATE Eines der Worte OK, WARN, CRIT oder UNKNOWN

11.5. Sammelalarme

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

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

local/share/check_mk/notifications/mybulk
#!/usr/bin/python
# 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 Newlines darzustellen.

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

Am besten, Sie probieren das Ganze erstmal mit einem einfachen Test aus, der die kompletten Daten in eine Datei schreibt und sehen sich an, wie die Daten gesendet werden. Das kann z. B. so gehen:

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

cat > $OMD_ROOT/tmp/mybulktest.out

12. Dateien und Verzeichnisse

12.1. Pfade von Check_MK

Pfad Bedeutung
var/log/cmc.log Logdatei des CMC. Fall das Notificationdebugging eingeschaltet ist, finden Sie hier genaue Angaben, warum Alarme (nicht) erzeugt wurden.
var/log/notify.log Logdatei des Alarmierungsmoduls
var/log/mkotifyd.log Logdatei des Alarmspoolers
var/log/mkotifyd.state Aktueller Zustand des Alarmspoolers. Das ist hauptsächlich bei einer verteilten Alarmierung relevant.
var/nagios/debug.log Debuglogfile von Nagios. Schalten Sie Debugmeldungen in etc/nagios/nagios.d/logging.cfg in der Variable debug_level ein.
var/check_mk/notify/spool/ Ablage der Spooldateien, die der Alarmspooler bearbeiten soll.
var/check_mk/notify/deferred/ Bei temporären Fehlern verschiebt der Alarmspooler die Dateien hierher und probiert es erst nach ein paar Minuten nochmal.
var/check_mk/notify/corrupted/ Defekte Spooldateien werden hierher verschoben.
share/check_mk/notifications Von Check_MK mitgelieferte Alarmierungsskripten. Ändern Sie hier nichts.
local/share/check_mk/notifications Ablageort für eigene Alarmierungsskripten. 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 Hier finden Sie einige Alarmierungsskripten, die Sie geringfügig anpassen und verwenden können.

12.2. Logdateien des SMTP-Diensts

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

Pfad Bedeutung
/var/log/mail.log Logdatei des SMTP-Servers unter Debian und Ubuntu
/var/log/mail Logdatei des SMTP-Servers unter SUSE LINUX (SLES)
/var/log/maillog Logdatei des SMTP-Servers unter Red Hat