LF11b

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?#

KategorieBeispiele
SystemressourcenCPU-Auslastung, RAM-Auslastung, Speicherplatz (Festplatte voll?)
NetzwerkErreichbarkeit (Ping), Bandbreitenauslastung, Latenz
DiensteLäuft der Webserver, die Datenbank, der Mailserver? (Prozess- und Portprüfung)
SicherheitFehlgeschlagene Anmeldeversuche, ungewöhnlicher Datenverkehr
AnwendungAntwortzeiten, 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-LevelBedeutungBeispiel
DebugDetailinformation für die Entwicklung/FehlersucheVariableninhalt bei jedem Funktionsaufruf
InfoNormaler BetriebsablaufDienst erfolgreich gestartet
WarningUngewöhnliches Ereignis, noch kein FehlerSpeicherplatz zu 85 % belegt
ErrorEin Vorgang ist fehlgeschlagenVerbindung zur Datenbank abgebrochen
CriticalDer Betrieb ist akut gefährdetFestplatte 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#

Ressourcen#