Log-Levels sind Schweregrad-Marker für jeden Logeintrag. Sie steuern, was aufgezeichnet, was angezeigt und was zu einem Alarm führt. Der gängige Standard kennt fünf Stufen — DEBUG, INFO, WARN, ERROR, FATAL — mit aufsteigendem Schweregrad. Der Kernwert der Stufen: im Normalbetrieb das Rauschen minimal halten und im Problemfall nach Stufe schnell filtern und alarmieren.
Schnellreferenz: Die fünf Standardstufen
| Stufe | Bedeutung | Typische Inhalte | Produktion | Alarm |
|---|---|---|---|---|
| DEBUG | Debug-Details | Variablenwerte, SQL-Statements, Funktionsargumente | Aus | Nein |
| INFO | Normale Geschäftsmeilensteine | Login, Bestellung erstellt, Aufgabe gestartet | An | Nein |
| WARN | Abnormal, aber selbstheilend | Wiederholung erfolgreich, Fallback ausgelöst, langsame Anfrage | An | Aggregieren und manuell prüfen |
| ERROR | Aktion fehlgeschlagen, betrifft den aktuellen Vorgang | API 5xx, Zahlung fehlgeschlagen, Null-Pointer | An | Ja |
| FATAL | Systemweiter Ausfall | Datenbank nicht erreichbar, Dienst startet nicht | An | Ja (P0-Antwort) |
Wie man die richtige Stufe wählt
In der Praxis ist der Missbrauch von Stufen häufiger als fehlende Logs. Hier brauchbare Kriterien:DEBUG: für die eigenen Augen des Entwicklers
- Kriterium: Die Information ist wertlos, solange das System normal läuft, und nur bei der Jagd nach einem konkreten Bug nützlich;
- Typische Inhalte: Funktionsargumente und Rückgabewerte, Zwischenergebnisse, Cache-Trefferquoten;
- Kernprinzip: in Produktion standardmäßig aus. Nicht gelöscht — gefiltert, damit man es im Problemfall kurz einschalten kann.
INFO: für alle, die wissen wollen, was das System tut
- Kriterium: Wer dieses Log ein halbes Jahr später liest, kann die Nutzerreise rekonstruieren;
- Typische Inhalte: zentrale Geschäftsaktionen (Registrierung, Bestellung, Veröffentlichung), Start/Ende und Dauer von Aufgaben;
- Anti-Pattern: jedes HTTP 200 als INFO loggen — das ist Sache des Access-Logs; die Business-Logs damit zu fluten ist verschwendete Information.
WARN: etwas ging schief, aber das System hat es aufgefangen
- Kriterium: Jemand sollte es wissen, aber niemand muss um 3 Uhr nachts aufstehen;
- Typische Inhalte: Erfolg nach Retry, Rate-Limiting/Degradierung ausgelöst, Anfrage über Schwellenwert;
- Risikosignal: ein plötzlicher Anstieg von WARNs geht oft ERRORs voraus — an Trend-Monitoring anbinden.
ERROR: eine Nutzeraktion ist fehlgeschlagen
- Kriterium: Wird das nicht behoben, trifft den Nutzer dasselbe Problem erneut;
- Typische Inhalte: fehlgeschlagene externe Serviceaufrufe, Validierungsfehler, unbehandelte Exceptions;
- Kernanforderung: jedes ERROR braucht Kontext (URL, Nutzer-/Tenant-ID, Request-Parameter, Stacktrace), sonst ist es nur nicht umsetzbares Rauschen.
FATAL: das System ist bereits down
- Kriterium: Der Dienst kann als Ganzes seinen Job nicht mehr erfüllen;
- Typische Inhalte: Datenbankverbindung fehlgeschlagen, Pflichtkonfiguration fehlt, Start fehlgeschlagen;
- Praxis-Tipp: FATAL ist in Web-Anwendungen selten — die meisten „alles hängt"-Lagen zeigen sich als Schwall von ERRORs, abgedeckt durch einen „plötzlicher-ERROR-Anstieg"-Alarm. FATAL nicht inflationär einsetzen und damit entschärfen.
Log-Levels in der Browser-Console
Frontend-Stufen heißen wie die Backend-Stufen, können aber weniger. Die Console unterstützt nativ:| Methode | Stufe in der Console | Zweck |
|---|---|---|
console.debug() |
Debug (standardmäßig ausgeblendet, Verbose aktivieren) | Debugging in der Entwicklung |
console.log() |
Info | Normale Ausgabe |
console.info() |
Info | Wie oben, expliziter formuliert |
console.warn() |
Warning, gelb | Hinweise auf behebbare Probleme |
console.error() |
Error, rot, mit Stacktrace | Fehler und unbehandelte Exceptions |
console.debug statt console.log schreiben — der Produktions-Build versteckt sie hinter dem Standardfilter, manuelles Aufräumen entfällt;window.onerror / unhandledrejection) sind von Hause aus ERROR-Stufe und der erste Anhaltspunkt in der Produktion.Das besondere Frontend-Problem: Nutzer sammeln keine Logs für dich
Backend-Logs liegen gebündelt auf dem Server und sind bei Problemen jederzeit abrufbar. Frontend-Logs verteilen sich auf die Browser jedes einzelnen Nutzers — der Nutzer meldet „die Seite ist kaputt", und die Console-Fehler und fehlgeschlagenen Requests verschwinden mit dieser Seiten-Session. Wenn der Nutzer der Anleitung folgt und DevTools öffnet (Schritte: Browser-Console öffnen), hat ein Refresh die Fehler längst weggespült. Die Frage, die eine Frontend-Log-Strategie beantworten muss, lautet also nicht „wie verteile ich Stufen", sondern „wie bewahre ich die Logs aus dem Augenblick des Fehlers auf". Gängige Ansätze:| Ansatz | Funktionsweise | Kosten |
|---|---|---|
| Selbst gebauter Reporter | Gesamte Console-Ausgabe zurück an den Server | Hohe Speicher-/Privatsphärekosten, Sampling schwer zu justieren |
| Frontend-Monitoring-Plattform | Volle Erfassung + Session-Replay | Volumenbasierte Abrechnung; für kleine und mittlere Teams teuer |
| Bedarfsgetriebene Erfassung (am Bug-Report dran) | Beim Einreichen von Feedback werden die Console-/Network-Fehler dieses Moments automatisch mitgeschickt | Geringste Kosten; deckt „vom Nutzer gemeldet" ab, die größte Quelle überhaupt |
Häufige Fehler
| Fehler | Richtig |
|---|---|
Alles mit console.log, nie aufgeräumt |
Stufen nutzen: debug fürs Debugging, info für Geschäftsmeilensteine, debug im Build herauskompilieren |
| Fehler als INFO loggen, „um Ops nicht zu erschrecken" | Ein Fehler ist ein ERROR; Alarmierung hängt an Stufen, nicht daran, dass jemand Logs liest |
| ERROR nur mit Meldung, ohne Kontext | Immer URL, Parameter und Stacktrace mitgeben — sonst hat man nichts aufgezeichnet |
| DEBUG überall an, „zum leichteren Fehlersuchen" | Stufen sind ein Filter: DEBUG normalerweise aus, im Problemfall gezielt an |
| WARN-Stau, den niemand abarbeitet | WARNs an Trend-Alarme anbinden; ein Schwall ist der Vorbote von ERRORs |