Distributed Tracing

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Le tracce distribuite forniscono una risposta a dove e perché si perde tempo durante il percorso di query attraverso gateway, API, code, database, provider esterni (PSP/Giochi Studios). OpenTelemetry (OTel) è uno standard SDK/agenti/protocollo aperto che unisce trailer, metriche e loghi. Nel iGaming è uno strumento di base per tenere p95/p99, localizzare rapidamente i problemi di pagamento e individuare «colli di bottiglia» prima dei tornei di picco.

1) Concetti OTEL

Trace è un percorso di transazione completo (deposito, tasso, output).
Span è un pezzo di lavoro (HTTP-handler, richiesta SQL, chiamata coda/provider).
Attribute è un valore chiave con parti ('net. peer. name`, `db. system`, `psp. route`).
Events - Eventi istantanei (retrai, timeout, cache).
Links - Collegamento ad altre piste (importante per async/queue).
Resource - Metadati del processo: 'service. name`, `service. version`, `deployment. environment`, `cloud. region`.

2) Esplorazione contesto

traceparent: 00-<trace_id>-<span_id>-01 tracestate:...

Opzionale - baggage per chiavi sicure (ad esempio, «tenant», «route»), non metterci PII.

Dove intravedere il contesto: gateway API e RPC interni, produttore → nella coda di → → → HTTP (provider PSP/PSP).

3) Convenzioni semantiche (minimo obbligatorio)

HTTP/RPC: `http. method`, `http. route`, `http. status_code`.
DB/cache: 'db. system` (`mysql`/`postgresql`/`redis`), `db. statement '(mascherato),' db. operation`.
Code: 'messaging. system` (`kafka`/`rabbitmq`), `messaging. destination`, `messaging. operation` (`send`/`process`).
Pagamenti: 'psp. route`, `psp. provider`, `payment. id "(alias)," amount "," currency ".
Dominio iGaming: 'game. provider`, `game. session_id` (hash), `player. id_hash`.

Una tassonomia → la comparabilità dei dashboard e una rapida ricerca delle cause.

4) Sampling: come non affondare nei dati

Head-based (all'ingresso della query)

Semplice, economico; adatto per il flusso totale.
Meno - si possono perdere piste lente/sbagliate.

Tail-based (в Collector)

La decisione viene presa dopo il completamento degli span: conserviamo solo errori/segmenti lenti/importanti (VIP/pagamenti).
Ideale per il carico di lavoro di prode, che riduce notevolmente i costi con elevata sensibilità.

• Head: 5-10% per la copertura di sottofondo.
• Tail: 100% di errori + p95 + lenti di pagamento/rilascio canario.

5) Topologie di OpenTelemetry Collector

Server agente (su ogni nodo/sottofondo) - Ricezione locale, buffer minimo, esportazione in aggregatore.
Gateway (cluster): tail-sampling, routing, arricchimento, esportazione in Tempo/Jaeger/Zipkin/OTLP.

Esempio: tail-sampling (frammento YAML)

yaml processors:
tailsampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code:
status_codes: [ ERROR ]
- name: slow_p95 type: latency latency:
threshold_ms: 250
- name: payments type: string_attribute string_attribute:
key: service. name values: [ "payments-api", "payments-worker" ]

6) Correlazione con metriche e loghi

Aggiungete «trace _ id »/« span _ id» a ogni voce di tubo.
Memorizzare le metriche di latenza come istogrammi e includere exemplars - il riferimento al rappresentativo «trace _ id» per «salto» da p95-booket a una traccia specifica.
Annotazioni di rilascio (Git SHA) - Come events/etichette.

7) Strumentalizzazione (lingue e agenti auto)

Go (manuale + auto)

go tp:= sdktrace. NewTracerProvider(
sdktrace. WithBatcher(exporter),
sdktrace. WithResource(resource. NewWithAttributes(
semconv. SchemaURL,
semconv. ServiceName("payments-api"),
)),
)
otel. SetTracerProvider(tp)

ctx, span:= tracer. Start(ctx, "Deposit")
defer span. End()
span. SetAttributes(
attribute. String("psp. route","pspX"),
attribute. String("currency","EUR"),
)

Java

Agente auto '-javaagent: opentelemetry-javaagent. jar ', Config per env (' OTEL _ SERVICE _ NAME ',' OTEL _ EXPORTER _ OTLP _ ENDPOINT ').
Manualmente - Annotazioni/utensile dei punti di cipolla (pool JDBC, cache).

Node. js / Python

Utensile auto con SDK + plugin (Express/FastAPI/celery).
Per le code, gli involucri del produttore/consumatore per mettere in scena «messagging» e links.

8) Code e async: span corretti

Produttore ('send'): span da inviare al top/coda.
Consumatore («process») - Nuovo span per l'elaborazione del messaggio da link a span produttore (salvare la causale senza generare «trace _ id»).
Attributi: 'messaging. kafka. partition`, `messaging. rabbitmq. routing_key`, `messaging. message_id`.
Per i retrai - event'retry ', conteggio tentativi.

9) Database/cache e N + 1

Attivare il driver dei driver di database, raggruppare le richieste in batch identiche.
Per Redis/cache, gli attributi'cache. hit`/`cache. miss`.
Portate le query «pesanti» nei singoli span - vediamo dove p99.

10) Provider esterni: PSP/giochi

Avvolgere i client HTTP: 'psp. provider`, `psp. route`, `timeout_ms`, `attempt`.
Logica codici/tipi di errore, ma non PII (numero di mappa, token).
Confrontare gli studi/percorsi per «duration», «error-rate».

11) Frontand e RUM

OTel Web SDK: `page_view`, `resource_load`, `xhr`.
Scorri «traceparent» nel backend per tracciare il percorso dell'utente con l'API e l'API.
Segmentazione geo/provider di rete - etichette opzionali.

12) Sicurezza e PII

Maschera i campi ('db. statement 'con modifica), hash' player _ id '.
Zone dati: 'pii = true', 'region = EU/TR/LATAM'.
Controllo dell'accesso alle roulotte di pagamento (ruolo basato).
Data di conservazione per le tracce sensibili, eliminazione per criteri.

13) Prestazioni e costi

Tail-sampling criteri: «Errori + lenti + pagamenti + rilasci canari».
Dawnsampling istogrammi di metriche, deduplicazione aggressiva dei logi.
Vincolo di cardinalità: non inserire «user _ id» come etichetta metrica.
Buffer/batch in Collettore, compressione OTLP.

14) Dashboard e analisi

Servizio map: dipendenze dei servizi, colorazione degli errori/latitanza.
Release compare - Revisione vs canaresca stabile (p95, errato-rate, payments convs).
Top slow traces: percorso «/deposit », taglio per PSP/regione.
Le piste con un profondo ritardo nel consumo.

15) Esempi di configurazioni Collector

Pipelines (metriche/trailer/fogli, frammento)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch:
memory_limiter:
limit_mib: 1024 spike_limit_mib: 256 attributes/payments:
actions:
- key: "psp. provider"
action: insert value: "pspX"

exporters:
otlp/traces: { endpoint: tempo:4317, tls: { insecure: true } }
otlp/metrics:{ endpoint: prometheus-otlp:4317, tls: { insecure: true } }
otlp/logs:  { endpoint: loki-otlp:4317, tls: { insecure: true } }

service:
pipelines:
traces:
receivers: [ otlp ]
processors: [ memory_limiter, batch, tailsampling ]
exporters: [ otlp/traces ]
metrics:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/metrics ]
logs:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/logs ]

16) Runbooks (tipici script)

A) p99 in «payments-api»

1. Apri «Top slow traces» per → in un database di database/PSP.
2. Se il problema PSP è tradurre l'itinerario, attivare i retrai/timeout.
3. Controlla la coda dì withdrawals "(lag), aumenta le consolle.

B) Errori 5xx dopo il lancio

1. Filtro dì service ". version`.
2. Confrontare stabile/canarico; trovare le fiammate dì psp ". route`.
3. Congelare la promozione, ritoccare (vedere Strategie di rilascio/Rolbecky).

C) Sospetto di N + 1

1. Roulotte con un gran numero di DB-span brevi.
2. Attiva aggregazione/gioielli, aggiungi livello cache.

17) Assegno-foglio di implementazione

1. Includere OTtel SDK e gli attributi di resource unici ('service. name`, `env`, `region`).
2. Esplorazione di W3C Trace Text attraverso tutti i livelli e le code.
3. Insieme minimo di attributi semantici (HTTP/DB/queue/PSP).
4. Tail-sampling: errori, p95 +, pagamenti, canaro.
5. Loghi con «trace _ id »/« span _ id», metriche con exemplars.
6. Dashboard: service map, release compare, payments flow.
7. Criteri PII: maschera, zone, ruoli, retensioni.
8. Test/carico - Verifica di correlazione e completeness tracsing prima dei picchi.
9. Generazione automatica dei collegamenti runbook negli alert.
10. Rapporto sui costi della telemetria e della radicalità.

18) Antipattern

Tracciare «solo in entrata» senza database/code non è utile.
L'assenza di denunce nell'async si sta interrompendo.
Il sampling è casuale 1% senza una logica tail. Non catturiamo lenti/errati.
Non c'è nessuna correlazione passante senza «trace _ id».
I PII crudi negli attributi/logi contengono i rischi della compilazione.
La cardinalità nel soffitto (user/sessione come etichette metriche) ha fatto esplodere il valore.

Riepilogo

OpenTelemetry trasforma l'osservabilità da un insieme di strumenti separati a un linguaggio di prestazioni end-to-end. Con la corretta esplorazione del contesto, la semantica attenta, il tail-sampling e l'allineamento delle metriche della pista , il comando tiene sotto controllo il p95/p99, isola rapidamente i colli di bottiglia (database, code, PSP) e rilascia i rilasci in modo sicuro anche nei picchi di traffico.