Logger w aplikacji

nie mylić z logowaniem (uwierzytelnianiem)

Piotr Wandycz

Jakiego frameworka używasz do zapisywania logów?

To było jedno z pytań, jakie zadał mi Maciek na rozmowie kwalifikacyjnej. Wtedy jeszcze zapisywałem zdarzenia po prostu do pliku, jeśli już w ogóle to robiłem. Co ciekawe, nie przypominam sobie innej rozmowy o pracę, gdzie ktoś by mnie o to zapytał. A przecież logger to podstawowe narzędzie przy pracy programisty. Pytanie o logowanie powinno być standardem w branży. Jeżeli to na mnie trafisz na rekrutacji, to na pewno znajdziesz kilka pytań na ten temat 🙂

Po co mi logi?

Pierwsze starty rakiet Falcon 1 były bardzo efektowne. Wyobraź sobie, że widzisz eksplodujące kilka milionów dolarów włożone w rakietę, nie wiedząc – co się stało. To jeszcze przebolejesz, bo masz budżet na dwie kolejne próby. Ale jeśli nie możesz przeanalizować, co poszło nie tak, bo nie masz logów? Cóż, pewnie porzucisz marzenie o wysłaniu człowieka na Marsa dość szybko.

W codziennej pracy raczej nie mamy tak spektakularnych widoków. Jeśli coś “wybucha na produkcji” to jest to raczej metafora, niż wizualny efekt. Nie mniej, błędy się zdarzają i naszym obowiązkiem jest prześledzenie krok po kroku, co się wydarzyło. Dorzucenie dodatkowej linijki kodu informującej o akcji użytkownika nic nas nie kosztuje w czasie developmentu. Natomiast już po fakcie, brak logów może wygenerować spore koszty.

Czasami jest tak, że w sumie to nic się nie zepsuło, ale aplikacja zaczęła wolniej chodzić. Wtedy możemy sobie porównać stan logów sprzed wdrożenia feralnej wersji aplikacji i po nim. Tutaj w sumie mamy dwie opcje, które przychodzą mi do głowy. Ręczne mierzenie czasu każdej akcji, oraz wbudowanie rozwiązania w infrastrukturę. W przyszłości będę pokazywał jak w prosty sposób utworzyć coś w stylu obrazka z góry artykułu. Mając jedno miejsce, przez które przechodzi każde Query i Command w aplikacji, bez problemu można dodać mierzenie czasu wykonania, nie musząc o tym pamiętać podczas implementowania kolejnych klas.

Poziomy logowania

Ta sprawa zależy już od specyfiki wybranej przez nas biblioteki. Zawsze należy sprawdzić – jakimi poziomami logowania dysponujemy oraz jak są one stopniowane. W konfiguracji loggera wskazujemy na minimalny poziom, od którego chcemy przechwytywać logi. Dla przykładu: wpisując tam Warning wszystkie logi z kategorii Warning < Error < Fatal zostaną zapisane do logu. Czasem zdarza się, że jeden twórca umieści Info niżej od Debug. A inny ma jeszcze dodatkowo Trace i stopniuje sobie Trace < Debug < Information. Pamiętaj o sprawdzeniu hierarchii poziomów w dokumentacji dostawcy biblioteki (log levels).

Ogólny podział zrobiłbym w zależności od środowiska. Na developerskim loguj ile się da. Wykorzystaj dostępne Trace i Debug. Na środowiskach testowych – zarówno wewnątrz firmy, jak i u klienta – wystarczy Info albo od Warning. Logowanie na produkcji poniżej poziomu Warning raczej nie ma sensu. Tam potrzebujemy mieć porządek.

Jeśli chodzi o to co wrzucić do Warning – to może być dobre miejsce dla czasów wykonywania akcji. W Error sprawa jest prosta – trafiają tutaj wyjątki. Istnieje jeszcze poziom Fatal na przypał na najwyższym poziomie. Hmm, jeśli coś wskoczy tak wysoko, to może powinno się automatycznie wysyłać się na maila.

Zródła (sink/target)

Dosłowne tłumaczenie słów z nagłówka kiepsko by tu brzmiało, więc będę się posługiwał terminem: źródło logowania. Nie ma co się tu rozpisywać – to po prostu miejsce, gdzie trafiają logi. Jednym z najprostszych i prawdopodobnie najpopularniejszym z nich jest zapis do pliku. Przy wyborze źródła logowania raczej nic nas nie ogranicza. Jeśli chcemy, zapisywać możemy do bazy danych, konsoli, streamu, Azure czy nawet wysyłać maile z logami. Dobrą praktyką jest powiązanie źródła z konfiguracją aplikacji. Dzięki temu np. na środowisku deweloperskim możemy mieć dodatkowy zapis do konsoli, żeby nie męczyć się z plikami.

Ciekawą opcją jest też wzbogacanie logów (enrich). Wystarczy dopisać jedną linijkę kodu, żeby widzieć u siebie np. wszystkie logi generowane przez framework Asp.Net MVC. W następnym tygodniu pokażę Ci, jak banalna jest konfiguracja loggera – na przykładzie biblioteki Serilog. Zrobię to od razu w połączeniu z odczytem ustawień z konfiguracji (appsettings.json).

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *