Leichter, aber schneller Open-Source-Sammler für Nutzerverhalten/Events in Rust, sofort einsatzbereit

 (github.com/lee-lou2)
9 Punkte von leelou2 2025-01-09 | 1 Kommentare | Auf WhatsApp teilen

Wenn ihr Nutzerverhalten oder Events selbst erfassen müsst, probiert das unbedingt einmal aus (bitte🙏) – ihr werdet sicher zufrieden sein!

Ich habe mit Rust einen Webserver entwickelt, der eine leichtgewichtige und zugleich schnelle Datenerfassung ermöglicht.

Der Code ist einfach gehalten, sodass auch Personen, die mit Rust nicht vertraut sind, ihn leicht anpassen und modifizieren können (falls nötig, kann ich auch einige Änderungen übernehmen 🥳).

Der Event-Sammler ist wie folgt aufgebaut:

Technische Spezifikationen

  • Entwicklungssprache: rust(axum)
  • Speicher: Event-Speicherung (OpenSearch), Speicherung ausstehender Daten (Sqlite3)

Geplant ist, künftig auch weitere Speicher-Backends nutzbar zu machen.

Systemarchitektur

API-Typen

  1. GET /ping : Health Check
  2. POST /events : Event-Erfassung

Erfasste Daten

  • Nutzerinformationen aus dem im Header enthaltenen Token
  • Geräte-/App-Informationen aus den Headern
  • Detaillierte Event-Informationen aus dem Body

Lässt sich durch reine Schema-Änderungen einfach anpassen 👍

Technische Details

Grundaufbau (kurze Erklärung)

  • 100.000 Channels: übernehmen die Weiterleitung eingehender Events an die Consumer; wenn alle 100.000 Channels belegt sind, werden ausstehende Events in der Datenbank gespeichert
  • 10 Threads + Consumer: holen Events aus den Channels und speichern sie entweder in 1.000er-Batches oder die innerhalb von 10 Sekunden angesammelten Events in OpenSearch
  • 1 Scheduler: lädt in festen Zeitabständen Events aus der Pending-Datenbank und leitet sie erneut an die Channels weiter

Anfrage zur Datenerzeugung (HTTP)

  • Anfrage zur Datenerzeugung über eine HTTP-API
  • Nach Eingang der Anfrage wird sie an einen Channel weitergeleitet; sind alle Channels belegt, wird sie in der Pending-Datenbank gespeichert

Event-Consumer (10 leichtgewichtige Threads)

  • Fassen aus den Channels empfangene Events zu je 1.000 zusammen und senden eine OpenSearch-Bulk-Indexierungsanfrage
  • Wenn sich keine 1.000 Events ansammeln, werden die innerhalb von 10 Sekunden gesammelten Events per Bulk in OpenSearch registriert
  • Falls die Registrierung in OpenSearch fehlschlägt, werden sie in der Pending-Datenbank gespeichert

Registrierung ausstehender Events (Sqlite3)

  • Wenn die Channels voll sind oder bei einem Fehler beim Schreiben nach OpenSearch, werden die Events in der Pending-Datenbank gespeichert

Scheduler

  • Fragt in bestimmten Intervallen die in der Pending-Datenbank angesammelten Events ab und leitet sie an die Channels weiter
  • Später ist geplant, für kontinuierlich auflaufende Events oder Events, die wegen Datenproblemen nicht in OpenSearch gespeichert werden können, eine separate Behandlung hinzuzufügen

Die Anzahl der Channels und der leichtgewichtigen Threads sollte je nach Ressourcen der Deployment-Umgebung und Art von OpenSearch angepasst werden 💪

Ich arbeite erst seit 2–3 Monaten mit Rust, daher kann die Syntax noch etwas holprig sein. Ich werde das Projekt aber kontinuierlich verbessern.

Ich freue mich über viel Interesse und verschiedenstes Feedback~~~
Vielen Dank 🙇‍♂️

Verwandte Beiträge