Obsługa błędów i logowanie w aplikacjach – best practices 2026

TL;DR

Prawidłowa obsługa błędów i logowanie ułatwiają debugowanie, monitoring i utrzymanie aplikacji. W 2026 warto stosować strukturyzowane logi, poziomy (info, warn, error) i centralne zbieranie (np. Sentry, Datadog). Oto praktyki.

Dla kogo to jest

• Deweloperów backendu i full-stack
• Zespołów wdrażających monitoring i alerty
• Osób chcących unikać „cichego” padania aplikacji

Fraza (SEO)

obsługa błędów, logowanie, strukturyzowane logi, monitoring, node.js, best practices

Po co obsługa błędów i logowanie?

• Debugowanie – szybkie znalezienie przyczyny błędu (stack trace, kontekst)
• Monitoring – alerty przy krytycznych błędach, metryki
• Audit – kto, kiedy, co (np. logowanie żądań, zmian)
• UX – użytkownik widzi zrozumiały komunikat zamiast białego ekranu

Zasady obsługi błędów

• Nie połykaj błędów – nie używaj pustego catch bez logowania
• Różnicuj błędy – oczekiwane (np. walidacja) vs nieoczekiwane (bug) – inna reakcja
• Zwracaj bezpieczne komunikaty – w API nie zwracaj stack trace do klienta; loguj pełne info wewnętrznie
• Używaj kodów HTTP – 400 (bad request), 401 (unauthorized), 404, 500 (server error)

Poziomy logowania

• error – błędy wymagające reakcji (exception, failed request)
• warn – coś nieoczekiwanego, ale aplikacja działa (deprecated API, retry)
• info – ważne zdarzenia (start/stop, deploy, kluczowe operacje)
• debug – szczegóły do debugowania (tylko w dev/staging)

W produkcji zwykle: info, warn, error; bez debug (za dużo danych).

Strukturyzowane logi (JSON)

Zamiast tekstu „User 123 failed” lepiej:

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

Ułatwia wyszukiwanie i agregację w narzędziach (ELK, Datadog, CloudWatch).

Przykład: Node.js / Next.js API

// Middleware lub global error handler
function logError(err, req) {
  logger.error({
    message: err.message,
    stack: err.stack,
    path: req?.path,
    method: req?.method,
  });
}

// W API route – nie przesyłaj stack do klienta
try {
  await doSomething();
} catch (err) {
  logError(err, request);
  return Response.json(
    { error: 'Something went wrong' },
    { status: 500 }
  );
}

Checklist / kroki

• Wprowadź jeden logger (np. Pino, Winston) z poziomami
• Loguj błędy z kontekstem (request id, user id, path)
• W produkcji nie zwracaj stack trace w odpowiedzi API
• Podłącz narzędzie do zbierania błędów (Sentry, LogRocket) dla frontendu i/lub backendu
• Ustaw alerty na poziom error (Slack, email, PagerDuty)

FAQ

Czy logować każde żądanie?

Zależy. Wysokotrafficowe API – często tylko błędy i wybrane metryki. Mniej ruchu – można logować każde żądanie (info) z czasem trwania. Unikaj logowania haseł i tokenów.

Sentry vs własne logi?

Sentry skupia się na błędach i ich kontekście (release, user, breadcrumbs). Własne logi – pełna kontrola nad formatem i przechowywaniem. W praktyce łączy się: Sentry do błędów, logi do audytu i metryk.

Jak nie wyciekać danymi w błędach?

W odpowiedzi do klienta zwracaj ogólny komunikat („Wystąpił błąd”). Stack trace, ścieżki plików, query – tylko w logach i w narzędziach wewnętrznych.

Chcesz wdrożyć logowanie i monitoring w aplikacji?

• Kontakt