New "labelpicker": "labelpicker_ng" (Next Generation)

Hallo :slight_smile:
erst einmal vielen Dank an Ralf Prengel für die Idee und (Weiter‑)Entwicklung von labelpicker. Wir haben den ursprünglichen Labelpicker lange im Einsatz gehabt, bis er mit Checkmk 2.3 nicht mehr funktionierte. Da ich auf der Homepage (https://labelpicker.mk) längere Zeit keine neue Version gefunden habe, habe ich begonnen, den Labelpicker von Grund auf zu überarbeiten – und erst im Nachhinein entdeckt, dass Ralf im Checkmk Exchange bereits neuere Versionen veröffentlicht hat.

Mit Labelpicker NG möchte ich euch nun eine (fast) komplette Überarbeitung des ursprünglichen Labelpickers vorstellen, die speziell auf aktuelle Checkmk-Versionen ausgerichtet ist.

Was hat sich geändert?

  • Modularisiertes Backend
    Die ursprüngliche Logik wurde in mehrere Bibliotheken/Module aufgeteilt, um den Code klarer zu strukturieren, besser wartbar zu machen und zukünftige Erweiterungen zu erleichtern.
  • Konfiguration & Validierung mit Pydantic
    Sämtliche Konfigurationen (Checkmk-Anbindung, Logging, Datasources etc.) werden intern validiert, Default-Werte sauber gesetzt und – wo sinnvoll – vererbt. Fehlkonfigurationen führen zu deutlich aussagekräftigeren Fehlermeldungen.
  • Verbesserte YAML-Fehlerdiagnose
    Wenn ein Fehler in der YAML-Konfiguration auftritt, wird die konkrete Stelle (Zeile/Spalte) inklusive Kontext ausgegeben. Das erleichtert das Debugging von Tippfehlern und Strukturfehlern in der Config erheblich.
  • Komplett überarbeitetes Logging
    Labelpicker NG schreibt ein eigenes Logfile und erlaubt, unterschiedliche Log-Levels für Konsole und Logfile zu konfigurieren (z. B. DEBUG im File, INFO auf der Konsole). So kann man im Fehlerfall tief einsteigen, ohne die Konsole zu „zukleistern“.
  • Nachvollziehbares Aufräumen der erzeugten Labels
    Das Entfernen von durch Labelpicker erzeugten Labels wurde neu umgesetzt:
    Bei jeder Ausführung wird eine Pickle-Datei mit den von labelpicker NG gesetzten Labels geschrieben. Auf Basis dieser Historie können erzeugte Labels gezielt und sauber wieder entfernt bzw. bereinigt werden, ohne „fremde“ Labels anzufassen.
  • Neue Datasource: Active Directory
    Es gibt ein zusätzliches Plugin, um Labels anhand von AD-Gruppen zu erstellen.
    Typisches Einsatzszenario: AD-Gruppen, die Hosts/Servern zugewiesen sind (z. B. für automatisierte Windows-Updates), werden in Checkmk-Labels übersetzt – etwa zur automatisierten Steuerung von Downtimes oder Wartungsfenstern.
  • Neue Datasource: hwswtreeapi (Hardware-/Software-Inventory über API)
    Das frühere Auslesen der Inventardaten direkt aus den lokalen Inventory-Dateien wurde durch ein neues Plugin hwswtreeapi ersetzt. Die Hardware-/Software-Inventory-Daten werden jetzt über die Checkmk-API geholt und anschließend ausgewertet. Das ist robuster gegenüber Änderungen am Dateiformat, funktioniert auch bei verteilten Setups / Remote-Instanzen und erlaubt eine klar definierte, zukunftssichere Schnittstelle für Inventory-basierte Labels (inklusive Regex-Filtern und komplexen Pfaden im Inventarbaum).

Labelpicker ist bei entsprechender Konfiguration auch unabhängig von Checkmk lauffähig und muss nicht mehr im Kontext einer Checkmk Site laufen.

Und natürlich noch viele kleinere Verbesserungen und Aufräumarbeiten „unter der Haube“ …
Eine erste Test-Version von labelpicker NG könnt ihr hier herunterladen:

Feedback, Bugmeldungen und Verbesserungsvorschläge sind ausdrücklich willkommen!

5 Likes

Hello :slight_smile:

First of all, many thanks to Ralf Prengel / Philipp Lemke for the idea and (further) development of labelpicker. We used the original label picker for a long time until it stopped working with Checkmk 2.3.

Since I haven’t found a new version on the homepage (https://labelpicker.mk) for a long time, I started to revise the label picker from scratch – and only discovered afterwards that Ralf had already published newer versions in the Checkmk Exchange.

With labelpicker NG I would now like to introduce you to an (almost) complete revision of the original labelpicker, which is specially designed for current Checkmk versions.

What has changed?

  • Modularized backend
    The original logic has been split into several libraries/modules to structure the code more clearly, make it easier to maintain, and facilitate future extensions.
  • Configuration & Validation with Pydantic
    All configurations (Checkmk connection, logging, data sources, etc.) are validated internally, default values are set cleanly and – where appropriate – inherited. Misconfigurations lead to much more meaningful error messages.
  • Improved YAML error diagnosis
    If an error occurs in the YAML configuration, the specific location (row/column) including context is displayed. This makes it much easier to debug typos and structural errors in the config.
  • Completely redesigned Logging
    Labelpicker NG writes its own log file and allows you to configure different log levels for console and log file (e.g. DEBUG in the file, INFO on the console). In the event of an error, you can go deep without “pasting” the console.
  • The removal of labels created by Labelpicker has been reimplemented
    Each time it is executed, a pickle file is written with the labels set by labelpicker NG. On the basis of this history, created labels can be removed or cleaned up in a targeted and clean manner without touching “foreign” labels.
  • New Datasource: Active Directory
    There is an additional plugin to create labels based on AD groups.
    Typical application scenario: AD groups that are assigned to hosts/servers (e.g. forautomated Windows updates) are translated into Checkmk labels – for example, for automated control of downtimes or maintenance windows.
  • New datasource: hwswtreeapi (hardware/software inventory via API)
    The previous reading of inventory data directly from the local inventory files has been replaced by a new plugin hwswtreeapi. The hardware/software inventory data is now fetched via the Checkmk API and then evaluated. This is more robust against changes to the file format, also works with distributed setups / remote instances and allows a clearly defined, future-proof interface for inventory-based labels (including regex filters and complex paths in the inventory tree).
  • If configured accordingly, Labelpicker can also be run independently of Checkmk and no longer has to run in the context of a Checkmk site.

and in the latest version:

  • Remove a specific label
    You can remove a label from all hosts. The label to be removed can consist of the label (prefix/key) or only parts of it. If a key is specified, it must match exactly.
    For this purpose, the --remove <label> switch was introduced. It can also be used with the --testmode switch.
    Important: This switch is for removing old, no longer needed, or faulty labels! To remove labels created by the label picker, use the --cleanup switch!

And of course many smaller improvements and clean-up work “under the hood” …
You can download a first test version of labelpicker NG here:

Feedback, bug reports and suggestions for improvement are expressly welcome!

1 Like

Ich bin sehr happy über das ng plugin, es spart mir sehr viel Arbeit. Da wir hauptsächlich Cisco Switche im checkmk monitoren und ein Host label mit dem Model Name das Gruppieren etc. vereinfacht. Somit lassen sich einfach Host Groups vom gleichen Switchtyp erstellen.

Bis ich jedoch genau verstanden hatte, wie die labelpicker_ng.yml zu konfigurieren ist, hat es etwas try&error gebraucht. Sieht dann bei uns so aus:


#Datasource: HwSwTree with Checkmk file access to the inventory

name: Hardware-Software-Inventory
module: lpds_hwswtree
label_prefix: hwsw
config:
mapping:

  - labelname: os_name
    tree: [Software, Operating System, type]

  - labelname: contact
    tree: [Software, Configuration, snmp_info, contact]

  - labelname: model
    tree: [Hardware, System, model]

  - labelname: serial
    tree: [Hardware, System, serial]

  - labelname: os_version
    tree: [Software, Operating System, version]

Im GUI beim “Inventory of host” sind manche Informationen mit anderen Namen dargestellt, z.B. Software → Configuration → SNMP Information muss letzteres als “snmp_info” in der yml konfiguriert werden. Aber man bekommt ja einige Werte aus der host Datei unter /omd/sites/[site_name]/tmp/check_mk/data_source_cache/snmp/inventory

Aber leider werden nicht alle Switchmodele gleich ausgelesen. Z.B. ein WS-C2960X-24PD-L liefert kein Hardware → System → Model name

Sondern der Model name wird unter Hardware → Physical components → Chassis angezeigt. Hierzu habe ich bisher noch keine tree: Konfiguration in der yml erfolgreich erstellen können. Aber vielleicht hat ja jemand eine Idee?

1 Like