Jak wygląda zgłoszenie błędu?
Dobre zgłoszenie błędu powinno odpowiadać nie tylko na pytanie co się zepsuło, ale również pomagać ustalić gdzie i w jakich warunkach problem wystąpił.
Dlatego poza samym komunikatem wyjątku możesz przekazywać między innymi stack trace, informacje o żądaniu, użytkowniku, środowisku oraz dodatkowy kontekst aplikacji.
Wyjątek i stack trace
Najważniejszą częścią zdarzenia jest wyjątek. Typ błędu i jego komunikat opisują problem, natomiast stack trace pokazuje ścieżkę wykonania kodu, która doprowadziła do jego wystąpienia.
W praktyce właśnie stack trace często pozwala przejść od ogólnego komunikatu do konkretnego miejsca w kodzie.
Informacje o żądaniu
Jeżeli błąd wystąpił podczas obsługi żądania HTTP, dodatkowy kontekst może zawierać adres, metodę, status odpowiedzi oraz wybrane informacje związane z requestem.
Dzięki temu łatwiej ustalić, czy problem dotyczy konkretnego endpointu, formularza, strony albo operacji wykonywanej przez użytkownika.
Użytkownik i kontekst
W zależności od używanej integracji możesz przekazać również informacje o użytkowniku oraz własne tagi i dane kontekstowe. Pozwala to odpowiedzieć na pytania takie jak: którego użytkownika dotyczył błąd, którego modułu dotyczył problem albo w jakim środowisku został wykryty.
Przy danych użytkownika zawsze warto stosować zasadę minimalizacji. Wysyłaj tylko informacje, które są rzeczywiście potrzebne do diagnozy.
Własne dane aplikacji
Jeżeli standardowy kontekst nie wystarcza, możesz wzbogacić zdarzenie o własne tagi. Przykładowo możesz oznaczyć błędy związane z płatnościami, konkretnym modułem albo wersją wdrożenia.
feature = payments
environment = production
release = 1.4.0Nie wysyłaj sekretów
Monitoring błędów nie powinien być miejscem do przesyłania haseł, tokenów, kluczy API czy pełnych danych uwierzytelniających. Przed wysłaniem danych warto sprawdzić, czy integracja nie przekazuje przypadkowo informacji wrażliwych.