Telemetrie und Eventsammlung

1) Zweck und Grundsätze

• Einheitlicher und vorhersehbarer Ereignisfluss für Analytics, Anti-Fraud, RG, Compliance und ML.
• Ende-zu-Ende-Tracing (user/session/request/trace) und Reproduzierbarkeit.
• Minimierung der PII und Einhaltung der Datenschutzbestimmungen.

Принципы: schema-first, privacy-by-design, idempotency-by-default, observability-by-default, cost-aware.

2) Taxonomie der Ereignisse

Zahlung: "Zahlung. deposit`, `payment. withdrawal`, `payment. chargeback`.
Spiel: 'Spiel. session_start/stop`, `game. bet`, `game. payout`, `bonus. applied`.
Benutzerdefiniert: 'auth. login`, `profile. update`, `kyc. status_changed`, `rg. limit_set`.
Operational: 'api. request`, `error. exception`, `release. deploy`, `feature. flag_changed`.
Compliance: 'aml. alert_opened`, `sanctions. screened`, `dsar. requested`.

Jeder Typ hat einen Besitzer (Domain Owner), ein Schema und ein Frische-SLO.

3) Systeme und Verträge

• `event_time` (UTC), `event_type`, `schema_version`, `event_id` (UUID/ULID),
• `trace_id`/`span_id`, `request_id`, `user. pseudo_id`, `session_id`,

json
{
"event_id": "01HFY1S93R8X",
"event_time": "2025-11-01T18:45:12. 387Z",
"event_type": "game. bet",
"schema_version": "1. 4. 0",
"user": {"pseudo_id": "p-7a2e", "age_band": "25-34", "country": "EE"},
"session": {"id": "s-2233", "device_id": "d-9af0"},
"game": {"id": "G-BookOfX", "provider": "StudioA", "stake": {"value": 2. 00, "currency": "EUR"}},
"ctx": {"ip": "198. 51. 100. 10", "trace_id": "f4c2...", "request_id": "req-7f91"},
"labels": {"market": "EE", "affiliate": "A-77"}
}

Entwicklung von Schemata: semantische Versionen; backward-compatible - fügen Sie nullable Felder hinzu; breaking - nur in der neuen Version ('/v2') mit doppelter Schreibperiode.

4) Instrumentierung: wo und wie

4. 1 Client (Web/Mobile/Desktop)

Telemetrie-SDK mit lokalem Puffer, Batch-Senden, exponentiellen Retrays.
Auto-Events: Besuche, Klicks, Blocksichtbarkeit, Web-Vitale (TTFB, LCP, CLS), JS-Fehler.
IDs: 'device _ id' (nachhaltig, aber privat), 'session _ id' (aktualisiert), 'user. pseudo_id`.
Schutz vor „Rauschen“: Dedup durch 'event _ id', Drosseln, Client-Side-Sampling.

4. 2 Server/Backend

Logger/Tracer-Wrapper (OpenTelemetry) → Domain-Event-Emit.
Obligatorisches Ausrollen von 'trace _ id' von edge/gateway zu allen Downstream-Diensten.
Outbox-Muster zur transaktionalen Veröffentlichung von Domänenereignissen.

4. 3 Anbieter/Dritte

Konnektoren (PSP/KYC/Studios) mit Normalisierung auf Host-Schaltungen; Versionsadapter.
Unterschrift/Integritätsprüfung payload, perimeter journalism (ingest audit).

5) OpenTelemetry (OTel)

Traces: Jede Anfrage erhält 'trace _ id'; Verknüpfen von Protokollen/Ereignissen über 'trace _ id '/' span _ id'.
Logs: Wir verwenden OTel Logs/Konverter; Umgebungsbeschriftungen 'service. name`, `deployment. env`.
Metriken: RPS/Latenz/Fehlerrate nach Diensten, Geschäftsmetriken (GGR, Conversion).
Sammler: Zentrale Empfangsstelle/Puffer/Export nach Kafka/HTTP/graphic. Stapel.

6) Kennungen und Korrelation

'event _ id' - Einzigartigkeit und Idempotenz.
`user. pseudo_id' - stabile Pseudonymisierung (Mapping getrennt und begrenzt).
'session _ id', 'request _ id', 'trace _ id', 'device _ id' - sind für die End-to-End-Analyse erforderlich.
ID-Konsistenz auf API-Gateway und SDK-Ebene.

7) Sampling und Volumenkontrolle

Regeln: per-event-type, per-market, dynamic (adaptive) by load.
Exakt gefilmte Ereignisse: Payment/Compliance/Incidents - werden nicht gesampelt.
Analytische Ereignisse: 10-50% mit Korrekturgewichten in Vitrinen erlaubt.
Server-side Downsampling: für hochfrequente Metriken zulässig.

8) Datenschutz und Compliance

Minimieren Sie PII: Tokenisieren Sie PAN/IBAN/E-Mail; IP → Geo-Codes/ASN bei ingest.
Regionalisierung: An regionale ingest-endpoints (EEA/UK/BR) senden.
DSAR/RTBF: Unterstützung für selektives Ausblenden von Projektionen; Protokoll der Rechtsgeschäfte.
Aufbewahrungsrichtlinien: Zeitrahmen nach Typ (Analysen sind kürzer, regulatorisch länger); Legal Hold.

9) Transport und Pufferung

→ Edge Client: HTTPS (HTTP/2/3), 'POST/telemetry/batch' (bis zu 100 Ereignisse).
Edge → Sheena: Kafka/Redpanda mit Partitionierung durch 'user. pseudo_id`/`tenant_id`.
Formate: JSON (ingest), Avro/Protobuf (im Bus), Parkett (im See).
Zuverlässigkeit: Retrays mit Jitter, DLQ, Poison-Pill-Isolierung.

json
{
"sdk": {"name":"igsdk-js","version":"2. 7. 1"},
"sent_at": "2025-11-01T18:45:12. 500Z",
"events": [ {... }, {... } ]
}

10) Zuverlässigkeit und Idempotenz

Client-generierte' event _ id'+ Server-Dedup durch'(event_id, source)'.
Outbox auf Diensten, Exactly-Once-Semantik in Streams (keyed state + dedupe).
Reihenfolge innerhalb des Schlüssels: Partitionierung durch 'user/session'.
Zeitsteuerung: NTP/PTP, zulässige Drift (z. B. ≤ 200 ms), „received _ at“ auf dem Server.

11) Telemetrie Qualität (TQ) und SLO

Completeness: ≥ 99. 5% der kritischen Ereignisse hinter T.
Freshness: p95 Lieferverzögerung bis Silber ≤ 15 min.
Korrektheit: Gültige Schemata ≥ 99. 9%, drop-rate < 0. 1%.
Trace Coverage: Anteil der Anfragen mit 'trace _ id' ≥ 98%.
Kosten/GB: Zielbudget für Ingest/Speicher nach Domäne.

12) Beobachtbarkeit und Dashboards

• Lag ingest (p50/p95) nach Quellen und Regionen.
• Completeness nach Ereignistypen und Märkten.
• Fehler bei der Validierung von Schemas/oversized-payloads.
• SDK-Versionszuordnung und Prozentsatz der veralteten Clients.
• Web-Vitale Korrelation ↔ Konversion/Fehler.

13) Client SDKs: Anforderungen

Einfacher Footprint, Offline-Puffer, verzögerte Initialisierung.
Einstellungen: sampling, max batch size, max queue age, privacy-modes (no-PII).
Schutz: Paketsignatur/Anti-Tamper, Verschleierung der Schlüssel.
Update: Feature-Flags zum Abschalten von lauten Ereignissen.

14) Randschicht und Schutz

Rate Limit, WAF, Schema Validierung, Kompression (gzip/br).
Token bucket pro Kunde; anti-replay ('request _ id', TTL).
IP und UA Entfernung → Normalisierung/Anreicherung außerhalb der „rohen“ payload.

15) Integration mit Datenpipeline

Bronze: irreversibel-additive rohe payload (für forensica).
Silber: normalisierte Tabellen mit Deduplizierung/Anreicherung.
Gold: Vitrinen für BI/AML/RG/Produkt.
Die Linie zwischen Ereignissen und Berichten; Versionen von Transformationen.

16) Kundenqualitätsanalyse

Quotient „stille Kunden“ (keine Veranstaltungen in N Stunden).
Anomalien des „Sturms“ (Masse duplicate/burst).
Anteil der "Legacy SDKs' nach Version und Plattform.

17) Prozesse und RACI

R: Data Platform (ingest/bus/validators), App Teams (SDK Toolkit).
A: Head of Data/Architecture.
C: Compliance/DPO (PII/retention), SRE (SLO/incidents).
I: BI/Marketing/Risiko/Produkt.

18) Fahrplan für die Umsetzung

1. Ereignistaxonomie v1 + JSON-Schema für 6-8 Typen.

2. SDK (Web/Android/iOS) с batch и sampling; Edge `/telemetry/batch`.

3. Kafka + Bronze Schicht; Basisvalidatoren und Dedup.

4. Dashboard ingest lag/completeness, alerts on drop/validator.

• OTel Collector, Trace-Korrelation; Silber-Normalisierung und DQ-Regeln.
• Regionale Endpunkte (EWR/UK), Privacy-Mods, DSAR/RTBF-Verfahren.
• SDK Versionskarte, Auto-Rollout Updates auf Ringe.

• Exactly-Once in Threads, Feature Store-Verbindungen, Anti-Fraud-Online-Feeds.
• Rule-as-Code für Schemata und Validatoren, Simulation von Änderungen (Impact-Analyse).
• Kostenoptimierung: adaptives Sampling, Z-Order/Clustering im See.

19) Qualitätscheckliste vor Veröffentlichung

• Erforderliche Schemafelder und korrekte Typen sind ausgefüllt.
• „trace _ id “/„ request _ id “/„ session _ id“ ist vorhanden.
• Das SDK unterstützt Batch, Retry, Sampling.
• Edge validiert das Schema und begrenzt die Payload-Größe.
• Included Privacy-Filter und Tokenisierung empfindlicher Felder.
• SLOs/Alerts und Dashboards sind konfiguriert.
• Dokumentation für Domains (Beispiel Event, Owner, SLA).

20) Häufige Fehler und wie man sie vermeidet

Rohereignisse ohne Schemata: Registry und CI-Validierung eingeben.
Keine Idempotenz: Fordern Sie' event _ id 'an und speichern Sie Deduplizierungsfenster.
Mix aus PII und Analytics: Muppings trennen, Felder maskieren.
Kein Tracing: Legen Sie „trace _ id“ durch das Gateway → die Dienste → Ereignisse.
Nicht verwaltete Volumina: Sampling/Trrottling und Budgetkontingente anwenden.
Globaler Endpoint ohne Regionen: Regionalisierung und Datenresidenz nutzen.

21) Glossar (kurz)

OpenTelemetry (OTel) ist ein offener Standard für Traces/Metriken/Logs.
Outbox - Transaktionale Veröffentlichung von Domänenereignissen.
DLQ - Warteschlange für „gebrochene“ Nachrichten.
Sampling - Auswahl eines Teils der Ereignisse, um das Volumen zu reduzieren.
Data Residency - Speicherung von Daten in der richtigen Gerichtsbarkeit.

22) Ergebnis

Bei der gut konzipierten Telemetrie geht es um Vereinbarungen und nicht nur um das „Senden von Protokollen“: strenge Schemata, harmonisierte IDs, Standard-Datenschutz, zuverlässiger Transport, Beobachtbarkeit und sparsame Kosten. Wenn Sie diesem Artikel folgen, erhalten Sie einen stetigen Ereignisfluss, der für Analysen, Compliance und maschinelles Lernen mit vorhersehbaren SLOs bereit ist.