Surveillance et logging

1) Pourquoi est-ce important dans iGaming

Argent en temps réel : acceptation des dépôts, paiements instantanés, calcul des paris et des gains, tournois - tout est sensible aux retards et aux pannes.
Réglementation et audit : une traçabilité complète des actions est requise (KYC/AML, paiements, limites de jeu responsable).
Architecture distribuée complexe : passerelles API, orchestration de paiement, EDA/Kafka, services fournisseurs, clients mobiles, fronts, bus BI.
Objectif : réduire le DTMT/DTMT, maintenir le SLO sur les signaux dorés et fournir une force d'incident.

2) Concepts de base de l'observabilité

Logs : événements détaillés (structurés par JSON), adaptés aux enquêtes et aux audits.
Métriques : agrégats temporels (TSDB), adaptés aux SLO/alerts.
Tracks : chaînes causales de requêtes (trace/span) à travers les services/courtiers/OBD.
Evénements : les événements de domaine (BetPlaced, DepositApproved) sont un pont entre les métriques d'entreprise et la technique.

3) « Signaux dorés » et SLI/SLO pour iGaming

Latitude : P95/P99 sur les flux critiques (autorisation, dépôt, pari, début de session, spin).
Traffic : RPS par API, TPS par paiement, EPS par événement.
Errors : proportion 5xx/4xx, taux décline, failed-withdrawals, erreurs des fournisseurs.
Saturation: CPU, memory, IO, Kafka lag, DB connections, thread-pools.

• SLI: `1 - (failed_payments / total_payments)`
• SLO: 99. 7 % d'autorisations de cartes réussies en 30 jours (error budget 0. 3%).

4) L'architecture de collecte et de traitement

1. Ingest : agents (OTel Collector/Fluent Bit), SDK en annexe, RUM/synthétique.
2. Routage : courtier/bus de télémétrie (OTLP/HTTP/GRPC), filtres et masquage PII.

• Métriques : TSDB (agrégations, downsampling).
• Logs : hot (indexable )/warm (moins indexable )/cold (stockage objet, WORM).
• Traces : stockage indexé avec rétentions et tail-sampling.
• 4. Analytics/alerties : règles (BouQL/LogQL/SQL), corrélation avec la tracamie et les versions.
• 5. Dashboards : types techniques + métiers (paiements, RNG/fournisseurs, moteur de tournoi).

5) Standard des loges (JSON) et taxonomie des événements

Un logage JSON rigoureux, des clés uniques et des niveaux sont recommandés.

Уровни: `DEBUG < INFO < NOTICE < WARN < ERROR < FATAL < AUDIT`

Таксономия: `auth.`, `payment.`, `gameplay.`, `risk.`, `psp.`, `kyc.`, `rg.` (responsible gaming), `ops.`.

json
{
"ts": "2025-11-04T19:45:31. 842Z",
"lvl": "AUDIT",
"event_type": "payment. deposit_approved",
"correlation_id": "c-7d2c1f0b",
"trace_id": "2d6a9c0e4c0b1f72",
"span_id": "9f3a81d2a1c3b764",
"request_id": "r-8f12de9e",
"tenant": "brand_eu",
"psp": "acq_xyz",
"user_id_hash": "u:sha256:1e63…",
"device_id": "d-3c8f…",
"ip_trunc": "203. 0. 113. 0/24",
"amount_minor": 5000,
"currency": "EUR",
"result": "approved",
"latency_ms": 312,
"tags": ["pci_safe", "kyc_passed", "low_risk"],
"extra": {
"bin": "411111",
"method": "card",
"region": "EU",
"ab_test": "checkout_v2"
}
}

• Nous masquons le PAN/BIN (nous ne stockons que les champs autorisés par la politique), email/téléphone - hash/token.
• Tronquer IP jusqu'à/24, stocker GeoIP séparément.
• Nous interdisons le texte libre dans 'extra' pour l'entrée utilisateur sans assainissement.

6) Corrélation : trace_id, correlation_id, idempotency_key

Ajouter « trace _ id » (de OTel), « span _ id', » correlation _ id' (de bout en bout pour le processus métier), « idempotency _ key » (pour les requêtes de paiement) à chaque journal et métrique.
Transférer le baggage (tenant/marque, market, A/B-option) pour construire des tranches.

7) Métriques : Techniques et d'affaires

Technique : RPS, p95 latency, error rate, saturation, GC, pool utilisation, Kafka consumer lag.
Affaires : CR registratsii→depozit, autorisations réussies, annulations de paiement, NGR/GGR, ARPPU, anomalies RTP, drop-off à l'étape KYC, part des limites responsables.

promql sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

8) Tracing et OpenTelemetry

Nous instrumentons le gateway, l'orchestrateur de paiement, le noyau de jeu, les notifications, KYC/AML, les intégrations avec les fournisseurs.
Head-sampling pour le flux total + tail-sampling (boost) pour les bugs/latents spans et les paiements.
Promotion du contexte : « traceparent »/« tracestate », Kafka headers, gRPC metadata.
Nous annotons les événements de domaine : 'BetPlaced', 'WithdrawalRequested'.

9) Alerting sans bruit

Seuils à plusieurs étapes (warning/critical), suppression de flapping, déduplication, temporisation.
La corrélation : nous lions "la croissance 5xx" + "Kafka lag" + "p95 latency PSP" → un incident.
alertes SLO-based : nous dépensons error-budget - nous progressons.
Alerts-as-Code (GitOps), revues et tests de règles.

yaml groups:
- name: payments rules:
- alert: PaymentErrorSpike expr: (sum(rate(payment_errors_total[5m])) / sum(rate(payment_attempts_total[5m]))) > 0. 02 for: 10m labels: { severity: "critical", team: "payments" }
annotations:
summary: "Payment errors> 2% per 10m"
runbook: "runbooks/payments/error-spike. md"

10) Recherche par logs (exemple LogQL)

logql
{app="psp-orchestrator", level=~"ERROR    FATAL"}
= "decline"
json amount_minor > 10000 region="EU"

L'objectif est d'éliminer rapidement le bruit et de mettre en évidence les refus « chers » dans la région cible.

11) Dashboards : ce qui est obligatoire

Payments Health : succès/échecs par PSP, latitude par méthode, carte des régions, SLA des fournisseurs.
Jeu Core : RPS par fournisseurs, p95 spin, error ratio SDK, anomalie RTP par slot.
Player Journey : registratsiya→KUS→depozit→igra→vyvod (entonnoir de conversion, temps entre les étapes).
Infra : Kafka lag, DB connexions, cache hit ratio, cluster Kubernetes (grille de pods/nœuds).

12) Stockage, retences et coût (FinOps)

Cardinalité sous contrôle : éviter les métriques avec des étiquettes hautement modifiables (user_id).
Retences : métriques hot 30-90 dn., downsampling jusqu'à 13 mois. ; logs hot 7-14 dn., warm 30-90 dn., cold 1-3 ans (compte tenu de la réglementation).
WORM/immutabilité pour les logs d'audit, Object Lock.
Compression/partitionnement et politiques ILM ; indices distincts pour l'audit/PII-safe.
Sampling des logs sur INFO/DEBUG ; ERROR/AUDIT - complet.

13) Sécurité et conformité

PII/PCI : Tokénisation, hachage, masquage ; minimisation des données.
RBAC/ABAC : accès aux logs/remorques - par rôle, partage des tentes.
Secrets et clés : ne pas loger credentials/tokens ; détecteurs de secrets sur CI.
Audit-trail : entrées d'administration, modifications des limites/paiements, ajustements manuels du solde - uniquement dans l'indice AUDIT, invariablement.
Legal-hold : mécanisme de gel des rétentions dans les enquêtes.

14) Qualité des données de télémétrie

Schema Registry pour logs/events (versioning, compatibilité).
Une seule valeur de champ (snake_case, unités).
Validation sur l'injection (drop d'événements sales, métriques sur le mariage).
Backpressure et protection contre les « tempêtes de loges ».

15) Processus SRE, Oncall et Runbucky

Matrice Oncall et escalade ; Quiet Hours et rotations.
Les runbooks sont liés aux alertes (étapes de diagnostic, recettes SQL/LogQL, ficheflags pour la dégradation).
Postmortem sans pénalité, action items avec propriétaires et deadlines.
Indicateurs de commande : MTD/MTR, pourcentage d'alertes bruyantes, couverture runbook.

16) RUM et synthétiques

RUM : WebVitals (LCP, CLS, INP), erreurs de front, empreintes de périphériques, régions/fournisseurs.
Synthétique : scénarios « registratsiya→depozit→spin→vyvod » de différentes régions ; emplacements privés pour les voies intérieures (adminka/back office).

17) Pratiques de libération, d'expérimentation et de ficheflags

Nous linkons les tracks avec les versions de sortie (commit/artefact).
A/B tags dans baggage → dashboard « impact de l'expérience sur SLI ».
Canary/Blue-Green : panneaux séparés pour les canaries, taux de croissance error-budget.

18) Détection des anomalies et des signaux anti-frod

Déclencheurs statistiques (seasonality-aware) sur decline-rate/chargeback-risk/sursaut de nouvelles cartes.
Corrélations : « augmentation des dépôts échoués + nouvelle version de l'adaptateur PSP ».
Règles de streaming (Kafka → Flink) pour les réactions en temps réel.

19) Feuille de route pour la mise en œuvre (par étape)

Étape 0 - Base : JSON-logs, champs coralliens uniques, métriques de base des services, dashboards communs, premières alertes.
Etape 1 - Traçabilité : Formation OTel, sampling head + tail, association aux logs.
Phase 2 - SLI/SLO : paiements/conclusions/métriques de jeu, alertes SLO, processus error-budget.
Étape 3 - Maturité : Alerts-as-Code, ILM, retences séparées, anomalie-detect, service per-runbuki, pratiques SRE en CI/CD.

20) Chèque-feuille pour la rhubarbe

• Logs uniquement JSON, clés uniques, masquage PII.
• Dans chaque événement : 'trace _ id', 'span _ id', 'correlation _ id', 'tenant'.
• Les métriques couvrent les signaux dorés et les flux d'affaires.
• SLO sont décrits, il y a error-budget et alertes sur burn rate.
• Tail-sampling inclus pour les erreurs de paiement et les latences élevées.
• ILM/retences et WORM sont configurés pour les logs d'audit.
• RBAC pour la télémétrie, la vérification d'accès.
• Dashboards par Payments/Game Core/Player Journey/Infra.
• Les runbooks sont attachés à chaque alerte critique.
• Post mortem et action items - en backlog avec les propriétaires.

Annexe A : Attributs OpenTelemetry (recommandation)

`service. name`, `service. version`, `deployment. environment`

`cloud. region`, `k8s. pod. name`, `k8s. container. name`

`tenant`, `brand`, `market`, `ab_test`, `user_segment`

`payment. method`, `psp`, `game. provider`, `game. id`

Annexe B : exemples de métriques pour SLO

`payment_success_ratio`, `withdrawal_ttw_p95` (time-to-wallet), `psp_latency_p99`

`game_spin_latency_p95`, `provider_error_rate`, `kafka_consumer_lag`

`auth_success_ratio`, `kyc_step_dropout`, `cache_hit_ratio`

Annexe C : Recettes rapides pour les enquêtes

Payment _ error _ rate 'grandit → comparer par PSP/région/méthode, vérifier les tail-tracks, voir la version de la carte.
« p99 spins ↑ » → de traçage front→geytvey→provayder, vérifier le fournisseur/les canaux, les limites des pools thread, les retraits réseau.
« Kafka lag ↑ » → consumers de santé, retraits des producteurs, backpressure, minks lents/DB.