Logging: Fehler protokollieren und auswerten

Mit dem Debugger findest du Bugs interaktiv – aber das funktioniert nur wenn du den Bug lokal reproduzieren kannst. Was ist mit Bugs die nur in Production auftreten? Nur bei einem bestimmten Kunden? Nur nachts um 3 Uhr unter Last? Da kommst du mit einem Debugger nicht hin. Die Antwort heißt Logging: dein Programm hinterlässt unterwegs eine Spur an Nachrichten die du später analysieren kannst.

Logging ist nicht das Gegenteil von Debugging, sondern ein ergänzendes Werkzeug. Profis nutzen beides: Debugger für lokale Bugs, Logging für Production-Probleme. Diese Lektion zeigt die Konzepte: Log-Levels, strukturiertes Logging, Log-Aggregation und wie du Logs richtig auswertest. Sprachunabhängig – funktioniert in Java, Python, JavaScript und überall sonst.

1) Warum Logging?

Stell dir vor du baust einen Webshop. Ein Kunde meldet: „Bei meiner Bestellung gestern Abend kam plötzlich die Fehlermeldung 'Etwas ging schief'." Was tust du?

• Den Debugger anwerfen geht nicht – du bist nicht beim Kunden
• Den Code lesen hilft nur wenn du weißt wo der Fehler war
• Den Kunden fragen „was hast du genau gemacht?" frustriert beide Seiten

Mit gutem Logging wäre die Antwort einfach: in den Server-Logs vom Abend nachschauen. Da steht: [ERROR] 2026-05-17 19:42:15 OrderService.process: Customer ID 4711 - PaymentGateway timeout after 30s. Aha, der Zahlungs-Dienst hatte Timeouts. Mit dieser Info kannst du gezielt das Problem fixen.

Logging ist die einzige Möglichkeit Production-Bugs zu diagnostizieren. Ohne sie ratest du nur. Mit Logging hast du Beweise.

2) Die Log-Level-Pyramide

Nicht jede Log-Zeile ist gleich wichtig. Die meisten Logging-Frameworks bieten Severity-Levels – Schweregrade. Damit kannst du in Production nur „kritische" Logs sehen, beim Debugging dagegen alles. Die klassische Hierarchie:

3) Log-Level-Konfiguration

Das Mächtigste an Levels: zur Laufzeit konfigurierbar. In Production setzt du den Level auf INFO – nur Infos, Warnungen und Fehler. Bei Bug-Verdacht drehst du auf DEBUG – plötzlich sind alle Detail-Infos da. Ohne Code-Change, ohne Neustart (bei manchen Frameworks).

So sieht das in der Praxis aus. Java mit Logback/SLF4J:

In Python:

4) Interaktiver Log-Reader

Spiel mit den Filtern – das ist genau wie ein echtes Log-Analyse-Tool funktioniert:

5) Strukturiertes Logging

Klassische Logs sind Textzeilen: 2026-05-17 19:42:15 ERROR PaymentGateway timeout for order 4711. Mit grep durchsuchbar, aber nicht maschinell aggregierbar. Strukturierte Logs sind JSON – jede Zeile ein Objekt mit Feldern:

Klingt overkill für eine Log-Zeile? Auf den ersten Blick ja. Aber: dieser Log ist automatisch durchsuchbar nach Feldern. „Wie viele Timeouts hatten wir heute pro Gateway?" → eine SQL-ähnliche Query auf den Logs. „Welcher User hatte gestern die meisten Fehler?" → Aggregation über user_id. Mit Text-Logs wäre das eine grep-Orgie.

Beispiele für strukturiertes Logging:

6) Schlechte vs. gute Log-Nachrichten

Eine Log-Zeile ist nur nützlich wenn sie genug Information enthält. Vergleich:

7) Was du NIEMALS loggen darfst

Logs landen oft an vielen Stellen – Files, zentrale Systeme, Backup-Bänder. Sensible Daten in Logs sind ein Sicherheits- und DSGVO-Albtraum. Logge NIEMALS:

• Passwörter – auch nicht gehashed/verschlüsselt. Klingt offensichtlich, passiert aber ständig durch versehentliches Loggen ganzer Request-Bodies.
• API-Keys, Tokens, Session-IDs – jeder mit Log-Zugriff könnte sie nutzen
• Kreditkarten-Daten (PCI-DSS-Verstoß!) – Vollständige Karten oder CVV niemals
• Personenbezogene Daten in unnötigem Detail – Name oder Email ja, Geburtsdatum + Anschrift + Krankenakten nein. DSGVO-Datenminimierung!
• Vollständige SQL-Queries mit User-Input – könnten Geheimnisse enthalten

Goldene Regel: was im Log steht, ist effektiv öffentlich. Wenn du es nicht in einer Email an einen Unbekannten schicken würdest, gehört es nicht in den Log. Bei Bedarf: Masking – Karten als ****1234, Emails als a***@firma.de.

8) Logging-Frameworks pro Sprache

Wichtige Auswahlkriterien: strukturiertes Logging (JSON-Output), asynchron (nicht jeder Log blockiert die App), Performance (manche sind 10x schneller als andere – wichtig bei Millionen Logs/Tag), flexible Output-Targets (Console, File, Syslog, Cloud).

9) Log-Aggregation: ELK, Loki, Splunk

Bei einer kleinen App: Logs in app.log-Datei, mit tail -f oder grep drauf zugreifen. Bei einer App mit 10 Servern, 50 Microservices? Pro Server eine Log-Datei ist unbenutzbar.

Lösung: zentrale Log-Aggregation. Alle Server schicken ihre Logs an einen Sammel-Dienst, der sie indexiert und durchsuchbar macht. Klassiker:

• ELK-Stack: Elasticsearch (Speicher) + Logstash (Sammlung) + Kibana (UI). Open-Source, weit verbreitet.
• Grafana Loki: jüngere Alternative, leichtgewichtiger. Kombiniert sich gut mit Prometheus für Metriken und Grafana fürs UI.
• Splunk: Enterprise-Tool, kommerziell. Sehr mächtig aber teuer.
• Datadog / New Relic: SaaS-Logging-Lösungen mit Monitoring kombiniert.
• CloudWatch / Stackdriver: Cloud-Provider-eigene Lösungen (AWS, Google Cloud – siehe K31).

In allen kannst du Queries wie „alle ERROR-Logs der letzten Stunde, gruppiert nach Service" stellen – mit grafischen Dashboards. Bei mehreren Servern ist das unverzichtbar.

10) Correlation-IDs / Trace-IDs

In einer Microservice-Welt geht ein User-Request durch mehrere Services. Wenn ein Service fehlt, willst du sehen was die anderen Services für genau diesen Request gemacht haben. Lösung: Correlation-ID – eine eindeutige ID die durch alle Services mitgegeben wird:

Filterst du nach trace=abc123, siehst du die komplette Lebenslinie eines Requests über alle Services. Verteilte Tracing-Systeme wie Jaeger, Zipkin oder das OpenTelemetry-Framework formalisieren das auf nächster Stufe – mit Visualisierungen, Spans, Latenz-Analyse.

11) Logging vs. Metrics vs. Tracing

In moderner Architektur kennt man die „three pillars of observability":

• Logs: was ist passiert (Text + Daten)
• Metrics: wie viel ist passiert (Zahlen, Counter, Gauges)
• Traces: wie ist es gelaufen (Sequenz über Services)

Jedes hat seinen Platz. Bei Bugs startest du meist mit Metrics („wann fingen Errors an"), drillst in Traces („welcher Request war betroffen"), und endest mit Logs („welche genaue Fehlermeldung").

12) Praxis-Tipps

Aus langjähriger FISI/FIAE-Erfahrung:

• Logge Eintrittspunkte und Ausgabe-Werte der wichtigen Funktionen – das ist meist genug
• Logge alle Exceptions mit Stacktrace, niemals nur die Message
• Logge Zeitstempel immer in UTC oder mit Zeitzone – sonst Albtraum in verteilten Systemen
• Logge das WAS, nicht das WIE – „Order created" reicht, nicht „loop iteration 42"
• Logs sind nicht für User – nicht „Fehler aufgetreten" sondern „NullPointerException at OrderService:42"
• Achte auf Log-Volumen – ein DEBUG in einer 1000x/sek-Loop killt deine Disk in Minuten
• Log-Rotation einrichten: Logfiles sollen rotieren (täglich, oder bei X MB) und alte gelöscht werden

Zusammenfassung

Logging ist die einzige Möglichkeit Production-Bugs zu diagnostizieren wo der Debugger nicht hilft. Log-Levels (6 Standard-Stufen): FATAL (System tot), ERROR (Operation fehlgeschlagen), WARN (Auffälligkeit), INFO (normaler Ablauf), DEBUG (Detail-Info), TRACE (extrem detailliert). Level-Konfiguration zur Laufzeit ohne Code-Change. Strukturiertes Logging: JSON-Lines mit Feldern statt Textzeilen – maschinell aggregierbar. Gute Logs: Was passiert, welche Werte, welcher Kontext, quantitative Daten. Nie loggen: Passwörter, API-Keys, Kreditkarten, übermäßige personenbezogene Daten. Frameworks: SLF4J/Logback (Java), logging/structlog (Python), winston/pino (Node), Serilog (.NET). Log-Aggregation: ELK-Stack, Grafana Loki, Splunk, Datadog für zentrale Sammlung über mehrere Server. Correlation-IDs zum Verfolgen eines Requests durch Microservices. Drei Säulen Observability: Logs, Metrics, Traces – ergänzen sich. Praxis: Eintritte+Ausgaben loggen, Exceptions mit Stacktrace, UTC-Timestamps, sparsame Log-Mengen, Log-Rotation. Mehr zu API-Debugging in L9.