Po co mi logi? Przecież wszystko na develu działa

Aplikacje, które wytwarzamy zawsze mają i będą mieć nieobsłużone wszystkie przypadki użycia, błędy czy wyjątki. Nawet najlepsze testy nie pozwalają pozbyć się 100% przypadków. Kiedy coś pójdzie nie tak, także idealnie napisany kod może mieć problemy z połączeniem z innym serwisem czy bazą danych i co wtedy? Skąd mamy o tym wiedzieć? Jak zlokalizować problem i usunąć przyczynę?

Maciej Rynkiewicz. Software Development Manager w Wakacje.pl. Inżynier z zamiłowaniem do pracy twórczej, programista, architekt systemów i lider. Potrafi zrozumieć potrzeby biznesu i znaleźć rozwiązanie dobre dla wszystkich. Zawsze stawia na zespół, w którym pracuje i transparentną relację. Ma kilkanaście lat doświadczenia w branży IT, w której zaliczył niejedną porażkę, ale odniósł też wiele sukcesów.

W większości sytuacji jesteśmy przyzwyczajeni do logów „negatywnych”, czyli takich, które pokazują nam jakiś błąd, awarię, nieprawidłowe działania powodujące przerwanie działania aplikacji. Tu nasuwa się pytanie: jak weryfikować anomalie, które jeszcze błędem nie są a efekty ich będą widoczne za jakiś czas. To „prawidłowe” działanie aplikacji jest często dla nas groźniejsze i istnieje ryzyko, że dowiemy się o tym od naszego użytkownika, a w bazie danych będziemy mieć już niezły bałagan. Żeby temu zapobiec musimy wiedzieć o naszym systemie więcej.

Nasz monitoring systemu musi odpowiadać na konkretne pytania, które pozwolą nam ocenić sytuację:

1. Czy aplikacja realizuje procesy biznesowe (log ogólny)?

• Opis: musimy mieć pewność, że to po co napisaliśmy naszą aplikację jest realizowane np. sprzedaż produktów czy świadczenie usług, to powinien być wskaźnik ogólny, który odpowie nam ostatecznie: 1 lub 0 – działa lub nie działa.
• Jak mierzyć: wystarczy sprawdzać, kiedy ostatni raz był akcja po stronie użytkownika, dzięki której możemy stwierdzić że „wszystko działa”.
• Zagrożenia: musimy dokładnie wiedzieć, co jest efektem oczekiwanym np. to że udało się przez aplikację sprzedać 1 sztukę towaru, ale nie mamy pojęcia, że 99 klientów właśnie skończyło zamówienie z błędem 500.

2. Czy aktualny stan aplikacji jest zgodny z oczekiwanym?

• Opis: mając dobre logi uczymy się monitorować nasz system, pewne schematy powtarzają się i łatwo znaleźć moment, kiedy trafimy w anomalię.
• Jak mierzyć: dobrze jest mieć kilka czynników, które składają się na jeden obraz, np. ilość logowań, zamówień, czy klientów online. Wymaga to jednak od nas stałej kontroli tego, co dzieje się z naszym systemem.
• Zagrożenia: musimy pamiętać o wszelkich sytuacjami wpływającymi na biznes, tak samo znać plany akcji (np. promocyjnych) w firmie, dla której pracujemy.

3. Czy aplikacja „sypie” błędami?

• Opis: jeśli nasz error handler nagle zaczął sypać błędami, to każdy developer wie, że to zły znak… 😉
• Jak mierzyć: konieczne jest zbieranie błędów aplikacji i notyfikacje, tak żeby to IT wiedziało szybciej o problemie niż użytkownik końcowy
• Zagrożenia: jeśli ilość błędów w danym momencie będzie gigantyczna (np. tysiące na sekundę) to warto przemyśleć system alertowania błędów – wysyłanie e-maila czy sms’a to nie najlepszy pomysł w tym przypadku.

4. Czy infrastruktura nie jest przeciążona?

• Opis: warto wiedzieć co dzieje się z naszym serwerem, bazą danych czy siecią – często to nie błędy aplikacji powodują awarie, a nie dostępne usługi lub sprzęt.
• Jak mierzyć: na rynku dostępnych jest dużo rozwiązań zarówno open source, jak i komercyjnych aplikacji, umożliwiających podgląd live tego dzieje się z naszym system.
• Zagrożenia: zewnętrzne usługi można zapchać przy dużej ilości awarii i wymaga to wysyłania danych poza naszą firmę, z drugiej strony rozwiązania możliwe do postawienia lokalnie trzeba samemu utrzymywać.

5. Czy wszystkie usługi, z których korzystamy są dostępne?

• Opis: jeśli twoja aplikacja musi korzystać z zewnętrznych serwisów, aplikacji, api czy baz danych to musisz wiedzieć czy działają zgodnie z Twoim oczekiwaniem.
• Jaki mierzyć: wystarczy sprawdzać czy komunikacja z ostatniego czasu jest prawidłowa, w momencie jak zaczną występować błędne odpowiedzi musisz o tym się natychmiast dowiedzieć.
• Zagrożenia: im więcej zależności zewnętrznych, tym utrzymanie staje się trudniejsze, coraz więcej nie zależy od naszego zespołu – warto w takiej sytuacji mieć dobrą relację z osobami utrzymującymi systemy, z którym się komunikujemy.

6. Czy poszczególne funkcjonalności działają prawidłowo?

• Opis: działanie każdej funkcjonalności można mierzyć, wymaga to jednak od nas obserwacji i nauki, tak żeby wiedzieć czego się spodziewać po jakimś czasie i co może być dla nas niepokojące np. mamy aktywność użytkowników na poziomie 10% tego czego się spodziewaliśmy.
• Jak mierzyć: tu w zależności od tego co mierzymy możliwości mamy duży, od logów w pliku, przez różnego rodzaju bazy danych.
• Zagrożenia: czasem błąd nie leży po stronie aplikacji, ale tu najszybciej wyjdą efekty np. wygaśnięcia kampanii reklamowej – dlatego warto wiedzieć co planuje nasz biznes.

7. Czy w bazie danych posiadamy nieprawidłowe dane?

• Opis: tego typu monitoring dodajemy raczej w momencie znalezienia błędu w danych, który nie wiemy z czego wynika, wtedy najłatwiej jest zacząć od monitorowania danego przypadku, tak aby docelowo dowiedzieć się z czego to wynika.
• Jak mierzyć: samo monitorowanie polega na wyciąganiu i raportowaniu takich przypadków, zazwyczaj jednak dodajemy do tego dodatkowe „debugi”, które pomogą nam zlokalizować przyczynę.
• Zagrożenia: to zawsze mało komfortowa sytuacja, kiedy wiemy. że coś poszło nie tak, ale nie wiem dlaczego, gorzej jeśli taka sytuacja spowodowana jest przez „coś” innego niż nasza aplikacja. Powyższy opis jest raczej zestawieniem pytań jakie warto sobie zadać, po to żeby mieć większą świadomość tego co robi nasza aplikacja.

Wiedząc już co chcemy logować poświęćmy kilka zdań na to, gdzie przechowywać logi i jak je wizualizować. Aktualnie najbardziej popularnymi sposobami do przechowywania logów są nierelacyjne bazy danych takie jak np.: MongoDb czy ElasticSearch, przy małych ilościach danych możemy oczywiście trzymać takie dane także w bazach relacyjnych, jednak jest to dużo mniej wydajniejsze. Mamy do dyspozycji także pliki tekstowe, ale wizualizacja tych danych bez przetwarzania jest raczej trudna.

Żeby nasze logi nie były tylko megabajtami na dysku warto zadbać o ich przystępną formę, tu najbardziej popularnymi rozwiązaniami są aplikacje takie jak np.: Grafana, Kibana, czy Graphite – ale to wątek raczej na oddzielny artykuł, którego nie będę teraz rozwijał. Na koniec warto pomyśleć nad tym jak długo chcemy takie dane trzymać – pierwsza myśl jest zawsze taka sama – lifetime, przecież dyski są tanie. Tylko po co nam logi, z których nie korzystamy już od dawna?

Zbieranie logów z aplikacji powinno być dla developerów rzeczą normalną, ale oczywiste to staje się dopiero wtedy, kiedy muszą oni utrzymywać to, co sami stworzyli i debugować własne błędy. Warto pomyśleć już na początku, podczas projektowania funkcjonalności, co będziemy chcieli wiedzieć o tym, co dzieje się w naszym systemie. Ostatnim elementem tej układanki jest przystępna forma prezentacji i komunikacji, czyli prezentacja logów w formie wykresów i raportów, ale to już osobny temat rzeka.

Zdjęcie główne artykułu pochodzi z pexels.com.

Oferty pracy z