Zentrales Logging im Serverbetrieb: Was Sie sammeln sollten, wie lange Sie es aufbewahren und was im Störfall zählt

Wenn ein Dienst ausfällt, entscheidet sich in den ersten Minuten, ob die Ursache schnell gefunden wird oder ob das Team raten muss. Monitoring zeigt, dass etwas nicht stimmt. Die Antwort auf die Frage, warum es nicht stimmt, steht fast immer in den Logs. Genau dort scheitert es in vielen Umgebungen: Die Daten existieren, aber verteilt über Dutzende Systeme, in unterschiedlichen Formaten und oft nur wenige Tage lang.

Warum lokale Logs im Störfall zu spät kommen

Lokale Logdateien haben drei strukturelle Schwächen. Erstens setzen sie voraus, dass der Server erreichbar ist. Fällt genau das System aus, dessen Logs Sie brauchen, kommen Sie im schlechtesten Fall nicht mehr heran. Zweitens sind sie flüchtig: Logrotation und kurze Aufbewahrungszeiten löschen still Daten, die Wochen später für eine Analyse gebraucht würden. Drittens lassen sie sich nicht sinnvoll korrelieren. Eine Anfrage, die über Loadbalancer, Applikationsserver und Datenbank läuft, hinterlässt drei Spuren an drei Orten.

Hinzu kommt der Sicherheitsaspekt. Wer Rootrechte auf einem kompromittierten System hat, kann lokale Logs verändern oder löschen. Ein Kopiervorgang auf ein separates System mit eigenen Zugriffsrechten macht genau das deutlich schwerer.

Welche Logs Sie tatsächlich brauchen

Das Ziel ist nicht, alles zu sammeln. Das Ziel ist, die Quellen zu sammeln, die im Störfall oder bei einer Sicherheitsfrage tatsächlich ausgewertet werden.

Systemebene

Journald beziehungsweise Syslog, Kernel-Meldungen, Dienste-Starts und -Abbrüche, OOM-Killer-Ereignisse, Paketmanager-Aktionen. Diese Daten beantworten die Frage, ob ein Problem vom Betriebssystem oder von der Anwendung ausgeht.

Anwendungs- und Webebene

Access- und Error-Logs von Webservern und Reverse Proxies, Applikationslogs mit Stacktraces, langsame Datenbankabfragen. Access-Logs sind besonders wertvoll, weil sie Statuscodes, Antwortzeiten und Pfade zusammenbringen und damit Lastmuster sichtbar machen.

Zugriff und Sicherheit

SSH-Anmeldungen und fehlgeschlagene Versuche, sudo-Aufrufe, Änderungen an Benutzern und Rechten, Firewall-Drops, Authentifizierungen in Anwendungen. Diese Kategorie ist die, die man am seltensten braucht und dann am dringendsten.

Was Sie dagegen bewusst ausschließen sollten: Debug-Ausgaben aus dem Normalbetrieb, Health-Check-Anfragen im Sekundentakt und alles, was Zugangsdaten, Tokens oder vollständige Personendaten enthält. Logs sind kein Ablageort für Nutzdaten.

Struktur schlägt Volumen

Ein Log, das nur aus freiem Text besteht, lässt sich durchsuchen, aber schlecht auswerten. Strukturierte Formate wie JSON mit festen Feldern für Zeitstempel, Host, Dienst, Schweregrad und Ereignis-ID machen aus Textzeilen auswertbare Daten. Erst dann können Sie Fragen stellen wie: Welche Hosts haben in diesem Zeitfenster HTTP 500 geliefert und welche Anwendungsversion lief dort?

Der eigentliche Wert eines zentralen Logsystems entsteht nicht durch die Menge der gesammelten Zeilen, sondern durch die Möglichkeit, Ereignisse über Systemgrenzen hinweg einer gemeinsamen Zeitachse und einer gemeinsamen Anfrage zuzuordnen.

Zwei Voraussetzungen dafür werden oft übersehen. Alle Systeme brauchen eine zuverlässige Zeitsynchronisation, sonst liegen zusammengehörige Ereignisse Sekunden auseinander und die Rekonstruktion wird unmöglich. Und alle Zeitstempel sollten in UTC mit Zeitzonenangabe geschrieben werden, damit Sommerzeitwechsel keine Lücken oder Dopplungen erzeugen.

Wer Anfragen über mehrere Dienste verfolgen will, ergänzt eine Korrelations-ID: eine eindeutige Kennung, die der erste Dienst vergibt und die alle nachgelagerten Systeme mitloggen. Der Aufwand ist gering, der Nutzen bei verteilten Anwendungen erheblich.

Aufbewahrung in Stufen denken

Die häufigste Fehlentscheidung ist eine einzige Aufbewahrungsfrist für alles. Entweder sie ist zu kurz für Sicherheitsfragen oder zu lang für die Speicherkosten. Sinnvoller ist eine Staffelung nach Zweck:

• Kurzfristig, voll durchsuchbar: alle Logs der letzten Tage bis Wochen im schnellen Index. Das ist die Basis für Fehlersuche im laufenden Betrieb.
• Mittelfristig, komprimiert: sicherheitsrelevante und zugriffsbezogene Logs in einem günstigeren Speicher. Abfragen dauern länger, sind aber möglich.
• Langfristig, nur aggregiert: Kennzahlen wie Anfragen pro Stunde oder Fehlerquoten statt Einzelereignisse. Für Kapazitätsplanung reicht das.

Welche Frist konkret gilt, hängt von Ihrer Branche, vertraglichen Zusagen und internen Vorgaben ab. Wichtig ist, dass die Frist dokumentiert und technisch durchgesetzt wird, statt sich aus der Standardkonfiguration zu ergeben.

Datenschutz ernst nehmen

IP-Adressen, Benutzernamen und User-Agents in Access-Logs sind personenbezogene Daten. Das bedeutet nicht, dass Sie sie nicht protokollieren dürfen, wohl aber, dass Zweck, Speicherdauer und Zugriffsberechtigungen festgelegt sein müssen. Drei Punkte helfen in der Praxis:

1. Ein Löschkonzept, das automatisch greift und nicht von manuellen Aufräumaktionen abhängt.
2. Zugriffsbeschränkung auf das Logsystem nach Rolle, denn wer Logs lesen darf, sieht in der Regel mehr als in der Anwendung selbst.
3. Eintrag im Verzeichnis der Verarbeitungstätigkeiten und, falls ein externer Dienstleister die Logs verarbeitet, ein passender Auftragsverarbeitungsvertrag.

Anonymisierung oder Kürzung von IP-Adressen ist möglich, verringert aber den Wert für die Sicherheitsanalyse. Diese Abwägung sollte bewusst getroffen und nicht dem Zufall überlassen werden.

Abgrenzung zum Monitoring

Monitoring und Logging lösen unterschiedliche Aufgaben. Metriken sind kompakt, numerisch und eignen sich für Schwellwerte und Alarmierung. Logs sind detailliert, textlastig und eignen sich für die Ursachenanalyse. Wer versucht, aus Logs ein Alarmsystem zu bauen, bekommt teure Abfragen und verzögerte Meldungen. Wer versucht, aus Metriken eine Ursache abzuleiten, rät.

Eine sinnvolle Verbindung ist der umgekehrte Weg: Der Alarm kommt aus dem Monitoring und enthält direkt den Zeitraum und die Hostkennung, mit denen die passende Logabfrage startet. Zwei bis drei Logabfragen mit festem Ergebnis pro typischem Störungsbild sparen im Ernstfall mehr Zeit als jede zusätzliche Datenquelle.

Das Logsystem ist selbst ein Produktivsystem

Ein zentraler Logserver sammelt Daten aus der gesamten Umgebung und wird damit selbst kritisch. Er braucht eigene Überwachung, eigene Backups der Konfiguration, eine klare Kapazitätsplanung und Schutz gegen Überlast. Ein einzelner Dienst, der in einer Schleife Fehler protokolliert, kann den Speicher innerhalb von Stunden füllen.

Praktische Gegenmaßnahmen sind Ratenbegrenzung pro Quelle, harte Speichergrenzen pro Index und eine Alarmierung auf ungewöhnlich hohe Eingangsraten. Ebenso sollte klar sein, was passiert, wenn das Logsystem nicht erreichbar ist: Puffern die Agenten lokal und senden später nach, oder gehen die Daten verloren?

Ein pragmatischer Einstieg

Sie müssen nicht mit einer vollständigen Plattform beginnen. Eine sinnvolle Reihenfolge ist: zuerst Systemlogs und Zugriffslogs aller Server zentral sammeln, dann Zeitsynchronisation und Formate vereinheitlichen, dann Retention-Stufen und Löschfristen festlegen, danach Anwendungslogs strukturieren und zuletzt Korrelations-IDs einführen.

Der Prüfstein ist einfach: Nehmen Sie eine Störung aus den vergangenen Monaten und versuchen Sie, sie allein mit den zentral vorhandenen Logs zu rekonstruieren. Wo Sie dabei hängen bleiben, fehlt eine Quelle, ein Feld oder Aufbewahrungszeit. Diese Lücken zu schließen bringt mehr als jede zusätzliche Datenquelle, die niemand abfragt.