Osservabilità e telemetria

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

L'osservazione è la capacità di rispondere al «perché funziona così?» senza la presentazione dei nuovi bilanci. Nel iGaming è critico: tornei di punta, picchi di pagamento, multiregionalità e requisiti di gambling responsabile/PII. Base - metriche, fogli, tracciabili, combinati da identificatori e standard comuni (OpenTelemetry), con contratti SLO, alerting rumoroso e controllo dei costi.

1) Ossatura di osservabilità: di cosa si compone

Metriche (numeri orari): RED/USE, Business KPI, SLI. Memorizzati in TSDB.
Loghi (eventi testo/JSON) - Controllo, errori, fatti aziendali, protezione.
Traccia (span): percorso di query attraverso servizi, latitanza, cause di ritardo.
Profiling: CPU/memoria/eBPF-flussi, heap/lock-contensioni.
RUM e sintetico: utenti reali (web/app) + test robot.
Catalogo di telemetria: schemi, criteri PII, tempi di conservazione, tag di costo.

2) Tassonomia segnali e principi

RED для API: Rate, Errors, Duration.
USE per l'infrastruttura: Utilization, Saturation, Errors (CPU, dischi, rete, code).
SLI/SLO: indicatori misurabili (ad esempio richieste di successo/tutte, p95 latency), obiettivi di disponibilità (ad esempio, "99. 9% in 30 giorni"), il bilancio degli errori → i processi.
High-cardinality con intelligenza: le etichette discografiche devono essere utili in tagli (regione/tenante/provider), ma non esplodere TSDB.

3) Standard e correlazione completa

OpenTelemetry (OTTEL) - Un unico SDK/protocollo per metriche, fogli e tracciati.
Identificatori: «trace _ id», «span _ id», «correlation _ id», «player _ id» (alias), «payment _ route».
ID di flusso: gateway di ingresso tutti i microservizi di pagamenti/PSP/code/giubbotti di login/metriche/span.

Esempio: intestazione correlazione

traceparent: 00-<trace_id>-<span_id>-01 x-request-id: <correlation_id>

4) Metriche: cosa e come misuriamo

Denominazione/etichetta

`service="payments-api"`, `env="prod"`, `region="eu-west"`, `tenant`, `provider="pspX"`.

Esempi di Prometheus

prometheus
RED http_requests_total{service="api",route="/deposit",method="POST",status="200"}
http_request_duration_seconds_bucket{service="api",le="0. 25",route="/deposit"} 1234 http_request_errors_total{service="api",route="/deposit"}

USE cpu_utilization_ratio{node="n1"} 0. 71 queue_depth{queue="withdrawals"} 128

Бизнес payments_success_total{psp="X",currency="EUR"} 4521 payment_conversion_ratio{route="pspX"} 0. 948

Istogrammi ed exemplars

Conserva gli istogrammi di latitanza (native-historograms/vcuckets) e aggancia l'exemplar con'trace _ id ', per saltare dal «baco lento» a una pista specifica.

5) Loghi: strutturato e sicuro

Solo JSON (niente free-form in vendita).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
Masking/hash PII, singoli indici/retention per sensibile.
Pipline dei logi: parsing, normalizzazione dell'arricchimento (geo/ASN), modifica dell'indicizzazione PII.

Esempio di evento JSON

json
{
"ts":"2025-11-05T10:42:31Z",
"sev":"ERROR",
"service":"payments-api",
"event":"psp_timeout",
"trace_id":"9c5e...e2",
"route":"pspX",
"duration_ms": 3100,
"attempt":2,
"player_id_hash":"p:1b7f...",
"pii_redacted":true
}

6) Tracce: dove perdere tempo

Span: richiesta di input, chiamate di provider (PSP/Games Provider), database/cache, RPC interserver.
Attributi: 'db. system`, `net. peer. name`, `messaging. system`, `psp. route`, `game. provider`.

• head-based (probabile) per il volume,
• tail-based (per errori, p95 +, segmento VIP),
• guaranteed-keep per pagamenti/critici PII.

7) Osservazione del fronte e del mobile

RUM: TTFB, FCP/LCP/CLS/INP, errori JS, reti e routing SPA.
Crash-report: simbolazione, disobfusione, versione del cartellino, dispositivo/OS.
Sintetica: script di ingresso/deposito/tasso; Controlli geografici.

8) SLO, SLI e bilancio degli errori

Esempio SLO (pseudo-YAML)

yaml service: payments-api sli:
- name: availability expr: sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
- name: latency_p95 expr: histogram_quantile(0. 95, rate(http_request_duration_seconds_bucket[5m]))
targets:
availability: "99. 9%/30d"
latency_p95: "<=250ms/30d"
error_budget_policy:
fast_burn: 5% for 1h -> page, freeze deploy slow_burn: 20% for 24h -> incident, improvement plan

Alerting sul budget degli errori, non su ogni metrica.
Procedure Freeze per bruciare il budget: limitare i rilasci/canarini.

9) Alerting senza rumore

Multi-window, multi-burn regole: finestra breve/lunga.
Deduplicazione/routing per servizi/regioni/criticità in on-call.
Runbook URL e assemblaggio automatico del contesto (ultimi deploi, modifiche ai configuri, grafico delle dipendenze).
Orologio silenzioso e soppressione durante i lavori di routine.

Esempio di regola (idea PromQL)

promql alert: PaymentsSLOFastBurn expr: slo_error_rate_5m > 2 slo_budget_rate for: 15m labels: { severity="page", service="payments-api" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"

10) Profiling e eBPF

eBPF/profiler: flame CPU/alloc, latitanza I/O, drop di rete, anomalie Syscall.
Utile con le strette p99, jitter e rare dipendenze.

11) Osservazione aziendale (product & risk)

Finanza/monetizzazione: conversione dei depositi, TTW (time-to-wallet), auto ./settl, cancellazioni/charjbeck.
Attività di gioco: retenschn/strick, quota di scommesse live, «appiccicosità» dei provider.
Antifrode/abuse: velocità di azione, corrispondenza dei dispositivi/IP, correlazioni.
Indicatori RG: sessioni lunghe, «raggiungimento», bistecche crescenti.
Le metriche aziendali sono correlate con le metriche e le release (annotation events).

12) Sicurezza, PII e conformità

Data-zone - Tag dataset/login ('pii = true', 'region = EU').
Maschera prima dell'indicizzazione, alias ID.
Storage WORM per il controllo Accesso di ruolo al cavo.
Tempi di conservazione diversi per i tecnici/verifiche/business.
Vietare i segreti crudi nei reparti; scan-test in CI.

13) Gestione del costo (FinOps)

Limite di cardinalità: attenzione con'user _ id ',' sessions _ id '.
Partitura/retenschn: caldo (7-14 giorni), caldo (30-90), freddo (archivio).
Sampling piste (tail-based) e downsampling metriche.
Bollo per i tag «team», «service», «tenant»: rapporti «chi brucia l'osservazione».

14) Strumentazione (matricola)

Metriche: Prometheus/lake per metriche, dashboard Grafana.
Logi: Loki/ELK; ingestione regole, reduction/parsing.
Trailer: Tempo/Jaeger/Raccoglitori OTel; eccplars-lines da metriche.
Il sintetico è l'esportatore Blackbox, i browser robot.
Alerting: Alertmanager/chat-integrazione, on-call rotazione.
Profiling, profiling.

15) Esempi: implementare rapidamente la base

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route'])
def handle(req):
with lat. labels(route=req. route). time():
status = app(req)
reqs. labels(route=req. route,method=req. method,status=str(status)). inc()

go tid:= ctx. Value("trace_id")
logger = logger. With("trace_id", tid)
logger. Info("deposit-accepted", "amount", amt, "route", route)

prometheus http_request_duration_seconds_bucket{..., le="0. 25"} 1023 # exemplar: trace_id=9c5e...

16) Processi e operazioni

Un unico dizionario/etichetta (naming-guide) e un modello di dashboard.
Release-annotazioni automatica nei grafici.
Incidenti: carta, timeline, RCA senza accuse, action items.
Ansia di apprendimento (game-day) - Simulazione di cadute, ritardi PSP, surriscaldamento della cache.
Runbooks - istruzioni passo passo e collegamenti automatici da alert.

17) Assegno-foglia di maturità

1. OtTel SDK/raccoglitore → un'unica esportazione di metriche/fogli/trailer.
2. RED/USE coprono tutti i servizi + SLI/SLO per API chiave.
3. La correlazione'trace _ id 'è una correlazione tra i fogli della metrica (exemplars, jump-links).
4. Alert di bilancio errori con multi-burn e link runabook.
5. RUM + sintetico per deposito/tasso/output.
6. Profiling (eBPF) sulla lista bianca.
7. Criteri PII: occultamento, zone, accesso, conservazione.
8. Rapporto finanziario sui costi della telemetria (tag «team/service»).
9. Preparazione al picco - Piano di prova, riscaldamento della cache, modelli alert.
10. RCA regolari e revisione SLO/soglie.

18) Antipattern

Fogli «lenzuola» senza struttura e «trace _ id».
Gli alert di ogni metrica → alert-fatiG.
Gli istogrammi non sono corretti.
L'illimitata radicalità delle etichette ha fatto esplodere il valore.
L'assenza di RUM/sintetici è «ok» e l'utente no.
Miscelazione di PII con i tecnici, ritenzione a tempo indeterminato.
L'isolamento della telemetria dalla KPI aziendale - «La latitanza è in calo, anche i ricavi».

Riepilogo

Una forte osservabilità è il linguaggio comune tra prodotto, SRE, sicurezza e pagamento. Collegando le metriche, i fogli, le piste sotto OTEL, introducendo SLO con il budget degli errori, rendendo l'alerting intelligente e il costo gestibile, si ottiene un sistema che prima nota i problemi, riparare più velocemente e passare prevedibilmente picchi di traffico e carichi di tornei.