GH GambleHub

Telemetria i kolekcja wydarzeń

1) Cel i zasady

Cele:
  • Pojedynczy i przewidywalny przepływ zdarzeń dla analityki, zwalczania nadużyć finansowych, RG, zgodności i ML.
  • Śledzenie końcowe (użytkownik/sesja/żądanie/śledzenie) i odtwarzalność.
  • Minimalizacja PII i zgodność z prywatnością.

Мринсива: schema-first, privacy-by-design, idempotency-by-default, observability-by-default, cost-aware.

2) Taksonomia zdarzeń

Płatność: "płatność. wpłata „,” płatność. wypłata „,” płatność. obciążenie zwrotne ".
Gra: 'gra. session_start/stop', gra. bet ',' gra. wypłata ',' bonus. zastosowane ".
Niestandardowe: 'aut. login', 'profil. aktualizacja ',' kyc. status_changed', 'rg. limit_set'.
Pokoje operacyjne: 'api. żądanie „,” błąd. wyjątek „,” zwolnienie. deploy ',' feature. flag_changed'.
Zgodność: 'aml. alert_opened', "sankcje. screened ',' dsar. wnioskowane ".

Każdy typ ma właściciela domeny, schemat i świeżość SLO.

3) Systemy i umowy

Wymagane pola (minimum):
  • "event _ time" (UTC), "event _ type", "schema _ version", "event _ id' (UUID/ULID),
  • 'trace _ id'/' span _ id',' request _ id', 'user. pseudo_id', "session _ id',
„source” (klientserwerdostawca), „rynek” (jurysdykcja), „etykiety”.
Przykład (JSON):
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"}
}

Ewolucja programów: wersje semantyczne; kompatybilne wstecz - dodać nieważne pola; breaking - tylko w nowej wersji ('/v2 ') z podwójnym okresem rejestracji.

4) Oprzyrządowanie: gdzie i w jaki sposób

4. 1 Klient (Web/Mobile/Desktop)

Lokalna telemetria buforowa SDK, składanie partii, przekładnie wykładnicze.
Auto-wydarzenia: wizyty, kliknięcia, widoczność bloków, witryny internetowe (TTFB, LCP, CLS), błędy JS.
Identyfikatory: 'device _ id' (stabilny, ale prywatny),' session _ id' (zaktualizowany), 'user. pseudo_id'.
Ochrona przed „hałasem”: dedup przez 'event _ id', throttling, client-side sampling.

4. 2 Serwer/backend

Logger/tracer wrappers (OpenTelemetry) → event domain emit.
Obowiązkowe rzucanie 'trace _ id' od krawędzi/bramy do wszystkich usług niższego szczebla.
Wzorzec skrzynki zewnętrznej do transakcyjnego publikowania zdarzeń domenowych.

4. 3 Dostawcy/osoby trzecie

Złącza (PSP/KYC/studios) z normalizacją obwodów hosta; adaptery wersji.
Kontrola integralności podpisu/ładunku, rejestrowanie obwodu (kontrola najazdu).

5) OpenTelemetry (OTel)

Ślady: każde żądanie otrzymuje 'trace _ id'; łączymy dzienniki/zdarzenia za pomocą 'trace _ id'/' span _ id'.
Dzienniki: użyj dzienników/konwerterów OTel; usługi w zakresie etykiet środowiskowych. nazwa „,” rozmieszczenie. ا".
Metryki: RPS/latency/error-rate by service, business metrics (GGR, conversion).
Kolektor: pojedynczy punkt odbioru/bufora/eksportu do Kafki/HTTP/grafiki. stosie.

6) Identyfikatory i korelacja

'event _ id' - wyjątkowość i idempotencja.
'user. pseudo_id' - stabilne aliasing (odwzorowanie oddzielnie i ograniczony).
'session _ id',' request _ id', 'trace _ id',' device _ id' są wymagane do analizy końcowej.
Spójność identyfikatorów na poziomie bramki API i SDK.

7) Pobieranie próbek i kontrola objętości

Zasady: dla każdego typu zdarzenia, dla każdego rynku, dynamiczny (adaptacyjny) przez obciążenie.
Dokładnie zarejestrowane zdarzenia: płatność/zgodność/incydenty - nie zostały pobrane próbki.
Zdarzenia analityczne: 10-50% z wagami korygującymi w przypadkach wyświetlania jest dozwolone.
Downsampling po stronie serwera: Ważne dla mierników wysokiej częstotliwości.

8) Prywatność i zgodność

Zminimalizuj PII: Tokenizuj PAN/IBAN/email; IP → kody geo/ASN podczas połknięcia.
Regionalizacja: Wysyłanie do regionalnych punktów końcowych (EOG/UK/BR).
DSAR/RTBF: wsparcie dla selektywnej ukrycia projekcji; dziennik transakcji prawnych.
Polityka retencji: harmonogram według rodzaju (krótsza analiza, dłuższa regulacja); Prawna blokada.

9) Transport i buforowanie

→ Klient krawędzi: HTTPS (HTTP/2/3), „POST/telemetry/batch” (do 100 zdarzeń).
Krawędź → Opona: Kafka/Redpanda podzielona przez 'user. pseudo_id'/'tenant_id'.
Formaty: JSON (ingest), Avro/Protobuf (w autobusie), Parkiet (w jeziorze).
Niezawodność: retrai z jitter, DLQ, izolacja pigułek trujących.

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

10) Niezawodność i idempotencja

Generowane przez klienta 'event _ id' + server grandfather by' (event_id, source) '.
Outbox na usługach, Dokładnie-Raz-semantyka w wątkach (stan kluczowy + dedupe).
Zamówienie w ramach klucza: podzielone przez 'user/session'.
Kontrola czasu: NTP/PTP, dozwolony dryf (na przykład ≤ 200 ms), 'received _ at' na serwerze.

11) Jakość telemetrii (TQ) i SLO

Kompletność: ≥ 99. 5% zdarzeń typu krytycznego na T.
Świeżość: p95 opóźnienie dostawy do srebra ≤ 15 min.
Prawidłowość: ważne schematy ≥ 99. 9%, wskaźnik spadku <0. 1%.
Zasięg śladu: odsetek wniosków o 'trace _ id' ≥ 98%.
Koszt/GB: docelowy budżet na połknięcie/przechowywanie według domeny.

12) Obserwowalność i deski rozdzielcze

Minimalne widżety:
  • Lag ingest (p50/p95) według źródła i regionu.
  • Kompletność według typu wydarzenia i rynku.
  • Błędy walidacyjne systemów/oversized-payloads.
  • Mapa wersji SDK i procent dotychczasowych klientów.
  • Korelacja życiowych stron internetowych, konwersji/awarii.

13) Wymagania SDK klienta

Odcisk światła, bufor offline, odroczona inicjalizacja.
Ustawienia: pobieranie próbek, maksymalny rozmiar partii, maksymalny wiek kolejki, moda prywatności (no-PII).
Ochrona: podpis pakietu/anty-manipulator, obfuscation klucza.
Aktualizacja: flagi funkcji, aby wyłączyć hałaśliwe zdarzenia.

14) Warstwa krawędzi i ochrona

Limit szybkości, WAF, walidacja schematu, kompresja (gzip/br).
Wiadro tokenowe na klienta; anty-replay ('request _ id', TTL).
Usuwanie IP i UA → normalizacja/wzbogacanie poza „surowym” ładunkiem użytkowym.

15) Integracja z rurociągiem danych

Brąz: nieodwracalnie dodany surowy ładunek użytkowy (do badań sądowych).
Srebro: znormalizowane stoły z deduplikacją/wzbogaceniem.
Złoto: obudowy wyświetlacza dla produktu BI/AML/RG/.
Powiązanie między zdarzeniami a raportami; wersje transformacji.

16) Analityka jakości klienta

Cichy stosunek klientów (brak zdarzeń w godzinach N).
Anomalie „burzy” (masowy duplikat/wybuch).
Udział „spuścizny SDK” według wersji i platformy.

17) Procesy i RACI

R: Platforma danych (ingest/bus/validators), App Teams (oprzyrządowanie SDK).
Odp.: Szef danych/architektury.
C: Zgodność/DPO (PII/zatrzymanie), SRE (SLO/incydenty).
I: BI/Marketing/Ryzyko/Produkt.

18) Plan działania na rzecz realizacji

MVP (2-4 tygodnie):

1. Taksonomia zdarzeń v1 + schematy JSON dla 6-8 typów.

2. SDK (Web/Android/iOS) Krawędź '/telemetria/partia '.

3. Kafka + warstwa brązu; podstawowe walidatory i dedup.

4. Deska rozdzielcza połknięcie lag/kompletność, alerty do upuścić/walidator.

Faza 2 (4-8 tygodni):
  • OTel Collector, korelacja śladowa; Srebrna normalizacja i zasady DQ.
  • Regionalne punkty końcowe (EOG/UK), moda prywatności, procedury DSAR/RTBF.
  • Mapa wersji SDK, aktualizacje automatyczne przez pierścienie.
Faza 3 (8-12 tygodni):
  • Dokładnie Raz w strumieniach, Funkcja Sklep połączeń, anty-oszustwa kanałów online.
  • Kodeks reguł dla programów i walidatorów, analiza wpływu.
  • Optymalizacja wartości: próbkowanie adaptacyjne, Z-order/clustering w jeziorze.

19) Lista kontrolna jakości przed wydaniem

  • Wypełniono wymagane pola schematu i prawidłowe typy.
  • są obecne 'trace _ id'/' request _ id'/' session _ id'.
  • SDK obsługuje partię, ponowne próbkowanie, pobieranie próbek.
  • Krawędź zatwierdza program i ogranicza rozmiar ładunku.
  • Filtry prywatności i tokenizacja pól wrażliwych są włączone.
  • Skonfigurowane SLO/alerty i deski rozdzielcze.
  • Dokumentacja dla domen (np. zdarzenie, właściciel, SLA).

20) Częste błędy i jak ich uniknąć

Zdarzenia surowe bez schematów: wprowadź rejestr i walidację CI.
Brak idempotencji: wymaga 'event _ id' i przechowywania okien deduplikacji.
Mieszanka PII i analityki: oddzielne mapowania, pola maski.
Brak śledzenia: trasa 'trace _ id' przez gateway → usługi → wydarzenia.
Wolumeny niezagospodarowane - pobieranie próbek/trrottling oraz kwoty budżetowe.
Globalny punkt końcowy bez regionów - wykorzystanie regionalizacji i rezydencji danych.

21) Słownik (krótki)

OpenTelemetry (OTel) jest otwartym standardem dla szlaków/mierników/dzienników.
Outbox - transakcyjne publikowanie zdarzeń domenowych.
DLQ - kolejka „uszkodzonych” wiadomości.
Pobieranie próbek - wybór części zdarzeń w celu zmniejszenia objętości.
Data Residency - przechowywanie danych w pożądanej jurysdykcji.

22) Linia dolna

Dobrze zaprojektowana telemetria dotyczy aranżacji, a nie tylko „dzienników wysyłających”: rygorystycznych programów, uzgodnionych identyfikatorów, domyślnej prywatności, niezawodnego transportu, obserwowalności i oszczędności kosztów. Po tym artykule otrzymasz stały strumień wydarzeń gotowych do analizy, zgodności i uczenia maszynowego z przewidywalnymi SLO.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.