Observation et télémétrie

(Section : Technologie et infrastructure)

Résumé succinct

L'observabilité est la capacité de répondre à « pourquoi fonctionne-t-elle comme ça ? » pas de sortie de nouveaux bilds. Dans iGaming, c'est essentiel : tournois de pointe, pics de paiement, multirégionalité et exigences de gambling/PII responsable. Les bases sont des métriques, des logs, des traçages combinés avec des identifiants et des normes communs (OpenTelemetry), avec des contrats SLO, un alerting résistant au bruit et un contrôle des coûts.

1) Cadre d'observabilité : en quoi il consiste

Métriques (nombres en fonction du temps) : RED/USE, KPI d'entreprise, SLI. Stocké dans la BST.
Logs (événements dans le texte/JSON) : audit, erreurs, faits commerciaux, sécurité.
Traces (spins) : chemin de requête via les services, latences, causes des retards.
Profil : CPU/mémoire/eBPF-threads, heap/lock-contour.
RUM et synthétiques : utilisateurs réels (web/app) + robot de vérification.
Catalogue de télémétrie : schémas, politiques PII, durées de conservation, notes de coût.

2) Taxonomie des signaux et principes

RED для API: Rate, Errors, Duration.
USE pour l'infrastructure : Utilisation, Saturation, Errors (CPU, disques, réseau, files d'attente).
SLI/SLO : indicateurs mesurables (par exemple, requêtes réussies/tous, p95 latitude), objectifs d'accessibilité (par exemple, "99. 9 % en 30 jours"), le budget des erreurs → les déclencheurs de processus.
Haute-cardinalité intelligente : les labels doivent être utiles dans les coupes (région/tenant/fournisseur), mais pas exploser TSDB.

3) Normes et corrélation de bout en bout

OpenTelemetry (OTel) : un SDK/protocole unique pour les métriques, les logs et les traces.
Identifiants : 'trace _ id', 'span _ id', 'correlation _ id', 'player _ id' (pseudonyme), 'payment _ route'.
Flux ID : passerelle d'entrée → tous les microservices → paiements/PSP → file d'attente/jobs → logs/métriques/spans.

Exemple : titres de corrélation

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

4) Métriques : Quoi et comment nous mesurons

Noms/labels

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

Exemples de 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

Histogrammes et exemples

Gardez les histogrammes de latence (native-histogrammes/ β uckets) et attachez un examplar avec 'trace _ id' pour sauter d'un « baquet lent » à une piste spécifique.

5) Logs : structuré et sûr

Seulement JSON (pas de « forme libre » dans la vente).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
Masquage/hachage PII, index/rétention séparés pour le sensible.
Pipline logs : parsing → normalisation → enrichissement (geo/ASN) → édition PII → indexation.

Exemple d'événement 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) Traces : où le temps est perdu

Spans : demande d'entrée, appels de fournisseurs (PSP/fournisseurs de jeux), bases de données/cache, RPC interservices.
Attributs : 'db. system`, `net. peer. name`, `messaging. system`, `psp. route`, `game. provider`.

• head-based (probabiliste) pour le volume,
• tail-based (selon les conditions : erreurs, p95 +, segment VIP),
• guaranteed-keep pour les paiements/PII-critiques.

7) L'observabilité du front et du mobile

RUM : TTFB, FCP/LCP/CLS/INP, erreurs JS, réseau et routage SPA.
Crash reports : symbolisme, déobfuscation, version du billet, appareil/OS.
Synthétique : scénarios d'entrée/dépôt/paris ; les inspections géo-distribuées.

8) SLO, SLI et budget des erreurs

Exemple 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

Alerter sur le budget des erreurs, pas sur « chaque métrique ».
Procédures freeze pour la combustion du budget : limiter les sorties/canaries.

9) Alerting sans bruit

Multi-window, multi-burn règles : fenêtre courte/longue.
Déduplication/routing : par service/région/criticité dans on-call.
Runbook URL et auto-assembler le contexte (derniers déployages, modifications de configues, graphique de dépendance).
Heures silencieuses et suppression pendant les travaux de routine.

Exemple de règle (idée de BouQL)

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) Profilage et eBPF

eBPF/profilers : graphes flame CPU/alloc, I/O-latence, drops réseau, anomalies Syscall.
Utile pour les goulots d'étranglement p99, le « gitter » et les accrochages rares.

11) Observation des affaires (produit et risque)

Finance/monétisation : conversion des dépôts, TTW (time-to-wallet), auteur ./settle, annulation/chargbecky.
Activité de jeu : rétention/stick, part de paris en direct, « collant » des fournisseurs.
Antifrod/abyse : taux d'action, coïncidences périphériques/IP, corrélations.
Indicateurs RG : longues sessions, « dogon », croissance des steaks.
Les mesures commerciales sont corrélées avec les mesures techniques et les versions (annotation events).

12) Sécurité, PII et conformité

Data-zones : balises datacets/logs ('pii = true', 'region = EU').
Masquage avant indexation, pseudonyme des identifiants.
Stockage WORM pour l'audit ; accès de rôle à la loge.
Durées de conservation : différentes pour les techniciens/auditeurs/entreprises.
L'interdiction des secrets bruts dans les loges ; scan-check en CI.

13) Gestion des coûts (FinOps)

Limite de cardinalité : attention avec 'user _ id', 'session _ id'.
Lot/rétention : chaud (7-14 jours), chaud (30-90), froid (archives).
Sentiers de sampling (tail-based) et métriques de downsampling.
Facturation par tags « team », « service », « tenant » : rapports « qui brûle l'observabilité ».

14) Boîte à outils (pile de référence)

Métriques : Prometheus/lack pour métriques, dashboards Grafana.
Logs : Loki/ELK ; règles d'ingestion, réduction/parsing.
Tracés : Tempo/Jaeger/OTel-collecteurs ; exemplars-links à partir de métriques.
Synthétiques : Blackbox-exportateur, robots de navigateur.
Alerting : Alertmanager/intégration de chat, rotation sur appel.
Profilage : eBPF/profilage continu.

15) Exemples : mettre rapidement en œuvre 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) Processus et opérations

Un seul dictionnaire de métriques/labels (naming-guide) et un modèle de dashboards.
Release-annotations automatiques dans les graphes.
Incidents : carte, temps, RCA sans charges, éléments d'action.
Alarmes d'apprentissage (« game-day ») : simulations de chutes, retards PSP, surchauffe du cache.
Runbooks : instructions étape par étape et liens automatiques à partir d'alerts.

17) Chèque de maturité

1. Le SDK/collecteur OTel → une seule exportation de métriques/logs/remorques.
2. RED/USE couvre tous les services + SLI/SLO via les API clés.
3. Corrélation 'trace _ id' ⇄ logs ⇄ métriques (examplars, jump-links).
4. Alert sur le budget des erreurs avec des liens multi-burn et runabook.
5. RUM + synthétique sur « dépôt/pari/retrait ».
6. Profilage (eBPF) en vente sur liste blanche.
7. Politiques PII : masquage, zones, accès, durée de conservation.
8. Rapport financier sur le coût de la télémétrie (étiquettes « team/service »).
9. « Prêt pour la charge de pointe » : plan de test, échauffement des caches, modèles d'alerte.
10. RCA réguliers et révision des SLO/seuils.

18) Anti-modèles

Logs « draps » sans structure et 'trace _ id'.
Alert pour chaque métrique → alert-fatIg.
Les histogrammes sans réservoirs corrects → « plat » p95.
La cardinalité illimitée des labels → une explosion des coûts.
L'absence de RUM/synthétiques est « tout ok », et l'utilisateur ne l'est pas.
Mélange de PII avec des technologues, rétention indéfinie.
L'isolement de la télémétrie des KPI d'affaires - « la latence diminue, les revenus aussi ».

Résultats

Une forte observabilité est un langage commun entre le produit, le SRE, la sécurité et les paiements. En connectant les métriques, les logs, les pistes sous OTel, en introduisant un SLO avec un budget d'erreur, en rendant l'alerte intelligente et le coût gérable, vous obtenez un système qui remarque les problèmes avant, se rétablit plus rapidement et passe prédictivement les pics de trafic et les charges de tournoi.