Workshop: Monitoring mit Checkmk – Teil 6 Wie funktioniert das Überwachen von Schnittstellen und Ports mit Checkmk?

Ein funktionierendes Netzwerk ist die Grundlage jeder IT-Infrastruktur. Netzwerkschnittstellen und Ports sollten daher kontinuierlich überwacht werden. Dank SNMP ist dies sowohl einfach als auch herausfordernd.

Dieser Artikel behandelt zwei zentrale Aspekte des Netzwerk-Monitorings:

• 1. Die Überwachung sämtlicher Netzwerkschnittstellen regulärer Hosts – von WLAN-Interfaces eines Endnutzer-Laptops bis zu den Ethernet-Buchsen von Servern.

• 2. Die Integration von Infrastruktur-Hosts ins Monitoring, insbesondere Switches und deren einzelne Ports.

Detailliertes Monitoring hilft, defekte oder verunreinigte Kabel zu identifizieren, Flaschenhälse zu entdecken und Nutzerfrust zu minimieren. Gleichzeitig können ungewöhnlich hohe Netzwerkaktivitäten aufgedeckt werden, um z. B. Streaming-Dienste gezielt einzuschränken.

Bildergalerie

Bildergalerie mit 7 Bildern

Einrichtung in Checkmk

Die gesamte Einrichtung in Checkmk ist weitestgehend selbsterklärend, erfordert jedoch besondere Aufmerksamkeit bei zwei Aspekten: Windows und SNMP. Ersteres begnügt sich mit einem simplen separaten Plugin, Letzteres braucht einen kleinen Kniff, um unterschiedliche SNMP-Implementierungen abzudecken.

Im Folgenden geht es zunächst an die nötigen Vorarbeiten auf Seiten von Netzwerkgeräten und in Checkmk, dann an die Konfiguration von Checks und Plugins und letztlich werfen wir einen Blick auf die Daten im Monitoring.

Host-Vorbereitungen

Auf normalen Hosts (Servern und Workstations mit Checkmk-Agenten) sind keine zusätzlichen Schritte erforderlich, vorausgesetzt, sie sind bereits im Monitoring enthalten.

Bei Switchen hingegen sieht es anders aus. Zunächst: Natürlich geht es hier um Managed-Switches, nicht um die reinen Verteilerdosen. In kleineren Umgebungen könnten das zum Beispiel die populären Smart-Switches aus Ciscos 250er-Serie sein.

Zunächst müssen natürlich überhaupt erst mal die Verbreitung von Informationen via SNMP freigeben und gegebenenfalls weiter konfigurieren werden. Wichtiger: Die Ports sollten sinnvollbenannt werden! Standardmäßig werden die meisten Switches Ports schlicht durchnummerieren (siehe Abbildung 1), bestenfalls noch mit einer Info versehen, ob es sich um einen Trunk- oder Access-Port handelt.

Um später vernünftig filtern zu können, bietet sich ein passendes Namensschema an, etwa myport_03_backupserver, access_port_workstations oder was auch immer der Infrastruktur entspricht. Was später noch relevant wird: Verwendet der Switch für den Interface-Namen die SNMP-Variable ifAlias oder ifDescr?

Checkmk-Vorbereitung

SNMP bietet zwar einfachen Zugriff auf Informationen von Netzwerkgeräten, ist aber auch ein steter Quell der Freude – sofern man Ungereimtheiten und nicht standardisierte Kleinigkeiten mag.

In Checkmk sollen Ports mit ihren Namen auftauchen und nach diesen auch gefiltert werden können. Dazu muss Checkmk allerdings wissen, in welchem Feld das SNMP-Gerät den Namen speichert, ifAlias oder ifDescr.

Diese Information muss man händisch bei den jeweiligen Hosts in Checkmk angeben. Und das geht über das Feature „Host-Merkmale“, die zur Strukturierung eingesetzt werden – wie Hosts in Checkmk strukturiert werden, haben wir kürzlich [LINK AUF HOST-STRUKTUR-ARTIKEL] gezeigt.

Hierzu dient das Feature Host-Merkmale, das in Checkmk unter Setup → Host → Tags konfiguriert wird. Für ifAlias und ifDescr werden entsprechende Merkmale erstellt und den jeweiligen Hosts zugewiesen. Die korrekte Einstellung lässt sich durch einen Blick ins Switch-Inventar überprüfen. (siehe Abbildung 3).

Monitoring einrichten

Das Monitoring wird über folgende Regeln konfiguriert:

• 1. Service discovery rule: Network interface and switch port discovery

• 2. Agent rule: Network interfaces on Windows

• 3. Service monitoring rule: Network interfaces and switch ports

Die Agenten-Regel für Windows wird schlicht benötigt, um Windows-Hosts die nötigen Informationen zu entlocken – Einstellungen gibt es hier nicht. Der Windows-Agent wird um ein Plugin erweitert. Unter Linux liefert der Agent die Daten standardmäßig.

Die Service-Erkennungs-Regel dient dazu, die vom Agenten gelieferten Rohdaten ins Monitoring zu holen – und hier kommen gleich auch die oben gesetzten Merkmale zum Einsatz.

Die Service-Monitoring-Regel wiederum dient wie üblich dazu, die nun im Monitoring verfügbaren Services zu konfigurieren – dazu später mehr.

Service-Erkennung

Die Service-Erkennung besagt im Grunde Folgendes: "Erkenne einzelne Interfaces/Ports und nutze als Namen für diese Services die per SNMP gelieferten Aliasse (oder eben die Beschreibungen)." Als Bedingung für diese Regel wird in der Regel selbst das Host-Merkmal für ifAlias gesetzt (siehe Abbildung 4).

Diese Regel wird ein zweites Mal benötigt: Nun muss natürlich die Beschreibung statt des Aliasses für die Benennung der Services genutzt werden – und folglich wird als Bedingung das Host-Merkmal für ifDescr gesetzt.

Ports auf Switches werden erkannt und entweder nach ihrem Alias oder ihrer Beschreibung ins Monitoring aufgenommen.

Das Gemeine: Unterschiedliche Systeme verwenden Alias und Beschreibung nicht immer gleich. Was Cisco zum Beispiel unter Beschreibung versteht, landet in Checkmk als Alias (siehe Abbildung 5).

Übrigens: Für kleine Umgebungen mit nur wenigen Switches kann statt der Merkmale auch eine explizite Host-Liste als Bedingung genutzt werden. Dies ist jedoch nicht skalierbar.

Service-Auswertung

Nach der Service-Erkennung erscheinen zahlreiche neue Services für den Switch – bestenfalls bereits mit den korrekten Namen.

Für die Auswertung stehen in der Regel Network interfaces and switch ports rund 20 Optionen zur Verfügung (siehe Abbildung 6). Eine davon kann auch dabei helfen zu entscheiden, ob die gewünschten Namen nun Alias oder Description sind: Change infotext in check output. Mit Show alias and description lassen sich in der Zusammenfassung (Summary) in Checkmk sowohl Alias als auch Beschreibung des Service anzeigen – und welche Variante sich in den Host-Eigenschaften des Switches einstellen lassen.

Und damit geht es nun an den erfreulichen Part: Fein-Tuning! Alle Optionen der Regel sind mit durchaus sinnvollen Vorgaben versehen, für den Anfang kann es durchaus dabei bleiben.

Falls nicht: Die Konfiguration beschränkt sich fast immer auf die Angabe von Schwellwerten und zugehörigen Status, also beispielsweise der Status CRIT für eine maximale Auslastung der Bandbreite von 95 Prozent in der Regel Used bandwidth.

In diesem Beispiel wird schnell klar, dass ein einziger Augenblick nicht genügt, 95 Prozent der maximalen Bandbreite dürften bei nahezu jedem Download kurz erreicht werden. Daher bietet sich die zugehörige Option Average values for used bandwidth an: Hier wird schlicht ein Zeitraum in Minuten angegeben und dann ein Durchschnittswert für die Status-Berechnung verwendet (gibt es ebenso für weitere Optionen). Wenn dann 95 Prozent der maximalen Bandbreite über einen Zeitraum von einer Stunde genutzt werden, könnte ein Status-Wechsel auf CRIT durchaus sinnvoll sein.

Zumindest für manche Ports! In dieser Regel gibt es im Conditions-Bereich die Bedingung Port, über die sich Regeln auf bestimmte Ports beschränken lassen – via regulärem Ausdruck. Und da kommt wieder das zu Beginn angepriesene Namensschema zum Einsatz! Aspekte wie Auslastung und Paketfehlerraten spielen bei Ports mit Druckern schließlich eine andere Rolle als bei Servern oder gar Uplink-Ports zu weiteren Routern und Switches.

Monitoring in der Praxis

Zum Schluss noch kurz ein Blick ins Monitoring. Die Port-zugehörigen Services finden sich wie üblich direkt bei ihren Hosts. Zudem gibt es im Hauptmenü im Bereich Monitor den Punkt Search network interfaces mit einer separaten Suchmaske – um gezielt nach bestimmten Ports zu suchen.

Spannend sind hier aber vor allem die vielen Graphen für die Auswertung von Bandbreite, Paketen, Fehlern und so weiter (siehe Abbildung 7). Und da bietet sich der Einsatz eines nicht Port-spezifischen Tools an: Jeder Graph besitzt unten links ein Burger-Menü mit der Option Add to custom graph. Damit lässt sich mit wenigen Klicks ein einzelner Graph bauen, der zum Beispiel die Fehlerraten aller Ports dieses Switches auf einen Blick zeigt. Im gleichen Menü finden Sie auch die Option Add to dashboard, um sich ein eigenes Port-Monitoring-Dashboard zu bauen.

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 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

(ID:50324140)