Blog

Gdy słyszę "monitoring aplikacji", pierwszym obrazem w mojej głowie jest centrum dowodzenia NASA i słynne "Huston, mamy problem!". Na szczęście, w przypadku większości aplikacji nie potrzebujemy całego pomieszczenia monitorów i ludzi, by trzymać rękę na pulsie. Zazwyczaj wystarczą dobre narzędzia i odpowiednio skonfigurowane alerty. To taka nasza wersja "Huston, mamy problem!" :)

Być może zastanawiasz się, czy wszystkie aplikacje wymagają monitoringu. Odpowiedź brzmi: Nie, pod warunkiem, że wszystko Ci jedno, czy Twój system działa poprawnie. No ale umówmy się, taki przypadek to wyjątek, który potwierdza regułę. Więc tak, prawdopodobnie potrzebujesz monitorować pracę swojej apki.

Monitorowanie systemów - kiedyś i dziś

Kiedyś monitorowanie systemów było bardzo złożonym i kosztownym procesem. Wszystko trzeba było instalować i konfigurować ręcznie. Firmy IT miały całe działy zajmujące się konfiguracją środowiska do monitorowania aplikacji.

Na szczęście te czasy mamy już za sobą. Dynamiczny rozwój usług w chmurze oraz wejście w erę oprogramowania dostarczanego jako usługa (SaaS) sprawił, że śledzenie podstawowych parametrów aplikacji możemy skonfigurować kilkoma kliknięciami. To spore ułatwienie.

Jak działa takie monitorowanie

W przypadku aplikacji monitorowanie podstawowych parametrów serwera, takich jak obciążenie procesora, czy zajęta pamięć, jest tym samym, co monitorowanie wskaźników życiowych u pacjenta podczas operacji.

Dzięki nim, mamy wstępną wiedzę o kondycji systemu. Niestety te dane nie dają nam pełnego obrazu sytuacji.

Sam fakt, że nasz serwer jest obciążony zaledwie w 5%, może świadczyć zarówno o tym, że wszystko działa perfekcyjnie, jak i o tym, że nasza aplikacja w ogóle nie działa i wszyscy użytkownicy z niej wychodzą.

Jak możemy upewnić się, że wszystko jest w porządku? Będziemy potrzebować dodatkowych informacji. Możemy je uzyskać za pomocą logów z aplikacji.

Logi z aplikacji

Możemy się z nich sporo dowiedzieć, jednak nikt nie będzie siedział i czytał ich na bieżąco. Potrzebujemy "czegoś", co zaalarmuje nas, gdy w działaniu aplikacji wystąpi błąd. O samych błędach pisaliśmy więcej w artykule o testowaniu API. Jeśli jeszcze go nie czytałeś, możesz to zrobić tutaj:

https://kielniakodu.io/pl/blog/jak-bardzo-znajomosc-api-pomaga-w-testach/

Jeśli wiemy jakie błędy potencjalnie mogą wystąpić, możemy ustawić odpowiednie alarmy, które wyślą nam powiadomienie mailem lub sms-em.

Nie znaczy to, że każda nieprawidłowość musi być nam raportowana w ten sposób. Przesadą byłoby wszczynanie alarmu przy każdym błędzie 5xx. Bywa, że problemem nie jest sam błąd, ale częstotliwość jego występowania. Dlatego mamy możliwość ustawienia alarmu w sytuacji, gdy błąd powtarza się np. 5 razy w ciągu minuty. Takie zachowanie aplikacji może sugerować kłopoty i warto powiadomić o tym odpowiednie osoby.

Oczywiście każdy przypadek będzie inny i wiąże się to głównie z ruchem w aplikacji. Musimy znaleźć złoty środek, który pozwoli nam wyłapać problem możliwie szybko, jednak nie angażując wszystkich służb ratunkowych bez potrzeby.

Czasem mniej, znaczy więcej

Gdy wiemy, co chcemy monitorować i ustawimy odpowiednie alarmy, możemy spać spokojnie. Nasza aplikacja działa poprawnie, a kiedy przestanie, odpowiednio wcześnie będziemy o tym wiedzieć.

Jednak monitorować możemy także parametry istotne z punktu widzenia biznesu. Weźmy na przykład aplikację do zamawiania jedzenia. Ważna będzie dla nas ilość zamówień, liczba porzuconych koszyków, błędy w płatnościach, porzucone płatności czy suma zamówień.

Możemy mieć oko na znacznie więcej rzeczy, ale istotne, aby przesyłać tylko najpotrzebniejsze dane, co ułatwi pracę z nimi. Będzie nie tylko bardziej przejrzyście, ale też taniej, bo każda metryka, każdy log aplikacji, to miejsce na dysku, które przecież kosztuje.

Z czego sami korzystamy?

W przypadku wewnętrznych narzędzi, w Kielni Kodu używamy wyłącznie narzędzi dostarczanych natywnie przez AWS. Możemy w nim zdefiniować alarmy, które wysyłają powiadomienia o problemach na zbiorczy adres e-mail. Mówimy tu oczywiście o całym module CloudWatch. Przy niewielkich systemach, gdy klient korzysta już z jakiegoś dostawcy chmury publicznej, te narzędzia są w pełni wystarczające. Dodatkowo są dostępne za niewielką miesięczną opłatą lub wręcz darmowe, jeśli mieścimy się w limitach.

Bardziej złożone systemy, gdzie do monitorowania jest więcej, do tego u różnych dostawców, wymagają użycia narzędzi do zbierania danych z wielu miejsc. Takim narzędziem są, chociażby Grafana czy Prometheus.

Grafana udostępnia wygodną opcję Cloud. Wystarczy, że założymy konto, podepniemy monitorowaną aplikację, skorzystamy z jednego z dostępnych pluginów i gotowe.

Prometheus wymaga więcej wysiłku przy instalacji i konfiguracji, więc nie jest to opcja dla leniwych. Alternatywą dla tych, którzy nie lubią bawić się w konfigurację, jest Datadog. Jeśli damy mu dostęp do naszej chmury, sam utworzy nam podstawowe ekrany do monitoringu infrastruktury i aplikacji.

Bez względu na to, na które narzędzie się zdecydujesz, mam nadzieję, że po przeczytaniu tego artykułu dostrzegasz już, że monitorowanie aplikacji bardzo, ale to bardzo usprawnia pracę.