Zum Inhalt springen

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.

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 Evententity.written, product.indexed, manuelles clear-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.

  • “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.

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
  • Operationpurge / 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:

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”.

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.

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.

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.

Wenn Core → Einstellungen → Debug-Modus an ist, trägt jede Antwort:

  • X-P2Lab-Cache-Status: HIT | MISS
  • X-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.

Drei Scheduled Tasks halten die Log-Tabellen davor, ewig zu wachsen:

  • p2lab_cache.cleanup_cache_entries — läuft nächtlich, entfernt verwaiste p2lab_cache_entry-Zeilen, die nicht mehr im Backend existieren
  • p2lab_cache.cleanup_invalidation_log — läuft nächtlich, entfernt Zeilen älter als 30 Tage
  • p2lab_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.