Fehlerbehandlung und Logging in Anwendungen, Best Practices 2026

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