Como calcular latência média por dispositivo em Real-Time Analytics

Este tutorial mostra como calcular a latência média por dispositivo em Real-Time Analytics, útil para monitorizar desempenho e detetar degradações. A técnica agrega eventos por janelas temporais, trata eventos tardios e produz métricas prontas para alertas ou dashboards.

Pré-requisitos

• Conta com acesso a um serviço de ingestão em tempo real (ex.: Event Hubs, Kafka) e a um motor de consulta/streaming (ex.: Azure Stream Analytics, Azure Data Explorer / Kusto).
• Fonte de eventos com campos: device_id, event_id, event_time (timestamp), processed_time (timestamp) e payload.
• Conhecimentos básicos de KQL ou SQL streaming, e acesso ao ambiente para executar consultas.

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

Medir latência (diferença entre event_time e processed_time) por dispositivo permite identificar problemas de rede, dispositivos com relógios fora de sincronização ou congestionamento na pipeline. A média por janela estabiliza variações e realça tendências.

Passo 2: Definir a métrica e a janela

Decida a definição: latência = processed_time - event_time (em milissegundos). Escolha uma janela tumbling ou sliding (por exemplo, tumbling de 1 minuto) para métricas em tempo real. Janela demasiado curta aumenta ruído; demasiado longa perde resolução.

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

Exemplo em Kusto (Azure Data Explorer) para calcular a latência em ms por device_id em janelas de 1 minuto, ignorando eventos com latência negativa significativa e limitando atraso 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

Explicação breve do que faz cada passo: converter timestamps, calcular latency_ms, filtrar valores anómalos e agregar por device_id e janela de 1 minuto com avg e percentile para contexto.

Passo 4: Tratar eventos tardios e ajustar resultados

Eventos que chegam atrasados podem distorcer métricas por janela. Em AZURE DATA EXPLORER pode usar policy de ingestion_time ou tolerância de lateness; em Azure Stream Analytics utiliza-se event-time e Late Arrival Policy. Alternativa: manter duas agregações — uma inicial e uma final com janela de processamento tardio (ex.: esperar 2 minutos) e reconciliar.

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

Para obter evolução mais estável, aplique uma média móvel sobre as janelas. Em KQL pode usar make-series para séries temporais ou função prev/next simples para janelas contínuas.

// 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 é uma função comum; se não existir no motor, implementa-se com prev/next ou make-series + array operations.

Passo 6: Exportar métricas para dashboard/alerting

Exporte os resultados para Power BI, Grafana ou um sistema de alertas. Para alertas, crie regras que disparem quando avg_latency_ms ou p95_latency_ms excederem thresholds. Ex.: avisar quando p95_latency_ms > 2000 ms e count > 50.

Verificar o resultado

Valide correndo a consulta olhando para algumas condições: 1) as médias estão dentro do esperado por dispositivo; 2) event_time e processed_time fazem sentido (sem latências negativas); 3) volume (count) por janela é coerente. Teste com eventos sintéticos: gere eventos com latências conhecidas e confirme que avg_latency_ms aproxima-se do valor esperado.

Conclusão

Com estes passos obtém-se latência média por dispositivo em Real-Time Analytics, com tratamento de eventos tardios e suavização por média móvel. Próximo passo: criar alertas baseados em p95 e integrar num dashboard. Dica: comece com janelas maiores e reduza a janela conforme ganha confiança nas medições — que limiar de latência considera crítico para a sua aplicação?