Surveillance en temps réel

(Section : Opérations et gestion)

1) Pourquoi la surveillance du temps réel

• visibilité instantanée de la disponibilité et des retards (p50/p95/p99) des itinéraires critiques ;
• le contrôle de l'intégrité des événements (webhooks, paiements, RTP/limites) ;
• sécurité financière (egress/coût 1k événements, compensation/séquestre) ;
• respect de la conformité (reçus, hygiène PII).

2) Contour architectural

1. Producteurs : services, SDK, nœuds edge, fournisseurs de paiement/contenu.

2. Ingest-passerelles : récepteurs 'metrics/traces/logs/events' avec backpressure et quotas.

3. Pneu/streaming : courtier avec lot (tenant/région/route), rétention pour replay.

4. Traitement par flux : agrégations de fenêtres (T + 5s/T + 1m), déduplication, normalisation du temps, calcul SLI.

5. Stockages : time-series (en ligne), OLAP (historique), journaux WORM (audit).

6. Analyse et alerting : règles SLO, détecteurs statistiques, anormaliste.

7. Dashboards et runes : UI pour l'action (pause/re-route/rollback/raise-limit).

• Contrats de données sur les métriques/événements (schémas, versions, validation).
• Outbox/CDC pour une publication garantie des événements de domaine.
• Idempotency et dedup par 'trace _ id/event _ id'.
• Clock sync : NTP/PTP, correction 'skew', chutes d'heure (event vs processing time).

3) Types de télémétrie et de sémantique

Metrics (SLI) : compteurs/games/histogrammes de p-percentiles.
Traces : "trace _ id/span _ id', lien de RPC↔sobytiya↔vebkhuki.
Logs : structuré, avec 'tenant _ id/region/version'.
Business events: `PaymentAuthorized`, `WebhookDelivered`, `RTPWindowClosed`.
Receipts : reçus/signatures (pour les opérations financières/critiques).

4) Temps et fenêtres

Types de temps : event-time, ingest-time, processing-time.
Fenêtres : coulissantes (5-30 c), à bascule (1-5 min), avec rétention d'eau (watermark) pour les événements tardifs.
Compacité : agrégez dans le flux (croquis d'histogrammes) → ne stockez que les bines percentiles nécessaires.

5) Normalisation et qualité des données

Validation à l'entrée : schéma/plages/champs obligatoires ; Les rejetés sont en quarantaine avec une étiquette de cause.
Déduplication : par '(event_id, producteur, seq)' ; stocker « seen-cache » dans la mémoire + KV.
Correction des métriques : contre « double count » et « flatline » (capteurs silencieux).
Samplage : Pour high-QPS - adaptatif, avec une marge d'erreur ; Les SLI critiques sont pleins.

6) SLI/SLO (référence)

North Star : Taux de réussite E2E avec p95 cibles par région.

• Disponibilité par canal/région.
• Latence p50/p95/p99 sur les itinéraires clés.
• Error-rate/Retry-rate.
• Succès de la livraison de webhooks (% confirmé par les reçus).
• Consistance des prix/taxes (« quote = = checkout », ± 1 unité mineure).
• Cost-SLI : coût de 1k événements, egress/ingress par unité.

• Disponibilité ≥ 99. 95 % dans la fenêtre de 28 jours.
• p95 : vitrine ≤ 120 ms, quote/checkout ≤ 250 ms.
• Les webhooks réussissent ≥ 99. 5 %/5-min fenêtre.
• Δ quote↔checkout = 0 (±1 minor unit).
• Réaction à P1 ≤ 10 min, MTTR ≤ 60 min.

7) Alerting et runes (auto-actions)

Niveaux : P1 (rupture de SLO/inactivité), P2 (dégradation), P3 (tendance/risques).
Réduction du bruit : déduplication par 'trace _ id', corrélation des chaînes causales.

• « PriceMismatch » → refresh du catalogue, rapprochement 'fx _ version/tax _ rule _ version', politique de compensation ;
• WebhookLag → redéfinir les workers, augmenter les batch, hiérarchiser les files d'attente ;
• « RTP Drift » → pause promo, vérification de la table de paiement/version, retour en arrière du profil ;
• « Egress Surge » → activer la compression/cache-pinning/autre route.
• Escalade : matrice 24 × 7, rotation sur appel, canaux (chat/appel/SMS).

8) Dashboards (widgets opérationnels)

La santé de la plateforme : accessibilité, p95/p99, error-rate, burn-down error-budget.
Intégrations/Webhooks : succès, lag, prise/idempotence, reçus.
Checkout/prix : écarts de vitrina↔checkout, versions FX/Tax, cas d'échec.
RTP/limites : théor. vs observed RTP, déclenchement des limites, exposition.
FinOps : cost per 1k, egress/ingress, budgets/cap alerts.
Sécurité/Conformité : SoD, JIT, MFA, demandes PII, signatures Crète. opérations.
Release/Flags : statuts fich, régions canaries, lien avec les incidents.

9) Multi-région et multi-tenant

Lot par 'tenant/region'.
SLO/quotas indépendants par région ; les limites des alertes croisées (afin que la défaillance locale ne « colore » pas le monde entier).
Zones de confiance des données : PII/Finances - uniquement lorsque cela est autorisé ; dans le dashboard général sont les agrégats/hash.

10) Sécurité, intimité, prouvabilité

Authentification ingest : clés/mutual-TLS, taux-limites, signatures de paquets.
Minimisation PII : jetons au lieu de la première, masques/hash ID.
Reçus (receipts) : DSSE/signatures pour les événements financiers/critiques.
Journaux WORM : logs immuables pour l'audit, sections Merkle.
Contrôle d'accès : RBAC/ABAC/ReBAC, JIT pour les panneaux sensibles.

11) Anomalie et corrélations

Guardrails : seuils statiques par SLI.
Statistiques : Shewhart/CUSUM/EWMA pour les tendances.
ML/signaux : saisonnalité/canaux/ASN/fournisseurs ; impact des releases/ficheflags.
Corrélations : relier les incidents avec des sorties, des changements de configues, des surtensions de trafic, des promotions.

12) Productivité et coût

Budget de télémétrie : cap sur QPS/volume ; rejet des métriques « bavardées ».
Compression/agrégation : downsampling story (1s→10s→1min), stockez les croquis percentyles.
Contrôle egress : caches/agrégats locaux, avant-travail.
Cost-aware alerts : signal si le coût/1k des événements ou egress va à l'encontre du plan.

13) Intégrations et contrats API

'POST/ingest/metric' (JSON/OTLP) : authentification, quotas, schéma/version.
« POST/ingest/events » (signé) : dedup/TTL/nonce.
`GET /kpis? filters = région, tenant, route '- agrégats pour UI.
'GET/traces/{ trace _ id} 'est une rotation de chaîne.
Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookLag`, `RTPDrift`.

14) Pleybooks d'incidents (short-form)

P1 Dostupnost↓ : changer le routage, allumer les circuits-breakers, réduire les délais des clients, poste d'urgence sur le statut.
P1 Quote≠Checkout : freeze promo/dynamique des prix, cache force handicapé, comparaison des versions FX/Tax, compensation.
P1 WebhookLag : augmenter les workers/compétitivité, taille batch, désactiver les webhooks non essentiels.
P2 RTP Drift : pause bonus, vérification des tables de paiement/versions, extension de la fenêtre d'observation, rapport.
P2 Egress Surge : compression, cache edge, délocalisation d'une partie du trafic, quotas de temps.

15) Les métriques de qualité de la surveillance elle-même

Disponibilité UI/API ≥ 99. 9%.
Freshness : mise à jour lag ≤ 30 s pour les panneaux opérationnels.
Completeness: ≥ 99. 5 % des sources ont envoyé des données par la fenêtre.
Correctness : divergence avec la référence ≤ 0. 1%.
MTTA/MTR alert-pipline : P1 ≤ 1/10 min.

16) Chèque de mise en œuvre

• Identifier le North Star et l'ensemble SLI/SLO par région/canal.
• Entrez les contrats de données et les schémas pour tous les flux de télémétrie.
• Configurer ingest avec quotas, backpressure et déduplication.
• Déployer le bus/streaming et les agrégations de fenêtres avec watermarks.
• Construire time-series/OLAP/WORM et un lien avec les reçus.
• Créer des alertes + auto-runes, une matrice d'escalade 24 × 7.
• Former des dashboards par rôles : SRE/Product/FinOps/Compliance/Partners.
• Inclure les PII-minimisation, signatures et RBAC/ABAC/ReBAC.
• Entrez les métriques FinOps (cost/1k, egress, stockage) et les caps.
• Tenir GameDay : lag webhooks, prix dissynchrone, rétro-burst, refus de la région.

17) Attacher à iGaming/Fintech

RTP & Limites : contrôle du RTP observé et des limites en minutes/heures, alertes sur « over/under pay ».
Paiements/décaissements : suivi de bout en bout des autorisations, de la compensation et des reçus ; SLA PSP.
Affiliation : Livraison de conversions (webhooks) et controverses → séquestre/rapprochement.
Promo : sursaut de trafic → protection des files d'attente et prix egress ; guardrails sur les budgets.

18) FAQ

Le temps réel est-il obligatoire partout ?
Non. Les contours « chauds » sont des secondes/minutes (incidents, paiements, webhooks). Économie/analyse - minutes/heures.

Comment lutter contre les fausses alarmes ?
Conditions orientées SLO, agrégation et déduplication par 'trace _ id', corrélation avec les sorties, hystérésis des seuils.

Dois-je garder toutes les loges pour toujours ?
Non. WORM - uniquement pour les flux d'audit/critiques ; le reste est downsampling/TTL.

Pourquoi « quote≠checkout » se trouve-t-il ?
Versions FX/Tax, cache handicapé, arrondis. Il est traité avec des versions, une stratégie SWR et des tests de cohérence.

Résumé : La surveillance en temps réel est une discipline : contrats de données stricts, calcul de fenêtre, temps normalisé, combinaison de reçus et d'alertes SLO, plus un bouton d'action dans chaque widget. En faisant cela correctement, vous réduisez MTTR, gardez le budget sous contrôle et évoluez en toute confiance l'écosystème à travers les régions et les tenants.