Aktuelles Langfuse v4 Self-Hosting nutzt Web/Worker plus PostgreSQL, ClickHouse, Redis/Valkey und S3/Blob Storage. Mit steigender Trace-Ingestion liegen Bottlenecks oft bei Worker, ClickHouse oder Queue/Storage statt Web.
Langfuse v4 nutzt Postgres für Transactional State, ClickHouse für Traces/Observations/Scores, Redis/Valkey für Queue/Cache und S3/Blob für Raw Events/Multimodal/Exports. Web nimmt Events an, Worker verarbeitet asynchron nach ClickHouse.
SDK/API-Events gehen an Web, Raw Events nach S3, Referenzen in Redis Queue; Worker verarbeitet und schreibt gebatcht nach ClickHouse.
Jede Storage-Komponente hat andere Backup- und Scaling-Anforderungen.
Langfuse empfiehlt Worker horizontal nach CPU-Last zu skalieren. Web, Worker, ClickHouse und Redis-Saturation separat beobachten.
Container-Namen an eigenes Compose/Kubernetes anpassen.
docker compose psdocker stats --no-streamdocker compose logs --tail=100 langfuse-workerdocker compose logs --tail=100 langfuse-webdf -hPostgres, ClickHouse und S3/Blob haben unterschiedliche Recovery-Mechanismen. Redis Queue/Cache-Durability hängt vom Design ab. Vor Upgrades Komponenten-Kompatibilität testen.
Web/Worker plus PostgreSQL, ClickHouse, Redis/Valkey und S3/Blob Storage.
Für Test/Low Scale per Docker Compose möglich; Production-HA/Scaling/Backup sind begrenzt.
Für hochvolumige Traces/Observations/Scores mit hohem Write-Throughput und schnellen Analysen.
Teilen Sie tägliche Traces/Events, Retention, Multimodal Files, Worker und HA; Web/Worker/ClickHouse/Redis/S3 planen.