Netzwerk-Layer-Visualisierung mit Checkmk erstellen

In zunehmend verteilten IT-Umgebungen ist eine visuelle Darstellung der Netzwerkverbindungen eine enorme Hilfe für Administratoren – insbesondere, wenn schnell erkennbar sein soll, ob Hosts Probleme haben. Sie erleichtert es, zu verstehen, wie eine Infrastruktur miteinander verbunden ist und aus welchen Komponenten sie besteht.

Die Netzwerkvisualisierung ist ein in Checkmk integriertes grafisches Backend, das Verbindungen zwischen Objekten darstellt. Diese Objekte können Hosts und Services aus Ihrer Checkmk-Instanz sein, aber auch Objekte, die nicht Teil der Checkmk-Instanz sind – zum Beispiel IP-Adressen, IP-Netzwerke, Cloud-Umgebungen oder andere frei definierbare Elemente. Theoretisch können Objekte alles Mögliche sein, etwa eine Sammlung von Spielzeugbausteinen oder das lokale Bahnnetz. In diesem Tutorial konzentrieren wir uns jedoch ausschließlich auf IT-Netzwerkinfrastrukturen. 

Ziel der Visualisierung ist es, Ihnen ein besseres Verständnis dafür zu geben, wie die Komponenten Ihrer IT-Infrastruktur miteinander verbunden sind. So können Sie beispielsweise Fehlkonfigurationen zwischen Geräten erkennen, etwa unterschiedliche Interface-Geschwindigkeiten an verbundenen Ports, oder unterbrochene Verbindungen schneller aufspüren.

Die Netzwerktopologie in Checkmk erfasst ihre Informationen über zwei dafür gängige Protokolle: CDP und LLDP. CDP, das Cisco Discovery Protocol, kommt vor allem auf Cisco-Geräten zum Einsatz, wurde aber auch von anderen Herstellern implementiert. Es ist daher gut möglich, dass CDP in Ihrer Infrastruktur verfügbar ist. LLDP, das Link Layer Discovery Protocol, ist hingegen herstellerneutral. Beide Protokolle arbeiten auf OSI-Layer 2. Es geht also um Informationen unterhalb der IP-Adressebene, etwa ARP-Tabellen und MAC-Adressen.

Darüber hinaus unterstützt Checkmk auch eine Topologie auf IP-Ebene. Diese arbeitet auf OSI-Layer 3 und basiert auf IP-Adressen. Damit lassen sich auch Windows- und Linux-Systeme sowie SNMP-basierte Netzwerkgeräte in die Topologie einbeziehen.

Unabhängig davon, ob Sie CDP, LLDP oder die IP-basierte Topologie verwenden, sollten Sie die Methode wählen, die am besten zu Ihren Anforderungen und Ihrer Umgebung passt.

Sehen wir uns nun an einem kleinen Beispiel an, wie die Netzwerkvisualisierung in Checkmk aussieht:

Die oben dargestellte Topologie wurde aus den LLDP-Informationen der überwachten Switches erstellt, die in der HW/SW-Inventur von Checkmk vorliegen. Die folgende animierte GIF-Datei zeigt genauer, wie die Root Nodes und Switches miteinander verbunden sind und welche Services darauf laufen:

Hier sehen Sie links die Root Nodes, rechts die verbundenen Switches und dazwischen die verschiedenen Interfaces, über die sie miteinander verbunden sind. Informationen zum jeweiligen Node oder Service werden per Hover-Tooltip über den Icons angezeigt.

Die Linienstärke kann die Bandbreite darstellen, die Farbe Hinweise auf Probleme geben, etwa Rot für eine langsame Verbindung.

Filter finden Sie wie gewohnt in der Checkmk-Oberfläche auf der rechten Seite des Bildschirms:

In der animierten GIF-Datei oben werden die Anzeigeoptionen gezeigt, mit denen Sie Labels und ganze Interfaces ein- oder ausblenden können. Diese Filter wirken in Echtzeit, Sie müssen sie also nicht erst anwenden.

Damit haben Sie einen ersten Eindruck davon, wie die Netzwerkvisualisierung aussieht und was sie leisten kann. Sehen wir uns nun an, wie Sie sie einrichten.

Die Einrichtung der Netzwerktopologie-Visualisierung ist inzwischen unkompliziert. Die dafür benötigten Inventory-Plugins für die Netzwerktopologie sind seit Checkmk 2.5.0 direkt in Checkmk integriert. Damit stehen Ihnen sofort folgende Plugins zur Verfügung:

• Layer-2-Topologie-Plugins: Inventory-Plugins für CDP und LLDP
• Layer-3-Topologie-Plugins: IP-Inventory-Plugins für SNMP, Windows und Linux
• Zusätzliche Plugins: Inventory-Plugin für Interface-Namen

Früher mussten Administratoren mehrere externe Plugins manuell herunterladen und installieren, um die Checkmk HW/SW-Inventur mit den entsprechenden Daten zu befüllen, darunter CDP, LLDP, IPv4 und INV_IFNAME. Diese Schritte entfallen mit Checkmk 2.5.

Für die Einrichtung der Netzwerkvisualisierung enthält Checkmk bereits alle benötigten Pakete standardmäßig. Die einzige Ausnahme ist das Network Visualization Data Creation Tool (NVDCT), das Sie weiterhin manuell installieren müssen. Sie können es wie gewohnt über die Checkmk-GUI unter Setup > Extension Packages > Upload package installieren. Nutzer von Checkmk Community müssen es über die CLI installieren mit:

mkp add PAKAGE_NAME.mkp
mkp enable PAKAGE_NAME VERSION

Das NVDCT-Tool nutzt bestimmte Host-Labels, die über die integrierten Plugins erkannt werden.

Wichtig: Checkmk 2.5 und neuer verwendet für alle topologiebezogenen Host-Labels das Präfix cmk/. Alle Referenzen, die bisher das Präfix nvdct/ verwendet haben, wurden durch ihre entsprechenden cmk/-Äquivalente ersetzt.

Diese Labels können die Erstellung der Topologiedatei beschleunigen und sind für Layer-3-IP-Topologien zwingend erforderlich, da Nachbarinformationen dort nicht nativ verfügbar sind wie bei CDP oder LLDP. Stellen Sie daher sicher, dass die Host-Labels aktualisiert sind, zum Beispiel über die Bulk Discovery:

Wenn die Erkennung der Host-Labels abgeschlossen ist, können Sie die erkannten Host-Labels überprüfen:

Die HW/SW-Inventur muss für alle Netzwerkgeräte aktiviert sein, die Sie in die Topologie aufnehmen möchten. Verwenden Sie dafür die Regel “Do hardware/software inventory”. Als Check-Intervall empfehlen wir 24 Stunden.

Die HW/SW-Inventur muss vor NVDCT ausgeführt werden, damit das Plugin die erfassten Daten auslesen und daraus die Netzwerktopologie erstellen kann.

Nach erfolgreicher Ausführung der HW/SW-Inventur können Sie die Ergebnisse überprüfen.

Wenn Ihr Gerät CDP-Nachbarn hat, sehen Sie zusätzlich zur LLDP-Tabelle auch eine entsprechende Tabelle für CDP.

Sobald das NVDCT-Paket installiert ist, die Regeln gesetzt sind, die HW/SW-Inventur ausgeführt wurde und die cmk/-Labels erkannt wurden, können Sie mit der Erstellung der Topologie beginnen.

Sehen Sie sich zunächst die Konfigurationsdatei unter ~/local/bin/nvdct/conf/nvdct.toml an. Erstellen Sie vor dem Bearbeiten eine persönliche Kopie, damit Ihre Einstellungen bei Updates nicht überschrieben werden.

Für den CDP/LLDP-Layer müssen Sie Ihre Seed Devices, also die Geräte, von denen NVDCT aus mit der Erstellung der Topologie beginnt, im Abschnitt SEED_DEVICES der TOML-Datei eintragen, wie unten gezeigt:

# list of seed devices
SEED_DEVICES = [
    "DEVICE01",
    "DEVICE02",
    "DEVICE03",
]

Aktivieren Sie im Abschnitt [SETTINGS] die Layer, die Sie erstellen möchten, zum Beispiel LLDP, CDP oder L3v4:

# settings equivalent to CLI options
[SETTINGS]
# layers = ["LLDP", "CDP", "STATIC", "CUSTOM", "L3v4"]
layers = ["LLDP", "L3v4"]

Wenn die Konfigurationsdatei vollständig und korrekt ist, erstellen Sie die Netzwerktopologie mit folgendem Befehl:

~$ ~/local/bin/nvdct/conf/nvdct.py -c ~/local/bin/nvdct/conf/my_nvdct.toml

Die Ausgabe sieht dann etwa so aus:

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 erstellten Topologiedaten finden Sie unter ~/var/check_mk/topology/data/.

Dort ist außerdem ein symbolischer Link auf die Standardtopologie vorhanden:

~$ 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/

Die erzeugte Topologie ist nun in Checkmk über das Host-Menü verfügbar. Wählen Sie dort die Option “Network layer topology”, wie im folgenden Screenshot gezeigt. Starten Sie mit einem Ihrer Seed Devices, um die Netzwerktopologie zu erkunden.

Unabhängig davon, ob Sie die Netzwerktopologie manuell oder mit dem NVDCT-Paket erstellen, bietet Checkmk zahlreiche Anpassungsmöglichkeiten. Standardmäßig zeigt die Visualisierung die Beziehungen zwischen Hosts und Interfaces. Außerdem sehen Sie den aktuellen Status von Hosts und Services, jeweils mit einem Link zur passenden Ansicht.

Bei Bedarf können Sie Services ausblenden, um die Darstellung übersichtlicher zu machen. Alternativ können Sie über den Schalter oben links in der Visualisierung nur Services anzeigen, die Probleme haben.

Außerdem können Sie zwei Datensätze aus unterschiedlichen Zeitpunkten visuell miteinander vergleichen. Diese Funktion finden Sie in den Optionen unter “compare history”.

Zunächst wählen Sie einen Referenzzeitpunkt aus, in der Regel den aktuellen Zeitpunkt. Anschließend wählen Sie den Vergleichszeitpunkt. Die Topologie ermittelt dann die Unterschiede zwischen den Verbindungen zu diesen beiden Zeitpunkten, also Verbindungen, die zum Referenzzeitpunkt fehlen, sowie Verbindungen, die nur zum Referenzzeitpunkt vorhanden sind.

Darüber hinaus stehen verschiedene Darstellungsstile zur Verfügung. Aktuell können Sie zwischen zwei vordefinierten Layouts für die Anzeige der Daten wechseln: Full und Flat.

Das Full-Layout bietet eine bessere Übersicht über die Verbindungen, da diese in einer Baumstruktur dargestellt werden. Das Flat-Layout ist kompakter und auf einen Blick leichter zu erfassen, enthält aber weiterhin alle Verbindungsdaten, die beim Hover über Nodes und Verbindungen angezeigt werden.

Alternativ können Sie über die Funktion “layout configuration” ein vollständig freies Layout erstellen. Dieses wird automatisch geladen, wenn die Ansicht mit exakt denselben Filtereinstellungen erneut aufgerufen wird.

Oberhalb der Visualisierung finden Sie einige nützliche Funktionen. Sie können die Netzwerktopologie filtern und ihr Layout konfigurieren. Die Filter lassen sich anpassen, sodass Sie auch eigene Filter hinzufügen können. Standardmäßig sind bereits die gängigsten Filter vorhanden, zum Beispiel:

• Topology max nodes
• Topology mesh depth
• Hostname (regex)
• Hostalias (regex)
• Several host groups
• Host Contact Group
• Host states
• Host labels
• Host tags
• Site

Zu den ersten beiden Filtern noch ein paar zusätzliche Hinweise: “Topology max nodes” legt fest, wie viele Nodes angezeigt werden sollen. Wird das ausgewählte Limit erreicht, erscheint eine Warnung im Titel.

“Topology max depth” ist hilfreich, um die Erstellung der Topologie auf eine bestimmte Anzahl von Hops ab dem Start-Node oder den Start-Nodes zu begrenzen.

Außerdem können Sie die Unterschiede zwischen zwei Zeitpunkten vergleichen, um visuell zu prüfen, was sich verändert hat. Mit NVDCT können Sie die Topologie darüber hinaus individuell gestalten, etwa mit verschiedenen Icons, eigenen Farben für Linien, stärkeren Verbindungen und weiteren Optionen.

Zusätzlich gibt es einen integrierten Filter, mit dem Sie die Standardparameter der Visualisierung anpassen können. Er heißt topology_filters. Klonen Sie diesen Filter und passen Sie die Parameter nach Bedarf an.

{
    "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 sind hier vor allem die Indizes „images“ und „line_config“. Der Index images hat zwei Keys:

• „icon“: ein Icon, das oben links am Node angezeigt wird und vorkonfigurierte Icons im Core überschreibt
• „emblem“: ein Bild, das das blaue Fragezeichen bei Nodes ersetzt, die nicht mit dem Core verknüpft sind

Der Index line_config hat ebenfalls zwei Keys:

• „thickness“: die gewünschte Stärke der Verbindung
• „color“: die Farbe der Verbindung. Hier werden sowohl Farbnamen als auch HEX-Farbcodes akzeptiert.