NetBox in Minuten statt Wochen befüllen — mit KI und echten Datenquellen
Warum die meisten NetBox-Evaluierungen an der leeren Datenbank enden
Fast jedes Infrastruktur-Team, das man fragt, hat NetBox mindestens einmal angeschaut. Viele haben es wieder beiseite gelegt. Nicht weil das Tool nicht überzeugt hätte — sondern weil nach dem ersten Login eine leere Datenbank wartet, und irgendjemand sie füllen müsste.
Wer das einmal durchgerechnet hat, kennt das Ergebnis: 200 VMs bei Hetzner, 50 Instanzen bei Linode, ein Xen Orchestra Cluster mit dutzenden Guests, Netzwerke über OPNsense, DNS bei Cloudflare, ein halbes Dutzend VLANs hinter Unifi. Manuell übertragen sind das Tage bis Wochen. Und wer es durchzieht, stößt nach sechs Monaten auf das zweite Problem: Die Hälfte stimmt nicht mehr.
Das ist die unangenehme Wahrheit über CMDBs — sie liegen fast immer einen Schritt hinter der Realität. Der leere NetBox ist nur die sichtbare Variante eines permanenten Problems. Import und kontinuierliche Synchronisation sind nicht zwei Themen, sondern dasselbe Thema.
Warum das jetzt erst funktioniert
Die Idee, Infrastruktur-Quellen anzuzapfen, ist nicht neu. Netdisco, nautobot-device-onboarding, diverse Ansible-Rollen existieren seit Jahren. Was neu ist: Die Mapping-Logik zwischen „was die Quelle liefert" und „was NetBox braucht" ließ sich bisher nur als starres Skript formulieren — und jedes Skript scheiterte an der nächsten Sonderlocke.
LLMs können seit etwa 18 Monaten zuverlässig mit typisierten Tool-APIs arbeiten. DADL und MCP machen diese Tool-Calls deterministisch und auditierbar. Das verschiebt die Arbeit: Statt jedes Edge-Case vorher auszuprogrammieren, reicht eine saubere Tool-Definition, und der Agent erledigt die kontextabhängige Zuordnung.
Die Daten existieren schon — nur nicht in NetBox
ToolMesh stellt Konnektoren bereit, die strukturierten Zugriff auf Infrastruktur-APIs geben — nicht als generische REST-Wrapper, sondern als typisierte Tool-Definitionen, die ein KI-Agent sinnvoll nutzen kann.
Aktuell verfügbar sind unter anderem Hetzner Cloud, Linode, Xen Orchestra, Cloudflare, Unifi, Tailscale, OPNsense, Shelly Cloud und NetBox selbst. Die NetBox-DADL definiert das Mapping:
- Hetzner-Server und Linode-Instanzen werden zu Devices
- IP-Adressen werden zu IP Addresses mit korrekter Zuordnung
- Netzwerke und Subnetze werden zu Prefixes
- Standorte werden zu Sites und Regions
Der Unterschied zu einem klassischen Migrationsskript liegt nicht im Durchsatz, sondern im Umgang mit Ausnahmen. Ein Server ohne Reverse-DNS, eine IP, die zwei Netzwerken zugeordnet erscheint, ein VLAN mit inkonsistentem Namen — all das sind Fälle, an denen statische Imports typischerweise abbrechen oder stillschweigend Müll schreiben. Der Agent erkennt diese Fälle, versucht sie aufzulösen, und fragt im Zweifel zurück.
Wie das Mapping und der Abgleich technisch im Detail aussehen, beschreibt der begleitende Post auf toolmesh.io: Populating NetBox from Real Infrastructure .
Vier Phasen, weil Big-Bang scheitert
Ein berechtigter Einwand: Soll eine KI einfach frei in die Produktiv-CMDB schreiben? Natürlich nicht. Deshalb ist der Prozess in Phasen aufgebaut, die schrittweise mehr Autonomie gewähren.
Phase 1 — Import. NetBox ist leer, es gibt nichts zu verlieren. Der Agent liest Quelldaten und schreibt sie direkt. Fehler sind billig, weil nichts überschrieben wird. Ideal als Einstieg: schnelle Ergebnisse, minimales Risiko, ein Stand, von dem aus man weiterarbeiten kann.
Phase 2 — Diff. Das ist der eigentliche Kern. Der Agent liest die Quellen erneut, vergleicht mit dem Ist-Zustand in NetBox und gibt einen lesbaren Plan aus: neue Server bei Hetzner, dekommissionierte Instanzen bei Linode, geänderte IP-Zuweisungen. Keine Schreiboperationen — nur der Bericht, den man bisher mit selbstgebauten Skripten erzeugt hat. Viele Teams bleiben dauerhaft in dieser Phase, weil sie das Problem der driftenden CMDB bereits löst.
Phase 3 — Reconcile. Vorschläge, Review, Umsetzung. Bei Konflikten — etwa ein Server, der in NetBox als decommissioned markiert ist, bei Hetzner aber aktiv läuft — wird nachgefragt, statt stumm zu synchronisieren. Write-Operationen mit Audit-Trail.
Phase 4 — Autopilot. Kontinuierliche Synchronisation für unkritische Änderungen. Neue IP-Zuweisung? Wird übernommen. Plötzlicher Wegfall von 30% der Hetzner-Server? Wird eskaliert, nicht ausgeführt. Jede Aktion ist geloggt und revidierbar.
Der Kern dieses Modells: Fehler passieren. Menschliche und KI-basierte. Mit definierten Review-Punkten und gradueller Eskalation der Autonomie sind sie beherrschbar. Wer heute manuell in NetBox eintippt, macht auch Tippfehler — nur ohne Log.
Die Richtung kehrt sich um
Historisch läuft die CMDB der Realität hinterher. Server werden provisioniert, IPs neu vergeben, VMs verschoben — und irgendwann, wenn jemand Zeit findet, zieht die Dokumentation nach. Oft nicht vollständig. Oft gar nicht.
Wenn die CMDB aktiv ihre Quellen beobachtet und dazwischen vermittelt, kehrt sich diese Beziehung um: NetBox ist nicht mehr die Spur, die jemand hinter sich herzieht, sondern ein lebender Abgleich mit dem, was wirklich läuft. Das ist ein anderes Arbeitsmodell — und es ist weniger dramatisch, als es klingt, weil niemand auf einen Schlag alles automatisieren muss. Die vier Phasen erlauben, so weit zu gehen, wie das eigene Vertrauen reicht.
Wer NetBox evaluiert und vor der leeren Datenbank steht: toolmesh.io zeigt, wie der Einstieg in Minuten statt Wochen funktioniert — und wie er dort nicht endet. Technische Details zu Konnektoren und Mapping finden sich im technischen Blog-Post .