Logi i monitoring

P2Lab Cache trzyma trzy opcjonalne logi — inwalidacji, reverse-proxy i historię warmupów. Wszystkie trzy są domyślnie off, by trzymać bazę lean; włącz te, na których Ci zależy, podczas diagnozowania lub strojenia strategii inwalidacji.

Log inwalidacji

Zapisuje każdy lokalny purge cache. Włącz z Settings → Speed Boost → Core → Settings → Enable Invalidation Log.

Co zawiera każdy wpis:

Timestamp
Triggerująca encja — typ, ID, number, name (gdy dostępne)
Triggerujący event — entity.written, product.indexed, ręczny clear-all, CLI, wywołanie API itp.
Zmienione pola (tylko tryb Smart) — field-level diff, który spowodował, że analizator wyprodukował ten zestaw tagów
Zestaw tagów — tagi, które zostały purgowane
Wpisy cache purgowane — liczba

Przeglądaj z Speed Boost → Invalidation log → List. Kliknij wiersz, by zobaczyć pełną stronę detalu.

Stare wpisy są usuwane automatycznie przez zadanie zaplanowane cleanup-invalidation-log po 30 dniach — zobacz Zadania zaplanowane.

Przypadki użycia

“Dlaczego mój cały cache został wczoraj o 14:32 wyczyszczony?” — otwórz log inwalidacji filtrowany do tego czasu.
“Dlaczego ta strona produktu zawsze MISSuje?” — przeszukaj log dla numeru produktu, zobacz, co ją inwaliduje.
“Widzę dużo więcej purgów, niż się spodziewałem” — posortuj po typie encji, znajdź gadatliwego.

Log reverse-proxy

Zapisuje każdy xkey purge wysłany do Varnisha. Włącz z Settings → Speed Boost → Reverse proxy → Settings → Enable Reverse Proxy Log.

Co zawiera każdy wpis:

Timestamp
Operacja — purge / ban
URL lub zestaw tagów wysłany do Varnisha
Status HTTP, którym Varnish odpowiedział
Czas odpowiedzi
Triggerująca encja — typ, ID, number (gdy znane)

Przeglądaj z Speed Boost → Reverse-proxy log → List.

Dwa wyspecjalizowane widoki uzupełniają listę:

Entity timeline

Reverse-proxy log → List → wiersz → Entity timeline (dostępne też bezpośrednio, gdy znasz encję). Pokazuje każdy xkey purge, który konkretna encja wywołała, chronologicznie. Przydatne dla “ten produkt wydaje się purgować za dużo”.

URL flow

Reverse-proxy log → List → wiersz → URL flow. Pokazuje każdy purge, który dotknął konkretny URL, i która encja każdy z nich spowodowała. Przydatne dla “ten URL jest zawsze cold; kto wciąż go purguje?”.

Stare wpisy są usuwane automatycznie przez zadanie zaplanowane cleanup-reverse-proxy-log po 30 dniach.

Historia warmupów

Zawsze rejestrowana — bez przełącznika. Przeglądaj z Speed Boost → Warmup history → List. Każdy wiersz to jeden run warmupu z:

Timestampami started / finished
Licznikami total / checked / failed
Średnim czasem odpowiedzi HTTP
Statusem (running / paused / cancelled / completed)
Zakresem kanału sprzedaży

Detail view listuje pojedyncze failed URLs z ich statusem HTTP.

Tabela wpisów cache

Nie do końca “log”, ale przydatna do diagnozy: Speed Boost → Cache entries → List pokazuje każdy wpis cache obecnie zapisany w bazie. Per wiersz:

URL
Typ (product / category / listing / cms / buybox)
Kanał sprzedaży
Rozmiar oryginalny / rozmiar w cache / ratio kompresji
Czas generowania / czas obsługi HIT
Last seen

Możesz szukać po prefiksie URL i wyczyścić pojedyncze wpisy z tego widoku.

Nagłówki debug

Gdy Core → Settings → Debug Mode jest on, każda odpowiedź niesie:

X-P2Lab-Cache-Status: HIT | MISS
X-P2Lab-Cache-Generation-Time: <sekundy>

Połącz to z powyższymi logami dla pełnego obrazu: nagłówek mówi Ci, czy żądanie było cache’owane; log mówi, dlaczego.

Zadania czyszczące

Trzy zadania zaplanowane trzymają tabele logów przed wiecznym rośnięciem:

p2lab_cache.cleanup_cache_entries — działa nocą, usuwa osierocone wiersze p2lab_cache_entry, których już nie ma w backendzie
p2lab_cache.cleanup_invalidation_log — działa nocą, usuwa wiersze starsze niż 30 dni
p2lab_cache.cleanup_reverse_proxy_log — działa nocą, usuwa wiersze starsze niż 30 dni

Upewnij się, że Twój worker messenger:consume scheduler działa, inaczej te nie odpalą. Zobacz Zadania zaplanowane.