Monitoring aplikacji produkcyjnej — co logować i kiedy alarmować

Najgorszy sposób dowiedzenia się o awarii to wiadomość od klienta. Niewiele lepszy — przejrzenie dziennika tydzień po fakcie i odkrycie, że formularz zamówień przestał działać w piątek wieczorem. Monitoring nie polega na zbieraniu jak największej ilości danych, lecz na tym, żeby o problemie wiedzieć przed użytkownikami i mieć informacje pozwalające ustalić przyczynę w minuty, a nie w godziny.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Cztery filary

Dostępność sprawdzana z zewnątrz

Najprostszy element i ten, którego brak kosztuje najwięcej. Zewnętrzna usługa co minutę odpytuje aplikację i powiadamia, gdy przestaje odpowiadać. Nie wymaga zmian w kodzie i działa nawet wtedy, gdy cała infrastruktura aplikacji leży.

• Sprawdzaj z innej infrastruktury niż ta, na której działa aplikacja — monitoring na tym samym serwerze padnie razem z nim.
• Sprawdzaj kluczowe ścieżki, nie tylko stronę główną. Strona główna potrafi działać, gdy zamówienia już nie.
• Przygotuj punkt kontrolny zdrowia, który weryfikuje połączenie z bazą i usługami zależnymi, a nie tylko zwraca odpowiedź.
• Sprawdzaj z kilku lokalizacji i alarmuj dopiero przy potwierdzeniu z więcej niż jednej — to eliminuje fałszywe alarmy z problemów sieciowych.
• Monitoruj datę wygaśnięcia certyfikatu — to przyczyna awarii, której da się uniknąć w stu procentach.

Śledzenie błędów

Dziennik pełen komunikatów o błędach jest mało użyteczny, jeśli nie da się ustalić, ile osób dotyczy problem, od kiedy występuje i w jakim kontekście. Narzędzia do śledzenia błędów grupują identyczne wyjątki, liczą wystąpienia i zapisują kontekst.

Przy każdym błędzie warto mieć: pełny ślad wykonania, wersję aplikacji, w której wystąpił, adres i parametry żądania, identyfikator użytkownika lub sesji, przeglądarkę albo urządzenie oraz czas pierwszego i ostatniego wystąpienia.

Metryki, które faktycznie mają znaczenie

Można mierzyć setki wskaźników. W praktyce o zdrowiu aplikacji mówi kilka, pogrupowanych wokół tego, co odczuwa użytkownik.

• Czas odpowiedzi — nie średnia, lecz wartości dla wolniejszych żądań. Średnia ukrywa to, że co dziesiąty użytkownik czeka kilka sekund.
• Odsetek błędów — stosunek odpowiedzi błędnych do wszystkich. Nagły wzrost jest najpewniejszym sygnałem problemu po wdrożeniu.
• Natężenie ruchu — liczba żądań w czasie. Nagły spadek bywa ważniejszy niż wzrost, bo może oznaczać, że użytkownicy nie są w stanie dotrzeć do aplikacji.
• Nasycenie zasobów — procesor, pamięć, połączenia z bazą, miejsce na dysku. Pozwala przewidzieć problem, zanim wystąpi.
• Metryki biznesowe — liczba zamówień, rejestracji, wysłanych formularzy w godzinie. Często wykrywają problem, którego nie widać w metrykach technicznych.

Ta ostatnia kategoria bywa najcenniejsza. Aplikacja może odpowiadać szybko i bez błędów, a jednocześnie od trzech godzin nie przyjąć żadnego zamówienia, bo zewnętrzna bramka płatnicza zwraca odpowiedź, którą kod interpretuje jako sukces.

Dzienniki — co zapisywać

Dziennik ma pozwolić odtworzyć przebieg zdarzeń, gdy coś pójdzie nie tak. Ani zbyt skąpy, ani zalewający szczegółami, w których nie da się niczego znaleźć.

Kluczowa praktyka to identyfikator żądania: jeden znacznik nadawany na początku operacji i dopisywany do każdego wpisu z nią związanego. Pozwala on wyfiltrować z milionów linii dokładnie te, które dotyczą zgłoszonego problemu. Przy systemach wykonujących pracę w tle — opisanych w materiale o kolejkach zadań — identyfikator warto przekazywać także do zadań asynchronicznych.

Warto też zapisywać w formacie strukturalnym, a nie jako swobodny tekst. Wpis z wyodrębnionymi polami da się przeszukiwać i agregować; zdanie opisowe — tylko czytać.

Alerty, które nie męczą

Zmęczenie alarmami jest realnym zagrożeniem dla niezawodności. Zespół, który codziennie dostaje kilkadziesiąt powiadomień, przestaje je czytać — a wtedy pierwszy prawdziwy alarm ginie w szumie.

• Alarmuj o objawach, nie o przyczynach. „Użytkownicy dostają błędy" jest ważniejsze niż „procesor osiągnął wysokie obciążenie", które może nie mieć żadnego skutku.
• Każdy alert musi wymagać działania. Jeśli reakcja brzmi „poczekajmy, samo przejdzie", to nie jest alert, tylko wpis w raporcie.
• Rozdziel pilność. Awaria kluczowej funkcji — powiadomienie natychmiastowe. Rosnące zajęcie dysku — wiadomość w godzinach pracy.
• Dołączaj kontekst. Alert powinien mówić, co się dzieje, od kiedy i gdzie szukać przyczyny.
• Przeglądaj alerty regularnie. Te, które nie prowadziły do żadnego działania, trzeba usunąć albo zmienić próg.
• Wymagaj utrzymania stanu, zanim alarm zostanie wysłany — chwilowy skok nie powinien nikogo budzić.

Monitoring a wdrożenia

Znacząca część awarii zaczyna się w momencie wdrożenia nowej wersji. Warto więc oznaczać wdrożenia na wykresach metryk — nagły wzrost odsetka błędów zbieżny z oznaczeniem od razu wskazuje przyczynę.

Po każdym wdrożeniu dobrze jest przez kilkanaście minut obserwować metryki zdrowia i porównywać je z okresem sprzed zmiany. Przy dojrzalszym procesie tę obserwację można zautomatyzować i wycofywać wersję samoczynnie, gdy odsetek błędów przekroczy ustalony próg. O samym procesie wdrażania piszemy w materiale o CI/CD dla małego zespołu.

Od czego zacząć

• Zewnętrzne sprawdzanie dostępności kluczowych ścieżek — pierwszy dzień, bez zmian w kodzie.
• Monitoring wygaśnięcia certyfikatu i domeny.
• Narzędzie do śledzenia błędów z maskowaniem danych wrażliwych.
• Identyfikator żądania w dziennikach i format strukturalny.
• Jedna metryka biznesowa z alertem przy nietypowym spadku — najczęściej liczba zamówień lub zgłoszeń.
• Czas odpowiedzi i odsetek błędów z oznaczeniem wdrożeń.
• Przegląd alertów raz w miesiącu i usuwanie tych, które nie prowadziły do działania.

Co robić, gdy alert już przyszedł

Monitoring kończy się w momencie wysłania powiadomienia. To, co dzieje się dalej, decyduje o czasie niedostępności bardziej niż jakość samych narzędzi.

Najpierw przywróć działanie, potem szukaj przyczyny

Jeśli problem pojawił się po wdrożeniu, wycofanie wersji jest zwykle szybsze niż diagnoza. Przyczynę ustalisz spokojnie, gdy użytkownicy znowu mogą pracować.

Jedna osoba koordynuje

Przy poważniejszej awarii kilka osób równolegle próbujących „coś sprawdzić" potrafi pogorszyć sytuację. Warto z góry ustalić, kto przejmuje koordynację i kto komunikuje się z klientami.

Zapisuj przebieg na bieżąco

Godzina wykrycia, podjęte działania, godzina przywrócenia. Po fakcie trudno odtworzyć kolejność zdarzeń, a bez niej nie da się rzetelnie ustalić przyczyny.

Omówienie bez szukania winnych

Po każdym istotnym incydencie krótka analiza: co się stało, dlaczego monitoring wykrył to wtedy, a nie wcześniej, i jaka jedna zmiana zapobiegnie powtórce. Nacisk na to, kto zawinił, prowadzi do ukrywania problemów — a ukryte problemy wracają.

Warto też pamiętać, że monitoring sam wymaga monitorowania. Usługa sprawdzająca dostępność, która przestała działać, milczy dokładnie tak samo jak ta, która nie wykryła żadnego problemu. Prosty test wysłania alertu raz w miesiącu potwierdza, że cały łańcuch — od wykrycia po powiadomienie — nadal działa.

Kilka minut raz w miesiącu wystarczy, żeby mieć pewność, że alerty naprawdę dotrą do właściwej osoby.

Podsumowanie

Dobry monitoring nie jest zbiorem wszystkich możliwych danych, lecz odpowiedzią na trzy pytania: czy aplikacja działa, co się zepsuło i dlaczego. Najwięcej daje najprostszy element — zewnętrzne sprawdzanie dostępności kluczowych ścieżek — który wdraża się w godzinę i bez ingerencji w kod.

Jeśli dziś o awariach dowiadujesz się od klientów, zacznij od tego jednego kroku i dodaj alert przy nietypowym spadku liczby zamówień albo zgłoszeń. Te dwie rzeczy wykrywają zdecydowaną większość poważnych problemów, zanim ktokolwiek zdąży zadzwonić. Szerzej o budowie niezawodnych systemów przeczytasz na stronie aplikacje webowe.