Zu wenig Logging kostet Kontext beim Debuggen. Zu viel Logging versteckt das Signal im Rauschen. Beides ist ein Problem.
Gutes Logging ist selektiv: Nur loggen, was bei einem Problem wirklich hilft.
Log-Level sinnvoll einsetzen
DEBUG fuer lokale Entwicklung und gezielte Diagnose, in Produktion abgeschaltet. INFO fuer wichtige, normale Systemereignisse wie App-Start oder erfolgreiche externe Service Calls. WARNING fuer ungewoehnliche Situationen, die noch kein Fehler sind, aber beobachtet werden sollten. ERROR fuer konkret Schiefgelaufenes, etwa eine gescheiterte Bestellung. CRITICAL fuer einen kritischen Systemzustand, der sofortige Aufmerksamkeit erfordert.
Structured Logging
Logs als JSON statt als Freitext ermoeglichen Filterung, Aggregation und gezieltes Alerting auf einzelne Felder, ein strukturiertes Log-Ereignis ist durchsuchbar, ein Fliesstext-Eintrag kaum.
Korrelations-ID durch alle Log-Zeilen
Wenn ein Request durch mehrere Services laeuft, braucht jede Log-Zeile eine Request- oder Trace-ID, die den gesamten Flow verbindet. Ohne das wird eine Post-Mortem-Analyse zum Puzzle ohne Bild.
Checkliste: Log-Level pro Umgebung konfiguriert, Structured Logging implementiert, keine sensiblen Daten in Logs, Korrelations-ID durch alle Log-Zeilen, Log-Aggregation in zentralem System, Alerts auf ERROR- und CRITICAL-Eintraege.
Ein Beispiel aus der Praxis
Ein Team hatte in einem produktiven System das DEBUG-Log-Level versehentlich aktiv gelassen, was innerhalb weniger Tage mehrere Gigabyte an Logdaten produzierte und dabei versehentlich auch komplette Request-Bodies inklusive sensibler Formulardaten mitschrieb. Der Vorfall wurde nur durch Zufall bei einer Kostenpruefung des Log-Speichers entdeckt. Seither ist die Konfiguration des Log-Levels pro Umgebung Teil eines automatisierten Deployment-Checks, der verhindert, dass DEBUG jemals versehentlich in Produktion aktiv bleibt.
Logging-Strategie verbessern? markom.digital ueberarbeitet Logging-Setups und richtet zentrale Log-Aggregation mit sinnvollem Alerting ein.
