API de análisis y métricas de rendimiento

1) Por qué es necesario

• probar la ejecución de SLO y SLA,
• gestionar el ancho de banda y la economía de las solicitudes,
• localizar rápidamente las degradaciones (colas p99, ráfagas 5xx),
• priorizar las optimizaciones por impacto en el negocio.

Objetivo: un único modelo de observabilidad donde cada solicitud es monitoreada desde el perímetro hasta la DAB con identificadores comunes y SLIs acordados.

2) Taxonomía métrica

Técnico: RPS, latencia (p50/p95/p99), error rate (4xx/5xx), saturación (CPU, memory, file-desc), queue time.
Productos: operaciones exitosas/min, conversión de paso (200/total), cuota de rate-limited (429), retraídas, segmentos personalizados.
Costo: costo/solicitud (CPU-ms + egress + solicitudes de DB), costo del fichi/endpoint, $/tenant, $/1k llamadas.

3) «Señales de oro»: RED y USE

• Tasa: consultas/segundos (por endpoint/tenant/plan).
• Errors - 4xx/5xx/429 lóbulos y absolutos.
• Duration - p50/p95/p99 end-to-end y por etapas (ingress → app → DB → terceros).

• Utilidad - Descarga de CPU/IO/canal.
• Saturation - colas (run-queue, backlog, DB wait).
• Errors - errores de controlador/temporizador.

4) Definiciones y fórmulas básicas

Availability SLI: `1 − (5xx + gateway_timeout) / all_requests`.
Éxito SLI: '2xx/( all − 429_shadow)' (excluyendo los bloqueos de sombra).
Apdex: `(|T≤T| + 0. 5·|T≤4T| )/all ', donde' T' es el umbral «bueno» objetivo.
Amplificación de cola: 'p99 _ total − max (p99_stage_i)' es una contribución de cola/composición.
Error budget (mes) a 99. 9%: 'presupuesto = 0. 1% de tiempo _ período '.

Listones de percentil recomendados de histogramas latency: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s]`.

5) SLI/SLO y alerting burn-rate

• Disponibilidad: ≥ 99. 9 %/30 días.
• p95 de latencia 'GET/wallet/balance' <150 ms; 'POST/payments' <400 ms.
• Errores '5xx' <0. 2%. '429' (sólido) <1% del tráfico total.

• 2% del presupuesto en 1 hora o 5% en 6 horas → page a un ingeniero.
• 10% por día → priorización de RCA.

6) Conjunto de métricas (que es obligatorio recoger)

• `http_requests_total{route,method,status,tenant,plan}`
• 'http _ request _ duration _ seconds _ bucket {route,...}' (histograma)
• `retries_total{reason}`, `rate_limited_total{key,policy}`
• Dimensiones del cuerpo: 'request _ bytes', 'response _ bytes'

• `db_client_requests_total{op,table}`, `db_latency_seconds_bucket{op}`
• 'cache _ ops _ total {op}', llamadas externas a la memoria caché de alta velocidad: 'outbound _ calls _ total {provider, op}', latency/bugs/timeouts de cola/pools: longitudes/latencias, ejecutores activos recursos USE: CPU, RSS S, FD, pausas GC

Etiquetas comerciales: 'tenant _ id', 'region', 'kyc _ level', 'plan', 'feature _ flag'.

7) Rastreo y correlación (OpenTelemetry)

W3C Trace-Context ('traceparent', 'tracestate') en todas las hopas.
Span por etapas: ingress → authZ → app handler → DB/Redis → PSP/externo.
Attributes/etiquetas: 'http. route`, `enduser. id`, `tenant. id`, `idempotency. key`, `risk. score`.
Exemplars: vincula los puntos de los gráficos latency/error a un id-trace específico.

• head-based 1-10% para las rutas «convencionales»,
• tail-based para las colas (tomar lento/erróneo),
• adaptativo para picos e incidentes.
• Baggage: transferir 'tenant '/' risk' para cortes sin marcar cada evento.

8) Registros: estructura y privacidad

JSON estructurado; campos obligatorios: 'ts',' trace _ id ',' span _ id ',' route ',' status ',' latency _ ms', 'tenant', 'user _ id _ hash'.
Política PII: enmascarar PAN/PII; prohibir los secretos/tokens.
Sampling Logs: alto para consultas 4xx/5xx/429 y «largas».

9) Mapa de dashboards (conjunto mínimo)

1. Exec-Summary: RPS, Availability, Error-rate, p95/p99 latency, 429 share, burn-rate del presupuesto.
2. Per-Route: endoints superiores por RPS/errores/colas; comparación de versiones (canario).
3. Per-Tenant/Plan: líderes en carga/costo/errores.
4. Dependency Health: DB, cache, PSP/externo - latencia, errores, saturación.
5. Capacidad: CPU/RAM/FD, colas, pool de conexión, GC, límites de contenedores.
6. Seguridad/Abuse: 401/403, 429/políticas, cortes geo/ASN, ráfagas de retraídas.

10) Alertas (umbral y tendencia)

'error _ rate {route}'> 2% (5 minutos) y RPS> N → pager.
'p99 _ latency {critical}'> del umbral de destino (10 minutos).
'burn _ rate' por presupuesto (véase § 5).
DB 'timeouts'/' deadlocks' o 'queue _ time' de crecimiento> X ms.
Proveedores externos: 'outbound _ 5xx _ rate {provider}'> 1% + dependientes de SLO.

11) Planificación capacitiva y rendimiento

Ley de Little: 'L = λ· W' (longitud media de la cola = tráfico × tiempo medio).
El objetivo p95 desplegamos: 'ingress + app + DB + external + queue'.
Budget de concurrencia: fijamos el máximo de operaciones de escritura simultáneas.
Budget-métrica: «ms CPU a petición»; mantenemos un stock del 30-50% al pico.
Interacción con rate-limit: mide la proporción de solicitudes en el «techo» de la cuota y el impacto en la latencia.

12) Pruebas de carga y sintéticas

Tipos: carga básica, burst × 10, «escalones», mesetas a largo plazo, estrés/chaos (matanza de nodos, retardo de red), sintética en escenarios críticos de clientes.
Perfilando: CPU/alloc/lock-contention, N + 1 (SQL/HTTP), códigos lentos.
Control de regresiones: comparación de p95/p99/errores antes/después de la liberación (canario).

13) Costo (Costo-Observabilidad)

Métricas de costos: 'cpu _ ms',' egress _ bytes ',' db _ calls', '$ per 1k requests'.
Alocación en endpoint/tenant/fichu: etiquetas de facturación del orquestador + métricas de carga → informe de economía unit de la API.
Algoritmo de optimización: seleccionamos endpoints TOP por el producto 'traffic × cost × (p95 − objetivo)'.

14) Per-tenant de la analítica y la «justicia»

Todas las métricas clave son con la etiqueta 'tenant _ id/plan'.
Proporción de clientes «pesados» en las colas p99; límites/cuotas individuales y presupuestos retraídos.
Ferial Shearing: al sobrecargar, reducimos la proporción de inquilinos «de alto perfil».

15) Especificidad de iGaming/finanzas

Cortes por 'kyc _ level', 'risk _ tier', 'payment _ method'.
SLI para rutas «monetarias» ('POST/deposits',' POST/withdrawals '): debajo de los p95 objetivos, presupuestos de errores separados.
Métricas Time-to-Wallet (TTW), proporción de autobloqueos antifraude, conversión de pago.
Auditoría: registros inmutables para acciones financieras y soluciones antifraude.

16) Herramientas: prácticas de implementación

• `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`.
Cardinalidad: evite valores sueltos (user_id), use «baquetas »/hash.
Exemplars: conecte a los histogramas p95/p99 → haga clic en trace.

17) Antipatternas

Medias en lugar de percentiles; sin división en clases de status.
'Route '/' path' (ID dinámicos 'cosidos' en etiquetas) no alineados.
Etiquetas de alta cardinalidad (raw user_id, IP).
No hay contabilidad separada de proveedores externos (PSP/3rd-party).
Alertas por «ruido» (una sola ventana y un solo umbral).
p99 sin tener en cuenta el tiempo de queue (enmascara la degradación real).

18) Lista de comprobación de preparación prod

• Definido por SLI/SLO y error-budget, alineado con el negocio.
• Histogramas únicos latency y status class; p95/p99 en dashboards.
• Rastreo completo (OTel), correlación de registros/métricas/tracks.
• alertas burn-rate (de dos ventanas), umbrales de p99 y error-rate.
• Pere-tenant/peer-plan incisiones e informes de valor.
• Dashboards: Exec, Per-Route, Dependencies, Capacity, Abuse.
• Escenarios de carga (burst/meseta/estrés), perfiles.
• Políticos retrayentes con jitter; teniendo en cuenta el impacto de los retraídos en el RPS.
• Documentación SLA/SLO para socios y clientes públicos.
• Retiro/enmascaramiento de registros, protección PII.

19) TL; DR

Construir la observabilidad alrededor de SLI/SLO y error-budget, medir RED/USE, recoger histogramas latency con p95/p99 y «queue time», distribuir un único trace-id desde el perímetro a la DB, usar tail/adaptive-sampling, sostenga los cortes per-tenant/costo y el burn-rate-alerting de dos ventanas. Planifique la capacidad según las leyes de colas y el impacto en las métricas del negocio; las antipatternas son medias en lugar de percentiles, alta cardinalidad y dependencias externas no contabilizadas.