Flux de télémétrie

1) Destination et contexte

Les flux de télémétrie fournissent un flux continu de données d'observation sur le fonctionnement de la plate-forme : ce qui se passe, pourquoi et combien cela coûte. Dans iGaming, c'est la clé de la détection précoce des dégradations des dépôts/paris, de la visibilité des fournisseurs externes (PSP/KYC/studios de jeux) et de la conformité prouvée de SLO/conformité.

2) Carte des sources de télémétrie

Métriques (TSDB) : RED/USE, SLI d'entreprise (succès des autorisations, % de taux de réussite).
Tracks (OTel) : chaînes de requêtes à travers le front → API → courtiers → OBD/PSP.
Logs (structurés) : événements, audit des opérations, erreurs.
RUM : TTFB/LCP, erreurs JS, géo/périphérique.
Synthétique : transactions d'essai externes (login/dépôt/ » sandwich ») à partir de différents GEO.
Télémétrie de bas niveau : eBPF/profil CPU/IO/alloc, réseau p95/p99.
Statuts externes : Webhooks/pools PSP/KYC/CDN/WAF.

3) Normes et schémas

OpenTelemetry comme lingua franca : unification de la sémantique des attributs (service. name, deployment. environment, enduser. id - masqué, trace/SpanID, codes PSP).
Accords de schémas : versioning, schema registry pour les logs/tracks, « breaking-changes » uniquement via le drapeau binaire et la période grace.
Correlation-ID : un seul 'correlation _ id' pour payer/parier à travers toutes les couches + examplars dans les percentiles des métriques.

4) Convoyeur d'injection (haut niveau)

1. Producteurs : SDK/agents/collecteurs (OTel Collector sur les nœuds).
2. Mise en mémoire tampon Edge : files d'attente locales (memory/disk) avec limites.
3. Transport : gRPC/HTTP OTLP → courtier de messages (Kafka/Pulsar) avec clés d'idempotency.
4. Processeurs : normalisation, enrichissement (GEO/tenant/canal), filtres PII, sample fin.
5. Fan-out : dans le TSDB (métriques), dans le magasin de pistes, dans le système de logs, dans le lac/DWH, dans l'alerte/les règles.
6. Consumers : dashboards, SLO-alerties (burn-rate), enquêtes, status-page, auto-gate releases.

5) QoS et classes de flux

Classe A (temps réel, P1) : SLI/SLO, synthétique, fournisseurs clés (PSP/KYC). SLA de livraison : <5-10 c, ≥99. 9%.
Classe B (opérationnel) : Trajets/logs pour RCA, SLA : <1-2 min.
Classe C (analytique) : agrégats et batchs dans le lac/DWH, SLA : heure/jour.
Routage par classe → hiérarchisation, rétentions différentes, files d'attente/tops séparés.

6) Sempling, agrégation, rétention

Métriques : downsampling des séries historiques (1s→10s→1m), agrégats percentyles, exemples.
Traces : tail-based sampling (augmenter la proportion en cas d'anomalies, erreurs PSP, p99- « surtensions »).
Logs : niveau par profil, compression, rejet de bruit (ping santé, DEBUG sur la vente - interdit).
Retenshn : « chaud » (détail de 7 à 14 jours), « froid » (agrégats/archives). Stratégies par classe de données et coût.

7) Vie privée et conformité

Hygiène PII : masquage/tokenisation des identifiants ; l'interdiction des documents KUS/jetons de cartes en télémétrie.
Géolocalisation : stockage par juridiction ; Exporter uniquement via un flux de travail approuvé (cryptage, TTL, audit).
Contrôle d'accès : RBAC/ABAC aux dépôts de télémétrie, SoD au déchargement.

8) Fiabilité des flux

Idempotence : clés sur les événements, dedup dans les processeurs.
Backpressure : limites d'injection per-tenant/service ; les politiques de drop pour les champs de faible priorité en cas de surcharge.
Replays : stockage dans un courtier ≥72 h pour le retraitement.
Dead-letter : routage des erreurs (schéma, taille, violation PII) vers un DLQ sécurisé avec alertes.
Versioning : « double flux » lors du changement de schéma (v1 + v2) et migration des consommateurs.

9) Multi-tenant et isolant

Les balises 'tenant _ id/brand/region' de chaque événement ; quotas et budgets per-tenants.
Isolation des flux A/B selon les axes ; showback/chargeback par injection et stockage.
Masquage/agrégation jusqu'à la limite du tenant lors de l'exportation.

10) Catalogue de flux (exemple de champs)

ID : 'telemetry. payments. auth. success. rate. eu`

Classe : A (temps réel)

Схема: `{timestamp, tenant, region, psp, bank_bin_group, success_rate, window}`

Source : OTel Collector + PSP-router metrics

Consommateurs : SLO-alertes, Exec-dashboard, status page

Rétention : 30 jours chauds, unités 12 mois

Propriétaire : Payments SRE, dpo-owner (privacy)

SLO du flux : retard <10 c p95, perte <0. 1 %/jour

11) Intégration avec alerting et releases

SLO-alertes par burn-rate (fenêtre rapide/lente) pour les dépôts/paris.
Release-gates : analyse canarique de SLI ; auto-stop/rollback en cas de dégradation.
Page de statut : Fid de mises à jour de la carte incident + agrégats SLI.

12) Ensemble de dashboards clés

Exec : aptyme, taux de croissance, succès des autorisations/paris (par GEO/PSP), statut des fournisseurs, $/RPS de télémétrie.
SRE/Plate-forme : RED/USE pour les services, les files d'attente, la détection outlier, les profils eBPF.
Payments/Risk : conversion par banques/PSP, soft/hard declines, KYC SLA, premiers signaux chargeback.
Cost-obs : volume d'injection par source, top labels de cardinalité, coût par flux.

13) Finances de l'observabilité (FinOps)

Valeur KPI : $/GB ingest, $/trace, $/SLI-dashboard ; rapport sur les métriques et labels « lourds ».
Optimisation : agrégation et mise à niveau, échantillonnage dynamique, nettoyage des logs chatti, classe de stockage par importance.
Politiques : quotas de haute cardinalité, limites de fréquence d'émission, examen des schémas une fois par trimestre.

14) Processus et rôles

Data/Observability Owners на домены (Payments, Games, Core API, Infra).
Changement-Control pour les circuits : PR-rhubarbe, banc d'essai, compatibilité avec les consommateurs.
Tabletop/Chaos-days : déconnexion des fournisseurs, surchauffe du courtier, contrôle de backpressure/idempotence.
Post-mortem : inclure l'analyse de télémétrie (suffisance des signaux, faux positifs, coût).

15) Feuille de route pour la mise en œuvre (8-12 semaines)

Ned. 1-2 : audit des flux actuels, carte des sources, objectifs de télémétrie SLO, choix des normes (OTel, TSDB, trajets, logs).
Ned. 3-4 : OTel-collecteurs, unique correlation-ID, base RED/USE + SLI d'entreprise sur le dépôt/pari, catalogue de flux v0.
Ned. 5-6 : tail-based sempling, synthétique par GEO, DLQ/idempotence, filtres de confidentialité.
Ned. 7-8 : FinOps panel (ingest/retraite), downsampling, quotas de cardinalité, SLO-alertes (burn-rate).
Ned. 9-10 : Signaux eBPF/de bas niveau, Fid Status Page, release-gates.
Ned. 11-12 : tests de chaos, optimisation des coûts, formal SLA des flux, lancement de la revue trimestrielle des schémas.

16) Modèles d'artefacts

Telemetry Stream Spec : id, propriétaire, circuit, classe QoS, sources, consommateurs, rétentions, SLO/alertes, politique de confidentialité.
Schema PR Template : changement/migration, compatibilité, tests, plan de retour.
Politique de sampling : règles de levage de l'échantillon en cas d'anomalies ; budgets ciblés.
Cost Review Pack : principales sources pour $/valeur, propositions pour TTL/agrégations.
Témoin de télémétrie d'incident : liste des cartes/tracés/logs qui doivent être pour RCA.

17) KPI/KRI des flux de télémétrie

Livraison : p95 retards par classe, % de messages perdus/24 heures.
Couverture : proportion de voies critiques avec trace> 90 %, proportion de SLI fermés par métriques.
Qualité des signaux :% des incidents capturés par SLI avant les plaintes, alertes fausses/manquées.
Coût : $/RPS par télémétrie, $/trace, proportion de « bruit » dans l'injection.
Fiabilité : temps de récupération après dégradation du courtier, volume des relais.

18) Anti-modèles

Métrique de haute cardinalité (userId, sessionId) dans TSDB.
Une seule « boîte noire » de logs sans structuration ni schémas.
L'absence DLQ/idempotentnosti → doubles et les pertes aux pics.
Retences « infinies » sans FinOps → croissance exponentielle des comptes.
Trajets sans contexte d'affaires (PSP/banque/GEO) → faible diagnostic.
Les schémas incohérents entre les équipes sont → brisés par les consommateurs.

Résultat

Les flux телеметрии est un système dirigé, multicouche : les OTel-standards et les schémas → sûr инжест avec QoS et backpressure → la sempling/aggrégation et ретенции sous le coût → приватность et la moul'ti-tenant-isolation → SLO-alerty, дашборды et гейты des releases. Une telle boucle fournit des signaux précoces, un RCA rapide, des coûts prévisibles et la stabilité de la plate-forme iGaming dans les modes de pointe.