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. 24 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. 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, Vorfallszähler und Known-Error-Datenbank 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 (Kühlraum eines Rechenzentrums)
Information	Ein Messwert liegt stabil im Sollbereich, oder eine Aktion war erfolgreich.	Kein Eingreifen nötig; das Event dient der Dokumentation.	„Raumtemperatur 23 °C“, „Datensicherung abgeschlossen“
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.	„Raumtemperatur 27 °C, steigend“
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.	„Raumtemperatur 35 °C, Klimagerät 2 ausgefallen“

Viele Systeme versuchen bei einer Störung zuerst eine Selbstentstörung (z. B. Dienst neu starten). Gelingt sie, wird nur ein Vorfallszähler für die Fehlerursache um eins erhöht. Gelingt sie nicht, wird ein Mensch informiert. Ist der Fehler bekannt (known error), schlägt das System aus der Known-Error-Datenbank einen Workaround (vorläufige Lösung) vor und erhöht ebenfalls den Vorfallszähler. Ein unbekannter Fehler wird mit dem gefundenen Workaround neu in die Datenbank aufgenommen.

Diese gesammelten Daten ermöglichen proaktives Problemmanagement: Statt Störungen nur zu beheben, wenn sie auftreten, wertet man Vorfallszähler und Verläufe aus und beseitigt die Ursache, bevor die nächste Störung entsteht. Ist z. B. bekannt, dass ein Bauteil im Mittel nach 450 Ladevorgängen versagt (Mean Time To Failure, MTTF), wird es ab etwa 400 Ladevorgängen geprüft und vorsorglich getauscht. 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. Steigt die Leistungsaufnahme eines Rechenzentrums, obwohl kein Gerät dazugekommen ist, hilft der Blick auf CPU-Auslastung und Netzwerkzugriffe: Mehr Rechenlast bedeutet mehr Strombedarf und mehr Abwärme, für deren Abfuhr die Kühlung zusätzlich Strom braucht.

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 und iostat unter Linux zeigen die Auslastung je Bereich. Typisch ist dieses Bild: CPU 15 %, Netzwerk 2 %, aber Arbeitsspeicher zu 91 % belegt und eine stark genutzte Auslagerungsdatei. Der Engpass ist dann der Arbeitsspeicher. Maßnahmen:

• Arbeitsspeicher erweitern (bei einer virtuellen Maschine: mehr RAM zuweisen),

• Anwendungen und Dienste mit hohem Speicherbedarf optimieren, auf andere Server verteilen oder nicht benötigte Dienste beenden,

• auf Speicherlecks (Memory Leaks) prüfen, also Programme, die Speicher belegen und nie freigeben (erkennbar an stetig steigender Belegung).

Auch Zeitverläufe helfen: Steigen Swap-Nutzung und Antwortzeiten eines Servers zu denselben Tageszeiten gemeinsam an, ist ebenfalls zu wenig Arbeitsspeicher die wahrscheinliche Ursache.

Messreihen darstellen

Zwei Messreihen mit sehr unterschiedlichen Wertebereichen in einem Diagramm mit einer y-Achse sind kaum lesbar: Eine Leistung zwischen 10 kW und 32 kW wirkt neben einer Netzfrequenz zwischen 49,1 Hz und 50,1 Hz wie eine waagerechte Linie, weil der Maßstab nur zu einer Reihe passt. Abhilfe schafft eine zweite y-Achse mit eigenem Maßstab (oder zwei übereinander angeordnete Diagramme mit gemeinsamer Zeitachse). Erst dann wird sichtbar, dass z. B. Warnungen genau dann auftreten, wenn die Leistung über eine Grenze steigt oder die Frequenz unter eine Grenze fällt.

Benchmarks und Lasttests

Ein Benchmark misst die Leistung eines Systems unter festgelegter Last, z. B. vor und nach einer Aufrüstung. Damit das Ergebnis aussagekräftig ist, müssen die Bedingungen kontrolliert sein:

• nicht benötigte Dienste und Programme beenden (auch Updates, Virenscans, Datensicherungen im Hintergrund),

• in einer abgeschotteten Testumgebung bzw. einem separaten Netz testen, damit fremder Verkehr das Ergebnis nicht verfälscht,

• praxisgerechte Tests wählen, die der tatsächlichen Nutzung entsprechen,

• mehrfach messen und Ausreißer erkennen (Caches sind beim zweiten Lauf „warm“).

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 hierarchisch aufgebautes Informationsmodell, eine Art Katalog aller abfragbaren und veränderbaren Werte eines Geräts („Messpunkte“ und „Steuerpunkte“) 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 5 °C to 60 °C,

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

Meldet S.M.A.R.T. 194 Temperature 62 °C, liegt das Laufwerk also 2 °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.

Automatisierte und manuelle Reaktionen

Reaktion	Vorteile	Grenzen
automatisiert	sofortige Reaktion, auch nachts und am Wochenende; Ausbreitung von Störungen und Angriffen wird schnell begrenzt; bekannte Muster werden zuverlässig und gleichbleibend behandelt	reagiert nur auf vorhergesehene Fälle; Fehlalarme können unnötige Abschaltungen auslösen
manuell	flexible Reaktion je nach Zusammenhang; Menschen erkennen Ursachen außerhalb der Systemgrenzen und finden für neue, komplexe Probleme individuelle Lösungen	langsamer, abhängig von Erreichbarkeit und Erfahrung

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 werden Vorfallszähler, Known-Error-Datenbank und Verläufe ausgewertet, um Ursachen zu beseitigen, bevor die nächste Störung auftritt (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. Ist z. B. der Arbeitsspeicher zu über 90 % belegt und die Auslagerungsdatei stark genutzt, während CPU und Netz wenig zu tun haben, ist der RAM der Engpass. Maßnahmen: RAM erweitern, Anwendungen optimieren oder verteilen, Speicherlecks suchen (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. Automatische Reaktionen sind sofort und rund um die Uhr wirksam und behandeln bekannte Muster zuverlässig; Menschen reagieren flexibler, erkennen Zusammenhänge außerhalb des Systems und lösen neue Probleme (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]