Logowanie błędów za pomocą Sentry.io

W aplikacjach renderowanych całkowicie po stronie frontendu, błędy logowane są w konsoli przeglądarki - tzn, ze my jako developrzy, mozemy byc ich nie świadomi. Dlatego potrzebujemy dodatkowych narzędzi przechwytujących roznego typu informacji takich jak logi z konsoli przeglądarki w postaci róznej maści błędów. Jednym z takich narzędzi jest Sentry.

Sentry.io

Sentry jest narzędziem do monitorowania błędów oraz ich debugowania. Sentry dostępne jest w modelu SaaS oraz self-hosted. Dla róznych projektów mamy rózne wersje.

https://sentry.macopedia-dev.pl/ (opens new window) http://sentry.io/ (opens new window)

Konfiguracja

Wszystkie potrzebne informacje znajdziemy tutaj https://docs.sentry.io/platforms/javascript/guides/vue/ (opens new window)

W przypadki aplikacji nuxt.js możemy zainstalować moduł, który bardzo ułatwia konfigurację takich tematów jak sourcemaps: https://sentry.nuxtjs.org/ (opens new window)

TIP

Kod JavaScript w wersji produkcyjnej jest najczęściej zminimalizowany, dlatego ważnym etapem konfiguracji sentry jest ustawienie wysyłania plików sourcemap do Sentry - po to aby w przypadku debugowania konkretnych błędów mieć informację o miejscu występowania danego błędu. Więcej tutaj [https://docs.sentry.io/platforms/javascript/sourcemaps/] Sentry pozwala również na konfiguracją releasów, wtedy będziemy mieć potencjalne informacje o tym, z którym wydaniem produkcyjnym otrzymaliśmy jaki błąd.

Debugowanie

Musimy być świadomi, że Sentry.io nie jest narzędziem rozwiązującym błedy czy kociołkiem magika, który wskaże nam drogę do rozwiązania. Sentry należy traktować jako narzędzie logujące oraz udostępniające pewne wskazówki, które mogą być pomocne w przypadku rozwiązywania konkretnych błędów. Wskazówki te występują pod postacią różnej maści zmiennych np.:

• jakim środowisku wystąpił błąd (tutaj uwaga, środowisko należy przekazać w konfiguracji)
• na jakim urlu
• na jakim urządzeniu/przeglądarce/systemie etc.
• jak użytkownik doszedł do konkretnego błędu - w postaci w breadcrumbs
• stack - czyli kolejność wykonania kodu do czasu kiedy wystąpił dany błąd z informacją o tym miejscu.
• dodatkowo mamy możliwośc przekazania własnych zmiennych czy ustawienia kontekstu użytkownika - np. informację o tym, że jest zalogowany.

Najważniejszym krokiem jest odtworzenie błędu, a powyższe wskazówki powinny być drogowskazem. Najłatwiejsze co można zrobić to przejść tę samą ścieżkę, co przeszedł użytkownik, korzystając z breadcrumbsów - są tam zawarte informację o poszczególnych klikach, eventach, zapytaniach itp. Jeżeli dany błąd wystąpił tylko na konkretnym urządzeniu czy przeglądarce, należy użyć Browserstack.

WARNING

Pamiętaj, że nie wszystkie błędy, muszą być wywołane przez nasz kod. Często spotykamy się z sytuacją, kiedy to kod po stronie klienta - dostarczony przez GTM jest niepoprawny - np. korzysta z jQuery ($ is undefined), którego nie mamy załadowanego na stronie. W takim przypadku powinniśmy poinformować klienta o tym fakcie, z prośbą o poprawienie - jednocześnie uświadamiając, że nie możemy dawać gwarancji poprawnego działania aplikacji, jeżeli kod, który nie należy do nas wchodzi w interakcję. Inne potencjalne problemy to wtyczki w przeglądarce np. adblock - tutaj należy też uważać przy debugowaniu, bo jeżeli mamy wlączonego adblocka, a kod, który powoduje błedy pochodzi z GTM - to nie będziemy w stanie takiego błędu odtworzyć.

Więcej informacji o debugowaniu znajdziesz tutaj https://docs.sentry.io/product/sentry-basics/guides/integrate-frontend/generate-first-error/ (opens new window)

Kto, kiedy i jak ?

O logi z sentry dba zespół danego projektu. Każdy z developerów, powinien otrzymywać notyfikację o nowych alertach: https://docs.sentry.io/product/alerts-notifications/ (opens new window)

Jeżeli do projektu mamy przypisanych testerów, to również oni powinni tam zaglądać, starając się odtworzyć bład i z jasną informacją wrzucić go na tablice projektu. To samo może starać się wykonać ProjectManager - lub ewentualnie pozbierać najważniejsze błędy.

Nie łatwo jest doprowadzić projekt do stanu w którym pozbędziemy się wszystkich błędów. Jako priorytet uważam, że powinniśmy dbać o alerty z największą liczbą wystąpień - ponieważ to znaczy, że potencjalny błąd dotyka większej liczby użytkowników. Sentry na widoku listy alertów pozwala nam posortować je wg priorytetu - najczęściej będzie to liczba wystąpień.

Sentry pozwala również na filtrowanie błędów - jeżeli wiemy, że nie wspieramy danej przeglądarki, powinniśmy ją odfiltrować. https://blog.sentry.io/2017/01/12/browser-filters (opens new window)

Duża liczba błędów może być zduplikowana, dlatego warto je mergować.

TIP

Ważne aby po rozwiązaniu błedu oznaczyć go jako rozwiązany: