Workshop: Monitoring mit Checkmk – Teil 15 So kommt die Netzwerk-Topologie ins Monitoring

Ein Monitoring-System soll meist auch die Netzwerkstruktur abbilden – welche Server laufen hinter welchen Servern? Wie sieht es mit Abhängigkeiten und Benachrichtigungen aus? Checkmk bietet hier mit wenig Aufwand relativ viel.

Eine ordentlich visualisierte Netzwerk-Topologie ist nicht nur hübsch, sondern verschafft auch Übersicht und hilft bei der Navigation (siehe Abbildung 1). Checkmk setzt dabei auf schlichte Eltern-Kind-Beziehungen, die sich manuell setzen, aber auch automatisch ermitteln lassen.

Diese Eltern-Kind-Beziehungen sind allerdings nicht vornehmlich als Basis für reines Eye-Candy gedacht. Sie lösen im Grunde zwei ganz andere Probleme. Nehmen Sie an, auf einem Virtualisierungsserver laufen ein paar virtuelle Maschinen. Wenn nun der Server nicht mehr erreichbar ist, etwa weil eine Netzwerkschnittstelle ausgefallen ist, bekommen Sie dafür (sofern konfiguriert) eine Benachrichtigung. Nun sind in der Folge aber auch die einzelnen VMs auf dem Server nicht mehr erreichbar. Und sofern falls diese ebenfalls als einzelne Hosts überwacht werden, bekommen Sie gleich noch eine ganze Reihe weiterer Benachrichtigungen – was Ihnen aber gar nichts bringt, schließlich ist das Problem ja schon bekannt. Anders ausgedrückt: Fällt ein ganzes Netzwerksegment aus, wollen Sie keine Host-Down-Benachrichtigung für alle Hosts in diesem Segment bekommen.

Bildergalerie

Bildergalerie mit 8 Bildern

Zumal: Die virtuellen Maschinen können ja durchaus noch laufen! Das ist sogar wahrscheinlich, denn warum sollten virtuelle-Maschinen-Hosts nicht laufen, nur weil der Virtualisierungsserver nicht erreichbar ist? Down wäre also gar nicht der richtige Status, und auch der Status Up würde der Sache freilich nicht gerecht. In solchen Fällen versieht Checkmk Hosts mit dem Status „UNREACH“ – denn genau das sind solche Hosts: Aus unbekannten Gründen nicht erreichbar (siehe Abbildung 2).

Nun, je nach Konfiguration könnten solche Hosts durchaus als Up betrachtet werden: Wenn entweder ein zweiter, alternativer Elternteil existiert (etwa redundante Switches) oder der Kind-Host generell nicht per Ping von Checkmk erreicht werden kann und deshalb grundsätzlich als Up gesehen wird.

Eltern-Kind-Beziehungen anlegen

Es gibt mehrere Möglichkeiten, derlei hierarchische Beziehungen zu setzen. Genauer: Sie setzen immer den Elternteil.

Die einfachste Variante ist der „Parent scan“ (siehe Abbildung 3); zu finden über das Hosts-Menü in der Ordneransicht des Setups. Über dieses Feature können alle Hosts oder Hosts in einzelnen Ordnern gescannt werden. Der Scan arbeitet mit traceroute und setzt das jeweils letzte gefundene Gateway als Parent, sofern es sich dabei um einen überwachten/bekannten Host im Monitoring handelt. So würde beispielsweise ein Switch als Parent für daran angeschlossene Geräte gesetzt.

Wenn kein passendes Gateway gefunden wird, erstellt Checkmk einen Pseudo-Host im Ordner „Main/Parents“ (inklusive Parents-Ordner selbst, falls nicht vorhanden). Dabei passiert in der Praxis regelmäßig etwas „Lustiges“: Angenommen, im Monitoring befindet sich ein Host, der nicht direkt angepingt werden kann, weil er in einem nicht verbundenen Netzwerk-Segment liegt (warum auch immer …). Der Scan findet dann irgendwo einen Hinweis auf ein letztes Gateway, meist auf dem Router den Zugangspunkt des Internet-Providers.

Beim Versuch, für diesen Artikel entsprechende Screenshots zu erstellen, wurde für einen Host mit Fantasie-IP ein Parent-Host namens „gw-mysite_24-172-28-128-1“ mit der IP „171.28.128.1“ erstellt (siehe Abbildung 4).

Nun taucht diese IP hier nirgends auf – nicht auf dem Router, dem Cisco-Switch oder einem Rechner mit virtuellen Netzwerkschnittstellen für Container oder dergleichen. Nach langer Analyse hat sich die IP als Gateway-Adresse des ISP erwiesen, der auf CG-NAT setzt … In Bild 4 sehen Sie auch den automatisch generierten Alias „Created by parent scan“. Diesen Alias können Sie in den Scan-Einstellungen anpassen und später als Filter für Regeln und Ansichten nutzen – es lohnt sich also, hier etwas sinnvolles zu verwenden.

Aufwändiger, aber weniger fehlerträchtig ist das Anlegen der Parents über die Eigenschaften von Hosts oder – besser – ganzen Ordnern (siehe Abbildung 5). Ein Beispiel dafür: Kürzlich haben wir Ihnen gezeigt, wie sich mit Checkmk/check_httpv2 Webseiten überwachen lassen. Wenn Sie derlei (externe) Webseiten als Hosts einrichten, kann es sich lohnen, diesen einen Parent-Host zuzuordnen – zum Beispiel den Router. Zum einen dient das der Ordnung, zum anderen darf man davon ausgehen, dass ein abgestürzter Router keinen Einfluss auf externe Webseiten hat. Router down, Webseiten up aber nicht erreichbar – kein Grund, die Webseiten als Down anzusehen, Unreach passt deutlich besser.

Eltern-Kind-Beziehungen im Monitoring

Sind die Beziehungen einmal etabliert, lässt sich im Monitoring damit arbeiten. In der Einleitung haben Sie schon einen Blick auf die aufgeräumte Netzwerk-Topologie werfen können – zu finden unter „Monitor/Network topology“.

Schon bei wenigen Hierarchieebenen ist die vorgegebene Baumansicht mäßig hilfreich. Sobald Sie „Layout configuration“ wählen wird es plötzlich sehr viel weniger aufgeräumt – alle Knoten werden mit Icons zum Skalieren und Rotieren sowie umrandeten Bereichen für ihre Kinder angezeigt (siehe Abbildung 6). Per Drag&Drop müssen Sie zunächst mal für grobe Ordnung sorgen.

Der Ausgangspunkt für den Baum ist natürlich die Instanz (im Bild „mysite_24“). Dann folgen alle Hosts, denen kein expliziter Parent zugeordnet wurde. Im Bild sind einige Elternteile nach rechts gezogen, beispielsweise die Fritzbox („Fritze“), die einigen überwachten Webseiten als Parent dient. Unten sind gleich mehrere Ebenen zu bewundern: Auf dem Desktoprechner „tauer“ läuft als Kind ein virtuelles Ubuntu („ubuntu_24_vm“) und darauf wiederum eine ganze Reihe von Docker-Containern wiederum als Kinder der Ubuntu-VM.

Abstände der Kinder untereinander und von den Eltern lassen sich über die Schieberegler einstellen und bisweilen helfen auch andere Linienstile, den Überblick zu verbessern – hier wird ein wenig Spieltrieb verlangt. Wichtig: Speichern nicht vergessen! Ansonsten war die Mühe nach dem nächsten Reload umsonst.

Und selbstverständlich lassen sich die angezeigten Hosts über Filter reduzieren. Fertig gelayoutet zeigt die Visualisierung stets den aktuellen Stand und sobald der Mauszeiger über einem Host liegt auch dessen Details als Overlay.

Dennoch gehen bisweilen Layouts etwas verloren – mehr Präzision gibt es mit NagVis.

Topologie in NagVis

NagVis ist ein in Checkmk integriertes, aber letztlich eigenständiges, Tool zur Visualisierung von Netzwerkstrukturen auf Kartenmaterial – beispielsweise Standorte von Rechenzentren auf OSM-Karten (OpenStreetMap).

NagVis ist etwas hakelig: Zunächst mal erreichen Sie es nur über ein „Sidebar-Snapin“, also ein Widget in der rechten Seitenleiste, das zuvor aber manuell hinzugefügt werden muss (über das Plus-Symbol unten rechts).

In NagVis kann dann abermals die Eltern-Kind-Dynamik für eine automatische Darstellung genutzt werden: Dafür braucht es eine neue Karte („Manage Maps/Create Map“) vom Typ „Automap based on parent/child relations“ (siehe Abbildung 7).

Das Ergebnis ist umgehend eine automatisch gelayoutete Netzwerk-Visualisierung. Auf der Karte gibt es dann deutlich mehr Details zu den einzelnen Knoten/Hosts und zudem sind sie grundsätzlich verlinkt, so dass man fix zu problematischen Geräten gelangt.

In den Kartenoptionen gibt es noch etliche Einstellungen für das Feintuning, eine sei Ihnen direkt ans Herz gelegt: „event_sound“ lässt eine markerschütternde Sirene ertönen, wenn ein Host auf Warn oder Crit wechselt – vielleicht ist das nicht in jedermanns Sinne (siehe Abbildung 8).

Ein Tipp zum Schluss: Wenn Sie viel mit Topologie-Ansichten arbeiten oder das Eltern-Kind-Feature intensiv nutzen wollen, bietet es sich an, die Eltern- und Kinder-Hosts weiter zu strukturieren, beispielsweise über Ordner, Label oder Hostgruppen. Mehr zu diesen Strukturierungselementen zeigt Teil 4 dieses Workshops.

Workshop: Monitoring mit Checkmk – Teil 1

Wie funktioniert das Monitoring mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 2

Monitoring von Servern und Workstations

Workshop: Monitoring mit Checkmk – Teil 3

Monitoring von Webseiten, Mailkonten und Applikationen

Workshop: Monitoring mit Checkmk – Teil 4

Wie sieht eine gute Strukturierung in Checkmk aus?

Workshop: Monitoring mit Checkmk – Teil 5

Die wichtigsten Schritte zur Backup-Überwachung mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 6

Wie funktioniert das Überwachen von Schnittstellen und Ports mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 7

Dashboards aus Daten: So wird das Checkmk-Inventar sichtbar

Workshop: Monitoring mit Checkmk – Teil 8

Checkmk aktualisieren – vorsichtig!

Workshop: Monitoring mit Checkmk – Teil 9

Checkmk: Android-Geräte überwachen – oder nicht?

Workshop: Monitoring mit Checkmk – Teil 10

So monitoren Sie Proxmox VE mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 11

Webseiten mit check_httpv2 überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 12

Zertifikate mit check_cert überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 13

Checkmk anpassen: Ansichten nach Belieben gestalten

Workshop: Monitoring mit Checkmk – Teil 14

Container im Blick: Docker mit Checkmk überwachen

Workshop: Monitoring mit Checkmk – Teil 16

Zusammenspiel: Integrationen von und in anderen Systemen

(ID:50613445)