Netzwerk-Layer-Visualisierung mit Checkmk erstellen
on 28.06.2024
In einer zunehmend vernetzten Welt ist es für Admins von unschätzbarem Wert, wenn sie auf einen Blick sehen können, wie ihre verzweigten Netzwerke miteinander verbunden sind und ob es darin Hosts mit Problemen gibt. Eine solche Übersicht macht es einfacher zu verstehen, wie die jeweilige Infrastruktur zusammengesetzt ist und auf welchen Bestandteilen sie beruht. Genau das leistet eine Netzwerktopologie.
Auf der Checkmk Konferenz 9 haben wir angekündigt, dass eine Visualisierung des Netzwerks Bestandteil der Roadmap von Checkmk ist. Mit Version 2.3 haben wir das nun erfüllt. Der Artikel soll zeigen, wie die Netzwerkvisualisierung in Checkmk funktioniert und wie Sie diese auf Ihren Checkmk-Instanzen aktivieren können.
Bei der Netzwerkvisualisierung handelt es sich um ein neues grafisches Backend, das in Checkmk 2.3 eingebaut wurde, um Verbindungen zwischen Objekten anzuzeigen. Bei diesen Objekten kann es sich einerseits um Hosts und Services von Hosts aus Ihrem Checkmk-Monitoring handeln sowie andererseits um Objekte, die nicht Teil Ihres Monitorings sind. Dabei kann es sich um IP-Adressen, IP-Netzwerke, Clouds etc. handeln. Theoretisch kann es sich bei den Objekten um alles Mögliche handeln, etwa eine Sammlung von Klemmbausteinen oder das lokale Eisenbahnnetz. In diesem Artikel konzentrieren wir uns jedoch ausschließlich auf IT-Netzwerkinfrastrukturen.
Die Visualisierung der Verbindungen zwischen Objekten hat den Zweck, Ihnen ein besseres Verständnis darüber zu vermitteln, wie die Komponenten Ihrer IT-Infrastruktur miteinander verbunden sind – und zwar in einer einfachen, aber aussagekräftigen Darstellung. Auf diese Weise unterstützt es Sie dabei, Fehlkonfigurationen zwischen Geräten, etwa Verbindungen mit unterschiedlichen Schnittstellengeschwindigkeiten, oder unterbrochene Verbindungen auf einem Blick zu identifizieren.
Die Netzwerktopologie in Checkmk ist über eine Reihe von Community-Paketen verfügbar, die das Abrufen von Informationen über zwei, für diese Aufgabe gängige Protokolle ermöglichen: CDP und LLDP. Das Cisco Discovery Protocol (CDP) ist hauptsächlich auf Cisco-Geräten vorhanden, wurde aber auch von anderen Herstellern implementiert. Daher ist es wahrscheinlich, dass es auch in Ihrer Infrastruktur vorhanden ist. Das Link Layer Discovery Protocol (LDDP) ist hingegen herstellerunabhängig. Beide Protokolle arbeiten auf der OSI-Schicht 2, das heißt, dass es sich um Informationen unterhalb der IP-Adressen wie ARP-Tabellen und Mac-Adressen handelt.
Darüber hinaus unterstützt Checkmk auch die Topologie auf IP-Ebene. Bei dieser handelt es sich um die OSI-Schicht 3, die mit IP-Adressen arbeitet. Unabhängig davon, ob Sie sich für CDP, LLDP oder IP entscheiden: Sie sollten die Option wählen, die am besten zu Ihren Anforderungen und Ihrer Netzwerkumgebung passt.
An diesem Beispiel können Sie sehen, wie die Netzwerkvisualisierung in Checkmk aussieht:
Die Topologie auf dem Screenshot basiert auf den LLDP-Informationen von überwachten Switches, die Checkmk über die HW/SW-Inventur bereitstellen kann. Die animierte Grafik verdeutlicht nochmals die Informationen, die über die Topologie verfügbar sind.
Auf der linken Seite befinden sich die Basis-Nodes, auf der rechten Seite die angeschlossenen Switches und dazwischen die verschiedenen Schnittstellen, die sie verbinden. Informationen über den Node/Service erhalten Sie zudem in einem Hover-Tooltip über den Symbolen.
Weitere Informationen können Sie außerdem aus den Linien entnehmen, die die Geräte und Hosts verbinden:
Sie können zudem die Dicke der Linie bestimmen, um etwa die Bandbreite darzustellen, die Farbe ändern, um etwa Probleme anzuzeigen – rot zum Beispiel für eine langsame Verbindung. Wie in der Checkmk-Oberfläche üblich stehen Ihnen auf der rechten Seite des Bildschirms Filter zur Verfügung:
Diese animierte Grafik demonstriert Ihnen die verschiedenen Anzeigeoptionen zum Ein- und Ausblenden von Beschriftungen und ganzen Oberflächen. Diese Filter sind in Echtzeit, man muss sie also nicht aktivieren.
Dies sind im Großen und Ganzen die Möglichkeiten, die die Topologie Ihnen bietet. Jetzt schauen wir uns an, wie Sie diese einrichten können.
Wie man die Netzwerkvisualisierung in Checkmk einrichtet
Checkmk erstellt die Daten, die das Visualisierungs-Backend benötigt nicht selbst, sodass wir in unserem Beispiel auf das NVDCT-Plugin zurückgreifen. Dies wurde von thl-cmk erstellt und steht unter der GPL auf thl-cmk.hopto.org zur Verfügung. In diesem Artikel konzentrieren wir uns auf eine Layer-2-/Layer-3-Netzwerktopologie. Wenn Sie Ihre eigene Visualisierungsdatei erstellen möchten, werfen Sie einen Blick auf den Abschnitt Datenformat.
Die Einrichtung von NVDCT besteht aus folgenden Schritten:
- Installation der benötigten Pakete.
- (Erneute) Discovery der Host-Labels.
- Konfiguration und Ausführung der HW/SW-Inventur.
- Modifizierung der NVDCT-Einstellungen.
- Ausführung des NCDVT-Tools.
Installation der erforderlichen Pakete
Damit die Hardware-/Software-Inventur die benötigten Daten abrufen kann, müssen Sie folgende Inventory-Plugins installieren:
- CDP cache HW/SW inventory plug-in für die “Cisco Discovery Protocol”-Topologie.
- LLDP cache HW/SW inventory plug-in für die “Link Layer Discovery Protocol”-Topologie.
- IPv4 address HW/SW inventory plug-in für die IPv4-Adressschicht-Topologie.
Je nachdem, welche Protokolle Ihre Geräte unterstützen, müssen Sie nur eines oder mehrere der oben genannten Plugins installieren. Wenn keines Ihrer Geräte CDP unterstützt, können Sie das CDP-Plugin zum Beispiel weglassen.
Empfehlenswert aber optional ist ein Plugin, das den Abgleich von Namen und Services ermöglicht. Es hilft Ihnen dabei, CDP/LLDP-Daten den jeweiligen Services in Checkmk zuzuordnen:
Das letzte Paket, das wir benötigen, ist das Network Visualization Data Creation Tool (NVDCT). Es ist das Programm, das die Datendatei für das grafische Backend der Netzwerkvisualisierung erstellt.
Die Plugins installieren Sie wie gewohnt über die Checkmk-GUI: Setup > Extension Packages > Upload package. Sollten Sie die Raw Edition nutzen, müssen Sie die einzelnen Pakete manuell installieren:
mkp add PAKAGE_NAME.mkp
mkp enable PAKAGE_NAME VERSION
Host-Labels (erneut) discovern
Das NVDCT-Tool stützt sich auf bestimmte Host-Labels, die über die oben genannten Plugins ermittelt werden. Diese Labels sind:
-
nvdct/routing_capable:yes
-
nvdct/has_cdp_neighbours:yes
-
nvdct/has_lldp_neighbours:yes
Die Layer2-Topologien funktionieren auch ohne Host-Labels unter Verwendung der Neighbor-Informationen aus dem CDP/LLDP-Protokoll. Auf der IP-Schicht sind solche Nachbarschaftsinformationen jedoch nicht verfügbar, sodass die Host-Labels obligatorisch sind.
Der andere Anwendungsfall für die Host-Labels durch NVDCT ist die Befehlszeilenoption --pre-fetch, die die Erstellung der Datendatei beschleunigen kann.
Aus diesem Grund müssen Sie die Host-Labels aktualisieren, etwa mit der Bulk Discovery:
Sobald Checkmk die Host-Label-Discovery durchgeführt hat, können Sie die erkannten Host-Labels überprüfen.
Konfiguration und Ausführung der HW/SW-Inventur
Für alle Netzwerkgeräte, die Sie in die Topologie aufnehmen möchten, müssen Sie in Checkmk die HW/SW-Inventur aktivieren. Mit der Regel “Do hardware/software inventory” lassen sich die gewünschten Einstellungen konfigurieren. Das empfohlene Prüfintervall beträgt 24 Stunden und lässt sich in der Regel unter “Normal check interval for service checks” festlegen.
Darüber hinaus muss Checkmk die HW/SW-Inventarisierung vor dem NVDCT ausführen, damit das Plugin die gemeldeten Daten sammeln und die Netzwerktopologie daraus erstellen kann.
Sobald Checkmk die HW/SW-Inventur erfolgreich durchgeführt hat, können Sie die Ergebnisse überprüfen.
Wenn ihr Gerät CDP-Nachbarn hat, sollten Sie, wie hier für LLDP, auch eine Tabelle für CDP sehen.
NVDCT-Einstellungen modifizieren
Wenn Sie alle Pakete installiert, alle Regeln festgelegt, die HW/SW-Inventur durchgefürt und alle Labels erkannt haben, können Sie mit der eigentlichen Erstellung der Topologie beginnen.
Dazu werfen Sie zunächst einen Blick in die Konfigurationsdatei unter
~/local/bin/nvdct/conf/nvdct.toml.
In der Datei können Sie Aspekte der Topologievisualisierung feinjustieren. Doch bevor Sie etwas ändern, sollten Sie eine persönliche Kopie der Datei erstellen. Das Original lassen Sie unverändert, da es bei jeder Aktualisierung des NVDCT-MKPs überschrieben wird. Für die CDP/LLDP-Schicht sollten Sie zumindest Ihre “Seed-Geräte” hinzufügen, von denen aus NVDCT die Topologie erstellen wird. Sie sind im Abschnitt SEED_DEVICES der TOML-Datei zu finden, wie unten gezeigt:
# list of (additional to -s/--seed-devices) seed devices
SEED_DEVICES = [
"DEVICE01",
"DEVICE02",
"DEVICE03",
]
Aktivieren Sie im Abschnitt [Settings] die Schichten, die Sie erstellen möchten. Standardmäßig erstellt NVDCT nur die CDP-Ebene:
# settings equivalent to CLI options
[SETTINGS]
# layers = ["LLDP", "CDP", "STATIC", "CUSTOM", "L3v4"]
layers = ["LLDP", "L3v4"]
NVDCT ausführen
Wenn Sie alle gewünschten Änderungen in der Konfigurationsdatei erledigt haben, können Sie die Netzwerktopologie erstellen. Das geschieht mit:
~$ ~/local/bin/nvdct/conf/nvdct.py -u ~/local/bin/nvdct/conf/my_nvdct.toml
Die Ausgabe ist in etwa wie folgt:
Network Visualisation Data Creation Tool (NVDCT)
by thl-cmk[at]outlook[dot]com, version 0.8.7-20240430
see https://thl-cmk.hopto.org/gitlab/checkmk/vendor-independent/nvdct
Start time....: 2024-04-30T14:17:02.04
Devices added.: 16, source lldp
Devices added.: 59, source L3v4
Time taken....: 3.225333135/s
End time......: 2024-04-30T14:17:05.04
~$
Die generierten Topologiedaten befinden sich unter: ~/var/check_mk/topology/data/
Einen symbolischer Link zur Standardtopologie existiert ebenfalls:
~$ ls -ls ~/var/check_mk/topology/data
4 drwx------ 2 build build 4096 Apr 30 14:17 2024-04-30T14:17:05.04/
0 lrwxrwxrwx 1 build build 57 Apr 30 14:25 default -> /omd/sites/build/var/topology_data/2024-04-30T14:17:05.04/
Sie können die Netzwerktopologie nun über das Host-Menü von Checkmk abrufen, indem Sie die Option “Network layer topology” auswählen (siehe Screenshot). Sie können nun damit beginnen, von einem Ihrer Seed-Geräte aus, Ihre Netzwerktopologie zu erkunden.
Visualisierungsoptionen
Egal wie Sie die Netzwerktopologie erstellen – von Hand oder mit der NVDCT-Erweiterung – Checkmk bietet Ihnen viele Möglichkeiten zur Anpassung. Standardmäßig wird die Beziehung zwischen den Hosts und den Schnittstellen angezeigt. Es wird auch der aktuelle Status von Hosts und Services angezeigt, mit einem Link zur entsprechenden Ansicht. Falls sie möchten, können Sie auch Services ausblenden, um die visuelle Unübersichtlichkeit zu reduzieren. Oder Sie lassen sich nur Services mit Problem anzeigen, dank des Schalters in der Visualisierung oben links.
Es ist zudem möglich, zwei Datensätze von verschiedenen Zeitpunkten aus visuell zu vergleichen. Dazu dient die Option "compare history" in den Optionen, wie die Animation zeigt:
Zunächst wählen Sie einen Referenzzeitpunkt, in der Regel die aktuelle Zeit, und dann den Vergleichszeitpunkt. Die Topologie ermittelt dann alle Unterschiede in den Verbindungen zwischen den beiden Zeitstempeln, nämlich Verbindungen, die in der Referenz fehlen, und Verbindungen, die nur in der Referenz existieren.
Es stehen verschiedene Darstellungsformen zur Verfügung. Derzeit können Sie zwischen zwei vorgefertigten Layouts für die Darstellung der Daten wählen: full oder flat.
Das komplette Layout bietet Ihnen eine bessere Übersicht über die Verbindungen, da Checkmk diese in einer Baumstruktur darstellt. Das flache Layout ist kompakter und daher leichter auf einen Blick zu lesen, zeigt aber die vollständigen Verbindungsdaten an, wenn Sie den Mauszeiger über die Knoten und Verbindungen bewegen.
Alternativ können Sie die Funktion "layout configuration" verwenden, um ein völlig freies Layout zu erstellen, das Checkmk automatisch lädt, wenn Sie diese Ansicht mit genau denselben Filtereinstellungen aufrufen.
Checkmk bietet über die pure Visualisierung hinaus noch einige weitere interessante Funktionen. So können Sie die Netzwerktopologie filtern und ihr Layout konfigurieren. Die Filter sind zudem anpassbar und Sie können Ihre eigenen hinzufügen. Standardmäßig sind die gängigsten vorhanden, wie beispielsweise:
- Topology max nodes
- Topology mesh depth
- Hostname (regex)
- Hostalias (regex)
- Several host groups
- Host Contact Group
- Host states
- Host labels
- Host tags
- Site
Für die ersten beiden genannten Filter ist eine zusätzliche Erklärung notwendig. Topology max nodes gibt an, wie viele Knoten das Layout anzeigen soll. Wenn die gewählte Grenze erreicht ist, zeigt es im Titel eine Warnung an.
Topology max depth ist nützlich, um den Weg zum Aufbau der Topologie auf eine bestimmte Anzahl von “hops” vom Startknoten oder den Knoten zu begrenzen.
Wie bereits erwähnt ist es außerdem möglich, die Unterschiede zwischen zwei Zeitstempeln zu vergleichen und die Änderungen zwischen zwei Zeitpunkten visuell zu überprüfen. Mit NVDCT können Sie die Topologie mit verschiedenen Symbolen, einer eigenen Farbe für die Linien, dickeren Verbindungen und vielem mehr gestalten.
Es gibt auch einen eingebauten Filter, um die Standardvisualisierungsparameter anzupassen. Dieser nennt sich topology_filters. Klonen Sie ihn und passen Sie seine Parameter nach Ihren Wünschen an.
Datenformat
Die Topologie verwendet eine Datendatei für jeden Datentyp für einen bestimmten Zeitstempel. Das heißt, dass sehr viele Dateien entstehen können, diese werden jedoch nicht sehr groß, da es sich um einfache TOML-Dateien handelt. Die Daten bestehen aus zwei Hauptkomponenten:
- Den Objekten, die die Knotenpunkte in der Visualisierung darstellen.
- Den Verbindungen, die die Beziehungen zwischen den Knoten darstellen.
Ein Beispiel für eine Datendatei sieht wie folgt aus:
{
"version": 1, # data format version
"name": "CDP data", # some name to display somewhere
"objects": { # A dictionary containing the object ID key and the object as value
# A generic node with the ID NodeA and the display name 'NodeA'
# It is a simple node with no relationship to the monitoring core
'NodeA': {'metadata': {}, 'name': 'NodeA'},
# A node with the ID HostA_ID, which is linked to a host 'HostA' in the core.
# In the visualization the node is named 'HostA Name'
'HostA_ID': {'link': {'core': 'HostA'}, 'metadata': {}, 'name': 'HostA Name'},
# A node with the ID HostA_ServiceX, which is linked to a service
# 'HostA'/'ServiceX' in the core. In the visualization the node is named 'Service X'
'HostA_ServiceX': {'link': {'core': ['HostA', 'ServiceX']}, 'metadata': {}, 'name': 'Service X'},
# The metadata field is used to add additional information.
# A generic node with the ID NodeWithImages and the display name 'ImageNode'
# This generates a node which is shown in the screenshot above
'NodeWithImages': {'metadata': {
'images': {"icon": "icon_checkmark", "emblem": "emblem_warning"}
},
'name': 'ImageNode'},
},
# The objects are always identified by their ID
# A connection always connects two objects and has tree values [SOURCE_ID, TARGET_ID, metadata]
"connections": [
# A simple connection between NodeA and HostA_ID
[["NodeA"], ["HostA_ID"], {}],
# Another simple connection between NodeA and HostA_ServiceX
[["NodeA"], ["HostA_ServiceX"], {}],
# A connection between HostA_ServiceX and NodeWithImages.
# The line_config field specifies the custom styling
[["HostA_ServiceX"], ["NodeWithImages"], {"line_config": {"thickness": 5, "color": "green"}}],
]
}
Wichtig zu beachten sind die Indizes "images" und "line_config". Der Index "images" hat zwei Keys:
- "icon": ein Symbol, das oben links auf dem Knoten angezeigt wird und die vorkonfigurierten Symbole im Kern überschreibt.
- "emblem": ein Bild, das das blaue Fragezeichen auf Knoten ersetzt, die nicht mit dem Kern verknüpft sind.
Der Index "line_config" hat ebenfalls zwei Keys:
- "thickness": die gewünschte Dicke der Verbindung.
- "color": die Farbe der Verbindung. Hier werden sowohl Farbnamen als auch HEX-Farbcodes akzeptiert.
Zukünftige Entwicklungen
Die derzeitige Topologie ist erst der Anfang. Sie wird in Zukunft noch weiter erweitert und optimiert werden. So soll beispielsweise die UX stark überarbeitet werden – sie wird sich folglich nochmal verändern.
Hinter dem Frontend arbeiten wir daran, Hosts einzubeziehen, die in der Datendatei angegeben sind, aber nicht im Monitoring-Core vorhanden sind. Der Traffic zwischen allen Hosts soll ebenfalls sichtbar sein, aber über die genaue Implementierung muss noch entschieden werden. Eine verlässliche Datenquelle für den Traffic ist noch nicht etabliert, und viele völlig unterschiedliche Geräte benötigen eine einheitliche Möglichkeit, den Datenverkehr anzuzeigen.
Die Visualisierung der Netzwerktopologie unterstützt derzeit nur die Protokolle CDP und LLDP. Wir wollen das erweitern und arbeiten daran, künftig auch die Unterstützung für Netstat-Daten hinzuzufügen. Dies sollte die Gruppe der unterstützten Geräte dank der Allgegenwärtigkeit des Tools in Unix- und abgeleiteten Systemen ziemlich erweitern. Außerdem würde es die Datenqualität verbessern, die wir bei CDP als gut empfunden haben, die jedoch bei LLDP oft noch bereinigt werden muss.
Aber das ist noch Zukunftsmusik. Für den Moment freuen wir uns, Ihnen ein neues Tool zur Verfügung stellen zu können, das die Visualisierungsmöglichkeiten in Ihren Monitoring-Umgebungen verbessert.