Jak plik tekstowy po cichu zapełnia dysk
Z włączonym WP_DEBUG_LOG każdy notice, warning i deprecation PHP dopisuje się do
wp-content/debug.log. Bez rotacji, bez limitu, bez sprzątania
- tylko rośnie. Na stronie, której nikt nie pilnuje, ten plik przeżywa problem, do którego debugowania go włączono.
Wszystko działało, potem nic nie działa. Uploady padają. Aktualizacje padają.
Czasem pada cała strona. Sprawdzasz dysk: pełny. Zdecydowanie największy plik
na nim: debug.log.
Jedna wtyczka pisząca notice przy każdym requeście dodaje tysiące niemal identycznych linii dziennie. Miesiące później log ma gigabajty, backupy rosną razem z nim, a pierwszym znakiem, że coś nie gra, jest pełny dysk - co wygląda jak problem hostingu, nie logowania.
Czemu nigdy nie przestaje sam
- Plik jest append-only. Nic w WordPressie go nie rotuje, nie ucina ani nie ogranicza - nigdy.
- Ten sam notice powtarza się przy każdym requeście. Jedno wywołanie przestarzałej funkcji na ruchliwej stronie to linia na wizytę.
- Na większości stron WP_DEBUG powinien być wyłączony na produkcji od miesięcy - log zapełnia się dalej, czy ktokolwiek go czyta, czy nie.
- A im większy jest, tym rzadziej ktokolwiek go otwiera, więc prawdziwe błędy w środku też zostają nieprzeczytane.
Co Debug Log Guard z tym robi
Debug Log Guard znajduje log, który PHP naprawdę pisze - respektuje stałe
WP_DEBUG, a gdy prawdziwym celem jest error_log z php.ini,
przełącza się na niego - a potem daje ci trzy rzeczy:
- Pogrupowane podsumowanie. Ta sama wiadomość zwinięta do jednego wiersza z licznikiem, źródłem (core, wtyczka albo motyw) i pierwszym i ostatnim wystąpieniem. Linia, która zapełniła dwa gigabajty, siedzi na górze zamiast powtarzać się na czterech milionach wierszy.
- Podgląd na żywo. Ostatnie 200 linii, streamowane - nigdy nie ładuje pliku do pamięci, więc wielogigabajtowy log otwiera się w sekundy zamiast wieszać stronę.
- Bezpieczne akcje zmniejszania. Compact zwija powtórki, Rotate archiwizuje plik i zaczyna od nowa, Clear go pustoszy. Wszystkie trzy lecą backup-first i atomowo - częściowy zapis nigdy nie zepsuje loga.
Godzinna straż rozmiaru
Zadanie WP-Cron sprawdza log raz na godzinę. Powyżej twojego progu - domyślnie 50 MB - wykonuje wybraną akcję: compact, rotate albo clear, trzymając ustawioną liczbę backupów. Ty decydujesz, co znaczy „za duży"; straż tego pilnuje, kiedy śpisz.
Wie też, kiedy nie kompaktować: log już powyżej ~1 GB dostaje force-rotate, bo zwijanie wielogigabajtowego pliku nie jest bezpieczną operacją in-place. Kompaktowanie najpierw sprawdza wolne miejsce na dysku, skanuje wielkie pliki od taila zamiast od góry i leci na budżecie czasowym - jak się skończy, przerywa i zostawia oryginał nietknięty.
Leci na WP-Cron, więc między tickami plik może dalej rosnąć - straż ogranicza szkodę, nie zatrzymuje zapisów.
Log jest symptomem - napraw źródło
Zmniejszenie pliku nie naprawia tego, co do niego pisze. Pogrupowane podsumowanie jest tu tym ważnym: kolumna źródła nazywa wtyczkę, motyw albo plik core generujący każdą wiadomość, więc możesz naprawić, wymienić albo zgłosić to, co spamuje log, zamiast kasować dowody.
Jeszcze dwa ostrzeżenia, które warto znać. Straż zaznacza, gdy WP_DEBUG_DISPLAY zostaje włączone na produkcji - to drukuje błędy twoim odwiedzającym - i ostrzega, gdy sam plik loga jest publicznie osiągalny, a tego ludzie naprawdę szukają. Jeśli nikt nie czyta loga na żywej stronie, uczciwa naprawa to wyłączenie WP_DEBUG; Config Manager zapisuje stałe wp-config bezpiecznie, z backupem.
Debug Log Guard to moduł Pro - jeden klik do pogrupowanej tabeli z nazwanym winowajcą i straż cron trzymająca plik w ryzach.
Pro od $79/rok →FAQ: debug.log za duży
Czemu mój plik debug.log jest taki duży?
WP_DEBUG_LOG dopisuje każdy notice, warning i deprecation - a ta sama wiadomość zwykle powtarza się przy każdym requeście. Jedna wtyczka pisząca notice na odsłonę to tysiące linii dziennie. Nic w WordPressie nie rotuje ani nie ogranicza pliku, więc rośnie, aż dysk się zapełni.
Czy bezpiecznie jest usunąć debug.log?
Tak - regeneruje się przy następnym błędzie. Ale tracisz dowody na to, która wtyczka go spamuje, a jeśli przyczyna dalej jest, zapełnia się od razu z powrotem. Clear i rotate w Debug Log Guard lecą backup-first, więc możesz go zmniejszyć bez utraty danych.
Jak zatrzymać wzrost debug.log?
Dwa sposoby i to nie ta sama robota. Godzinna straż rozmiaru Debug Log Guard docina plik do twojego progu - domyślnie 50 MB - przez compact, rotate albo clear. Zatrzymanie zapisów znaczy naprawienie wtyczki, która je spamuje, albo wyłączenie WP_DEBUG; pogrupowane podsumowanie nazywa źródło tak czy tak.
Czy Debug Log Guard naprawia błędy w logu?
Nie - pokazuje, która wtyczka, motyw albo plik core je pisze. Pogrupowana tabela daje każdej wiadomości licznik i źródło, więc naprawiasz albo wymieniasz winowajcę zamiast w kółko kasować log, który się zapełnia.
A jak potrzebuję WP_DEBUG na żywej stronie?
Wtedy bezpieczny setup to WP_DEBUG_LOG włączone, WP_DEBUG_DISPLAY wyłączone - i Debug Log Guard pilnujący rozmiaru. Ostrzega też, gdy log jest publicznie osiągalny, więc plik, który trzymasz, nie zdradza twoich ścieżek każdemu, kto o nie zapyta.
Czy straż rozmiaru zadziała, gdy WP-Cron jest zepsuty?
Nie - godzinna kontrola jedzie na WP-Cron, więc jak cron nie odpala, straż też nie odpali. Akcje ręczne i pogrupowane podsumowanie nie zależą od crona i działają dalej.
Zmniejsz log, zachowaj dowody
Debug Log Guard grupuje powtórki, streamuje tail i kompaktuje, rotuje albo czyści plik z backupem - potem godzinna straż rozmiaru trzyma go w ryzach. Moduł Pro, $79/rok za jedną stronę. Każdy płatny plan zawiera wszystkie 19 modułów.
Weź Pro - od $79/rok Poradnik: strona leży Wszystkie plany na stronie cennika →