Monitoring & Logging#
Monitoring ist die kontinuierliche Überwachung von IT-Systemen, um Fehler frühzeitig zu erkennen, bevor sie zu einem Ausfall führen. Logging ergänzt das um eine lückenlose Aufzeichnung von Ereignissen, die im Nachhinein zur Fehleranalyse oder forensischen Untersuchung ausgewertet werden kann.
Warum überwachen?#
Ohne Monitoring bemerkt ein Betrieb einen Systemausfall oft erst, wenn Anwender sich beschweren — dann ist der Schaden bereits entstanden. Ziel des Monitorings ist es, Probleme proaktiv zu erkennen:
- Verfügbarkeit sicherstellen — Ausfälle von Diensten sofort bemerken, nicht erst durch Kundenmeldungen
- Frühwarnung — Ressourcenengpässe erkennen, bevor sie zum Ausfall führen (z. B. Festplatte wird voll)
- Kapazitätsplanung — Trends erkennen, um Hardware rechtzeitig aufzurüsten
- Nachvollziehbarkeit — im Sicherheitsvorfall rekonstruieren, was wann passiert ist
Was wird typischerweise überwacht?#
| Kategorie | Beispiele |
|---|---|
| Systemressourcen | CPU-Auslastung, RAM-Auslastung, Speicherplatz (Festplatte voll?) |
| Netzwerk | Erreichbarkeit (Ping), Bandbreitenauslastung, Latenz |
| Dienste | Läuft der Webserver, die Datenbank, der Mailserver? (Prozess- und Portprüfung) |
| Sicherheit | Fehlgeschlagene Anmeldeversuche, ungewöhnlicher Datenverkehr |
| Anwendung | Antwortzeiten, Fehlerraten einer Applikation |
Für die Abfrage von Netzwerkgeräten wird häufig SNMP eingesetzt: Ein Agent auf dem überwachten Gerät stellt Kennzahlen bereit, die ein Management-System zentral abfragt oder die das Gerät selbstständig als Trap meldet.
Zentrale Log-Sammlung#
Jeder Server, jede Firewall und jeder Netzwerk-Switch erzeugt eigene Logdateien. Werden diese nur lokal auf dem jeweiligen Gerät gespeichert, entstehen mehrere Probleme:
- Bei einem Ausfall des Systems können die Logs mit verloren gehen
- Ein Angreifer, der ein System kompromittiert, kann lokale Logs manipulieren oder löschen, um Spuren zu verwischen
- Eine Auswertung über mehrere Systeme hinweg (z. B. „wann hat sich dieser Benutzer wo überall angemeldet?") ist praktisch unmöglich, wenn jedes System isoliert protokolliert
Deshalb werden Logs in der Praxis an einen zentralen Log-Server weitergeleitet, wo sie gesammelt, indiziert und ausgewertet werden können. Ein System, das Logs verschiedenster Quellen zentral sammelt und zusätzlich Sicherheitsereignisse korreliert, wird als SIEM-System (Security Information and Event Management) bezeichnet.
flowchart LR
S1[Server] -->|Logs / Metriken| C[Zentrale Sammlung]
S2[Firewall] -->|Logs / Metriken| C
S3[Switch/Router] -->|Logs / Metriken| C
S4[Anwendung] -->|Logs / Metriken| C
C --> A[Zentrale Auswertung<br/>Dashboards, Korrelation]
A -->|Schwellenwert<br/>überschritten| AL[Alerting]
AL --> N1[E-Mail]
AL --> N2[SMS / Push]
AL --> N3[Ticket-System]Log-Level#
Damit nicht jede Kleinigkeit als „kritisch" gilt und wichtige Meldungen in der Masse untergehen, werden Logeinträge nach Schweregrad abgestuft. Eine gängige Abstufung:
| Log-Level | Bedeutung | Beispiel |
|---|---|---|
| Debug | Detailinformation für die Entwicklung/Fehlersuche | Variableninhalt bei jedem Funktionsaufruf |
| Info | Normaler Betriebsablauf | Dienst erfolgreich gestartet |
| Warning | Ungewöhnliches Ereignis, noch kein Fehler | Speicherplatz zu 85 % belegt |
| Error | Ein Vorgang ist fehlgeschlagen | Verbindung zur Datenbank abgebrochen |
| Critical | Der Betrieb ist akut gefährdet | Festplatte voll, Dienst nicht mehr erreichbar |
In der Praxis lässt sich die Menge der protokollierten Meldungen über den Log-Level filtern — im Normalbetrieb reicht oft „Warning und höher", zur Fehlersuche wird kurzzeitig auf „Debug" umgeschaltet.
Alerting#
Alerting ist die automatische Benachrichtigung, sobald ein definierter Schwellenwert (Threshold) überschritten wird — etwa wenn die CPU-Auslastung dauerhaft über 90 % liegt oder ein überwachter Dienst nicht mehr antwortet. Wichtig dabei:
- Sinnvolle Schwellenwerte — zu empfindlich eingestellte Alarme führen zu „Alert Fatigue", bei der wichtige Meldungen in der Flut untergehen
- Eskalationsstufen — leichte Probleme per E-Mail melden, kritische Ausfälle zusätzlich per SMS oder Anruf
- Nachvollziehbarkeit — jeder Alarm sollte im Ticket-System oder Log dokumentiert werden, auch nachdem er behoben wurde
Prüfungsbeispiele#
„Warum reicht es nicht aus, Logdateien nur lokal auf jedem Server zu speichern?"
→ Lokale Logs können bei einem Systemausfall verloren gehen oder von einem Angreifer manipuliert werden, um Spuren zu verwischen. Eine zentrale Log-Sammlung ermöglicht außerdem die Auswertung über mehrere Systeme hinweg.
„Ein Administrator bekommt jede Minute eine E-Mail wegen kleinerer Warnungen und übersieht dadurch einen kritischen Ausfall. Was wurde falsch konfiguriert?"
→ Die Alerting-Schwellenwerte bzw. Log-Level sind zu empfindlich eingestellt — es fehlt eine sinnvolle Eskalationsstufe, die zwischen unkritischen Warnungen und akuten kritischen Ereignissen unterscheidet.
„Welches Protokoll wird häufig eingesetzt, um Netzwerkgeräte wie Switches und Router zentral zu überwachen?"
→ SNMP — ein Manager fragt Kennzahlen bei Agenten auf den Geräten ab (GET) oder die Geräte melden Ereignisse selbstständig (TRAP).
Selbstkontrolle#
❓ Warum sollten Logs nicht nur lokal auf jedem System gespeichert werden?
❓ Welches Log-Level zeigt an, dass der Betrieb akut gefährdet ist?
❓ Wie wird ein System bezeichnet, das Logs verschiedenster Quellen zentral sammelt und Sicherheitsereignisse korreliert?
Siehe auch#
- protokolle-ports — SNMP als Protokoll für Netzwerkmonitoring
- schutzbedarfsanalyse ISMSLF4 — Verfügbarkeit als Schutzziel, das Monitoring absichert
- hochverfuegbarkeit — Monitoring als Voraussetzung für automatisches Failover
- malware — Logs als Grundlage zur Erkennung von Sicherheitsvorfällen