Regularnie monitoruj błędy HTTP 400, 404, 500 i 502, aby wykryć problem, zanim obejmie dużą część serwisu. Ta lista kontrolna pomaga mierzyć liczbę błędów, wskazać dotknięte adresy URL, sprawdzić logi, ustawić progi alertów oraz zebrać dane potrzebne deweloperowi lub pomocy technicznej.

Kod statusu HTTP to odpowiedź serwera na żądanie przeglądarki lub innego klienta. W audycie warto śledzić osobno kody 400, 404, 500 i 502, ponieważ monitoring tych odpowiedzi pozwala ustalać poziom błędów, progi alertów i zmiany w czasie. Źródło: FaultForge

Spis treści

Przed rozpoczęciem audytu

Przygotuj dostęp do narzędzia monitorującego odpowiedzi HTTP oraz do logów serwera lub aplikacji. Potrzebna będzie też lista ostatnich zmian w kodzie, konfiguracji i zależnościach usługi.

Ustal okres porównawczy, na przykład bieżącą godzinę i wcześniejszy, spokojny okres działania.
Rozdziel dane według kodu HTTP: 400, 404, 500 i 502.
Zapisuj czas wystąpienia, adres URL, liczbę odpowiedzi oraz zakres problemu.
Ustal akceptowalny poziom błędów i próg, po którym ma zostać wysłany alert.

Wyznaczenie normalnego poziomu błędów i progów alertów jest podstawą monitorowania zmian w liczbie odpowiedzi HTTP. Źródło: FaultForge

Codzienna lista kontrolna monitorowania HTTP

Sprawdź liczbę błędów według kodu. Porównaj bieżący wynik z ustalonym poziomem odniesienia. Zwróć uwagę na wzrost liczby odpowiedzi, nie tylko na pojedynczy wpis.
Wskaż adresy URL z błędami. Zestaw adresy według liczby wystąpień. Osobno oznacz adresy, które generują błędy wielokrotnie.
Porównaj zakres adresów. Ustal, czy błąd dotyczy jednego URL, grupy powiązanych adresów czy wielu niezależnych części serwisu.
Sprawdź czas zdarzeń. Zapisz początek wzrostu błędów, czas ostatniego błędu i okres największego natężenia.
Przejrzyj logi. Filtruj wpisy po czasie, kodzie HTTP i dotkniętym URL. Zachowaj fragmenty logów związane z momentem wzrostu błędów.
Porównaj zdarzenia z wdrożeniami. Sprawdź, czy początek problemu pokrywa się z ostatnią zmianą kodu, konfiguracji lub publikacją nowej wersji.
Sprawdź zależności upstream. Przy odpowiedziach 502 zapisz, z którą usługą pośrednią lub zależnością problem występuje, jeśli taka informacja jest widoczna w monitoringu albo logach.
Potwierdź powrót do normy. Po zmianie naprawczej obserwuj liczbę błędów, dotknięte URL i odpowiedzi HTTP w kolejnym okresie pomiarowym.

[Screenshot: Widok monitoringu z liczbą odpowiedzi HTTP 400, 404, 500 i 502 w wybranym okresie]

Jak odróżnić pojedynczy URL od incydentu w całym serwisie

Izolowany problem dotyczy jednego adresu URL lub małej, powtarzalnej grupy adresów. W takim przypadku dokumentuj pełne adresy, liczbę wystąpień i czas błędów. Dzięki temu można sprawdzić konkretną trasę, zasób lub żądanie bez traktowania zdarzenia jako awarii całej witryny.

Incydent o szerszym zasięgu obejmuje wiele niezależnych URL albo powoduje równoczesny wzrost odpowiedzi 500 lub 502 w różnych częściach serwisu. Taki wzorzec wymaga szybszego zgłoszenia, ponieważ dotyczy większego zakresu żądań. Monitorowanie liczby błędów według kodu i trendu pomaga zauważyć ten typ zmiany. Źródło: FaultForge

Sygnały do natychmiastowej eskalacji

Liczba odpowiedzi HTTP przekracza ustalony próg alertu.
Błędy pojawiają się na wielu niezależnych adresach URL.
Występuje wyraźny wzrost odpowiedzi 500 lub 502 w krótkim okresie.
Wzrost błędów zaczyna się bezpośrednio po wdrożeniu lub zmianie konfiguracji.
Błąd utrzymuje się po wykonaniu zmiany naprawczej.

Alerty powinny wynikać z wcześniej ustalonych progów, a nie z samego faktu wystąpienia pojedynczej odpowiedzi błędnej. Źródło: FaultForge

Jak sprawdzić logi i ostatnie wdrożenia

Wybierz przedział czasu obejmujący początek wzrostu błędów.
Wyszukaj wpisy dla kodu HTTP i URL wskazanego przez monitoring.
Zapisz komunikaty z tego samego czasu w logu aplikacji, serwera lub zależnej usługi.
Porównaj czas wpisów z godziną ostatniego wdrożenia.
Jeżeli problem zaczął się po zmianie, przekaż osobie odpowiedzialnej nazwę zmiany, czas wdrożenia oraz przykłady błędnych żądań.
Po naprawie powtórz pomiar dla tych samych kodów i adresów URL.

Nie usuwaj danych z logów przed przekazaniem zgłoszenia. Krótki wycinek z właściwego czasu jest bardziej użyteczny niż ogólny opis problemu.

Jakie dane przekazać do dewelopera lub pomocy technicznej

Przygotuj jeden opis incydentu. Powinien zawierać dane, które pozwalają odtworzyć zakres i kolejność zdarzeń:

kod HTTP, na przykład 404, 500 lub 502,
pełny adres URL dotknięty błędem,
czas pierwszego i ostatniego zaobserwowanego błędu,
liczbę błędów w badanym okresie,
informację, czy problem dotyczy jednego URL, czy wielu części serwisu,
fragmenty logów z odpowiadającego okresu,
informację o ostatnim wdrożeniu lub zmianie konfiguracji,
wynik sprawdzenia po podjęciu działania naprawczego.

Co zrobić, jeśli błąd nadal występuje

Jeśli liczba błędów nie wraca do ustalonego poziomu, kontynuuj obserwację tych samych kodów i URL. Zaktualizuj zgłoszenie o nowe godziny wystąpień, bieżącą liczbę odpowiedzi oraz wynik kolejnych prób. Gdy problem obejmuje wiele adresów lub przekracza próg alertu, eskaluj go wraz z zebranym materiałem.

Powtarzaj tę checklistę w stałych odstępach oraz po wdrożeniach. Stałe porównanie bieżących wyników z poziomem odniesienia ułatwia wychwycenie wzrostu błędów HTTP i potwierdzenie, że usługa wróciła do normalnego działania.

FAQ

Czy pojedynczy błąd 404 oznacza awarię serwisu?

Nie musi. Najpierw sprawdź, czy błąd dotyczy jednego URL, czy wielu niezależnych adresów. W audycie ważny jest trend, liczba wystąpień i zakres dotkniętych URL.

Kiedy uznać, że naprawa zadziałała?

Po zmianie sprawdź ponownie te same kody HTTP, adresy URL i okres pomiarowy. Potwierdzenie powrotu do normy wymaga obserwacji, czy liczba błędów wraca do ustalonego poziomu.

Lista kontrolna monitorowania błędów HTTP 400, 404, 500 i 502