Checkmk Tags erstellen: Services sauber zuweisen und eigene Funktionen hinterlegen

Wer Checkmk „einfach nur laufen lässt“, bekommt schnell viele Daten – aber nicht automatisch effizientes Monitoring. Spätestens wenn mehrere Standorte, unterschiedliche Systemkritikalitäten, gemischte Betriebssysteme oder Spezialfälle (z. B. Cluster, Appliances, DMZ-Hosts) dazukommen, stellt sich eine praktische Frage: Wie bekomme ich Regeln, Checks und Benachrichtigungen so sortiert, dass sie automatisch passen – ohne diese Checks und Services einzeln für jeden Host entsprechend zu konfigurieren?

Genau hier helfen Checkmk Tags (in der deutschen Doku oft „Host-Merkmale“). Richtig eingesetzt sind Tags die Grundlage, um Checkmk zu personalisieren, Regeln sauber zu schneiden und sogar eigene Funktionen/Skripte kontrolliert auszurollen.

Was sind Checkmk Tags überhaupt?

Host-Tags sind vordefinierte Merkmale, die Sie einem Host zuweisen. Wichtig ist dabei: Tags hängen immer an einem Host (nicht an einem Service). Sie werden in Tag-Gruppen organisiert, und pro Tag-Gruppe kann ein Host genau einen Tag auswählen.

Ein Klassiker ist die (oft vorhandene) Tag-Gruppe „Criticality“ bzw. „Kritikalität“. Dort wählen Sie beispielsweise „Produktiv“, „Test“, „Unkritisch“.

Checkmk unterscheidet hier außerdem zwischen:

• Host-Tags (Host-Merkmale): Streng vordefiniert, in Tag-Gruppen organisiert. Sehr gut für klare Regel-Schnitte.
• Labels (Host-Labels): Flexibler, können dynamisch erzeugt werden und sind nicht so „starr“ wie Tags. Labels eignen sich, wenn Sie dynamische Metadaten brauchen (z. B. aus Cloud-Discovery). (docs.checkmk.com)

Für viele Admin-Setups gilt in der Praxis: Tags für stabile Klassifikationen, Labels für dynamische/automatisch gelernte Eigenschaften.

Einfach gesagt: Tags sind diese auswählbaren Boxen, wenn Sie einen Host anlegen.

Wie funktionieren Tags in Regeln?

Tags wirken nicht direkt „magisch“. Der Effekt entsteht dadurch, dass Sie in fast allen Rulesets die Bedingung „Host tags“ setzen können. Dann greift die Regel nur für Hosts, die bestimmte Tags haben (oder eben nicht haben). In der Regelbearbeitung fügen Sie dazu eine Tag-Bedingung hinzu („Add tag condition“). (docs.checkmk.com)

Sprich, diese Tags sind bestimmten Checks oder Services zugeordnet. Wenn Sie ein Tag bei einem Host auswählen, dann wird der entsprechende Check bzw. Service für diesen Host ausgeführt.

So könne Sie „Checkmk richtig nutzen“: Nicht indem Sie alle Regeln einzeln konfigurieren und riesen Listen an Hosts in diese Regeln eintragen sondern indem Sie Eigenschaften/Tags erstellen und diesen Checks oder Services zuweisen.

Das macht Ihre Arbeit um einiges leichter und weniger fehleranfällig.

Was bringt mir das konkret?

Tags lösen typische Alltagsprobleme in Checkmk:

• Weniger Ausnahme-Regeln: Ein sauberer Tagschnitt reduziert Regelwildwuchs.
• Skalierung: Neue Hosts bekommen automatisch die passenden Checks/Parameter, wenn die Tags stimmen.
• Bessere Lesbarkeit: Regeln nach Tags sind deutlich verständlicher als Regex auf Hostnamen.
• Stabilere Automatisierung: Tags sind kontrolliert (Tag-Gruppe + Auswahl), daher weniger fehleranfällig als „freie“ Texte.
• Weniger Konfigurationsaufwand: Wenn Sie einen neuen Host anlegen, müssen Sie sich nicht mehr durch riesen Listen an Checks und Services wälzen, um die passenden zu finden und diese Hosts dort zu hinterlegen.

Wenn Sie Checkmk Personalisieren wollen, sind Tags oft der schnellste Hebel, weil Sie damit das Regelwerk strukturieren, statt es zu verkomplizieren. Außerdem können Sie auch eigene Scripte in Checkmk mit integrieren und diesen dann passenden Tags zuweisen.

Wie genau Sie eigene Scripte erstellen und diese in Checkmk anlegen, sehen Sie in unserem Beitrag „Custom Checks in Checkmk: eigene Scripte sauber integrieren und als Local Check ausrollen„. Wie genau man diese Checks dann den Tags zuordnet, dazu gleich mehr.

Checkmk Tags erstellen: Tag-Gruppen und Tags anlegen

Das Anlegen der Tags ist recht simpel. Als Erstes gehen Sie auf Setup (in der linken, vertikalen Aktionssammlung) und suchen dort nach dem Stichwort Tag. Unter der Überschrift Setup sollten Sie den Menüpunkt dann finden. Das klicken Sie an.

In der nächsten Maske, klicken Sie dann, links oben auf Add tag group um ein Tag zu erstellen und zu konfigurieren.

Nun sind Sie in der Tag-Konfigurationsmaske. Hier müssen wir einige Dinge einstellen.

• Die Tag group ID: Diese Einstellung sehen Sie später beim Anlegen der Hosts nicht. Diese dient nur der Zuordnung innerhalb der Tagliste in der vorherigen Maske.
• Der Titel: Diesen sehen Sie später. Das ist der Name dieses Tags, links von der Checkbox (Wie genau das aussieht, sehen Sie nochmal in dem Bild unter dieser Liste).
• Das Topic: Das ist die Überschrift, unter der dieses Tag später zu finden ist. Sie können eine neue erstellen oder eine bestehende nutzen.
• Help: Hier können Sie Ihren Tag beschreiben. Das hilft, wenn Sie sich nach langer Zeit nicht mehr erinnern können, was genau ein Tag tut.
• Die Tag choices: Diesen Punkt sehen Sie beim Anlegen eines Hosts rechts neben der Checkbox.

Erstellen Sie am besten ein Test-Tag mit verschiedenen Attributen in jedem Feld und gehen dann in die Hostkonfiguration. Dort können Sie dieses Tag mal anschauen und auswählen, dann sehen Sie die Funktionsweise live.

Checkmk kann außerdem anzeigen, wo Tags im Einsatz sind (Tag usage). Das ist hilfreich, wenn Sie Tag-Strukturen ändern und Nebenwirkungen vermeiden wollen. Aber das geht etwas zu weit in die Tiefe. Wenn Sie das Thema interessiert dann klingeln Sie doch mal bei uns vorbei! Wir helfen Ihnen gerne.

Praxis-Tipp: Tag-Gruppen so schneiden, dass Regeln stabil bleiben

Ein häufiger Fehler ist, Tag-Gruppen zu „technisch“ oder zu „kleinteilig“ zu gestalten. Gute Tag-Gruppen beschreiben Dinge, die sich selten ändern:

• Kritikalität
• Standort/Netzsegment
• Betriebsmodell (On-Prem, Cloud)
• Check-Typ (Agent, SNMP, Spezial)

Wenn Sie anfangen, Tags für kurzlebige Zustände zu nutzen („heute Wartung“, „gerade Test“), kippt das Regelwerk in Handarbeit.

Wie verbinde ich Tags mit einem Service?

Direkt gar nicht – und genau das ist der Punkt, der am Anfang oft verwirrt.

• Tags hängen am Host.
• Services (Checks) hängen am Host und werden per Discovery erzeugt oder per Regel hinzugefügt/parametriert.

Die Verbindung entsteht über Rulesets:

• Sie setzen in einem Ruleset eine Host-Tag-Bedingung.
• Die Regel verändert dann Service-Parameter, Service-Monitoring, Discovery-Verhalten, Benachrichtigung usw.

Sie machen das folgendermaßen:

1. Sie gehen wieder auf Setup und suchen dort nach den service monitoring rules. Diese klicken Sie an.

Hier wählen Sie sich nun einen Service aus und öffnen ihn. Innerhalb des Service können Sie nun auf Add rule klicken, so kommen Sie in die Konfigurationsmaske dieses Services und können das gewünschte Tag hinterlegen.

Wenn Sie diesen Knopf gedrückt haben, können Sie dann unten, unter der Überschrift Conditions ein Host Tag auswählen. So wird dieses Tag dann der Funktion hinter diesem Service zugeordnet und ausgeführt, wenn Sie es dann bei der Konfiguration eines Hosts auswählen.

Active Checks sind in Checkmk als Rulesets verfügbar (HTTP, TCP, SSH, …).dort geht das genau so.

Wie und wo kann ich den Tag auswählen – und was passiert dann?

Den Tag wählen Sie in den Host-Eigenschaften (Host Properties) des jeweiligen Hosts oder über Ordnerregeln/Host-Templates (je nach Struktur). Sobald Sie den Tag speichern:

• Regeln, deren Bedingungen auf diesen Tag passen, greifen beim nächsten Aktivieren der Änderungen.
• Service-Discovery kann sich ändern, wenn Sie Discovery-Regeln nach Tags geschnitten haben.
• Parameter-Regeln (z. B. Schwellwerte) greifen für bereits vorhandene Services.

Wichtig: Nach Tag-Änderungen lohnt sich oft eine gezielte Service-Discovery auf dem Host (oder eine Automation), wenn Discovery-Regeln im Spiel sind.

Wenn Sie als Einstieg noch Grundlagen brauchen: In unserem Beitrag „Was ist Checkmk?“ ordnen wir die wichtigsten Bausteine (Agent, Discovery, Regeln) einmal ein.

Eigene Funktionen hinterlegen: Custom Scripts per Tag steuern (praxisnah)

Je nachdem, was genau Sie bevorzugen oder für Ihren spezifischen Fall brauchen, können Sie:

• Dem Script ein Tag hinterlegen und dieses dann den gewünschten Hosts zuweisen. Das bedeutet, dass das Script dann immer gemeinsam mit dem Checkmk Agenten gestartet wird.
• Das Tag dynamisch einer Gruppe von Labels zuweisen.
• Eine zeitgesteuerte Konfiguration einrichten. In diesem Fall würde das Script zu bestimmten Zeiten laufen.

Schauen wir uns das mal genauer an:

Baustein 1: Custom Checks als Local Check

Für eigene Skripte ist der Local-Check-Mechanismus ein sauberer Standardweg: Ein Skript erzeugt eine Zeile im Local-Check-Format, und der Agent liefert diese Daten an Checkmk.

Checkmk dokumentiert dazu auch Details wie Multi-Line-Ausgaben und Einschränkungen (z. B. Umgang mit Newlines).

Wenn Sie tiefer in die saubere Integration wollen (inkl. Ausrollen/Einbindung), passt dieser ADMIN-INTELLIGENCE-Artikel direkt dazu: „Custom Checks in Checkmk: eigene Scripts sauber integrieren und als Local Check ausrollen“. Dort erkläen wir Ihnen genau, wie Sie Ihre eigenen Checks in Checkmk integrieren.

Das Hinterlegen des Tags funktioniert dann genau so, wie bei den Checkmk-Services, die oben beschrieben wurden.

Baustein 2: Ausrollen über Agent Bakery – aber aktivieren über Tag

Das typische Muster in der Praxis:

• Sie rollen das Skript (oder eine Konfiguration) technisch per Agent Bakery / Softwareverteilung aus.
• Ob das Skript „aktiv“ ist, steuern Sie über eine Konfigurationsdatei oder einen Wrapper.

Tag-basierte Steuerung erreichen Sie dann nicht dadurch, dass das Skript „den Tag kennt“ (der Tag sitzt in Checkmk), sondern über die Kombination:

1. Tag setzt eine Regel in Checkmk.
2. Diese Regel sorgt dafür, dass ein Host ein Label bekommt oder eine Konfiguration erhält.
3. Das Skript reagiert auf dieses Signal.

Der wichtigste offizielle Hebel dafür sind Labels: Checkmk kann Labels per Regel abhängig von Tags vergeben. Die Doku beschreibt genau, warum Labels hier flexibler sind und wie Regeln Labels setzen können (z. B. „wenn Tag X, dann Label hw:real“). (docs.checkmk.com)

Das ist ein gutes, robustes Modell:

• Tag: „backup:gold/silver/bronze“
• Regel: Wenn backup=gold, setze Label backup_tier:gold
• Skript/Check: wertet backup_tier aus (z. B. via API/Agentdaten je nach Implementierung) oder Sie nutzen das Label in Regeln zur Service-Zuordnung.

Baustein 3: Local Checks via Spool-Dateien (wenn Sie zeitgesteuert arbeiten)

Wenn ein Skript nicht bei jedem Agent-Lauf ausgeführt werden soll (z. B. ein längerer Backup-Check), können Sie die Ergebnisse über Spool-Dateien bereitstellen. Checkmk beschreibt das Spool-Verzeichnis und dass Spool-Dateien beliebige Agentdatenformate enthalten können, inklusive Local-Checks, und dass ein Abschnittsheader verwendet wird. (docs.checkmk.com)

Das ist in der Praxis oft die bessere Lösung für Checks, die:

• nur alle X Minuten laufen sollen
• externe APIs abfragen
• Lastspitzen vermeiden müssen

Wozu kann man Tags noch nutzen?

Tags sind nicht nur „Regel-Filter“. Im Alltag nutzen Admins sie typischerweise für:

• Benachrichtigungen: andere Eskalationsketten nach Kritikalität/Standort
• Kontaktgruppen-Zuordnung: Regeln können Hosts automatisch Gruppen zuweisen, wenn Sie Hostmerkmale sinnvoll schneiden (das Prinzip wird auch in Community-Diskussionen häufig genutzt) (forum.checkmk.com)
• Discovery-Steuerung: Dienste automatisch hinzufügen oder weglassen, abhängig von Hosttyp/Tag (z. B. Appliances vs. Server)
• Views/Dashboards: Filter nach Tags für Betriebsübersichten (z. B. „alle WAN-Systeme“)

Wenn Sie ein konkretes Ziel haben (z. B. „alle Proxmox-Backups anders behandeln“), dann ist das Tag-Modell meist stabiler als Namenskonventionen. Passend dazu: „Proxmox Backups mit Checkmk überwachen“ zeigt typische Muster, wie man Monitoring sauber operationalisiert.

Troubleshooting: typische Fehlerbilder bei Checkmk Tags

Regel greift nicht, obwohl der Tag gesetzt ist

Prüfen Sie der Reihe nach:

• Tag wirklich am Host gesetzt? Nicht am Ordner „gedacht“, sondern im Host-Objekt sichtbar.
• Regel-Reihenfolge / Regel-Set: Greift eine andere Regel früher und überschreibt Parameter?
• Bedingung korrekt gesetzt? In Regeln müssen Sie die Tag-Bedingung explizit hinzufügen (Add tag condition).
• Änderungen aktiviert? (Klassiker, aber passiert.)

Tag-Struktur geändert und plötzlich ist „Chaos“

Wenn Sie Tag-Gruppen/Tags umbauen, prüfen Sie die „Tag usage“-Auswertung, um zu sehen, wo Tags verwendet werden. Das reduziert Überraschungen bei Regeln und Ordnern. (docs.checkmk.com)

Sie brauchen eigentlich Labels statt Tags

Wenn Sie versuchen, Dinge wie „Region=eu-central-1“ oder „InstanceType=t3.medium“ als Tags abzubilden, arbeiten Sie gegen das System. Tags sind bewusst „rigid“. Für dynamische Cloud-Metadaten sind Labels sinnvoller.

Local Check liefert nichts / Service erscheint nicht

Typische Ursachen:

• Skript liegt nicht im richtigen Agent-Kontext oder wird nicht ausgeführt.
• Ausgabe entspricht nicht dem Local-Check-Format.
• Zeilenumbrüche in Plugin-Output (Checkmk beschreibt die Einschränkung und mögliche Maskierung).
• Spool-Datei ohne korrektes Section-Header-Format im Spool-Verzeichnis (bei Spool-Ansatz).

Wenn Sie das Thema „Custom Checks“ gerade angehen, ist der strukturierte Weg über unseren Beitrag zu Local Checks meist der schnellste, weil dort die gängigen Stolpersteine einmal am Stück abgearbeitet sind: Custom Checks in Checkmk.

Kurzer Praxis-Workflow: so nutzen Sie Tags für „effizientes Monitoring“

Wenn Sie das Ganze als wiederholbares Vorgehen etablieren wollen:

1. Tag-Gruppen definieren (max. 4–8, fachlich sinnvoll).
2. Pro Gruppe Tags definieren, die Regeln später sauber schneiden.
3. In Rulesets konsequent Host tags als Bedingungen einsetzen, statt Hostlisten.
4. Für „Funktionen“ (eigene Checks) Local Checks/Spool nutzen und die Aktivierung über Tag→Regel→(Label/Parameter) steuern.

So wird „Checkmk Tags“ nicht nur ein UI-Feature, sondern Ihr Werkzeugkasten zum Checkmk Personalisieren.

Wenn Sie Checkmk in Ihrer Umgebung gerade aufräumen oder ein Regelwerk von „gewachsen“ auf „wartbar“ umbauen möchten, lohnt sich meist ein kurzer technischer Blick von außen. Auf unserer Seite zu Checkmk on premise beschreiben wir, wie wir Installationen, Regelwerke und Custom-Checks in der Praxis unterstützen. Für mehr praktische Artikel rund um Checkmk richtig nutzen finden Sie laufend neue Beiträge auf https://blog.admin-intelligence.de/ – und wenn Sie konkrete Fragen zu Ihrer Tag- und Regelstruktur haben, erreichen Sie uns unkompliziert über https://www.admin-intelligence.de/kontakt/.

Sie sehen also, das Thema Tags ist gar nicht mal so einfach wie erwartet und natürlich konnten wir hier nicht auf alle Details eingehen. Wir raten Ihnen, nehmen Sie sich ausreichend Zeit und testen Sie die Funktionsweise von Tags. So können Sie sehen, was genau in der Praxis passiert und entwickeln ein tieferes Verständniss dafür. Wenn Ihnen das nicht reicht, rufen Sie uns an. Wir bieten Checkmk Installationen, Konfigurationen, Personalisierung, Support, Custom Scripting und auch Demo-Termine an, in denen wir Ihnen alles Wichtige zum Thema Checkmk erklären und alle Ihre Fragen beantworten.