Logging, das hilft: Signal vs Noise, Korrelation, PII vermeiden.
Logging, das wirklich hilft: Signal vs. Noise
Wenn alles geloggt wird, ist nichts mehr lesbar. Gutes Logging ist selektiv.
Das Logging-Paradox
Zu wenig Logging: Wenn etwas schief geht, fehlt der Kontext zum Debuggen.
Zu viel Logging: Die Log-Dateien sind so voll, dass das wichtige Signal im Rauschen verschwindet.
Beides ist ein Problem. Die Balance ist: Nur loggen, was bei einem Problem wirklich hilft.
Log-Level sinnvoll einsetzen
DEBUG: Für lokale Entwicklung und gezielte Diagnose. In Produktion aus.
INFO: Wichtige, normale Systemereignisse. App Start, User Login, erfolgreiche externe Service Calls.
WARNING: Ungewöhnliche Situationen, die noch kein Fehler sind, aber beobachtet werden sollten.
ERROR: Etwas Konkretes ist schiefgegangen. Ein User konnte seine Bestellung nicht absenden.
CRITICAL: Das System ist in einem kritischen Zustand. Sofortige Aufmerksamkeit nötig.
Structured Logging
Logs als JSON, nicht als Freitext. Das ermöglicht Filterung, Aggregation, Alerting auf spezifische Felder. {"level": "error", "userId": "123", "action": "checkout", "error": "PaymentTimeout"} ist durchsuchbar. "Error during checkout for user 123: PaymentTimeout" – kaum.
Korrelations-ID durch alle Log-Zeilen
Wenn ein Request durch mehrere Services geht, braucht jede Log-Zeile eine Request-ID oder Trace-ID, die den gesamten Flow verbindet. Ohne das ist Post-mortem-Analyse ein Puzzle ohne Bild.
Checkliste Logging
Log-Level pro Umgebung konfiguriert (kein DEBUG in Produktion)
Structured Logging in JSON implementiert
Keine sensiblen Daten (Passwörter, Tokens) in Logs
Korrelations-ID durch alle Log-Zeilen
Log-Aggregation in zentralem System
Alerts auf ERROR und CRITICAL Log-Einträge
Logging-Strategie verbessern?
markom.digital überarbeitet Logging-Setups und richtet zentrale Log-Aggregation mit sinnvollem Alerting ein.
