Systemüberwachung: Monitoring-Kennwerte, SNMP, S.M.A.R.T. und Logs

Systemüberwachung: Monitoring-Kennwerte, SNMP, S.M.A.R.T. und Logs

https://bildung.social/@oerinformatik/

https://oer-informatik.de/systemueberwachung

Monitoring, Systemüberwachung, SNMP, MIB, Trap, Schwellenwert, Round Trip Time, Packet Loss, S.M.A.R.T., Syslog, Event, Predictive Maintenance

tl/dr; (ca. 27 min Lesezeit): Server, Netzwerkgeräte und Festplatten kündigen viele Ausfälle an – wenn jemand hinschaut. Der Artikel erklärt die wichtigsten Begriffe des Monitorings (Schwellenwert, Event, Round Trip Time, Packet Loss, Predictive Maintenance), die Event-Stufen Information, Warning und Exception, typische Kennwerte für Server und Netz und wie Du Engpässe erkennst. Danach geht es um SNMP mit Manager, Agent, MIB, GET, SET und TRAP und die Sicherheit der SNMP-Versionen, um die Festplattenüberwachung mit S.M.A.R.T., um LEDs und Umgebungsbedingungen und um das Auswerten von Logs. Du erfährst, wie ein Event mithilfe einer Known-Error-Datenbank zum Incident wird. Zum Schluss: Wann reagiert ein System automatisch, wann ein Mensch? [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Als Grundlagen der Systemüberwachung kann ich nach Durchlesen des Artikels…

• … Ziele des Monitorings nennen und Begriffe wie Schwellenwert (Threshold), Event, Round Trip Time, Packet Loss und Predictive Maintenance an Beispielen beschreiben.

• … wichtige Kennwerte für Server und Netzwerk nennen, erläutern, was sie über den Zustand der IT aussagen, und in Messwerten einen Engpass (Bottleneck) erkennen und Maßnahmen dagegen erläutern.

• … Aufgaben von SNMP nennen, die Arbeitsweise von Manager und Agent, die Rolle der MIB und die Nachrichten GET-REQUEST, SET-REQUEST und TRAP beschreiben und Transportprotokoll und Ports benennen.

• … die SNMP-Versionen hinsichtlich Authentifizierung und Verschlüsselung vergleichen und SNMP von einer Abfrage über eine API abgrenzen.

• … den Zweck von S.M.A.R.T. beschreiben, eine S.M.A.R.T.-Warnung mithilfe eines (englischen) Datenblatts erläutern, Folgen für Festplatte, RAID und Leistung beschreiben und Maßnahmen nennen.

• … Umwelteinflüsse auf die Lebensdauer von Hardware und die Bedeutung typischer Status-LEDs benennen.

Darüber hinaus kann ich als Expertenwissen der Systemüberwachung…

• … die Event-Stufen Information, Warning und Exception mit Bedeutung und Folge erklären, Known-Error-Datenbank mit Workarounds und gezählten Vorfällen nutzen und proaktives Problemmanagement erläutern.

• … Logs mit Schweregraden auswerten, Muster erkennen und Alarmregeln ableiten.

• … Vor- und Nachteile automatisierter und manueller Reaktionen beschreiben und Messreihen sowie Benchmarks so gestalten, dass sie aussagekräftig sind.

Ein Server, der um 3 Uhr nachts stehen bleibt, ist ärgerlich. Ärgerlicher ist, wenn er es seit Wochen angekündigt hat: Der Arbeitsspeicher lief voll, eine Festplatte meldete steigende Fehlerzahlen, im Serverraum wurde es warm – nur hat niemand hingesehen. Systemüberwachung (Monitoring) erfasst laufend Messwerte und Zustände von Hardware, Netz und Diensten, wertet sie aus und meldet Abweichungen. Ziele sind:

• Störungen früh erkennen, bevor Nutzende sie bemerken, und die Ursache schneller finden,

• die Verfügbarkeit nachweisen (z. B. gegenüber einem Service Level Agreement),

• Kapazitäten planen (Wann ist der Speicher voll? Reicht die Bandbreite noch?),

• vorausschauend warten, statt auf den Ausfall zu warten,

• Sicherheitsvorfälle anhand ungewöhnlicher Muster entdecken.

Die Mindmap zeigt die Themen dieses Artikels im Überblick:

Begriffe des Monitorings

Wichtige Begriffe des Monitorings

Begriff	Bedeutung	Beispiel
Messwert, Metrik	regelmäßig erfasster Zahlenwert	CPU-Auslastung in %, freier Speicherplatz in GB
Baseline	„Normalzustand“, gegen den Abweichungen beurteilt werden	Auslastung an einem gewöhnlichen Dienstag
Schwellenwert (Threshold)	festgelegte Grenze, ab der ein Ereignis ausgelöst wird; oft zweistufig (Warnung, kritisch)	Warnung ab 80 % Datenträgerbelegung, kritisch ab 95 %
Ereignis (Event)	eintretender Zustandswechsel oder Vorfall, den das System registriert	Link eines Switch-Ports geht auf „down“, Stromversorgung unterbrochen
Alarm	Event, das eine Benachrichtigung auslöst (E-Mail, SMS, Ticket)	Bereitschaft wird nachts angerufen
Antwortzeit (Response Time)	Zeit, bis ein Dienst auf eine Anfrage antwortet	Webshop liefert die Startseite in 0,4 s
Round Trip Time (RTT)	Zeit für den Hin- und Rückweg eines Pakets zwischen zwei Geräten; wichtig für Echtzeitanwendungen	ping meldet 12 ms
Latenz	Verzögerung bis zur Ankunft bzw. Verarbeitung; im Netz oft die halbe RTT, bei Diensten die Bearbeitungszeit	Datenbankabfrage braucht 250 ms statt 20 ms
Paketverlust (Packet Loss)	Anteil der Pakete, die unterwegs verloren gehen; beeinträchtigt Qualität und Durchsatz	3 % Verlust führt zu ruckelndem Videostream
Jitter	Schwankung der Laufzeit	Sprachqualität bei VoIP sinkt
Durchsatz, Auslastung	übertragene Datenmenge je Zeit bzw. Anteil an der Kapazität	Uplink mit 870 Mbit/s zu 87 % ausgelastet
Fehlerzähler	Zähler für fehlerhafte oder verworfene Pakete, Wiederholungen	steigende CRC-Fehler an einem Switch-Port deuten auf ein defektes Kabel
Predictive Maintenance	vorausschauende Wartung: aus Verlauf und Zustand wird ein drohender Ausfall vorhergesagt und rechtzeitig getauscht	Festplatte mit steigender Zahl defekter Sektoren wird vor dem Ausfall ersetzt

Gute Schwellenwerte orientieren sich an der Baseline und an Herstellerangaben. Zu niedrige Schwellen erzeugen eine Flut von Meldungen, die irgendwann niemand mehr liest; zu hohe melden erst, wenn es zu spät ist. Häufig wird deshalb eine Meldung erst ausgelöst, wenn ein Wert eine gewisse Zeit über der Schwelle liegt (z. B. CPU über 90 % für mehr als fünf Minuten).

Das Diagramm zeigt einen zweistufigen Schwellenwert an einem Beispiel: Die Belegung eines Datenträgers wächst stetig, überschreitet zuerst die Warnschwelle und später die kritische Schwelle. Aus dem Trend lässt sich ablesen, wann der Speicher voll ist.

Event-Stufen: Information, Warning, Exception

Monitoring-Systeme ordnen Events nach ihrer Bedeutung. Verbreitet ist die Einteilung aus dem IT-Service-Management (ITIL):

Event-Stufen mit Bedeutung und Folge

Event	Bedeutung	Folge	Beispiel (TLS-Zertifikat eines Webshops)
Information	Ein Messwert liegt stabil im Sollbereich, oder eine Aktion war erfolgreich.	Kein Eingreifen nötig; das Event dient der Dokumentation.	„Zertifikat gültig, noch 61 Tage“, „Zertifikat automatisch erneuert“
Warning	Ein Messwert nähert sich der Grenze seines Sollbereichs oder ändert sich ungewöhnlich.	Noch kein sofortiges Eingreifen, aber beobachten und Ursache klären.	„Zertifikat läuft in 9 Tagen ab, automatische Erneuerung zweimal fehlgeschlagen“
Exception	Ein Messwert liegt außerhalb des Sollbereichs, oder ein Dienst ist ausgefallen.	Sofort eingreifen, damit kein Schaden oder Folgeproblem entsteht; oft wird automatisch ein Incident (Störungsticket) erzeugt.	„Zertifikat abgelaufen, Browser warnen die Kundschaft, Bestellungen brechen ein“

Vom Event zum Incident: Known Errors nutzen

Nicht jedes Event braucht einen Menschen. Ein Monitoring-System fasst zunächst gleichartige Meldungen zusammen (zwanzig „Port down“-Meldungen hinter einem ausgefallenen Switch sind ein Ereignis) und protokolliert reine Informationen nur. Für Warnungen und Ausnahmen gleicht es die Fehlersignatur – also Meldungstext, Quelle und Muster – mit der Known-Error-Datenbank (KEDB) ab. Ein Known Error ist ein Fehler, dessen Erscheinungsbild bekannt ist und für den es mindestens einen Workaround gibt: eine vorläufige Lösung, die den Dienst wiederherstellt, ohne die Ursache zu beseitigen.

Aufbau eines Eintrags in einer Known-Error-Datenbank (Beispiel)

Feld eines Known Errors	Zweck	Beispiel
Fehlersignatur	woran das System den Fehler wiedererkennt	Dienst bildkonverter beendet sich mit „out of memory“
Ursache (Stand der Analyse)	was über den Grund bekannt ist	Speicherleck bei sehr großen Fotos, Herstellerfall offen
Workaround	was den Dienst wiederherstellt	Dienst neu starten, Warteschlange erneut abarbeiten
automatisierbar	darf das System den Workaround selbst ausführen?	ja
Vorfälle je Zeitraum	wie oft der Fehler zuletzt auftrat	14 in den letzten 30 Tagen
Problem-Datensatz	Verweis auf die Ursachenanalyse	PRB-112 (offen)

Ist ein automatisierbarer Workaround hinterlegt, führt das System ihn aus und prüft danach, ob der Sollzustand wieder erreicht ist. Erst wenn kein automatisierbarer Workaround hinterlegt ist oder er den Sollzustand nicht herstellt, entsteht ein Incident-Ticket für die Bereitschaft. Sie stellt den Dienst wieder her – mit einem Workaround aus der KEDB oder einer eigenen Lösung. Was sie dabei Neues erfährt, hält sie fest: einen neuen Fehler als Known Error mit Signatur und Workaround, einen versagenden Workaround als Ergänzung des vorhandenen Eintrags – beim nächsten Mal geht es schneller oder ganz ohne Menschen. Das Diagramm zeigt einen solchen Ablauf:

Die gezählten Vorfälle ermöglichen proaktives Problemmanagement: Das Incident-Management stellt den Dienst möglichst schnell wieder her, das Problem-Management sucht die Ursache und beseitigt sie, bevor weitere Störungen entstehen. Zwei Beispiele:

• Nach einem Treiberupdate steigt die Zahl der Vorfälle „Netzwerkkarte verliert die Verbindung“ von zwei auf neunzehn je Woche. Statt die Rechner weiter einzeln neu zu starten, wird das Update für die übrigen Geräte gestoppt und der alte Treiber wieder eingespielt, bis der Hersteller nachbessert.

• Der monatliche Selbsttest einer USV zeigt eine Überbrückungszeit, die innerhalb eines Jahres von 18 auf 11 Minuten gesunken ist. Weil die Server zum Herunterfahren mindestens 8 Minuten brauchen, werden die Akkus jetzt getauscht – und nicht erst nach dem Stromausfall, bei dem die Zeit nicht mehr reicht.

Auch Ausfallstatistiken der Hersteller (z. B. die mittlere Betriebszeit bis zum Ausfall, Mean Time To Failure, MTTF) helfen, Tauschzeitpunkte zu planen. Mehr zu MTTF und Verfügbarkeit steht im Artikel Hochverfügbarkeit.

Kennwerte für Server und Netzwerk

Typische Kennwerte und ihre Aussage

Bereich	Kennwerte	Was sie aussagen
CPU	Auslastung in %, Warteschlange (Load), Temperatur	Reicht die Rechenleistung (CPU-Sizing)? Dauerhaft hohe Last bremst alle Dienste.
Arbeitsspeicher	belegter Speicher in %, Nutzung der Auslagerungsdatei (Swap, Pagefile)	Wird ausgelagert, sinkt die Leistung stark, weil Datenträger viel langsamer sind als RAM.
Datenträger	Belegung, Lese-/Schreibrate, Warteschlange, Antwortzeit, S.M.A.R.T.-Werte	Läuft der Speicher voll? Ist der Datenträger der Engpass? Droht ein Ausfall?
Netzwerk	Auslastung je Port, Durchsatz, Fehlerzähler, verworfene Pakete, RTT, Paketverlust	Reicht die Bandbreite? Gibt es defekte Kabel, Überlast oder unerwünschte Übertragungen?
Firewall	Anzahl verworfener Pakete, Verbindungen	Fehlkonfiguration der Regeln oder Angriffsversuche
Dienste	erreichbar ja/nein, Antwortzeit, Anzahl gleichzeitiger Zugriffe, Fehlerquote	Ist der Dienst aus Sicht der Nutzenden verfügbar und schnell genug?
Umgebung und Strom	Raumtemperatur, Luftfeuchte, Leistungsaufnahme, Netzfrequenz, Zustand der USV	Gefährden Hitze oder Stromprobleme die Hardware?

Kennwerte werden selten einzeln betrachtet. Meldet ein Webshop langsame Antworten, obwohl die CPU des Webservers kaum zu tun hat, zeigt erst der Vergleich mit dem Datenbankserver das Bild: Dort ist die Warteschlange des Datenträgers lang und jede Abfrage wartet. Der Engpass liegt also eine Schicht tiefer als die Stelle, an der die Nutzenden ihn bemerken.

Engpässe erkennen

Ein Engpass (Bottleneck) ist die Komponente, die die Leistung des ganzen Systems begrenzt. Werkzeuge wie der Ressourcenmonitor unter Windows oder top, free, vmstat und iostat unter Linux zeigen die Auslastung je Bereich. Typische Anzeichen und Gegenmaßnahmen:

Engpässe erkennen und beheben

Engpass	Anzeichen	mögliche Maßnahmen
CPU	Auslastung dauerhaft nahe 100 %, lange Warteschlange (Load deutlich über der Zahl der Kerne)	Kerne ergänzen bzw. einer VM mehr vCPUs zuweisen, rechenintensive Aufgaben zeitlich verschieben oder verteilen
Arbeitsspeicher	Belegung nahe 100 %, viele Zugriffe auf ausgelagerte Seiten („harte Fehler“, page faults), stark genutzter Swap	RAM erweitern (bei einer VM: mehr RAM zuweisen), speicherhungrige Dienste verlagern oder beenden, auf Speicherlecks (Memory Leaks) prüfen – erkennbar an stetig steigender Belegung
Datenträger	aktive Zeit nahe 100 %, lange Warteschlange, hohe Antwortzeiten je Zugriff	schnellere Datenträger (SSD), Last verteilen (RAID, mehrere Volumes), Sicherungen und Scans in lastarme Zeiten legen
Netzwerk	Auslastung des Ports nahe der Bandbreite, verworfene Pakete, steigende RTT	schnellere oder gebündelte Verbindungen, Verkehr priorisieren (QoS), große Übertragungen zeitlich verschieben

Vorsicht bei Folgeerscheinungen: Fehlt Arbeitsspeicher, lagert das Betriebssystem Seiten aus, und dann wirkt auch der Datenträger überlastet. Wer nur auf die Datenträgeranzeige schaut, kauft eine schnellere SSD – das lindert die Symptome, beseitigt aber nicht die Ursache. Auch Zeitverläufe helfen: Steigen Antwortzeiten immer zur selben Uhrzeit, lohnt ein Blick auf geplante Aufgaben wie Datensicherungen, Virenscans oder Indexierungen.

Messreihen darstellen

Zwei Messreihen mit sehr unterschiedlichen Wertebereichen in einem Diagramm mit einer y-Achse sind kaum lesbar: Trägt man den Durchsatz eines Uplinks (zwischen 80 und 940 Mbit/s) und seinen Paketverlust (zwischen 0 und 2 %) gemeinsam auf, liegt die Verlustkurve flach am unteren Rand. Abhilfe schafft eine zweite y-Achse mit eigenem Maßstab und eigener Einheit oder zwei übereinander angeordnete Diagramme mit gemeinsamer Zeitachse. Erst dann wird sichtbar, ob der Paketverlust immer dann steigt, wenn der Uplink fast voll ist.

Benchmarks und Lasttests

Ein Benchmark misst die Leistung eines Systems unter festgelegter Last, z. B. vor und nach einer Aufrüstung. Vergleichbar sind die Ergebnisse nur, wenn sich zwischen den Messungen allein das untersuchte Merkmal ändert:

Störgrößen bei Benchmarks

Störgröße	Wirkung	Gegenmaßnahme
Hintergrundlast (Updates, Virenscan, Sicherung, andere VMs)	misst fremde Last mit	Messzeitpunkt und Begleitlast festhalten, Hintergrundaufgaben pausieren
Caches	erster Lauf langsam, Folgeläufe „warm“	immer gleich behandeln: z. B. einen Aufwärmlauf verwerfen, dann mehrere Läufe mitteln
Testfall und Datenmenge	anderer Test = andere Aussage	dieselben, praxisnahen Testfälle mit derselben Datenmenge
fremder Netzverkehr	schwankende Laufzeiten	abgeschottetes Testnetz oder lastarme Zeit
Einzelmessung	Zufall wird zum Ergebnis	mehrere Läufe, Mittelwert und Streuung angeben

SNMP: Netzwerkgeräte zentral überwachen

Das Simple Network Management Protocol (SNMP) ist das klassische Protokoll, um Geräte verschiedener Hersteller zentral zu überwachen und zu verwalten. Seine Aufgaben:

• Zustands- und Leistungsdaten abfragen (Überwachung),

• Einstellungen aus der Ferne ändern (Fernkonfiguration und -steuerung),

• Fehler und Ereignisse an eine zentrale Stelle melden (Fehlererkennung und -benachrichtigung).

Überwachen lassen sich fast alle Netzwerkgeräte: Switches, Router, Firewalls, Access Points, Server, Drucker (z. B. Tonerstand), USV-Anlagen, NAS-Systeme, Klimageräte und Sensoren mit Netzwerkkarte.

Manager und Agent

• Der Agent ist eine Software auf dem überwachten Gerät (oder ein Hardwaremodul, etwa eine Netzwerkkarte in einer USV). Er erfasst den Zustand des Geräts, beantwortet Anfragen, kann Einstellungen vornehmen oder Aktionen auslösen und meldet besondere Ereignisse selbstständig.

• Der Manager (die Managementstation, z. B. eine Monitoring-Software) fragt die Agenten regelmäßig ab, speichert die Werte, stellt sie dar und alarmiert bei Grenzwertverletzungen.

MIB und OID

Welche Werte ein Agent kennt, beschreibt die Management Information Base (MIB): ein baumartig gegliedertes Verzeichnis der Objekte, die ein Agent bereitstellt – lesbare Zustandswerte ebenso wie schreibbare Einstellungen –, jeweils mit Name, Datentyp und Zugriffsrecht. Jeder Wert hat einen eindeutigen Object Identifier (OID) in Punktschreibweise:

Beispiele aus der Standard-MIB-II

OID	Name	Bedeutung
1.3.6.1.2.1.1.3.0	sysUpTime	Zeit seit dem letzten Neustart
1.3.6.1.2.1.1.5.0	sysName	Gerätename
1.3.6.1.2.1.2.2.1.8.<n>	ifOperStatus	Betriebszustand der Schnittstelle n (up/down)
1.3.6.1.2.1.2.2.1.10.<n>	ifInOctets	empfangene Bytes an Schnittstelle n (Zähler)

Neben den Standard-MIBs liefern Hersteller eigene MIB-Dateien für ihre Geräte. Damit der Manager Werte richtig anzeigt, lädt man diese MIB-Dateien in die Monitoring-Software.

Nachrichtentypen

SNMP-Nachrichtentypen

Nachricht	Richtung	Funktion
GET-REQUEST	Manager → Agent	einen (oder mehrere) Werte anfordern, z. B. ifOperStatus von Port 12
GET-NEXT-REQUEST, GET-BULK-REQUEST	Manager → Agent	den nächsten Wert bzw. viele Werte auf einmal anfordern (Tabellen durchlaufen)
SET-REQUEST	Manager → Agent	einen oder mehrere Werte im Gerät verändern, z. B. einen Port deaktivieren
RESPONSE	Agent → Manager	Antwort mit den angeforderten Werten bzw. Bestätigung
TRAP	Agent → Manager	unaufgeforderte Meldung, dass ein Ereignis eingetreten ist (z. B. Link down, Netzteil ausgefallen) – ohne Bestätigung
INFORM	Agent → Manager	wie TRAP, aber vom Empfänger bestätigt (ab SNMPv2c)

Regelmäßige Abfragen per GET heißen Polling. TRAPs ergänzen das Polling: Ein Ausfall wird sofort gemeldet und nicht erst beim nächsten Abfrageintervall bemerkt.

SNMP arbeitet standardmäßig mit dem verbindungslosen UDP: Agenten nehmen Anfragen auf Port 161 entgegen, der Manager empfängt TRAPs auf Port 162. UDP hält den Aufwand klein; geht eine Abfrage verloren, wird sie beim nächsten Intervall wiederholt.

SNMP-Versionen und Sicherheit

SNMP-Versionen im Vergleich

Version	Authentifizierung	Verschlüsselung	Bewertung
SNMPv1	nur „Community-String“ (eine Art Gruppenpasswort), im Klartext übertragen	keine	veraltet, nicht mehr einsetzen
SNMPv2c	wie v1 (Community-String im Klartext), dazu GET-BULK und INFORM	keine	weit verbreitet, aber unsicher
SNMPv3	Benutzerkonto mit Passwort, Nachrichten werden mit HMAC (z. B. SHA-2) signiert	optional, z. B. AES	Stand der Technik, Sicherheitsstufe authPriv verwenden

Warum das wichtig ist:

• Authentifizierung stellt sicher, dass nur berechtigte Manager Werte abfragen oder – schlimmer – per SET verändern können und dass Nachrichten nicht unterwegs verfälscht wurden. Mit dem mitgelesenen Community-String private könnte ein Angreifer bei v1/v2c z. B. Ports abschalten oder Konfigurationen ändern.

• Verschlüsselung verhindert, dass Unbefugte die übertragenen Daten mitlesen. Gerätenamen, Adressen, Softwarestände und Konfigurationen sind wertvolle Informationen für Angriffe.

Weitere Regeln: Standard-Communities (public, private) ändern bzw. deaktivieren, SNMP-Zugriff nur aus dem Managementnetz erlauben (Firewall, ACL), wo möglich nur lesenden Zugriff einrichten.

SNMP oder API?

Neuere Geräte, Cloud-Dienste und Anwendungen bieten ihre Zustandsdaten oft über eine API (Application Programming Interface) an, meist als REST-Schnittstelle über HTTPS mit JSON-Antworten. Eine API ist eine definierte Schnittstelle mit festgelegten Anfragen und Antworten, über die Programme Daten austauschen, ohne den Quellcode des anderen Systems zu kennen.

Monitoring-Systeme unterstützen in der Regel beides, dazu eigene Agenten für Server und Prüfungen von Diensten (z. B. „Liefert die Webseite in weniger als 2 s den Statuscode 200?“).

Festplatten überwachen mit S.M.A.R.T.

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) ist eine Selbstüberwachung in Festplatten und SSDs. Das Laufwerk erfasst laufend Zustandswerte und meldet, wenn einer seinen Grenzwert erreicht. Der Zweck: Ein drohender Ausfall wird frühzeitig erkannt, sodass Daten gesichert und das Laufwerk geplant getauscht werden kann, bevor Daten verloren gehen.

Häufige S.M.A.R.T.-Attribute (Nummern und Namen können je Hersteller abweichen)

ID	Attribut	Bedeutung
5	Reallocated Sectors Count	Anzahl defekter Sektoren, die durch Reservesektoren ersetzt wurden – steigt der Wert, verschleißt die Oberfläche
9	Power-On Hours	Betriebsstunden
12	Power Cycle Count	Anzahl der Ein- und Ausschaltvorgänge
194	Temperature	aktuelle Temperatur in °C
197	Current Pending Sector Count	Sektoren, die nicht gelesen werden konnten und auf Neuzuweisung warten
199	UDMA CRC Error Count	Übertragungsfehler zwischen Laufwerk und Controller (häufig Kabel oder Steckverbindung)
–	Percentage Used / Wear Leveling	bei SSDs: verbrauchter Anteil der Schreibzyklen

Neben dem Rohwert (raw value) zeigen Werkzeuge einen normierten Wert (value), den schlechtesten bisherigen Wert (worst) und den Grenzwert des Herstellers (threshold). Abgelesen werden die Werte z. B. mit smartctl -a /dev/sda (Paket smartmontools), im BIOS, in der Verwaltungssoftware eines RAID-Controllers oder eines NAS. Manche Server melden einen kritischen S.M.A.R.T.-Status schon beim Start und warten auf eine Bestätigung (z. B. mit F1). Dann gilt: Daten sofort sichern und das Laufwerk austauschen.

Eine S.M.A.R.T.-Warnung anhand des Datenblatts erläutern

Eine Warnung beurteilst Du, indem Du den gemeldeten Wert mit dem Datenblatt des Laufwerks vergleichst. Datenblätter sind meist englisch. Bei der Temperatur unterscheiden sie zwei Bereiche:

• Environmental (operating): zulässige Werte im Betrieb, z. B. Temperature 0 °C to 65 °C,

• Environmental (non-operating): zulässige Werte bei Lagerung und Transport, z. B. −40 °C to 75 °C.

Meldet S.M.A.R.T. 194 Temperature 69 °C, liegt das Laufwerk also 4 °C über der zulässigen Betriebstemperatur. Der Wert im Lager-Bereich spielt für den Betrieb keine Rolle.

Mögliche Folgen, wenn die Festplatte so weiterbetrieben wird:

• höhere Fehlerrate, schnellerer Verschleiß und kürzere Lebensdauer bis hin zum Totalausfall,

• in einem RAID: Fällt die Platte aus, arbeitet der Verbund im Degraded Mode ohne Redundanz weiter; ein weiterer Ausfall bedeutet je nach RAID-Level Datenverlust, und der Rebuild belastet die übrigen Platten zusätzlich,

• Leistungsverlust: Viele Controller schalten im Degraded Mode den Schreibcache ab, Rebuild und Lesefehler verlangsamen den Server,

• Überhitzung benachbarter Laufwerke, wenn die Ursache (z. B. ausgefallener Lüfter) bestehen bleibt.

Maßnahmen bei einer S.M.A.R.T.-Warnung: Datensicherung prüfen bzw. sofort durchführen, Ursache untersuchen (Lüfter, Luftstrom, Raumtemperatur), Vorfall dokumentieren und ein Ticket eröffnen, das Laufwerk planmäßig tauschen (bei Hot-Swap im laufenden Betrieb) und den Rebuild überwachen.

S.M.A.R.T. kündigt nicht jeden Ausfall an – mechanische Defekte oder Elektronikschäden treten oft plötzlich auf. Es ersetzt deshalb weder RAID noch Datensicherung.

Am Gerät: Status-LEDs und Umgebung

Viele Zustände zeigt die Hardware direkt an. Server-Netzteile haben typischerweise drei LEDs, deren genaue Bedeutung im Handbuch steht:

Typische LEDs eines Server-Netzteils

LED	leuchtet, wenn …
Power input (AC OK)	das Netzteil netzseitig mit Wechselspannung versorgt wird
Power output (DC OK)	das Netzteil den Server mit Gleichspannung versorgt
Fault (Fehler)	das Netzteil eine Störung hat (blinkt oft bei Warnungen wie Übertemperatur)

Bei redundanten Netzteilen meldet der Server den Ausfall eines Netzteils zusätzlich per Management-Controller (z. B. per TRAP), denn der Server läuft ja weiter – ohne Überwachung bliebe der Verlust der Redundanz unbemerkt.

Auf die Lebensdauer der Hardware wirken auch Umwelteinflüsse: Temperatur (Hitze beschleunigt die Alterung, starke Temperaturwechsel belasten Lötstellen), Luftfeuchte (Kondensation, Korrosion; zu trockene Luft begünstigt elektrostatische Entladung), Staub und Partikel (verstopfte Lüfter, Überhitzung), Vibrationen (Festplatten), elektromagnetische Störungen (EMV) sowie Spannungsschwankungen und Überspannung. Im Serverraum werden Temperatur und Luftfeuchte deshalb selbst überwacht.

Logs auswerten

Neben Messwerten liefern Logs die Erklärung: Betriebssysteme, Dienste und Netzwerkgeräte schreiben Meldungen mit Zeitstempel, Quelle, Schweregrad und Text. Unter Linux und auf Netzwerkgeräten ist Syslog verbreitet (RFC 5424), unter Windows die Ereignisanzeige mit den Stufen Information, Warnung, Fehler und Kritisch.

Schweregrade nach Syslog

Wert	Schweregrad (Syslog)	Beispiel
0	Emergency	System unbenutzbar
1	Alert	sofortiges Handeln nötig (z. B. Datenbank beschädigt)
2	Critical	kritischer Zustand (Festplattenausfall)
3	Error	Fehler (Dienst konnte nicht starten)
4	Warning	Warnung (Datenträger zu 85 % belegt)
5	Notice	normales, aber bemerkenswertes Ereignis (Konfiguration geändert)
6	Informational	Information (Anmeldung erfolgreich)
7	Debug	Meldungen zur Fehlersuche

Damit Logs nützen, werden sie zentral gesammelt (Log-Server, bei großen Umgebungen ein SIEM-System), alle Geräte haben eine synchronisierte Uhrzeit (NTP) – sonst lassen sich Meldungen verschiedener Geräte nicht in die richtige Reihenfolge bringen –, und es gibt Regeln, welche Meldungen einen Alarm auslösen. Beim Auswerten suchst Du nach Mustern: Häufen sich gleiche Meldungen? Treten sie zu bestimmten Zeiten auf (nachts, bei Regen, bei der Datensicherung)? Folgt auf eine Warnung regelmäßig ein Fehler? Daraus leitest Du Alarmregeln ab, z. B. „mehr als fünf fehlgeschlagene Anmeldungen in zehn Minuten“. Weil Logs oft personenbezogene Daten enthalten (Benutzernamen, IP-Adressen), gehören Zweck, Zugriffsrechte und Löschfristen in ein Konzept. Ein Beispiel für das Auswerten von Sensorlogs zeigt der Artikel Netzwerkfehler analysieren.

Automatisch oder manuell reagieren?

Auf ein Event kann ein System selbst reagieren (Dienst neu starten, Port sperren, verdächtige IP-Adresse blockieren, Last auf einen anderen Server verschieben), oder es informiert einen Menschen.

Wann automatisch, wann manuell reagieren?

Kriterium	spricht für eine automatische Reaktion	spricht für einen Menschen
Bekanntheit	Fehler und passende Maßnahme sind bekannt und eindeutig erkennbar	Lage ist neu, mehrdeutig oder widersprüchlich
Zeitdruck	Schaden wächst in Sekunden oder Minuten (Angriff breitet sich aus, Akku überhitzt)	wenige Minuten Verzögerung richten keinen Schaden an
Umkehrbarkeit	Maßnahme lässt sich gefahrlos rückgängig machen (Dienst neu starten, Port sperren)	Maßnahme ist folgenreich (Daten löschen, ganzen Standort abschalten)
Kontext	Messwerte genügen für die Entscheidung	Wissen von außerhalb des Systems nötig (Bauarbeiten, Veranstaltung, Wetter)

Eine automatische Reaktion arbeitet rund um die Uhr gleichbleibend, kann aber nur, was vorher festgelegt wurde – und ein Fehlalarm löst dann womöglich eine unnötige Abschaltung aus. Ein Mensch braucht länger und muss erreichbar sein, kann dafür abwägen und neue Lösungswege finden.

In der Praxis kombiniert man beides: Bekannte Störungen behebt das System selbst und dokumentiert sie, alles andere landet als Ticket bei einem Menschen.

Typische Fehler

• Zu viele Alarme: Wer jede Kleinigkeit meldet, erzieht alle dazu, Meldungen zu ignorieren.

• Nur „läuft/läuft nicht“ überwachen: Ohne Verlaufsdaten lassen sich weder Engpässe noch schleichende Verschlechterungen erkennen.

• SNMPv2c mit public im ganzen Netz: Jeder kann Geräte abfragen, mit Schreibrechten sogar umkonfigurieren.

• S.M.A.R.T.-Werte „operating“ und „non-operating“ verwechseln.

• Das Monitoring selbst nicht überwachen: Fällt der Monitoring-Server aus, meldet niemand mehr etwas.

Leitfragen

1. Was bedeuten Threshold, Event, Round Trip Time, Packet Loss und Predictive Maintenance? Antwort

Ein Threshold ist ein festgelegter Grenzwert, ab dem ein Event ausgelöst wird (z. B. Warnung ab 80 % Belegung). Ein Event ist ein registrierter Zustandswechsel oder Vorfall (z. B. Link down). Die Round Trip Time ist die Zeit für Hin- und Rückweg eines Pakets, Packet Loss der Anteil verlorener Pakete. Predictive Maintenance sagt aus Zustandsdaten einen drohenden Ausfall voraus, damit rechtzeitig gewartet wird (siehe Abschnitt „Begriffe des Monitorings“).

2. Worin unterscheiden sich die Events Information, Warning und Exception, und was versteht man unter proaktivem Problemmanagement? Antwort

Information: Wert im Sollbereich, kein Eingreifen. Warning: Wert an der Grenze des Sollbereichs, beobachten. Exception: Wert außerhalb des Sollbereichs oder Ausfall, sofort eingreifen. Beim proaktiven Problemmanagement wertet man gezählte Vorfälle aus der Known-Error-Datenbank und Verläufe aus und beseitigt die Ursache, bevor die nächste Störung auftritt – etwa ein fehlerhaftes Treiberupdate zurücknehmen, statt Rechner immer wieder neu zu starten (siehe Abschnitt „Event-Stufen“).

3. Woran erkennst Du einen Engpass in einem Server, und was kannst Du dagegen tun? Antwort

Du vergleichst die Auslastung von CPU, Arbeitsspeicher, Datenträgern und Netz und suchst den Bereich, der an seiner Grenze arbeitet, während die anderen Luft haben. Dabei unterscheidest Du Ursache und Folge: Ein voller Arbeitsspeicher mit vielen Auslagerungen lässt auch den Datenträger überlastet erscheinen. Die Maßnahme setzt an der Ursache an, z. B. RAM erweitern, Last verteilen oder Aufgaben zeitlich verschieben (siehe Abschnitt „Engpässe erkennen“).

4. Wie arbeiten SNMP-Manager und -Agent zusammen, und wozu dienen MIB, GET-REQUEST, SET-REQUEST und TRAP? Antwort

Der Agent läuft auf dem überwachten Gerät, erfasst dessen Zustand, beantwortet Anfragen und meldet Ereignisse; der Manager fragt zentral ab, speichert, stellt dar und alarmiert. Die MIB beschreibt als hierarchischer Katalog, welche Werte (OIDs) abgefragt oder verändert werden können. GET-REQUEST fordert Werte an, SET-REQUEST verändert Werte, ein TRAP ist eine unaufgeforderte Meldung des Agenten über ein Ereignis. SNMP nutzt UDP, Port 161 für Anfragen und 162 für TRAPs (siehe Abschnitt „SNMP“).

5. Warum sollte SNMPv3 statt v1 oder v2c eingesetzt werden? Antwort

v1 und v2c übertragen nur einen Community-String im Klartext und verschlüsseln nichts. SNMPv3 bietet Authentifizierung (nur berechtigte Manager dürfen abfragen oder per SET ändern, Nachrichten sind gegen Verfälschung geschützt) und Verschlüsselung (niemand kann Gerätedaten mitlesen) (siehe Abschnitt „SNMP-Versionen und Sicherheit“).

6. Wozu dient S.M.A.R.T., und wie beurteilst Du eine S.M.A.R.T.-Warnung? Antwort

S.M.A.R.T. überwacht Zustandswerte eines Laufwerks (z. B. neu zugewiesene Sektoren, Betriebsstunden, Temperatur), um einen Ausfall früh zu erkennen. Eine Warnung vergleichst Du mit dem Datenblatt – bei der Temperatur mit dem Bereich operating. Folgen des Weiterbetriebs sind Verschleiß bis zum Totalausfall, ein RAID im Degraded Mode und Leistungsverlust; Maßnahmen sind Sicherung, Ursachensuche, Dokumentation und geplanter Tausch (siehe Abschnitt „Festplatten überwachen mit S.M.A.R.T.“).

7. Wie wertest Du Logs aus, und wann reagiert ein System besser automatisch, wann ein Mensch? Antwort

Logs werden zentral gesammelt, mit synchroner Uhrzeit versehen und nach Schweregrad (Syslog 0 Emergency bis 7 Debug) und Mustern ausgewertet; daraus entstehen Alarmregeln. Automatisch reagiert ein System am besten, wenn der Fehler bekannt und eindeutig erkennbar ist, die Zeit drängt und die Maßnahme gefahrlos umkehrbar ist; ein Mensch ist gefragt, wenn die Lage neu oder mehrdeutig ist, die Maßnahme schwere Folgen hat oder Wissen von außerhalb des Systems nötig ist (siehe Abschnitt „Logs auswerten“ und Abschnitt „Automatisch oder manuell reagieren?“).

Links und weitere Informationen

• Übungsaufgaben zur Systemüberwachung

• Hochverfügbarkeit: Ausfallzeiten berechnen, Redundanz planen

• Netzwerkfehler analysieren: ping, tracert, nslookup und Paketmitschnitt

• RAID

• RFC 3411: An Architecture for Describing SNMP Management Frameworks

• RFC 5424: The Syslog Protocol

• smartmontools: Werkzeuge zum Auslesen von S.M.A.R.T.

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Systemüberwachung: Monitoring-Kennwerte, SNMP, S.M.A.R.T. und Logs” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/systemueberwachung veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/it-systeme/administration. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]