Jak analizować logi błędów PrestaShop

Stabilny sklep to nie tylko ładny szablon i szybka dostawa, ale też kontrola nad tym, co dzieje się pod spodem. Jeśli prowadzisz sklep na PrestaShop, umiejętność sprawnego analizowania logi to jeden z najważniejszych nawyków administracyjnych. Wpisy z rejestrów pozwalają szybko wykryć źródło błędów, zrozumieć wpływ zmian, a nawet przewidywać awarie. Poniżej znajdziesz praktyczną, krok‑po‑kroku instrukcję: gdzie szukać informacji, jak je czytać i jak wdrożyć proces analizy, który naprawdę działa.

Gdzie znaleźć logi i jak je włączyć

Lokalizacja plików logów PrestaShop (zależnie od wersji)

PrestaShop korzysta z ekosystemu Symfony, więc pliki dzienników mogą leżeć w kilku miejscach w zależności od wersji i ustawień środowiska:

• PrestaShop 1.7 (starsze wydania): app/logs/prod.log oraz app/logs/dev.log
• PrestaShop 1.7.x (nowsze) i 8.x: var/logs/prod.log, var/logs/dev.log lub var/log/prod.log, var/log/dev.log

Ścieżki mogą się różnić po aktualizacjach lub modyfikacjach wdrożeniowych. Jeśli w katalogu projektu nie widzisz plików logów, sprawdź konfigurację Monolog/Symfony oraz uprawnienia do katalogu var/ lub app/.

Panel administracyjny: zakładka „Logi”

Back Office oferuje dodatkowe źródło: Zaawansowane > Logi. To rejestr zdarzeń zapisywanych w bazie (tabela ps_log), zwykle operacje biznesowe, ostrzeżenia oraz błędy zgłaszane przez PrestaShop i moduły. Dobrą praktyką jest korelowanie daty i treści z plikami prod.log/dev.log, aby zyskać pełny obraz zdarzenia.

Logi WWW i PHP na poziomie serwera

Poza logami aplikacji koniecznie analizuj warstwę serwerową. Najczęstsze lokalizacje:

• Apache: /var/log/apache2/error.log oraz pliki wirtualnych hostów
• Nginx: /var/log/nginx/error.log i access.log
• PHP-FPM: /var/log/php8.x-fpm.log (wersja zależna od instalacji)

To tu pojawiają się krytyczne informacje o segfaultach PHP, błędach kompilacji, ograniczeniach pamięci i czasie wykonywania, a także ostrzeżenia dotyczące uprawnień plików. Jeśli podejrzewasz problemy z konfiguracją HTTP lub PHP, logi warstwy serwer mogą być kluczowe.

Logi bazy i narzędzia do inspekcji

Problemy z zapytaniami SQL, zablokowanymi tabelami czy replikacją zwykle widać w logach systemu bazodanowego. Dla MySQL/MariaDB sprawdź:

• error log: zwykle /var/log/mysql/error.log lub /var/log/mysqld.log
• slow query log: plik z wolnymi zapytaniami (konfiguracja w mysqld.cnf)

Zidentyfikowanie wolnego indeksu, deadlocka lub błędu składni SQL często wymaga korelacji wpisów aplikacyjnych i dzienników warstwy baza danych.

Włączenie trybu diagnostycznego i poziomu logowania

W środowisku deweloperskim uruchom tryb debugowania, by zobaczyć więcej szczegółów:

• BO: Zaawansowane > Wydajność > Tryb debugowania (włącz)
• Plik konfiguracyjny: config/defines.inc.php i ustaw _PS_MODE_DEV_ na true

Sympatycznym uzupełnieniem jest legacy profiler (_PS_DEBUG_PROFILING_), który wyświetla czasy i zapytania SQL. Pamiętaj, by po diagnozie wyłączyć tryb debug w produkcji.

Jak czytać wpis logu

Poziomy i znaczniki

PrestaShop (poprzez Symfony) korzysta ze standardowych poziomów: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY. W praktyce interesują Cię głównie ERROR/CRITICAL (awarie) oraz WARNING (wczesne ostrzeżenia). Stwórz prostą regułę: dla ERROR/CRITICAL zawsze otwieraj zadanie naprawcze, dla WARNING oceniaj wpływ i decyduj o priorytecie.

Struktura pojedynczego wpisu

Typowy wpis prod.log może wyglądać tak:

[2026-05-06 11:02:33] app.ERROR: SQLSTATE[HY000] [1040] Too many connections {„uri”:”/cart”,”ip”:”203.0.113.42″,”method”:”POST”} []

Kluczowe pola do szybkiej diagnozy:

• znacznik czasu i strefa czasowa (zwracaj uwagę na serwery w różnych strefach)
• kanał (app, doctrine, php, request)
• poziom (ERROR/CRITICAL/…)
• treść (komunikat), zwykle pierwszy trop do przyczyny
• kontekst (uri, ip, method, shopId, module), ułatwia odtworzenie zdarzenia

Stack trace i korelacja

W trybie dev lub przy odpowiedniej konfiguracji zobaczysz stack trace. Szukaj pierwszej aplikacyjnej ramki (src/Adapter lub moduł) nad warstwą frameworka. Zanotuj: nazwa modułu, nazwa klasy i metoda, parametry. Następnie skoreluj wpis z:

• logiem access (status 5xx, 4xx, czas odpowiedzi, user-agent),
• logiem bazy (deadlock, slow query),
• zdarzeniami systemowymi (deploy, restart PHP-FPM, backupy).

Reguły 5 minut

Jeśli nie znasz jeszcze przyczyny, zastosuj prosty schemat:

• Znajdź pierwsze wystąpienie problemu i porównaj z momentem ostatnich zmian.
• Potwierdź, czy problem dotyczy jednego sklepu (multistore) czy całej instancji.
• Wyizoluj moduł: wyłącz podejrzany moduł na środowisku testowym i sprawdź log.
• Utwórz minimalny scenariusz: powtórz request z tymi samymi parametrami.

Typowe symptomy i procedury naprawcze

Biały ekran i HTTP 500

Procedura:

• Włącz logging błędów PHP (php.ini: log_errors=On; sprawdź ścieżkę error_log).
• Na chwilę przełącz na dev (o ile to bezpieczne) i sprawdź prod.log/dev.log.
• Sprawdź uprawnienia do var/, img/, cache/ (w tym kompilacje Smarty).
• Poszukaj autoload/Composer: czy vendor/ jest pełne, czy pamięć opcache nie wymaga restartu.

Najczęstsze przyczyny: brakująca klasa po aktualizacji, niekompatybilna wersja modułu, błąd w override, brak miejsca na dysku (sprawdź df -h), przekroczony limit plików (ulimit -n).

Problemy z modułami i override’ami

Wpisy CRITICAL/ERROR często wskażą nazwę modułu. Działaj tak:

• Wyłącz moduł w BO (o ile sklep działa) lub przez bazę (ps_module: active=0),
• Usuń lub przenieś override z override/ jeśli dotyczy kolizji klas,
• Wyczyść kompilacje Smarty i katalog var/cache, po czym odtwórz błąd,
• Sprawdź zależności modułu (wersja PHP, PrestaShop, inne biblioteki).

Gdy błąd zniknie po wyłączeniu modułu, porównaj jego kod z changelogiem i najnowszą wersją. Poprawki bezpieczeństwa i kompatybilności często adresują typowe wyjątki.

Wydajność, timeouty i ograniczenia zasobów

Objawy: 504 Gateway Timeout, losowe 500 przy dużym obciążeniu, długie czasy odpowiedzi. Kroki:

• Przejrzyj access.log (czas, upstream_response_time) i prod.log pod kątem ostrzeżeń „slow”.
• Sprawdź slow query log i brakujące indeksy (EXPLAIN, ANALYZE FORMAT=JSON).
• Zwiększ limity, jeśli uzasadnione: max_execution_time, php-fpm pm.max_children, MySQL innodb_buffer_pool_size.
• Zweryfikuj szablony i moduły „heavy” – prosty test A/B po wyłączeniu.

Pamiętaj o warstwie cache HTTP (np. Varnish/Nginx), Smarty i Doctrine. Niewłaściwa invalidacja cache lub nadmierne dogrzewanie może pogorszyć sytuację. Jeżeli prod.log wskazuje OOM lub „Allowed memory size exhausted”, rośnie presja na pamięć – sprawdź alokacje, limity i potencjalne wycieki.

Konflikty plików, prawa i właściciel

Komunikaty o braku dostępu lub niemożności zapisu często wynikają z różnic między użytkownikiem PHP a właścicielem plików. Sprawdź:

• Uprawnienia: katalogi 755, pliki 644 (zależnie od polityki),
• Właściciela: chown -R www-data:www-data /ścieżka/do/sklepu (Debian/Ubuntu),
• Bezpieczną politykę zapisu: tylko wymagane katalogi do zapisu.

Problemy z e‑mailami i webhooks

Kiedy klient nie dostaje potwierdzeń, spójrz w logi modułu mail i transportu (SMTP/API). Dodatkowo:

• Zweryfikuj odpowiedzi API zewnętrznych dostawców (statusy 4xx/5xx w access.log),
• Dodaj korelacyjny identyfikator (X-Request-ID) i loguj go w aplikacji,
• Ustaw retry z backoffem dla krótkich awarii.

Narzędzia, automatyzacja i analiza na żywo

Szybka inspekcja na serwerze

Podstawowy zestaw poleceń do pracy na żywo:

• tail -f var/log/prod.log — podgląd w czasie rzeczywistym,
• grep -i „CRITICAL” var/log/prod.log* — szukanie krytycznych wpisów,
• zgrep -i „SQLSTATE” var/log/prod.log*gz — przeszukiwanie zarchiwizowanych,
• awk, sed — filtrowanie na podstawie pól i zakresów czasu,
• lnav lub multitail — kolorowanie i nawigacja po logach.

Dla logów HTTP przydatny jest goaccess (interaktywny raport z access.log) oraz narzędzia do korelacji X-Request-ID między warstwami (Nginx mapuje nagłówek, PrestaShop dopisuje do kontekstu logu).

Centralizacja i obserwowalność

Przy większym ruchu lokalne pliki to za mało. Skorzystaj z ELK/Opensearch, Graylog lub SaaS (np. Sentry, Datadog). Korzyści:

• Wyszukiwanie po polach, dashboardy i alerty,
• Korelacja wielu źródeł (aplikacja, www, DB, system),
• Retencja i kontrola dostępu w jednym miejscu.

Jeśli decydujesz się na Sentry, skonfiguruj SDK PHP i breadcrumbs, by łączyć zdarzenia użytkownika z wyjątkiem. W przypadku ELK zadbaj o parsowanie linii do formatu strukturalnego (grok lub JSON).

Konfiguracja i rozszerzenia Monolog

Symfony korzysta z handlerów Monolog. W zależności od wersji i środowiska konfiguracja znajduje się w app/config/config*.yml lub config/packages/*/monolog.yaml. Zalecenia:

• Rozdzielaj kanały (app, doctrine, php, request) i nadaj im różne poziomy,
• Używaj handlerów rotujących i wysyłających (syslog, slack, gelf),
• Dodaj procesory: identyfikator żądania, ID koszyka, ID klienta (z anonimizacją).

Zadbaj o zgodność z RODO: maskuj e‑maile, telefony i tokeny w kontekście wpisów. Dobrze skonfigurowany Monolog pozwala bezboleśnie przejść od chaosu do czytelnych sygnałów.

Format JSON i schemat zdarzeń

Jeżeli chcesz skutecznie wyszukiwać i agregować dane, rozważ JSON jako format logów aplikacyjnych. Ustal schemat pól (timestamp, level, message, channel, request_id, shop_id, module, duration_ms). Dzięki temu łatwiej zbudujesz reguły alertowe (np. liczba CRITICAL w 5 min > 0) i raporty trendów błędów per moduł.

Dobre praktyki bezpieczeństwa i utrzymania

Rotacja, kompresja i retencja

Bez rotacji nawet niewielki błąd w pętli potrafi w kilka godzin zapełnić dysk. Skorzystaj z logrotate:

• rotacja dzienna lub rozmiarowa (size 50M),
• przechowuj 14–30 kopii,
• kompresuj (compress, delaycompress),
• nadawaj poprawne prawa po rotacji (create 0640 www-data adm).

Monitoruj zajętość dysku i inode (df -h, df -i). Automatyczne alerty powyżej 80% pomogą uniknąć awarii spowodowanych brakiem miejsca.

Uprawnienia, dostęp i prywatność

Zabezpiecz katalogi z logami przed dostępem z zewnątrz (deny all w .htaccess lub odpowiednie reguły Nginx). Ogranicz dostęp SSH i SFTP do kont serwisowych. Anonimizuj dane osobowe (hash lub maska) i tokeny płatności. Zdefiniuj okresy retencji zgodne z polityką firmy i regulacjami.

Standardy nazewnictwa i korelacji

Ustal standardy identyfikatorów zdarzeń:

• request_id — generowany na wejściu, przekazywany do logów i odpowiedzi,
• job_id — dla CRON/CLI,
• correlation_id — używany między usługami (ESB, integracje z ERP/WMS).

Zachowanie spójności pól w całym łańcuchu (aplikacja, proxy, worker) skraca czas diagnozy, bo każdy wpis można szybko połączyć z użytkownikiem, koszykiem i transakcją.

Checklisty operacyjne

Wprowadź dwie krótkie checklisty.

Przed wdrożeniem:

• Włącz logowanie na poziomie INFO/ERROR; DEBUG tylko w testach,
• Sprawdź rotację i wolne miejsce,
• Zadbaj o healthcheck: /ping lub /health z prostą odpowiedzią,
• Ustal plan rollbacku i punkty kontrolne w monitoringu.

Po incydencie:

• Zbierz wszystkie logi z 30 minut przed i po zdarzeniu,
• Odtwórz oś czasu (zmiany, obciążenie, błędy),
• Oceń wpływ i ryzyko ponownego wystąpienia,
• Dodaj testy regresji i reguły alertów, uaktualnij runbook.

Optymalizacja ścieżek krytycznych

Najwięcej wartości przyniesie koncentracja na ścieżkach: koszyk, checkout, płatność, import asortymentu, indeksacja. Dla każdej z nich zbuduj minimalny zestaw metryk i logów: rozpoczęcie, ważne etapy (np. autoryzacja płatności), zakończenie, czas trwania, kody błędów partnerów. Takie sygnały upraszczają diagnostykę w godzinach szczytu i zmniejszają MTTR.

Profilowanie i proaktywne ostrzeganie

Oprócz logów wdroż profilowanie i metryki systemowe: APM (np. OpenTelemetry/Jaeger, New Relic), metryki Prometheus (CPU, RAM, I/O, FPM), wykresy panelowe (Grafana). Kiedy log pokazuje symptom, metryka często podpowiada mechanizm (throttling, GC, blokady I/O). Zestawienie obu strumieni danych stabilizuje wydajność całej platformy.

Typowe receptury konfiguracyjne

Przykłady działań, które często rozwiązują problemy widoczne w logach:

• Włączenie realpath_cache_size w PHP i zoptymalizowanie opcache dla szybszego autoloadingu,
• Dostosowanie ilości workerów PHP-FPM do rdzeni i RAM,
• Separacja logów środowisk (prod, staging, dev) i sklepów (multistore) do osobnych plików/kanałów,
• Wyłączenie logowania danych wrażliwych w middleware (maskowanie parametrów POST).

Praca z błędami integracji

Integracje z bramkami płatności, kurierami, ERP czy marketing automation generują własne kody i komunikaty. Ustal mapowanie błędów zewnętrznych na wewnętrzne (np. EXT_TIMEOUT -> PAYMENT_PROVIDER_TIMEOUT) i loguj je jednolicie, wraz z request_id i correlation_id. Ułatwia to filtrowanie i budowę alertów per dostawca.

Sprzątanie i sanityzacja wpisów

Regularnie przeglądaj logi pod kątem „hałasu”: powtarzalnych ostrzeżeń, nadmiarowych stack trace, nieistotnych informacji zewnętrznych SDK. Twórz reguły tłumienia (rate limit, sampling) oraz obniżaj poziom logowania tam, gdzie to bezpieczne. Mniej, ale bardziej użytecznych wpisów, to szybsza diagnoza i krótszy czas reakcji zespołu.