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.
Krótka odpowiedź: monitoring aplikacji opiera się na czterech filarach: sprawdzaniu dostępności z zewnątrz, śledzeniu błędów z pełnym kontekstem, metrykach opisujących zdrowie systemu oraz dziennikach pozwalających odtworzyć przebieg zdarzeń.
Najważniejsza zasada dotyczy alertów: powiadomienie powinno przychodzić tylko wtedy, gdy wymaga działania człowieka. System, który alarmuje kilkadziesiąt razy dziennie, jest po tygodniu ignorowany — razem z alarmem, który naprawdę ma znaczenie.
Cztery filary
| Filar | Odpowiada na pytanie | Przykład | Priorytet wdrożenia |
|---|---|---|---|
| Dostępność z zewnątrz | Czy aplikacja w ogóle działa? | Zapytanie co minutę z innej lokalizacji | Pierwszy — najprostszy i najważniejszy |
| Śledzenie błędów | Co się zepsuło i u kogo? | Wyjątek z pełnym śladem wykonania | Drugi |
| Metryki | Czy system jest zdrowy? | Czas odpowiedzi, odsetek błędów, obciążenie | Trzeci |
| Dzienniki | Co dokładnie się wydarzyło? | Przebieg konkretnego zamówienia | Równolegle, od początku |
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.
Uwaga praktyczna: kontekst błędu łatwo zamienia się w wyciek danych. Zanim wyślesz dane żądania do zewnętrznego narzędzia, upewnij się, że hasła, numery kart, tokeny i dane osobowe są maskowane. Narzędzie do śledzenia błędów nie powinno stać się miejscem, w którym leżą dane uwierzytelniające Twoich klientów.
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źć.
| Zapisuj | Nie zapisuj |
|---|---|
| Zdarzenia biznesowe: złożenie zamówienia, zmiana statusu, płatność | Hasła, tokeny, klucze dostępu |
| Wywołania usług zewnętrznych z czasem i wynikiem | Pełne numery kart i rachunków |
| Błędy i ostrzeżenia z kontekstem | Pełną treść dokumentów klientów |
| Logowania i zmiany uprawnień | Każde pojedyncze zapytanie do bazy na produkcji |
| Identyfikator żądania łączący wpisy z jednej operacji | Dane osobowe bez uzasadnionej potrzeby |
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.
Najczęstsze pytania
Od zewnętrznego sprawdzania dostępności kluczowych ścieżek, wykonywanego z innej infrastruktury niż ta, na której działa aplikacja. Nie wymaga zmian w kodzie, wdraża się je w godzinę i wykrywa najpoważniejsze awarie. Następnie warto dodać monitoring certyfikatu i narzędzie do śledzenia błędów.
Zdarzenia biznesowe, wywołania usług zewnętrznych z czasem i wynikiem, błędy z kontekstem, logowania i zmiany uprawnień oraz identyfikator żądania łączący wpisy z jednej operacji. Nie należy zapisywać haseł, tokenów, pełnych numerów kart ani danych osobowych bez uzasadnionej potrzeby.
Alarmować o objawach odczuwanych przez użytkowników, a nie o przyczynach technicznych, wysyłać powiadomienia wyłącznie wtedy, gdy wymagają działania, rozdzielać pilność, wymagać utrzymania stanu przed alarmem oraz regularnie usuwać alerty, które nie prowadziły do żadnej reakcji.
Bo wykrywają problemy niewidoczne w metrykach technicznych. Aplikacja może odpowiadać szybko i bez błędów, a jednocześnie nie przyjmować zamówień, gdy zewnętrzna usługa zwraca odpowiedź interpretowaną przez kod jako sukces. Nietypowy spadek liczby zamówień to jeden z najpewniejszych sygnałów awarii.
Oznaczać wdrożenia na wykresach metryk i przez kilkanaście minut po każdej zmianie porównywać odsetek błędów oraz czas odpowiedzi z okresem sprzed wdrożenia. Przy dojrzalszym procesie można automatycznie wycofywać wersję po przekroczeniu ustalonego progu błędów.
Bezpłatna wycena Twojego projektu
Opisz w kilku zdaniach, co chcesz zbudować — stronę, aplikację czy sklep. Odpowiadamy w ciągu 24 godzin roboczych konkretną propozycją zakresu i harmonogramu. Konsultacja i wycena są bezpłatne, bez zobowiązań.