Czym są logi serwera i dlaczego są kluczowe w diagnostyce

Logi serwera to techniczny zapis zdarzeń, które zachodzą w trakcie działania strony i infrastruktury. Można je traktować jak czarną skrzynkę serwera: nie pokazują wyglądu awarii, ale rejestrują to, co wydarzyło się tuż przed nią, w jej trakcie i po niej.

W praktyce logi pomagają ustalić, czy problem wynika z aplikacji, konfiguracji serwera, zasobów hostingu, bazy danych, uprawnień do plików czy np. konfliktu wtyczki. Dzięki nim da się odróżnić pojedynczy incydent od powtarzalnego wzorca, który wskazuje na konkretną przyczynę awarii strony.

To ważne rozróżnienie, bo sam komunikat widoczny dla użytkownika zwykle jest bardzo ogólny. Strona może pokazać 500 Internal Server Error albo po prostu biały ekran, ale dopiero logi ujawniają szczegóły: nazwę pliku, linię kodu, czas odpowiedzi, błąd połączenia z bazą czy przekroczony limit pamięci.

Największa wartość logów polega na tym, że dokumentują zdarzenia w kolejności chronologicznej. Jeśli znasz moment, w którym strona przestała działać, możesz szybko zawęzić analizę i sprawdzić, co działo się kilka sekund lub minut wcześniej. To często wystarcza, by znaleźć punkt zapalny całego problemu.

W diagnostyce warto pamiętać o kilku typowych klasach problemów, które logi ujawniają najczęściej:

• błędy aplikacji — wyjątki, błędy skryptów, nieudane zapytania;
• przeciążenie — timeouty, limit procesów, brak pamięci lub CPU;
• brak uprawnień — niedostępne pliki, katalogi lub procesy;
• problemy z bazą danych — brak połączenia, błędne dane logowania, zbyt wolne zapytania;
• konflikty wtyczek lub modułów — szczególnie w CMS-ach i aplikacjach rozbudowanych;
• błędy konfiguracji — niepoprawne reguły serwera, przekierowania, limity lub ścieżki.

Im szybciej nauczysz się czytać logi w kontekście całej awarii, tym łatwiej odróżnisz objaw od przyczyny. W praktyce nie chodzi o znalezienie jednego „magicznego” wpisu, ale o zbudowanie pełnego obrazu zdarzeń.

Gdzie szukać logów: hosting, panel administracyjny, SSH i katalogi systemowe

To, gdzie znajdują się logi serwera, zależy od typu hostingu i zakresu uprawnień. Na współdzielonym hostingu zwykle masz dostęp tylko do wybranych plików przez panel administracyjny, a na VPS lub serwerze dedykowanym możesz wejść głębiej: przez SSH, do katalogów usług i logów systemowych.

W praktyce najlepiej zacząć od miejsc, które są dostępne bezpośrednio z poziomu panelu hostingu. W wielu panelach logi są pod nazwami typu Logi błędów, Error log, Dzienniki albo Statystyki. Czasem dostępne są też osobne sekcje dla domen, poddomen i usług PHP, więc warto sprawdzić każdą z nich osobno, zwłaszcza jeśli awaria dotyczy konkretnej części serwisu.

Jeśli masz dostęp do SSH, możliwości są znacznie większe. Możesz przejrzeć pliki logów bezpośrednio w systemie, użyć wyszukiwania po czasie lub filtrów i szybko porównać kilka źródeł informacji. W środowiskach Linux najczęściej spotyka się logi serwera WWW, PHP-FPM, aplikacji i systemowe, a ich położenie zależy od dystrybucji, konfiguracji hostingu i używanego stacku.

Najczęściej spotykane lokalizacje i źródła to:

• Apache — error log i access log, zwykle w katalogach związanych z konfiguracją wirtualnych hostów lub w ścieżkach systemowych typu /var/log/apache2/ albo /var/log/httpd/;
• Nginx — zazwyczaj /var/log/nginx/, gdzie osobno występują logi dostępu i błędów;
• PHP-FPM — logi procesu PHP, często w katalogach /var/log/ lub w lokalizacjach zdefiniowanych w konfiguracji puli;
• logi aplikacji — zależne od CMS-a lub frameworka, często w katalogach storage/logs, var/log albo w dedykowanych folderach aplikacji;
• logi systemowe — przydatne przy problemach z zasobami, błędami usług lub restartami, np. w /var/log/syslog, /var/log/messages lub przez journalctl.

W przypadku CMS-ów i popularnych aplikacji warto pamiętać, że część logów nie trafia do ogólnego logu serwera WWW. Błędy PHP, wyjątki aplikacyjne, problemy z bazą danych czy błędne zadania CRON mogą być zapisywane lokalnie przez samą aplikację. Jeśli po awarii strona pokazuje pusty ekran albo ogólny błąd 500, log aplikacyjny bywa równie ważny jak error log serwera.

Jeżeli hosting ukrywa logi albo pokazuje tylko ich skrócony fragment, sprawdź trzy rzeczy: czy panel nie ma osobnej zakładki diagnostycznej, czy masz dostęp do plików przez SFTP/SSH oraz czy usługa nie wymaga zgłoszenia do supportu. W środowiskach współdzielonych dostawca często ogranicza wgląd do pełnych logów ze względów bezpieczeństwa i wydajności. Wtedy najlepiej poprosić o wycinek logu z konkretnego przedziału czasowego, podając dokładną godzinę, domenę i objaw awarii.

Przy kontakcie z pomocą techniczną warto sformułować prośbę możliwie precyzyjnie, na przykład: strona zwraca błąd 500 od godziny 14:20, problem dotyczy konkretnego adresu URL, a ostatnia zmiana obejmowała aktualizację wtyczki lub konfiguracji. Taki opis znacząco przyspiesza udostępnienie właściwych logów i ogranicza liczbę wymian wiadomości.

Jeśli nie wiesz, gdzie zacząć, działaj według prostego porządku: najpierw panel hostingu, potem pliki przez FTP/SFTP, następnie SSH, a na końcu logi systemowe lub odpowiedź supportu. Dzięki temu nie tracisz czasu na przeszukiwanie całej infrastruktury, tylko stopniowo zawężasz obszar diagnostyki.

Najważniejsze typy logów i co z nich wynika

W diagnostyce awarii strony nie wystarczy wiedzieć, że „coś się zepsuło”. Trzeba ustalić, który log pokaże pierwszy ślad problemu i jak go połączyć z objawem widocznym dla użytkownika. Różne warstwy infrastruktury zapisują różne informacje, dlatego każdy typ logu wnosi coś innego do analizy.

Najczęściej zaczyna się od dwóch źródeł: access log i error log. Pierwszy pokazuje, jakie żądania trafiają do serwera i jakie odpowiedzi zwraca aplikacja lub serwer WWW. Drugi rejestruje błędy, ostrzeżenia i sytuacje nietypowe, które zwykle są bliżej przyczyny awarii niż sam komunikat wyświetlany na stronie.

W praktyce warto znać kilka podstawowych kategorii logów:

• Access log — rejestr żądań HTTP, przydatny do sprawdzania, które adresy URL zwracają błędy i czy awaria dotyczy całej strony, czy tylko jednej podstrony;
• Error log — log błędów serwera WWW, w którym często widać problemy z konfiguracją, brakiem pliku, uprawnieniami lub przekierowaniami;
• Logi PHP — szczególnie ważne przy błędach 500, ponieważ pokazują wyjątki, fatal errors, błędy pamięci i problemy z wykonaniem skryptu;
• Logi aplikacyjne — prowadzone przez CMS lub framework; mogą zawierać stack trace, błędy zapytań do bazy i informacje o konkretnym module;
• Logi bazy danych — pomocne przy problemach z połączeniem, blokadach, wolnych zapytaniach i błędach uprawnień do bazy;
• Logi systemowe — przydatne, gdy problem wynika z zasobów serwera, restartu usługi, błędu dysku albo ograniczeń systemu operacyjnego.

Każdy z tych logów zawiera trochę inne dane, ale wiele wpisów ma podobną strukturę. Najczęściej pojawiają się w nich:

• adres IP klienta lub źródła żądania,
• data i godzina zdarzenia,
• kod odpowiedzi HTTP,
• adres URL lub ścieżka do zasobu,
• komunikat błędu,
• identyfikator procesu, wątku lub żądania.

To, który log sprawdzić najpierw, zależy od objawu. Jeśli strona zwraca 500 lub biały ekran, w pierwszej kolejności warto przejrzeć error log i logi PHP. Jeśli problem dotyczy niedostępności tylko jednej podstrony, pomocny będzie access log, bo pokaże, czy konkretne URL-e zwracają błędy. Gdy awaria występuje nieregularnie, warto dołączyć też logi aplikacyjne i systemowe, aby sprawdzić, czy nie ma problemu z zasobami albo usługami pomocniczymi.

Przy pracy z logami ważne jest także rozróżnienie między objawem a źródłem problemu. Na przykład w access logu możesz zobaczyć serię odpowiedzi 500, ale to tylko sygnał, że żądanie się nie powiodło. Prawdziwa przyczyna zwykle znajduje się w error logu, logach PHP albo logach aplikacji. Z kolei komunikat z bazy danych może wskazywać tylko skutek wcześniejszego błędu konfiguracji lub przeciążenia serwera.

W praktyce najwięcej informacji dają logi czytane razem, a nie osobno. Jeśli w tym samym czasie w access logu pojawiają się powtarzające się 502 dla jednego endpointu, a w error logu widzisz timeout lub problem z połączeniem do backendu, zaczynasz mieć spójny obraz awarii. To właśnie takie połączenie źródeł pozwala szybko zawęzić obszar poszukiwań.

Jak czytać pojedynczy wpis w logu i nie zgubić kontekstu

Pojedynczy wpis w logu ma sens tylko wtedy, gdy odczytujesz go jako część większego ciągu zdarzeń. Sam komunikat błędu bywa krótki i pozornie oczywisty, ale dopiero zestawienie go z czasem, źródłem oraz kodem odpowiedzi pozwala ustalić, czy problem dotyczy aplikacji, serwera WWW, bazy danych czy warstwy sieciowej.

Najczęściej wpis w logu składa się z kilku stałych elementów:

• data i godzina — wskazują moment, w którym wystąpił problem;
• poziom zdarzenia — np. warning, error, critical lub fatal;
• źródło — proces, moduł, plik albo usługa, która zapisała wpis;
• treść komunikatu — opis tego, co się stało;
• kod statusu HTTP — jeśli błąd dotyczy odpowiedzi serwera;
• identyfikator żądania lub procesu — pomocny przy łączeniu wpisów z różnych logów.

Przykładowo wpis z komunikatem o błędzie PHP może wyglądać niepozornie, ale zawierać kluczowe informacje: nazwę pliku, numer linii, typ wyjątku i opis problemu. Dzięki temu możesz szybko ustalić, czy awaria wynika z konkretnego skryptu, błędnej konfiguracji czy np. braku zasobu na serwerze.

Duże znaczenie mają też kody HTTP, bo pokazują ogólny charakter problemu. W praktyce najczęściej analizuje się:

• 403 Forbidden — dostęp został zablokowany, zwykle przez uprawnienia, reguły bezpieczeństwa lub konfigurację;
• 404 Not Found — zasób nie istnieje albo ścieżka jest błędna;
• 500 Internal Server Error — błąd po stronie aplikacji lub serwera;
• 502 Bad Gateway — serwer pośredniczący nie uzyskał poprawnej odpowiedzi od backendu;
• 503 Service Unavailable — usługa jest chwilowo niedostępna, często przez przeciążenie lub konserwację;
• 504 Gateway Timeout — backend nie odpowiedział w wymaganym czasie.

Same kody nie mówią jeszcze wszystkiego, ale bardzo zawężają obszar poszukiwań. Jeśli w access logu pojawia się seria 502 lub 504, warto sprawdzić, czy problem dotyczy backendu, PHP-FPM, bazy danych albo zbyt długiego czasu odpowiedzi aplikacji. Jeśli widać 403, przyczyną częściej są uprawnienia, reguły w .htaccess lub blokada na poziomie konfiguracji serwera.

Warto też odróżniać warning, error, exception i fatal error. Ostrzeżenie nie zawsze zatrzymuje działanie strony, ale może być sygnałem nadchodzącego problemu. Wyjątek zwykle oznacza, że kod napotkał sytuację, której nie potrafił obsłużyć. Z kolei fatal error oznacza błąd krytyczny, który przerywa wykonanie skryptu i często prowadzi do widocznej awarii.

Nie wolno też ignorować kontekstu czasowego. Logi mogą mieć inną strefę czasową niż panel administracyjny, przeglądarka czy system lokalny administratora. Jeśli awaria wystąpiła o 14:20 czasu lokalnego, a serwer zapisuje logi w UTC, wpis trzeba przeliczyć, zanim zaczniesz porównywać go z historią zmian lub zgłoszeniami użytkowników. W praktyce najlepiej sprawdzać kilka minut przed i po awarii, a nie tylko dokładną minutę, w której strona przestała działać.

Dobrym nawykiem jest czytanie jednego wpisu razem z kilkoma następnymi i poprzednimi. Pojedyncza linia może pokazać skutek, ale sąsiednie wpisy często ujawniają źródło: wcześniejsze ostrzeżenie, próbę połączenia z bazą, powtarzający się timeout albo błąd dostępu do pliku. To właśnie taki szerszy kontekst pomaga nie zgubić się w szczegółach i nie wyciągnąć błędnego wniosku z jednego, wyrwanego z ciągu zdarzenia.

Jeśli chcesz szybko ocenić wpis, zadawaj sobie trzy pytania: co się stało, w którym miejscu i czy problem się powtarza. Ta prosta sekwencja pozwala przejść od pojedynczej linii do realnej diagnozy awarii strony.

Proces diagnozy krok po kroku: od objawu do przyczyny

Skuteczna analiza logów nie polega na przypadkowym przeglądaniu setek linii, lecz na zawężaniu obszaru poszukiwań. Najlepiej zacząć od objawu widocznego dla użytkownika, a dopiero potem przechodzić do wpisów technicznych, które ten objaw tłumaczą. Dzięki temu szybciej oddzielisz skutki od źródeł problemu.

Dobry proces diagnostyczny warto prowadzić według stałej sekwencji:

1. ustal dokładny moment awarii — zapisz godzinę, datę i strefę czasową, w której strona przestała działać;
2. sprawdź kod odpowiedzi HTTP — 500, 502, 503, 504, 403 lub 404 od razu zawężają typ problemu;
3. przejrzyj wpisy z kilku minut przed i po awarii — pojedyncza linia rzadko daje pełny obraz;
4. szukaj powtarzających się komunikatów — ten sam błąd w wielu żądaniach zwykle wskazuje na trwałą przyczynę, a nie jednorazowy incydent;
5. porównaj logi z ostatnimi zmianami — aktualizacja wtyczki, zmiana konfiguracji, nowy certyfikat lub modyfikacja reguł mogą wywołać awarię;
6. zawęź problem do konkretnego URL, skryptu lub komponentu — to pozwala określić, czy awaria dotyczy całej strony, czy tylko jednej funkcji.

W praktyce bardzo pomaga analiza według wzorców. Jeśli błąd pojawia się wyłącznie na jednym endpointcie, prawdopodobnie problem leży w kodzie tej funkcji, zapytaniu do bazy albo konfiguracji zależnej od konkretnej ścieżki. Jeśli awaria dotyczy wielu adresów jednocześnie, bardziej prawdopodobne są ograniczenia zasobów, problem z backendem, PHP-FPM, serwerem WWW albo warstwą pośrednią, taką jak cache czy CDN.

Ważne jest też porównanie różnych typów logów. Access log pokaże, które żądania kończą się błędami i czy wzrasta liczba nieudanych odpowiedzi. Error log dostarczy szczegółów o przyczynie, na przykład timeoutu, braku pliku, błędnej konfiguracji lub problemu z backendem. Jeśli to nie wystarczy, dołącz logi PHP, aplikacyjne, bazodanowe i systemowe, aby sprawdzić, czy awaria nie zaczęła się niżej w stosie zależności.

Przy diagnozie dobrze działa metoda eliminacji. Zamiast pytać „co mogło się zepsuć?”, lepiej pytać kolejno:

• czy problem dotyczy wszystkich użytkowników czy tylko części ruchu,
• czy dotyczy całej strony czy jednego zasobu,
• czy występuje stale czy tylko przy określonym obciążeniu,
• czy zaczął się po zmianie w kodzie, konfiguracji lub infrastrukturze.

Taka kolejność pozwala szybko odrzucać mało prawdopodobne hipotezy. Na przykład jeśli awaria pojawia się tylko przy zapisie formularza, a pozostałe podstrony działają poprawnie, nie ma sensu od razu zakładać globalnego problemu serwera. Bardziej prawdopodobny jest błąd w jednym module, wtyczce, zapytaniu do bazy danych lub regule walidacji.

Warto też szukać zależności czasowych. Jeżeli pierwszy błąd pojawił się kilka sekund po wdrożeniu, restarcie usługi albo zmianie rekordu DNS, to właśnie tam należy szukać przyczyny. Logi pokazują wtedy nie tylko sam błąd, ale również sekwencję zdarzeń prowadzących do awarii. To szczególnie ważne przy problemach okresowych, które znikają po odświeżeniu strony, ale wracają pod obciążeniem.

Przy analizie nie wolno wyciągać wniosków z jednego wpisu wyrwanego z kontekstu. Jeśli w logu pojawia się np. 502, to jeszcze nie znaczy, że winny jest serwer proxy. Trzeba sprawdzić, czy wcześniej backend nie zwracał 500, czy nie było timeoutu po stronie PHP, czy baza danych odpowiadała wystarczająco szybko i czy aplikacja nie generowała błędów przed chwilą widoczną w access logu. Dopiero po połączeniu tych śladów można mówić o realnej przyczynie awarii.

Najbardziej praktyczne jest podejście: objaw → zakres → wzorzec → przyczyna. Najpierw widzisz, co nie działa. Potem określasz, gdzie problem występuje. Następnie sprawdzasz, czy błąd się powtarza i w jakim układzie. Na końcu łączysz to z ostatnimi zmianami i konkretnym komponentem systemu. Taki sposób pracy oszczędza czas i znacząco zwiększa szansę na trafną diagnozę.

Najczęstsze przyczyny awarii widoczne w logach

Gdy masz już dostęp do logów, następny krok to rozpoznanie źródła awarii, a nie tylko samego komunikatu. W praktyce większość problemów da się przypisać do kilku powtarzalnych scenariuszy. Jeśli nauczysz się je odróżniać, szybciej zawęzisz diagnozę i unikniesz zgadywania.

Poniżej znajdziesz najczęstsze przyczyny, które widać w logach serwera, PHP, aplikacji lub systemu, oraz typowe ślady, jakie po sobie zostawiają.

• Błędy konfiguracji serwera — zwykle pojawiają się jako komunikaty o nieprawidłowej składni, błędnych dyrektywach, braku pliku konfiguracyjnego lub konflikcie reguł. W logach często widać wtedy odwołanie do konkretnego pliku i numeru linii, a także informację, że usługa nie mogła się poprawnie przeładować.
• Wyczerpane zasoby CPU lub RAM — objawiają się timeoutami, spadkiem wydajności, przerwanymi połączeniami albo błędami o zabiciu procesu przez system. W logach systemowych możesz zobaczyć wzmianki o out of memory, wysokim obciążeniu lub restartach usług.
• Problemy z uprawnieniami do plików — serwer nie może odczytać, zapisać lub wykonać pliku. W logach pojawiają się komunikaty typu permission denied, access denied albo informacje o braku dostępu do katalogu, pliku tymczasowego czy cache.
• Przekroczony limit pamięci PHP — częsty powód błędu 500 albo białego ekranu. W logach PHP pojawia się wtedy zwykle komunikat o allowed memory size exhausted, czasem wraz z nazwą skryptu i linią, na której wykonanie się zatrzymało.
• Timeouty — aplikacja lub backend nie odpowiadają wystarczająco szybko. W praktyce oznacza to 502, 503 lub 504, a w logach można znaleźć wzmianki o przekroczonym czasie oczekiwania na odpowiedź, rozłączonym upstreamie albo zbyt wolnym zapytaniu do bazy.
• Błędy połączenia z bazą danych — logi pokazują brak połączenia, błędny host, złą nazwę użytkownika, brak dostępu do bazy albo zbyt dużo równoległych połączeń. W aplikacjach często towarzyszą temu wyjścioe i stack trace wskazujące, że odczyt danych się nie powiódł.
• Brakująca wtyczka, moduł lub zależność — w logach pojawiają się komunikaty o nieznanej klasie, brakującym pliku, niemożności załadowania modułu lub błędzie autoloadingu. To częste po aktualizacjach, migracjach albo ręcznych zmianach w kodzie.
• Nieprawidłowe reguły w .htaccess lub konfiguracji routingu — prowadzą do pętli przekierowań, błędnych ścieżek, 403 lub 404. W logach widać wtedy powtarzające się przekierowania, blokady dostępu lub problem z interpretacją URL.
• Błędy przekierowań — objawiają się wielokrotnym przeskakiwaniem między adresami, a w access logu często widać serię kolejnych żądań do tych samych domen lub ścieżek. Jeśli przekierowanie jest pętlą, użytkownik może nawet nie dotrzeć do końcowej strony.
• Awarie CDN lub cache — z perspektywy logów serwera mogą wyglądać jak losowe błędy, bo część ruchu trafia do źródła, a część do warstwy pośredniej. Wpisy pokazują wtedy niespójne odpowiedzi, błędne nagłówki, niezgodność wersji zasobów albo okresowe 502/504.

Warto zapamiętać prostą zasadę: jeden objaw może mieć kilka potencjalnych przyczyn, ale logi zwykle zdradzają, na której warstwie zaczął się problem. Jeśli widzisz 500, nie zakładaj od razu błędu kodu. Jeśli pojawiają się 502 lub 504, sprawdź najpierw backend, PHP-FPM, bazę danych i czas odpowiedzi. Jeśli masz 403 lub 404, przyczyna częściej leży w uprawnieniach, ścieżkach albo regułach serwera niż w samej aplikacji.

Dobrym nawykiem jest też łączenie wpisów z różnych źródeł. Na przykład:

• access log pokazuje serię błędów na jednym adresie URL,
• error log wskazuje timeout lub brak pliku,
• log PHP ujawnia przekroczenie pamięci,
• log systemowy pokazuje wysokie obciążenie lub restart usługi.

Dopiero taki zestaw daje pełny obraz awarii. Pojedynczy wpis najczęściej jest tylko fragmentem historii, a nie całą odpowiedzią.

Jeśli chcesz szybko ocenić przyczynę problemu, zacznij od pytania: co zmieniło się tuż przed awarią? Nowa wtyczka, aktualizacja, modyfikacja konfiguracji, wyczerpanie zasobów albo zmiana reguł routingu bardzo często tłumaczą to, co logi pokazują jako pierwszy widoczny błąd.

Jak wyciągać wnioski i przygotować materiał dla supportu lub administratora

Gdy już zidentyfikujesz podejrzany wpis, najważniejsze jest przejście od obserwacji do konkretnego wniosku. Sam fragment logu rzadko wystarcza do naprawy strony — trzeba jeszcze połączyć go z czasem awarii, adresem URL, ostatnimi zmianami i informacją, który komponent mógł wywołać problem.

W praktyce przygotuj zestaw danych, który pozwoli administratorowi lub supportowi odtworzyć sytuację bez zgadywania. Im bardziej precyzyjny opis, tym szybciej da się potwierdzić przyczynę i zaproponować rozwiązanie.

• dokładny czas awarii — najlepiej z uwzględnieniem strefy czasowej;
• adres URL lub ścieżka, której dotyczy problem;
• fragment logu z kilku linii przed i po błędzie;
• kod HTTP lub treść komunikatu widocznego dla użytkownika;
• ostatnie zmiany na stronie, wtyczkach, konfiguracji lub deploymencie;
• wersje oprogramowania — CMS, PHP, serwer WWW, baza danych, wtyczki i moduły;
• środowisko występowania — produkcja, staging, tylko jeden serwer, tylko jeden endpoint.

Jeśli log zawiera dane wrażliwe, nie udostępniaj go w całości bez potrzeby. Wiele wpisów może zawierać adresy IP, identyfikatory sesji, tokeny, parametry zapytań, nazwy użytkowników albo fragmenty danych klientów. Przed wysłaniem warto więc:

• usunąć lub zamaskować tokeny, hasła i klucze API;
• ukryć dane osobowe, jeśli nie są niezbędne do diagnozy;
• zostawić czas, URL, kod błędu i komunikat techniczny, bo to zwykle wystarcza;
• ograniczyć wycinek logu do konkretnego przedziału czasowego zamiast przekazywać pełne archiwum.

Dobrze sformułowane zgłoszenie powinno brzmieć technicznie, ale zwięźle. Zamiast pisać ogólnie, że „strona nie działa”, podaj, co dokładnie się dzieje i od kiedy. Na przykład:

„Od 14:20 czasu lokalnego strona /koszyk zwraca błąd 500. W error logu pojawia się komunikat o przekroczeniu pamięci PHP, a problem zaczął się po aktualizacji wtyczki do wersji X.Y.”

Taki opis od razu zawęża obszar sprawdzania. Administrator wie, czy szukać w logach PHP, konfiguracji, kodzie aplikacji czy w ostatnich wdrożeniach. Z kolei support hostingu może szybciej wyodrębnić właściwy fragment logów serwera i potwierdzić, czy problem leży po ich stronie, czy w aplikacji.

Warto też dołączyć informację o tym, co już zostało sprawdzone. Jeśli wykluczyłeś błąd przeglądarki, cache po stronie użytkownika, zmianę DNS lub jednorazowy spike ruchu, napisz o tym. To oszczędza czas i zmniejsza ryzyko powtarzania tych samych testów.

Jeśli zgłaszasz problem do supportu hostingu, trzymaj się schematu:

1. krótki opis objawu;
2. dokładny czas wystąpienia;
3. adres domeny i URL;
4. fragment logu lub numer błędu;
5. informacja o ostatniej zmianie;
6. prośba o weryfikację konkretnego zakresu czasu.

Tak przygotowany materiał pozwala szybciej połączyć logi z realnym zdarzeniem i zwykle znacząco skraca czas diagnozy. W praktyce to właśnie jakość zgłoszenia często decyduje o tym, czy problem zostanie rozwiązany w jednej odpowiedzi, czy po wielu dodatkowych pytaniach.

FAQ

Od czego zacząć analizę logów, gdy strona przestała działać?

Najpierw ustal dokładny czas problemu i sprawdź error log oraz kody odpowiedzi HTTP z access logu. Następnie porównaj wpisy z ostatnimi zmianami na stronie i zawęź problem do konkretnego URL lub komponentu.

Który log jest najważniejszy przy błędzie 500?

W pierwszej kolejności sprawdź error log serwera i logi PHP, bo błąd 500 zwykle oznacza problem po stronie aplikacji lub konfiguracji. Jeśli to nie wystarczy, dołącz logi bazy danych i systemowe.

Jak odróżnić problem serwera od błędu aplikacji?

Błędy serwera częściej pojawiają się w error logach WWW, PHP-FPM lub systemowych jako timeout, brak zasobów albo problem z konfiguracją. Błędy aplikacji częściej zawierają stack trace, wyjątki, problemy z zapytaniami do bazy lub błędy w kodzie.

Czy access log też pomaga w diagnozie awarii?

Tak, bo pokazuje, które adresy URL zwracają błędy, z jakich IP przychodzą żądania i o jakiej porze problem występuje. To przydatne do wykrycia ataku, pętli przekierowań, przeciążenia lub awarii tylko jednej podstrony.

Co zrobić, jeśli logi są ucięte albo niedostępne w panelu hostingu?

Sprawdź, czy hosting udostępnia pełne logi przez SSH lub osobny panel diagnostyczny. Jeśli nie, poproś support o wycinek logów z konkretnego przedziału czasowego i wskaż dokładny objaw awarii.

Sprawdź logi krok po kroku i wyciągnij z nich konkretne wskazówki, zanim zgłosisz awarię do hostingu lub programisty.