Logs & Monitoring
P2Lab Cache hält drei optionale Logs — Invalidierung, Reverse-Proxy und Warmup-Historie. Alle drei sind standardmäßig aus, um die Datenbank schlank zu halten; aktivieren Sie die, die Sie beim Diagnostizieren oder beim Tuning Ihrer Invalidierungsstrategie interessieren.
Invalidierungslog
Abschnitt betitelt „Invalidierungslog“Erfasst jeden lokalen Cache-Purge. Aktivieren unter Einstellungen → Speed Boost → Core → Einstellungen → Invalidierungslog aktivieren.
Was jeder Eintrag enthält:
- Zeitstempel
- Auslösende Entität — Typ, ID, Nummer, Name (sofern verfügbar)
- Auslösendes Event —
entity.written,product.indexed, manuellesclear-all, CLI, API-Aufruf usw. - Geänderte Felder (nur Smart-Modus) — das Feld-Diff, das den Analyzer zu diesem Tag-Set führte
- Tag-Set — die gepurgeten Tags
- Gepurgete Cache-Einträge — Anzahl
Browsen Sie von Speed Boost → Invalidierungslog → Liste. Klicken Sie eine Zeile für die volle Detailseite.
Alte Einträge werden vom Scheduled Task cleanup-invalidation-log nach 30 Tagen automatisch gelöscht — siehe Geplante Tasks.
Anwendungsfälle
Abschnitt betitelt „Anwendungsfälle“- “Warum wurde gestern um 14:32 mein ganzer Cache geleert?” — Invalidierungslog auf diese Zeit filtern.
- “Warum MISST diese Produktseite immer?” — Log nach Produktnummer durchsuchen, sehen, was sie invalidiert.
- “Ich sehe viel mehr Purges als erwartet” — nach Entitätstyp sortieren, den geschwätzigen finden.
Reverse-Proxy-Log
Abschnitt betitelt „Reverse-Proxy-Log“Erfasst jeden an Varnish gesendeten xkey-Purge. Aktivieren unter Einstellungen → Speed Boost → Reverse Proxy → Einstellungen → Reverse-Proxy-Log aktivieren.
Was jeder Eintrag enthält:
- Zeitstempel
- Operation —
purge/ban - URL oder an Varnish gesendetes Tag-Set
- HTTP-Status der Varnish-Antwort
- Antwortzeit
- Auslösende Entität — Typ, ID, Nummer (sofern bekannt)
Browsen von Speed Boost → Reverse-Proxy-Log → Liste.
Zwei spezialisierte Ansichten ergänzen die Liste:
Entitäts-Timeline
Abschnitt betitelt „Entitäts-Timeline“Reverse-Proxy-Log → Liste → Zeile → Entitäts-Timeline (auch direkt aufrufbar, wenn die Entität bekannt ist). Zeigt jeden xkey-Purge, den eine bestimmte Entität ausgelöst hat, chronologisch. Nützlich für “dieses Produkt scheint zu viel zu purgen”.
URL-Flow
Abschnitt betitelt „URL-Flow“Reverse-Proxy-Log → Liste → Zeile → URL-Flow. Zeigt jeden Purge, der eine bestimmte URL betroffen hat, und welche Entität jeden ausgelöst hat. Nützlich für “diese URL ist immer kalt; wer purged sie ständig?”.
Alte Einträge werden vom Scheduled Task cleanup-reverse-proxy-log nach 30 Tagen automatisch gelöscht.
Warmup-Historie
Abschnitt betitelt „Warmup-Historie“Wird immer erfasst — kein Schalter. Browsen von Speed Boost → Warmup-Historie → Liste. Jede Zeile ist ein Warmup-Lauf mit:
- Start- / Ende-Zeitstempeln
- Zähler total / geprüft / fehlgeschlagen
- Durchschnittliche HTTP-Antwortzeit
- Status (laufend / pausiert / abgebrochen / abgeschlossen)
- Sales-Channel-Geltungsbereich
Die Detailansicht listet einzelne fehlgeschlagene URLs mit ihrem HTTP-Statuscode.
Cache-Einträge-Tabelle
Abschnitt betitelt „Cache-Einträge-Tabelle“Nicht streng ein “Log”, aber nützlich für die Diagnose: Speed Boost → Cache-Einträge → Liste zeigt jeden aktuell in der Datenbank gespeicherten Cache-Eintrag. Pro Zeile:
- URL
- Typ (product / category / listing / cms / buybox)
- Sales Channel
- Original-Größe / Cache-Größe / Komprimierungs-Ratio
- Generierungszeit / Cache-Hit-Zeit
- Last seen
Sie können nach URL-Prefix suchen und einzelne Einträge aus dieser Ansicht löschen.
Debug-Header
Abschnitt betitelt „Debug-Header“Wenn Core → Einstellungen → Debug-Modus an ist, trägt jede Antwort:
X-P2Lab-Cache-Status: HIT | MISSX-P2Lab-Cache-Generation-Time: <Sekunden>
Kombinieren Sie diese mit den obigen Logs für das volle Bild: der Header sagt Ihnen, ob eine Anfrage gecacht wurde, das Log sagt warum.
Aufräumtasks
Abschnitt betitelt „Aufräumtasks“Drei Scheduled Tasks halten die Log-Tabellen davor, ewig zu wachsen:
p2lab_cache.cleanup_cache_entries— läuft nächtlich, entfernt verwaistep2lab_cache_entry-Zeilen, die nicht mehr im Backend existierenp2lab_cache.cleanup_invalidation_log— läuft nächtlich, entfernt Zeilen älter als 30 Tagep2lab_cache.cleanup_reverse_proxy_log— läuft nächtlich, entfernt Zeilen älter als 30 Tage
Stellen Sie sicher, dass Ihr messenger:consume scheduler-Worker läuft, sonst feuern diese nicht. Siehe Geplante Tasks.