claude-wuerth-plato/memory/project_logging.md

name, description, metadata

name	description	metadata
project_logging	Logging-Lösung — pino-BE + offline-fähiger FE-Log-Sync; Board (Phase 3) noch offen	node_type type originSessionId memory project c4e04d11-9b40-4c6a-9333-ce3bbf949ba2

Implementiert 2026-06-03 (Branch development), Phase 1+2:

• BE: nestjs-pino als App-Logger → strukturiertes JSON auf stdout (Cluster-Pipeline frisst das). Kein pino-Transport (bricht unter webpack); lokal … | npx pino-pretty. Sensible Header redacted, /health vom Auto-Logging ausgenommen. Bestehende Logger.*-Aufrufe routen automatisch durch pino. LOG_LEVEL-Env steuert das Level.
• POST /client-logs (SessionAuthGuard, ClientLogModule): nimmt FE-Log-Batches, schreibt sie mit source:'fe' + Actor aus der Session (nicht aus dem Body), Batch-Cap 100.
• FE: clientLog (frontend-common, Singleton): gedeckelter In-Memory-Ring (200), Batch-Sync (50) an /client-logs sobald online — Heartbeat-getriggert, gleiches Muster wie Outbox. Retry bei Fehler, kein Log-Loop, Einträge PII-frei (message/stack/code/context/path, gekürzt). In main.js verdrahtet: window.onerror + unhandledrejection + Vue errorHandler, früh im Boot. (Vorher gingen uncaught FE-Fehler komplett verloren.)
• Geteilter Typ ClientLogEntry in @plato/models. Commits 6f78d4b (BE) + fcc62f2 (FE).

Bewusste Tradeoffs: FE-Puffer ist in-memory (kein Storage-Dependency, übersteht keinen Reload — Sync läuft aber sofort bei capture/online). errorList (Toasts) ist NICHT an clientLog gekoppelt — nur uncaught/globale Fehler werden gesynct (Bridging wäre ein leichter Zusatz).

Phase 3 (offen): das Board. Empfehlung Grafana/Loki (oder vorhandener Cluster-Stack) — JSON-stdout ist schon board-ready. Sentry/GlitchTip nur falls Stacktrace-Grouping gewünscht (SaaS = Egress/Ticket-Risiko → self-service beachten). Offene Frage an Marcus: was bietet der Würth-Cluster schon (Grafana/Loki, ELK)? Eine kleine logger-Abstraktion hält einen späteren Sentry/OTEL-Wechsel call-site-frei.