Fehlerbehandlung und Logging in Anwendungen

Kurzfassung

Richtige Fehlerbehandlung und Logging erleichtern Debugging, Monitoring und Wartung. 2026: strukturierte Logs, Level (info, warn, error) und zentrale Sammlung (z. B. Sentry, Datadog). Hier die Praktiken.

Für wen ist das

Backend- und Full-Stack-Entwickler
Teams, die Monitoring und Alerting einrichten
Alle, die stille Ausfälle vermeiden wollen

Keyword (SEO)

fehlerbehandlung, logging, strukturierte logs, monitoring, node.js, best practices

Wozu Fehlerbehandlung und Logging?

Debugging – schnelle Ursachenfindung (Stack Trace, Kontext)
Monitoring – Alerts bei kritischen Fehlern, Metriken
Audit – wer, wann, was (z. B. Request-Logs, Änderungs-Logs)
UX – Nutzer sieht klare Meldung statt weißen Bildschirm

Regeln zur Fehlerbehandlung

Fehler nicht verschlucken – kein leeres catch ohne Logging
Fehlertypen unterscheiden – erwartet (z. B. Validierung) vs. unerwartet (Bug) – unterschiedliche Reaktion
Sichere Meldungen zurückgeben – im API keine Stack Traces an den Client; intern vollständig loggen
HTTP-Status nutzen – 400 (bad request), 401 (unauthorized), 404, 500 (server error)

Log-Level

error – Fehler, die Reaktion erfordern (Exception, fehlgeschlagener Request)
warn – Unerwartetes, App läuft weiter (deprecated API, Retry)
info – Wichtige Ereignisse (Start/Stop, Deploy, Schlüsseloperationen)
debug – Details zum Debuggen (nur Dev/Staging)

In Produktion meist: info, warn, error; kein debug (zu viele Daten).

Strukturierte Logs (JSON)

Statt Text „User 123 failed“ besser:

{
  "level": "error",
  "message": "Login failed",
  "userId": "123",
  "reason": "Invalid password",
  "timestamp": "2026-01-29T12:00:00Z"
}

Erleichtert Suche und Auswertung in Tools (ELK, Datadog, CloudWatch).

Beispiel: Node.js / Next.js API

// Middleware oder globaler Error Handler
function logError(err, req) {
  logger.error({
    message: err.message,
    stack: err.stack,
    path: req?.path,
    method: req?.method,
  });
}

// In API Route – Stack nicht an Client senden
try {
  await doSomething();
} catch (err) {
  logError(err, request);
  return Response.json(
    { error: 'Something went wrong' },
    { status: 500 }
  );
}

Checkliste / Schritte

Einen Logger (z. B. Pino, Winston) mit Leveln einführen
Fehler mit Kontext loggen (Request-ID, User-ID, Pfad)
In Produktion keinen Stack Trace in API-Response zurückgeben
Fehlersammlung (Sentry, LogRocket) für Frontend und/oder Backend einbinden
Alerts auf Error-Level setzen (Slack, E-Mail, PagerDuty)

FAQ

Jeden Request loggen?

Abhängig. High-Traffic-API – oft nur Fehler und ausgewählte Metriken. Weniger Traffic – jeden Request (info) mit Dauer möglich. Nie Passwörter oder Tokens loggen.

Sentry vs. eigene Logs?

Sentry fokussiert auf Fehler und Kontext (Release, User, Breadcrumbs). Eigene Logs – volle Kontrolle über Format und Speicher. In der Praxis beides: Sentry für Fehler, Logs für Audit und Metriken.

Keine Daten in Fehlermeldungen leaken?

An den Client nur generische Meldung („Etwas ist schiefgelaufen“). Stack Trace, Dateipfade, Queries – nur in Logs und internen Tools.

Wollen Sie Fehlerbehandlung und Monitoring in Ihrer Anwendung?

Kontakt

Fehlerbehandlung und Logging in Anwendungen – Best Practices 2026