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, vergleichen wir es 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:

Host Dateisystem Warnung Kritisch

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 Richtlinie (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 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:

  1. Dateisysteme mit dem Mount-Punkt /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 Richtlinie ist klar erkennbar und wird zuverlässig durchgesetzt.

  • Sie können die Richtlinie 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, Monitoring-Einstellungen, Zuständigkeiten, Benachrichtigungen, 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 Speicherbedarfs von Java virtuellen Maschinen (VM) fest.

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.

1.4. Host-Merkmale

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.

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:

Die '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 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 icon rulesets Symbol in der Liste der Hosts eines Ordners.

Host-Liste im Setup-Menü mit Hervorhebung des Knopfes für die gültigen 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 Smart PING (only with Checkmk Micro Core), dem Standardwert in den kommerziellen Editionen. In der Raw Edition ist der Standardwert PING (active check with ICMP echo request).

Anzeige für das 'Host check command' mit dem Standardwert.

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:

Anzeige für das 'Host check command' mit Regel.

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 Setup-Menü, in diesem Fall also Setup > Services > Service monitoring rules oder zweckmäßigerweise über das Suchfeld.

Setup-Menü mit Fokus auf die 'Service monitoring rules' und 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 icon services Symbol in der Liste der Services eines Hosts im Setup. Das icon check parameters Symbol bringt Sie direkt zu demjenigen Regelsatz, der die Parameter für das Check-Plugin des Services festlegt.

Services-Liste im Setup mit den Symbolen zum Aufruf der Parameter.

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

Services-Liste im Monitoring mit geöffnetem Aktionsmenü eines Services.

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

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

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

Optionen zur Suche nach veralteten Regelsätzen.

3. Regeln erstellen und editieren

Die 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 icon 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 weiter oben stehende Regeln immer 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 seinen 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 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 icon menu Aktionsmenü das Symbol icon rulesets 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:

Der Analysemodus mit der Ampel.

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:

icon rulenmatch

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

icon rulematch

Diese Regel greift und definiert einen oder mehrere 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 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.

4. Eigenschaften einer Regel

Jede Regel besteht aus drei Blöcken. Der erste Block enthält allgemeine Informationen zur Regel, wie z.B. den Namen der Regel. Im zweiten Block wird definiert, was die Regel machen soll, welche Aktionen also durch sie ausgeführt werden. Der dritte Block enthält die Informationen darüber, auf wen, d.h. auf welche Hosts oder Services, die Regel angewendet werden soll.

4.1. Allgemeine Optionen (Rule properties)

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

Allgemeine Regeloptionen.
  • 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 Login-Namen 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, 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:

Verschiedene Regelwerte mit Festlegung eines Wertes.

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:

Ansicht der Regelwerte bei Auswahl zeitabhängiger Parameter.

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:

Auswahl der positiven oder negativen Übereinstimmung.

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

4.3. 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:

Die Bedingungen für eine Regel.

Condition type

Hier haben Sie die Möglichkeit, neben einer normalen Bedingung auch auf vordefinierte Bedingungen (predefined conditions) zurückzugreifen. Diese werden über Setup > General > Predefined conditions verwaltet. Geben Sie hier 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:

Auswahl einer vordefinierten Bedingung für eine Regel.

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, 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 Regeln in höher liegenden.

Host tags

Die Host tags schränken die Regel auf solche Hosts ein, die bestimmte Host-Merkmale haben oder nicht haben. Auch hier wird immer mit UND verknüpft. Jede weitere Bedingung für Host-Merkmale 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 Test system). Eine andere Möglichkeit sind sogenannte Hilfsmerkmale.

Weil einige Anwender wirklich sehr viele Host-Merkmale verwenden, haben wir den Dialog so gestaltet, dass nicht sofort alle Host-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 Host-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 das gewünschte Merkmal als Vergleichswert.

Festlegung mehrerer Host-Merkmale in einer Bedingung.

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 auf die exakte Schreibweise einschließlich der Groß-/Kleinschreibung. Sonst wird die Bedingung nicht korrekt funktionieren.

Bedingung für Service-Labels.

Hinweis: Haben Sie weder Host tags noch Host labels definiert, wird die betreffende Regel immer auf alle Hosts bzw. Services angewendet. Haben Sie mehrere Regeln erstellt, so werden nachfolgende Regeln dadurch unter Umständen nicht mehr ausgewertet, siehe Arten der Regelauswertung.

Explicit hosts

Diese Art von Bedingung ist für Ausnahmeregeln vorgesehen. Hier können Sie einen oder mehrere Host-Namen auflisten. Die Regel gilt dann nur für diese Hosts. 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. Die Regel greift dann für alle Hosts außer den hier genannten.

Bedingung für explizit genannte Hosts.

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

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

  • Die Suche geht auf den Anfang des Host-Namens.

  • Die Suche ignoriert Groß-/Kleinschreibung.

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

Bedingung zur Host-Auswahl mit Platzhaltern.

Explicit services

Bei Regeln, die sich auf Services beziehen, gibt es als letzte Bedingungsart noch eine Suche auf den Namen des Services, bzw. bei Regeln, die Check-Parameter festlegen, auf den Namen des Check Items. Wonach genau gesucht wird, sehen Sie in der Beschriftung. In unserem Beispiel ist das der Name (Instance) eines Tablespaces:

Bedingung zur Service-Auswahl mit Platzhaltern.

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

Vergessen Sie nicht: Bei Regeln, in denen es um Explicit services geht, benötigen Sie eine Suche nach dem Service-Namen (z.B. Tablespace transfer). Bei Regeln mit Check-Parametern geht es um eine Suche nach dem Item (z.B. transfer). Das Item ist quasi der variable Teil des Service-Namens 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 Check-Typen haben folglich auch keine Bedingung dafür.

5. Regelauswertungen

Nun haben wir beschrieben, wie Regeln erstellt werden. Mit der Erstellung von Regeln ist es jedoch nicht getan. Im Beispiel des Abschnitts Regelbasiert ist besser reicht eine einzelne Regel nicht, um das gewünschte Ergebnis zu erreichen. Ein komplexeres System aus logisch aufeinanderfolgenden Regeln wird hierfür benötigt. Damit wird auch das Verständnis für das Zusammenspiel verschiedener Regeln bedeutsam.

5.1. 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:

Auswertung Verhalten

Erste Regel
(The first matching rule defines the parameter.)

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
(Each parameter is defined by the first matching rule where that parameter is set.)

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
(All matching rules will add to the resulting list.)

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.

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

Anzeige der geltenden Regelauswertung oberhalb der Regel.

5.2. Regelauswertung praktisch erklärt

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:

  1. Regel A: Host-1 alle 10 Minuten

  2. Regel B: Host-2 alle 20 Minuten

  3. Regel C: alle Hosts alle 30 Minuten (allgemeine Regel, um sowohl Host-3 als auch künftige Hosts abzudecken)

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

  • Für Host-1 trifft Regel A zu und wird angewendet. Die Benachrichtigung für Host-1 erfolgt im 10-Minuten-Takt. Damit ist die Bearbeitung für Host-1 abgeschlossen.

  • Für Host-2 trifft Regel A nicht zu. Weiter geht es mit Regel B. Diese trifft für Host-2 zu und wird angewendet, so dass für Host-2 im 20-Minuten-Takt benachrichtigt wird. Damit ist die Bearbeitung für Host-2 abgeschlossen.

  • Für Host-3 trifft Regel A nicht zu, ebenso wenig Regel B. Aber Regel C passt und wird angewendet: die Benachrichtigung für Host-3 erfolgt im 30-Minuten-Takt. Damit ist auch die Bearbeitung für Host-3 abgeschlossen.

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:

  1. Regel A: Host-1 alle 10 Minuten

  2. Regel C: alle Hosts alle 30 Minuten

  3. Regel B: Host-2 alle 20 Minuten

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:

Analysemodus für Host-2 nach Vertauschung der Regeln B und C.
Für Host-2 trifft auch die letzte Regel mit der gelben Kugel zu, wird aber nicht angewendet

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.

Auf dieser Seite