Host- und Serviceparameter

Letzte Aktualisierung: 26. April 2018


1. Einleitung

In Check_MK konfigurieren Sie Parameter für Hosts und Services über Regeln. Diese Besonderheit macht Check_MK 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 klassiche Ansatz

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

Host Filesystem Warnung Kritisch
xysrv123 /var  90%  95%
xysrv123 /sapdata  90%  95%
xysrv123 /var/log  90%  95%
xysrv124 /var  85%  90%
xysrv124 /opt  85%  90%
xysrv124 /sapdata  85%  95%
xysrv124 /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 xyserv124 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 xyserv124 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 Unterschied schnell sehr groß. Die Vorteile der regel­basierten 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 Check_MK 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

WATO organisiert Regeln in Regelsätzen. Jeder Regelsatz hat die Aufgabe, einen ganz bestimmten Parameter für Hosts oder Services festzulegen. In der Version 1.2.8 von Check_MK 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 Checksplugins fest. Ein Beispiel ist Network interfaces and switch ports. Die Einstellungen in diesen Regeln sind sehr individuell auf das jeweilge Plugin zugeschnitten. Solche Regelsätze finden grundsätzlich nur bei denjenigen Services Anwendung, die auf diesem Checkplugin 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 ein Regel für alle Testsysteme. Wo ist eigentlich festgelegt, welcher Host ein Testsystem ist?

So etwas wie Testsystem heißt bei Check_MK Hostmerkmal (englisch: Host tag). Welche Merkmale es gibt, können Sie frei definieren, und einige Merkmale sind bereits vordefiniert. Die Zuordnung zu den Hosts geschieht entweder in der Detailmaske beim Host 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 das WATO-Modul Host & service parameters:

Am schnellsten geht es jetzt mit dem Suchfeld. 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 check. Die Zahlen zeigen die Anzahl der bereits vorhandenen Regeln in den jeweiligen Regelsätzen an:

Ein anderer Weg geht über den Knopf in den Details eines vorhandenen Hosts in WATO 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.

2.2. Service-Regelsätze

Der Weg zu den Regelsätzen für Services ist ähnlich. Der allgemeine Zugang geht auch hier über das WATO-Modul Host & service parameters und 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 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 in WATO. Das Symbol bringt Sie direkt zu demjenigen Regelsatz, der die Parameter für das Checkplugin des Services festlegt.

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

2.3. Manuelle Checks

Ein Teil der Regelsätze ist nicht im Modul Host & Service Parameters eingeordnet, sondern im Modul Manual Checks. Hierbei handelt es sich um Services, welche nicht durch die Serviceerkennung entstehen, sondern von Ihnen manuell angelegt werden. Einzelheiten dazu finden Sie im Artikel über die Services.

2.4. Benutzte Regelsätze

In der Hauptansicht unter Host & Service Parameters finden Sie den Knopf . Dieser zeigt alle Regelsätze, 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 Check_MK-Instanz und sind Teil der WATO-Beispiel­konfiguration. Auch diese werden hier angezeigt.

2.5. Wirkungslose Regeln

Monitoring ist eine komplexe Sache. Da kann es schonmal 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 mit dem Knopf anzeigen lassen.

2.6. Veraltete Regelsätze

Check_MK wird ständig weiterentwickelt. Gelegentlich werden dabei Dinge vereinheitlicht und es kommt dazu, dass manche Regelsätze durch andere ersetzt werden. Ein Beispiel ist die Vereinheitlichung von allen Checkplugins, welche Temperaturen überwachen. Seit der Version 1.2.8 von Check_MK werden diese ausnahmslos mit einem einzigen Regelsatz konfiguriert. Etliche der bisherigen Regelsätze sind in diesem Zuge wirkungslos geworden. Soche Regelsätze finden Sie dann unter . Dort können Sie auch sehen, ob Sie Regeln definiert haben, damit Sie diese dann nach Bedarf in den jeweils neuen Regelsätzen nachbilden können.

3. Regeln erstellen und editieren

Folgende Abbilung zeigt den Regelsatz Filesystems (used space and growth), wobei exakt die vier Beispielregeln aus der Einleitung konfiguriert sind:

Neue Regeln erzeugen Sie entweder über den Knopf Create rule in folder oder über das Klonen einer bestehenden Regel. Das Klonen erzeugt eine identische Kopie einer Regel, die Sie anschließend mit 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 an der gleichen Stelle wie die Ausgangsregel erzeugt wird.

Die Reihenfolge von Regeln können Sie mit den Knöpfen , , , und ä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 Wirkungs­bereich 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 oder bei einem Host oder Service – zeigt WATO 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:

Diese Regel greift nicht für den aktuellen Host oder Service.
Diese Regel greift und definiert Parameter.
Diese Regel greift zwar. Aber da eine Regel weiter oben auch greift und Vorrang hat, ist die Regel wirkungslos.
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 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 options ist optional und dient vor allem der Dokumentation:

  • 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 können Sie einen Zeitstempel und Ihren Loginnamen in den Text einfügen lassen (hier im Beispiel 2016-05-06 mk:).
  • 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 anklickbar dargestellt.
  • Mit der Checkbox Do not apply this rule können Sie die Regel vorrübergehend abschalten. Sie wird dann in der Tabelle mit 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. Über Checkboxen können Sie bestimmen, welche Einzelparameter die Regel definieren soll. Wie weiter oben beschrieben, wird von Check_MK für jeden einzelnen Parameter getrennt ermittelt, welche Regel diesen setzt. Die Regel aus der Abbildung deaktiviert also einfach nur das Überprüfen von Autoextend 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.

4.3. Bedingungen

Im dritten Abschnitt Conditions legen Sie fest, für welche Hosts bzw. Services die Regel greifen soll. Dabei gibt es vier verschiedene Arten von Bedingungen, die alle erfüllt sein müssen, damit die Regel greift. Die Bedingungen werden also quasi logisch UND-verknüpft:

Ordner

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.

Hostmerkmale

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

Explizite 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 Specify explicit host names 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.

Wichtig: Alle hier eingetippten Hostnamen werden auf genaue Übereinstimmung geprüft. Groß-/Klein­schreibung wird von Check_MK 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 in WATO:

  • Der Match geht auf den Anfang des Hostnamens.
  • Der Match ignoriert Groß-/Klein­schreibung.

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 test (oder Test, TEST, tEsT usw.) enthält:

Explizite Services

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

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 wir gesehen, dass immer die erste zutreffende Regel den Ergebniswert festlegt. Das ist nicht die ganze Wahrheit. Es gibt insgesamt drei verschiedene Arten der Auswertung:

Auswertung Verhalten
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.

Ab Version 1.2.8p1 von Check_MK wird diese Information bei jedem Regelsatz oben angezeigt.

6. Hostmerkmale im Detail

Wie wir 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 Seiten­leisten­element 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 mit WATO 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. Check_MK 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) zusammen­fassen. 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 Konfi­guration.

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 WATO automatisch immer auch das Hilftstag Windows. In den Regeln erscheint Windows als eigenes Tag für die Formulierung von Bedingungen.

6.2. Vordefinierte Merkmale

Check_MK richtet bei der Installation mehrere Taggruppen für Sie ein:

Tag-Gruppe Zweck
Agent type Legt fest, auf welche Art der Host Daten von seinem Agenten bekommt.
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.
Networking Segment Verstehen Sie diese Taggruppe nur als Bespiel. 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.
IP 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 Check_MK bei der Konfigurationserzeugung benötigt werden.

Ä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 Check_MK referenziert.

6.3. Taggruppen über WATO erstellen

Das Erzeugen von eigenen Merkmalengeschieht im WATO-Modul Host tags. Dieses sieht bei einem frisch aufgesetzten System je nach Check_MK-Version etwa so aus:

Das Anlegen einer neuen Taggruppe geschieht mit dem Knopf und bringt Sie zu folgender Eingabemaske:

Die Internal 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 zusammen­fassen.

Am wichtigsten sind natürlich die 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_dc1 anstelle von nur dc1.

Die Reihenfolge, welche Sie wie gewohnt mit den Knöpfen , , und ä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 von WATO dem Host hinzugefügt werden sollen, wenn dieses Tag gewählt ist.

6.4. Hilfsmerkmale erstellen

Neue Hilfsmerkmale (Auxiliary Tags) können Sie über 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.

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. WATO 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 vorhan­denen Regeln als Bedingung verwendet wird, bekommen Sie folgende Warnung:

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 WATO 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 Beding­ung ü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 Check_MK-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 Check_MK überhaupt erkennt, dass es sich um eine Umbenennung handelt und nicht einfach eine Tag-ID entfernt und eine neue hinzugefügt wurde.

Bevor Check_MK mit der Anpassung der Konfiguration zu Werke geht, werden Sie nochmal über die Konse­quenzen aufgeklärt:

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

Bitte beachten Sie, dass es trotzdem noch Situtation 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. WATO 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.