Como implementar alertas de latência por percentil em Real-Time Analytics

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

Este tutorial mostra como implementar alertas que monitorizam percentis de latência em Real-Time Analytics — útil para detetar degradações de desempenho por utilizador ou por serviço. Vamos calcular percentis em janelas deslizantes e disparar eventos de alerta quando o valor exceder um limiar.

Pré-requisitos

Conta e instância com um sistema de streaming (ex.: Apache Kafka, Event Hubs) e um motor de processamento em tempo real (ex.: Azure Stream Analytics, Flink, Spark Structured Streaming).
Fonte de eventos com timestamp, request_id, service, latency_ms.
Ferramenta de notificação (ex.: webhook, Azure Function, Prometheus Alertmanager) para receber alertas.

Passo 1: Escolher a estratégia de janelas e percentil

Decidir a janela temporal (ex.: 1 minuto, deslizante a cada 15s) e o percentil a monitorizar (ex.: 95.º). A janela deslizante reduz falsos positivos e dá visibilidade rápida. Exemplo: janela de 1 minuto com slide de 15s para calcular o 95.º percentil de latency_ms por service.

Passo 2: Normalizar e validar eventos

Garantir que cada evento tem timestamp correcto e latency_ms numérico; remover outliers absurdos (ex.: negativos ou > 1 hora). Isto evita cálculos errados do percentil.

// Pseudocódigo para validação (adaptar ao seu motor) // recebe evento {timestamp, request_id, service, latency_ms} if (!timestamp || !service || latency_ms == null) drop(event) if (latency_ms < 0 || latency_ms > 3600000) drop(event) // mais de 1h inválido emit(validated_event)

Passo 3: Calcular o percentil em streaming

Usar função de percentil do motor (ex.: APPROX_PERCENTILE, percentile_approx, approxQuantile). No exemplo abaixo uso pseudo-SQL compatível com motores que suportam agregações por janela deslizante.

// Exemplo conceptual SQL para um motor de streaming que suporte janelas 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)

Passo 4: Definir regras de alerta e suavização

Estabelecer limiares (ex.: p95_latency > 500ms) e regras adicionais para evitar alertas por picos curtos: exigir N janelas consecutivas acima do limiar ou usar backoff. Exemplo: alertar apenas se 3 janelas consecutivas (com slide 15s) excederem 500ms.

// Lógica simples para detetar 3 janelas consecutivas em pseudo-SQL/streaming WITH p95_per_window AS (
  -- resultado do passo 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

Passo 5: Emissão do alerta e integração com notificações

Quando a condição de alerta for satisfeita, emitir mensagem para um tópico de alertas ou invocar webhook/Azure Function que envia e‑mail, SMS ou cria ticket. Incluir contexto: service, p95, timestamps e amostra de requests para diagnóstico.

// Exemplo minimal 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 o resultado

Confirmar que o pipeline emite p95 por janela e que os alertas aparecem apenas quando a regra de suavização é satisfeita. Testar com eventos sintéticos: injetar latências elevadas durante 45s para tentar exceder o critério de 3 janelas consecutivas. Verifique logs do motor, tópicos de alertas e recepção do webhook.

Conclusão

Implementou um fluxo de Real-Time Analytics que calcula percentis de latência em janelas deslizantes e dispara alertas com suavização para evitar falsos positivos. Próximos passos: ajustar limiares por serviço, armazenar histórico para análises e integrar dashboards em tempo real. Dica: comece por métricas menos sensíveis (p90) para reduzir ruído e só depois passe para p95/p99.