Logi dostępu i błędów na hostingu. Gdzie je znaleźć i jak czytać wpisy?

Strona nagle pokazuje błąd 500, formularz przestał wysyłać wiadomości, a sklep w nocy działał bardzo wolno. Panel WordPressa nic o tym nie mówi, statystyki odwiedzin też nie. Odpowiedź niemal zawsze leży w dwóch plikach, które serwer prowadzi bez przerwy: w logu dostępu i w logu błędów.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób opiekujących się stroną, które nie są administratorami serwerów. Nie wymaga znajomości programowania. Wystarczy dostęp do panelu hostingu i zwykły edytor tekstu.

Po lekturze czytelnik będzie wiedział, gdzie w panelu szukać logów, jak je pobrać i otworzyć, co oznacza każdy element pojedynczego wpisu, jak po godzinie awarii dojść do jej przyczyny oraz jak odróżnić prawdziwego robota Google od programu, który tylko się pod niego podszywa.

Czym są logi serwera i kiedy warto do nich zajrzeć?

Log to zwykły plik tekstowy, w którym serwer dopisuje na końcu kolejne wiersze. Jeden wiersz odpowiada jednemu zdarzeniu. Na typowym hostingu prowadzone są dwa podstawowe rodzaje takich plików i każdy odpowiada na inne pytanie.

Log dostępu (access log) zapisuje każde żądanie, które trafiło do serwera: kto pytał, o który adres, kiedy i jaką odpowiedź otrzymał. Trafiają tu wizyty ludzi, robotów wyszukiwarek, programów sprawdzających dostępność strony oraz prób włamań. To pełniejszy obraz ruchu niż w narzędziach analitycznych, które liczą tylko wizyty z uruchomionym skryptem pomiarowym i wyrażoną zgodą.

Log błędów (error log) zapisuje tylko to, co poszło źle: błędy serwera WWW, błędy w kodzie PHP, odmowy dostępu, błędne reguły w pliku .htaccess. To tutaj znajduje się dokładna nazwa pliku i numer wiersza, w którym wtyczka lub motyw przerwały pracę.

Do logów należy zajrzeć zawsze wtedy, gdy strona zachowuje się inaczej niż zwykle, a przyczyna nie jest widoczna na ekranie. Najczęstsze sytuacje to:

• komunikat o błędzie 500, 502, 503 albo pusta, biała strona,
• nagłe spowolnienie serwisu lub wiadomość od hostingu o przekroczeniu limitów konta,
• podejrzenie włamania, masowych prób logowania albo wysyłki spamu z formularza,
• spadek liczby stron pobieranych przez Google lub błędy serwera zgłaszane w Google Search Console,
• adresy, które zgłaszają błąd 404, mimo że podstrona powinna istnieć.

Uważam, że log błędów to pierwsze miejsce, które należy otworzyć przy każdej awarii. Wyłączanie wtyczek po kolei bywa skuteczne, ale trwa długo i niczego nie wyjaśnia. Wpis w logu zwykle od razu wskazuje źródło problemu.

Gdzie znaleźć logi w panelu hostingu i jak je pobrać?

Miejsce zależy od panelu, z którego korzysta dostawca. Nazwy pozycji różnią się między firmami, dlatego poniżej podaję dokładną ścieżkę dla panelu cPanel, którą potwierdza jego dokumentacja, oraz ogólne wskazówki dla pozostałych paneli.

Panel cPanel

W panelu cPanel logi znajdują się w grupie „Metrics”. W polskiej wersji językowej nazwy mogą być przetłumaczone, ale ikony i kolejność pozostają te same. Potrzebne są dwie pozycje: „Errors” oraz „Raw Access”.

1. Po zalogowaniu do panelu należy przewinąć stronę do grupy „Metrics”.
2. Kliknięcie pozycji „Errors” otwiera podgląd logu błędów. Według dokumentacji cPanel widać tam do 300 najnowszych wpisów, ułożonych od najświeższego do najstarszego.
3. Po powrocie do grupy „Metrics” należy otworzyć pozycję „Raw Access”. To miejsce, z którego pobiera się log dostępu.
4. W części „Download Current Raw Access Logs” znajduje się lista domen przypisanych do konta. Kliknięcie nazwy domeny lub ikony pobierania przy niej zapisuje na dysku plik z rozszerzeniem .gz.
5. Pobrany plik trzeba rozpakować, a następnie otworzyć w edytorze tekstu.

Bieżący plik obejmuje zwykle krótki okres. Starsze wpisy zachowują się tylko wtedy, gdy włączona jest archiwizacja. W części „Configure Logs” służy do tego pole wyboru „Archive log files in your home directory after the system processes statistics”. Po jego zaznaczeniu i kliknięciu „Save” spakowane logi trafiają do katalogu logs w katalogu domowym konta. Dokumentacja podaje, że statystyki są domyślnie przetwarzane co 24 godziny.

W tej samej części są jeszcze dwa pola. Pierwsze, „Remove the previous month’s archived logs from your home directory at the end of the month”, usuwa na koniec miesiąca archiwa z miesiąca poprzedniego. Drugie, „Set a custom retention period for archived logs”, pozwala wskazać liczbę dni przechowywania. Bez tych ustawień archiwa są przechowywane bezterminowo i zajmują miejsce na koncie, więc warto od razu zdecydować, jak długo mają być trzymane.

DirectAdmin i panele własne dostawców

W panelu DirectAdmin logi są przypisane do konkretnej domeny i znajdują się w części ze statystykami oraz logami witryny. Dla każdej domeny dostępny jest osobno log odwiedzin i log błędów, zwykle w dwóch postaciach: podgląd ostatnich wierszy oraz pełny plik.

Wielu polskich dostawców korzysta z własnych paneli. Logów należy szukać w ustawieniach konkretnej strony lub domeny, pod nazwami takimi jak „Logi”, „Logi serwera WWW”, „Logi błędów” albo „Statystyki”. U części firm zapis logów jest domyślnie wyłączony i trzeba go najpierw włączyć. Wtedy wpisy zaczynają się gromadzić dopiero od tej chwili, a awarii sprzed włączenia nie da się już prześledzić.

Katalog z logami widoczny przez FTP lub menedżer plików

Niektóre hostingi zapisują logi w osobnym katalogu na koncie, najczęściej o nazwie logs, położonym obok katalogu ze stroną. Można się do niego dostać przez menedżer plików w panelu albo przez program do połączeń SFTP. Pliki bieżące mają zwykle w nazwie słowa „access” i „error”, a starsze są spakowane i oznaczone kolejnym numerem lub dniem.

Jeśli logów nie widać w żadnym z tych miejsc, najszybciej jest napisać do działu pomocy hostingu. Sprawdza się krótka, konkretna wiadomość: „Proszę o wskazanie, gdzie w panelu znajdę log dostępu i log błędów dla domeny (nazwa domeny) oraz przez ile dni są przechowywane.”

Czym otworzyć duży plik logu?

Plik z rozszerzeniem .gz rozpakowuje się programem do archiwów, na przykład 7-Zip. W systemie macOS wystarczy dwukrotne kliknięcie. Po rozpakowaniu powstaje plik tekstowy bez formatowania.

Do przeglądania nadaje się każdy edytor zwykłego tekstu, który radzi sobie z dużymi plikami, na przykład Notepad++ albo Visual Studio Code. Edytory biurowe, takie jak Word, są złym wyborem, ponieważ łamią długie wiersze i zamieniają znaki. Najważniejszą funkcją jest wyszukiwanie, wywoływane skrótem Ctrl+F. Dzięki niemu można w kilka sekund znaleźć wszystkie wpisy z danej godziny, z jednego adresu IP albo z konkretnym kodem odpowiedzi.

Jak czytać wpis w logu dostępu?

Większość hostingów zapisuje log dostępu w układzie nazywanym Combined Log Format. Stosuje go serwer Apache, a serwer nginx ma domyślny format o tej samej kolejności pól. Przykładowy wiersz wygląda tak (w miejscu RRRR stoi w prawdziwym logu rok):

66.249.66.1 - - [12/Mar/RRRR:14:05:31 +0100] "GET /oferta/ HTTP/1.1" 200 15320 "https://www.example.com/" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Na pierwszy rzut oka to ciąg znaków bez ładu. W rzeczywistości każdy wiersz składa się z tych samych pól, zawsze w tej samej kolejności, oddzielonych spacjami:

• 66.249.66.1 – adres IP, z którego przyszło żądanie. Jeśli strona działa za usługą pośredniczącą, w tym miejscu może stać adres pośrednika, a nie odwiedzającego.
• – – – dwa pola, które prawie zawsze zawierają myślnik. Pierwsze jest pozostałością dawnego sposobu identyfikacji, drugie pokazuje nazwę użytkownika tylko wtedy, gdy katalog jest chroniony hasłem serwera.
• [12/Mar/RRRR:14:05:31 +0100] – dzień, miesiąc, rok, godzina, minuta i sekunda przyjęcia żądania oraz przesunięcie strefy czasowej serwera.
• „GET /oferta/ HTTP/1.1” – wiersz żądania: metoda (GET to pobranie strony, POST to wysłanie danych, na przykład formularza), adres zasobu i wersja protokołu.
• 200 – kod odpowiedzi serwera. To najważniejsza liczba w całym wierszu.
• 15320 – rozmiar wysłanej odpowiedzi w bajtach, bez nagłówków. Myślnik w tym miejscu oznacza, że serwer nie wysłał żadnej treści.
• „https://www.example.com/” – adres strony, z której odwiedzający przeszedł do zasobu. Myślnik oznacza wejście bezpośrednie lub brak tej informacji.
• „Mozilla/5.0 (compatible; Googlebot/2.1; …)” – opis przeglądarki lub programu, którym wykonano żądanie. Tę wartość podaje sam odwiedzający, więc nie jest ona dowodem tożsamości.

Trzeba zwrócić uwagę na strefę czasową. Wartość +0100 lub +0200 oznacza czas polski, zimowy albo letni. Wartość +0000 oznacza czas uniwersalny, czyli godzinę lub dwie wcześniej niż na zegarze w Polsce. Pomyłka w tym miejscu to najczęstszy powód, dla którego ktoś nie znajduje w logu wpisów z chwili awarii.

Jedno otwarcie strony przez człowieka zostawia w logu wiele wierszy, a nie jeden. Przeglądarka pobiera osobno dokument, arkusze stylów, skrypty, czcionki i każdą grafikę. Dlatego liczba wierszy w logu nie jest liczbą odwiedzin i nie należy jej porównywać wprost z danymi z narzędzi analitycznych.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Pobiorę logi z hostingu, znajdę w nich wpisy z chwili awarii i wskażę konkretną przyczynę wraz ze sposobem naprawy.

Co oznaczają kody odpowiedzi zapisane w logu?

Kod odpowiedzi to trzycyfrowa liczba, którą serwer opisuje wynik żądania. Pierwsza cyfra wyznacza grupę i już ona mówi, czy jest powód do niepokoju.

• Kody zaczynające się od 2 oznaczają powodzenie. Kod 200 to poprawnie wysłana strona.
• Kody zaczynające się od 3 oznaczają przekierowanie. Kod 301 to przekierowanie stałe, 302 to tymczasowe, a 304 informuje, że zasób nie zmienił się od poprzedniej wizyty i przeglądarka może użyć zapisanej kopii.
• Kody zaczynające się od 4 oznaczają błąd po stronie pytającego. Kod 404 to brak zasobu pod danym adresem, 403 to odmowa dostępu, 401 to brak uwierzytelnienia, a 429 to zbyt wiele żądań w krótkim czasie.
• Kody zaczynające się od 5 oznaczają błąd po stronie serwera. Kod 500 to błąd wewnętrzny, zwykle w kodzie strony lub w konfiguracji, 502 i 504 dotyczą zwykle komunikacji między elementami serwera, a 503 oznacza czasową niedostępność usługi.

Pojedyncze kody 404 są zjawiskiem normalnym. Roboty i automaty stale odpytują adresy, które na stronie nigdy nie istniały. Uwagi wymagają dopiero kody 404 przy adresach, które powinny działać, zwłaszcza gdy w polu ze stroną odsyłającą widać własną domenę. Oznacza to uszkodzony link wewnątrz serwisu.

Kody z grupy 5 zawsze wymagają wyjaśnienia. Dokumentacja Google podaje, że błędy serwera oraz kod 429 są dla robotów sygnałem, aby na pewien czas zwolnić pobieranie stron, a adresy, które długo zwracają taki błąd, mogą zostać usunięte z indeksu. Gdy w logu widać serię kodów 500 lub 503 przy wizytach Googlebota, sprawa jest pilna. Osobno opisałem, co sprawdzić, gdy strona zniknęła z wyników Google.

Warto też przejrzeć przekierowania. Długie łańcuchy kodów 301, w których jeden adres prowadzi do drugiego, a ten do trzeciego, spowalniają stronę i utrudniają pracę robotom. Jeżeli po zmianie reguł pojawiły się nieoczekiwane kody 301 albo 500, przyczyna zwykle leży w pliku .htaccess. Sposób bezpiecznego zapisu takich reguł pokazuje wpis o przekierowaniu 301 w pliku .htaccess.

Jak czytać wpis w logu błędów?

Log błędów ma inną budowę niż log dostępu. Wiersz jest dłuższy i kończy się opisem słownym w języku angielskim. Dokumentacja serwera Apache podaje taki przykład (pomijam w nim znacznik czasu):

[core:error] [pid 35708:tid 4328636416] [client 72.15.99.187] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error

Prawdziwy wiersz zaczyna się od nawiasu z dniem i godziną zdarzenia. Dalej następują: nazwa modułu serwera i poziom ważności („core:error”), numer procesu, adres IP odwiedzającego, którego żądanie wywołało błąd, a na końcu właściwy komunikat. W tym przykładzie serwer informuje, że przekierowania wewnętrzne zapętliły się, co niemal zawsze oznacza błędną regułę w pliku .htaccess.

Poziomy ważności błędów PHP

Strony na WordPressie i większość sklepów działają w języku PHP, dlatego duża część wpisów zaczyna się od słów „PHP” i nazwy poziomu. Poziomy różnią się wagą:

• PHP Fatal error – błąd krytyczny. Skrypt przerwał pracę, a odwiedzający zobaczył błąd 500 lub pustą stronę. Takie wpisy naprawia się w pierwszej kolejności.
• PHP Parse error – błąd składni w pliku, najczęściej po ręcznej zmianie kodu. Skutek jest taki sam jak przy błędzie krytycznym.
• PHP Warning – ostrzeżenie. Strona działa dalej, ale któryś element mógł się nie wykonać, na przykład nie wczytał się plik.
• PHP Notice oraz PHP Deprecated – uwagi o drobnych nieścisłościach i o funkcjach, które zostaną wycofane w przyszłych wersjach PHP. Nie psują strony, lecz zapowiadają kłopoty po aktualizacji.

Komunikaty, które pojawiają się najczęściej

Każdy wpis o błędzie PHP kończy się ścieżką do pliku i numerem wiersza. Ścieżka jest najcenniejszą wskazówką. Jeśli zawiera fragment wp-content/plugins/nazwa-wtyczki/, przyczyną jest ta wtyczka. Jeśli zawiera wp-content/themes/, przyczyną jest motyw.

Komunikat „Allowed memory size of … bytes exhausted” oznacza, że skrypt wyczerpał przydzieloną pamięć. Rozwiązaniem bywa podniesienie limitu pamięci PHP w panelu hostingu, ale najpierw należy ustalić, która wtyczka zużywa jej tak dużo, bo sam wyższy limit często tylko odsuwa problem.

Komunikat „Maximum execution time of … seconds exceeded” informuje, że skrypt działał dłużej, niż pozwala serwer. Zdarza się to przy imporcie produktów, tworzeniu kopii lub przy zapytaniach do wolno odpowiadającej usługi zewnętrznej.

Komunikaty „Call to undefined function” oraz „Class … not found” wskazują na brakujący element: niepełną aktualizację, wtyczkę wymagającą innej wtyczki albo niezgodność z wersją PHP. Zwykle pomaga ponowne wgranie wtyczki lub zmiana wersji PHP w panelu.

Wpis zawierający nazwę pliku .htaccess i słowa „Invalid command” mówi, że w tym pliku znalazło się polecenie, którego serwer nie rozumie. Taki błąd wyłącza całą stronę i daje kod 500 przy każdym adresie. Wpis „client denied by server configuration” oznacza z kolei, że serwer celowo odmówił dostępu, bo tak stanowi reguła blokująca. To wyjaśnienie wielu kodów 403.

Gdy cała strona pokazuje pusty ekran, a w logu widać błąd krytyczny, dalsze kroki opisuje wpis o tym, jak postąpić, gdy pojawia się biały ekran w WordPressie.

Jak znaleźć w logach przyczynę konkretnej awarii?

Log z kilku dni liczy tysiące wierszy. Czytanie go od początku nie ma sensu. Skuteczna metoda polega na zawężeniu poszukiwań do jednej chwili i jednego adresu, a potem na zestawieniu obu logów ze sobą.

1. Ustalenie możliwie dokładnej godziny problemu. Jeśli awaria trwa, należy otworzyć wadliwą podstronę i zanotować godzinę co do minuty.
2. Sprawdzenie własnego adresu IP. Wystarczy wpisać w wyszukiwarce pytanie o swój adres IP, a zostanie on wyświetlony.
3. Pobranie aktualnego logu dostępu i logu błędów z panelu hostingu, zaraz po wywołaniu błędu.
4. Wyszukanie w logu dostępu własnego adresu IP. Ostatnie wiersze z tym adresem to właśnie wykonana przed chwilą próba.
5. Odczytanie kodu odpowiedzi w tych wierszach. Kod 500 kieruje do logu błędów, kod 403 do reguł blokujących, kod 404 do adresu lub przekierowań, a kod 200 przy błędnie wyglądającej stronie sugeruje kłopot z pamięcią podręczną, skryptem albo stylem.
6. Odszukanie w logu błędów wpisów z tej samej minuty i z tym samym adresem IP w polu „client”.
7. Zapisanie pełnej treści komunikatu wraz ze ścieżką do pliku. To gotowa informacja dla wykonawcy strony, autora wtyczki lub działu pomocy hostingu.

Gdy awaria już minęła i nie da się jej wywołać ponownie, pozostaje szukanie po godzinie. W logu dostępu należy wyszukać fragment znacznika czasu, na przykład 12/Mar razem z godziną :03:, i przejrzeć kody odpowiedzi z tego okresu. Seria kodów 5 obok siebie wyznacza początek i koniec awarii.

Jak rozpoznać przeciążenie i niepożądany ruch?

Przy spowolnieniach należy sprawdzić, czy w krótkim czasie nie powtarza się jeden adres IP albo jeden adres zasobu. Setki żądań na minutę do pliku wp-login.php lub xmlrpc.php to próby odgadnięcia hasła. Długie serie żądań z jednym opisem programu w ostatnim polu to zwykle robot pobierający całą witrynę.

Niepokoić powinny też żądania metodą POST kierowane do plików PHP o przypadkowych nazwach, zwłaszcza w katalogach z przesłanymi grafikami, jeśli serwer odpowiada na nie kodem 200. Może to oznaczać, że na koncie znalazł się obcy plik. W takiej sytuacji należy przejść do planu opisanego we wpisie o tym, co robić, gdy strona na WordPressie została zainfekowana, a logi z tego okresu zachować jako materiał do ustalenia drogi włamania.

Blokowanie adresów IP na podstawie logu wymaga ostrożności. Zablokowanie adresu, z którego korzysta robot wyszukiwarki, operator płatności albo usługa pośrednicząca, wyrządzi więcej szkody niż sam niepożądany ruch. Przed blokadą trzeba sprawdzić, do kogo adres należy.

Jak sprawdzić, czy wizyta naprawdę pochodzi od robota Google?

Opis programu w ostatnim polu wiersza można wpisać dowolnie. Wiele automatów przedstawia się jako Googlebot, licząc na to, że nikt ich nie zablokuje. Google opisuje w swojej dokumentacji sposób weryfikacji oparty na systemie nazw domen, którego nie da się w ten sposób podrobić.

1. Z logu dostępu należy skopiować adres IP z wiersza, w którym pojawia się nazwa Googlebot.
2. W wierszu poleceń komputera wykonuje się odwrotne wyszukiwanie nazwy dla tego adresu. Dokumentacja Google podaje polecenie host 66.249.66.1. W systemie Windows tę samą rolę pełni polecenie nslookup z adresem IP.
3. W odpowiedzi pojawia się nazwa serwera. Trzeba sprawdzić, czy kończy się ona na googlebot.com, google.com lub googleusercontent.com.
4. Następnie wykonuje się zwykłe wyszukiwanie dla otrzymanej nazwy, na przykład host crawl-66-249-66-1.googlebot.com.
5. Jeżeli wynik to ten sam adres IP, który widnieje w logu, wizyta pochodziła od Google. Jeżeli nazwa ma inne zakończenie albo adresy się różnią, ktoś się pod robota podszywał.

Przy dużej liczbie adresów ręczne sprawdzanie jest uciążliwe. Google publikuje listy zakresów adresów IP swoich robotów i wskazuje je jako metodę automatyczną. Z takich list korzystają zapory i usługi ochrony stron, więc na hostingu z dobrą zaporą część tej pracy wykonuje się sama.

Prawdziwy obraz pracy robota Google warto zestawić z raportem „Statystyki indeksowania” w Google Search Console, dostępnym w części „Ustawienia”. Raport pokazuje liczbę żądań i udział poszczególnych odpowiedzi serwera, a log pozwala zejść do pojedynczych adresów i godzin.

Co zrobić, gdy log hostingu milczy? Dziennik błędów WordPressa

Zdarza się, że strona pokazuje błąd, a w logu błędów na hostingu nie ma odpowiadającego mu wpisu. Powodem bywa wyłączony zapis błędów PHP, osobny plik z błędami PHP albo podgląd ograniczony do ostatnich wierszy. W wielu panelach zapis błędów PHP włącza się w ustawieniach PHP danej domeny. Na części serwerów błędy PHP trafiają do pliku error_log w tym samym katalogu, w którym leży wykonywany skrypt.

WordPress ma własny mechanizm zapisu błędów, opisany w oficjalnej dokumentacji. Włącza się go trzema wierszami w pliku wp-config.php, który leży w głównym katalogu strony. Przed zmianą należy pobrać kopię tego pliku na dysk, ponieważ pomyłka w nim wyłącza całą stronę.

1. Otwarcie pliku wp-config.php w menedżerze plików panelu hostingu lub przez SFTP.
2. Odszukanie wiersza z komentarzem, który kończy część przeznaczoną do edycji (w wersji angielskiej zaczyna się od słów „That’s all, stop editing”).
3. Wklejenie powyżej tego wiersza poniższego fragmentu. Jeśli w pliku istnieje już wiersz z nazwą WP_DEBUG, trzeba go zastąpić, a nie powielać.
4. Zapisanie pliku i ponowne otwarcie podstrony, która sprawia kłopot.
5. Pobranie pliku debug.log z katalogu wp-content i odczytanie ostatnich wierszy.
6. Po zakończeniu diagnozy przywrócenie w pliku wartości false przy WP_DEBUG oraz usunięcie pliku debug.log z serwera.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Pierwszy wiersz włącza tryb diagnostyczny, drugi każe zapisywać błędy do pliku, a dwa ostatnie ukrywają komunikaty przed odwiedzającymi. Bez nich ostrzeżenia wyświetlałyby się klientom na stronie.

Dokumentacja WordPressa zaznacza, że tryb diagnostyczny nie jest zalecany na działających stronach i służy do testów. Na stronie firmowej należy więc włączać go na krótko, tylko na czas szukania przyczyny. Plik debug.log leży w katalogu dostępnym z przeglądarki i potrafi zawierać ścieżki serwera oraz inne dane techniczne, dlatego pozostawienie go na serwerze jest realnym zagrożeniem.

Jakich błędów unikać przy pracy z logami?

Logi są źródłem wiedzy, ale też zbiorem danych, z którym trzeba obchodzić się rozważnie. W praktyce powtarza się kilka pomyłek:

• Udostępnianie całych plików osobom postronnym. Log zawiera adresy IP odwiedzających, a adres IP może być uznany za daną osobową. Wykonawcy lub na forum wystarczy przekazać kilka wierszy dotyczących błędu, najlepiej z własnym adresem IP.
• Odkładanie pobrania logu na później. Hostingi przechowują logi przez ograniczony czas, a podgląd w panelu obejmuje tylko najnowsze wpisy. Po awarii plik należy zapisać na dysku od razu.
• Usuwanie lub edytowanie logów na serwerze. Przy podejrzeniu włamania są one jedynym śladem tego, co się wydarzyło. Analizuje się zawsze pobraną kopię.
• Wyciąganie wniosków z jednego wiersza. Pojedynczy kod 404 lub jedno ostrzeżenie PHP nic nie znaczy. Liczy się powtarzalność i zbieżność w czasie z problemem.
• Traktowanie opisu programu jako dowodu. Nazwa Googlebot w ostatnim polu nie potwierdza, że wizyta pochodziła od Google. Potwierdza to dopiero weryfikacja adresu IP.

Radzę też nie zostawiać włączonej archiwizacji bez ustalonego okresu przechowywania. Na ruchliwej stronie archiwa logów potrafią po kilku miesiącach zająć znaczną część miejsca na koncie, a przepełnione konto samo staje się przyczyną awarii.

Po czym poznać, że naprawa zadziałała, i co zrobić, gdy nie pomogła?

Sprawdzenie polega na powtórzeniu tej samej czynności, która wcześniej wywoływała błąd, i ponownym odczytaniu obu logów. Naprawa jest skuteczna, gdy w logu dostępu przy własnym adresie IP widnieje kod 200 zamiast kodu z grupy 5 lub 4, a w logu błędów nie przybywa nowych wpisów z tym samym komunikatem. Stare wpisy pozostają w pliku, dlatego liczy się wyłącznie godzina ostatniego wystąpienia.

Po kilku dniach warto zajrzeć do logu jeszcze raz i sprawdzić, czy błąd nie wraca o stałych porach, na przykład podczas nocnych zadań. W Google Search Console liczba błędów serwera w raporcie „Statystyki indeksowania” powinna stopniowo maleć.

Jeżeli błąd nadal się pojawia, należy sprawdzić, czy komunikat w logu jest ten sam, czy już inny. Nowa treść oznacza, że pierwsza przyczyna została usunięta i odsłoniła kolejną. Ta sama treść oznacza, że zmiana nie objęła właściwego pliku albo strona jest podawana z pamięci podręcznej, którą trzeba wyczyścić.

Gdy komunikat wskazuje na wtyczkę lub motyw, zgłoszenie należy skierować do ich autora, z pełnym wierszem z logu, wersją PHP i wersją WordPressa. Gdy wskazuje na konfigurację serwera, limit zasobów albo moduł, którego nazwa nic nie mówi, właściwym adresatem jest dział pomocy hostingu. Sprawdza się taka treść: „O godzinie (godzina) strona (adres) zwróciła błąd 500. W logu błędów widnieje wpis: (pełna treść wiersza). Proszę o wskazanie przyczyny po stronie serwera.”

Najczęstsze pytania

Jak długo hosting przechowuje logi?

Zależy to od dostawcy i od ustawień konta, a okres bywa krótki. W panelu cPanel starsze wpisy zachowują się dopiero po włączeniu archiwizacji w pozycji „Raw Access”. U innych dostawców okres przechowywania jest podany w dokumentacji lub regulaminie, a w razie wątpliwości najlepiej zapytać o niego dział pomocy.

Czy przeglądanie logów może zaszkodzić stronie?

Nie. Pobranie i czytanie pliku niczego na serwerze nie zmienia. Ryzyko pojawia się dopiero przy zmianach wprowadzanych na podstawie logu, takich jak edycja pliku wp-config.php, reguł w pliku .htaccess czy blokowanie adresów IP, dlatego przed każdą z nich należy wykonać kopię zmienianego pliku.

Dlaczego w logu dostępu jest znacznie więcej wejść niż w Google Analytics?

Log zapisuje każde żądanie do serwera, w tym pobranie każdej grafiki i skryptu, a także wizyty robotów i automatów. Narzędzia analityczne liczą wyłącznie odwiedziny, podczas których w przeglądarce uruchomił się skrypt pomiarowy. Obie liczby opisują co innego i nie powinny być sobie równe.

Log błędów jest pusty, a strona nie działa. Co to oznacza?

Najczęściej zapis błędów PHP jest wyłączony albo trafia do innego pliku niż ten, który pokazuje panel. Należy sprawdzić ustawienia PHP w panelu, poszukać pliku error_log w katalogu strony, a w przypadku WordPressa włączyć na krótko zapis do pliku debug.log. Pusty log przy błędzie 404 lub 403 jest z kolei naturalny, bo te kody nie zawsze zostawiają wpis o błędzie.

Czy na podstawie adresu IP z logu da się ustalić, kto odwiedził stronę?

Z logu można odczytać jedynie adres i na jego podstawie ustalić operatora sieci oraz przybliżony region. Tożsamość osoby zna wyłącznie operator, który udostępnia takie dane na żądanie uprawnionych organów, w trybie przewidzianym przepisami. Przy podejrzeniu przestępstwa logi należy zabezpieczyć i przekazać policji lub prokuraturze wraz z zawiadomieniem.

Czym różni się log serwera od pliku debug.log w WordPressie?

Log serwera prowadzi hosting i obejmuje on całe konto lub domenę, niezależnie od tego, jaki system obsługuje stronę. Plik debug.log tworzy sam WordPress, tylko po włączeniu trybu diagnostycznego, i trafiają do niego wyłącznie błędy PHP powstałe podczas jego pracy. Oba źródła uzupełniają się, lecz na co dzień wystarcza log serwera.

Czy w logach widać, jakie dane klient wpisał w formularzu?

Standardowy log dostępu zapisuje adres żądania, a nie treść wysłaną metodą POST, więc zawartości pól formularza w nim nie ma. Wyjątkiem są dane przekazywane w samym adresie, po znaku zapytania. To jeden z powodów, dla których formularze z danymi osobowymi nie powinny wysyłać ich metodą GET.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Czytanie logów wymaga spokoju i odrobiny wprawy, a awaria strony rzadko przychodzi w dogodnej chwili. Mogę przejąć tę sprawę w całości: pobiorę logi z hostingu, odnajdę wpisy z chwili problemu, ustalę przyczynę, wprowadzę poprawkę albo przygotuję gotowe zgłoszenie do hostingu lub autora wtyczki, a na koniec sprawdzę w logach, czy błąd przestał się pojawiać. Wynik opiszę zwykłym językiem, bez technicznego żargonu.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i krótko opisać, co dzieje się ze stroną.