Monitoring verstehen: Server und Netzwerke überwachen

Samstagnacht fällt eine Platte im Dateiserver aus. Das RAID 6 fängt es ab, wie im Beitrag RAID verstehen beschrieben, und alles läuft weiter. Niemand merkt etwas. Zwei Wochen später fällt eine zweite Platte aus, danach noch eine. Jetzt ist die Redundanz aufgebraucht, und der Server steht. Die erste Warnung gab es zwei Wochen früher. Sie blinkte nur an einem Gerät, das keiner ansah.

Genau dafür gibt es Monitoring: Systeme überwachen sich nicht selbst, also lässt man sie überwachen. Du erfährst von Problemen, bevor Anwender anrufen, und siehst Trends, bevor etwas voll läuft. In den Beiträgen zu Backup und Servern war das schon mehrfach die Frage: Woher weißt du, dass es funktioniert?

Was ist Monitoring?

Monitoring bedeutet, Systeme laufend zu messen und zu prüfen, die Werte mit Soll-Grenzen zu vergleichen und bei Abweichungen zu alarmieren. Die Ziele:

Verfügbarkeit: Läuft der Dienst, ist das Gerät erreichbar?
Leistung: Antwortet das System schnell genug? Ist es überlastet?
Kapazität: Wird etwas knapp, zum Beispiel Plattenplatz, Bandbreite oder Adressen? Wann?
Fehlersuche: Wann hat das Problem angefangen, was hat sich geändert? Gespeicherte Verläufe beantworten das.
Sicherheit: Gibt es auffällig viele fehlgeschlagene Anmeldungen, fehlende Updates, unbekannte Geräte?

Der entscheidende Unterschied zu „Wir schauen, wenn jemand meldet“ ist der Wechsel von reaktiv zu proaktiv: Du siehst das Problem, bevor es wehtut.

Was man überwacht

Überwacht wird auf mehreren Ebenen. Die folgende Übersicht zeigt, was dazugehört und welche Grenzwerte man als Startpunkt wählen kann. Die Zahlen sind Beispiele und müssen an dein Netz angepasst werden:

Ebene	Was wird gemessen?	Beispiel für Warnung und Kritisch
Server-Hardware	CPU-Last, Arbeitsspeicher, Plattenplatz, Temperatur, Lüfter, Netzteil, RAID-Status, SMART-Werte	Plattenplatz: 80 % und 90 % belegt. RAID: Kritisch bei „degradiert“
Netzwerk	Erreichbarkeit per Ping, Antwortzeit, Paketverlust, Bandbreite, Fehlerzähler an Ports	Ausfall des Routers: sofort kritisch. Paketverlust über 2 %: Warnung
Dienste	Port offen, HTTP-Antwort, Antwortzeit, DNS-Auflösung, DHCP-Pool-Auslastung	DHCP-Pool über 80 % belegt: Warnung
Zertifikate	Ablaufdatum von TLS-Zertifikaten	Unter 14 Tagen: Warnung, unter 3 Tagen: kritisch
Backup	Erfolg der Jobs, Alter der letzten erfolgreichen Sicherung	Letztes Backup älter als 26 Stunden: Warnung, älter als 48 Stunden: kritisch
Umgebung	Temperatur im Serverraum, Zustand und Restlaufzeit der USV, PoE-Budget am Switch	USV läuft im Batteriebetrieb: kritisch. PoE-Budget über 80 %: Warnung
Sicherheit	Fehlanmeldungen, ausstehende Updates, neue unbekannte Geräte	Viele Fehlanmeldungen in kurzer Zeit: Warnung

Die Beispiele zeigen, wie vieles, was du in dieser Reihe gelernt hast, zum Überwachen geeignet ist: Das Leistungsbudget bei PoE aus dem Beitrag PoE-Leistungsbudget berechnen, die Adresspools aus DHCP verstehen oder die USV aus dem Beitrag zur elektrischen Energie.

Das Prinzip: messen, speichern, bewerten und bei Abweichungen alarmieren.

Wie kommen die Werte zum Monitoring-System?

Es gibt zwei Grundmuster. Beim Pull fragt der Monitoring-Server die Geräte regelmäßig ab. Beim Push schickt das Gerät seine Werte von sich aus. Je nach Ziel kommen verschiedene Techniken zum Einsatz:

Methode	Wofür?	Port
Ping (ICMP)	Ist das Gerät erreichbar, wie lang ist die Antwortzeit?	kein Port (ICMP)
Port- und Dienstprüfung	Antwortet ein Dienst wirklich, zum Beispiel eine Webseite mit Statuscode 200?	je nach Dienst
SNMP	Messwerte von Netzwerkgeräten, Druckern, USVs und Servern	UDP 161 (Abfrage), UDP 162 (Meldungen)
Agent	Ein kleines Programm auf dem Server, das Werte erfasst und weiterschickt	je nach Produkt
Syslog	Ereignismeldungen von Geräten zentral sammeln	UDP 514
Flussdaten (NetFlow, sFlow)	Wer kommuniziert mit wem und wie viel?	je nach Verfahren

Die Ports und das Zusammenspiel von UDP und TCP kennst du aus dem Beitrag TCP/IP-Modell erklärt.

SNMP: Die Sprache der Netzwerkgeräte

Das Simple Network Management Protocol ist der Standard, um Switches, Router, Access Points und viele andere Geräte abzufragen. Die Beteiligten:

Der Manager (das Monitoring-System) stellt Fragen.
Der Agent im Gerät antwortet.
Die MIB (Management Information Base) beschreibt, welche Werte ein Gerät anbietet. Jeder Wert hat eine Nummer, die OID.

Zwei Beispiele für OIDs: 1.3.6.1.2.1.1.3.0 liefert die Laufzeit des Geräts (sysUpTime), 1.3.6.1.2.1.2.2.1.10 die Zahl der empfangenen Oktette (Byte) an einer Schnittstelle (ifInOctets). Du musst die Nummern nicht auswendig kennen, die Programme übersetzen sie in Namen.

Sicherheit: SNMPv2c oder SNMPv3?

SNMP gibt es in mehreren Versionen. Version 2c schützt den Zugriff nur mit einer „Community“, einem Klartext-Kennwort. Als Standardwert wird gern public verwendet, das jeder kennt. Version 3 bietet dagegen Benutzer, Authentifizierung und Verschlüsselung. Wo es geht, nimmst du SNMPv3 und gibst nur dem Monitoring-Server Zugriff.

Eine Abfrage mit den Net-SNMP-Werkzeugen (Linux) sieht mit Version 3 so aus. Benutzer, Passwörter und Adresse sind Platzhalter:

snmpget -v3 -l authPriv -u monitor -a SHA -A 'AuthPasswort' -x AES -X 'PrivPasswort' 192.168.10.1 sysUpTime.0

Der Befehl fragt den Router unter 192.168.10.1 nach seiner Laufzeit. -l authPriv verlangt Authentifizierung und Verschlüsselung, -a und -x legen die Verfahren fest.

Rechenbeispiel: Datenverkehr aus Zählern

SNMP liefert für Schnittstellen keine Datenrate, sondern einen Zähler, der die Zahl der übertragenen Oktette seit dem Start hochzählt. Die Rate berechnest du aus zwei Messungen. Ein Port zeigt um 10:00:00 den Wert 1.000.000.000 und eine Minute später 1.450.000.000 Oktette:

Differenz:   1.450.000.000 − 1.000.000.000 = 450.000.000 Byte
In Bit:      450.000.000 × 8 = 3.600.000.000 Bit
Rate:        3.600.000.000 Bit ÷ 60 s = 60.000.000 Bit/s = 60 Mbit/s

Auslastung eines 1-Gbit/s-Ports: 60 ÷ 1.000 = 6 %

Die Umrechnung von Byte in Bit mit dem Faktor 8 kennst du aus dem Beitrag Bit und Byte. Dabei gibt es eine Falle: Ein 32-Bit-Zähler läuft bei 232 = 4.294.967.296 über und springt auf null. Bei 1 Gbit/s, das sind 125 MB/s, passiert das nach:

4.294.967.296 Byte ÷ 125.000.000 Byte/s ≈ 34 Sekunden

Bei schnellen Schnittstellen muss man also sehr häufig messen oder gleich die 64-Bit-Zähler verwenden (ifHCInOctets). Sonst stimmen die Werte nicht.

Zustände, Schwellwerte und Alarme

Ein Monitoring-System bewertet jeden Wert mit einem Zustand. Verbreitet sind vier:

Code	Zustand	Bedeutung
0	OK	Alles im grünen Bereich
1	WARNING	Auffällig, aber noch kein Notfall
2	CRITICAL	Handlungsbedarf, Dienst gestört oder in Kürze gestört
3	UNKNOWN	Der Wert konnte nicht ermittelt werden

Die Zahlen sind die Rückgabewerte, die Prüfprogramme nach dem Standard von Nagios und davon abgeleiteten Systemen verwenden. Ein einfaches Prüfskript unter Linux zeigt das Prinzip. Es prüft die Belegung eines Dateisystems und meldet entsprechend:

#!/bin/bash
# Einfacher Check: Belegung des Dateisystems
belegt=$(df --output=pcent /daten | tail -1 | tr -dc '0-9')
if [ "$belegt" -ge 90 ]; then
  echo "CRITICAL: /daten zu ${belegt} % belegt"; exit 2
elif [ "$belegt" -ge 80 ]; then
  echo "WARNING: /daten zu ${belegt} % belegt"; exit 1
else
  echo "OK: /daten zu ${belegt} % belegt"; exit 0
fi

Das Skript fragt mit df die Belegung ab, trennt die Prozentzahl heraus und vergleicht sie mit den Schwellwerten 80 und 90. Meldung und Exit-Code gehen an das Monitoring-System. Pfad und Grenzen sind Beispiele.

Gute Alarme: weniger ist mehr

Ein Monitoring, das ständig Alarm schlägt, wird irgendwann ignoriert. Man nennt das Alert Fatigue, Alarmmüdigkeit. Gegen sie helfen einige Regeln:

Jeder Alarm braucht eine Aktion. Wenn niemand etwas tun muss, ist es kein Alarm, sondern ein Messwert für das Dashboard.
Kurze Spitzen ignorieren. Eine CPU, die für Sekunden bei 100 Prozent liegt, ist normal. Alarmiere erst, wenn der Wert zum Beispiel 15 Minuten über 90 Prozent bleibt.
Wiederholen, bevor man alarmiert. Ein einzelner verlorener Ping ist kein Ausfall. Üblich ist, einen Fehler erst nach mehreren Wiederholungen als endgültig zu werten.
Wartungsfenster eintragen. Bei geplanten Arbeiten werden Alarme für die betroffenen Systeme pausiert.
Eskalation festlegen. Wer wird zuerst informiert, wer nach 30 Minuten ohne Reaktion? Nachts reichen kritische Meldungen für die Bereitschaft.

Trends erkennen: Wann ist der Platz voll?

Gespeicherte Verläufe erlauben eine Prognose. Auf dem Dateiserver sind 100 GB frei, und der Verbrauch wächst um 2 GB pro Tag:

100 GB ÷ 2 GB/Tag = 50 Tage

In sieben Wochen ist der Server voll. Du kannst rechtzeitig Platz schaffen, statt eines Nachts um drei von der Meldung „Disk full“ überrascht zu werden.

Verfügbarkeit aus dem Monitoring berechnen

Im Beitrag Was ist ein Server? haben wir Verfügbarkeit in Prozent und Ausfallzeit im Jahr umgerechnet. Das Monitoring liefert dafür die Messwerte. Ein Monat mit 30 Tagen hat 43.200 Minuten. Fällt der Dienst für 5 Minuten aus:

Verfügbarkeit = (43.200 − 5) ÷ 43.200 = 0,99988 ≈ 99,988 %

Das klingt nach sehr viel. Doch eine Zusage von 99,99 Prozent erlaubt in diesem Monat nur 43.200 × 0,0001 = 4,32 Minuten Ausfall. Die 5 Minuten sind also schon zu viel. Solche Rechnungen sind der Grund, warum Zusagen zur Verfügbarkeit nur mit einer belastbaren Messung einen Wert haben.

Monitoring, Logging und Dashboards

Drei Begriffe, die oft vermischt werden:

Monitoring misst Zustände und Werte und bewertet sie. Es beantwortet: „Ist alles in Ordnung?“
Logging sammelt Ereignisse: Wer hat sich wann angemeldet, welcher Fehler trat auf? Es beantwortet: „Was ist passiert?“ Die zentrale Sammlung per Syslog hilft, weil man nicht auf jedem Gerät einzeln nachsehen muss.
Dashboards zeigen Werte übersichtlich für den Blick auf einen Bildschirm. Alarme dagegen holen dich, wenn du nicht hinsiehst.

Damit Logs von verschiedenen Geräten zusammenpassen, müssen alle Uhren übereinstimmen. Dafür sorgt ein gemeinsamer Zeitserver (NTP). Ohne ihn lassen sich Ereignisse nicht in die richtige Reihenfolge bringen.

Werkzeuge im Überblick

Werkzeug	Ansatz	Typische Stärke
Zabbix	Open Source, Agenten und SNMP, alles in einem	Breiter Funktionsumfang, Vorlagen für viele Geräte
Icinga, Nagios	Prüfprogramme mit Zuständen OK, WARNING, CRITICAL	Flexible Checks, weit verbreitetes Prinzip
Checkmk	Automatische Erkennung, viele fertige Prüfungen	Schneller Einstieg
Prometheus mit Grafana	Pull von Messwerten, Zeitreihen, Dashboards	Stark bei Servern, Containern und Anwendungen
LibreNMS	Open Source, auf SNMP und Netzwerkgeräte ausgerichtet	Netzwerk-Überblick mit wenig Aufwand
PRTG	Kommerziell, Sensor-Modell, eingeschränkte Gratis-Version	Einfache Bedienung unter Windows

Welches Werkzeug passt, hängt von Größe, Budget und Erfahrung ab. Die Prinzipien aus diesem Beitrag gelten bei allen.

Praxisbeispiel: Das Monitoring der Firma

Die Firma richtet für das Server-VLAN einen Monitoring-Server ein, srv-monitor mit der Adresse 192.168.10.160. Er prüft die wichtigsten Dinge, die in den Beiträgen dieser Reihe vorkamen:

Objekt	Prüfung	Intervall	Warnung	Kritisch
Router (192.168.10.1)	Ping	1 Minute	Antwort über 50 ms	Keine Antwort in 3 Versuchen
Dateiserver	Plattenplatz	5 Minuten	80 %	90 %
Dateiserver	RAID-Zustand	5 Minuten	–	Degradiert oder Platte fehlt
Backup (srv-backup)	Alter des letzten erfolgreichen Laufs	1 Stunde	Über 26 Stunden	Über 48 Stunden
DHCP-Pool VLAN 40	Belegte Adressen von 51	10 Minuten	Über 41 (80 %)	Über 48
PoE-Switch Obergeschoss	Genutzte Leistung gegenüber Budget 195 W	5 Minuten	Über 156 W (80 %)	Über 185 W
USV	Batteriebetrieb	1 Minute	–	Sofort bei Netzausfall
Webseite der Firma	HTTPS-Antwort und Zertifikat	5 Minuten	Zertifikat unter 14 Tagen	Seite nicht erreichbar oder unter 3 Tagen

Die Grenze für den DHCP-Pool ergibt sich aus 0,8 × 51 = 40,8, also Warnung ab 41 belegten Adressen. Beim PoE-Budget aus 0,8 × 195 W = 156 W. Kritische Meldungen gehen per E-Mail und Chat an die Bereitschaft, Warnungen nur per E-Mail an das IT-Team. Auf einem Dashboard sieht der Administrator morgens alles auf einen Blick.

Der Monitoring-Server darf als einziger per SNMP (UDP 161) auf die Netzwerkgeräte zugreifen. Das setzt die Firewall am Router durch. Die Verwaltungsanschlüsse der Geräte liegen im VLAN 10, wie im Beitrag VLAN verstehen gezeigt. Und weil der Überwacher selbst ausfallen kann, prüft ein zweiter, einfacher Check außerhalb des Netzes, zum Beispiel ein externer Dienst, ob srv-monitor noch lebt. Wer überwacht den Überwacher? Eine zweite, unabhängige Stelle.

Ein Dashboard fasst Zustände und Trends zusammen. Die Alarme kommen unabhängig davon.

Einzelne Prüfungen von Hand

Auch ohne Monitoring-System kannst du die Prüfungen von Hand ausführen und so verstehen, was sie messen. Ob eine Webseite antwortet und mit welchem Statuscode, zeigt (mit example.com als Beispiel):

curl -I https://example.com

Die erste Zeile der Antwort enthält den Statuscode, 200 bedeutet „in Ordnung“. Wann ein Zertifikat abläuft, liest du so aus:

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Die Ausgabe nennt das Datum, bis zu dem das Zertifikat gilt. Unter Windows prüft die PowerShell einen Port so:

Test-NetConnection example.com -Port 443

Plattenplatz und Arbeitsspeicher unter Linux zeigen df -h und free -h, unter Windows Get-PSDrive C. Ein Monitoring-System macht im Grunde genau das, nur automatisch, regelmäßig und mit Verlauf.

Typische Fehler und Missverständnisse

Nur Ping überwachen. Ein Gerät kann auf Ping antworten, während der Dienst darauf längst tot ist.
Zu viele Alarme. Wer alles meldet, wird am Ende nichts mehr lesen.
Alarme ohne Empfänger. Eine Meldung, die in ein unbeachtetes Postfach läuft, hilft niemandem.
Schwellwerte nie überprüft. Netze ändern sich, die Grenzen müssen mitwachsen.
Nur den Zustand, keinen Verlauf speichern. Ohne Verläufe fehlen Trends und die Antwort auf die Frage, wann es angefangen hat.
SNMPv2c mit „public“. Jeder im Netz kann die Geräte abfragen. Nimm SNMPv3 und beschränke den Zugriff.
Das Monitoring selbst nicht absichern und überwachen. Es sieht das ganze Netz und ist selbst ein Ziel.
Backups nicht mitüberwachen. Das stille Scheitern einer Sicherung ist einer der teuersten Fehler.
Keine Wartungsfenster. Geplante Arbeiten lösen sonst Alarme aus und trainieren, Alarme zu ignorieren.
Uhren nicht abgeglichen. Logs verschiedener Geräte passen dann nicht zusammen.

Zum Üben

Nenne drei Ebenen, die man überwacht, und je eine Messgröße.
Ein SNMP-Zähler steigt in 60 Sekunden von 2.000.000.000 auf 2.900.000.000 Oktette. Wie hoch ist die Rate in Mbit/s, und wie hoch ist die Auslastung eines 1-Gbit/s-Ports?
Nach welcher Zeit läuft ein 32-Bit-Zähler bei 125 MB/s über?
Ein Dienst war in einem 30-Tage-Monat 20 Minuten gestört. Wie hoch war die Verfügbarkeit?
Auf einem Server sind noch 100 GB frei, und der Verbrauch wächst um 2,5 GB pro Tag. Wann ist der Platz voll?
Welche Zustände und Codes verwendet das Nagios-Prinzip?
Warum ist SNMPv3 besser als SNMPv2c?
Was versteht man unter Alert Fatigue, und was hilft dagegen?

Lösungen:

(1) Zum Beispiel: Server (Plattenplatz), Netzwerk (Antwortzeit per Ping),
    Backup (Alter des letzten erfolgreichen Laufs), Umgebung (USV-Zustand).

(2) Differenz 900.000.000 Byte × 8 = 7.200.000.000 Bit
    ÷ 60 s = 120.000.000 Bit/s = 120 Mbit/s
    Auslastung: 120 ÷ 1.000 = 12 %

(3) 4.294.967.296 Byte ÷ 125.000.000 Byte/s ≈ 34 Sekunden

(4) (43.200 − 20) ÷ 43.200 ≈ 0,99954 → 99,954 %

(5) 100 GB ÷ 2,5 GB/Tag = 40 Tage

(6) 0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN

(7) SNMPv3 bietet Benutzer, Authentifizierung und Verschlüsselung.
    SNMPv2c schützt nur mit einem Klartext-Kennwort (Community).

(8) Alarmmüdigkeit: Zu viele unwichtige Alarme führen dazu, dass auch
    wichtige ignoriert werden. Dagegen helfen: Nur Alarme mit Aktion,
    kurze Spitzen ignorieren, Wiederholungsprüfungen, Wartungsfenster,
    sinnvolle Eskalation.

Das solltest du dir merken

Monitoring misst Systeme laufend, bewertet die Werte gegen Schwellwerte und alarmiert bei Abweichungen. Es macht aus reaktiver proaktive Arbeit.
Überwacht werden Server, Netzwerk, Dienste, Zertifikate, Backup, Umgebung und Sicherheit.
Werte kommen per Ping, Dienstprüfung, SNMP, Agent oder Syslog. Nutze SNMPv3.
Datenraten berechnest du aus der Differenz zweier Zählerstände: Byte × 8 ÷ Sekunden. Achte auf Zählerüberläufe.
Zustände: OK, WARNING, CRITICAL, UNKNOWN. Jeder Alarm braucht eine Aktion, sonst droht Alarmmüdigkeit.
Verläufe zeigen Trends und erlauben Prognosen, etwa wann ein Datenträger voll ist.
Überwache auch das Monitoring selbst und die Sicherungen.

Zum Schluss dieses Blocks ein Thema, das fast alles bisher Gelernte nutzt, um mit weniger Hardware mehr zu leisten: mehrere Server auf einem Gerät. Wie das funktioniert, zeigt der nächste Beitrag: Virtualisierung verstehen.

Monitoring verstehen: Wie du Server und Netzwerke überwachst