Regeln

Nehmen wir als Beispiel die Konfiguration von Schwellwerten für WARN und CRIT bei der Überwachung von Dateisystemen. Bei einer an Datenbanken orientierten Konfiguration würde man in einer Tabelle für jedes Dateisystem eine Zeile anlegen:

Das ist einigermaßen übersichtlich — aber nur weil die Tabelle hier kurz ist. In der Praxis haben Sie eher Hunderte oder Tausende von Dateisystemen. Werkzeuge wie Copy & Paste und Bulk-Operationen können die Arbeit erleichtern, aber es bleibt ein Grundproblem: Wie können Sie hier eine Richtlinie (policy) erkennen und durchsetzen? Wie ist die generelle Regel? Wie sollen Schwellwerte für zukünftige Hosts eingestellt werden?

Eine regelbasierte Konfiguration hingegen besteht aus der Richtlinie! Die Logik der obigen Tabelle ersetzen wir durch einen Satz aus vier Regeln. Wenn wir davon ausgehen, dass myserver001 ein Testsystem ist, und dass für jedes Dateisystem die jeweils erste zutreffende Regel gilt, ergeben sich die gleichen Schwellwerte wie in der Tabelle von oben:

Zugegeben — bei nur zwei Hosts bringt das nicht viel. Aber wenn es nur ein paar mehr sind, wird der Mehraufwand schnell sehr groß. Die Vorteile der regelbasierten Konfiguration liegen auf der Hand:

Zusammengefasst also: weniger Arbeit — mehr Qualität! Und deswegen finden Sie Regeln bei Checkmk an allen Stellen, wo es irgendwie um Hosts oder Services geht: bei Schwellwerten, Monitoring-Einstellungen, Zuständigkeiten, Benachrichtigungen, Agentenkonfiguration und vielem mehr.

Im Setup von Checkmk werden Regeln in Regelsätzen organisiert. Jeder Regelsatz hat die Aufgabe, einen ganz bestimmten Parameter für Hosts oder Services festzulegen. In Checkmk gibt es über 700 Regelsätze! Hier einige Beispiele:

Jeder Regelsatz ist entweder für Hosts oder für Services zuständig — nie für beide. Wenn Parameter sowohl für Hosts als auch für Services einstellbar sind, gibt es jeweils ein Paar von Regelsätzen — z.B. Normal check interval for host checks und Normal check interval for services checks.

Einige Regelsätze legen genau genommen nicht Parameter fest, sondern erzeugen Services. Ein Beispiel sind die Regeln für aktive Checks, die Sie unter Setup > Services > HTTP, TCP, Email, …​ finden. Damit können Sie z.B. einen HTTP-Check für bestimmte Hosts einrichten. Diese Regeln gelten als Host-Regeln. Denn die Tatsache, dass so ein Check auf einem Host existiert, gilt als eine Eigenschaft des Hosts.

Ferner gibt es Regelsätze, welche die Service-Erkennung steuern. So können Sie z.B. über Windows service discovery festlegen, für welche Windows-Dienste automatisch Checks eingerichtet werden sollen, falls diese auf einem System gefunden werden. Auch dies sind Host-Regeln.

Der Großteil der Regelsätze legt Parameter für bestimmte Check-Plugins fest. Ein Beispiel ist Network interfaces and switch ports. Die Einstellungen in diesen Regeln sind sehr individuell auf das jeweilige Plugin zugeschnitten. Solche Regelsätze finden grundsätzlich nur bei denjenigen Services Anwendung, die auf diesem Check-Plugin basieren. Falls Sie unsicher sind, welcher Regelsatz für welche Services zuständig ist, navigieren Sie am besten direkt über den Service zur passenden Regel. Wie das geht, erfahren Sie später.

Eines haben wir bisher noch unterschlagen: In obigem Beispiel gibt es eine Regel für alle Testsysteme. Wo ist eigentlich festgelegt, welcher Host ein Testsystem ist?

So etwas wie Testsystem heißt bei Checkmk Host-Merkmal (englisch: host tag). Welche Merkmale es gibt, können Sie sich über Setup > Hosts > Tags anzeigen lassen. Einige Merkmale sind bereits vordefiniert — zum Beispiel für ein Test system, das in der Gruppe Criticality definiert ist.

Die Zuordnung zu den Hosts geschieht entweder explizit in den Eigenschaften des Hosts oder per Vererbung über die Ordnerhierarchie. Wie das geht, erfahren Sie im Artikel über die Hosts. Wie Sie eigene Merkmale anlegen können und was es mit den bereits vordefinierten Merkmalen auf sich hat, lesen Sie im Artikel über die Host-Merkmale.

Wenn Sie eine neue Regel anlegen möchten, die für einen oder mehrere Hosts einen Parameter definiert, dann gibt es mehrere Wege zum Ziel. Der direkte Weg geht über die entsprechende Gruppe im Setup-Menü, in diesem Fall also Setup > Hosts > Host monitoring rules:

In der folgenden Ansicht werden nun alle für das Host-Monitoring relevanten Regelsätze angezeigt. Die Zahlen hinter den Namen dieser Regelsätze zeigen die Anzahl der bereits definierten Regeln:

Etwas schneller können Sie allerdings über das Suchfeld an Ihr Ziel gelangen. Dazu müssen Sie natürlich ungefähr wissen, wie der Regelsatz heißt. Hier ist als Beispiel das Ergebnis einer Suche nach host checks.

Ein anderer Weg geht über den Menüpunkt Hosts > Effective parameters in den Eigenschaften eines vorhandenen Hosts im Setup oder über das Symbol in der Liste der Hosts eines Ordners.

Dort finden Sie nicht nur alle Regelsätze, die den Host betreffen, sondern auch den jeweils für diesen Host aktuell wirksamen Parameter. Im Beispiel von Host check command greift für den gezeigten Host keine Regel, und er steht deswegen auf Smart PING (only with Checkmk Micro Core), dem Standardwert in den kommerziellen Editionen. In Checkmk Raw ist der Standardwert PING (active check with ICMP echo request).

Klicken Sie auf Host Check Command, um den ganzen Regelsatz zu sehen.

Falls bereits eine Regel existiert, erscheint anstelle von Default Value die Nummer der Regel, welche diesen Parameter festlegt:

Ein Klick darauf bringt Sie direkt zu dieser Regel.

Der Weg zu den Regelsätzen für Services ist ähnlich. Der allgemeine Zugang geht auch hier über das Setup-Menü, in diesem Fall also Setup > Services > Service monitoring rules oder zweckmäßigerweise über das Suchfeld.

Wenn Sie nicht schon sehr geübt mit den Namen der Regelsätze sind, dann ist der Weg über den Service allerdings einfacher. Analog zu den Hosts gibt es auch hier eine Seite, auf der alle Parameter des Services dargestellt werden und Sie die Möglichkeit haben, die passenden Regelsätze direkt anzusteuern. Sie erreichen diese Parameterseite mit dem Symbol in der Liste der Services eines Hosts im Setup. Das Symbol bringt Sie direkt zu demjenigen Regelsatz, der die Parameter für das Check-Plugin des Services festlegt.

Das Symbol für die Parameterseite gibt es übrigens auch im Monitoring im Aktionsmenü jedes Services:

Im Setup-Menü finden Sie des Weiteren einen Eintrag für Enforced Services, d.h. für erzwungene Services. Wie der Name schon sagt, können Sie über diese Regelsätze erzwingen, dass Services bei Ihren Hosts angelegt werden. Einzelheiten dazu finden Sie im Artikel über die Services. Eine kleine Zahl von Regelsätzen — wie z.B. Simple checks for BIOS/Hardware errors — finden Sie ausschließlich unter den erzwungenen Services. Hierbei handelt es sich um Services, welche nicht durch die Service-Erkennung entstehen, sondern von Ihnen manuell angelegt werden.

In jeder der vorgenannten Auflistungen von Regelsätzen — sei es in den Host monitoring rules oder den Service monitoring rules — können Sie über Related > Used rulesets in der Menüleiste, nur genau die Regelsätze anzeigen lassen, in denen Sie mindestens eine Regel definiert haben. Dies ist oft ein bequemer Einstieg, wenn Sie Anpassungen an Ihren bestehenden Regeln vornehmen möchten. Einige der Regeln entstehen übrigens schon beim Anlegen der Checkmk-Instanz und sind Teil der Beispielkonfiguration. Auch diese werden hier angezeigt.

Monitoring ist eine komplexe Sache. Da kann es schon mal vorkommen, dass es Regeln gibt, welche bei keinem einzigen Host oder Service greifen — entweder, weil Sie einen Fehler gemacht haben oder weil die passenden Hosts und Services verschwunden sind. Solche wirkungslosen Regeln können Sie, in den vorgenannten Auflistungen von Regelsätzen, über Related > Ineffective rulesets in der Menüleiste anzeigen lassen.

Checkmk wird ständig weiterentwickelt. Gelegentlich werden dabei Dinge vereinheitlicht und es kommt dazu, dass manche Regelsätze durch andere ersetzt werden. Wenn Sie solche Regelsätze im Einsatz haben, finden Sie diese am einfachsten durch eine Regelsuche. Öffnen Sie diese über Setup > General > Rule search. Klicken Sie anschließend in der Menüleiste auf Rules > Refine search, wählen Sie hinter Deprecated die Option Search for deprecated rulesets und hinter Used die Option Search for rulesets that have rules configured. Nach einem weiteren Klick auf Search bekommen Sie die gewünschte Übersicht.

Wenn Sie im Setup einen Regelsatz für einen Host oder Service ansteuern, zeigt Checkmk Ihnen diesen Regelsatz im Analysemodus. Dorthin gelangen Sie, wenn Sie im Setup in der Host- oder Service-Liste im Aktionsmenü das Symbol anklicken. Die folgende Seite Effective parameters of zeigt die Liste der für den Host/Service geltenden Regeln. Um zum Analysemodus zu gelangen, klicken Sie den Namen eines Regelsatzes an, für den zumindest eine Regel existiert, der also nicht auf Default value steht:

Dies bewirkt zwei Dinge: Zum einen taucht oben ein zweiter Knopf zum Anlegen von Regeln auf: Add rule for current host bzw. Add rule for current host and service.

Damit können Sie eine neue Regel erzeugen, welche als Bedingung direkt den aktuellen Host bzw. Service eingetragen hat. So können Sie sehr einfach direkt eine Ausnahmeregel erzeugen. Zum anderen taucht in jeder Zeile ein Kugelsymbol auf, welches Ihnen anzeigt, ob diese Regel für den aktuellen Host bzw. Service greift. Dabei gibt es folgende mögliche Fälle:

Der letzte Fall — das partielle Greifen einer Regel — kann nur bei solchen Regelsätzen auftreten, in denen eine Regel mehrere Parameter festlegt, welche durch Checkboxen einzeln angewählt werden können. Hier kann theoretisch jeder einzelne der Parameter von einer anderen Regel festgelegt werden. Dazu später mehr.

Alles im ersten Block Rule Properties ist optional und dient vor allem der Dokumentation:

Der zweite Abschnitt ist bei jeder Regel anders, legt aber immer fest, was geschehen soll. Folgende Abbildung zeigt einen weit verbreiteten Typ von Regel (DB2 Tablespaces). Über Checkboxen können Sie bestimmen, welche Einzelparameter die Regel definieren soll. Wie weiter oben beschrieben, wird von Checkmk für jeden einzelnen Parameter getrennt ermittelt, welche Regel diesen setzt. Die Regel aus der Abbildung setzt also nur den einen Wert und lässt alle anderen Einstellungen unbeeinflusst:

Die Werte in dieser und anderen Regeln können Sie auch zeitabhängig steuern. So können Sie zum Beispiel die Schwellwerte für die Nutzung der Tablespaces während der Geschäftszeiten anders setzen als am Wochenende.

Klicken Sie erst auf den Knopf Enable timespecific parameters und dann auf Add new element, werden Ihnen die zeitabhängigen Optionen angezeigt:

Nun wählen Sie in der Liste Match only during time period eine Zeitperiode aus und anschließend die Parameter, für die diese Zeitperiode gelten soll.

Manche Regelsätze legen keinen Parameter fest, sondern entscheiden nur, welche Hosts drin sind und welche nicht. Ein Beispiel ist der Regelsatz Hosts to be monitored, dessen Parameterbereich so aussieht:

Durch Auswahl eines der beiden verfügbaren Werte entscheiden Sie, was mit den betroffenen Hosts geschehen soll. Wählen Sie Positive match (Add matching hosts to the set), so werden die betroffenen Hosts in die Menge der zu überwachenden Hosts aufgenommen. Durch Auswahl von Negative match (Exclude matching hosts from the set) entfernen Sie die betroffenen Hosts aus dem Monitoring. Das Positive match bzw. Negative match bezieht sich auf den Inhalt der aktuellen Regel. Es ist kein zusätzliches Filterkriterium zur Auswahl der Hosts. Die Menge der betroffenen Hosts filtern Sie ausschließlich mit den nachfolgenden Bedingungen (Conditions).

Im vorigen Abschnitt haben Sie festgelegt, wie all jene Hosts bzw. Services bearbeitet werden sollen, die von Ihrer Regel betroffen sind. Im dritten Abschnitt Conditions definieren Sie nun, welche Hosts bzw. Services für die Regel — und damit deren Auswirkungen — herangezogen werden sollen. Dabei gibt es verschiedene Arten von Bedingungen, die alle erfüllt sein müssen, damit die Regel greift. Die Bedingungen werden also logisch UND-verknüpft:

In der Einleitung in das Prinzip der Regeln haben Sie gesehen, dass immer die erste zutreffende Regel den Ergebniswert festlegt. Das ist nicht die ganze Wahrheit. Es gibt insgesamt drei verschiedene Arten der Auswertung:

Die Information, wie die Regel ausgewertet wird, wird bei jedem Regelsatz direkt unterhalb der Menüleiste angezeigt:

Wie wird nun konkret ausgewertet, wenn man mehrere Regeln erstellt hat, die auf mehrere Hosts angewendet werden sollen? Um dies zu veranschaulichen, nehmen wir ein einfaches Beispiel:

Angenommen, Sie haben drei Hosts und wollen für jeden dieser Hosts (und auch für alle künftig hinzukommenden) mit der Regel Periodic notifications during host problems unterschiedliche periodisch wiederholte Benachrichtigungen festlegen:

Wenn Sie nun Ihre Konfiguration aktivieren, läuft Checkmk die Regelkette von oben nach unten durch. Es ergibt sich so die folgende Auswertung:

Zu beachten ist hier: Da bei diesem Regelsatz „The first matching rule defines the parameter“ gilt, wird die Abarbeitung der Regelkette jeweils nach dem ersten Treffer beendet. Die Reihenfolge der Regeln ist daher entscheidend für das Ergebnis! Das zeigt sich, wenn die Reihenfolge der Regeln umgestellt wird und Regel B und C vertauscht werden:

Wird nun die Regelkette erneut von oben nach unten für die einzelnen Hosts durchlaufen, so ändert sich auch das Ergebnis: Regel C trifft jetzt nicht nur auf Host-3, sondern auch auf Host-2 zu, so dass die Benachrichtigung für beide Hosts im 30-Minuten-Takt erfolgt. Damit ist die Bearbeitung für beide Hosts abgeschlossen. Obwohl Regel B für Host-2 relevant wäre, ja sogar für diesen Host geschrieben wurde, wird sie nicht mehr ausgewertet und angewendet. Im Analysemodus sieht das dann so aus:

Kombinieren Sie die verschiedenen in diesem Artikel genannten Einstellungen und beachten dabei die Abarbeitungsreihenfolge, so können Sie damit komplexe Regelketten für ganze Host-Komplexe aufbauen.