LogPulse

Architektur & Transparenz

Wie LogPulse gebaut ist

Vertrauen beginnt damit zu wissen, was unter der Haube steckt. Hier ist der Stack, der Ihre Logs betreibt, die getroffenen Entscheidungen und wohin wir gehen. Lieber zu viel teilen als zu viel versprechen.

Der Stack auf einen Blick

Langweilige, gut verstandene Komponenten. Keine Magie.

Ingest

Fastify auf Node 22

GCP · Amsterdam (NL)

OTLP HTTP plus ein generischer JSON-Endpoint. Bearer-Auth mit bcrypt-gehashten API-Keys. Pro Key rate-limited.

Queue

BullMQ auf Redis

GCP · Amsterdam (NL)

Batched 100–1000 Records pro Insert. Retry bei vorübergehenden ClickHouse-Fehlern.

Log-Speicher

ClickHouse Cloud

GCP · Amsterdam (NL)

Spaltenorientiert, partitioniert nach tenant_id und Datum. Order Key (tenant_id, namespace, timestamp, log_id) sorgt dafür, dass tenant-bezogene Queries die richtigen Partitionen zuerst treffen. Typischerweise 8–12× Kompression auf Text-Logs.

Metadaten

PostgreSQL via Drizzle ORM

GCP · Amsterdam (NL)

Nutzer, Organisationen, API-Keys, Dashboards, Alerts, Pipelines. Hier wird kein Log-Inhalt gespeichert.

Frontend

React 19 + Vite

Cloudflare Pages

TanStack Query für Server-State, Zustand für UI-State, Tailwind + shadcn/ui. Strict TypeScript überall.

Anthropic Claude

US-Subprocessor

Treibt natürlichsprachige → LPQL-Übersetzung und den AI Investigator an. In unseren Subprocessors gelistet. Logs gehen nur an die LLM, wenn Sie eine KI-Query auslösen.

Wie Daten fließen

Von Ihren Apps nach ClickHouse und zurück zu Ihnen.

  Your apps  ──OTLP HTTP──▶  Fastify ingest  ──▶  BullMQ (Redis)
                                  │                       │
                              auth + quota              batch
                                  │                       ▼
                                  │             ClickHouse (GCP · Amsterdam)
                                  │                       │
                                  ▼                       │
                              PostgreSQL                  │
                              (metadata)                  │
                                                          ▼
  Web UI  ◀── LPQL / AI ──  Fastify query  ──▶  ClickHouse (tenant-scoped)

Push-basierter Ingest: Agents und SDKs senden Logs über OTLP HTTP. Die API authentifiziert und queued; ein Worker batched und schreibt nach ClickHouse. Queries fließen umgekehrt. Die UI trifft die API, die API führt LPQL auf ClickHouse aus, mit Tenant-Scoping an der Boundary erzwungen.

Multi-Tenancy & Isolation

Trennung erzwungen in der Datenbank, nicht nur in der App.

Free-, Pro- und Business-Tenants teilen sich eine ClickHouse-Tabelle, partitioniert nach tenant_id + Datum. Enterprise-Kunden erhalten einen vollständig dedizierten Stack: isolierte Ingestion, Compute und Speicher.
Jede Query trägt WHERE tenant_id = '…', an der API-Boundary erzwungen, parameterisiert, nie string-konkateniert. Partition Pruning bedeutet, dass Cross-Tenant-Daten nicht gescannt werden.
API-Keys sind in PostgreSQL bcrypt-gehasht; Raw-Keys werden einmalig bei Erstellung gezeigt und nie geloggt.
Namespace-RBAC scopt Log-Zugriff pro Team. Platform-Engineering-Teams können Devs Self-Service geben, ohne andere Namespaces offenzulegen.

Aufbewahrung & Kosten

Pauschalpreise heißt: Sie zahlen nicht extra, wenn Sie mehr loggen als geplant.

Plan-basierte Aufbewahrung: Free 7 Tage, Starter 14 Tage, Pro 30 Tage. Team- und Platform-Pläne haben konfigurierbare Aufbewahrung mit automatisiertem Lifecycle-Management.
Pauschalpreis. Täglicher Ingest ist bis zur Quota inklusive. Keine Pro-GB-Kosten, keine Überraschungs-Overage-Rechnungen.
ClickHouse-Spaltenkompression erreicht typischerweise 8–12× auf Text-Logs. Deshalb können wir Pauschalpreise anbieten, ohne Marge zu verbrennen.
Bei Quota-Erreichung gibt es 429 und eine E-Mail bei 80%. Lieber bewusst upgraden als still Overage abrechnen.

KI: eine Abkürzung, keine Black Box

Jede Query, die die KI ausführt, wird gezeigt. Sie können verifizieren, anpassen und speichern.

Natürlichsprachige Fragen werden von einer LLM (Anthropic Claude) in LPQL übersetzt. Die LLM ist in unseren Subprocessors gelistet und sieht Daten nur, wenn Sie eine KI-Query auslösen.
Der AI Investigator verkettet Queries: suchen, mit Deploys korrelieren, mit Baseline vergleichen. Jeder Schritt wird im Chat gezeigt, mit der ausgeführten LPQL und den zurückgegebenen Logzeilen.
Hypothesen werden als 'wahrscheinliche Ursache' mit Belegen formuliert, nicht als Behauptungen. Sie verifizieren vor dem Handeln.
EU-gehostete LLM-Optionen sind auf der Roadmap für Kunden mit strengen Residency-Anforderungen. Bis dahin sind KI-Features pro Query opt-in.

Ehrlich, nicht atemlos

Wo wir stehen vs. wohin wir gehen

Lieber ehrlich darüber, was steht und was noch in Arbeit ist.

DSGVO

Standardmäßig konform

DPA + SCCs auf bezahlten Tarifen verfügbar. EU-only Datenpfad. Verschlüsselung at rest und in transit.

SOC 2 Type II

In Arbeit · Q3 2026

Trust Services Criteria Controls vorhanden. Audit läuft.

ISO 27001

In Vorbereitung

Aligned Controls; noch nicht zertifiziert.

Öffentliche Uptime-Seite

Geplant

Status-Seite mit historischer Uptime pro Service.

Öffentliche Benchmarks

Geplant

Reproduzierbare Ingest-Throughput- und Query-Latency-Posts.

Lücke entdeckt oder tiefer eintauchen?

Lieber zu viel teilen als zu viel versprechen. Mailen Sie [email protected] mit Fragen zum Stack, zur Isolation oder zu allem, was wir hier nicht abgedeckt haben.

Mail an [email protected]Zur Security- & Compliance-Seite

Wir verwenden Cookies, um den Site-Verkehr zu analysieren und Ihre Erfahrung zu verbessern. Ohne Ihre Einwilligung werden keine Cookies gesetzt. Datenschutzerklärung