Sag mir, wo die Geräte sind

von Martin Loschwitz

NetBox arbeitet als DCIM und IPAM und erlaubt durch sein umfassendes API hilfreiche Integrationen in das Monitoring. So zum Beispiel in der Automatisierung, für die NetBox die zu überwachenden Systeme als zentrale Quelle im Netzwerk bereitstellt. Damit das funktioniert, muss das genutzte Monitoringsystem allerdings eine Schnittstelle zu NetBox haben. Welche Mittel und Wege existieren, um NetBox-Geräte automatisiert zu überwachen, zeigt dieser Workshop.

Mit Cloud- und Container-Technologien hat sich das Monitoring fundamental verändert. Wo früher monolithische Systeme für Event-Monitoring wie Nagios oder Icinga vorrangig den Ton angaben, ist die Branche heute dynamischer. Längst ist etwa beim Bau eines Setups nicht mehr klar, wie viele Systeme die Umgebung letztendlich umfasst – insbesondere bei virtuellen Hemisphären. Denn hier dominieren heute flexibel skalierbare Clouds oder Container-Umgebungen, in denen einzelne Instanzen von Diensten aus dem Nichts auftauchen und bei wenig Last ebenso schnell wieder verschwinden.

Unter dem Oberbegriff "Monitoring, Alerting, Trending" hat sich eine neue Klasse von Überwachungswerkzeugen etabliert: Prometheus etwa fängt nicht mehr die Meldungen einzelner Dienste auf Systemen ab, stattdessen überwacht es die Zustände von Diensten und zieht daraus im Hintergrund Rückschlüsse. Dadurch kann es penibel mitschreiben, welche Services gerade wo in der Plattform laufen, wann ein Skalieren in die Breite nötig ist und wann die Plattform schrumpfen darf, um nicht unnötig Ressourcen zu vergeuden.

Die neue Art, IT-Systeme skalierbar zu bauen, hat auch an anderen Stellen zu neuen Methoden geführt: So wichtig wie nie ist im Rechenzentrum beispielsweise das möglichst umfangreiche Überwachen der vorhandenen Assets. Blech will dabei ebenso im Blick behalten sein wie jede virtuelle Instanz und jeder virtueller Container. Das hat zum Aufstieg einer eigenen Art von Werkzeug geführt, den DCIM-Tools (Datacenter Inventory Management). Neu ist das Konzept zwar ebenso wenig wie das Management von IP-Adressen (IPAM; IP Address Management). Doch im dynamischen RZ der Gegenwart ist es viel wichtiger als vorher, den Überblick zu bewahren. NetBox [1] gilt als Königsweg in Sachen DCIM und IPAM. Das Werkzeug verzeichnet alle vergebenen IP-Adressen, Hardware, Kabel und im System laufenden virtuelle Instanzen. Vorausgesetzt freilich, der Administrator füttert es mit den richtigen Daten. Nicht weniger als die universelle Single Source of Truth will NetBox sein – jene Stelle also, an der zentral verzeichnet ist, was existiert und was in Sachen Netz wie konfiguriert ist.

Monitoring muss sich anpassen

Doch derartige Werkzeuge führen vielerorts zu grotesken Situationen. Dabei läuft zwar NetBox, doch die Monitoringwerkzeuge erhalten ihre Konfiguration weiterhin per Textdatei – mit viel Glück aus einem Git-Verzeichnis im Rahmen von Infrastructure-as-Code. Mit der Single Source of Truth ist es spätestens dann vorbei, weil es erfahrungsgemäß selbst bei größter Sorgfalt kaum gelingt, die Inhalte des Monitorings und jene in NetBox deckungsgleich zu halten. Und der Mehraufwand durch die Pflege mehrerer Informationsquellen ist dabei als Problem noch gar nicht zur Sprache gekommen.

Dabei geht es auch anders, denn diverse Monitoringanwendungen lassen sich nativ mit NetBox koppeln. Die Informationen zu den zu überwachenden Geräten kommen dann dynamisch aus DCIM und IPAM, sodass das Hinzufügen eines Geräts in NetBox im besten Fall dazu führt, dass dieses auch gleich automatisch der Überwachung unterliegt. Das händische Eintragen von Systemen in das Monitoring gehört dann der Vergangenheit an. Entfernt der Administrator Systeme aus NetBox, sind sie vermutlich dekommissioniert und dürfen auch aus dem Monitoring verschwinden. Wir zeigen anhand der Beispiele Prometheus, Icinga, Zabbix und Checkmk, wie die Integration von Monitoring und NetBox aussehen kann, auf welche Faktoren zu achten ist und wie eine gelungene Kopplung gelingt. Den Anfang macht dabei Icinga als Vertreter der klassischen Event-Monitoringwerkzeuge.

Icinga Director verwaltet Zusammenspiel

Praktischerweise lässt sich Icinga verhältnismäßig leicht an NetBox andocken, denn es verfügt über eine native NetBox-Schnittstelle. Diese ist passionierten Icinga-Administratoren freilich ein Begriff, denn in aktuellen Icinga-Setups ist der "Director" Dreh- und Angelpunkt der Plattformkonfiguration. Icinga stammt bekanntlich von Nagios ab, auch wenn moderne Icinga-Versionen damit nur wenig gemein haben. Eine ganze Weile hat Icinga allerdings das klassische Konfigurationsmuster aus Nagios noch mit sich herumgeschleppt, auch lange nachdem es als eigenständiges Projekt existierte. Der Icinga Director hat dem Treiben ein Ende bereitet und fungiert als Konfigurationszentrale (Bild 1), über die sich praktisch sämtliche Einstellungen steuern lassen.

Das Icingaweb2-NetBox-Modul verbindet sich im Hintergrund mit NetBox und lädt – abhängig von der Konfiguration – die Assets von dort herunter, um sie als eigenständige, zu überwachende Instanzen in Icinga anzulegen. Eingerichtet ist das Plug-in schnell. Unter Ubuntu laden Sie das Modul [2] zunächst herunter und entpacken es anschließend nach "/usr/share/ icingaweb2/modules/netbox". Dann aktiviert das Kommando icingacli module enable netbox das Plug-in. Seine Konfiguration finden Sie in der Administrationsspalte des Icinga-Directors, wo Sie im Wesentlichen zwei Parameter eintragen: den Pfad zur NetBox-API, im Regelfall "https://netbox.example.net/api" sowie ein API-Token aus NetBox für den Zugriff darauf. Über die Schaltfläche "Object type to import" legen Sie fest, welche Objektarten aus dem API zu importieren sind. So lässt sich etwa bestimmen, ob nur physische Hardware ihren Weg in NetBox finden soll oder ob etwa auch virtuelle Instanzen zu überwachen sind.

Dieses Vorgehen versorgt Sie mit zahlreichen Konfigurationsoptionen. So lassen sich in NetBox hinterlegte Kontaktadressen für einzelne Geräte übernehmen und als Teil einer Alarmierungskette in Icinga definieren. Alarme erreichen dann beispielsweise bei Fehlern mit Netzwerkgeräten, die Icinga aus NetBox übernommen hat, andere Personen als bei Problemen mit Linux-Servern. Darüber hinaus können Sie die Daten aus NetBox in Icinga mannigfaltig modifizieren und manipulieren, um sie in Einklang mit den dort bereits hinterlegten Daten zu bringen. Schließlich lassen sich für die aus Icinga importieren Objekte ebenso Checks und Tests definieren wie für nativ in Icinga angelegte Geräte auch.

Zabbix benötigt Hilfe von außen

Nicht ganz so dynamisch und integriert gestaltet sich der Versuch, NetBox und Zabbix miteinander zu verheiraten. Leider, denn Zabbix hat bis heute unter Administratoren eine treue Fangemeinde und dies aus durchaus gutem Grund. Denn anders als viele klassische Eventmonitoring-Systeme hat Zabbix die Trends der vergangenen Jahre nicht völlig verschlafen. Sukzessive haben die Zabbix-Entwickler ihr Werkzeug so umgebaut, dass es wesentlich größere Set-ups abdeckt – vor allem moderne, dynamisch skalierende Installationen. Auch das Thema Trending spielt bei Zabbix seit ein paar Versionen eine immer wichtigere Rolle. Mittlerweile lassen sich Metrikdaten über eigene Werkzeuge von den Zielsystemen für die meisten Standarddienste problemlos durch Zabbix einsammeln und im Nachgang dort auch visualisieren.

Die Kombination von NetBox und Zabbix ergibt folgerichtig mindestens so viel Sinn wie bei Icinga. Jedoch gestaltet sie sich etwas komplizierter. Das liegt daran, dass die Anwendung eine eigene Datenbank der überwachten Assets betreibt, für diese aber kein natives Tool bietet, um NetBox als Datenquelle zu integrieren. Die Open-Source-Community schafft Abhilfe und stellt ein umfangreiches Werkzeug namens "Netbox-Zabbix-Sync" [3] zur Verfügung, mit dem sich eine dauerhafte Synchronisation von NetBox und Zabbix erreichen lässt.

Laden Sie sich dieses Tool herunter, finden Sie einen sofort lauffähigen Docker-Container vor. De facto benötigen Sie also lediglich ein System, das sowohl mit NetBox als auch mit Zabbix kommunizieren kann. Danach laden Sie mittels docker pull das Image "ghcr.io/thenetworkguy/ netbox-zabbix-sync:main" herunter und starten es:

Wie schon durch die von uns für Variablen verwendeten Spitzklammern gekennzeichnet, müssen Sie "ZABBIX_HOST", "ZABBIX_TOKEN", "NETBOX_HOST" sowie "NETBOX_TOKEN" durch für Ihre Umgebung zutreffende Einträge ersetzen. Ein Token für den Zugriff auf NetBox holen Sie direkt von diesem, das Zabbix-Token stellt Zabbix per GUI ebenfalls eigenständig aus. Im Anschluss steht die Definition von "Custom Fields" in NetBox an: Das Feld "zabbix_hostid" ist ebenso anzulegen wie "zabbix_template". Ersteres bekommt den Typ Integer, "Required" steht auf "False" und der Objekttyp ist "dcim => device". Letzterer ist vom Typ "Text" und nicht zwingend erforderlich, hat auch keinen Standardwert und nutzt den Typ "dcim => device_type". Um auch virtuelle Instanzen zu synchronisieren, schieben Sie dem laufenden Container per Volume eine modifizierte "config.py"-Datei unter, die den Wert für "sync_vms" auf "True" setzt.

Das Synchronisationsskript startet im Nachgang von sich aus mit dem Import der Daten aus NetBox in Zabbix, ergänzt den Datensatz aber auch in NetBox, um schnellere Rückschlüsse von dort auf die NetBox-Daten zu ermöglichen. Ähnlich wie bei der Integration von Icinga haben Sie danach viele Möglichkeiten zum Ausprobieren und Testen. Und ebenso lassen sich aus NetBox importierte Geräte danach in Zabbix nutzen wie jedes andere Überwachungsziel (Bild 2). In Summe ist die Integration von NetBox und Zabbix mittels Skript weitgehend vollständig. Der gewünschte Effekt tritt jedenfalls ein: Neue Daten in NetBox führen zu einer Resynchronisation mit Zabbix, wo die neuen Assets kurz darauf auftauchen.

Checkmk braucht Zusatztool

Deutlich unangenehmer gestaltet sich die Integration von NetBox und Checkmk. Das mag daran liegen, dass die Fangemeinde von Checkmk nicht ganz so groß ist wie jene von Zabbix oder Icinga. Möglich ist ein Zusammenspiel der Werkzeuge aber dennoch. Die Kuhn & Ruess GmbH bietet ein Werkzeug namens CMDB Syncer [4]. Expertise bringen Kuhn & Ruess vor allem als Implementierungspartner für Checkmk mit, aber auch zu NetBox ist umfangreiches Know-how vorhanden.

Streng genommen ist CMDB Syncer nicht NetBox-spezifisch. Stattdessen handelt es sich um einen eigenen und eigenständigen Dienst, der sich auf der einen Seite mit einer CMDB verbinden kann und die Daten auf der anderen Seite dann so für Checkmk vorbereitet, dass sie dort als Asset nutzbar werden. Neben NetBox unterstützt das Werkzeug auch die Synchronisation von Checkmk mittels Ansible-Inventar, i-doit und Cisco-DNA. Importfunktionen für eine Vielzahl von Datenbankschemata stehen ebenfalls zur Verfügung.

Dank Docker geht auch der Start mit CMDB Syncer leicht von der Hand. Seine Autoren stellen zwar keine fertigen Abbilder zur Verfügung, haben ihr GitHub-Repository aber so hergerichtet, dass sich mittels Docker Compose schnell eine laufende Instanz schaffen lässt. Dazu laden Sie das Repo erst mittels git clone herunter und rufen danach ./helper up auf. Freilich funktioniert dies nur auf einem System mit funktionierender Docker-Laufzeitumgebung und vorhandenem Docker Compose. Sind diese Anforderungen erfüllt, lässt sich im nächsten Schritt mittels

ein Login samt Passwort für CMDB Syncer aktivieren. Danach ist ein Login im Webinterface über den HTTP-Port 5003 möglich. Die Entwickler weisen darauf hin, dass CMDB Syncer aktuell noch als Version für Entwickler ausgerollt wird, in absehbarer Zeit soll sich dies aber ändern. Herumexperimentieren ist jedenfalls erlaubt: Im GUI richten Sie im Nachgang sowohl eine Verbindung mittels Token zu NetBox als auch zu Checkmk ein. Danach lassen sich Regeln definieren, anhand derer CMDB Syncer Assets aus NetBox per API prüft und danach in Checkmk anlegt. Der Vorteil daran ist, dass Änderungen in NetBox auf diese Weise automatisch auch in Checkmk landen – etwa beim Anlegen neuer Systeme. Die Aufgabe, diesen anschließend eine eigene Konfiguration zu verpassen, obliegt allerdings einmal mehr Ihnen.

Traumhochzeit mit Prometheus

Der letzte Kandidat ist die Zeitreihendatenbank Prometheus. Diese unterscheidet sich von den drei anderen Werkzeugen vor allem dadurch, dass sie eine echte Cloudnative-Anwendung für das Monitoring ist. Prometheus ist unter der Haube vor allem eine Datenbank, jedoch keine relationale, sondern sie orientiert sich intern an einem Zeitstrahl, an den sie an verschiedenen Punkten Datensätze anheftet. Das macht insbesondere das Speichern und Auslesen von Daten für bestimmte Zeitpunkte viel schneller, als es mit einer klassischen relationalen DB möglich wäre.

Prometheus entstammt ursprünglich der Feder von Entwicklern bei SoundCloud, mittlerweile ist das Werkzeug aber ein echtes Open-Source-Projekt und weltweit millionenfach im Einsatz. Seine Stärke ist das Überwachen massiv skalierbarer Setups. Hier bringt Prometheus beispielsweise das automatische Erkennen von Zielen auf Basis konfigurierbarer Regeln mit. Die DNS-Features beispielsweise von Etcd oder Consul lassen sich unmittelbar nutzen, um Prometheus neue Monitoringziele beizubringen – hundertprozentig zuverlässig ist das allerdings nicht. Und wenn ohnehin das gesamte Setup in NetBox abgebildet ist, spricht nichts dagegen, Prometheus mit den von dort stammenden Daten umfassend zu füttern.

Die dafür notwendigen Komponenten sind sowohl bei NetBox als auch bei Prometheus Bestandteil der Grundausstattung. Ein von Felix Peters gebautes Plug-in [5] ermöglicht dann die native Verbindung mittels eines Umwegs. Zum Zug kommt einmal mehr die automatische Diensterkennung in Prometheus, kurz "SD" oder "Service Discovery" genannt. Seit Version 2.28.0 unterstützt Prometheus Service-Discovery auch mittels HTTP-Protokoll. Zielsysteme lassen sich entsprechend mittels URL finden statt wie bisher über Einträge in der Konfigurationsdatei.

Das Plug-in exponiert in NetBox URLs, die mit der automatischen Erkennung von Prometheus kompatibel sind. Es genügt insofern, das Plug-in in NetBox zu installieren und zu aktivieren und Prometheus anschließend seine reguläre Diensterkennung im Netzwerk durchführen zu lassen. Eine beispielhafte Prometheus-Konfiguration stellt der Autor in seinem GitHub-Verzeichnis [5] zur Verfügung. Zu beachten ist, dass für den Zugriff auf die NetBox-API durch Prometheus in diesem ebenfalls ein API-Token hinterlegt sein muss, weil NetBox andernfalls den Zugang verweigert. Läuft alles, müssen Sie wie üblich die genutzten Dashboards – meist in Grafana – konfigurieren, um die neuen Monitoringziele anzuzeigen. Auch Alarme mittels Alert Manager sind händisch zu konfigurieren. An dieser Stelle unterscheiden sich Ziele aus NetBox aber nicht von anderen, die Sie in Prometheus konfigurieren.

Ein Umdenken ist gerade für Administratoren eher klassischen Monitorings an dieser Stelle trotzdem nötig. Das liegt daran, dass Prometheus unter der Haube anders funktioniert als Zabbix & Co. und grundsätzlich Pull-basiert ist. Die Zeitreihendatenbank will also die Überwachungsziele auf den zu prüfenden Geräten regelmäßig selbst abfragen, um von dort die aktuellen Metrikdaten zu empfangen. Nur weil Prometheus dank der Synchronisation mit NetBox weiß, dass ein Host existiert, erkennt es nicht automatisch, ob dort überhaupt kompatible Exporter laufen und welche.

Hierfür bringt das NetBox-Plug-in allerdings Intelligenz mit. Hinterlegen Sie einen Host in NetBox nämlich mit einem erweiterten Konfigurationskontext namens "prometheus-plugin-prometheus-sd" und fügen darin einzelne Einträge mit den Parametern "metrics_path", "port" und "scheme" ein, erkennt Prometheus diese automatisch und beginnt mit der Abfrage (Bild 4). Ihnen kommt dann allerdings immer noch die Aufgabe zu, die Daten passend zu verarbeiten, etwa zur Virtualisierung per Dashboard in Grafana.

Fazit

Unsere vier Beispiele belegen, dass in der Regel die Herausforderung gar nicht darin besteht, die Assets aus NetBox in das jeweilige Monitoring zu synchronisieren. Aufwendiger ist im Nachgang der Akt, die nun im Monitoring vorhandenen Überwachungsziele mit den passenden Service-Definitionen zu versehen, um aussagekräftige Überwachungsdaten zu erhalten. Prometheus hat an dieser Stelle den Vorteil, dass das für die Synchronisierung notwendige NetBox-Plug-in diese Information direkt übermittelt. Das verlagert das Problem aber tatsächlich nur, denn die visuelle Darstellung von Metrikdaten oder die Integration von Alarmen im Alertmanager sind weiterhin hochspezifisch für ein jeweiliges Setup und notwendige Handarbeit für den Administrator.

NetBox in das Monitoring integrieren