Distribution des signaux et métriques

(Section : Écosystème et réseau)

1) Objectif et zone

• Langage unique de télémétrie et contrats de données.
• Canaux QoS contrôlés : priorité des signaux critiques.
• Un SLI/SLO transparent et une alerte prévisible.
• Confidentialité, isolation et économie de budget métriques.

2) Taxonomie des signaux

1. Événements d'affaires : onbording, dépôts/paiements, événements de jeu, attribution.
2. T-métriques : latency/throughput/code d'erreur, file d'attente, utilisation de CPU/RAM/IO.
3. Logs : enregistrements structurés des opérations et des erreurs.
4. Traces : spans de requêtes/tops, corrélation hop-to-hop.
5. Statuts de santé : Synthetic probes, read..../liveness, heartbeat nœuds.
6. Signaux de risque/complication : KYC/KYB/AML succès, événements de sanctions.

Chaque classe a son propre niveau de criticité et sa politique de stockage/livraison.

3) Architecture de distribution (référence)

Collecteurs Edge (SDK/agents) → Ingress (HTTP/OTLP/gRPC/QUIC) → Bus (Kafka/Pulsar) → Processeurs (stream-jobs) → Stockage (TSDB pour métriques, objet/colonique - pour logs/événements, traceur) → Vitrines/dashboards/alerts.
Multi-tenance : namespace/tenant-id dans les clés, quote/limits/ACL séparés.
Segmentation par QoS : critique (P0), important (P1), arrière-plan (P2).
Egress : abonnés (Ops/BI/Third-party) via les abonnements aux tops et views materialized.

4) Contrats et schémas (événements/métriques/tracés)

4. 1 Événements (simplifiés, YAML)

yaml event:
id: uuid kind: business    ops    risk ts: timestamp    # ISO8601 tenant: string    # org_id/namespace source: string    # service/peer-id trace_id: string type: string     # deposit. created    payout. failed    probe. ok...
attrs: object # semantic fields (no PII)
severity: info    warn    error    critical qos: P0    P1    P2

4. 2 Métriques (OpenMetrics/OTLP)

Gauge/Counter/Histogramme avec labels stables (cardinalité limitée).
Identifiants : 'metric _ name {service, region, tenant, version, route}'.
Histogrammes pour latence/dimensions au lieu de p99 dans le code.

4. 3 Tracs

Champs obligatoires : 'trace _ id', 'span _ id', 'parent _ id', 'service', 'peer', 'route', 'qos'.
Links entre les domaines (consumer/producteur) et les réseaux hop (relay/bridge).

5) QoS et priorité

P0 (Critiquement) : les paiements/paiements SLI, les statuts des ponts/noeuds, burn-rate SLO → la livraison sévère (acks, retries, идемпотентность), minimal таймауты.
P1 (important) : événements de produits/métriques de base → livraison garantie au sein de SLO.
P2 (arrière-plan) : les logs de détail, le débogage → le meilleur effet, peuvent être flashés en cas de surcharge.

Politiques : différentes files d'attente, quota sur les producteurs, backpressure, rate-limits, dedup par 'idempotency _ key'.

6) Cardinalité et budget métriques

Règle 6 labels : pas plus de 6 clés par métrique, dictionnaires de valeurs fixes.
Cardinalité ≤ 10k séries chronologiques/métrique/tenant.
Échantillonnage : head-/tail-based pour les traces ; downsampling métriques 10s→1m→5m→1h.
Quotas : limites de points/s et octets/s par tentant et par classe QoS.
Linter des schémas : rejette les métriques avec des labels « explosant » (id, email, ip, etc.).

7) Collecte et livraison : push vs pull

Push (OTLP/StatsD/HTTP) : flexibilité, clients mobiles/edge, canaux P0.
Pull (Prometheus) : infrastructure interne, targets prévisibles.
Hybride : exporters→gateway→TSDB ; scrapes fédérés pour les régions.
Transport : QUIC/HTTP/2, compression, trampoline, TLS/mTLS, retraits avec gitter.

8) SLI/SLO et alerting

8. 1 SLI de base

Disponibilité % des endpoints/passerelles,

Latitude p50/p95/p99 sur des itinéraires critiques,

Error-rate (5xx/timeout/abort),

Delivery lag par pneu, Queue depth,

Freshness vitrine (retard ingest→serve).

8. 2 exemples de SLO

P0 pipelines: Availability ≥ 99. 95%, p99 latency ≤ 400 мс, Delivery lag p95 ≤ 2 с.
P1: Availability ≥ 99. 9 %, Freshness p95 ≤ 3 min.
P2: Freshness p95 ≤ 15 мин, no-page.

8. 3 Burn-rate alert (exemple)

Fenêtre de 2 heures : 'error _ budget _ burn ≥ 2 ×' → page.
Fenêtre de 6 heures : 'error _ budget _ burn ≥ 1 ×' → page/escalade.
Combiner avec 'queue _ lag' et 'drop _ rate' P0.

9) Dépôts et rétentions

Métriques TSDB : haute fréquence - 7-14 jours ; les agrégats sont de 6 à 12 mois.
Événements/logs : stockage chaud 7-30 jours, froid (objet) 6-24 mois.
Tracés : sampling 1-10 %; la conservation des spans « lents/erronés » (tail-based).
Politiques de suppression/révision pour les IPI et les demandes des personnes concernées.

10) Vie privée, sécurité et isolation

Minimisation des PII : Tokenization/pseudonymisation des champs, interdiction des identifiants « bruts » dans les métriques.
mTLS/signature d'événement, pincement des clés des producteurs.
ACL/ABAC sur les sujets/services/tenants, clés séparées pour write/read.
Tenant sandboxing : séparation logique/physique, limites et rate-limit per tenant.
Piste d'audit : journaux d'accès/changements de configues immuables.

11) Flux de traitement (stream jobs)

Enrich : normalisation, géo/version/classe de trafic.
Aggregate : fenêtres 10s/1m/5m, histogrammes, croquis quantiles.
Detect : anomalies (EWMA/ESD), dérive des distributions, surtension des files d'attente.
Route : fan-out dans les vitrines/alerters/webhooks partenaires.
Garde : « bouton rouge » - throttling/kill-switch par source/sujet.

12) Dashboards (maquettes de référence)

Ops Core (heure/temps réel) : p95 latency, error-rate, delivery lag, queue depth, success-rate ingest.
Pipelines Health: freshness per pipeline, drop-rate, backpressure, burn-rate SLO.
Utilisation de Tenant : rangées/sec, octets/sec, cardinalité, top-labels.
Sécurité/Conformité : États mTLS, clés d'expiration, accès, révision PII.
Business Lens : conversions/paiements/passerelles SLI à côté de ces métriques.

13) Exemples de configurations

Classes et limites de QoS (YAML)

yaml telemetry:
qos:
P0:
topics: [payout. sli, bridge. finality, gateway. availability]
delivery: guaranteed retry:
attempts: 3 backoff_ms: [100, 400, 800]
max_queue_lag_ms: 2000
P1:
topics: [product. events, api. metrics]
delivery: at-least-once sampling: 1. 0
P2:
topics: [debug. logs, verbose. traces]
delivery: best-effort sampling: 0. 1 quotas:
tenant_default:
metrics_points_per_sec: 50_000 logs_mb_per_hour: 500 traces_spans_sampled_pct: 5

Labels métriques (politique)

yaml metrics_policy:
allowed_labels: [service, route, code, region, tenant, version]
forbidden_labels: [user_id, email, ip, session_id]
max_label_value_count: 1000

Alert burn-rate

yaml alerts:
- name: "p0_error_burn_2h"
expr: burn_rate_p0_2h > 2 action: [page_oncall, open_incident]
- name: "queue_lag_p0"
expr: queue_lag_ms_p95 > 2000 action: [page_oncall]

14) Schémas de données et demandes

Registre des métriques (catalogue)

sql
CREATE TABLE metric_catalog(
name TEXT PRIMARY KEY,
unit TEXT, description TEXT,
labels JSONB, owner TEXT, qos TEXT, sla JSONB
);

Files d'attente et lag

sql
SELECT topic,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY lag_ms) AS lag_p95,
SUM(dropped) AS drops
FROM queue_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY topic;

Cardinalité par tentant

sql
SELECT tenant, metric_name, COUNT(DISTINCT series_id) AS series
FROM tsdb_series
WHERE day = current_date
GROUP BY tenant, metric_name
ORDER BY series DESC
LIMIT 50;

15) Processus et rôles

Telemetry Owner - schémas/politiques/quotas, contrôle de la cardinalité.
SRE/Ops - SLO, alertes, incidents, mise à l'échelle.
Sécurité/Conformité - clés, accès, PII, audits.
Product/BI - vitrines KPI, analytique, métriques A/B.
Tenants (partenaires) - intégration correcte du SDK, respect des contrats.

16) Playbook des incidents

A. L'explosion de la cardinalité

1. Bloc auto du producteur/métrique, 2) coupons les labels « mauvais », 3) rétro-agrégation, 4) post-mortem et règles de linter.

B. Croissance de la queue lag P0

1. Inclure la priorité, 2) étendre les lots/consumers, 3) réduire temporairement P2 sampling, 4) analyser les goulets d'étranglement.

C. Chute Freshness vitrine

1. Basculer vers le connecteur de secours, 2) activer le mode de dégradation (« finalisé le plus récent »), 3) informer les propriétaires des sources.

D. Fuite de PII dans les métriques

1. Blocage immédiat du flux, 2) redaction sur la couche chaude, 3) notification DPO/Compliance, 4) mise à jour des lenteurs/SDK.

E. Masse 5xx/erreurs de trace

1. Page, 2) sampling tail-based ↑ pour les erreurs, 3) diagnostic de la voie critique, 4) retour de sortie/fich-flag.

17) Chèque de mise en œuvre

1. Approuver les contrats d'événements/métriques/trajets et la liste des labels valides.
2. Créer des classes QoS, des tops/files d'attente, des quotes et des métriques de budget.
3. Configurer ingest (push/pull), TLS/mTLS, retraits et idempotence.
4. Activer les répertoires métriques/événements et les liens de schéma.
5. Définissez les alertes SLI/SLO, burn-rate et escalade.
6. Construire des dashboards Ops/Pipelines/Tenant/Security.
7. Exécutez les tests chaos de télémétrie (perte/jitter/spike).
8. Revivez régulièrement la cardinalité, la retraite et le coût du stockage.

18) Glossaire

QoS est une classe de qualité/priorité de livraison.
Freshness - retarder l'apparition des données dans la vitrine.
Burn-rate est le taux de consommation du budget d'erreur par rapport au SLO.
Cardinality est le nombre de séries uniques de métriques (combinaisons de label).
Tail-based sampling est un échantillon de traces « lentes/erronées ».
Idempotency key est la clé de déduplication des répétitions d'événements.

Résultat : la distribution des signaux et des métriques n'est pas seulement « assembler et afficher des graphiques », mais la discipline des contrats, des canaux QoS et des budgets. En suivant ce cadre, l'écosystème obtient une observabilité prévisible, résistante aux surtensions, privée des données et utile pour les solutions à la fois dans le circuit opérationnel et commercial.