Logi serwera znajdziesz najczęściej w katalogach /var/log/apache2/ dla serwerów Apache lub /var/log/nginx/ dla środowisk Nginx, a na hostingach współdzielonych w panelach typu cPanel pod zakładką Raw Access Logs. Analizę tych plików powinieneś zacząć od użycia poleceń konsolowych takich jak grep czy tail, szukając wierszy z kodami HTTP 500 lub słowem error, co od razu wskaże przyczynę awarii aplikacji. Logi serwera – gdzie je znaleźć i jak analizować w poszukiwaniu błędów to pytanie, które zadaje sobie każdy administrator po pierwszej poważnej awarii na produkcji.
Pamiętam wdrożenie na warszawskim Mokotowie u dewelopera od nieruchomości. Zwykły portal z ofertami mieszkań. Piątek wieczór. Zrobiliśmy aktualizację bazy danych, po czym nagle koszyk z rezerwacjami przestał działać. Brak błędów na froncie. Zwykłe białe tło w przeglądarce. Wszedłem po SSH na maszynę. Rzuciłem proste polecenie tail -n 100 na error loga Nginxa i od razu zobaczyłem wyczerpany limit pamięci PHP przez jedną, źle napisaną wtyczkę do generowania PDF-ów. To jest bez mała najgorsza opcja z wszystkich. Wyłączenie tego modułu z palca zajęło mi dziesięć sekund. Bez dostępu do logów szukałbym tego w kodzie do rana.
Gdzie dokładnie leżą pliki z logami na różnych systemach operacyjnych?
Lokalizacja logów zależy od tego, jaki system operacyjny i jaki serwer WWW został zainstalowany na maszynie. Większość infrastruktury opiera się na dystrybucjach Linuxa takich jak Ubuntu, Debian czy CentOS. Prawda jest zresztą absolutnie taka, że struktura katalogów bywa powtarzalna, ale administratorzy potrafią ją mocno modyfikować w konfiguracji wirtualnych hostów.
Standardowe ścieżki wyglądają następująco. Tabela poniżej pokazuje twarde dane z domyślnych instalacji.
| Oprogramowanie | Domyślna ścieżka do logów dostępu (Access) | Domyślna ścieżka do logów błędów (Error) |
| Apache (Debian/Ubuntu) | /var/log/apache2/access.log | /var/log/apache2/error.log |
| Apache (CentOS/RHEL) | /var/log/httpd/access_log | /var/log/httpd/error_log |
| Nginx (Większość systemów) | /var/log/nginx/access.log | /var/log/nginx/error.log |
| Microsoft IIS (Windows) | %SystemDrive%\inetpub\logs\LogFiles | Zależne od konfiguracji Event Viewera |
Hostingi współdzielone ukrywają te ścieżki przed użytkownikiem. Zalogowanie się przez SSH często nie wchodzi w grę. Użytkownik dostaje panel DirectAdmin lub cPanel. Tam trzeba wejść w sekcję statystyk i pobrać spakowany plik tekstowy na dysk własnego komputera. A potem otworzyć go w Notatniku lub programie Notepad++. To boli przy dużych plikach. Otwieranie gigabajtowego pliku tekstowego na zwykłym laptopie kończy się zamrożeniem systemu na kilka minut. Wtedy CAŁY sprzęt po prostu staje.
Jak czytać surowy tekst z pliku access.log?
Surowy wiersz w logu dostępu wydaje się na pierwszy rzut oka nieczytelny. Format w Nginx i Apache jest jednak bardzo ustandaryzowany. Nazywa się to Combined Log Format. Zrozumienie jednego wiersza pozwala szybko filtrować ruch w poszukiwaniu anomalii.
Weźmy na warsztat typowy wpis. Adres IP klienta pojawia się na samym początku. Następnie widzimy datę i czas żądania ujęte w nawiasy kwadratowe. Dalej jest metoda HTTP, najczęściej GET lub POST, oraz ścieżka do pliku, o który prosi przeglądarka. Zaraz po tym serwer zwraca kod statusu HTTP. Na samym końcu widnieje User-Agent, czyli dokładny podpis przeglądarki internetowej lub bota skanującego stronę.
Widzisz adres IP z Chin, który generuje tysiąc zapytań POST na sekundę do pliku wp-login.php? Masz do czynienia z atakiem brute force. Odczytanie tego z pliku access.log zajmuje ułamek sekundy. Wystarczy zablokować ten IP na zaporze sieciowej iptables. I po problemie. System wraca do normy.
Jakie polecenia w terminalu Linux ratują życie przy awariach?
Grep to absolutna podstawa. Zwykłe otwieranie pliku logów w edytorze tekstowym mija się z celem, bo dane dopisują się tam w czasie rzeczywistym. Analiza logów serwera wymaga użycia odpowiednich narzędzi wiersza poleceń by odsiać szum informacyjny od faktycznych błędów.
Zrobiliśmy na wdrożeniu szybki test obciążeniowy, po czym serwer zaczął zwracać błędy. Użyliśmy kilku prostych komend, żeby zlokalizować problem.
- Zastosowanie polecenia tail z przełącznikiem -f pozwala na śledzenie pliku na żywo. Wpisujesz tail -f /var/log/nginx/error.log i patrzysz w monitor. Kiedy klient klika przycisk na stronie, ty widzisz w tej samej sekundzie, czy aplikacja wygenerowała błąd w kodzie PHP, czy też połączyła się z bazą poprawnie. To eliminuje zgadywanie.
- Polecenie awk. Służy do wyciągania konkretnych kolumn z tekstu.
- Grep z flagą -i oraz -v. Szukanie błędów polega na wpisaniu grep „500” access.log. Jeśli chcesz pominąć swój własny adres IP, dodajesz grep -v „Twój.IP”.
- Komenda less. Pozwala przewijać plik do góry i do dołu bez wczytywania całości do pamięci RAM.
Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Deweloperzy rzucają nowy kod, nie sprawdzają zależności, a potem serwer bazy danych odrzuca połączenia bo pula została wyczerpana. Logi błędów wypluwają wtedy komunikaty o zerwanym połączeniu. Wystarczy wpisać grep „Connection refused” i od razu widać, że to baza leży, a nie aplikacja webowa.
Jakie kody HTTP w logach zwiastują największe problemy?
Kody statusu HTTP to pierwsza rzecz, na którą musisz spojrzeć. Status 200 oznacza sukces. Status 301 to przekierowanie. Schody zaczynają się przy kodach z rodziny 4xx i 5xx. Analiza logów polega na wyłapywaniu właśnie tych wartości.
Błąd 500 Internal Server Error. To twój kod PHP, Python lub Node.js wywala się na pysk. Serwer WWW nie wie co się stało. Skrypt przerwał działanie, więc Nginx zwraca 500. Wtedy musisz bezwzględnie zajrzeć do pliku error.log, bo tam znajdziesz dokładną ścieżkę do pliku i numer linijki kodu, która spowodowała błąd. Często jest to literówka w składni, brakujący średnik albo wywołanie funkcji, która nie istnieje. W logu dostępu zobaczysz tylko sam fakt wystąpienia kodu 500. W logu błędów zobaczysz powód. Różnica jest kolosalna.
Błąd 502 Bad Gateway. Serwer Nginx działa jako reverse proxy i próbuje skontaktować się z aplikacją w tle, na przykład przez PHP-FPM. Aplikacja nie odpowiada. Proces umarł. Trzeba go zrestartować.
Błąd 404 Not Found. Użytkownik szuka pliku, którego nie ma na dysku.
Kod 403 Forbidden. Brak uprawnień do pliku lub katalogu. Chown i chmod rozwiązują sprawę od ręki.
Czy przy hostingu chmurowym ręczna analiza logów ma jeszcze sens?
To u nas w sumie chyba hipoteza z wczoraj bo pewności do tych trendów rynkowych nikt obecnie nie ma o 2025 r. Wszyscy mówią o narzędziach takich jak ELK Stack, czyli połączeniu Elasticsearch, Logstash i Kibana. Albo o Datadog i New Relic. Zbierają logi serwera ze stu różnych maszyn i wrzucają je do jednego, pięknego panelu z wykresami. Wpisujesz frazę w wyszukiwarkę i masz wynik ze wszystkich środowisk naraz.
Ale prawda jest taka, że postawienie ELK kosztuje czas i zasoby. Wymaga osobnych maszyn. Dla małego sklepu internetowego albo prostej aplikacji B2B to przerost formy nad treścią. Ręczne wejście po SSH i wpisanie grepa zawsze będzie szybsze w przypadku pojedynczych serwerów. Nie musisz czekać na przetworzenie danych przez zewnętrzne agenty. Widzisz plik. Czytasz plik. Poprawiasz kod aplikacji. Zmieniliśmy te zasady na robocie niedawno, bo utrzymanie klastra logującego pożerało nam prawie pięćdziesiąt procent zasobów sprzętowych całego projektu.
Jeżeli aplikacja generuje dziesiątki tysięcy błędów dziennie, to masz problem z architekturą, a nie z brakiem narzędzi do przeglądania logów. Zamiast budować skomplikowane systemy analityczne, lepiej po prostu zatrudnić programistę, który posprząta ten bałagan w kodzie źródłowym. Logi serwera – gdzie je znaleźć i jak analizować w poszukiwaniu błędów to podstawa pracy inżyniera systemowego. Ktoś, kto nie potrafi czytać pliku tekstowego, nie poradzi sobie z zaawansowaną analityką w chmurze AWS czy Google Cloud.
Przekierowanie strumienia logów do zewnętrznych usług bywa też problematyczne pod kątem RODO. W access.log zapisują się adresy IP klientów. Wysyłanie tego do amerykańskich serwerowni bez odpowiednich umów powierzenia przetwarzania danych osobowych to proszenie się o kłopoty. Trzymanie logów na własnym serwerze w Europie jest bezpieczniejsze prawnie. Aplikacja działa lokalnie, logi zostają lokalnie. Odpada cały proces anonimizacji adresów sieciowych przed ich eksportem.
Jak automatyzować rotację plików by nie zapchać dysku twardego?
Logi puchną. Zostawienie serwera bez konfiguracji rotacji logów to gwarancja awarii. Dysk zapełni się w sto procent w ciągu kilku tygodni. A systemy operacyjne Linux nienawidzą braku wolnego miejsca. Usługi po kolei zaczną odmawiać posłuszeństwa. Baza danych MySQL zatrzyma się pierwsza.
Narzędzie logrotate rozwiązuje ten problem systemowo. Znajdziesz jego konfigurację w katalogu /etc/logrotate.d/. Działa to z automatu. Codziennie o północy system bierze plik access.log, zmienia jego nazwę na access.log.1, a stary plik kompresuje do archiwum gzip. Po czternastu dniach najstarsze archiwa są kasowane na zawsze. Oszczędza to setki gigabajtów przestrzeni dyskowej.
Miałem przypadek, gdzie klient dzwonił z pretensjami, że strona nagle przestała działać. Loguje się na serwer. Wpisuję df -h. Widzę 100% zajętości na partycji root. Szukam największych plików poleceniem find / -type f -size +1G. Co znajduję? Plik error.log ważący 45 gigabajtów. Aplikacja sypała ostrzeżeniami PHP Notice przy każdym wejściu użytkownika na stronę główną. Logrotate nie był skonfigurowany. Usunięcie tego pliku i restart Nginxa przywróciły sklep do życia w dwie minuty.
Przestań polegać na zgadywaniu. Przestań resetować serwer z nadzieją, że problem magicznie zniknie. Idź, zaloguj się na maszynę, odpal terminal i użyj polecenia tail. Zobaczysz dokładnie to, co widzi twój serwer. Błędy nie ukrywają się w mroku. Są zapisane czarno na białym w plikach tekstowych na twoim własnym dysku. Musisz tylko chcieć je przeczytać.
Najczęściej zadawane pytania (FAQ)
- Gdzie znajdują się logi serwera Apache?
W systemach Ubuntu i Debian logi serwera Apache znajdziesz w katalogu /var/log/apache2/. Na systemach CentOS ścieżka to /var/log/httpd/. - Gdzie leżą logi serwera Nginx?
Domyślna lokalizacja logów Nginx na większości dystrybucji Linuxa to katalog /var/log/nginx/. Znajdziesz tam pliki access.log oraz error.log. - Jak sprawdzić błędy na żywo w terminalu?
Użyj polecenia tail -f /sciezka/do/pliku/error.log. Pozwala to na podgląd nowo dopisywanych wierszy w czasie rzeczywistym. - Co oznacza błąd 500 w logach serwera?
Kod 500 Internal Server Error oznacza krytyczny błąd po stronie aplikacji webowej, na przykład błąd składni w kodzie PHP lub problem z połączeniem do bazy danych. - Jak przefiltrować logi pod kątem konkretnego adresu IP?
Możesz użyć polecenia grep. Wpisz w terminalu grep 'ADRES_IP’ /var/log/nginx/access.log, aby wyciągnąć tylko wiersze dotyczące tego konkretnego klienta. - Dlaczego pliki logów zajmują całe miejsce na dysku?
Brak skonfigurowanego narzędzia logrotate powoduje, że pliki tekstowe rosną w nieskończoność. Należy włączyć automatyczną kompresję i usuwanie starych logów systemowych.
Bibliografia
1. Apache HTTP Server Project – https://httpd.apache.org
2. NGINX – https://nginx.org
3. The PHP Group – https://php.net
4. Ubuntu Documentation – https://ubuntu.com/server/docs
5. Debian Project – https://debian.org
