Logi serwera: jak czytać access log i error log

Zgłoszenie brzmi zawsze tak samo: strona nie działa. To nie jest diagnoza, tylko objaw, a odpowiedź na pytanie co się stało leży w logach. Serwer zapisuje tam każde żądanie i każdy błąd, więc zamiast zgadywać, wystarczy nauczyć się kilku poleceń. Poniżej pokazujemy, gdzie szukać, co dokładnie znaczą poszczególne pola i jak w minutę przejść od tysięcy linii do konkretnej przyczyny.

Dwa pliki, dwie różne historie

Access log zapisuje każde żądanie, które dotarło do serwera: kto przyszedł, o co poprosił i co dostał w odpowiedzi. Służy do odpowiadania na pytania o ruch, o to, kto generuje obciążenie i czy dane żądanie w ogóle doszło.

Error log zapisuje sytuacje, w których coś poszło nie tak po stronie serwera albo aplikacji. To tutaj znajdziesz komunikaty PHP, problemy z uprawnieniami i błędy konfiguracji.

Kolejność przy diagnostyce jest zwykle odwrotna do intuicyjnej: zacznij od error loga, bo on wprost mówi o przyczynie, a do access loga sięgnij po kontekst.

Na hostingu współdzielonym logi znajdziesz w panelu, gdzie DirectAdmin udostępnia je w sekcji statystyk i dzienników, a o samym panelu pisaliśmy we wpisie o panelu DirectAdmin. Na własnym serwerze standardowe lokalizacje to /var/log/apache2/ albo /var/log/nginx/.

Anatomia jednej linii

Typowy wpis w access logu wygląda tak:

192.0.2.10 - - [08/Oct/2026:14:22:31 +0200] "GET /sklep/produkt-a HTTP/1.1" 200 15423 "https://google.com/" "Mozilla/5.0 ..."

Po kolei: adres klienta, znacznik czasu ze strefą, metoda i żądany zasób, kod odpowiedzi, liczba przesłanych bajtów, adres strony odsyłającej i identyfikator przeglądarki.

Dwa pola mówią najwięcej. Kod odpowiedzi przesądza o tym, czy żądanie się powiodło, a jego znaczenie rozpisaliśmy we wpisie o kodach odpowiedzi HTTP. Liczba bajtów bywa niedoceniana: odpowiedź o rozmiarze zerowym przy kodzie 200 oznacza, że serwer odpowiedział poprawnie, ale nie wysłał treści, co zwykle wskazuje na przerwane wykonanie skryptu.

Pięć poleceń, które załatwiają większość analiz

Ostatnie sto linii, czyli pierwsze miejsce, do którego warto zajrzeć:

tail -n 100 /var/log/nginx/error.log

Podgląd na żywo podczas odtwarzania błędu w przeglądarce:

tail -f /var/log/nginx/error.log

Rozkład kodów odpowiedzi, który od razu pokazuje skalę problemu:

awk '{print $9}' access.log | sort | uniq -c | sort -rn

Adresy generujące najwięcej żądań, przydatne przy podejrzeniu nadmiernego ruchu:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

Najczęściej zwracane błędy serwera, żeby wiedzieć, która podstrona się wywala:

awk '$9 == 500 {print $7}' access.log | sort | uniq -c | sort -rn | head

Te pięć poleceń pokrywa zdecydowaną większość realnych zgłoszeń. Trzecie z nich uruchamiaj jako pierwsze: jeśli kodów 500 jest kilka na tysiąc żądań, masz drobiazg, a jeśli stanowią połowę, masz awarię.

Co jest szumem, a co problemem

Świeżo uruchomiony serwer natychmiast zaczyna zbierać żądania o nieistniejące zasoby: próby wejścia na panele administracyjne, pliki konfiguracyjne, kopie baz danych. To normalne tło internetu i samo w sobie nie jest powodem do niepokoju, o ile kończy się kodem 404.

Zaniepokoić powinno co innego:

1. Kod 200 na adresie, którego nie ma w Twoim serwisie, bo to znaczy, że coś tam odpowiada.
2. Żądania metodą POST na plikach, które nie powinny nic przyjmować.
3. Ten sam adres z setkami żądań w krótkim czasie, zwłaszcza na stronie logowania.
4. Kody 500 pojawiające się regularnie o stałej porze, co zwykle wskazuje na zadanie cykliczne.
5. Nagły wzrost liczby żądań bez odpowiadającego wzrostu w statystykach odwiedzin.

Punkt czwarty bywa najtrudniejszy do wyśledzenia bez logów, bo objaw zgłaszany przez użytkowników to po prostu wolna strona o poranku.

Log PHP bywa ważniejszy od loga serwera

Serwer WWW zapisze, że skrypt zwrócił błąd, ale przyczynę zna wyłącznie sam interpreter. Dlatego przy problemach z WordPressem albo własną aplikacją zaglądaj do dziennika PHP, a przy diagnozowaniu włącz w WordPressie zapis błędów do pliku:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Trzecia linia jest obowiązkowa na serwisie produkcyjnym, bo wyświetlanie błędów użytkownikom ujawnia ścieżki na serwerze i wersje komponentów. Błędy trafią do pliku wp-content/debug.log, a po zakończeniu diagnostyki pamiętaj o wyłączeniu zapisu, bo plik potrafi urosnąć bardzo szybko.

Zanim logi zapchają dysk

Logi rosną nieustannie i na serwerze bez rotacji potrafią zająć całą wolną przestrzeń, co kończy się awarią trudną do zdiagnozowania, bo nic już nie może zapisać. Na własnej maszynie standardowo zajmuje się tym logrotate, warto jednak sprawdzić, czy obejmuje wszystkie pliki, w tym te tworzone przez aplikację.

Rozsądny punkt wyjścia to rotacja dzienna, kompresja i przechowywanie od czternastu do trzydziestu dni. Przy okazji ustaw monitorowanie zajętości dysku z alertem przy 80%, bo to ostrzeżenie przychodzi zwykle dużo wcześniej niż jakiekolwiek inne.

Podsumowanie

Analiza logów serwera zamienia zgadywanie w czytanie. Zacznij od stu ostatnich linii error loga, sprawdź rozkład kodów odpowiedzi, znajdź adres albo podstronę odpowiedzialną za problem i dopiero wtedy szukaj przyczyny w kodzie.

Na hostingu RapidDC dzienniki masz w panelu DirectAdmin bez dodatkowej konfiguracji. Na serwerze VPS z dostępem root dochodzi pełna kontrola nad tym, co i jak długo jest zapisywane, oraz możliwość podpięcia własnych narzędzi analitycznych. Jeśli problem dotyczy samego połączenia z maszyną, pomoże wpis o najczęstszych błędach VPS.

FAQ – najczęściej zadawane pytania o logi serwera

Jak długo przechowywać logi?

Od czternastu do trzydziestu dni wystarcza do diagnostyki bieżących problemów. Dłuższe okresy mają sens tylko wtedy, gdy wymagają tego procedury wewnętrzne, i wówczas lepiej archiwizować logi poza serwerem produkcyjnym.

Czy logi zawierają dane osobowe?

Adres IP jest daną osobową w rozumieniu przepisów o ochronie danych, więc logi podlegają tym samym zasadom co inne zbiory. W praktyce oznacza to ograniczony czas przechowywania i kontrolę nad tym, kto ma do nich dostęp.

Dlaczego w logu widzę żądania o pliki, których nie mam?

To automatyczne skanowanie, które dotyczy każdego publicznego adresu. Dopóki takie żądania kończą się kodem 404, nie dzieje się nic złego. Niepokojący jest dopiero kod 200 na adresie, którego nie powinno być.

Czym różni się access log od statystyk odwiedzin?

Access log zapisuje każde żądanie, łącznie z robotami, skanerami i plikami graficznymi. Statystyki próbują liczyć ludzi i odfiltrowują resztę. Rozbieżność między nimi jest normalna i zwykle bardzo duża.

Czy na hostingu współdzielonym mam dostęp do logów?

Tak, przez panel, choć zwykle w węższym zakresie niż na własnym serwerze i za krótszy okres. Pełną kontrolę nad zapisem, rotacją i retencją daje dopiero VPS z dostępem root.

---

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu RapidDC. Grafika ilustracyjna została wygenerowana przez AI.