API d'analyse et de mesure des performances

1) Pourquoi est-ce nécessaire

• prouver l'exécution du SLO et du SLA,
• gérer la bande passante et l'économie des demandes,
• localiser rapidement les dégradations (p99-queues, surtensions 5xx),
• hiérarchiser les optimisations par impact sur l'entreprise.

Objectif : un modèle d'observation unique où chaque demande est suivie du périmètre à l'OBD avec des identifiants communs et des IDS cohérents.

2) Taxonomie des métriques

Technique : RPS, latence (p50/p95/p99), taux d'erreur (4xx/5xx), saturation (CPU, mémoire, file-desc), queue time.
Produits : opérations réussies/min, conversion d'étape (200/total), part de rate-limited (429), retraits, segments personnalisés.
Coût : cost/request (CPU-ms + egress + OBD request), coût fichi/endpoint, $/tenant, $/1k appels.

3) « Signaux d'or » : RED et USE

• Rate - requêtes/s (par endpoint/tenant/plan).
• Errors - 4xx/5xx/429 parts et absolus.
• Durée - p50/p95/p99 end-to-end et par étapes (ingress → app → DB → tiers).

• Utilisation - Chargement CPU/IO/canal.
• Saturation - files d'attente (run-queue, backlog, DB wait).
• Errors - Erreurs de pilote/temporisation.

4) Définitions et formules de base

Availability SLI: `1 − (5xx + gateway_timeout) / all_requests`.
Success SLI : '2xx/( all − 429_shadow)' (à l'exclusion des verrous « shadow »).
Apdex: `(|T≤T| + 0. 5·|T≤4T| )/all ', où « T » est le seuil « bon » cible.
Tail amplification : 'p99 _ total − max (p99_stage_i)' est la contribution des files d'attente/composition.
Error budget (mois) à 99. 9 %: 'budget = 0. 1 % temps _ période '.

Bines percentiles recommandées pour les histogrammes latins : '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s]`.

5) SLI/SLO et alerting par burn-rate

• Disponibilité : ≥ 99. 9 %/30 jours.
• p95 de latence 'GET/wallet/balance' <150 ms ; 'POST/payments' <400 ms.
• Erreurs '5xx' <0. 2 %. '429' (solide) <1 % du trafic total.

• 2 % de budget en 1 heure ou 5 % en 6 heures → page à l'ingénieur.
• 10 % par jour → priorité RCA.

6) Ensemble de métriques (ce qui est obligatoire)

• `http_requests_total{route,method,status,tenant,plan}`
• 'http _ request _ duration _ seconds _ bucket {route,...}' (histogramme)
• `retries_total{reason}`, `rate_limited_total{key,policy}`
• Dimensions du corps : 'request _ bytes', 'response _ bytes'

• `db_client_requests_total{op,table}`, `db_latency_seconds_bucket{op}`
• 'cache _ ops _ total {op}', hit-rate cache appels externes : 'outbound _ calls _ total {provider, op}', latency/error/timauts queue/pools : longueurs/retards, workers actifs ressources USE : CPU, RSS, FD, GC-pauses

Labels d'entreprise : 'tenant _ id', 'region', 'kyc _ level', 'plan', 'feature _ flag'.

7) Trace et corrélation (OpenTelemetry)

W3C Trace-Context (« traceparent », « tracestate ») sur tous les hops.
Span par étapes : ingress → authZ → app handler → DB/Redis → PSP/externe.
Attributes/labels : 'http. route`, `enduser. id`, `tenant. id`, `idempotency. key`, `risk. score`.
Exemples : associez les points des graphiques latency/error à des points spécifiques trace-id.

• head-based 1-10 % pour les voies « classiques »,
• tail-based pour les résidus (nous prenons lent/erroné),
• adaptive pour les pics et les incidents.
• Baggage : transfère 'tenant '/' risk' pour les coupes sans marquer chaque événement.

8) Logs : Structure et vie privée

JSON structuré ; champs obligatoires : 't',' trace _ id ',' span _ id ',' route ',' status ',' latency _ ms', 'tenant', 'user _ id _ hash'.
Politique PII : masquer le PAN/PII ; interdire les secrets/tokens.
Sampling logs : haut pour 4xx/5xx/429 et requêtes « longues ».

9) Carte de dashboard (recrutement minimum)

1. Exec-Résumé : RPS, Disponibilité, Taux d'erreur, p95/p99 latitude, 429 parts, Budget de burn-rate.
2. Per-Route : top endoints sur RPS/erreurs/queues ; comparaison des versions (canaries).
3. Per-Tenant/Plan : leaders en charge/coût/erreurs.
4. Dependency Health : DB, cache, PSP/externe - latency, erreurs, saturation.
5. Capacity : CPU/RAM/FD, files d'attente, pool de connexion, GC, limites de conteneurs.
6. Sécurité/Abuse : 401/403, 429/politiques, tranches géo/ASN, éclats de rétrograves.

10) Alerts (seuil et tendance)

'error _ rate {route} '> 2 % (5 minutes) et RPS> N → pager.
'P99 _ latency {critical}> seuil cible (10 minutes).
« burn _ rate » par budget (voir § 5).
DB 'timeouts '/' deadlocks' ou la taille 'queue _ time'> Xms.
Fournisseurs externes : 'outbound _ 5xx _ rate {provider}'> 1 % + SLO dépendants.

11) Planification et performance capacitives

Loi de Little : « L = λ· W » (longueur moyenne de la file d'attente = trafic × temps moyen).
La cible p95 est mise en place : 'ingress + app + DB + external + queue'.
Budget de concurrence : nous enregistrons un maximum d'opérations write simultanées.
Métrique du budget : « ms CPU à demander » ; nous avons une marge de 30 à 50 % au sommet.
Interaction avec rate-limit : mesurez la proportion de demandes au « plafond » du quota et l'impact sur la latence.

12) Contrôles de charge et de synthèse

Espèces : charge de base, bourgeons × 10, « étages », plateaux à long terme, stress/chaos (tuer des nodules, retards du réseau), synthétique selon des scénarios critiques pour les clients.
Profilage : CPU/alloc/lock-content, N + 1 (SQL/HTTP), codes lents.
Contrôle des régressions : comparaison p95/p99/erreurs avant/après libération (canaries).

13) Coût (Cost-Observability)

Métriques de coût : 'cpu _ ms',' egress _ bytes ',' db _ calls ',' $ per 1k requests '.
Allocation sur endpoint/tenant/fich : balises de facturation de l'orchestrateur + métriques de charge → rapport sur l'économie unitaire de l'API.
Algorithme d'optimisation : nous sélectionnons les endpoints TOP par le produit « traffic × cost × (p95 − cible) ».

14) Per-tenant de l'analyse et de la « justice »

Toutes les mesures clés sont avec le label 'tenant _ id/plan'.
Proportion de clients « lourds » dans les résidus p99 ; des limites/quotas distincts et des budgets rétrogrades.
Fairing équitable : en cas de surcharge, nous réduisons la proportion de locataires « importants ».

15) Spécificités iGaming/Finance

Coupes par 'kyc _ level', 'risk _ tier', 'payment _ method'.
SLI pour les chemins « monétaires » (« POST/dépôts », « POST/withdrawals ») : ci-dessous les cibles p95, budgets d'erreurs séparés.
Métriques Time-to-Wallet (TTW), proportion de blocage automatique par antifrood, conversion de paiement.
Audit : logs immuables pour les actions financières et les solutions antifrod.

16) Instrumentation : pratiques de mise en œuvre

• `api_http_requests_total` (counter)
• `api_http_request_duration_seconds` (histogram)
• `api_outbound_requests_total`, `api_db_query_duration_seconds`
• `api_rate_limited_total`, `api_retry_total{reason}`

Лейблы: `route`, `method`, `status_class`, `tenant`, `region`, `version`, `canary`, `provider`, `db_table`.
Cardinalité : éviter les valeurs libres (user_id), utiliser des « baquets »/hash.
Exemples : connectez-vous aux histogrammes p95/p99 → un clic sur trace.

17) Anti-modèles

Moyenne au lieu des percentiles ; pas de division en classes statu quo.
« route »/« path » (ID dynamique « cousus » dans les labels).
Labels à haute cardinalité (raw user_id, IP).
Absence de comptabilité séparée des fournisseurs externes (PSP/3rd-party).
Alert par « bruit » (une seule fois et un seul seuil).
p99 sans tenir compte du temps de queue (masque de la dégradation réelle).

18) Liste de contrôle prod-ready

• Défini par SLI/SLO et error-budget, harmonisé avec l'entreprise.
• Histogrammes uniques de latitude et de status-classes ; p95/p99 sur les dashboards.
• Trace complète (OTel), corrélation logs/métriques/tracés.
• Alert burn-rate, seuils p99 et error-rate.
• Per-tenant/per-plan coupes et rapports sur le coût.
• Dashboards : Exec, Per-Route, Dependencies, Capacity, Abuse.
• Scénarios de charge (burst/plateau/stress), profilage.
• Politiques rétrogrades avec jitter ; prise en compte de l'influence des retraits sur le RPS.
• Documentation SLA/SLO pour les partenaires et les clients publics.
• Rétention/masquage des logs, protection PII.

19) TL; DR

Construisez l'observabilité autour de SLI/SLO et error-budget, mesurez RED/USE, collectez des histogrammes de latitude avec p95/p99 et « queue time », distribuez un seul trace-id du périmètre à l'OBD, utilisez tail/adaptive-sampling, tenez le per-tenant/valeur coupes et burn-rate-alerting à deux fenêtres. Planifier la capacité selon les lois des files d'attente et l'impact sur les métriques d'entreprise ; les anti-pectures sont des moyennes au lieu des percentiles, une cardinalité élevée et des dépendances extérieures non comptabilisées.