Fire de telemetrie
1) Scop și context
Fluxurile de telemetrie oferă un aflux continuu de date observaționale despre performanța platformei: ce se întâmplă, de ce și cât costă. În iGaming, aceasta este cheia detectării timpurii a degradării depozitelor/pariurilor, a vizibilității furnizorilor externi (studiouri PSP/KYC/game) și a conformității SLO/conformității dovedibile.
2) Harta sursei de telemetrie
Metrics (TSDB): RED/USE, business SLI (succesul autorizațiilor,% din pariurile de succes).
OTel: lanțuri de cereri prin intermediul front → API → brokeri → baza de date/PSP.
Jurnale (structurate): evenimente, operațiuni de audit, erori.
ROM: TTFB/LCP, JS erori, geo/dispozitiv.
Sintetice: tranzacții de încercare externe (login/depozit/rata de nisip) din diferite OUG-uri.
Telemetrie de nivel scăzut: profilare eBPF/CPU/IO/allocare, rețea p95/p99.
Statusuri externe: webhooks/PSP/KYC/CDN/WAF pools.
3) Standarde și scheme
OpenTelemetry as lingua franca: unificarea semanticii atributelor (serviciu. nume, implementare. mediu, enduser. id - mascat, urme/SpanID, coduri PSP).
Convenții schemă: versioning, registru schemă pentru busteni/trasee, „breaking-changes” numai prin perioada de pavilion binar și grație.
Corelație-ID: un singur 'corelation _ id' pentru plată/pariu prin toate straturile + exemplare în percentile metrice.
4) Transportor pentru injecție (nivel înalt)
1. Producători: SDK/agenți/colecționari (OTel Colector pe noduri).
2. Tamponare margine: cozi locale (memorie/disc) cu limite.
3. Transport: gRPC/HTTP OTLP → broker de mesaje (Kafka/Pulsar) cu chei de idempotency.
4. Procesoare: normalizare, îmbogățire (GEO/chiriaș/canal), filtre PII, eșantionare subțire.
5. Fan-out: în TSDB (valori), în depozitarea urmelor, în sistemul de jurnal, în lac/DWH, în alertă/reguli.
6. Consumatori: tablouri de bord, alerte SLO (burn-rate), investigații, pagina de stare, auto-porți de lansare.
5) QoS și clase de flux
Clasa A (timp real, P1): SLI/SLO, sintetice, furnizori cheie (PSP/KYC). Livrare SLA: <5-10c, ≥99. 9%.
Clasa B (săli de operație): trasee/jurnale pentru RCA, SLA: <1-2 min.
Clasa C (analitică): agregate și loturi în lac/DWH, SLA: oră/zi.
Rutarea claselor → prioritizarea, cereri diferite, cozi/subiecte individuale.
6) Prelevare de probe, agregare, retenție
Metrica: sub-eşantionarea seriei istorice (1s→10s→1m), agregate percentile, exemplare.
Trasee: eșantionare bazată pe coadă (cota de creștere pentru anomalii, erori PSP, p99- „explozii”).
Busteni: nivel profil, compresie, respingere zgomot (sănătate-ping-uri, DEBUG la vânzare - interzis).
Retentie: „fierbinte” (7-14 zile detaliu), „rece” (unitati/arhiva). Politici pe clasă de date și costuri.
7) Confidențialitate și conformitate
Igiena PII: mascarea/tokenizarea identificatorilor; interzicerea documentelor CCM/jetoanelor de card în telemetrie.
Geo-localizare: stocare în funcție de jurisdicție; export - numai prin fluxul de lucru aprobat (criptare, TTL, audit).
Controlul accesului: RBAC/ABAC la depozitele de telemetrie, SoD pentru încărcări.
8) Fiabilitatea fluxului
Idempotence: chei de evenimente, dedup în procesoare.
Backpressure: limite de injecție per chiriaș/serviciu; politici de eliminare a câmpurilor de suprasarcină cu prioritate redusă.
Reluări - magazin în broker ≥72 h pentru reprocesare.
Scrisoare moartă: erori de rutare (schemă, dimensiune, încălcare PII) pentru a asigura DLQ cu alerte.
Versioning: „flux dual” la schimbarea circuitelor (v1 + v2) și migrarea consumatorilor.
9) Multi-chiriaș și izolare
Etichete 'chiriaș _ id/brand/region' în fiecare eveniment; cote și bugete marginale.
Izolarea fluxurilor A/B prin topicaluri; showback/chargeback la injectare şi păstrare.
Mascarea/agregarea la limita chiriașilor în timpul exportului.
10) Stream director (câmpuri exemplu)
Identificator: "telemetrie. plăți. Autentificare. Succes. rata. eu "
Clasa: A (timp real)
Схема: '{timestamp, chiriaș, regiune, psp, bank_bin_group, success_rate, fereastră}'
Sursa: OTel colector + PSP-router metrici
Consumatori: alerte SLO, tabloul de bord , pagina de stare
Retenție: fierbinte timp de 30 de zile, agregate timp de 12 luni
Proprietar: Plăți SRE, dpo-proprietar (confidențialitate)
Flow SLO: întârziere <10 c p95, pierdere <0. 1 %/zi
11) Integrarea cu alertă și eliberări
Alerte SLO prin burn-rate (fereastră rapidă/lentă) pentru depozite/rate.
Release-gates: analiză canară SLI; auto-stop/rollback în timpul degradării.
Pagina de stare: actualizați fluxul de pe cardul incident + unitățile SLI.
12) Un set de tablouri de bord cheie
: uptime, burn-rate, succesul autorizațiilor/tarifelor (prin GEO/PSP), starea furnizorului, $/RPS telemetrie.
SRE/Platform: RED/USE by service, lag cozi, detectarea outlier, profiluri eBPF.
Plăți/Risc: conversie bancară/PSP, scăderi soft/hard, KYC SLA, semnale de încărcare timpurie.
Cost-obs: volumul injecției după sursă, etichetele de top ale cardinalității, costul prin flux.
13) Observability Finance (FinOps)
Costul KPI: $/GB ingera, $/trace, $/SLI-tablou de bord; raport privind valorile și etichetele „grele”.
Optimizări: agregare și sub-eșantionare, eșantionare dinamică, curățarea jurnalelor de conversație, clasă de stocare de importanță.
Politicieni: cote pentru cardinalitate ridicată, limite privind frecvența emiterii, revizuirea schemelor o dată pe trimestru.
14) Procese și roluri
Proprietarii de date/observabilitate на домены (plăți, jocuri, API de bază, Infra).
Change-Control pentru circuite: PR-review, banci de testare, compatibilitate la consumatori.
Tabletop/Haos-zile: deconectări ale furnizorilor, supraîncărcare broker, backpressure/idempotency check.
Post-mortem: include analiza telemetriei (suficiența semnalelor, alarmele false, costul).
15) Foaie de parcurs de implementare (8-12 săptămâni)
Ned. 1-2: auditul fluxurilor curente, harta surselor, telemetria obiectivelor SLO, selectarea standardelor (OTel, TSDB, trasee, busteni).
Ned. 3-4: Colectoare OTel, ID-ul de corelare unică, SLI de bază RED/USE + pentru depozit/pariu, directorul de flux v0.
Ned. 5-6: prelevare de probe pe bază de coadă, sintetice GEO, DLQ/idempotency, filtre de confidențialitate.
Ned. 7-8: panou FinOps (ingerare/retenție), sub-eșantionare, cote de cardinalitate, alerte SLO (burn-rate).
Ned. 9-10: semnale eBPF/low-level, feed pagină de stare, release-gates.
Ned. 11-12: teste de haos, optimizarea costurilor, fluxuri SLA formale, lansarea revizuirii trimestriale a schemelor.
16) Modele artefact
Specificații: id, proprietar, schemă, clasă QoS, surse, consumatori, retenție, SLO/alerte, politică de confidențialitate.
Schema PR Șablon: schimbare/migrare, compatibilitate, teste, plan rollback.
Politica de eșantionare: reguli pentru ridicarea eșantionării în caz de anomalii; bugetele țintă.
Cost Review Pack: Surse de top de $/Valoare, TTL/Agregare Oferte.
Lista de verificare a telemetriei incidente: o listă de diagrame/trasee/jurnale care trebuie să fie pentru RCA.
17) KPI/KRI de fluxuri de telemetrie
Livrare: p95 întârzieri pe clasă,% mesaje pierdute/zi.
Acoperire: proporția de căi critice cu trasare> 90%, proporția de SLI-uri închise de metrici.
Calitatea semnalului:% din incidentele surprinse pe SLI înainte de plângeri, alerte false/ratate.
Cost: $/RPS pentru telemetrie, $/urmă, cota de „zgomot” în injecție.
Fiabilitate: timpul de recuperare după degradarea brokerului, volumul reluării.
18) Antipattern
Valori de înaltă cardinalitate (userId, sessionId) în TSDB.
O singură „cutie neagră” de bușteni fără structurare și scheme.
Nu există DLQ/idempotency → duplicate și pierderi de vârf.
Retențiile „nesfârșite” fără FinOps → creșterea exponențială a facturilor.
Trasee fără context de afaceri (PSP/bank/OUG) → diagnosticare deficitară.
Sistemele inconsecvente între comenzi → consumatori se încalcă.
Total
Fluxurile de telemetrie sunt un sistem controlat, multi-stratificat: standardele și schemele OTel → injecție fiabilă cu QoS și backpressure → eșantionare/agregare și retenții pentru costuri → confidențialitate și izolare multi-chiriaș → alerte SLO, tablouri de bord și porți de eliberare. Un astfel de circuit oferă semnale timpurii, RCA rapid, costuri previzibile și stabilitatea platformei iGaming în modurile de vârf.