Distributed Tracing

(Section : Technologie et infrastructure)

Résumé succinct

Les traces distribuées donnent la réponse à la question où et pourquoi le temps est perdu sur le chemin de la requête à travers la passerelle, l'API, la file d'attente, les bases de données, les fournisseurs externes (PSP/studios de jeux). OpenTelemetry (OTel) est une norme ouverte SDK/agents/protocole qui combine les trajets, les métriques et les logs. Dans iGaming, c'est un outil de base pour garder p95/p99, localiser rapidement les problèmes de paiement et identifier les « goulots d'étranglement » avant les tournois de pointe.

1) Concepts OTel

Trace est le chemin complet de l'opération (dépôt, pari, retrait).
Span - zone de travail (handler HTTP, requête SQL, appel de file d'attente/fournisseur).
Attributes est une clé-valeur avec des détails ('net. peer. name`, `db. system`, `psp. route`).
Events - événements instantanés (rétraction, temporisation, échec de cache).
Liens - lien avec d'autres pistes (important pour async/queue).
Ressource - métadonnées de processus : 'service. name`, `service. version`, `deployment. environment`, `cloud. region`.

2) Promotion du contexte

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

En option - baggage pour les clés de sécurité (par exemple, 'tenant', 'route'), ne mettez pas PII là-bas.

Où percer le contexte : la passerelle API → les RPC internes → le producteur dans la file d'attente du consumer → → HTTP externes (PSP/fournisseurs).

3) Conventions sémantiques (minimum obligatoire)

HTTP/RPC: `http. method`, `http. route`, `http. status_code`.
DB/cache : 'db. system` (`mysql`/`postgresql`/`redis`), `db. statement '(masqué),' db. operation`.
Files d'attente : 'messaging. system` (`kafka`/`rabbitmq`), `messaging. destination`, `messaging. operation` (`send`/`process`).
Paiements : 'psp. route`, `psp. provider`, `payment. id '(pseudonyme),' amount ',' currency '.
iGaming domaine : 'game. provider`, `game. session_id` (hash), `player. id_hash`.

Une taxonomie unifiée → la comparabilité des dashboards et la recherche rapide des causes.

4) Sampling : comment ne pas se noyer dans les données

Head-based (à l'entrée de la demande)

Simple, bon marché ; convient au flux total.
Moins - vous pouvez perdre des pistes « intéressantes » lentes/erronées.

Tail-based (в Collector)

La décision est prise une fois les spans terminés : nous ne conservons que les erreurs/segments lents/importants (VIP/paiements).
Idéal pour la charge de travail : réduit considérablement le coût avec une grande information.

• Tête : 5-10 % pour le revêtement de fond.
• Tail : 100 % d'erreurs + p95 + pistes de paiement lentes +/sorties canaries.

5) Topologies OpenTelemetry Collector

Agent-sidkar (sur chaque nœud/sous-site) : acceptation locale, tampon minimum, exportation vers l'agrégateur.
Gateway (cluster) : tail-sampling, routage, enrichissement, exportation vers Tempo/Jaeger/Zipkin/OTLP.

Exemple : tail-sampling (fragment 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) Corrélation avec les métriques et les logs

Ajoutez 'trace _ id '/' span _ id' à chaque entrée de logs.
Stockez les métriques de latence comme des histogrammes et incluez les exemples - une référence à la représentation 'trace _ id' pour le « saut » de la boîte p95 dans une trace spécifique.
Annotations de sortie (Git SHA, version chart) - comme events/labels.

7) Instrumentalisation (langages et auto-agents)

Go (manuel + 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

Auto-agent '-javaagent : opentelemetry-javaagent. jar ', config via bou (' OTEL _ SERVICE _ NAME ',' OTEL _ EXPORTATEUR _ OTLP _ ENDPOINT ').
Manuellement : Annotations/outil d'emplacement d'oignon (pools JDBC, cache).

Node. js / Python

Outil automatique avec SDK + plugins (Express/FastAPI/celery).
Pour les files d'attente, les enveloppes du producteur/consumer pour mettre 'messaging.' et les liens.

8) Files d'attente et async : les bons dormeurs

Producteur ('send') : span à envoyer à la file d'attente.
Consumer ('process') : nouveau span de traitement du message de link à span du producteur (garder le lien de causalité sans le 'trace _ id'commun).
Attributs : 'messaging. kafka. partition`, `messaging. rabbitmq. routing_key`, `messaging. message_id`.
Pour les retraits, event 'retry', compteur de tentatives.

9) OBD/cache et N + 1

Activez la traction des pilotes OBD et regroupez les requêtes du même type dans Batchi.
Pour Redis/cache, les attributs 'cache. hit`/`cache. miss`.
Faites des demandes « lourdes » dans des couchages séparés - vous pouvez voir où est p99.

10) Fournisseurs externes : PSP/studios de jeux

Enveloppez les clients HTTP : 'psp. provider`, `psp. route`, `timeout_ms`, `attempt`.
Loger les codes/types d'erreur, mais pas PII (numéro de carte, jetons).
Comparer les studios/itinéraires par 'duration', 'error-rate'.

11) Frontende et RUM

OTel Web SDK: `page_view`, `resource_load`, `xhr`.
Faites glisser 'traceparent' dans le backend pour mettre le chemin d'accès de l'utilisateur sur l'interface utilisateur → l'API → la base de données.
Segmentation par géo/fournisseurs de réseau - labels optionnels.

12) Sécurité et PII

Masquer les champs ('db. statement 'avec édition), hachez' player _ id '.
Zones de données : 'pii = true', 'region = EU/TR/LATAM'.
Contrôle de l'accès aux remorques de paiement (rôle basé).
WORM/Rétention : durée de conservation pour les traces sensibles, suppression par stratégie.

13) Productivité et coût

Tail-sampling par politique : « erreurs + lenteurs + paiements + sorties canaries ».
Downsampling histogrammes métriques, déduplication agressive des logs.
Limitation de la cardinalité : ne pas inscrire 'user _ id' comme label métrique.
Tampons/batchs en Collector, compression OTLP.

14) Dashboards et analyse

Service map : dépendances des services, coloration par erreur/latence.
Release compare : stable vs révisions canaries (p95, error-rate, payments bou).
Top slow traces : sur la route '/deposit ', coupe PSP/région.
Queue lag : pistes avec un profond retard de consommation.

15) Exemples de configurations Collector

Pipelines (métriques/tracés/logs, fragments)

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 (scénarios types)

A) Croissance de p99 dans 'payments-api'

1. Ouvrir « Top slow traces » → échouer dans les spans OBD/PSP.
2. Si le problème PSP est de traduire l'itinéraire, activez les retraits/délais.
3. Vérifiez la file d'attente 'withdrawals' (lag), augmentez les consumers.

B) Erreurs 5xx après la sortie

1. Filtre par service. version`.
2. Comparer stable/canarien ; trouver des épices dans 'psp. route`.
3. Geler la promotion, faire tomber (voir « Stratégies de libération « / » Rolbacky »).

C) Suspicion sur N + 1

1. Tracs avec un grand nombre de spans DB courts.
2. Activer l'agrégation/joyaux, ajouter un cache.

17) Chèque de mise en œuvre

1. Activez le SDK OTel et les attributs de ressources uniques ('service. name`, `env`, `region`).
2. Promotion du W3C Trace Context à travers toutes les couches et files d'attente.
3. Ensemble minimal d'attributs sémantiques (HTTP/DB/queue/PSP).
4. Tail-sampling : erreurs, p95 +, paiements, canard.
5. Logs avec 'trace _ id '/' span _ id', métriques avec exemplars.
6. Dashboards : service map, release compare, payments flow.
7. Politiques PII : masquage, zones, rôles, rétentions.
8. Tests/charge : vérification de la corrélation et du traçage complet avant les pics.
9. Auto-génération de liens runbook en alerts.
10. Rapport sur le coût de la télémétrie et de la cardinalité.

18) Anti-modèles

Les traces « à l'entrée seulement » sans OBD/files d'attente ne sont → utiles.
L'absence de propagande dans async → « déchire » les chaînes de causalité.
Sampling aléatoire 1 % sans logique tail → ne pas attraper lent/faux.
Les logs sans 'trace _ id'ne → pas de corrélation de bout en bout.
Les IPI bruts dans les attributs/loges → les risques de complication.
La cardinalité « au plafond » (user/session en tant que labels métriques) → l'explosion du coût.

Résultats

OpenTelemetry transforme l'observabilité d'un ensemble d'outils disparates en un langage de performance de bout en bout. Avec une bonne promotion du contexte, une sémantique soignée, un tail-sampling et un lien de « métriques de piste ↔ ↔ logs », l'équipe iGaming contrôle p95/p99, isole rapidement les goulots d'étranglement (OBD, files d'attente, PSP) et publie avec confiance des versions même dans les pics de trafic.