Labels

Einem Host können auf verschiedenen Wegen Labels zugeordnet werden.

Der erste davon ist einfach: Auf der Seite mit den Host-Eigenschaften, die angezeigt wird, wenn Sie im Setup einen Host erstellen oder bearbeiten, können Sie diesem beliebig viele Labels verpassen:

Aktivieren Sie Labels mit der Checkbox, klicken Sie dann in das Feld Add some label, geben Sie die Label-Definition in der Form Schlüssel:Wert ein und schließen diese mit Enter ab.

Ein bestehendes Label können Sie durch einen Klick in dessen Text editieren oder mit dem kleinen Kreuz wieder entfernen.

Natürlich können Labels auch von einem Ordner vererbt werden. Wie andere Attribute auch, können Labels in Unterordnern oder beim Host dann nach Bedarf wieder überschrieben werden — und zwar pro Label. Wird im Ordner z.B. das Label location:munich gesetzt, so wird dies an alle Hosts in diesem Ordner vererbt, welche nicht selbst das Label location definiert haben. Andere Labels, die ein Hosts eventuell hat, bleiben dadurch unberührt.

Beim Host oder beim Ordner explizit definierte Labels werden in der Liste der Hosts violett dargestellt:

Wie in Checkmk üblich, können Attribute auch per Regeln den Hosts und Services zugeordnet werden. Damit werden Sie unabhängig von der Ordnerstruktur. Dies gilt auch für die Labels. Dazu gibt es den Regelsatz Host labels, den Sie schnell über die Suche im Setup-Menü finden können.

Folgende Regel fügt allen Hosts im Ordner Bavaria mit dem Host-Merkmal Real Hardware das Label hw:real hinzu:

Vielleicht fällt Ihnen auf, dass bei den Bedingungen zu dieser Regel Labels nicht verwendet werden können. Das ist kein Fehler, sondern Absicht und vermeidet rekursive Abhängigkeiten und andere Anomalien.

Über Regeln hinzugefügte Labels werden rot dargestellt, tauchen allerdings nicht in der Host-Liste im Setup auf, sondern nur in der Statusansicht des Hosts.

Die dritte Art, wie Labels entstehen können, ist vollautomatisch. Verschiedene Datenquellen, wie z.B. die Spezialagenten für das Überwachen von Cloud- und Containersystemen erzeugen automatisch Labels. Im Speziellen sind hier die Spezialagenten für AWS, Azure und Kubernetes zu nennen. Mitunter werden diese Dinge auf den jeweiligen Plattformen auch als Tags bezeichnet und in Checkmk eben als Host- oder Service-Labels angelegt. Die jeweiligen Regelsätze geben darüber hinreichend Auskunft.

Das Schöne: Sie müssen gar nichts konfigurieren. Sobald diese Datenquellen aktiv sind, entstehen die entsprechenden Labels.

Im Abschnitt Automatisch generierte Host-Labels finden Sie eine Übersicht der Labels, die Checkmk automatisch generiert.

Ein einfacher Weg, Label direkt zu beeinflussen, ist die Ergänzung eines Agentenplugins, das analog zu lokalen Checks eine Sektion labels erzeugt. Sie können auf diese Weise Labels detaillierter als alleine durch Auswertung der HW-/SW-Inventur vergeben — beispielsweise nach Nuancen der verbauten Hardware (wie CPU-Features) oder tatsächlich laufenden Prozessen (statt nur installierter Software).

Die Label-Ausgabe ist hierbei als Python Dictionary zu formatieren, wie im folgenden Beispiel:

Vermeiden Sie Konflikte mit den von Checkmk selbst und anderen Plugins automatisch vergebenen Labels, da keine bestimmte Reihenfolge der Auswertung garantiert werden kann.

Falls Sie den Discovery Check aktiviert haben — und das ist bei neuen Installationen per Default der Fall — wird dieser Sie warnen, wenn neue Host-Labels gefunden wurden, welche noch nicht in die Host-Eigenschaften im Setup aufgenommen wurden. Das sieht dann z.B. so aus:

Sie haben zwei Möglichkeiten, auf diese Warnung zu reagieren. Die erste ist das Aufnehmen der neuen Labels, indem Sie im Setup die Service-Konfiguration des Hosts aufrufen und mit dem Menüeintrag Hosts > Update host labels die Konfiguration der Labels aktualisieren. Der Discovery Check wird bei der nächsten Ausführung (in bis zu zwei Stunden) dann wieder OK, selbst wenn Sie die Änderungen noch nicht aktiviert haben. Wenn Sie nicht so lange warten wollen, können Sie den Service auch sofort manuell aktualisieren durch Auswahl von Reschedule check im Aktionsmenü des Services.

Wenn das viele Hosts auf einmal betrifft, werden Sie sicher nicht für jeden einzelnen die Service-Konfiguration besuchen wollen. Führen Sie hier am besten die Bulk-Aktion zur Service-Erkennung durch (Run bulk service discovery) und wählen Sie als Modus Only discover new host labels — oder alternativ Add unmonitored services and new host labels, wenn Sie bei der Gelegenheit auch gleich neue Services aufnehmen wollen.

Die zweite Art, den Discovery Check grün zu bekommen, ist, dass Sie diesen so umkonfigurieren, dass er neue Labels nicht mehr anmahnt. Gehen Sie dazu in den Regelsatz Periodic service discovery und editieren Sie die bestehende Regel. Dort finden Sie die Option Severity of new host labels:

Diese ist per Default auf Warning eingestellt. Wählen Sie hier OK - do not alert, just display und der Check wird Ruhe geben.

Per Discovery Check gefundene Labels werden gelb-ocker dargestellt.

Theoretisch kann es sein, dass das gleiche Label in mehreren Quellen gleichzeitig und mit unterschiedlichen Werten definiert wird. Deswegen gibt es folgende Reihenfolge des Vorrangs:

Durch diese Vorrangregeln haben Sie stets die letztgültige Kontrolle über die Labels.

Eine wichtige Funktion von Labels ist die gleiche wie bei Host-Merkmalen: Nämlich ihre Verwendung als Bedingung in Regeln. Das ist vor allem bei automatisch erzeugten Labels interessant, weil Sie so ihr Monitoring vollautomatisch aufgrund von Informationen aus AWS, Azure, Kubernetes und Co anpassen können.

Fügen Sie Bedingungen mit Add to condition für die Host- oder die Service-Labels hinzu. Wählen Sie nun entweder is oder 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. Da Labels ohne Vorgaben festgelegt werden können, kann Checkmk Vertipper nicht erkennen. Immerhin: Beim Eintippen eines Labels schlägt Checkmk bereits existierende Labels vor, sofern sie zu ihrer bisherigen Eingabe passen. Bei den Vorschlägen wird nicht nach Host- und Service-Labels unterschieden: es werden alle passenden Labels angeboten. Achten Sie auf die korrekte Schreibweise, denn Buchstabendreher, falsche Groß-/Kleinschreibung etc. führen dazu, dass die Regel nicht mehr funktioniert.

Die Definition der Bedingung geht aber noch einen Schritt weiter: Um die Bedingung weiter zu verfeinern, stehen Ihnen zusätzlich die booleschen Operatoren Not, And und Or zur Verfügung. Dabei ist Not die Abkürzung für And Not.

Um beispielsweise Hosts mit dem Label cmk/site:heute aber ohne das Label cmk/piggyback_source_heute:yes zu finden, könnte die Bedingung wie folgt aussehen:

Diese Bedingung können Sie mit is oder not um beliebige weitere Vorgaben verfeinern. Oder Sie fügen mit Add to condition eine neue Gruppe von Bedingungen hinzu, was die nunmehr komplexere Bedingung besser lesbar macht, aber nichts an der Auswertung der booleschen Algebra ändert:

Sie können in einer Regel sowohl Labels als auch Host-Merkmale verwenden. Diese werden automatisch UND verknüpft. Die Regel greift also nur dann, wenn beide Bedingungen gleichzeitig erfüllt sind.

Auch in Benachrichtigungsregeln können Sie Labels als Bedingungen nutzen. Das funktioniert analog zu den anderen verfügbaren Bedingungen, so dass Sie sich hier nicht umgewöhnen müssen. Wählen Sie Match host labels und geben Sie einfach ein, welche Labels ein Host oder Service haben muss, damit durch die Regel eine Benachrichtigung ausgelöst wird. Auch hier werden mehrere Labels durch die UND-Verknüpfung verbunden.