Cómo calcular latencia media por dispositivo en Real-Time Analytics

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

Este tutorial muestra cómo calcular la latencia media por dispositivo en Real-Time Analytics, útil para monitorizar rendimiento y detectar degradaciones. La técnica agrega eventos por ventanas temporales, trata eventos tardíos y produce métricas listas para alertas o dashboards.

Pré-requisitos

Cuenta con acceso a un servicio de ingestión en tiempo real (ej.: Event Hubs, Kafka) y a un motor de consulta/streaming (ej.: Azure Stream Analytics, Azure Data Explorer / Kusto).
Fuente de eventos con campos: device_id, event_id, event_time (timestamp), processed_time (timestamp) y payload.
Conocimientos básicos de KQL o SQL streaming, y acceso al entorno para ejecutar consultas.

Passo 1: Porque calcular latência média por dispositivo

Medir latencia (diferencia entre event_time y processed_time) por dispositivo permite identificar problemas de red, dispositivos con relojes fuera de sincronización o congestión en la pipeline. La media por ventana estabiliza variaciones y realza tendencias.

Passo 2: Definir a métrica e a janela

Decida la definición: latencia = processed_time - event_time (en milisegundos). Elija una ventana tumbling o sliding (por ejemplo, tumbling de 1 minuto) para métricas en tiempo real. Ventana demasiado corta aumenta ruido; demasiado larga pierde resolución.

Passo 3: Ingerir eventos e calcular latência (exemplo KQL)

Ejemplo en Kusto (Azure Data Explorer) para calcular la latencia en ms por device_id en ventanas de 1 minuto, ignorando eventos con latencia negativa significativa y limitando retraso permitido (lateness) a 2 minutos.

Events
| where ingestion_time() > ago(1h)  // ajustar conforme necessário
| extend event_time = todatetime(event_time), processed_time = todatetime(processed_time)
| extend latency_ms = datetime_diff('millisecond', processed_time, event_time) * -1
| where latency_ms >= 0 and latency_ms < 300000   // filtrar latências inválidas e >5min
| summarize avg_latency_ms = avg(latency_ms), p95_latency_ms = percentile(latency_ms, 95), count = count()
    by device_id, bin(event_time, 1m)
| order by event_time desc, device_id

Breve explicación de lo que hace cada paso: convertir timestamps, calcular latency_ms, filtrar valores anómalos y agregar por device_id y ventana de 1 minuto con avg y percentile para contexto.

Passo 4: Tratar eventos tardios e ajustar resultados

Los eventos que llegan tardíos pueden distorsionar métricas por ventana. En AZURE DATA EXPLORER puede usar policy de ingestion_time o tolerancia de lateness; en Azure Stream Analytics se utiliza event-time y Late Arrival Policy. Alternativa: mantener dos agregaciones — una inicial y una final con ventana de procesamiento tardío (ej.: esperar 2 minutos) y reconciliar.

Passo 5: Calcular média móvel para suavizar ruído

Para obtener evolución más estable, aplique una media móvil sobre las ventanas. En KQL puede usar make-series para series temporales o función prev/next simple para ventanas continuas.

// Exemplo simples de média móvel de 5 janelas de 1m
Events
| extend event_time = todatetime(event_time), latency_ms = datetime_diff('millisecond', todatetime(processed_time), event_time) * -1
| where latency_ms between (0 .. 300000)
| summarize avg_latency_ms = avg(latency_ms) by device_id, bin(event_time, 1m)
| sort by device_id, event_time asc
| serialize
| extend ma5 = moving_avg(avg_latency_ms, 5)

moving_avg es una función común; si no existe en el motor, se implementa con prev/next o make-series + array operations.

Passo 6: Exportar métricas para dashboard/alerting

Exporte los resultados a Power BI, Grafana o un sistema de alertas. Para alertas, cree reglas que se activen cuando avg_latency_ms o p95_latency_ms excedan thresholds. Ej.: avisar cuando p95_latency_ms > 2000 ms y count > 50.

Verificar o resultado

Valide ejecutando la consulta y observando algunas condiciones: 1) las medias están dentro de lo esperado por dispositivo; 2) event_time y processed_time tienen sentido (sin latencias negativas); 3) volumen (count) por ventana es coherente. Pruebe con eventos sintéticos: genere eventos con latencias conocidas y confirme que avg_latency_ms se aproxima al valor esperado.

Conclusão

Con estos pasos se obtiene la latencia media por dispositivo en Real-Time Analytics, con tratamiento de eventos tardíos y suavizado por media móvil. Siguiente paso: crear alertas basadas en p95 e integrar en un dashboard. Consejo: comience con ventanas mayores y reduzca la ventana conforme gane confianza en las mediciones — ¿qué umbral de latencia considera crítico para su aplicación?