Host- und Serviceparameter

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 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 Policy! 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 beides. Wenn Parameter sowohl für Hosts als auch für Services einstellbar sind, gibt es jeweils ein Pärchen 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 in der Rubrik Active checks. 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 Host-Eigenschaft des Hosts.

Ferner gibt es Regelsätze, welche die Serviceerkennung 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 Hostmerkmal (englisch: Host tag). Welche Merkmale es gibt, können Sie über Setup > Tags frei definieren, und einige Merkmale sind bereits vordefiniert. 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 weiter unten in diesem Artikel.

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 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 der Defaulteinstellung 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, in 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 in der Statusoberfläche im Kontextmenü jedes Services:

Im Setup-Menü finden Sie desweiteren einen Eintrag für erzwungene Services (Enforced 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 bspw. Simple checks for BIOS/Hardware errors - finden Sie ausschließlich unter den erzwungenen Services. Hierbei handelt es sich um Services, welche nicht durch die Serviceerkennung 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 auf keinen einzigen Host oder Service matchen — entweder weil Sie einen Fehler gemacht haben oder weil die passenden Hosts und Service 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 in der Navigationsleiste. 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 bekomme Sie die gewünschte Übersicht.

Wenn Sie einen Regelsatz über einen Host oder Service ansteuern — also z.B. über die Symbole oder bei einem Host oder Service — zeigt Checkmk Ihnen den Regelsatz im Analysemodus:

Dies bewirkt zwei Dinge: Zum einen taucht ein zweiter Knopf zum Anlegen von Regeln auf — hier im Beispiel Create mount point specific rule for. Damit können Sie eine neue Regel erzeugen, welche als Bedingung direkt den aktuellen Host bzw. Service voreingetragen 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 Matchen 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.

Jede Regel ist in drei Blöcken aufgebaut. Alles im ersten Block Rule Properties ist optional und dient vor allem der Dokumentation:

Der zweite Abschnitt ist bei jeder Regel anders. 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.

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, mit welchem Sie manche Hosts ganz aus dem Monitoring entfernen können. Der Parameterbereich sieht dann so aus:

Wählen Sie hier Make the outcome of the rule positive, so heißt das, dass die betroffenen Hosts in die Menge aufgenommen — in unserem Beispiel also gemonitort werden sollen.

Im dritten Abschnitt Conditions legen Sie fest, für welche Hosts bzw. Services die Regel greifen soll. 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:

Host-Merkmale (Englisch: _Host tags) sind in Gruppen organisiert. Dabei kann ein Host aus jeder Gruppe maximal ein Merkmal haben! Ein gutes Beispiel für eine eigene Gruppe wäre z.B. Datacenter mit den möglichen Merkmalen DC 1 und DC 2. Damit wäre dann jeder Host genau einem der beiden Rechenzentren zugeordnet. Möchten Sie Hosts anlegen, die in keinem der beiden Rechenzentren stehen, so brauchen Sie eine dritte Auswahlmöglichkeit — z.B. Not in a datacenter.

Manche Anwender haben versucht, die Anwendung, die auf einem Host läuft, in einer Merkmalsgruppe abzubilden. Die Gruppe hieß z.B. Anwendung und hatte die Ausprägungen ORACLE, SAP, MS Exchange, usw. Das geht solange gut, bis der Tag kommt, an dem ein Host zwei Anwendungen hat — und der kommt gewiss!

Die richtige Lösung ist hier daher eine andere: Erzeugen Sie pro Anwendung eine eigene Merkmalsgruppe, welche nur zwei Möglichkeiten hat: ja oder nein. Checkmk vereinfacht dies, indem es Ihnen erlaubt, Merkmalsgruppen mit nur einem einzigen Merkmal anzulegen. Diese werden dann in der Hostmaske nicht als Auswahlfeld, sondern als Checkbox dargestellt. Ein Ankreuzen der Checkbox setzt das Merkmal, andernfalls entfällt das Tag. Solche Merkmalsgruppen heißen auch Checkboxtags.

Damit das Ganze nicht unübersichtlich wird, wenn Sie sehr viele Merkmalsgruppen haben (z.B. weil Sie viele verschieden Anwendungen abbilden), können Sie die Merkmalsgruppen zu Themen (Englisch: Topics) zusammenfassen. Alle Merkmalsgruppen des gleichen Themas sind dann

Die Themen haben also „nur“ eine optische Funktion und keine Auswirkung auf die eigentliche Konfiguration.

Hilfsmerkmale (Englisch: Auxiliary tags) lösen folgendes Problem: Stellen Sie sich vor, dass Sie eine Merkmalsgruppe Betriebssystem definieren, mit den Ausprägungen Linux, AIX, Windows 2008 und Windows 2012. Nun möchten Sie eine Regel definieren, welche für alle Windows-Hosts gelten soll. Das geht so überhaupt nicht, da Sie in einer Bedingung wie oben gezeigt pro Gruppe immer nur ein Tag auswählen können.

Um das Problem zu lösen, können Sie das Hilfsmerkmal Windows definieren. Dann ordnen Sie den beiden Merkmalen Windows 2008 und Windows 2012 dieses Hilfsmerkmal zu. Ein Host, der eines der beiden Merkmale hat, erhält dann von Checkmk automatisch immer auch das Hilftstag Windows. In den Regeln erscheint Windows als eigenes Merkmal für die Formulierung von Bedingungen.

Checkmk richtet bei der Installation mehrere Merkmalsgruppen bzw. Tag-Gruppen für Sie ein:

Das Erzeugen von eigenen Merkmalen geschieht über Setup > Hosts > Tags. Dieses sieht bei einem frisch aufgesetzten System je nach Checkmk-Version etwa so aus:

Das Anlegen einer neuen Merkmalsgruppe geschieht mit dem Knopf Add tag group und bringt Sie zu folgenden Eingabemasken:

Die Tag group ID wird intern als ID für die Merkmalsgruppe verwendet. Diese muss eindeutig sein und kann später nicht geändert werden. Es gelten die üblichen Regeln für erlaubte Zeichen (nur Buchstaben, Ziffern, Unterstrich).

Der Title wird überall in der GUI verwendet, wo es um die Merkmalsgruppe geht. Da dies ein reiner Anzeigetext ist, kann er jederzeit geändert werden, ohne dass das einen Einfluss auf die bestehende Konfiguration hat.

Das Topic können Sie leer lassen. Dann wird Ihre Merkmalsgruppe zusammen mit den mitgelieferten Gruppen angezeigt. Sie können aber auch eigene Themen anlegen und damit Ihre Merkmale übersichtlich zusammenfassen.

Am wichtigsten sind natürlich die Choices im nächsten Kasten.

Wichtig ist, dass auch hier die Tag ID jeweils eindeutig sein muss — und zwar nicht nur innerhalb der Gruppe, sondern über alle Gruppen hinweg! Im Zweifelsfall können Sie einfach mit Präfixen arbeiten, z.B. loc_dc01 anstelle von nur dc01.

Die Reihenfolge, welche Sie wie gewohnt mit dem Knopf ändern können, hat nicht nur eine optische Funktion: Das erste Merkmal in der Liste gilt als Defaultwert! Das bedeutet, dass alle Hosts, die keine explizite Einstellung für diese Merkmalsgruppe haben, automatisch auf diesen Wert gesetzt werden.

Unter Auxiliary tags können Sie dem Merkmal Hilfsmerkmale zuordnen, die automatisch dem Host hinzugefügt werden sollen, wenn dieses Merkmal gewählt ist.

Neue Hilfsmerkmale (Auxiliary Tags) können Sie über Add aux tag erstellen. Im folgenden Dialog vergeben Sie wieder eine unveränderliche ID und einen aussagekräftigen Titel. Wie schon bei den Merkmalsgruppen lässt sich hier zudem ein Topic angeben.

Die Zuordnung/Nutzung dieser Hilfsmerkmale erfolgt dann direkt in den Merkmalsgruppen bei den einzelnen Auswahlmöglichkeiten.

Das Ändern der bestehenden Merkmalsgruppenkonfiguration mag auf den ersten Blick wie eine einfache Operation aussehen. Das ist aber leider nicht immer so, da es größere Auswirkungen auf Ihre bestehende Konfiguration haben kann. Änderungen, die lediglich die Anzeige betreffen oder nur neue Auswahlen hinzufügt, sind unproblematisch und haben keine Auswirkung auf die bestehenden Hosts und Regeln:

Alle anderen Änderungen können Auswirkungen auf bestehende Hosts oder Regeln haben, die die betroffenen Merkmale verwenden. Checkmk verbietet dabei nicht einfach solche Änderungen, sondern versucht für Sie, Ihre bestehende Konfiguration so anzupassen, dass alles wieder Sinn ergibt. Was das genau bedeutet, hängt von der Art der Operation ab.

Hosts werden in Checkmk in der Regel in Ordnern organisiert, woraus sich eine natürliche Hierarchie ergibt. Diese können Sie als Baumansicht über das Seitenleisten-Snapin Folders darstellen und von dort die Standardansicht für die pro Verzweigung gefilterten Hosts aufrufen. Das Snapin Tree of Folders ergänzt diesen Baum noch um Filtermöglichkeiten für Themen und Optionen für unterschiedliche Ansichten. Eine solche Baumansicht können Sie aber auch aus Host-Merkmalen erstellen und so eine „virtuelle“ Hierarchie abbilden — und zwar über das Snapin Virtual Host Tree. Neben den Host-Merkmalen dürfen Sie auch die Ordnerstruktur in derlei Bäume einbauen, wobei sowohl die Anzahl der virtuellen Bäume als auch der jeweiligen Verzweigungen unbeschränkt ist.

Angenommen, Sie haben für Ihre Hosts die drei Merkmalsgruppen Ort, Geräteklasse und Betriebssystem angelegt. Dann bekommen Sie auf der obersten Baumebene eine Auswahl der Orte zu sehen, darunter der Geräteklassen und letztlich der Betriebssysteme. Jede Hierarchieebene bringt Sie direkt zur Ansicht aller Hosts mit eben diesen Merkmalen.

Zum Anlegen eines Virtual Host Tree fügen Sie zunächst das Snapin über unten links in der Seitenleiste zu dieser hinzu.

Rufen Sie dann die Einstellungen über Setup > General > Global Settings > User Interface > Virtual Host Trees auf und erstellen Sie einen neuen Baum über Create new virtual host tree configuration.

Vergeben Sie anschließend ID und Titel des Baums und schließen Sie optional leere Baumzweige über ein Häkchen bei Exclude empty tag choices aus. Anschließend fügen Sie über Add new element die gewünschten Merkmalsgruppen in der gewünschten Reihenfolge hinzu. Wenn Sie die Ordnerhierarchie als oberste Ordnung übernehmen wollen, beginnen Sie einfach mit WATO folder tree. Die Reihenfolge/Hierarchie können Sie freilich wie üblich über die Anfasser nachträglich ändern.

Speichern Sie noch und übernehmen Sie die Änderungen — und schon liefert die Baumstruktur etliche neue Ansichten.