Flussi di telemetria
1) Assegnazione e contesto
I flussi di telemetria forniscono un flusso continuo di dati di osservazione sul funzionamento della piattaforma: cosa accade, perché e quanto costa. Nel iGaming è la chiave per rilevare in anticipo il degrado di depositi/scommesse, la visibilità dei provider esterni (PSP/KYC/Giochi Studios) e la compatibilità dimostrabile con il SLO/Compilation.
2) Mappa delle fonti di telemetria
Metriche (TSDB): RED/USE, Business SLI (successo delle autorizzazioni,% delle scommesse di successo).
Trailer (OTTEL): catene di query attraverso il fronte di API di broker OBD/PSP.
Logi (strutturati) - Eventi, controllo delle operazioni, errori.
RUM: TTFB/LCP, errori JS, geo/dispositivo.
Sintetica: transazioni esterne (login/deposito/tasso» sabbia») da GEO diverse.
Telemetria a basso livello: eBPF/profiling CPU/IO/alloc, p95/p99 in rete.
Stati esterni: webhoop/pool PSP/KYC/CDN/WAF.
3) Standard e schemi
OpenTelemetry come lingua franca: unificazione semantica degli attributi (service. name, deployment. environment, enduser. id - maschera, trace/SpanID, codice PSP).
Gli accordi di schema sono versioning, schema registry per logi/trailer, breaking-changes solo attraverso il binario flag e grace-time.
Correlation-ID: un unico «correlation _ id» per il pagamento/puntata attraverso tutti i livelli + exemplars delle metriche.
4) Trasportatore di iniezione (high-level)
1. Producers: SDK/agenti/raccoglitori (OTel raccoglitore).
2. Edge-buffer: code locali (memory/disk) con limiti.
3. Trasporti: OTLP broker di messaggi (Kafka/Pulsar) con chiavi idempotency.
4. Processors: normalizzazione, arricchimento (GEO/tenant/canale), filtri PII, sottile sempling.
5. Fan-out: in TSDB (metriche), nel magazzino delle piste, nel sistema di logi, in lake/DWH, in alerting/regole.
6. Consumers: dashboard, SLO-alert (burn-rate), indagini, status page, release auto-gate.
5) QoS e classi di flusso
Classe A (tempo reale, P1): SLI/SLO, sintetico, provider chiave (PSP/KYC). Consegne SLA <5-10 c, ≥99. 9%.
Classe B (operativi): trailer/login per RCA, SLA: <1-2 minuti
Classe C (analitiche): unità e batch in lake/DWH, SLA: ore/giorno.
Routing per classe di priorità, retenze diverse, code singole/topic.
6) Sempling, aggregazione, restauro
Metriche: downsampling delle righe storiche (1s→10s→1m), aggregati perentori, exemplars.
Trail: tail-based sempling (alzare la quota in caso di anomalie, errori PSP, p99- «picchi»).
Fogli: livello profilo, compressione, scollatura del rumore (health-ping, DEBUG in vendita - vietato).
Retenschn: «caldo» (7-14 giorni), «freddo» (unità/archivio). Criteri per la classe di dati e costi.
7) Privacy e compliance
Igiene PII: occultamento/tornizzazione degli identificatori; Proibire i documenti CUS/token di carte nella telemetria.
Geo-localizzazione: archiviazione giurisdizionale esportazione: solo tramite workflow approvati (crittografia, TTL, controllo).
Controllo degli accessi: RBAC/ABAC ai depositi di telemetria che vengono scaricati.
8) Affidabilità dei flussi
Idampotenza: chiavi per gli eventi, deducibilità nei processori.
Backpressure: limiti di iniezione per-tenante/servizio; Regole drop per i campi a bassa priorità in caso di sovraccarico.
Replays - Memorizzazione nel broker di ≥72 h per la rielaborazione.
Dead-letter: instradamento degli errori (schema, dimensione, violazione PII) in una DLQ sicura con alert.
Versioning: dual-thread per cambio di schema (v1 + v2) e migrazione dei consumatori.
9) Multi-tenente e isolamento
Tag «tenant _ id/brand/region» in ogni evento; Quote per tenanti e budget.
Isolamento dei flussi A/B su topic; showback/chargeback per iniezione e archiviazione.
Maschera/aggregazione fino al bordo del tenante durante l'esportazione.
10) Directory dei flussi (esempio di campi)
Identificatore: 'telemetry. payments. auth. success. rate. eu`
Classe A (tempo reale)
Схема: `{timestamp, tenant, region, psp, bank_bin_group, success_rate, window}`
Origine: OTEL Raccoglitore + PSP-router metrics
Consumatori: SLO-alert, Exec-dashboard, pagina di stato
Retenschn: 30 giorni caldi, unità 12 mes
Proprietario: Payments SRE, dpo-owner (privacy)
Flusso SLO: ritardo <10 c p95, perdita <0. 1 %/24 ore
11) Integrazione con alerting e release
SLO-alert per burn-rate (finestra veloce/lenta) per depositi/tassi.
Release-gates: SLI a canaretto; auto-stop/rollback in caso di degrado.
Pagina di stato: fide di aggiornamento da schede di incidente + unità SLI.
12) Set di dashboard chiave
Exec: farmacia, burn-rate, successo di autorizzazioni/scommesse (GEO/PSP), stato dei provider, $/RPS telemetria.
SRE/Piattaforma: RED/USE per servizi, code, rilevamento outler, profili eBPF.
Payments/Risk: conversione su banche/PSP, soft/hard decolli, KYC SLA, primi segnali di chargeback.
Cost-obs: quantità di iniezione per fonte, top label di radicalità, costo per flusso.
13) Finanza di osservabilità (FinOps)
Valore KPI: $/GB ingest, $/trace, $/SLI-dashboard; Rapporto su metriche e etichette pesanti.
Ottimizzazioni: aggregazione e downsampling, sempling dinamico, pulizia dei topi di chat, classe di conservazione per importanza.
Criteri: quote di high-cardinality, limiti di frequenza di emissione, riview diagrammi una volta al trimestre.
14) Processi e ruoli
Data/Observability Owners на домены (Payments, Games, Core API, Infra).
Cambio-Control per diagrammi: RV, banco di prova, compatibilità con i consumatori.
Tabletop/Chaos-days: disattivazione dei provider, sovraccarico del broker, verifica backpressure/idampotenza.
Post-mortem - Includere l'analisi della telemetria (sufficiente segnale, false attivazioni, costo).
15) Road map di implementazione (8-12 settimane)
Ned. 1-2: controllo dei flussi correnti, mappa delle sorgenti, obiettivi SLO di telemetria, selezione degli standard (OTTEL, TSDB, trailer, logi).
Ned. 3-4: raccoglitori OTEL, unico correlation-ID, base RED/USE + Business SLI per deposito/tasso, catalogo dei flussi v0.
Ned. 5-6: tail-based sempread, sintetico GEO, DLQ/Idampotenza, filtri privacy.
Ned. 7-8: Pannello FinOps (ingest/retention), downsampling, quote di cardinalità, alert SLO (burn-rate).
Ned. 9-10: eBPF/segnali di basso livello, fide di stato, release-gates.
Ned. 11-12: test chaos, ottimizzazione dei costi, moduli SLA di flusso, avvio di diagrammi di revisione trimestrale.
16) Modelli di manufatti
Telemetry Stream Spec: id, proprietario, schema, classe QoS, fonti, consumatori, retensioni, SLO/alert, privacy-policy.
Schema PR Template: modifica/migrazione, compatibilità, test, piano di ripristino.
Sampling Policy: regole per sollevare il sempling in caso di anomalie; Budget di destinazione.
Cost Review Pack: top fonti per $/valore, offerte per TTL/aggregazioni.
Insert Telemetry Checklist è un elenco di grafici/trailer/logi che devono essere per RCA.
17) KPI/KRI dei flussi di telemetria
Consegna: p95 ritardi di classe,% messaggi persi/24 ore.
Copertura: percentuale di percorsi critici con tracciamento> 90%, percentuale di SLI chiusi con metriche.
La qualità dei segnali è il% degli incidenti catturati dalla SLI prima delle denunce, gli alert falsi/mancati.
Costo: $/RPS per la telemetria, $/trace, quota di rumore nell'iniezione.
Affidabilità: tempi di recupero dal degrado del broker, quantità di repliche.
18) Antipattern
Alta-cardinalità metriche (userId, sessionId) nel TSDB.
Una singola scatola nera senza struttura o schemi.
Assenza di DLQ/idampotenza per le prese e le perdite di picco.
Le retenzioni «infinite», senza , aumentano esponenzialmente i conti.
I trailer senza contesto aziendale (PSP/banca/GEO) hanno una diagnosi scarsa.
Gli schemi incoerenti tra i team si rompono.
Totale
I flussi di telemetria sono un sistema controllato, a più livelli: gli standard e i circuiti di OTEL una sicura iniezione con e backpressure, sempling/aggregazione e reticenze a costo di privacy e multi-tenant-isolamento di SLO-alert, dashboard e gate di lancio. Questo tracciato fornisce segnali iniziali, RCA veloce, costi prevedibili e la sostenibilità della piattaforma iGaming in modalità di punta.