Die Event Console

Wie immer in Checkmk, müssen Sie zuerst Änderungen aktivieren, damit diese wirksam werden. Das ist nicht von Nachteil: Denn so können Sie bei Änderungen, die mehrere zusammengehörige Regeln betreffen, genau festlegen, wann diese „live“ gehen sollen. Und Sie können mit dem Event Simulator zuvor testen, ob alles passt.

Klicken Sie zuerst rechts oben auf der Seite auf die Zahl der aufgelaufenen Änderungen.

Klicken Sie anschließend auf Activate on selected sites um die Änderung zu aktivieren. Die Event Console ist so konstruiert, dass diese Aktion absolut unterbrechungsfrei abläuft. Der Empfang von eingehenden Meldungen wird zu jeder Zeit sichergestellt, so dass durch den Prozess keine Meldungen verlorengehen können.

Das Aktivieren von Änderungen in der EC ist nur Administratoren erlaubt. Gesteuert wird das über die Berechtigung Activate changes for event console.

Für das Testen könnten Sie jetzt natürlich Meldungen per Syslog oder SNMP senden. Das sollten Sie später auch tun. Für einen ersten Test ist aber der in der EC eingebaute Event Simulator praktischer:

Hier haben Sie zwei Möglichkeiten: Try out berechnet anhand der simulierten Meldung, welche der Regeln matchen würden. Befinden Sie sich in der obersten Ebene der Setup-GUI für die EC, so werden die Regelpakete markiert. Befinden Sie sich innerhalb eines Regelpakets, so werden die einzelnen Regeln markiert. Jedes Paket bzw. jede Regel wird mit einem der folgenden drei Symbole gekennzeichnet:

Ein Klick auf Generate event macht fast das Gleiche wie Try out, nur wird jetzt die Meldung tatsächlich erzeugt. Eventuell definierte Aktionen werden tatsächlich ausgeführt. Und das Event taucht dann auch in den offenen Events im Monitoring auf. Den Quelltext der erzeugten Meldung sehen Sie in der Bestätigung:

Das so erzeugte Event taucht im Monitor-Menü unter Event Console > Events auf:

Für einen ersten echten Test über das Netzwerk können Sie sehr einfach von einem anderen Linux-Rechner aus per Hand eine Syslog-Meldung versenden. Da das Protokoll so einfach ist, brauchen Sie dafür nicht einmal ein spezielles Programm, sondern können die Daten einfach per netcat oder nc via UDP versenden. Der Inhalt des UDP-Pakets besteht aus einer Zeile Text. Wenn diese einem bestimmten Aufbau entspricht, werden die Bestandteile von der Event Console sauber zerlegt:

Sie können aber auch einfach irgendetwas senden. Die EC wird das dann trotzdem annehmen und einfach als Meldungstext auswerten. Zusatzinformation wie z.B. die Anwendung, die Priorität etc. fehlen dann natürlich. Als Status wird zur Sicherheit CRIT angenommen:

Innerhalb der Checkmk Instanz, auf der die EC läuft, gibt es eine named Pipe, in die Sie Textmeldungen lokal per echo schreiben können. Dies ist eine sehr einfache Methode, um eine lokale Anwendung anzubinden und ebenfalls eine Möglichkeit, das Verarbeiten von Meldungen zu testen:

Auch hier ist es übrigens möglich, im Syslog-Format zu senden, damit alle Felder des Events sauber befüllt werden.

Das Kommando Update & Acknowledge blendet den folgenden Bereich oberhalb der Event-Liste ein:

Mit dem Knopf Update können Sie in einem einzigen Arbeitsschritt einen Kommentar an das Event hängen, eine Kontaktperson eintragen und das Event quittieren. Das Feld Change contact ist bewusst Freitext. Hier können Sie auch Dinge wie Telefonnummern eintragen. Das Feld hat insbesondere keinen Einfluss auf die Sichtbarkeit des Events in der GUI. Es ist ein reines Kommentarfeld.

Die Checkbox Set event to acknowledged führt dazu, dass das Event von der Phase open übergeht nach acknowledged und fortan als handled gilt. Dies ist analog zu dem Quittieren von Host-und Service-Problemen.

Ein späteres erneutes Aufrufen des Kommando mit nicht gesetzter Checkbox entfernt die Quittierung wieder.

Das Kommando Change State erlaubt den manuellen Zustandswechsel von Events — z.b. von CRIT auf WARN.

Mit dem Kommando Custom Action können Sie auf Events frei definierbare Aktionen ausführen lassen. Zunächst ist nur die Aktion Send monitoring notification verfügbar. Diese sendet eine Checkmk Benachrichtigung, die genauso behandelt wird wie die von einem aktiv überwachten Service. Diese durchläuft die Benachrichtigungsregeln und führt dann entsprechend zu E-Mails, SMS oder was auch immer Sie konfiguriert haben. Einzelheiten zur Benachrichtigung durch die EC erfahren Sie weiter unten.

Das Kommando Archive Event löscht das Event endgültig aus der Liste der offenen Events. Da alle Aktionen auf Events — inklusive dieses Löschvorgangs — auch im Archiv aufgezeichnet werden, können Sie später immer noch auf alle Informationen des Events zugreifen. Deswegen sprechen wir nicht von Löschen, sondern von Archivieren.

Das Archivieren von einzelnen Events erreichen Sie auch aus der Event-Liste bequem über das Symbol .

Für die Sichtbarkeit von Hosts und Services im Monitoring für normale Benutzer werden von Checkmk Kontaktgruppen verwendet. Diese werden per Setup-GUI, Regel oder Ordnerkonfiguration den Hosts und Service zugeordnet.

Nun ist es aber bei der Event Console so, dass so eine Zuordnung von Events zu Kontaktgruppen erst einmal nicht existiert. Denn im Vorhinein ist gar nicht bekannt, welche Meldungen überhaupt empfangen werden können. Nicht einmal die Liste der Hosts ist bekannt, denn die Sockets für Syslog und SNMP sind ja von überall aus erreichbar. Deswegen gibt es bei der Sichtbarkeit in der Event Console ein paar Besonderheiten.

Zunächst einmal gibt es bei der Konfiguration der Benutzerrollen die Berechtigung Event Console > See all events. Diese ist per Default an, so dass auch normale Benutzer alle Events sehen dürfen! Dies ist bewusst so eingestellt, damit nicht aufgrund fehlerhafter Konfiguration wichtige Fehlermeldungen unter den Tisch fallen. Der erste Schritt zu einer genaueren Steuerung der Sichtbarkeit ist also das Entfernen dieser Berechtigung aus der Rolle user.

Damit die Sichtbarkeit von Events möglichst konsistent mit dem übrigen Monitoring ist, versucht die Event Console so gut wie möglich die Hosts, von denen sie Events empfängt, ihren per Setup-GUI konfigurierten Hosts zuzuordnen. Was einfach klingt ist trickreich im Detail. Denn teils fehlt im Event eine Angabe zum Host-Namen und nur die IP-Adresse ist bekannt. In anderen Fällen hat der Host-Name eine andere Schreibweise als in der Setup-GUI.

Die Zuordnung erfolgt konkret wie folgt:

Sie können die Zuordnung an einer Stelle beeinflussen: Falls nämlich in der Regel Kontaktgruppen definiert sind und der Host zugeordnet werden konnte, hat normalerweise die Zuordnung Vorrang. Dies können Sie in einer Regel mit der Option Precedence of contact groups umstellen:

Zudem können Sie direkt in der Regel Einstellungen für die Benachrichtigung vornehmen. Dies ermöglicht es, die Art des Events gegenüber den regulären Zuständigkeiten für einen Host zu priorisieren.

Sowohl bei den Regelpaketen  …​

…  als auch bei den einzelnen Regeln  …​

… finden Sie in der Spalte Hits die Angabe, wie oft das Paket bzw. die Regel schon auf eine Meldung gepasst hat. Dies hilft Ihnen zum einen dabei, unwirksame Regeln zu eliminieren oder zu reparieren. Aber auch bei Regeln, die sehr oft matchen, kann dies interessant sein. Für die optimale Performance der EC sollten diese möglichst am Anfang der Regelkette stehen. So können Sie die Anzahl von Regeln reduzieren, die die EC bei jeder Meldung ausprobieren muss.

Die Zählerstände können Sie jederzeit mit dem Menüpunkt Event Console > Reset counters zurücksetzen.

Beim Ausprobieren einer Regel haben Sie schon gesehen, wie Sie mit dem Event Simulator die Auswertungen Ihrer Regeln prüfen können. Ähnliche Informationen bekommen Sie zur Laufzeit für alle Meldungen, wenn Sie in den Einstellungen der Event Console den Wert von Debug rule execution auf on umstellen.

Die Log-Datei der Event Console finden Sie unter var/log/mkeventd.log. Für jede Regel, die geprüft wird, aber nicht greift, erfahren Sie den genauen Grund:

Es versteht sich wohl von selbst, dass Sie dieses intensive Logging nur bei Bedarf und mit Bedacht verwenden sollten. Bei einer nur etwas komplexeren Umgebung werden Unmengen von Daten erzeugt!

Bei allen Bedingungen, die Textfelder betreffen, wird der Vergleichstext grundsätzlich als regulärer Ausdruck behandelt. Der Vergleich findet hier immer ohne Unterscheidung von Groß-/Kleinschreibung statt. Letzteres ist eine Ausnahme von Checkmk Konventionen in anderen Modulen. Es macht aber das Formulieren der Regeln robuster. Auch sind gerade Host-Namen in Events nicht unbedingt konsistent in ihrer Schreibweise, falls diese nicht zentral, sondern auf jedem Host selbst konfiguriert werden. Daher ist diese Ausnahme hier sehr sinnvoll.

Ferner gilt immer ein Infix-Match — also eine Überprüfung auf ein Enthaltensein des Suchtextes. Ein .* am Anfang oder am Ende des Suchtexts können Sie sich also sparen.

Davon gibt es allerdings eine Ausnahme: Wird beim Match auf den Host-Namen kein regulärer Ausdruck verwendet, sondern ein fester Host-Name, so wird dieser auf exaktes Übereinstimmen geprüft und nicht auf ein Enthaltensein.

Achtung: Sobald der Suchtext einen Punkt enthält, wird dieser als regulärer Ausdruck gewertet und es gilt die Infix-Suche. myhost.de matcht dann auch z.B. auf notmyhostide!

Sehr wichtig und nützlich ist hier das Konzept Match-Gruppen beim Feld Text to match. Damit sind die Textabschnitte gemeint, die beim Matchen mit geklammerten Ausdrücken im regulären Ausdruck übereinstimmen.

Nehmen Sie an, Sie möchten folgende Art von Meldung in der Log-Datei einer Datenbank überwachen:

Das WP41 ist dabei natürlich variabel und Sie möchten sicher nicht für jede unterschiedliche Instanz ein eigene Regel formulieren. Daher verwenden Sie im regulären Ausdruck .*, was für eine beliebige Zeichenfolge steht:

Database instance .* has failed

Wenn Sie jetzt den variablen Teil in runde Klammern setzen, wird sich die Event Console den tatsächlichen Wert beim Matchen für weitere Aktionen merken (capturing):

Database instance (.*) has failed

Nach einem erfolgreichen Match der Regel ist jetzt die erste Match-Gruppe auf den Wert WP41 gesetzt (oder welche Instanz auch immer den Fehler produziert hat).

Diese Match-Gruppen können Sie im Event Simulator sehen, wenn Sie mit der Maus über die grüne Kugel fahren:

Auch in den Details des erzeugten Events können Sie die Gruppen sehen:

Die Match-Gruppen finden unter anderem Anwendung bei:

An dieser Stelle noch ein Tipp: Es gibt Situationen, in denen Sie im regulären Ausdruck etwas gruppieren müssen, aber keine Match-Gruppe erzeugen möchten. Dies können Sie durch ein ?: direkt nach der öffnenden Klammer erreichen. Beispiel: Der Ausdruck one (.*) two (?:.*) three erzeugt bei einem Match auf one 123 two 456 three nur die eine Match-Gruppe 123.

Im Feld Match original source IP address können Sie auf die IPv4-Adresse des Senders der Meldung matchen. Geben Sie entweder eine exakte Adresse an oder ein Netzwerk in der Notation X.X.X.X/Y, also z.B. 192.168.8.0/24, um alle Adressen im Netzwerk 192.168.8.X zu matchen.

Beachten Sie, dass der Match auf die IP-Adresse nur dann funktioniert, wenn die überwachten Systeme direkt an die Event Console senden. Ist noch ein anderer Syslog-Server dazwischen geschaltet, der die Meldungen weiterleitet, wird stattdessen dessen Adresse als Absender in der Meldung erscheinen.

Die Felder Match syslog priority und Match syslog facility sind ursprünglich von Syslog definierte, standardisierte Informationen. Intern wird dabei ein 8-Bit-Feld in 5 Bits für die Facility (ergibt 32 Möglichkeiten) und 3 Bits für die Priorität (8 Möglichkeiten) aufgeteilt.

Die 32 vordefinierten Facilities waren mal für so etwas wie eine Anwendung gedacht. Nur ist die Auswahl damals nicht sehr zukunftsweisend gemacht worden. Eine der Facilities ist z.B. uucp — ein Protokoll das schon in den 90er Jahren des vergangenen Jahrtausends kaum noch verwendet wurde.

Fakt ist aber, dass jede Meldung, die per Syslog kommt, eine der Facilities trägt. Teilweise können Sie diese beim Senden auch frei vergeben, um später darauf gezielt zu filtern. Das ist durchaus nützlich.

Die Verwendung von Facility und Priorität hat auch einen Performance-Aspekt. Wenn Sie eine Regel definieren, die sowieso nur auf Meldungen greift, die alle die gleiche Facility oder Priorität haben, sollten Sie diese zusätzlich in den Filtern der Regel setzen. Die Event Console kann diese Regeln dann sehr effizient sofort umgehen, wenn eine Meldung mit abweichenden Werten eingeht. Je mehr Regeln diese Filter gesetzt haben, desto weniger Regelvergleiche werden benötigt.

Die Checkbox Negate match: Execute this rule if the upper conditions are not fulfilled. führt dazu, dass die Regel genau dann greift, wenn die Bedingungen nicht alle erfüllt sind. Dies ist eigentlich nur nützlich im Zusammenhang mit zwei Regelarten (Rule type im Kasten Outcome & Action der Regel):

Zu den Regelpaketen erfahren Sie weiter unten mehr.

Wenn eine Regel matcht, legt sie fest, was mit der Meldung geschehen soll. Das geschieht im Kasten Outcome & Action:

Mit dem Rule type kann die Auswertung an der Stelle ganz oder für das aktuelle Regelpaket abgebrochen werden. Gerade die erste Möglichkeit sollten Sie nutzen, um den größten Teil des nutzlosen „Rauschens“ durch ein paar gezielte Regeln ganz am Anfang loszuwerden. Nur bei den „normalen“ Regeln werden die anderen Optionen in diesem Kasten überhaupt ausgewertet.

Mit State legt die Regel den Monitoring-Status des Events fest. In der Regel wird diese WARN oder CRIT sein. Regeln, die OK-Events erzeugen, können in Ausnahmen interessant sein, um bestimmte Ereignisse rein informativ darzustellen. Hier ist dann eine Kombination mit einem automatischen Herausaltern dieser Events interessant.

Neben dem Festlegen eines expliziten Status gibt es noch zwei dynamischere Möglichkeiten. Die Einstellung (set by syslog) übernimmt die Einstufung anhand der Syslog-Priorität. Dies funktioniert allerdings nur, wenn die Meldung bereits vom Absender nutzbar klassifiziert wurde. Meldungen, die direkt per Syslog empfangen wurden, enthalten eine von acht per RFC festgelegten Prioritäten, die wie folgt abgebildet werden:

Neben Syslog-Meldungen bieten auch Meldungen aus dem Windows Event Log und Meldungen aus Textdateien, die bereits mit dem Checkmk Plugin Logwatch auf dem Zielsystem klassifiziert wurden, vorbereitete Zustände. Bei SNMP-Traps gibt es diese leider nicht.

Eine ganze andere Methode ist, die Einstufung der Meldung anhand des Texts selbst zu machen. Dies geht mit der Einstellung (set by message text):

Der Match auf die hier konfigurierten Texte geschieht erst, nachdem auf Text to match und auf die anderen Regelbedingungen geprüft wurde. Diese müssen Sie also hier nicht wiederholen.

Falls keines der konfigurierten Patterns gefunden wird, nimmt das Event den Zustand UNKNOWN an.

Hinter dem Feld Service Level steckt die Idee, dass jeder Host und jeder Service im Unternehmen eine bestimmte Wichtigkeit hat. Damit kann eine konkrete Service-Vereinbarung verbunden sein. In Checkmk können Sie per Regeln Ihren Hosts und Services solche Level zuordnen und dann z.B. die Benachrichtigung oder selbst definierte Dashboards davon abhängig machen.

Da Events erst einmal nicht unbedingt mit Hosts oder Services korrelieren, erlaubt die Event Console, dass Sie einem Event per Regel ebenfalls einen Service-Level zuordnen. Sie können die Event-Ansichten dann später nach diesem Level filtern.

Ab Werk definiert Checkmk die vier Level 0 (kein Level), 10 (Silber), 20 (Gold) und 30 (Platin). Diese Auswahl können Sie in den Global settings > Notifications > Service Levels beliebig anpassen. Entscheidend sind hierbei die Zahlen der Levels, dann nach diesen werden sie sortiert und auch nach der Wichtigkeit verglichen.

Die Kontaktgruppen für die Sichtbarkeit werden auch bei der Benachrichtigung von Events verwendet. Sie können hier per Regel Events explizit Kontaktgruppen zuordnen. Einzelheiten erfahren Sie im Kapitel über das Monitoring.

Aktionen sind den Alert Handlers für Hosts und Services sehr ähnlich. Hier können Sie beim Öffnen eines Events ein selbst definiertes Skript ausführen lassen. Alle Einzelheiten zu den Aktionen erfahren Sie weiter unten in einem eigenen Abschnitt.

Das automatische Löschen (= Archivieren), welches Sie mit Delete event immediately after the actions einstellen können, sorgt letztlich dafür, dass ein Event im Monitoring überhaupt nicht sichtbar wird. Das ist dann sinnvoll, wenn Sie lediglich automatisch Aktionen auslösen oder nur bestimmte Events archivieren möchten, damit Sie später danach recherchieren können.

Sie können beim Aufheben eines Events auch automatisch Aktionen ausführen lassen. Dazu ist es wichtig zu wissen, dass beim Aufheben etliche Datenfelder des Events von Werten der OK-Meldung überschrieben werden, bevor die Aktionen ausgeführt werden. Auf diese Art sind im Aktionsskript dann die Daten der OK-Meldung vollständig verfügbar. Auch ist während dieser Phase der Zustand des Events als OK eingetragen. Auf diese Art kann ein Aktionsskript ein Aufheben erkennen und Sie können das gleiche Skript für Fehler und OK-Meldung verwenden (z.B. bei der Anbindung an ein Ticketsystem).

Folgende Felder werden aus Daten der OK-Meldung überschrieben:

Alle anderen Felder bleiben unverändert — inklusive der Event-ID.

Falls Sie in der gleichen Regel mit Umschreiben und Aufheben arbeiten, so sollten Sie vorsichtig sein beim Umschreiben des Host-Namens oder der Application. Beim Aufheben prüft die EC stets, ob die aufhebende Meldung zu Host-Name und Anwendung des offenen Events passt. Wenn diese aber umgeschrieben wurden, würde das Aufheben nie funktionieren.

Daher simuliert die Event Console vor dem Aufheben ein Umschreiben von Host-Name und Anwendung (application), um so die relevanten Texte zu vergleichen. Das ist wahrscheinlich das, was Sie auch erwarten würden.

Dieses Verhalten können Sie auch ausnutzen, wenn das Anwendungsfeld bei der Fehlermeldung und der späteren OK-Meldung nicht übereinstimmen. Schreiben Sie in diesem Fall einfach das Anwendungsfeld in einen bekannten festen Wert um. Das führt faktisch dazu, dass dieses Feld beim Aufheben ignoriert wird.

Es gibt (leider) Fälle, in denen der Text der Fehler- und OK-Meldung absolut identisch ist. Meist ist der eigentliche Status dann nicht im Text, sondern in der Syslog-Priorität kodiert.

Dazu gibt es die Option Syslog priority to cancel event. Geben Sie hier z.B. den Bereich debug …​ notice an. Alle Prioritäten in diesem Bereich werden normalerweise als OK-Status gewertet. Bei Verwendung dieser Option sollten Sie trotzdem in das Feld Text to cancel event(s) einen passenden Text eintragen. Sonst wird die Regel auf alle OK-Meldungen matchen, welche die gleiche Anwendung betreffen.

Das Prüfen auf zu oft auftretende Meldungen aktivieren Sie mit der Option Count messages in interval:

Hier geben Sie zunächst einen Zeitraum bei Time period for counting und eine Anzahl von Meldungen bei Count until triggered vor, die zum Öffnen eines Events führen sollen. Im Beispiel in der Abbildung ist das auf 10 Meldungen pro Stunde eingestellt. Natürlich handelt es sich dabei nicht um 10 beliebige Meldungen, sondern um solche, die von der Regel gematcht werden.

Normalerweise ist es hier aber sinnvoll, nicht einfach global alle passenden Meldungen zu zählen, sondern nur diejenigen, die sich auf die gleiche „Ursache“ beziehen. Um das zu steuern, gibt es die drei Checkboxen mit dem Titel Force separate events for different …​. Diese sind so voreingestellt, dass Meldungen nur dann zusammengezählt werden, wenn sie übereinstimmen in:

Damit können Sie Regeln formulieren wie „Wenn vom gleichen Host, der gleichen Anwendung und dort der gleichen Instanz mehr als 10 Meldungen pro Stunde kommen, dann…​“. Dadurch kann es dann auch sein, dass aufgrund der Regel mehrere unterschiedliche Events erzeugt werden.

Wählen Sie z.B. alle drei Checkboxen ab, so wird nur noch global gezählt und die Regel kann auch nur insgesamt ein einziges Event generieren!

Es kann übrigens durchaus sinnvoll sein, als Anzahl eine 1 einzutragen. Damit können Sie „Event-Stürme“ effektiv in den Griff bekommen. Kommen z.B. in kurzer Zeit 100 Meldungen der gleichen Art, so wird dafür dann trotzdem nur ein einziges Event erzeugt. Sie sehen dann in den Event-Details

Wann der Fall dann „abgeschlossen“ ist und bei erneuten Meldungen wieder ein neues Event aufgemacht werden soll, legen Sie über zwei Checkboxen fest. Normalerweise führt eine Quittierung des Events dazu, dass bei weiteren Meldungen eine neue Zählung mit einem neuen Event angefangen wird. Das können Sie mit Continue counting when event is acknowledged abschalten.

Die Option Discontinue counting after time has elapsed sorgt dafür, dass für jeden Vergleichszeitraum immer ein separates Event geöffnet wird. In obigem Beispiel war eine Schwelle von 10 Meldungen pro Stunde eingestellt. Ist diese Option aktiviert, so werden auf ein bereits geöffnetes Event maximal 10 Meldungen einer Stunde aufgerechnet. Sobald die Stunde abgelaufen ist, wird (bei ausreichender Zahl von Meldungen) wieder ein neues Event geöffnet.

Setzen Sie z.B. die Anzahl auf 1 und das Zeitintervall auf einen Tag, so werden Sie pro Tag von diesem Meldungstyp nur noch maximal ein Event sehen.

Die Einstellung Algorithm ist auf den ersten Blick vielleicht etwas überraschend. Aber mal ehrlich: Was meint man eigentlich mit „10 Meldungen pro Stunde“? Welche Stunde ist damit gemeint? Immer volle Stunden der Tageszeit? Dann könnte es sein, dass in der letzten Minute einer Stunde neun Meldungen kommen und in der ersten Minute der nächsten nochmal neun. Macht insgesamt 18 Meldungen in zwei Minuten. Aber trotzdem weniger als 10 pro Stunde und die Regel würde nicht greifen. Das klingt nicht so sinnvoll  …​

Weil es dazu nicht nur eine einzige Lösung gibt, bietet Checkmk drei verschiedene Definitionen an, was denn „10 Meldungen pro Stunde“ genau bedeuten soll:

Welchen Algorithmus sollten Sie also wählen?

Events, die die eingestellte Anzahl noch nicht erreicht haben, sind latent schon vorhanden aber für den Operator nicht automatisch sichtbar. Sie befinden sich in der Phase counting. Sie können solche Events mit dem Filter Phase in der Event-Ansicht sichtbar machen:

Genauso wie das Eingehen einer bestimmten Meldung kann auch das Ausbleiben ein Problem bedeuten. Eventuell erwarten Sie pro Tag mindestens eine Meldung von einem bestimmten Job. Bleibt diese aus, ist der Job wahrscheinlich nicht gelaufen und sollte dringend repariert werden.

So etwas können Sie unter Counting & Timing > Expect regular messages konfigurieren:

Wie beim Zählen müssen Sie auch hier einen Zeitraum angeben, in dem Sie die Meldung(en) erwarten. Hier kommt allerdings ein ganz anderer Algorithmus zur Anwendung, der an dieser Stelle viel sinnvoller ist. Der Zeitraum wird hier nämlich immer exakt an definierten Stellen ausgerichtet. So wird z.B. beim Interval hour immer bei Minute und Sekunde Null begonnen. Sie haben folgende Optionen:

Warum ist das so kompliziert? Das soll Fehlalarme vermeiden. Erwarten Sie z.B. eine Meldung vom Backup pro Tag? Sicher wird es leichte Unterschiede in der Laufzeit des Backups geben, so dass die Meldungen nicht exakt 24 Stunden auseinander liegen. Erwarten Sie die Meldung z.B. ungefähr gegen Mitternacht plus/minus ein oder zwei Stunden, so ist ein Intervall von 12:00 bis 12:00 Uhr viel robuster, als eines von 00:00 bis 00:00 Uhr. Allerdings bekommen Sie dann auch erst um 12:00 Uhr eine Benachrichtigung, wenn die Meldung ausbleibt.

Die Option Merge with open event ist so voreingestellt, dass bei einem mehrfachen hintereinander Ausbleiben der gewünschten Meldung, das bestehende Event aktualisiert wird. Dies können Sie so umschalten, dass jedes Mal ein neues Event aufgemacht wird.

Mit dem Knopf Add new action legen Sie eine neue Aktion an. Folgendes Beispiel zeigt, wie Sie ein einfaches Shell-Skript als Aktion vom Typ Execute Shell Script anlegen können. Dem Skript stehen über Umgebungsvariablen Details zu den Events zur Verfügung, beispielsweise die $CMK_ID des Events, der $CMK_HOST, Volltext $CMK_TEXT oder die erste Match-Gruppe als $CMK_MATCH_GROUP_1. Eine vollständige Liste der verfügbaren Umgebungsvariablen erhalten Sie in der Inline-Hilfe.

Ältere Versionen von Checkmk haben neben Umgebungsvariablen auch Makros wie $TEXT$ erlaubt, die vor Ausführung des Skriptes ersetzt wurden. Wegen der Gefahr, dass ein Angreifer über ein eigens angefertigtes UDP-Paket Befehle einschleusen kann, die mit den Rechten des Checkmk Prozesses ausgeführt werden, sollten Sie von Makros keinen Gebrauch machen. Makros sind derzeit noch aus Kompatibilitätsgründen erlaubt, jedoch behalten wir uns die Entfernung in einer künftigen Checkmk Version vor.

Das Beispielskript aus dem Screenshot legt im Instanzverzeichnis die Datei tmp/test.out an und schreibt dort einen Text mit den konkreten Werten der Variablen zu dem jeweils letzten Event:

Die Skripte werden unter folgender Umgebung ausgeführt:

Sollte Ihr Skript eventuell Wartezeiten enthalten, können Sie es mithilfe von Linux' at-Spooler asynchron laufen lassen. Dazu legen Sie das Skript in einer eigenen Datei local/bin/myaction an und starten es mit dem at-Befehl, z.B.:

Der Aktionstyp Send Email versendet eine einfache Text-E-Mail. Eigentlich könnten Sie das auch über den Umweg mit einem Skript erreichen, in dem Sie z.B. mit dem Kommandozeilenbefehl mail arbeiten. Aber so ist es komfortabler. Bitte beachten Sie, dass auch in den Feldern Recipient E-Mail address und Subject Platzhalter erlaubt sind.

Events können von beliebigen Hosts kommen — egal, ob diese im aktiven Monitoring konfiguriert sind oder nicht. Schließlich steht der Syslog- und SNMP-Port allen Hosts im Netzwerk offen. Daher stehen die erweiterten Host-Attribute wie Alias, Host-Merkmale, Kontakte usw. erst einmal nicht zur Verfügung. Das bedeutet insbesondere, dass Bedingungen in Benachrichtigungsregeln nicht unbedingt so funktionieren, wie Sie das erwarten würden.

Daher versucht die EC bei der Benachrichtigung einen zum Event passenden Host aus dem aktiven Monitoring zu finden. Dabei wird das gleiche Verfahren wie bei der Sichtbarkeit von Events angewandt. Kann so ein Host gefunden werden, so werden von diesem folgende Daten übernommen:

Dadurch kann es dazu kommen, dass der Host-Name in der Benachrichtigung nicht exakt mit dem Host-Namen aus der ursprünglichen Meldung übereinstimmt. Die Anpassung auf die Schreibweise des aktiven Monitorings vereinfacht aber das Formulieren von einheitlichen Benachrichtigungsregeln, welche Bedingungen auf den Host-Namen enthalten.

Die Zuordnung geschieht in Echtzeit durch eine Livestatus-Abfrage an den Monitoring-Kern, welcher in der gleichen Instanz wie die EC läuft, die die Meldung empfangen hat. Das klappt natürlich nur, wenn die Syslog-Meldungen, SNMP-Traps usw. immer an diejenige Checkmk Instanz gesendet werden, auf der der Host auch aktiv überwacht wird!

Falls die Abfrage nicht klappt oder der Host nicht gefunden werden kann, werden Ersatzdaten angenommen:

Wenn der Host im aktiven Monitoring nicht zugeordnet werden kann, kann das natürlich zu Problemen bei der Benachrichtigung führen. Zum einen wegen der Bedingungen, die dann eventuell nicht mehr greifen, zum anderen wegen der Kontaktauswahl. Für solche Fälle können Sie Ihre Benachrichtigungsregeln so anpassen, dass Benachrichtigungen aus der Event Console mit einer eigenen Regel gezielt behandelt werden. Dazu gibt es eine eigene Bedingung, mit der Sie entweder positiv nur auf EC-Benachrichtigungen matchen oder umgekehrt diese ausschließen können:

Damit Benachrichtigungen aus der EC das Benachrichtigungssystem des aktiven Monitorings durchlaufen können, muss sich die EC an dessen Schema anpassen. Dabei werden die typischen Datenfelder einer Benachrichtigung so sinnvoll wie möglich gefüllt. Wie die Daten des Hosts ermittelt werden, haben wir gerade beschrieben. Weitere Felder sind:

Wie oben beschrieben, können zu einem Event eventuell nicht die passenden Kontakte automatisch ermittelt werden. Für solche Fälle können Sie direkt in der EC-Regel Kontaktgruppen angeben, welche für die Benachrichtigung verwendet werden sollen. Wichtig ist, dass Sie den Haken bei Use in notifications nicht vergessen:

Im Snapin Master control gibt es einen zentralen Schalter für Benachrichtigungen. Dieser gilt auch für Benachrichtigungen, die von der EC weitergeleitet werden:

Ebenso wie die Host-Zuordnung erfordert die Abfrage des Schalters durch die EC einen Livestatus-Zugriff auf den lokalen Monitoring-Kern. Eine erfolgreiche Abfrage sehen Sie in der Log-Datei der Event Console:

Die Event Console erkennt Hosts, die gerade in einer Wartungszeit sind und versendet in diesem Fall keine Benachrichtigungen. In der Log-Datei sieht das so aus:

Auch das setzt natürlich ein erfolgreiches Finden des Hosts im aktiven Monitoring voraus. Falls dies nicht gelingt, wird angenommen, dass sich der Host nicht in Wartung befindet und die Benachrichtigung auf jeden Fall generiert.

Falls Sie ein eigenes Benachrichtigungsskript schreiben, haben Sie speziell bei Benachrichtigungen, die aus der Event Console kommen, etliche zusätzliche Variablen zur Verfügung, die den ursprünglichen Event beschreiben (Zugriff wie gewohnt mit Präfix NOTIFY_):

Zum Messen Ihrer Performance gibt es ein eigenes Snapin für die Seitenleiste mit dem Namen Event Console Performance. Dieses können Sie wie gewohnt mit einbinden:

Die hier dargestellten Werte sind Mittelwerte über etwa die letzte Minute. Einen Event-Sturm, der nur ein paar Sekunden dauert, können Sie hier also nicht direkt ablesen, aber dadurch sind die Zahlen etwas geglättet und daher besser zu lesen.

Um die maximale Performance zu testen, können Sie künstlich einen Sturm von unklassifizierten Meldungen erzeugen (bitte nur im Testsystem!), indem Sie z.B. in einer Shell-Schleife fortwährend den Inhalt einer Textdatei in die Events Pipe schreiben:

Die wichtigsten Messwerte aus dem Snapin haben folgende Bedeutung:

Wie viele Meldungen die Event Console pro Sekunde verarbeiten kann, können Sie in etwa an der Processing time per message ablesen. Generell hängt diese Zeit damit zusammen, wie viele Regeln probiert werden müssen, bis eine Meldung verarbeitet wird. Sie haben verschiedene Möglichkeiten, hier zu optimieren:

Weiterhin gibt es in der EC eine Optimierung, die auf der Syslog-Priorität und -Facility basiert. Dazu wird für jede Kombination von Priorität und Facility intern eine eigene Regelkette gebildet, in die jeweils nur solche Regeln aufgenommen werden, die für Meldungen dieser Kombination relevant sind.

Jede Regel, die eine Bedingung auf die Priorität, die Facility oder am besten auf beides enthält, kommt dann nicht mehr in alle diese Regelketten, sondern optimalerweise nur in eine einzige. Das bedeutet, dass diese Regel bei Meldungen mit einer anderen Syslog-Klassifizierung gar nicht überprüft werden muss.

Im ~/var/log/mkeventd.log sehen Sie nach einem Neustart eine Übersicht der optimierten Regelketten:

In obigem Beispiel sehen Sie, dass es 67 Regeln gibt, die in jedem Fall geprüft werden müssen. Bei Meldungen der Facility daemon sind 89 Regeln relevant, nur bei der Kombination daemon/emerg müssen 120 Regeln geprüft werden. Jede Regel, die eine Bedingung auf Priorität oder Facility bekommt, reduziert die Anzahl von 67 weiter.

Natürlich können Sie diese Bedingungen nur dann setzen, wenn Sie sicher sind, dass sie von den relevanten Meldungen auch erfüllt werden!

Die Event Console besitzt einen automatischen Schutz vor einem „Überlaufen“. Dieser limitiert die Anzahl von aktuellen Events pro Host, pro Regel und global. Dabei werden nicht nur offene Events gezählt, sondern auch solche in anderen Phasen, wie z.B. delayed oder counting. Archivierte Events werden nicht gezählt.

Dies schützt Sie in Situationen, in denen aufgrund eines systematischen Problems in Ihrem Netzwerk Tausende von kritischen Events hereinströmen und die Event Console „dicht“ machen würde. Zum einen verhindert das Performance-Einbrüche der Event Console, die zu viele Events im Hauptspeicher halten müsste. Zum anderen bleibt so die Übersicht für den Operator (einigermaßen) bewahrt und Events, die nicht Teil des Sturms sind, bleiben sichtbar.

Sobald ein Limit erreicht ist, geschieht eine der folgenden Aktionen:

Die Limits sowie die verknüpfte Auswirkung beim Erreichen stellen Sie in den Einstellungen der Event Console mit Limit amount of current events ein. Folgende Abbildung zeigt die Voreinstellung:

Falls Sie einen Wert mit …​create overflow event aktiviert haben, wird beim Erreichen des Limits ein künstliches Event erzeugt, das den Operator von der Fehlersituation in Kenntnis setzt:

Falls Sie zusätzlich einen Wert mit …​notify contacts aktiviert haben, werden passende Kontaktpersonen per Checkmk Benachrichtigung informiert. Die Benachrichtigung durchläuft die Benachrichtigungsregeln von Checkmk. Diese Regeln müssen sich nicht unbedingt an die Kontaktauswahl der Event Console halten, sondern können diese modifizieren. Folgende Tabelle zeigt, welche Kontakte ausgewählt werden, falls Sie Notify all contacts of the notified host or service eingestellt haben (was der Default ist):