Tempo de ingestão de dados de log no Azure Monitor

  • Artigo

O Azure Monitor é um serviço de dados de grande escala que atende milhares de clientes que enviam terabytes de dados por mês em um ritmo cada vez maior. Frequentemente, há dúvidas sobre o tempo necessário para que os dados de log fiquem disponíveis após a coleta. Este artigo explica os diferentes fatores que afetam essa latência.

Latência média

Latência se refere ao período entre o momento em que os dados são criados no sistema monitorado e o momento em que eles são disponibilizados para análise no Azure Monitor. A latência média para ingestão de dados de log é entre 20 segundos e 3 minutos. A latência específica de qualquer dado específico varia de acordo com vários fatores explicados neste artigo.

Fatores que afetam a latência

O tempo total de ingestão de determinado conjunto de dados pode ser dividido nas seguintes áreas gerais:

  • Tempo do agente: o tempo necessário para descobrir um evento, coletá-lo e, em seguida, enviá-lo para um ponto de extremidade de coleta de dados como registro de log. Na maioria dos casos, esse processo é manipulado por um agente. Uma latência maior pode ser causada pela rede.
  • Tempo do pipeline: o tempo para o pipeline de ingestão processar o registro de log. Esse período de tempo inclui a análise das propriedades do evento e a possível adição de informações calculadas.
  • Tempo de indexação: o tempo gasto na ingestão de um registro de log no armazenamento de Big Data do Azure Monitor.

Os detalhes sobre a latência diferente gerada nesse processo são descritos abaixo.

Latência da coleta de agente

A hora varia

Os agentes e as soluções de gerenciamento usam estratégias diferentes para coletar dados de uma máquina virtual, o que pode afetar a latência. Alguns exemplos específicos são listados na tabela a seguir.

Tipo de dados Frequência de coleta Observações
Eventos do Windows, eventos de syslog e métricas de desempenho Coletados imediatamente
Contadores de desempenho do Linux Sondados em intervalos de 30 segundos
Log do IIS e logs de texto Coletados quando o carimbo de data/hora é alterado Para os logs do IIS, esse agendamento é influenciado pelo agendamento de sobreposição configurado no IIS.
Solução de replicação do Active Directory Avaliação a cada cinco dias O agente coleta esses logs somente quando a avaliação é concluída.
Solução de Avaliação do Active Directory Avaliação semanal da infraestrutura do Active Directory O agente coleta esses logs somente quando a avaliação é concluída.

Frequência de upload de agente

Menos de 1 minuto

Para garantir que o agente do Log Analytics seja leve, o agente armazena em buffer os logs e carrega-os periodicamente no Azure Monitor. A frequência de upload varia entre 30 segundos e 2 minutos, dependendo do tipo de dados. A maioria dos dados é carregada em menos de 1 minuto.

Rede

Varia

As condições de rede podem afetar negativamente a latência desses dados para alcançar um ponto de extremidade de coleta de dados.

Métricas do Azure, logs de recursos, log de atividades

30 segundos a 15 minutos

Os dados do Azure adicionam mais tempo para ficarem disponíveis em um ponto de extremidade de coleta de dados para processamento:

  • As métricas da plataforma do Azure ficam disponíveis em menos de um minuto no banco de dados de métricas, mas levam mais três minutos para serem exportadas para o ponto de extremidade de coleta de dados.
  • Os logs de recursos costumam adicionar de 30 a 90 segundos, dependendo do serviço do Azure. No momento, alguns serviços do Azure (principalmente, o Banco de Dados SQL do Azure e a Rede Virtual do Azure) relatam os logs em intervalos de cinco minutos. Estão em curso trabalhos para reduzir esse tempo. Confira a consulta a seguir para examinar essa latência no seu ambiente.
  • Os logs de atividade estão disponíveis para análise em 3 a 10 minutos.

Coleção de soluções de gerenciamento

Varia

Algumas soluções não coletam os dados de um agente e podem usar um método de coleta que gera mais latência. Algumas soluções coletam dados em intervalos regulares sem tentar a coleta quase em tempo real. Exemplos específicos incluem:

  • A solução Microsoft 365 sonda os logs de atividades usando API de Atividade de Gerenciamento, que no momento não fornece nenhuma garantia de latência quase em tempo real.
  • Os dados das soluções de Análise do Windows (Conformidade de Atualizações, por exemplo) são coletados pela solução com uma frequência diária.

Veja a documentação de cada solução para determinar a respectiva frequência de coleta.

Tempo de processo de pipeline

30 a 60 segundos

Depois que os dados ficam disponíveis em um ponto de extremidade de coleta de dados, são necessários mais 30 a 60 segundos até que eles fiquem disponíveis para consulta.

Depois que os registros de log são ingeridos no pipeline do Azure Monitor (de acordo com a propriedade _TimeReceived ), eles são gravados em um armazenamento temporário para garantir o isolamento do locatário e garantir que os dados não sejam perdidos. Normalmente, esse processo adiciona de 5 a 15 segundos.

Algumas soluções implementam algoritmos mais pesados para agregar dados e obter insights conforme os dados são transmitidos. Por exemplo, o Application Insights calcula os dados do mapa do aplicativo; o Monitoramento de Desempenho de Rede do Azure agrega dados de entrada em intervalos de três minutos, o que efetivamente adiciona latência de três minutos.

Se a coleta de dados incluir uma transformação no tempo de ingestão, isso adicionará alguma latência ao pipeline. Use a métrica Duração da transformação de logs por minuto para monitorar a eficiência da consulta de transformação.

Outro processo que adiciona latência é o processo que lida com logs personalizados. Em alguns casos, esse processo pode adicionar alguns minutos de latência aos logs que são coletados de arquivos pelo agente.

Provisionamento de novos tipos de dados personalizados

Quando um novo tipo de dados personalizados é criado com base em um log personalizado ou na API do Coletor de Dados, o sistema cria um contêiner de armazenamento dedicado. Essa é uma sobrecarga única que ocorre apenas na primeira vez em que esse tipo de dados aparece.

Proteção contra aumento

Normalmente é menos de um minuto, mas pode ser maior

A principal prioridade do Azure Monitor é garantir que nenhum dado do cliente seja perdido e, portanto, o sistema tem uma proteção interna para aumentos de dados. Essa proteção inclui buffers para garantir que, mesmo sob uma carga enorme, o sistema continue funcionando. Sob carga normal, esses controles adicionam menos de um minuto. Em condições extremas e falhas, eles adicionam tempo significativo, mas garantem a segurança dos dados.

Tempo de indexação

5 minutos ou menos

Há um equilíbrio interno em cada plataforma de Big Data entre o fornecimento de funcionalidades de análise e pesquisa avançada e o fornecimento de acesso imediato aos dados. Com o Azure Monitor, você pode executar consultas avançadas em bilhões de registros e obter resultados em poucos segundos. Esse desempenho é possível porque a infraestrutura transforma os dados radicalmente durante a ingestão e armazena-os em estruturas compactas exclusivas. O sistema armazena os dados em buffer até que dados suficientes estejam disponíveis para criar essas estruturas. Esse processo precisa ser concluído até que o registro de log seja exibido nos resultados da pesquisa.

Esse processo demora cerca de cinco minutos quando há um baixo volume de dados, mas pode demorar menos em taxas mais altas de dados. Esse comportamento parece controverso, mas esse processo permite a otimização de latência para cargas de trabalho de produção de alto volume.

Verificar a hora da ingestão

O tempo de ingestão pode variar para diferentes recursos em circunstâncias diferentes. Você pode usar consultas de log para identificar um comportamento específico do seu ambiente. A tabela a seguir especifica como você pode determinar as diferentes times para um registro conforme ele é criado e enviado para Azure Monitor.

Etapa Propriedade ou função Comentários
Registro criado na fonte de dados TimeGenerated
Se a fonte de dados não definir esse valor, ela será definida com a mesma hora que _TimeReceived.		 Se, no momento do processamento, o valor de Hora Gerada for maior que dois dias, a linha será removida.
Registro recebido pelo ponto de extremidade de coleta de dados _TimeReceived Esse campo não é otimizado para processamento em massa e não deve ser usado para filtrar grandes conjuntos de dados.
Registro armazenado no espaço de trabalho e disponível para consultas ingestion_time() Recomendamos o uso de ingestion_time() quando há necessidade de filtrar somente registros que foram ingeridos em uma determinada janela de tempo. Nesses casos, recomendamos também adicionar um filtro TimeGenerated com um intervalo maior.

Atrasos de latência de ingestão

Você pode medir a latência de um registro específico ao comparar o resultado da função ingestion_time() com a propriedade TimeGenerated. Esses dados podem ser usados com várias agregações para descobrir como a latência de ingestão se comporta. Examine algum percentil do tempo de ingestão para obter insights de uma grande quantidade de dados.

Por exemplo, a consulta a seguir mostrará quais computadores tiveram o maior tempo de ingestão nas últimas 8 horas:

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

As verificações de percentil anteriores são boas para localizar tendências gerais em latência. Para identificar um pico de curto prazo em latência, usar o máximo ( max() ) pode ser mais eficaz.

Se você quiser fazer busca detalhada da hora de ingestão para um computador específico em um período, use a seguinte consulta, que também visualiza os dados do dia anterior em um gráfico:

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

Use a seguinte consulta para mostrar o tempo de ingestão do computador pelo país/região em que ele está localizado, ou seja, com base no endereço IP:

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry

Diferentes tipos de dados de origem do agente podem ter tempos de latência de ingestão diferentes, assim, as consultas anteriores podem ser usadas com outros tipos. Use a consulta a seguir para examinar o tempo de ingestão de vários serviços do Azure:

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

Use a mesma lógica de consulta para diagnosticar as condições de latência dos dados do Application Insights:

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

As duas consultas acima podem ser combinadas com qualquer outra tabela do Application Insights que não seja "solicitações".

Recursos que param de responder

Em alguns casos, um recurso pode parar de enviar dados. Para entender se um recurso está enviando dados ou não, examine o registro mais recente, que pode ser identificado pelo campo TimeGenerated padrão.

Use a tabela Heartbeat para verificar a disponibilidade de uma VM, pois uma pulsação é enviada uma vez por minuto pelo agente. Use a consulta a seguir para listar os computadores ativos que não relataram recentemente a pulsação:

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc

Próximas etapas

Leia o Contrato de Nível de Serviço do Azure Monitor.