Checkmk
to checkmk.com

1. Einleitung

In Checkmk konfigurieren Sie Parameter für Hosts und Services über Regeln. Diese Besonderheit macht Checkmk in komplexen Umgebungen sehr leistungsfähig und bringt auch in kleineren Installationen etliche Vorteile. Um das Prinzip der regelbasierten Konfiguration anschaulich zu machen, machen wir einen Vergleich mit der klassischen Methode:

1.1. Der klassische Ansatz

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:

HostFilesystemWarnungKritisch

myserver001

/var

 90%

 95%

myserver001

/sapdata

 90%

 95%

myserver001

/var/log

 90%

 95%

myserver002

/var

 85%

 90%

myserver002

/opt

 85%

 90%

myserver002

/sapdata

 85%

 95%

myserver002

/var/trans

100%

100%

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?

1.2. Regelbasiert ist besser!

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:

  1. Dateisysteme mit dem Mountpunkt /var/trans haben die Schwellwerte 100/100%.

  2. Das Dateisystem /sapdata auf myserver002 hat die Schwellwerte 85/95%.

  3. Dateisysteme auf Testsystemen haben die Schwellwerte 90/95%.

  4. Alle (übrigen) Dateisysteme haben die Schwellwerte 85/90%.

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:

  • Die Policy ist klar erkennbar und wird zuverlässig durchgesetzt.

  • Sie können die Policy jederzeit ändern, ohne dass Sie Tausende Datensätze anfassen müssen.

  • Ausnahmen sind immer noch möglich, aber in Form von Regeln dokumentiert.

  • Das Aufnehmen von neuen Hosts ist einfach und wenig fehleranfällig.

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, Monitoringeinstellungen, Zuständigkeiten, Alarmierungen, Agentenkonfiguration und vielem mehr.

1.3. Arten von Regelsätzen

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:

  • Host check command — legt fest, wie geprüft werden soll, ob Hosts UP sind.

  • Alternative display name for services — definiert für Services alternative Anzeigenamen.

  • JVM memory levels — legt Schwellwerte und andere Parameter für die Überwachung des Speicherverbrauchs von Java-VMs fest.

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.

1.4. Hostmerkmale

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.

2. Auffinden der richtigen Regelsätze

2.1. Host-Regelsätze

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:

Setup-Menü mit Fokus auf die 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:

Ansicht der Host monitoring rules im Setup-Menü

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.

Auszug des Ergebnisses 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 icon rulesets in der Liste der Hosts eines Ordners.

Liste einiger Hosts im Setup-Menü mit Hervorhebung des Knopfes für Host Parameter

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

wato rules host rule sets

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.

wato rules host rule sets2

2.2. Service-Regelsätze

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.

wato rules service monitoring rules

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 icon rulesets in der Liste der Services eines Hosts im Setup. Das Symbol icon check parameters bringt Sie direkt zu demjenigen Regelsatz, der die Parameter für das Check-Plugin des Services festlegt.

wato rules setup service list

Das Symbol icon rulesets für die Parameterseite gibt es übrigens auch in der Statusoberfläche im Kontextmenü jedes Services:

wato rules service context menu

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

2.4. Benutzte Regelsätze

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.

2.5. Wirkungslose Regeln

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.

2.6. Veraltete Regelsätze

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.

Eingabemaske für die Suche nach veraltetem Regelsätzen

3. Regeln erstellen und editieren

Folgende Abbildung zeigt den Regelsatz Filesystems (used space and growth) mit vier konfigurierten Regeln:

rules filesystem

Neue Regeln erzeugen Sie entweder über den Knopf Create rule in folder oder über das button clone Klonen einer bestehenden Regel. Das Klonen erzeugt eine identische Kopie einer Regel, die Sie anschließend mit icon edit bearbeiten können. Eine über den Knopf Create rule in folder erzeugte neue Regel wird immer am Ende der Liste der Regeln erzeugt, während eine geklonte Regel als Kopie unterhalb des Originals erzeugt wird.

Die Reihenfolge von Regeln können Sie mit dem Knopf icon drag ändern. Die Reihenfolge ist wichtig, weil immer weiter oben stehende Regeln Vorrang vor späteren haben.

Die Regeln sind dabei in den Ordnern abgelegt, in denen Sie auch die Hosts verwalten. Der Wirkungsbereich von Regeln ist auf die Hosts eingeschränkt, die in diesem Ordner oder in Unterordnern liegen. Falls sich Regeln widersprechen, so hat immer die Regel in einem Unterordner Vorrang. So können z.B. Benutzer, die nur für manche Ordner berechtigt sind, für Ihre Hosts Regeln anlegen, ohne dass diese Einfluss auf den Rest des Systems haben. In den Eigenschaften einer Regel können Sie deren Ordner ändern und sie somit „umziehen“.

3.1. Analyse mit der Ampel

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

rules filesystem analyze

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:

icon rulenmatch

Diese Regel greift nicht für den aktuellen Host oder Service.

icon rulematch

Diese Regel greift und definiert Parameter.

icon ruleimatch

Diese Regel greift zwar. Aber da eine Regel weiter oben auch greift und Vorrang hat, ist die Regel wirkungslos.

icon rulepmatch

Diese Regel greift. Eine Regel weiter oben hat zwar Vorrang und greift auch, definiert aber nicht alle Parameter, so dass mindestens ein Parameter von dieser Regel definiert wird.

Der letzte Fall — das icon rulepmatch 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.

4. Eigenschaften einer Regel

4.1. Allgemeine Optionen

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

rules props properties
  • Die Description wird in der Tabelle aller Regeln eines Regelsatzes angezeigt.

  • Das Feld Comment können Sie für eine längere Beschreibung verwenden. Es erscheint nur im Editiermodus einer Regel. Über das Symbol icon insertdate können Sie einen Zeitstempel und Ihren Loginnamen in den Text einfügen lassen.

  • Die Documentation-URL ist für einen Link auf interne Dokumentation gedacht, die Sie in einem anderen System (z.B. einer CMDB) pflegen. Sie wird in der Regeltabelle über das Symbol icon url anklickbar dargestellt.

  • Mit der Checkbox do not apply this rule können Sie die Regel vorübergehend abschalten. Sie wird dann in der Tabelle mit icon disabled dargestellt und hat keine Wirkung.

4.2. Die festgelegten Parameter

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.

rules props value 1

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:

rules props value 2

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.

4.3. Bedingungen

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:

rules props conditions 1

Condition type

Hier haben Sie die Möglichkeit, neben einer normalen Bedingungen auch auf vordefinierte Bedingungen (Predefined Conditions) zurückzugreifen. Diese werden werden über Setup > General > Predefined conditions verwaltet. Geben Sie hier einfach Regelbedingungen, die Sie immer wieder brauchen, einen festen Namen und verweisen in den Regeln einfach darauf. Sie können sogar später den Inhalt dieser Bedingungen zentral ändern und alle Regeln werden automatisch angepasst. In folgendem Beispiel wird die vordefinierte Bedingung No VM ausgewählt:

rules props conditions 2

Folder

Mit der Bedingung Folder legen Sie fest, dass die Regel nur für Hosts gelten soll, die in diesem Ordner (oder einem Unterordner) enthalten sind. Ist die Einstellung auf Main Directory, so gilt diese Bedingung also für alle Hosts. Wie weiter oben beschrieben, haben die Ordner auch einen Einfluss auf die Reihenfolge der Regeln. Regeln in tieferen Ordnern haben immer Vorrang vor höher liegenden.

Host tags

Die Host tags schränken die Regel auf solche Host ein, die bestimmte Hostmerkmale haben oder nicht haben. Auch hier wird immer mit UND verknüpft. Jede weitere Host-tag-Bedingung in einer Regel verringert also die Menge der Hosts, auf die diese wirkt.

Wenn Sie eine Regel für zwei mögliche Ausprägungen eines Merkmals gelten lassen möchten (z.B. bei Criticality sowohl Productive system als auch Business critical), so geht das nicht mit einer einzelnen Regel. Sie benötigen dann eine Kopie der Regel für jede Variante. Manchmal hilft hier aber auch die Negation. Sie können als Bedingung auch festlegen, dass ein Merkmal nicht vorhanden ist (z.B. nicht Testsystem). Eine andere Möglichkeit sind sogenannte Hilfsmerkmale.

Weil einige Anwender wirklich sehr viele Hostmerkmale verwenden, haben wir den Dialog so gestaltet, dass nicht sofort alle Merkmalsgruppen angezeigt werden. Sie müssen diese zunächst für die Regel aktivieren. Das geht so:

  1. Wählen Sie in der Auswahlbox eine Merkmalsgruppe.

  2. Klicken Sie Add tag condition. Dadurch wird darüber ein Eintrag für diese Gruppe hinzugefügt.

  3. Wählen Sie is oder is not.

  4. Wählen Sie den gewünschten Vergleichswert.

rules props hosttags

Labels

Auch Labels können Sie für Bedingungen in Regeln verwenden. Fügen Sie Bedingungen mit Add label condition hinzu. Wählen Sie nun entweder has oder has not um eine positive oder negative Bedingung zu formulieren und geben Sie dann das Label in der gewohnten Form Schlüssel`:`Wert ein. Achten Sie hier bitte auf ganz exakte Schreibung, auch was Groß-/Kleinschreibung betrifft. Sonst wird die Bedingung nicht korrekt funktionieren.

rules props labels

Explicit hosts

Diese Art von Bedingung ist für Ausnahmeregeln vorgesehen. Hier können Sie einen oder mehrere Hostnamen auflisten. Die Regel gilt dann nur für diese Hosts. Bitte beachten Sie, dass wenn Sie Explicit hosts angekreuzt haben und keinen Host eintragen, die Regel überhaupt nicht greifen wird.

Über die Option Negate können Sie eine umgekehrte Ausnahme definieren. Damit schließen Sie bestimmte explizit genannte Hosts von der Regel aus.

rules props explicithosts 1

Wichtig: Alle hier eingetippten Hostnamen werden auf genaue Übereinstimmung geprüft. Groß-/Kleinschreibung wird von Checkmk in Hostnamen grundsätzlich unterschieden!

Sie können dieses Verhalten auf reguläre Ausdrücke umstellen, indem Sie dem Hostnamen eine Tilde (~) voranstellen. In diesem Fall gilt wie immer im Setup:

  • Der Match geht auf den Anfang des Hostnamens.

  • Der Match ignoriert Groß-/Kleinschreibung.

Punkt-Stern (.*) bedeutet bei regulären Ausdrücken eine beliebige Folge von Zeichen. Folgendes Beispiel zeigt eine Bedingung, die auf alle Hosts matcht, deren Namen die Zeichenfolge my (oder My, MY, mY usw.) enthält:

rules props explicithosts 2

Explicit services

Bei Regeln, die sich auf Services beziehen, gibt es als letzte Bedingungsart noch einen Match auf den Namen des Services, bzw. bei Regeln, die Checkparameter festlegen, auf den Namen des Checkitems. Auf was genau gematcht wird, sehen Sie in der Beschriftung. In unserem Beispiel ist das der Name (Instance) eines Tablespaces:

rules props explicitservices

Hier gilt grundsätzlich ein Match mit regulären Ausdrücken. Die Folge .temp matcht alle Tablespaces, die temp *enthalten, denn der Match geht immer auf den Anfang des Namens. Das Dollarzeichen am Ende von transfer$ steht für das Ende und erzwingt somit einen exakten Match. Ein Tablespace mit dem Namen transfer2 würde daher nicht matchen.

Bitte vergessen Sie nicht: Bei Regeln wo es um Explicit services geht, benötigen Sie einen Match auf den Servicenamen (z.B. Tablespace transfer). Bei Checkparameter-Regeln geht es um einen Match auf das Item (z.B. transfer). Das Item ist quasi der variable Teil des Servicenamens und legt fest, um welchen Tablespace es sich handelt.

Es gibt übrigens auch Services ohne Item. Ein Beispiel ist die CPU load. Diese gibt es pro Host nur einmal, also ist kein Item notwendig. Regeln für solche Checktypen haben folglich auch keine Bedingung dafür.

5. Arten der Regelauswertung

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:

AuswertungVerhalten

Erste Regel

Die erste Regel, die zutrifft, legt den Wert fest. Weitere Regeln werden nicht mehr ausgewertet. Dies ist der Normalfall für Regeln, die einfache Parameter festlegen.

Erste Regel pro Parameter

Jeder Einzelparameter wird von der ersten Regel festgelegt, bei der dieser Parameter definiert ist (Checkbox angekreuzt). Dies ist der Normalfall für alle Regeln mit Unterparametern, die mit Checkboxen aktiviert werden.

Alle Regeln

Alle zutreffenden Regeln fügen Elemente zum Ergebnis hinzu. Dieser Typ kommt z.B. bei der Zuordnung von Hosts und Services zu Host-, Service- und Kontaktgruppen zum Einsatz.

Diese Information wird bei jedem Regelsatz oben angezeigt.

rules matching strategy

6. Hostmerkmale im Detail

Wie Sie gesehen haben, sind die Hostmerkmale eine wichtige Grundlage für die Definition von Regeln. Sie sind aber auch an anderen Stellen nützlich. Zum Beispiel gibt es in Views einen Filter für Hosttags. Das Seitenleistenelement Virtual host tree kann Ihre Ordner anhand von Hostmerkmalen in einem Baum anordnen. Und auf der Kommandozeile können Sie bei vielen Befehlen mit der Syntax @foo alle Hosts mit dem Tag foo auswählen.

Damit alles richtig Sinn ergibt, sollten Sie Ihr eigenes Schema für Hosttags einrichten, welches für Ihre Umgebung optimal passt. Aber bevor wir Ihnen zeigen, wie Sie im Setup eigene Hosttags definieren können, sollten wir zunächst einige Begriffe klären.

6.1. Taggruppen, Checkboxtags, Themen und Hilfsmerkmale

Hosttags 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 Taggruppe 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 Taggruppe, welche nur zwei Möglichkeiten hat: ja oder nein. Checkmk vereinfacht dies, indem es Ihnen erlaubt, Taggruppen mit nur einem einzigen Tag anzulegen. Diese werden dann in der Hostmaske nicht als Auswahlfeld, sondern als Checkbox dargestellt. Ein Ankreuzen der Checkbox setzt das Tag, andernfalls entfällt das Tag. Solche Taggruppen heißen auch Checkboxtags.

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

  • in den Hostdetails in einem eigenen Kasten zusammengefasst und

  • bei den Bedingungen der Regel über ein kleine Dreieck auf- und zuklappbar dargestellt.

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 Taggruppe 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 Hilfstag 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 Tag für die Formulierung von Bedingungen.

6.2. Vordefinierte Merkmale

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

Tag-GruppeidZweckWahlmöglichkeiten

Checkmk Agent / API integrations

agent

Legt fest, auf welche Art der Host Daten von seinem Agenten bekommt.

cmk-agent, all-agents, special-agents, no-agent

Criticality

criticality

Wichtigkeit (Servicelevel) des Systems. Für das Merkmal Do not monitor this host wird eine Regel mit ausgeliefert, welche die Überwachung des Hosts abschaltet. Die anderen Merkmale sind nur Beispiele und ohne Funktion. Sie können diese aber Hosts zuweisen und dann in Regeln verwenden.

prod, critical, test, offline

Networking Segment

networking

Verstehen Sie diese Taggruppe nur als Beispiel. Für das Merkmal WAN (high latency) ist eine Beispielregel hinterlegt, welche die Schwellwerte für PING-Antwortzeiten an die längeren Laufzeiten im WAN anpasst.

lan, wan , dmz

IP address family

address_family

Legt fest, ob der Host per IPv4 oder IPv6 oder beidem überwacht werden soll. Diese Gruppe hat den Status builtin und kann nicht modifiziert werden. Das ist notwendig, da die Tags intern von Checkmk bei der Konfigurationserzeugung benötigt werden.

"ip-v4-only" "ip-v6-only" "ip-v4v6" "no-ip"

SNMP

snmp_ds

Hier wird bestimmt, ob SNMP-Daten ausgewertet werden.

"no-snmp" "snmp-v2" "snmp-v1"

Piggyback

piggyback

Dieses Merkmal legt fest, ob und wie Huckepackdaten für entsprechende Hosts erwartet/verarbeitet werden.

"auto-piggyback" "piggyback" "no-piggyback"

Ändern von vordefinierten Taggruppen

Theoretisch können Sie die vordefinierten Taggruppen anpassen, solange diese nicht als builtin markiert sind. Änderungen in Criticality oder Network Segment sind unkritisch. Diese sind nur als Beispiel vorgesehen. Die Gruppe Agent Type jedoch sollten Sie auf keinen Fall ändern oder erweitern — auch wenn diese nicht als builtin gekennzeichnet ist! Die Tags dieser Gruppe werden intern von Checkmk referenziert.

6.3. Merkmalsgruppen erstellen

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

Eine Liste aller eingebauten Host-Merkmalsgruppen.

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

rules hosttags config properties

Die Tag group ID wird intern als ID für die Taggruppe 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 Taggruppe 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 Taggruppe zusammen mit den mitgelieferten Gruppen angezeigt. Sie können aber auch eigene Themen anlegen und damit Ihre Tags übersichtlich zusammenfassen.

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

rules hosttags config choices

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 icon drag ändern können, hat nicht nur eine optische Funktion: Das erste Tag in der Liste gilt als Defaultwert! Das bedeutet, dass alle Hosts, die keine explizite Einstellung für diese Taggruppe 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 Tag gewählt ist.

6.4. Hilfsmerkmale erstellen

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 Taggruppen lässt sich hier zudem ein Topic angeben.

rules hosttags auxtag basic

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

6.5. Löschen und Ändern von bestehenden Tags und Taggruppen

Das Ändern der bestehenden Taggruppenkonfiguration 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:

  • Änderung im Titel oder Thema von Tags und Taggruppen

  • Hinzufügen eines weiteren Merkmals zu einer Taggruppe

Alle anderen Änderungen können Auswirkungen auf bestehende Hosts oder Regeln haben, die die betroffenen Tags 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.

Löschen von Taggruppen

Von allen Hosts wird die Information über die betroffenen Tags entfernt. Falls die Taggruppe in vorhandenen Regeln als Bedingung verwendet wird, bekommen Sie folgende Warnung:

rules hosttags delete

Sie müssen sich hier entscheiden, ob Sie aus den bestehenden Regeln die Bedingungen entfernen möchten oder ob Sie die ganzen Regeln löschen möchten. Beides kann sinnvoll sein und Checkmk kann nicht für Sie entscheiden, was hier besser ist. Wenn Sie sich nicht sicher sind, sollten Sie die Regelsätze (hier in der Warnung verlinkt) von Hand durchgehen und alle Bedingungen der betroffene Gruppe von Hand entfernen oder abändern.

Löschen von einzelnen Tags

Das Löschen von Tags erreichen Sie durch Editieren der Gruppe, Entfernen des Tags und anschließendes Speichern. Dabei kann es zu einer ähnlichen Warnung wie beim Entfernen einer Taggruppe kommen.

Hosts, die das betroffen Tag gesetzt hatten, werden automatisch auf den Defaultwert gesetzt. Dies ist (wie oben beschrieben) stets das oberste Tag in der Liste.

Regeln, die eine negative Bedingung auf das Tag haben, verlieren einfach diese Bedingung — ohne Rückfrage. Wenn Sie z.B. eine Regel haben für alle Hosts, die nicht das Tag loc_dc2 haben und Sie entfernen das Tag loc_dc2 komplett aus der Konfiguration, dann ist augenscheinlich auch diese Bedingung überflüssig.

Falls jedoch eine positive Bedingung mit dem Tag existiert, kommt es wieder zu obiger Warnung und Sie müssen entscheiden, wie die Konfiguration angepasst werden soll.

Umbenennen von Tag-IDs

Anders als bei den Taggruppen können Sie die IDs von Tags tatsächlich nachträglich ändern. Dies ist sozusagen eine Ausnahme vom Checkmk-Prinzip, nach der IDs, wenn einmal vergeben, unveränderlich sind. Es kann aber nützlich sein, wenn Sie z.B. einen Datenimport von einem bestehenden System vorbereiten wollen, und sich dafür an ein vorhandenes, unterschiedliches Tagschema anpassen müssen.

Um Tag-IDs umzubenennen, gehen Sie in den Editiermodus der Taggruppe und ändern Sie dort einfach die IDs, wobei Sie die Titel unverändert lassen. Letzteres ist wichtig, damit Checkmk überhaupt erkennt, dass es sich um eine Umbenennung handelt und nicht einfach eine Tag-ID entfernt und eine neue hinzugefügt wurde.

Bevor Checkmk mit der Anpassung der Konfiguration zu Werke geht, werden Sie nochmal über die Konsequenzen aufgeklärt:

rules hosttags rename

Checkmk wird nun alle betroffenen Hosts, Folder und Regeln entsprechend anpassen.

Bitte beachten Sie, dass es trotzdem noch Situationen geben kann, in denen Sie an anderen Stellen manuell nacharbeiten müssen. So sind z.B. Tag-IDs Bestandteile von URLs, welche Views aufrufen, die nach Tags filtern. Checkmk kann diese URLs nicht für Sie anpassen. Auch Filter-Konfigurationen in Reports und Dashboards können nicht automatisch angepasst werden. Es ist also sicher eine gute Idee, sich über das Tagschema am Anfang genügend Gedanken zu machen, so dass Sie Umbenennungen später nach Möglichkeit vermeiden können.

6.6. Baumansicht aus Hostmerkmalen erstellen

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 Hostmerkmalen erstellen und so eine „virtuelle“ Hierarchie abbilden — und zwar über das Snapin Virtual Host Tree. Neben den Hostmerkmalen 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 Taggruppen 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 button sidebar add snapin unten links in der Seitenleiste zu dieser hinzu.

rules virtual host tree snapin

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.

rules virtual host tree new

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

rules virtual host tree settings

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

rules virtual host tree views
Auf dieser Seite