Logi i diagnostyka Magento 2

Kiedy w sklepie coś idzie nie tak - biały ekran, błąd 500, niedziałający checkout - pierwsze co robi doświadczony admin to patrzy do logów. Ten poradnik pokazuje gdzie są wszystkie logi Magento i jak je czytać.

Główne miejsca logowania

Lokalizacja	Co zawiera
var/log/system.log	Główne logi aplikacji (info, warnings, notices).
var/log/exception.log	Wszystkie nieobsłużone wyjątki PHP.
var/log/debug.log	Wpisy z Magento\Framework\Logger\Monolog (tylko gdy włączony developer mode).
var/log/payment.log	Logi modułów płatności (PayPal, etc.).
var/log/magento.cron.log	Logi crona Magento.
var/log/update.cron.log	Logi Updater (Magento Open Source Tools).
var/log/install.log	Logi instalatora.
var/report/	Report ID z białych ekranów / krytycznych błędów.
Logi modułów ecomhouse i 3rd-party	Zwykle: var/log/{modul}.log (np. fastQtyUpdate.log, import_queue.log).

var/log/system.log

Najważniejszy log. Magento wpisuje tu wszystkie:

• Błędy konfiguracji.
• Brak uprawnień plików.
• Failed cron jobs.
• Problemy z indekserami.
• Email delivery failures.
• Notice / warning z poziomu modułów.

Czytanie loga

# Live monitoring
tail -f var/log/system.log

# Ostatnie 100 wpisów
tail -100 var/log/system.log

# Szukaj konkretnego błędu
grep -i "error" var/log/system.log | tail -20

# Logi z dziś
grep "$(date +%Y-%m-%d)" var/log/system.log

Format wpisu

[2026-01-05T14:32:18.345672+00:00] main.ERROR: Cron Job [...] has an error: ... {"exception":"..."} []

Element	Co znaczy
[2026-01-05T14:32:...]	Timestamp w ISO 8601 UTC.
main	Logger name (zwykle main).
ERROR	Poziom (DEBUG / INFO / NOTICE / WARNING / ERROR / CRITICAL).
Komunikat	Tekst błędu.
{"exception":"..."} (JSON)	Dodatkowy kontekst (stack trace, dane).

var/log/exception.log

Tylko nieobsłużone wyjątki. Mniej "szumu" niż system.log - łatwiej znaleźć krytyczne błędy.

tail -50 var/log/exception.log

Każdy wpis zawiera pełen stack trace - kluczowy do diagnostyki.

var/report/ - Report ID

Gdy klient widzi biały ekran lub komunikat:

There has been an error processing your request

Report ID: 1736089012345_67890

znaczy to, że Magento zapisało szczegóły błędu w pliku:

var/report/1736089012345_67890

Czytanie raportu

cat var/report/1736089012345_67890

Zawiera:

• Komunikat błędu PHP / Magento.
• Pełen stack trace z numerami linii.
• Backtrace wywołań klas i metod.

To podstawowy plik do dołączenia w zgłoszeniu do developera / supportu modułu.

Report ID - gdzie szukać: Gdy klient zgłasza problem "sklep mi się wywalił" - zapytaj o Report ID. Bez tego musisz zgadywać, w czym był problem. Z Report ID - wiesz natychmiast, w którym module / linii kodu wystąpił błąd.

Skala raportów

var/report/ może rosnąć w nieskończoność. Co jakiś czas:

# Pokaż liczbę raportów
ls var/report/ | wc -l

# Usuń stare (>30 dni)
find var/report/ -mtime +30 -delete

Developer Mode

Magento ma trzy tryby deploy:

Tryb	Cel	Logi
default	Pośredni - pokazuje błędy, ale optimization include.	Średnio.
developer	Pełen debug - błędy widoczne, cache wyłączone.	Wszystko, włącznie z debug.log.
production	Optimized - błędy ukryte, cache pełen.	Tylko error i wyżej.

Sprawdzenie trybu

bin/magento deploy:mode:show

Przełączanie

# Włącz developer mode (development / staging)
bin/magento deploy:mode:set developer

# Production
bin/magento deploy:mode:set production

Nigdy nie używaj developer mode na produkcji: Developer mode wyświetla pełne błędy PHP i stack trace na froncie sklepu - widoczne dla każdego klienta. To wyciek informacji wrażliwych (ścieżki serwera, struktura kodu, etc.).

Na produkcji zawsze używaj production mode.

Debug.log

W developer mode plik var/log/debug.log rejestruje dodatkowe wpisy z \Magento\Framework\Logger\Monolog. Często używany przez moduły do logowania niskoryzykowych informacji.

W production mode debug.log jest wyłączony (chyba że system > debug > logging is enabled w konfiguracji).

Magento DB profiler

Aby zobaczyć, jakie zapytania SQL Magento wykonuje przy danej stronie, włącz profiler bazy:

app/etc/env.php:

'db' => [
    'connection' => [
        'default' => [
            // ... existing config
            'profiler' => [
                'enabled' => true,
                'class' => 'Magento\Framework\DB\Profiler',
            ],
        ],
    ],
],

Następnie:

Stores > Configuration > Advanced > Developer > Debug > Profile Database → Yes.

Logi w var/debug/db.log - pokazuje czas wykonania każdego zapytania.

Wyłącz na produkcji - profilowanie ma narzut wydajnościowy.

Diagnostyka popularnych problemów

Problem 1: Biały ekran (500 error)

# Sprawdź exception.log
tail -50 var/log/exception.log

# Jeśli klient podał Report ID
cat var/report/{REPORT_ID}

# Sprawdź logi Nginx / Apache
sudo tail -50 /var/log/nginx/error.log
sudo tail -50 /var/log/apache2/error.log

# Sprawdź logi PHP-FPM
sudo tail -50 /var/log/php-fpm/error.log

Problem 2: "Static content deploy errors"

tail -100 var/log/system.log | grep -i "static"
ls -la pub/static/

Najczęściej brak uprawnień:

sudo chown -R www-data:www-data pub/static var generated

Problem 3: "Cron job has not been started in X minutes"

# Sprawdź czy cron działa
sudo tail -20 /var/log/syslog | grep CRON
bin/magento cron:run

# Sprawdź magento.cron.log
tail -100 var/log/magento.cron.log

Patrz Magento Cron.

Problem 4: Maile nie wysyłają się

# Logi modułu SMTP (jeśli Mageplaza)
tail -100 var/log/mageplaza_smtp_email.log

# System log dla błędów wysyłki
grep -i "mail\|email\|smtp" var/log/system.log | tail -20

Problem 5: Strona ładuje się wolno

# Profilowanie wydajności
# Włącz New Relic / Tideways jeśli dostępne

# Sprawdź stan cache
bin/magento cache:status

# Sprawdź indeksery
bin/magento indexer:status

# Sprawdź consumery queue
bin/magento queue:consumers:list
ps aux | grep "queue:consumers"

Często wolność = wyłączony Page Cache lub stuck consumer.

Problem 6: Klient nie może zalogować się / zarejestrować

# Customer-related logs
grep -i "customer\|login\|register" var/log/system.log | tail -20

# Może być problem z CAPTCHA / 2FA
grep -i "captcha\|2fa" var/log/system.log | tail -10

Centralizacja logów (produkcja)

Na produkcji lokalne pliki logów to za mało. Rekomendowane podejście:

• ELK Stack (Elasticsearch + Logstash + Kibana) - pełna obróbka i wyszukiwanie.
• Datadog / New Relic / Sentry - narzędzia komercyjne, łatwiejsze w setupie.
• Loki + Grafana - open source alternatywa dla ELK.
• Cloudwatch Logs (AWS) / Stackdriver (GCP) - natywne dla cloud.

Magento po prostu zapisuje do var/log/ - agent na serwerze stamtąd shipuje logi do platformy.

Centralizacja daje:

• Alerty (np. "więcej niż 10 błędów w minutę → Slack").
• Wyszukiwanie po wielu serwerach (web1, web2, ...).
• Wizualizację trendów w czasie.

Audyt logów - co sprawdzać regularnie

Częstotliwość	Co sprawdzać
Codziennie	var/log/exception.log - nowe błędy.
Codziennie	var/log/magento.cron.log - czy cron działa.
Tygodniowo	var/log/system.log - peak'i z błędami.
Tygodniowo	var/report/ - liczba nowych raportów (rosnąca = problemy).
Co kwartał	Audyt logów logowania admin - nieautoryzowane próby?
Co kwartał	Rotation / czyszczenie starych logów (logrotate / find).

Logrotate dla Magento

/etc/logrotate.d/magento:

/var/www/magento/var/log/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 644 www-data www-data
    sharedscripts
}

Logi rotują się codziennie, kompresowane, 14 dni historii.

Najczęstsze problemy

Logi puste, mimo że błędy występują

Sprawdź:

1. Uprawnienia var/log/ - musi być zapisywalny przez www-data:

   sudo chown -R www-data:www-data var/log/
   

2. Deploy mode - w production mode tylko error i wyżej. Przełącz na developer (dla stagingu).

3. php-fpm error_log - może błędy lądują w logu PHP-FPM zamiast Magento:

   sudo tail -50 /var/log/php-fpm/error.log
   

system.log ma gigabajty rozmiaru

Brak logrotate. Skonfiguruj go (powyżej) i wyczyść ręcznie:

> var/log/system.log     # truncate file (bez usuwania)

(> file jest lepsze niż rm file - Magento nadal trzyma file descriptor, restart nie wymagany).

Report ID nie istnieje w var/report/

Magento mógł go usunąć (auto-cleanup) lub klient pomylił się przepisując. Poproś o screenshot błędu lub timestamp z dokładną godziną - szukaj w logach z tego czasu.

Logi nie pokazują nic, ale 500 errors są

Błąd może być przed uruchomieniem Magento PHP - w serwerze web. Sprawdź:

sudo tail -100 /var/log/nginx/error.log
sudo tail -100 /var/log/php-fpm/error.log

---

Powiązane

• Magento Cron - magento.cron.log
• Cache i indeksery - błędy indekserów w system.log
• Bezpieczeństwo panelu admina - audyt logów logowania
• Backup i restore - backup ważnych logów off-site