Cómo implementar alertas de latencia por percentil en Real-Time Analytics

João Barros 30 de September de 2026 4 min de lectura

Este tutorial muestra cómo implementar alertas que monitorizan percentiles de latencia en Real-Time Analytics — útil para detectar degradaciones de rendimiento por usuario o por servicio. Vamos a calcular percentiles en ventanas deslizantes y disparar eventos de alerta cuando el valor exceda un umbral.

Requisitos previos

Cuenta e instancia con un sistema de streaming (p. ej.: Apache Kafka, Event Hubs) y un motor de procesamiento en tiempo real (p. ej.: Azure Stream Analytics, Flink, Spark Structured Streaming).
Fuente de eventos con timestamp, request_id, service, latency_ms.
Herramienta de notificación (p. ej.: webhook, Azure Function, Prometheus Alertmanager) para recibir alertas.

Paso 1: Elegir la estrategia de ventanas y percentil

Decidir la ventana temporal (p. ej.: 1 minuto, deslizante cada 15s) y el percentil a monitorizar (p. ej.: 95.º). La ventana deslizante reduce falsos positivos y proporciona visibilidad rápida. Ejemplo: ventana de 1 minuto con slide de 15s para calcular el 95.º percentil de latency_ms por service.

Paso 2: Normalizar y validar eventos

Asegurarse de que cada evento tiene timestamp correcto y latency_ms numérico; eliminar outliers absurdos (p. ej.: negativos o > 1 hora). Esto evita cálculos erróneos del percentil.

// Pseudocódigo para validación (adaptar a su motor) // recibe evento {timestamp, request_id, service, latency_ms} if (!timestamp || !service || latency_ms == null) drop(event) if (latency_ms < 0 || latency_ms > 3600000) drop(event) // más de 1h inválido emit(validated_event)

Paso 3: Calcular el percentil en streaming

Usar la función de percentil del motor (p. ej.: APPROX_PERCENTILE, percentile_approx, approxQuantile). En el ejemplo abajo uso pseudo-SQL compatible con motores que soportan agregaciones por ventana deslizante.

// Ejemplo conceptual SQL para un motor de streaming que soporte ventanas deslizantes SELECT
  TUMBLE_START(event_time, INTERVAL '15' SECOND) AS window_start,
  service,
  APPROX_PERCENTILE(latency_ms, 0.95) AS p95_latency
FROM input_stream
WHERE event_time >= CURRENT_TIMESTAMP - INTERVAL '2' HOUR
GROUP BY
  service,
  HOP(event_time, INTERVAL '15' SECOND, INTERVAL '1' MINUTE)

Paso 4: Definir reglas de alerta y suavizado

Establecer umbrales (p. ej.: p95_latency > 500ms) y reglas adicionales para evitar alertas por picos cortos: exigir N ventanas consecutivas por encima del umbral o usar backoff. Ejemplo: alertar solo si 3 ventanas consecutivas (con slide 15s) exceden 500ms.

// Lógica simple para detectar 3 ventanas consecutivas en pseudo-SQL/streaming WITH p95_per_window AS (
  -- resultado del paso 3
)
SELECT service, window_start, p95_latency,
  SUM(CASE WHEN p95_latency > 500 THEN 1 ELSE 0 END) OVER (PARTITION BY service ORDER BY window_start ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS last3_count
FROM p95_per_window
WHERE last3_count = 3

Paso 5: Emisión de la alerta e integración con notificaciones

Cuando la condición de alerta se cumpla, emitir mensaje a un topic de alertas o invocar webhook/Azure Function que envíe e‑mail, SMS o cree ticket. Incluir contexto: service, p95, timestamps y muestra de requests para diagnóstico.

// Ejemplo mínimo de payload para webhook {
  "service": "checkout-api",
  "alert": "p95_latency_exceeded",
  "p95_latency": 652,
  "window_start": "2026-09-30T12:00:00Z",
  "samples": ["req-123","req-456"]
}

Verificar el resultado

Confirmar que el pipeline emite p95 por ventana y que las alertas aparecen solo cuando se satisface la regla de suavizado. Probar con eventos sintéticos: inyectar latencias altas durante 45s para intentar exceder el criterio de 3 ventanas consecutivas. Verifique logs del motor, topics de alertas y recepción del webhook.

Conclusión

Ha implementado un flujo de Real-Time Analytics que calcula percentiles de latencia en ventanas deslizantes y dispara alertas con suavizado para evitar falsos positivos. Próximos pasos: ajustar umbrales por servicio, almacenar historial para análisis e integrar dashboards en tiempo real. Consejo: empiece por métricas menos sensibles (p90) para reducir ruido y solo después pase a p95/p99.