NetBox führt als Source of Truth den Soll-Zustand deines Netzwerks: jedes Gerät, jede IP, jeder Standort ist dort dokumentiert. Checkmk überwacht den Ist-Zustand und bekommt seine Host-Liste im Idealfall direkt aus NetBox, damit Doku und Monitoring nie auseinanderlaufen.
Wer NetBox und Checkmk getrennt pflegt, betreibt zwei Inventare parallel. Diese drei Probleme sehen wir dabei immer wieder.
Jede Änderung wird zweimal eingetragen: einmal in der Doku, einmal im Monitoring. Das kostet Zeit, und irgendwann vergisst jemand eine der beiden Seiten. Ab da lügen beide Systeme ein bisschen.
Das neue Gerät ist produktiv, dokumentiert, verkabelt. Nur ins Monitoring hat es niemand eingetragen. Das fällt genau dann auf, wenn es ausfällt und kein Alarm kommt.
Checkmk kennt Hosts, die in NetBox fehlen, und umgekehrt. Niemand weiß, welche Liste stimmt. Spätestens im Audit wird aus der Unschärfe ein Befund.
Checkmk ist ein Monitoring-System der Checkmk GmbH und im DACH-Raum weit verbreitet. Für die NetBox-Integration zählt vor allem eines: die REST-API.
Checkmk GmbH mit Hauptsitz in München, dazu US-Standorte in Atlanta und Minneapolis. Support und Doku sind auch auf Deutsch verfügbar.
Community (self-hosted, kostenlos), Pro und Ultimate (self-hosted, kommerziell) sowie Cloud als SaaS mit 99,5 % Verfügbarkeit und EU/US-Datenresidenz.
Aus Raw wurde Community, aus Enterprise Pro, aus Cloud Ultimate. In Checkmk 2.3 und 2.4 ändern sich nur die Titel, ab 2.5 auch interne Identifier. Das betrifft Skripte und Integrationen.
Die Integrationsbasis: Hosts anlegen per POST auf host_config, authentifiziert über einen Automation-User mit Bearer-Header. Änderungen werden erst nach Activate Changes wirksam.
Alle drei Wege nutzen dieselbe Basis: die NetBox-API als Quelle und die Checkmk-REST-API als Ziel. Sie unterscheiden sich in Betriebsaufwand, Flexibilität und Robustheit.
Regelbasiertes, modulares Sync-System von kuhn-ruess. Arbeitet dreistufig: Import aus Quellen, Rules Engine mit Attribut-Rewrites, Export nach Checkmk. Laut README mit über 140.000 Hosts getestet.
Passt, wenn du mehrere Quellen, Regeln und wenig Lust auf Eigenentwicklung hast.
Ein Python-Skript liest Geräte aus NetBox und schreibt sie per REST-API nach Checkmk. Läuft periodisch per Cron oder aus der CI.
Passt, wenn dein Anforderungsset klein und stabil ist.
NetBox-Webhooks feuern bei created-, updated- und deleted-Ereignissen, senden eine JSON-Payload inklusive Vorher/Nachher-Snapshots und laufen über eine Redis-Queue.
Passt als Ergänzung zu einem periodischen Sync, selten allein.
Der DCD (dynamische Host-Verwaltung) ist den kommerziellen Checkmk-Editionen vorbehalten und bringt Konnektoren für Piggyback (etwa AWS, Azure, VMware, Proxmox) und OpenTelemetry mit. Einen generischen NetBox- oder REST-Konnektor gibt es nicht: Für den NetBox-Sync brauchst du in jedem Fall den CMDBsyncer oder ein eigenes Skript. Sein eingebauter Löschschutz taugt trotzdem als Vorbild für deine eigene Sync-Logik. Welche Erweiterungen auf der NetBox-Seite helfen, zeigt unser Guide zu NetBox-Plugins.
Ein Sync ist mehr als ein Import. Er muss den kompletten Lebenszyklus eines Hosts abbilden, inklusive des Schrittes, den fast jeder beim ersten Mal vergisst.
Ein Gerät mit Status Active und primärer IP wird per POST auf host_config im passenden Folder angelegt. Praxis-Detail aus dem verbreiteten Community-Bauplan: Ein eigener Create-Trigger ist oft unnötig, denn monitorbar ist ein Gerät erst, wenn es eine IP-Adresse hat. Der Update-Trigger reicht.
Der Sync aktualisiert Attribute und Labels und verschiebt den Host bei Bedarf in einen anderen Folder. Konvention hilft: Wenn Region und Site die Folder-Hierarchie bestimmen, ist jeder Umzug in NetBox automatisch auch ein Umzug im Monitoring.
Verschwindet ein Gerät aus NetBox, sollte der Host nicht in derselben Sekunde aus dem Monitoring fliegen. Der CMDBsyncer entfernt Hosts erst nach einer Grace Period, der DCD löscht in den ersten 10 Minuten nach einem Serverneustart standardmäßig gar nicht. Beides sind gute Muster.
Checkmk übernimmt API-Änderungen erst nach einem separaten Activate: pending Changes abrufen, dann den activate-changes-Endpoint aufrufen, der ETag-Header ist dafür nötig. Wer diesen Schritt im Sync vergisst, wundert sich über eine wachsende Liste offener Änderungen.
Wichtig für alle Label-Ideen: Bedingte Logik ("wenn Tag X, dann Label Y, außer ...") gehört in deinen Sync-Code, nicht in die API-Payload. Die Checkmk-API wertet keine if-Bedingungen aus und quittiert solche Versuche mit einem 400-Fehler.
Die Reihenfolge ist bewusst gewählt: Erst die Daten, dann die Technik, dann die Automatisierung.
Der Sync ist nur so gut wie die Quelle. Ohne saubere Status-Werte und primäre IPs synchronisierst du Chaos.
In Checkmk ein eigener Automation-User für die API, in NetBox ein Token mit Leserechten.
Sites zu Foldern, Tags zu Labels, Custom Fields zu Attributen. Einmal aufschreiben, dann umsetzen.
Erst rechnen lassen, was passieren würde, dann schreiben. Beim CMDBsyncer per CLI inspizierbar.
Zeitplan oder Webhooks aktivieren, Activate Changes automatisieren, den Sync-Job überwachen.
Der Sync ist meist der Einstieg in ein größeres Thema: NetBox als Datenbasis für Ansible, Terraform und Co. Wie das zusammenhängt, liest du im Guide zur NetBox-Automatisierung.
Das Grundmuster jedes eigenen Sync-Skripts: Host anlegen, dann aktivieren. Python mit requests, authentifiziert als Automation-User.
Ein NetBox-Device wird mit Hostname, Folder und IP-Adresse als Host angelegt. Tags aus NetBox landen als Labels.
Host manuell in Checkmk anlegen, Folder suchen, IP abtippen
Sync legt den Host aus NetBox an, Attribute und Labels inklusive
Erst das Activate macht die Änderung wirksam. Der ETag aus den pending Changes wandert in den If-Match-Header.
Änderungen stapeln sich als pending, das Monitoring bleibt beim alten Stand
Host ist aktiv, Services werden erkannt und überwacht
Der Erst-Sync ist der einfache Teil. Diese drei Punkte entscheiden, ob die Integration nach einem Jahr noch Vertrauen genießt.
Nicht nur beim Erst-Sync: Nach jeder Mapping- oder Regeländerung erst berechnen lassen, was passieren würde. Der CMDBsyncer zeigt alle berechneten Ergebnisse vor dem Export per CLI, ein eigenes Skript braucht einen expliziten Dry-Run-Modus.
Ein Host, der aus der Quelle verschwindet, darf nicht sofort aus dem Monitoring fliegen. Grace Periods und Schwellwerte gegen Massenlöschung schützen dich vor einem fehlerhaften Export oder einer leeren API-Antwort.
Der Sync ist Infrastruktur: Alter des letzten Laufs, Fehlerquote und offene Activates gehören selbst ins Monitoring. Für die Gegenrichtung existiert eine frühe Checkmk-Extension, die NetBox selbst überwacht.
Was andere zum Thema NetBox und Checkmk wissen wollen.
Wir schauen gemeinsam auf deine NetBox-Datenqualität, dein Checkmk-Setup und den passenden Sync-Weg. Kostenfrei, unverbindlich, Praktiker zu Praktiker.
Wir melden uns innerhalb eines Werktages mit Terminvorschlägen. Im Gespräch klären wir Datenqualität, Sync-Weg und Aufwand, Praktiker zu Praktiker.