Logi serwera: co o Twoim sklepie mówią błędy 500, 404 i boty

Serwer Twojego sklepu zapisuje każde żądanie i każdy błąd. Te pliki czytane regularnie mówią więcej o stanie sklepu niż większość narzędzi analitycznych: pokazują, co się psuje, zanim klienci zadzwonią, kto próbuje się włamać i ile ruchu robią boty. Pokażemy, co w nich jest, jak je czytać bez wiedzy programisty i czego szukać.

W skrócie

Access log to lista wszystkich żądań: kto, kiedy, o co prosił, co dostał. Error log to lista błędów aplikacji i serwera. Oba są na każdym serwerze.
Błędy 500 to sklep, który nie działa dla klienta. Błędy 404 z ruchem to utracone wejścia z Google. Setki żądań na sekundę do logowania to atak.
Boty robią zwykle większość ruchu w logach. Część to Google i trzeba je wpuszczać, część to skanery i scrapery, które warto ograniczyć.
Logi muszą się rotować i mieć ustalony czas przechowywania. Bez tego zapełnią dysk, a sklep stanie. Trzymaj je co najmniej kilka tygodni na potrzeby analizy po incydencie.

Dwa pliki, które ma każdy serwer

Access log

Serwer HTTP (Nginx albo Apache) zapisuje każde żądanie w jednej linii: adres IP klienta, data i godzina, metoda i adres strony, kod odpowiedzi (200, 301, 404, 500), rozmiar odpowiedzi, strona odsyłająca i identyfikator przeglądarki (user agent). Sklep z umiarkowanym ruchem generuje dziesiątki tysięcy linii dziennie, więc czyta się to przez zliczanie i filtrowanie, nie linia po linii.

Error log

Osobny plik dla błędów serwera i PHP. Tu trafia informacja, dlaczego klient dostał błąd 500: wyjątek w module, brak pamięci, przekroczony czas wykonania, błąd połączenia z bazą. PrestaShop ma dodatkowo własne logi w panelu (Zaawansowane, Logi) i w katalogu logów aplikacji na serwerze, gdzie zapisuje błędy aplikacji i działania administratorów. Przy integracjach dochodzą logi łączników.

Gdzie są te pliki, zależy od hostingu: na współdzielonym zwykle w panelu klienta do pobrania, na VPS w katalogu logów Nginx albo Apache.

Kody odpowiedzi: co znaczą dla sklepu

Kod	Znaczenie	Co oznacza w sklepie	Co zrobić
200	OK	strona oddana poprawnie	nic, to norma
301, 302	przekierowanie	stare adresy po migracji, zmiana adresu produktu	sprawdź, czy przekierowania nie tworzą łańcuchów
404	nie znaleziono	usunięty produkt, literówka w linku, stary adres bez przekierowania	dla adresów z ruchem ustaw przekierowanie 301
403	zabroniony	blokada dostępu, często boty w zabronionych katalogach	sprawdź, czy nie blokujesz Google albo klientów
500	błąd serwera	sklep nie zadziałał dla klienta	pilne, szukaj przyczyny w error log
502, 503, 504	serwer niedostępny albo przeciążony	PHP nie odpowiada, baza padła, za duży ruch	pilne, sprawdź obciążenie i limity

Błędy 500: sklep, który nie działa

Każdy wpis 500 w access logu to klient, który zobaczył białą stronę albo komunikat o błędzie. Pierwszy krok to policzyć, ile ich jest dziennie i na jakich adresach. Jeśli skupiają się na jednej stronie, np. na kroku płatności, przyczyna jest zwykle jedna. Jeśli są rozsiane losowo, podejrzewaj limity serwera: pamięć PHP, liczbę procesów, połączenia z bazą.

Drugi krok to error log z tej samej minuty. Znajdziesz tam komunikat PHP ze ścieżką do pliku i numerem linii. Nawet bez znajomości kodu ścieżka powie Ci, który moduł zawinił, bo moduły leżą w katalogu modules pod własną nazwą. Trzeci krok to data pierwszego wpisu: zwykle pokrywa się z aktualizacją modułu, zmianą w szablonie albo zmianą wersji PHP przez hosting.

Uwaga

Na sklepie produkcyjnym tryb debugowania PrestaShop ma być wyłączony. Włączony pokazuje klientom szczegóły błędów ze ścieżkami i fragmentami kodu, co ułatwia atak. Szczegóły błędów mają trafiać do error logu, nie na ekran.

Błędy 404: utracone wejścia

Błąd 404 sam w sobie nie szkodzi, Google nie karze za jego istnienie. Szkodzi 404 na adresie, na który ktoś wchodzi: z Google, z porównywarki, z newslettera sprzed roku, z linku na forum. Każde takie wejście to klient, który zobaczył „nie znaleziono” i wyszedł. W access logu szukasz adresów z kodem 404 posortowanych według liczby wystąpień, z odfiltrowaniem botów. Pierwsze dwadzieścia adresów to Twoja lista przekierowań do ustawienia. Typowe źródła: produkty usunięte zamiast wyłączone, migracja bez pełnej mapy przekierowań, stare adresy w newsletterach.

Osobna kategoria to 404 od botów szukających znanych luk: pliki WordPressa na sklepie PrestaShop, pliki konfiguracyjne, kopie baz pod typowymi nazwami. Nie wymagają przekierowań, ale mówią, że ktoś skanuje sklep. Jeśli któryś z tych adresów zwróci kiedyś 200, masz problem.

Boty: kto naprawdę odwiedza sklep

W logach sklepu boty często robią większość żądań. Dzielą się na trzy grupy. Pierwsza to roboty wyszukiwarek: Googlebot, Bingbot. Tych nie blokujesz, ale sprawdzasz, czy nie marnują czasu na tysiące kombinacji filtrów i sortowań, bo Google ma ograniczony budżet na przejrzenie Twojego sklepu. Druga to boty narzędzi SEO, porównywarek i monitoringów cen. Część z nich jest użyteczna, część wysysa katalog dla konkurencji. Trzecia to skanery luk i scrapery udające przeglądarki.

Rozpoznajesz je po identyfikatorze przeglądarki, po wzorcu żądań (setki stron w minutę, bez obrazków i stylów) i po adresach z centrów danych. Prawdziwego Googlebota weryfikujesz po odwrotnym wyszukiwaniu nazwy hosta, bo sam identyfikator każdy może podrobić. Ograniczanie: robots.txt (tylko dla grzecznych botów), limity żądań na adres IP w konfiguracji serwera, blokada zakresów adresów, a przy większej skali usługa filtrująca ruch przed serwerem.

Kiedy to sygnał ataku

Setki żądań POST na adres logowania do panelu albo konta klienta z jednego adresu lub z wielu adresów w krótkim czasie. To próba zgadnięcia haseł. Odpowiedź: limit prób, blokada po kilku nieudanych, zmiana adresu panelu administracyjnego, dwuskładnikowe logowanie.
Żądania z dziwnymi parametrami w adresie: fragmenty zapytań SQL, znaczniki skryptów, ścieżki z kropkami w górę katalogu. To skanowanie pod kątem wstrzyknięć. Jeśli odpowiedzi to 404 albo 403, serwer sobie radzi. Jeśli 200 albo 500, sprawdź, co się stało.
Żądania do plików, których nie powinno być, zakończone kodem 200: pliki PHP w katalogu z obrazkami albo wgranymi plikami. To może oznaczać, że ktoś już wgrał złośliwy kod i teraz go używa.
Nagły wzrost ruchu bez wzrostu zamówień z jednego kraju albo zakresu adresów. Atak przeciążeniowy albo scraper; w logach widać kody 503 i 504 przy normalnym dniu.
Logowania do panelu o nietypowych godzinach w logu PrestaShop. Jeśli nikt z zespołu się nie logował, zmień hasła i sprawdź konta administratorów.

Jeśli znajdziesz ślady, że ktoś dostał się do danych klientów, pamiętaj o RODO: naruszenie trzeba zgłosić do UODO w ciągu 72 godzin od stwierdzenia. Logi są wtedy podstawowym dowodem, co się stało i kogo dotyczy, dlatego muszą być przechowywane wystarczająco długo.

Z naszej praktyki

Sklep z branży dziecięcej zgłosił nam, że „strona czasem wolno działa po północy”. W access logu okazało się, że co noc jeden zakres adresów pobierał cały katalog, około 40 tysięcy stron, w kilkanaście minut, z identyfikatorem udającym zwykłą przeglądarkę. Serwer dochodził do limitu procesów PHP i klienci w tym czasie dostawali 503. Ustawiliśmy limit żądań na adres IP na poziomie serwera i blokadę tego zakresu. Problem nocny zniknął, a przy okazji z logów wyszło 300 adresów produktów z błędem 404 i ruchem z Google, dla których ustawiliśmy przekierowania.

Klienci rzadko piszą, że coś nie działa. Po prostu wychodzą. Logi są jedynym miejscem, gdzie to widać.

Jak czytać logi bez programisty

Krok po kroku

Pobierz logi z ostatnich 7 dni. Z panelu hostingu albo z serwera, na kopię lokalną.
Policz kody odpowiedzi. Darmowe narzędzie do analizy logów pokaże udział 200, 301, 404, 500. Zapisz liczby do porównania tydzień do tygodnia.
Wylistuj adresy z 500 i 404 według liczby wystąpień. Pierwsza lista idzie do programisty z error logiem. Druga do przekierowań, po odfiltrowaniu botów.
Sprawdź top 20 adresów IP i identyfikatorów. Adres robiący więcej żądań niż cały ruch z Google to bot do ograniczenia.
Zajrzyj w godziny. Rozkład żądań po godzinach pokaże nocne skany i to, czy szczyt ruchu nie pokrywa się z ciężkimi zadaniami (synchronizacje z ERP, kopie), które lepiej przesunąć.

Rotacja i przechowywanie

Logi rosną codziennie. Bez rotacji access log na ruchliwym sklepie urośnie do gigabajtów w kilka tygodni i w końcu zapełni dysk, a wtedy sklep przestaje działać, bo baza nie może zapisać zamówienia. Rotacja to automatyczne zamknięcie pliku raz dziennie albo po osiągnięciu rozmiaru, skompresowanie i usunięcie najstarszych po ustalonym czasie. Na większości serwerów robi to logrotate, ale sprawdź, czy obejmuje też logi PrestaShop i integracji, bo te często rosną bez końca.

Ile trzymać? Na potrzeby analizy problemów i incydentów co najmniej kilka tygodni, lepiej do trzech miesięcy w postaci skompresowanej. Adresy IP w logach to dane osobowe w rozumieniu RODO, więc czas przechowywania wpisz w rejestr czynności. W opiece nad sklepem przeglądamy logi co tydzień i trzymamy je według ustalonej z klientem polityki.

Pytania, które słyszymy najczęściej

Czy Google Analytics nie wystarczy zamiast logów?

Nie. Analytics widzi tylko to, co wykonało skrypt w przeglądarce: ani błędów 500, ani botów, ani prób logowania do panelu. Logi widzą wszystko, co dotarło do serwera.

Jak często zaglądać w logi?

Raz w tygodniu krótki przegląd kodów i top adresów, codziennie przy wdrożeniach. Najlepiej ustawić powiadomienie, gdy liczba 500 albo 503 przekroczy próg.

Czy mogę wyłączyć logowanie, żeby serwer był szybszy?

Zysk jest znikomy, a tracisz jedyne źródło informacji o awariach i atakach. Zamiast tego ustaw rotację.

W opiece nad sklepem przeglądamy logi regularnie, ustawiamy powiadomienia o błędach i reagujemy, zanim klienci zauważą problem. Zobacz, co obejmuje opieka nad sklepem.

Zapytaj o opiekę nad sklepem