Co monitorować na stronie i w aplikacji? Praktyczna lista od uptime po błędy i wydajność

CPU, RAM, load average, kontenery, procesy, requesty, błędy, logi, kolejki, bazę danych, DNS, SSL, API, uptime, czasy odpowiedzi, Core Web Vitals i wiele innych.

Problem polega na tym, że większa liczba monitorowanych metryk nie musi oznaczać lepszego monitoringu.

W praktyce najważniejsze jest wykrywanie problemów, które rzeczywiście wpływają na użytkowników lub biznes.

Dlatego zamiast zaczynać od pytania:

„Co możemy mierzyć?”

lepiej zapytać:

„O jakich problemach chcemy dowiedzieć się, zanim poinformuje nas o nich klient?”

1. Czy strona w ogóle działa?

To najbardziej podstawowy poziom monitoringu.

Zewnętrzny system regularnie wysyła żądanie do strony i sprawdza, czy otrzymuje prawidłową odpowiedź.

Pozwala wykryć między innymi:

• HTTP 500,
• HTTP 502,
• HTTP 503,
• timeout,
• brak możliwości nawiązania połączenia,
• problemy z DNS,
• błędne przekierowania.

To klasyczny uptime monitoring.

Jeżeli strona jest sprawdzana co minutę, problem można potencjalnie wykryć w ciągu około minuty zamiast czekać, aż ktoś przypadkiem wejdzie na stronę i zgłosi awarię.

Ale sam uptime to dopiero początek.

2. Czy strona odpowiada wystarczająco szybko?

Strona może być dostępna i jednocześnie bardzo wolna.

Dlatego przy każdym sprawdzeniu warto zapisywać również czas odpowiedzi.

Załóżmy, że aplikacja przez większość czasu odpowiada w:

250-400 ms

Nagle zaczyna odpowiadać w:

1.8-3.5 s

Nie mamy jeszcze pełnego downtime.

Mamy jednak wyraźną zmianę zachowania systemu.

Może to oznaczać:

• przeciążenie serwera,
• problem z bazą danych,
• wolne zewnętrzne API,
• wyczerpanie dostępnych workerów,
• problem z cache,
• zmianę po ostatnim deploymencie.

Monitoring czasu odpowiedzi może więc wykryć problem wcześniej niż klasyczny alert o niedostępności.

3. Czy pogorszenie jest chwilowe, czy trwałe?

Pojedynczy wolniejszy request nie musi oznaczać problemu.

Internet nie jest środowiskiem całkowicie deterministycznym.

Dlatego zamiast reagować na każdą pojedynczą anomalię, warto analizować zachowanie w czasie.

Przykładowo:

10:00 - 320 ms
10:01 - 340 ms
10:02 - 310 ms
10:03 - 870 ms
10:04 - 350 ms

Pojedyncze 870 ms prawdopodobnie nie jest powodem do alarmu.

Ale:

10:00 - 320 ms
10:01 - 510 ms
10:02 - 840 ms
10:03 - 1.3 s
10:04 - 2.1 s
10:05 - 3.4 s

pokazuje już wyraźny trend.

Dobry monitoring powinien pomagać odróżnić chwilowe odchylenie od rzeczywistej degradacji usługi.

4. Czy certyfikat SSL jest ważny?

Certyfikat SSL jest jednym z najprostszych elementów do monitorowania.

I jednocześnie jednym z tych, o których bardzo łatwo zapomnieć.

Problem z certyfikatem może spowodować, że użytkownik zobaczy komunikat bezpieczeństwa zamiast strony.

W przypadku sklepu lub aplikacji może to praktycznie zatrzymać ruch.

Dlatego monitoring powinien sprawdzać:

• czy certyfikat jest prawidłowy,
• kiedy wygasa,
• czy domena certyfikatu jest prawidłowa,
• czy można prawidłowo ustanowić połączenie HTTPS.

Najważniejszą zaletą takiego monitoringu jest możliwość reakcji przed awarią.

Nie trzeba czekać, aż certyfikat wygaśnie.

Alert może pojawić się odpowiednio wcześniej.

5. Czy aplikacja generuje błędy?

Zewnętrzny monitoring pokazuje aplikację z perspektywy użytkownika.

Error monitoring pokazuje ją od środka.

Jeżeli aplikacja generuje wyjątek:

PaymentException

albo:

DatabaseConnectionException

warto wiedzieć o tym niezależnie od tego, czy homepage nadal odpowiada kodem 200.

Sam komunikat błędu również często nie wystarcza.

Znacznie bardziej przydatny jest kontekst:

• gdzie wystąpił błąd,
• kiedy wystąpił po raz pierwszy,
• kiedy wystąpił ostatnio,
• ile razy wystąpił,
• jaka wersja aplikacji była wdrożona,
• jaki endpoint był wykonywany,
• jaki jest stack trace,
• czy liczba wystąpień rośnie.

To pozwala przejść od:

„mamy błąd”

do:

„wiemy, gdzie zacząć go szukać”.

6. Nie każdy błąd jest równie ważny

Załóżmy, że system zarejestrował dwa wyjątki.

Pierwszy:

5 wystąpień przez 30 dni

Drugi:

5 000 wystąpień w ciągu ostatnich 20 minut

Technicznie oba mogą reprezentować dokładnie ten sam typ wyjątku.

Operacyjnie są to jednak zupełnie inne sytuacje.

Dlatego przy monitoringu błędów ważna jest nie tylko informacja:

„jaki błąd wystąpił?”

ale również:

„jak zmienia się częstotliwość jego występowania?”

Nagły wzrost liczby błędów po wdrożeniu nowej wersji może być znacznie ważniejszy niż sam fakt istnienia danego wyjątku.

7. Czy wdrożenie nowej wersji coś zepsuło?

Jednym z najbardziej wartościowych zastosowań monitoringu jest obserwowanie aplikacji bezpośrednio po deploymencie.

Wyobraźmy sobie:

14:02 - deployment version 2.18.4
14:05 - pierwsze nowe błędy
14:07 - 120 błędów
14:10 - 640 błędów

Bez informacji o wersji aplikacji widzimy jedynie wzrost błędów.

Jeżeli monitoring zna release, otrzymujemy znacznie więcej kontekstu:

problemy rozpoczęły się kilka minut po wdrożeniu wersji 2.18.4.

Nie oznacza to automatycznie, że deployment jest przyczyną.

Ale jest to bardzo istotna wskazówka diagnostyczna.

8. Czy strona jest szybka dla użytkownika?

Czas odpowiedzi serwera i szybkość działania strony w przeglądarce to nie to samo.

Serwer może zwrócić HTML w 150 ms, ale strona może nadal ładować:

• duże obrazy,
• JavaScript,
• fonty,
• reklamy,
• skrypty analityczne,
• zewnętrzne widgety.

Dlatego warto obserwować również wydajność strony.

Jednym ze standardowych punktów odniesienia są Core Web Vitals.

LCP - Largest Contentful Paint

Mierzy, jak szybko pojawia się główny element treści strony.

INP - Interaction to Next Paint

Mierzy responsywność strony po interakcji użytkownika.

Kliknięcie przycisku, wybór opcji czy wpisanie danych może wyglądać na „zepsute”, jeśli przeglądarka reaguje z dużym opóźnieniem.

Za dobry wynik INP uznaje się wartość do 200 ms na 75. percentylu.

CLS - Cumulative Layout Shift

Mierzy nieoczekiwane przesunięcia elementów podczas korzystania ze strony.

Przykładowo użytkownik chce kliknąć przycisk:

Kup teraz

ale chwilę przed kliknięciem nad nim ładuje się baner i przycisk przesuwa się w inne miejsce.

To właśnie rodzaj problemu, który CLS pomaga mierzyć.

9. Dlaczego warto monitorować wydajność regularnie?

Jednorazowy test PageSpeed jest przydatny.

Ale strona internetowa nie pozostaje niezmienna.

Może pojawić się:

• nowy baner,
• nowy skrypt marketingowy,
• dodatkowy tag analityczny,
• nowa wersja aplikacji,
• nowa biblioteka JavaScript,
• większe zdjęcia produktów,
• zmiana fontów,
• nowy widget czatu.

Każda z tych zmian może pogorszyć wydajność.

Dlatego znacznie ciekawsze od pytania:

„Jaki wynik PageSpeed mamy dzisiaj?”

jest pytanie:

„Czy wydajność naszej strony pogarsza się w czasie?”

Monitoring pozwala zobaczyć trend.

10. Czy warto monitorować tylko stronę główną?

Najczęściej nie.

Strona główna jest zwykle tylko jednym z wielu typów stron.

W sklepie internetowym warto rozważyć monitoring:

/
/product/example
/category/example
/cart
/checkout

W SaaS:

/
/login
/register
/dashboard

oraz najważniejszych endpointów API.

Nie chodzi o monitorowanie każdego URL-a w taki sam sposób.

Chodzi o wybranie reprezentatywnych punktów krytycznych.

11. Co monitorować w sklepie internetowym?

Minimalny sensowny zestaw może obejmować:

Dostępność sklepu

Czy sklep odpowiada?

Czas odpowiedzi

Czy sklep nie zaczął nagle działać znacznie wolniej?

SSL

Czy certyfikat jest ważny i nie zbliża się jego termin wygaśnięcia?

Błędy aplikacji

Czy WooCommerce, PrestaShop lub customowy backend generuje nowe błędy?

Checkout

Czy kluczowa część procesu zakupowego jest dostępna?

Wydajność

Czy Core Web Vitals i inne parametry wydajności nie pogorszyły się po zmianach?

Krytyczne integracje

Jeżeli sprzedaż zależy od zewnętrznych usług, problemy mogą dotyczyć również:

• płatności,
• ERP,
• systemu magazynowego,
• kurierów,
• marketplace,
• zewnętrznego API.

Sklep może działać technicznie, a jednocześnie nie być w stanie poprawnie realizować zamówień.

12. Co monitorować w aplikacji SaaS?

W przypadku SaaS priorytety mogą być trochę inne.

Warto obserwować:

• publiczną stronę,
• logowanie,
• API,
• błędy backendu,
• najważniejsze procesy biznesowe,
• czasy odpowiedzi,
• zadania wykonywane w tle,
• kolejki,
• integracje zewnętrzne,
• SSL,
• wydajność frontendu.

Szczególnie istotne jest monitorowanie funkcji, za które użytkownik faktycznie płaci.

Jeżeli dashboard działa, ale główna funkcja produktu przestała działać, z biznesowego punktu widzenia aplikacja ma poważną awarię.

13. Monitoring powinien odpowiadać na pytania, a nie produkować dane

Łatwo zbudować dashboard zawierający:

47 wykresów
23 metryki
15 statusów
8 tabel

i nadal nie wiedzieć, czy aplikacja działa poprawnie.

Dobry monitoring powinien pozwalać szybko odpowiedzieć na kilka prostych pytań:

• Czy aplikacja działa?
• Czy działa tak szybko jak zwykle?
• Czy pojawiły się nowe błędy?
• Czy liczba błędów nagle wzrosła?
• Czy certyfikat jest bezpieczny?
• Czy wydajność strony się pogorszyła?
• Czy najważniejsze funkcje biznesowe działają?

Jeżeli monitoring nie pomaga odpowiedzieć na te pytania, większa liczba danych niekoniecznie rozwiąże problem.

14. Od czego zacząć?

Nie trzeba od razu budować rozbudowanego systemu obserwowalności.

Dla wielu stron i aplikacji rozsądnym początkiem będzie monitorowanie czterech obszarów:

1. Uptime - czy usługa jest dostępna?
2. Błędy - czy aplikacja generuje wyjątki i czy ich liczba rośnie?
3. SSL - czy certyfikat jest prawidłowy i nie zbliża się jego wygaśnięcie?
4. Wydajność - czy strona nadal działa tak szybko jak wcześniej?

Dopiero później można dodawać bardziej szczegółowe mechanizmy zależnie od rodzaju aplikacji.

Najważniejsza zasada monitoringu

Monitoring nie powinien istnieć po to, żeby mieć dashboard.

Powinien skracać czas pomiędzy powstaniem problemu a momentem, w którym dowiaduje się o nim właściwa osoba.

Jeszcze lepiej, jeżeli pozwala wykryć pogarszającą się sytuację, zanim dojdzie do pełnej awarii.

Najgorszy scenariusz to nie zawsze aplikacja, która przestała działać.

Czasami znacznie gorsza jest aplikacja, która nie działa poprawnie od kilku godzin, a jej właściciel nadal o tym nie wie.