1. Einleitung
Checkmk unterstützt das Konzept der Labels, von denen Sie beliebig viele einem Host zuweisen können. Dabei verhalten sich Labels und Host-Merkmale (host tags) recht ähnlich:
Labels werden wie Merkmale an Hosts „gehängt“.
Labels können wie Merkmale als Bedingungen in Regeln verwendet werden.
Labels sind ähnlich wie Merkmale nach dem Prinzip
Schlüssel:Wert
aufgebaut.
Warum gibt es hier also ein neues Konzept? Nun — die IT-Welt ändert sich und wird viel dynamischer. Cloud- und Containersysteme wie Amazon Web Services (AWS), Microsoft Azure und Kubernetes erzeugen und löschen selbständig Objekte, die in Checkmk Hosts entsprechen. In diesen Technologien spielen Labels und Merkmale eine große Rolle, denn sie stellen die Verbindung zwischen den überwachten Objekten und ihrer Bedeutung her. Die Host-Namen hingegen werden zunehmend zufällig und nichtssagend.
Checkmk kann mit der dynamischen Host-Konfiguration solche dynamischen Hosts automatisch anlegen und bekommt dabei auch die Information über die dort bereits vorhandenen Labels/Merkmale. Diese können Sie dann für Regelbedingungen, Suchen, Auswertungen, Dashboards und andere Aufgaben verwenden.
Natürlich stellt sich die Frage, warum wir solche dynamischen Labels nicht einfach auf das vorhandene Konzept der Host-Merkmale abbilden. Und in der Tat ist das auch erst einmal sehr naheliegend. Allerdings haben Host-Merkmale eine sehr wichtige Eigenschaft, die das sehr schwierig und kompliziert machen würde: Welche Merkmalsgruppen und Merkmale es gibt, legen Sie bei Checkmk starr fest. Alles ist wohldefiniert. Jeder Host hat aus jeder Gruppe genau ein Merkmal. Alle können sich darauf verlassen. Tippfehler in der Schreibweise von Merkmalen können nicht vorkommen, ebenso wenig Hosts, die sich nicht an das Schema halten. Denn dessen Einhaltung wird von Checkmk streng kontrolliert. Bei sehr heterogenen Umgebungen mit vielen Tausend manuell gepflegten Hosts ist das wichtig und nützlich.
Dynamische Labels von Kubernetes und Co hingegen sind quasi „Freiform“. Und selbst wenn diese einem Schema folgen, ist dieses Checkmk überhaupt nicht bekannt. Außerdem überwachen Sie vielleicht mehrere unterschiedliche Plattformen, die wiederum Labels auf sehr unterschiedliche Art einsetzen.
Deswegen wurde mit den Checkmk-Labels ein Konzept eingeführt, welches bestens auf die wachsende Dynamik passt. Und Sie können die Labels natürlich auch ohne Anbindung an Cloud-Umgebungen nutzen.
Zur Beantwortung der Frage „Wann soll man Labels nehmen und wann Host-Merkmale?“ gibt es mehr Informationen im Artikel zur Strukturierung der Hosts.
Hier sind die Besonderheiten von Labels:
Labels müssen nirgendwo vordefiniert werden. Es gibt kein fixes Schema für Labels. Alles ist Freiform. Alles ist erlaubt.
Jeder Host kann beliebig viele Labels haben. Diese können manuell gepflegt sein, über Regeln definiert werden oder automatisch entstehen.
Labels sind nach dem Prinzip
Schlüssel:Wert
aufgebaut. Pro Schlüssel darf ein Host nur einen Wert haben. Also kann ein Host, der das Labelfoo:bar
hat, nicht gleichzeitigfoo:bar2
haben.Anders als die Host-Merkmale dürfen sowohl der Schlüssel als auch der Wert — bis auf den Doppelpunkt — beliebige Zeichen enthalten.
Es gibt keine Unterscheidung zwischen ID und Titel (oder angezeigtem Namen): Der Schlüssel des Labels ist beides gleichzeitig.
Labels haben folgende Aufgaben:
Sie bilden eine Grundlage für Bedingungen in Konfigurationsregeln, z.B. „Alle Hosts mit dem Label
os:windows
sollen so oder so oder sehr genau überwacht werden.“Sie können sehr einfach zusätzliche Informationen oder Anmerkungen zu einem Host speichern (z.B.
location:RZ 74/123/xyz
) und diese z.B. in Tabellenansichten anzeigen lassen.
2. Labels erstellen
2.1. Explizite 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:
![Dialog mit Eigenschaften eines Hosts zum Definieren von Labels.](../images/labels_host_properties.png)
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.
![]() |
Sowohl der Schlüssel als auch der Wert eines Labels dürfen jedes beliebige Zeichen enthalten — außer dem Doppelpunkt! Allerdings sollten Sie sich genau überlegen, wie Sie es mit der Groß-/Kleinschreibung halten. Denn wenn Sie später Bedingungen über Labels definieren, dann muss die Schreibweise sowohl beim Schlüssel als auch beim Wert strikt beachtet werden. |
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:
![Listeneintrag eines Hosts mit den zugewiesenen expliziten Labels.](../images/labels_host_list.png)
2.2. Labels über Regeln erzeugen
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:
![Regel für die Festlegung von Labels für Hosts.](../images/labels_rule_host_labels.png)
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.
2.3. Automatisch erzeugte Labels
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.
2.4. Label per Agentenplugin setzen
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:
<<<labels>>>
{"cpu/vendor": "zilog"}
Vermeiden Sie Konflikte mit den von Checkmk selbst und anderen Plugins automatisch vergebenen Labels, da keine bestimmte Reihenfolge der Auswertung garantiert werden kann.
2.5. Im Discovery Check gefundene Labels aufnehmen
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:
![Service-Liste mit dem Service 'Check_MK Discovery'.](../images/labels_discovery_check.png)
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:
![Regel für die regelmäßige Service-Erkennung.](../images/labels_rule_periodic_service_discovery.png)
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.
2.6. Reihenfolge der Labelzuordnung
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:
Zuerst gelten die expliziten Labels, also solche, die Sie im Setup direkt dem Host oder Ordner zuordnen.
An zweiter Stelle gelten Labels, die per Regeln erzeugt werden.
An letzter Stelle stehen die automatisch erzeugten Labels.
Durch diese Vorrangregeln haben Sie stets die letztgültige Kontrolle über die Labels.
3. Labels als Bedingungen in Regeln
3.1. Bedingungen in Regeln
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
.
Not
bedeutet also, die Bedingung A muss erfüllt und gleichzeitig die Bedingung B nicht erfüllt sein.And
bedeutet, dass sowohl die Bedingung A als auch gleichzeitig die Bedingung B erfüllt sein müssen.Or
bedeutet, dass entweder Bedingung A oder Bedingung B erfüllt sein müssen, aber auch beide Bedingungen erfüllt sein dürfen.
![]() |
Die Operatoren werden in genau dieser Priorität — |
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:
![Bedingung für Host-Labels.](../images/labels_props_labels.png)
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:
![mehrere Bedingungen für Host-Labels.](../images/labels_props_labels2.png)
![]() |
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. |
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.
3.2. Bedingungen in Benachrichtigungsregeln
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.
4. Labels in Tabellenansichten
Bisher haben wir fast ausschließlich über die Labels im Setup (oder der Konfigurationsumgebung) gesprochen. Auch in der Monitoring-Umgebung sind die Labels sichtbar, z.B. in der Statusansicht eines Hosts:
![Dialog mit dem Host-Status und den zugewiesenen Labels.](../images/labels_host_status.png)
Hier sehen Sie die Labels in den unterschiedlichen Farben, je nachdem, wie sie erzeugt wurden: Explizite Labels in violett, durch Regeln erzeugte in rot und per Discovery Check angelegte in gelb-ocker.
Die Farbtupfer der Label stechen nicht nur optisch aus der Ansicht hervor, sie sind dazu auch noch praktisch, weil anklickbar, und führen Sie dann zu einer Suche nach allen Hosts mit diesem Label weiter:
![Filterleiste mit Filter zur Suche nach einem Label.](../images/labels_search_filterbar.png)
Hier können Sie nach Hosts fahnden mit diesem Label (über die Vorgabe is) oder ohne dieses Label (mit der Option is not).
Auch bei der Label-Suche können Sie die booleschen Operatoren Not
, And
und Or
nutzen, analog wie sie unter Bedingungen in Regeln beschrieben wurden.
Um beispielsweise Linux-Hosts zu finden, die in München stehen und keine Web-Server sind, könnte der Filter dann wie folgt aussehen:
![Filterleiste mit 3 per logischen Operatoren verknüpften Label-Filtern.](../images/labels_filter_boolean.png)
Diesen Filter können Sie noch verfeinern, um z.B. (mit or) zusätzlich Windows-Hosts zu finden, die sowohl „headless“ als auch französisch sind (mit and). Die drei neuen Zeilen für diese Erweiterung des Filters können Sie direkt unter die bestehenden eintragen — oder Sie erstellen mit Add to query eine neue Gruppe, was den nunmehr komplexeren Filter besser lesbar macht, aber nichts an der Auswertung der booleschen Algebra ändert:
![Filterleiste mit 6 per logischen Operatoren verknüpften Label-Filtern.](../images/labels_filter_boolean_extended.png)
![]() |
Wenn Sie daran interessiert sind, welche Klammersetzung Checkmk aus den eingegebenen Label-Filtern erzeugt, können Sie sich die zugehörige Livestatus-Abfrage einblenden lassen. Dazu aktivieren Sie in den globalen Einstellungen Setup > General > Global settings > Debug Livestatus queries. |
Die Suche nach Labels können Sie natürlich auch mit den anderen verfügbaren Suchparametern in der Filterleiste kombinieren.
5. Service-Labels
Auch Services können Labels haben. Diese sind ähnlich zu den Host-Labels, allerdings mit ein paar kleinen Unterschieden:
Sie können Service-Labels nicht explizit vergeben. Diese können nur durch Regeln (Service labels) oder automatisch entstehen.
Auch mit Service-Labels können Sie Bedingungen formulieren. In einem Regelsatz werden Ihnen die Service-Labels nur dann zur Eingabe angeboten, wenn die Regel auf einen Service matchen kann.
6. Agenten-Labels
Die Checkmk Cloud Edition verfügt über die Möglichkeit, Hosts automatisch erstellen zu lassen.
Hierfür ist die gesamte Kette der Registrierung des Agenten, das Anlegen des Hosts, die Service-Erkennung und die Aktivierung der Änderungen automatisiert.
Das Anlegen des Hosts findet dabei nach der Registrierung statt.
Dieser Automatismus schafft einige Herausforderungen für die Strukturierung neu angelegter Hosts.
Bislang konnte das Betriebssystem (im Host-Label cmk/os_family
hinterlegt) erst aus der Agentenausgabe ermittelt werden.
Um diese zu bekommen, muss der Host jedoch bereits angelegt sein.
Aus diesem Grund wurde das Konzept der flüchtigen Agenten-Labels eingeführt, welche bereits bei der Registrierung übermittelt werden und damit vor der ersten Agentenausgabe bereit stehen. Während der Registrierung können Sie anhand dieser Labels bestimmen, ob ein Host überhaupt im Monitoring angelegt werden soll, und - falls dem so ist - seinen Ordner, aber auch andere Host-Attribute beeinflussen. Nach abgeschlossener Registrierung kann nicht mehr auf Agenten-Labels zugegriffen werden.
Zwei vordefinierte Agenten-Labels werden immer bei der Registrierung übertragen:
cmk/os-family
enthält die Betriebssystemfamilie (derzeitWindows
oderLinux
)cmk/hostname-simple
enthält den Computernamen in Kurzform (also ohne Domainpart)
Sie können weitere, benutzerdefinierte Agenten-Label frei vergeben, beispielsweise:
organizational/department:documentation
.
Automatisch registrierte Hosts erhalten das Host-Label cmk/agent_auto_registered:yes
.
Eine direkte Zuweisung von Host-Labels als Folge bestimmter Agenten-Labels ist nicht vorgesehen.
Sie können jedoch den Weg über die Registrierung in einem (temporären) Ordner und anschließender Zuweisung von Host-Labels für alle Hosts in diesem Ordner gehen.
7. Weitere Informationen
7.1. Automatisch generierte Host-Labels
Schlüssel | Werte |
---|---|
|
|
|
|
|
Name des zugehörigen AWS-Accounts |
|
Tags der AWS-Objekte |
|
Ressourcengruppen, der das Azure-Objekt angehört |
|
Tags der Azure-Objekte |
|
|
|
|
|
SNMP-übertragene Gerätebezeichnung, z.B. |
|
Docker-Image, z.B. |
|
Name des Docker-Images, z.B. |
|
Version des Docker-Images, z.B. |
|
|
|
Diese Bezeichnungen werden für jede Kubernetes-Beschriftung ausgegeben, die ein gültiges Kubernetes-Label ist (über die Regel Kubernetes konfigurierbar). |
|
|
|
Name des Kubernetes Clusters |
|
Name des Kubernetes Cluster-Hosts |
|
Kubernetes Cronjobs |
|
Name des DaemonSet |
|
Name des Deployments |
|
Name des zugehörigen Kubernetes Namespace |
|
Name des zugehörigen Kubernetes-Knotens. Checkmk-Hosts vom Typ Pod oder Node erhalten dieses Label. |
|
Kubernetes Objekttyp, z.B. |
|
Name des StatefulSet |
|
|
|
Typ des Meraki-Geräts, z.B. |
|
Netzwerk-ID des Meraki-Geräts |
|
ID der Organisation des Meraki-Geräts |
|
Organisationsname des Meraki-Geräts |
|
|
|
Betriebssystem, vom Agenten als |
|
Betriebssystemgattung, vom Agenten als |
|
Betriebssystemname, vom Agenten als |
|
Betriebssystemplattform, vom Agenten als |
|
Betriebssystemversion, vom Agenten als |
|
|
|
|