← Wróć do bloga

Klient pisze, że nie może złożyć zamówienia, i przysyła zrzut ekranu: „There has been an error processing your request” i długi numer. Dla właściciela sklepu wygląda to jak ślepa uliczka. Tymczasem ten numer to adres — wskazuje konkretny plik z pełnym opisem błędu. Poniżej: gdzie Magento zapisuje błędy, w jakiej kolejności ich szukać i czego w logach sklepu po prostu nie ma.

Gdzie szukać przyczyny błędu w Magento. Komunikat z numerem raportu prowadzi do pliku w katalogu var/report. Logi sklepu w katalogu var/log: exception.log z nieobsłużonymi wyjątkami, system.log z ogólnym dziennikiem pracy, debug.log z logami diagnostycznymi wyłączonymi domyślnie w trybie production oraz cron.log z wynikami zadań cron. Poza logami Magento: błędy PHP i serwera WWW, na przykład przekroczony limit pamięci albo czas odpowiedzi, błędy JavaScript widoczne tylko w konsoli przeglądarki oraz błędy po stronie zewnętrznych usług, takich jak bramka płatności

Co oznacza numer w komunikacie

Pełny komunikat wygląda zwykle tak:

There has been an error processing your request
Exception printing is disabled by default for security reasons.
Error log record number: 1234567890

Poza trybem developer Magento nie pokazuje odwiedzającemu szczegółów błędu. Ślad wywołań ujawniłby ścieżki na serwerze, nazwy klas i fragmenty konfiguracji — informacje, które nie powinny trafiać do przypadkowej osoby. Zamiast tego Magento zapisuje pełny raport w katalogu var/report, a na ekranie pokazuje tylko jego numer. Numer jest nazwą pliku, więc raport z przykładu wyżej leży w var/report/1234567890.

W praktyce oznacza to, że numer z komunikatu jest najcenniejszą informacją w zgłoszeniu od klienta. Pozwala znaleźć dokładnie ten błąd, zamiast zgadywać, który z setek wpisów w logach dotyczy tej sytuacji.

Gdzie Magento zapisuje błędy

Poza raportami z numerami Magento prowadzi kilka dzienników w katalogu var/log:

  • exception.log — nieobsłużone wyjątki z pełnym śladem wywołań. Pierwsze miejsce, gdy coś „wybucha”.
  • system.log — ogólny dziennik pracy sklepu: ostrzeżenia, komunikaty modułów i integracji. Sporo w nim szumu, ale często to tu pojawia się pierwsza wskazówka.
  • debug.log — szczegółowe logi diagnostyczne. W trybie production są domyślnie wyłączone; od wersji 2.3.1 włącza się je poleceniem bin/magento setup:config:set --enable-debug-logging=true, a potem czyści cache.
  • cron.log — wyniki zadań cron. Jeśli sklep przestał wysyłać maile albo odświeżać ceny, zacznij od tego pliku i od sprawdzenia, czy cron w Magento w ogóle działa.

Do tego dochodzą rozszerzenia. Moduły płatności, kurierów czy integracji z ERP często zapisują własne pliki w var/log, więc przy problemie z konkretną integracją warto zacząć od jej logu, a nie od ogólnego.

Czego w logach Magento nie znajdziesz

To częsta przyczyna straconego czasu: przeszukuje się var/log, a błędu tam nie ma, bo nigdy tam nie trafił.

  • Błędy, zanim Magento przejmie żądanie. Błąd składni PHP albo przekroczony limit pamięci kończy działanie skryptu, zanim Magento zdąży cokolwiek zapisać. Takich błędów szuka się w logach PHP (np. PHP-FPM) i serwera WWW. Typowy objaw to biała strona albo błąd 500 bez numeru raportu.
  • Błędy 502 i 504. Zgłasza je serwer WWW lub serwer pośredniczący, gdy PHP nie odpowie albo odpowie za późno — i to w jego logach jest ślad.
  • Błędy JavaScript. Przycisk „Złóż zamówienie” nie reaguje, formularz adresu się nie zapisuje, a na serwerze cisza. Te błędy dzieją się w przeglądarce klienta i widać je w konsoli narzędzi deweloperskich, nie w logach sklepu.
  • Błędy po stronie zewnętrznych usług. Jeśli bramka płatności albo API kuriera odrzuci żądanie, w logach Magento widać najwyżej odpowiedź, którą sklep dostał. Przyczynę trzeba sprawdzić w panelu dostawcy.

Tryb developer — nie na żywym sklepie

W trybie developer Magento wyświetla wyjątki bezpośrednio w przeglądarce. Kusi, żeby przełączyć tak sklep produkcyjny i „po prostu zobaczyć błąd”. Nie warto: komunikaty z detalami technicznymi zobaczy każdy odwiedzający, sklep działa wolniej, a samo przełączenie trybu czyści m.in. var/cache i pub/static.

Wszystko, czego potrzeba do diagnozy, jest w var/report i var/log — bez pokazywania tego klientom. Tryb developer służy do pracy na kopii sklepu. O tym, który tryb pasuje do którego środowiska, piszemy we wpisie o środowiskach i wdrażaniu zmian w Magento.

Log zapytań do bazy — narzędzie na chwilę

Gdy strona działa wolno, a logi milczą, pomocny bywa log zapytań do bazy danych. Włącza się go poleceniem bin/magento dev:query-log:enable, a zapytania trafiają do var/debug/db.log — razem z czasem wykonania i parametrami.

Dwie rzeczy, o których trzeba pamiętać. Po pierwsze, Adobe ostrzega, że przy dużym ruchu ten plik bardzo szybko rośnie, więc włącza się go na krótko — najlepiej na stagingu — i wyłącza poleceniem dev:query-log:disable. Po drugie, parametry zapytań mogą zawierać dane klientów, więc po diagnozie plik lepiej usunąć.

Logi rosną — i to też jest problem

Logi i raporty błędów zbierają się latami. Na serwerze z ograniczonym miejscem zapełniony dysk potrafi zatrzymać sklep, bo Magento nie ma gdzie zapisać cache ani plików tymczasowych. Na własnym serwerze rotacją logów zajmuje się zwykle logrotate — warto sprawdzić, czy obejmuje katalog var/log sklepu, i od czasu do czasu przejrzeć var/report.

Jest też drugi powód, żeby nie trzymać logów bez końca: logi integracji potrafią zawierać dane klientów, takie jak adresy e-mail czy dane zamówień.

Jak zgłosić błąd, żeby dało się go szybko naprawić

  1. Numer raportu z komunikatu, jeśli się pojawił.
  2. Dokładny czas wystąpienia — po nim szuka się wpisów w logach.
  3. Adres strony i to, co zostało kliknięte.
  4. Zasięg: czy błąd się powtarza i czy dotyczy wszystkich, czy jednego klienta, jednej przeglądarki albo jednej metody płatności.
  5. Zrzut ekranu z widocznym adresem i komunikatem.
  6. Ostatnie zmiany: aktualizacja, nowy moduł, zmiana konfiguracji.

Z takim zgłoszeniem diagnoza zaczyna się od właściwego pliku, a nie od przeszukiwania całego serwera.