Operaciones y administración de → Métricas de rendimiento

Métricas de rendimiento

1) Por qué se necesitan métricas de rendimiento

• detectar degradaciones antes de incidentes,
• prever la capacidad y el presupuesto,
• comparar soluciones alternativas (caché vs BD, gRPC vs NAT),
• gestionar las regresiones posteriores a los lanzamientos.

Principios: un solo diccionario de métricas, agregación de percentiles (p50/p90/p95/p99), contabilización separada de rutas «calientes» y «frías», contexto (versión, región, proveedor, dispositivo).

2) Taxonomía métrica

2. 1 Marco SRE básico

Cuatro señales de oro: Latency, Traffic, Errors, Saturation.
RED (para microservicios): Rate, Errors, Duration.
USE (para hierro): Utilización, Saturación, Errores.

2. 2 Niveles

Infraestructura: CPU, RAM, disco, red, contenedores, nodos.
Plataforma/Servicios: API-endpoints, colas, cachés, DB, bus de eventos.
Experiencia del cliente: Web Vitals, SDK móvil, streaming, CDN.
Plataforma de datos: ETL/ELT, streams, escaparates, latencia BI.
Flow crítico de negocios: autorización, KYC, depósitos/pagos, rondas de juegos.

3) Catálogo de métricas y fórmulas clave

3. 1 API y microservicios

RPS (Requests per second).
Latency p50/p95/p99 (ms) - preferiblemente "end-to-end' y" backend-only ".
Error Rate (%) = 5xx + 4xx validable/todas las solicitudes.
Saturation: longitud media de la cola de workers, consultas «in-flight».
Cold Start Rate (para FaaS).
Throttling/Dropped Requests.

SLO ejemplo: p95 latency ≤ 250 ms en RPS a 2k en la región EU-East; Errores ≤ 0. 5%.

3. 2 Bases de datos

QPS/Transactions/s, avg/median query time, p95 query time.
Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.
AproxLag (replicación), Checkpoint/Flush time, Autovacuum nat.
Hot Keys/Skew es el top N de las llaves por carga.

Fórmula «Solicitudes de núcleo»: QPS/ vCPU_core_count → una señal para charding.

3. 3 Caché y CDN

Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.
Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.

3. 4 colas/streams

Ingress/egress msg/s, Consumer Log (mensajes/tiempo), Rebalance rate.
Processing Time p95, DLQ Rate.

3. 5 Infraestructura/contenedores

CPU Utilization %, CPU Throttle %, Run Queue length.
Memory RSS/Working Set, OOM kills, Page Faults.
Disk IOPS/Latency/Throughput, Network RTT/ retransmits.
Node Saturation: pods pending, pressure (CPU/Memory/IO).

3. 6 Cliente Web (UX)

Core Web Vitals: LCP, INP, CLS.
TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).
Error Rate (JS), Long Tasks, SPA route change time.
CDN Geo-Latency (percentil).

3. 7 Cliente móvil

App Start time (cold/warm), ANR rate, Crash-free sessions %.
Network round-trips/session, Payload size, Battery drain/session.
Tasa de éxito sin conexión (operaciones en caché).

3. 8 Plataforma de datos y presentación de informes

Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.
Costo por TB procesado, Skew por lotes, eventos Late%.
BI Time-to-Render p95 para dashboards clave.

3. 9 Dominio crítico flow (iGaming como ejemplo)

Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.
Game Round Duration p95, RNG call latency, Provider RTT p95.
Payment PSP success rate, Chargeback investigation SLA.

4) Normalización, percentili y atribución

Percentili contra medias: fijamos p50/p90/p95/p99 - medianas suavizan los dolores máximos.
Cortes: versión de la aplicación, región, proveedor, canal de red (4G/Wi-Fi), dispositivo.
Correlación: asociamos métricas «backend-only» y «real-user» para cadenas causales.
Exemplars/Traces: asociamos percentils extremos con trazados.

5) Umbrales y alertas (cuadrícula aproximada)

Latency p95 (core API): warning> 250 ms, critical> 400 ms 5 min seguidos.
Error rate: warning > 0. 5%, critical> 2% (por endpoint, no global).
DB RepLag: warning > 2 s, critical > 10 s.
Kafka consumer lag (time): warning > 30 s, critical > 2 min.
Web LCP (p75): warning > 2. 5 s, critical > 4 s.
Mobile ANR: warning > 0. 5%, critical > 1%.
ETL Freshness: warning > +15 min, critical > +60 min от SLA.

Utilizamos umbrales estáticos + adaptativos (estacionalidad, patrones diurnos), deduplicación y agrupación de alertas por servicios/lanzamientos.

6) Pruebas de rendimiento

Tipos: baseline, estrés, largo (soak), caos (degrade links/PSP).
Perfiles de carga: por tries reales (distribution-based), «burst», picos regionales.
Objetivos: lograr SLO con RPS objetivo y operaciones de mix, validación de backpressure.
Métricas de ejecución: Throughput, Error%, p95 latency, pausa GC, CPU throttle, queue lag, costo/run.

Regla de regresión: la liberación se considera exitosa si p95 no se deteriora> 10% con un perfil igual y el costo de la solicitud (CPU-ms/request) no ha aumentado> 15%.

7) Planificación de capacidad y precio/rendimiento

Demand model: RPS por reloj × trabajo medio/consulta (CPU-ms, IO-ops).
Headroom: 30-50% de stock para rutas críticas, auto-scaling por P95.
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p. p. Mejoras LCP.
Almacenamiento en caché/desnormalización: contar «cache ROI» = (ahorro de CPU-ms − costo de caché).
Regiones cálidas y frías: offload en CDN/edge, replicación de sólo lectura.

8) Prácticas de observación y elaboración de perfiles

Tracks: trace-ID distribuidos a través de todos los hop's; sampling inteligente (tail-based).
Métricas: Prometheus/OpenTelemetry, notación única de nombres y etiquetas.
Logs: con correlación por trace/span, budget por ruido de registro, edición PII.
Perfiles: Perfiles CPU/Heap/Alloc/Lock, Perfiles Continuos (eBPF).
Instancias de muestra: asociamos p99 ráfagas con span/SQL/PSP-coll específicos.

9) Métricas de lanzamientos y comandos (para completar)

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
ESPACIO: satisfacción, rendimiento, actividad, comunicación, eficiencia.
Estas métricas no son sobre hierro, sino que afectan directamente a la sostenibilidad del rendimiento.

10) Anti-patrones

Perseguir los promedios: ignorar p95/p99.
«Global» error rate: oculta endpoints dolorosos.
Sin atribución por versiones: no es posible capturar las regresiones del cliente.
Alert spam: umbrales sin histéresis y corrección de estacionalidad.
Optimización «a ciegas»: falta de perfiles y trazados.
Mezcla de UX y latencia de respaldo: conclusiones incorrectas sobre la experiencia del cliente.

11) Hojas de cheques

Estándar único de métricas

• Diccionario de métricas con fórmulas, unidades, propietarios
• Percentiles obligatorios p50/p90/p95/p99
• Correlación de trade y correlación de logs
• Etiquetas: región, versión, proveedor, dispositivo, canal de red
• Umbrales con histéresis y deduplicación

Antes

• Beizline p95/p99 en stage y venta
• Tráfico canario + comparación de métricas A/B
• Bandera de Ficha con retroceso rápido
• Plan de vigilancia (observabilidad runbook)

• Revuelo de las consultas Top N/SQL más lentas
• Auditoría de políticas de caché y TTL
• Comprobación de Freshness y réplicas de DB
• Pruebas de degradación de proveedores externos (PSP, KYC)

12) Mini playbucks (ejemplo)

Degradación p95/api/payments

1. Conciliar error% y temporizadores PSP externos.
2. Compruebe la cola de los collbacks del registro de consumo.
3. Ver trace ejemplos p99: ¿cuello de botella SQL/HTTP?
4. Habilitar caché de referencia/límite, reducir N + 1.
5. Presupuesto: elevar temporalmente los recursos del worker en un 20%, habilitar autoscale.
6. Post-fix: índice por (psp_id, status, created_at), retray-jitter.

Crecimiento de AmbLag en la DB

1. Compruebe las solicitudes «pesadas» y las transacciones largas.
2. Aumentar el paralelismo de replicación, afinar checkpoint.
3. Las lecturas en caché/réplicas son de sólo lectura.
4. En ventanas de pico, denorm + batches parciales.

13) Ejemplos de fórmulas/SQL (simplificado)

Error Rate por endpoint

sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;

Latency p95 (TDigest/Approx)

sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;

Registro de consumo (tiempo)

sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;

Web LCP p75

sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;

14) Incrustación en dashboards y presentación de informes

Tarjetas KPI: p95 latency, error%, RPS, saturation con tendencias WoW/DoD.
Top N «peor» endpoints/SQL/recursos, click drill-down → trace.
Correlación de versiones del cliente: grafo «versión → p95 LCP/INP → conversión».
Mapa del mundo: geo-latencia (CDN), latencia PSP por región.
Panel SLO: cuota de tiempo en SLO, salidas de SLO, «presupuesto de errores».

15) Resultados

Las métricas de rendimiento son una disciplina de sistema: diccionario único, percentili, atribución, buena observabilidad y SLO rigurosos. Al combinar señales técnicas (latencia, lags, caché) y de producto (tiempo KYC, depósito p95, LCP), gestiona la calidad de la experiencia y el costo de su envío - predecible y escalable.