Wszystkie projekty

~/tgolab/projekty $ cat raportowanie-bledow.md

Raportowanie błędów

Landingi

Z nieużywanego Sentry do procesu, w którym raportowanie jest domyślne: pełny kontekst każdego błędu i odfiltrowany szum.

Dzwonek alertu obok wykresu błędów przekraczającego próg
Lista błędów aplikacji SPA w Sentry z trendem i liczbą użytkowników
Lista błędów EventTrackera w Sentry
Monitory błędów i metryk w Sentry
Reguły alertów Sentry z powiadomieniami na Slacka i e-mail
1 / 5

Problem

Sentry było w projekcie obecne, ale praktycznie nieużywane — błędy z frontendu nie trafiały do systemu, a o awariach na produkcji zespół dowiadywał się od klientów.

Moja rola

Uporządkowanie obsługi błędów w całej aplikacji SPA i zbudowanie narzędzia, dzięki któremu raportowanie stało się domyślnym zachowaniem, a nie dodatkową pracą.

Co zbudowałem

  • Własna funkcja raportująca, upraszczająca logowanie błędów z frontendu. Podpięta przy każdym pobieraniu danych z backendu — wysyła kod błędu wraz z pełnym kontekstem potrzebnym do debugowania.
  • Wzbogacanie zdarzeń o kontekst: użytkownik, wersja aplikacji, release, breadcrumbs.
  • Filtrowanie szumu — wyciszenie błędów z rozszerzeń przeglądarki, botów i ResizeObservera, dzięki czemu w Sentry zostały wyłącznie zdarzenia, na które warto reagować.
  • Alerty i monitoring błędów w Sentry dla wielu projektów — kilkoma z nich zarządzam na bieżąco.

Efekt

  • Błędy produkcyjne wykrywane szybciej, w części przypadków zanim zgłosi je klient.
  • Krótszy czas debugowania — zgłoszenie zawiera od razu wszystko, co potrzebne, bez odtwarzania sytuacji u siebie.
  • Mniej zgłoszeń trafiających do supportu.