Netzwerk-Monitoring: was beobachten, worauf alarmieren

Ein Alarm nützt nur, wenn ihn jemand liest, und niemand liest einen Strom, der überwiegend Rauschen ist. Ein Netz zu überwachen heißt nicht, ein Werkzeug zu installieren, sondern zu entscheiden, was Sie wissen müssen, wie schnell, und wer handeln muss, wenn es eintritt.

Denken Sie an das Armaturenbrett eines Autos. Es hat zwei Arten von Instrumenten. Anzeigen (Geschwindigkeit, Tank, Temperatur) zeigen einen Wert fortlaufend; Sie schauen hin, wann Sie wollen, und ihr Wert liegt im Verlauf, etwa in der Tanknadel, die langsam gegen Null geht. Warnleuchten bleiben dunkel, bis etwas jetzt Ihre Aufmerksamkeit braucht: Öldruck, Bremsen. Ein gutes Armaturenbrett hat viele Anzeigen und wenige Leuchten. Und jeder weiß, was mit einer Warnleuchte passiert, die immer brennt: Nach einer Woche sieht sie niemand mehr. Netzwerk-Monitoring funktioniert genauso. Grafiken sind die Anzeigen, Alarme die Warnleuchten, und die meisten Setups scheitern, weil sie Anzeigen zu Leuchten machen.

Dieser Leitfaden ist die Karte: was Geräte bereits melden und wie, was in Grafiken gehört und worauf alarmiert wird, wo Sie anfangen und wie Alarme aussagekräftig bleiben. Die beiden Protokolle, mit denen Geräte über sich berichten, haben eigene Artikel: Was ist Syslog? und Was ist SNMP?

Warum überhaupt überwachen?

Monitoring existiert, weil Störungen passieren, wenn niemand hinschaut. Eine Leitung, die um 14 Uhr voll läuft, sieht nur, wer um 14 Uhr hinsieht. Ein Port, der um drei Uhr nachts eine Minute ausfällt, hinterlässt bis zum Morgen keine Spur. Ein Mensch kann nicht ununterbrochen zusehen, ein Programm schon.

Der tiefere Grund ist sprachlich. „Das Internet ist langsam“ ist eine Meinung, keine Messung: welcher Standort, welche Uhrzeit, wie langsam? Ohne diese drei Antworten lässt sich keine Entscheidung darauf bauen. Monitoring macht aus Meinungen Messungen, und ein Problem, das sich messen lässt, wird lösbar, noch bevor es gelöst ist. Kapazitätsprobleme kommen dabei nicht plötzlich, sie wachsen leise: Standortleitungen werden aus Kostengründen knapp bemessen, dann gehen alle gleichzeitig in eine Online-Besprechung, und die Leitung ist dicht.

Wann brauchen Sie es nicht? Bei einem Switch und wenigen Geräten kosten Server, Software und Dashboard womöglich mehr, als sie bringen. Die Schwelle ist überschritten bei mehr als einem Standort, einer nach Kapazität bezahlten Leitung oder wenn Sie von Ausfällen durch Benutzer erfahren. Das Letzte ist das deutlichste Zeichen.

Was Geräte schon melden: Logs und Messwerte

Bevor Sie ein Werkzeug wählen, hören Sie, was bereits gesagt wird. Netzwerkgeräte berichten über zwei Kanäle, und die beantworten verschiedene Fragen.

Messwerte sind Zahlen, regelmäßig abgefragt, meist über SNMP. Ein Monitoring-Server fragt jedes Gerät alle paar Minuten nach seinen Zählern: Bytes durch eine Schnittstelle, CPU-Last, Speicher, Temperatur. Ein Wert sagt wenig, zwei im Abstand weniger Minuten ergeben eine Rate, eine Reihe von Raten einen Trend. SNMP funktioniert auch umgekehrt: Ein Gerät kann im Moment eines Ereignisses einen Trap senden.

Logs sind Sätze, vom Gerät gesendet, wenn etwas passiert, meist per Syslog: welcher Port ausfiel, wer sich anmeldete, welcher Prozess scheiterte, welche Konfiguration sich änderte. Eine Störungsanalyse liest man in Logs.

Eine Zahl erzählt keine Geschichte, ein Satz zeigt keinen Trend. SNMP sagt, die CPU liegt bei 80 %; Syslog, welcher Prozess sie belastet. Ein sauberer Aufbau sammelt beides. Die Mechanik, etwa was die führende Zahl einer Syslog-Zeile bedeutet, warum der SNMP-Community-String für jeden im Netz lesbar ist und eine Windows-Firewallregel, die Trap-Empfänger still blockiert, ist in den beiden Protokollartikeln gemessen.

Anzeigen oder Warnleuchten: Trends und Alarme

Kapazität gehört in Grafiken; Verfügbarkeit und Ausfälle gehören in Alarme. Dieser eine Satz verhindert die meisten Monitoring-Fehler.

Kapazität ändert sich langsam und braucht Kontext. Eine Leitung bei 70 % ist mittags in Ordnung und bedenklich, wenn sie letzten Monat bei 40 % lag. Dafür muss niemand geweckt werden; jemand sollte die Kurve in einer wöchentlichen Durchsicht sehen und einen Ausbau planen. Werkzeuge auf Basis von Round-Robin-Datenbanken, klassisch Cacti, sind genau dafür gebaut: lange Kurven, wenig Aufwand, gut lesbar.

Verfügbarkeit und Ausfälle verlangen jetzt Handeln. Ein Core-Switch, der nicht mehr antwortet, eine ausgefallene Leitung, eine volllaufende Platte, eine USV im Batteriebetrieb: Das sind Warnleuchten. Werkzeuge mit Triggern und Benachrichtigungen, verbreitet ist Zabbix, machen aus Bedingungen Alarme.

Die Grenze ist scharf genug für eine Faustregel: Das eine Werkzeug zeichnet Kapazität, das andere macht aus Verfügbarkeit Alarme. Reife Umgebungen betreiben beides nebeneinander, manche ergänzen ein drittes Stück für das Inventar, damit jede Frage einen offensichtlichen Ort hat.

Wo anfangen: die ersten Grafiken

Bei Dutzenden Geräten und Hunderten Schnittstellen ist die Frage nicht, was man grafisch darstellen könnte, sondern was zuerst auf den Bildschirm kommt.

Zuerst: der Port zum Router Ihres Internetanbieters. Der gesamte Internetverkehr der Organisation läuft über diese eine Schnittstelle, also beantwortet ihre Grafik Kapazität und „warum ist das Internet langsam“ zugleich. Im Störfall schaut man zuerst dorthin, ihr eigentlicher Wert zeigt sich aber an normalen Tagen: welcher Anteil einer 200-Mbit/s-Leitung zu welcher Stunde belegt ist.

Lesen Sie das Maximum, nicht den Durchschnitt. Für Kapazitätsentscheidungen zählt der Spitzenwert: Liegt die Spitze einer 100-Mbit-Leitung bei 95, beginnt sie zu sättigen, auch wenn der Durchschnitt entspannt aussieht. Und achten Sie auf die Richtung: Eingehend und ausgehend sind relativ zur überwachten Schnittstelle definiert, nicht zu Ihnen.

Dann Gleiches mit Gleichem vergleichen. Setzen Sie nicht fünf Eigenschaften eines Geräts nebeneinander, sondern dieselbe Eigenschaft möglichst vieler Geräte, etwa den Internet-Uplink jedes Standorts. Der Wert liegt im Vergleich. Gefährlich ist, auf einen Standort zu schauen und zu schließen „alle haben 200 Mbit/s, also geht es allen gut“, während der Standort, der nicht auf dem Bildschirm ist, an seiner Decke hängt.

An die Wand damit. Ein freier Monitor oder Fernseher in der Zentrale mit einem zweispaltigen Raster der kritischsten Grafiken holt Monitoring vom Schreibtisch in den Raum. Stehen acht Grafiken ständig im Blick, fällt ein volllaufender Standort oder ein verstummter Switch auf, ohne dass jemand ein Dashboard öffnet.

Über den Verkehr hinaus: Gerätezustand

Bandbreite ist nicht das Einzige, was SNMP grafisch darstellen kann. Der physische und systemische Zustand der Geräte zählt ebenso, und hier findet Monitoring Probleme, die niemand vermutet hätte. Sie haben vielleicht in jede Filiale dasselbe Switch-Modell gestellt, ihr Zustand muss aber nicht gleich sein. Entscheidend ist meist die Umgebung: Sauberkeit, Raumtemperatur, Klimatisierung, Belüftung des Schranks.

Neben dem Verkehr lohnen sich: Temperatur, CPU und Speicher von Switches, Routern und Firewalls; Plattenbelegung von Servern, um Wochen vorher zu sehen, wann sie vollläuft; USV-Status mit Ladung, Last und Restlaufzeit; Latenz und Paketverlust zu wichtigen Zielen, die eine Leitung verschlechtert zeigen, lange bevor sie voll ist; Umgebungssensoren im Technikraum, falls sie SNMP sprechen.

Auf das Knistern hören: Störungen früh erkennen

Bevor eine Funkverbindung ganz ausfällt, wird das Rauschen stärker. Netze verhalten sich genauso. Steigende Fehlerzähler einer Schnittstelle, Speicher, der auf einem Switch Woche für Woche wächst, eine Gerätetemperatur, die jeden Sommer ein paar Grad höher liegt: Jedes davon ist eine leise Warnung. Nehmen Sie diese kleinen Signale ernst und das Gerät in Wartung, und der Ausfall passiert nie. Stellen Sie die Zähler dar, die auf Probleme hinweisen, nicht nur die, die Last anzeigen, und sehen Sie die langsamen Kurven planmäßig durch; einen schleichenden Anstieg bemerkt niemand im täglichen Vorbeischauen.

Syslog trägt dieselbe Frühwarnung, mit einer Besonderheit: Eine Meldung, die sich alle paar Sekunden wiederholt, ist keine Information, sondern ein Symptom. Im Labor hinter Was ist Syslog? verwarf ein Switch, der monatelang ohne Beschwerde lief, alle zwei Sekunden eine Protokollnachricht, die er nicht verstand, und 99 % seiner Protokollierung waren diese Wiederholung.

Alarme aussagekräftig halten

Alarmmüdigkeit ist das Monitoring-Versagen, das jeder kennt: So viele Alarme lösen aus, dass niemand sie mehr liest, und der wichtige geht in der Menge unter. Vier Regeln halten Alarme aussagekräftig.

Nur auf Handlungsbedürftiges alarmieren. Lautet die richtige Reaktion „zur Kenntnis nehmen und weitermachen“, gehört es in eine Grafik oder einen Bericht, nicht in jemandes Hosentasche. Jeder Alarm sollte beantworten: Was tut die Person, die ihn bekommt, als Nächstes?

Jedem Alarm einen Zuständigen geben. Eine Meldung gehört zu einer benannten Person oder Rufbereitschaft, nicht in ein gemeinsames Postfach, von dem alle annehmen, jemand anderes lese es.

Schwellen aus der Historie ableiten, nicht aus Voreinstellungen. Die Grafik der letzten Monate zeigt, was für jede Leitung normal ist. Darauf beruhende Schwellen lösen bei gewöhnlichen Spitzen nicht aus; Herstellervorgaben lösen ständig oder nie aus.

Einen ignorierten Alarm als Fehler behandeln. Löst ein Alarm aus und niemand handelt, ist der Alarm falsch oder der Prozess. Beheben Sie eines von beiden. Dasselbe gilt für Alarme, die täglich auslösen und von selbst verschwinden: Sie trainieren den Leuten das Ignorieren an.

Eine Alarmklasse verdient Erwähnung, weil sie so oft ungenutzt bleibt: SNMP-Traps bei fehlgeschlagener Authentifizierung. Fragt jemand ein Gerät mit falschem Community-String ab, bekommt die fragende Seite gar keine Antwort, das Gerät kann den Fehlversuch aber dem Monitoring-Server melden. Still zur falschen Seite, sichtbar nur für den, der auf Port 162 hört: eines der billigsten Einbruchssignale, die ein Netz hat.

Live-Ansicht oder aufgezeichnete Historie?

Monitoring-Werkzeuge bieten meist zwei Blickweisen. Standard ist die Aufzeichnung: Der Poller misst alle paar Minuten, speichert die Werte, und Sie schauen bei Bedarf in die Grafik. Viele Werkzeuge haben zusätzlich einen Echtzeitmodus, der eine Grafik alle paar Sekunden abfragt. Was richtig ist, hängt daran, ob jemand vor dem Bildschirm sitzt. Verfolgt jemand aktiv eine Störung, ist Echtzeit unbezahlbar. Die Realität ist aber meist ein kleines Team, das mehrere Aufgaben jongliert und Monitoring nur bei Bedarf öffnet; für dieses ist die aufgezeichnete Historie weit praktischer.

Wie auch immer: Fünf-Minuten-Abfragen verbergen kurze Spitzen. Eine Spitze von Sekunden verschwindet im Mittel, weshalb eine Leitung Gespräche abbrechen kann, während ihre Grafik gut aussieht. Fragen Sie kritische Leitungen häufiger ab, und nutzen Sie Traps für Ereignisse, die nicht warten können.

Grundlagen: Zeit, Zugang und Aufbewahrung

Drei Dinge liegen unter jeder Grafik und jedem Alarm, und jedes versagt leise.

Zeit. Grafiken und Logs sind nur so gut wie ihre Uhren. Ein Monitoring-Server mit driftender Uhr verschiebt jede Kurve, und Grafiken verschiedener Geräte passen nicht mehr zusammen. Synchronisieren Sie Server und Geräte mit derselben verlässlichen Zeitquelle, bevor Sie einem Zeitverlauf trauen.

Zugang. Monitoring-Protokolle sind mächtig und in ihren älteren Versionen ungeschützt: SNMPv2c sendet seinen Community-String im Klartext, Syslog über UDP Logzeilen, die jeder auf dem Weg lesen kann. Halten Sie Monitoring-Verkehr in einem Managementnetz, nutzen Sie SNMPv3, wo Geräte es können, und beschränken Sie, wer Geräte abfragen darf. Wie Management-Verkehr ein eigenes Segment bekommt, steht im Leitfaden Netzwerksegmentierung.

Aufbewahrung. Alles für immer zu sammeln ist teuer und sinnlos. Legen Sie fest, wie lange Grafiken und Logs bleiben, filtern Sie Rauschen an der Quelle mit sinnvollen Schwellen, fassen Sie Wiederholungen zusammen und archivieren Sie Altes. Unterliegen Ihre Logs einer Aufbewahrungspflicht, ist das nicht allein Ihre Entscheidung, und Aufbewahrungsdauer, Manipulationsschutz und verlässliche Zeitstempel entstehen um den Collector herum, nicht durch das Protokoll. Planen Sie Platz ein: Im Syslog-Labor erzeugte ein einziger untätiger Switch rund 11 MB Logs am Tag.

Fazit: Installieren ist leicht, Hinschauen ist die Arbeit

Ein Monitoring-Werkzeug zu installieren, ein Gerät hinzuzufügen und die erste Grafik zu zeichnen dauert einen halben Tag. Die eigentliche Arbeit ist, dass jemand hinschaut. Das häufigste Versagen ist kein fehlendes Werkzeug, sondern eines, das „damit wir eins haben“ eingerichtet und herrenlos gelassen wurde: ein Dashboard, das sechs Monate später niemand öffnet.

Eine kurze Prüfliste für den Anfang:

• Zuerst den Internet-Uplink grafisch darstellen, dann die Uplinks zwischen Switches, dann den Zustand der Kerngeräte.
• Maxima lesen, nicht Mittelwerte, wenn es um Kapazität geht.
• Standorte nebeneinander vergleichen, auf demselben Bildschirm.
• Beide Kanäle sammeln: SNMP für Zahlen, Syslog für Ereignisse.
• Nur auf Handlungsbedürftiges alarmieren und jedem Alarm einen benannten Zuständigen geben.
• Langsame Kurven planmäßig durchsehen, inklusive Fehlerzählern und Temperaturen.
• Jede Uhr synchronisieren, bevor Sie Zeitverläufen trauen.

Die Protokollartikel dieses Leitfadens zeigen, was diese Kanäle tatsächlich transportieren, gemessen an einem echten Switch: Was ist Syslog? und Was ist SNMP?