Log data ingestion time in Azure Monitor (Tempo de ingestão de dados de registo no Azure Monitor)

O Azure Monitor é um serviço de dados de alta escala que serve milhares de clientes que enviam terabytes de dados todos os meses a um ritmo crescente. Muitas vezes, existem dúvidas sobre o tempo que os dados de registo demoram a ficar disponíveis depois de serem recolhidos. Este artigo explica os diferentes fatores que afetam esta latência.

Latência típica

A latência refere-se à hora em que os dados são criados no sistema monitorizado e à hora em que ficam disponíveis para análise no Azure Monitor. A latência típica para ingerir dados de registo é entre 20 segundos e 3 minutos. A latência específica para dados específicos irá variar consoante vários fatores explicados neste artigo.

Fatores que afetam a latência

O tempo total de ingestão de um determinado conjunto de dados pode ser dividido nas seguintes áreas de alto nível:

  • Hora do agente: a hora de detetar um evento, recolhê-lo e, em seguida, enviá-lo para um ponto de ingestão de Registos do Azure Monitor como um registo. Na maioria dos casos, este processo é processado por um agente. A rede poderá introduzir mais latência.
  • Hora do pipeline: o tempo para o pipeline de ingestão processar o registo. Este período de tempo inclui analisar as propriedades do evento e potencialmente adicionar informações calculadas.
  • Tempo de indexação: o tempo gasto para ingerir um registo num arquivo de macrodados do Azure Monitor.

Os detalhes sobre a latência diferente introduzida neste processo são descritos nas secções seguintes.

Agent collection latency (Latência de recolha do agente)

O tempo varia

Os agentes e as soluções de gestão utilizam diferentes estratégias para recolher dados de uma máquina virtual, o que pode afetar a latência. Alguns exemplos específicos estão listados na tabela seguinte.

Tipo de dados Frequência da recolha Notas
Eventos do Windows, eventos do Syslog e métricas de desempenho Recolhidos imediatamente
Contadores de desempenho do Linux Consultado em intervalos de 30 segundos
Registos do IIS e registos de texto Recolhido após as alterações ao carimbo de data/hora Para os registos do IIS, esta agenda é influenciada pela agenda de rollover configurada no IIS.
Solução de Replicação do Active Directory Avaliação a cada cinco dias O agente recolhe os registos apenas quando a avaliação estiver concluída.
Solução de Avaliação do Active Directory Avaliação semanal da infraestrutura do Active Directory O agente recolhe os registos apenas quando a avaliação estiver concluída.

Agent upload frequency (Frequência de carregamento do agente)

Menos de 1 minuto

Para garantir que o agente do Log Analytics é leve, o agente intermédia regista e carrega-os periodicamente para o Azure Monitor. A frequência de carregamento 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 destes dados para atingir um ponto de ingestão de Registos do Azure Monitor.

Métricas do Azure, registos de recursos, registo de atividades

30 segundos a 15 minutos

Os dados do Azure adicionam mais tempo para ficarem disponíveis num ponto de ingestão de Registos do Azure Monitor para processamento:

  • As métricas da plataforma do Azure estão disponíveis em menos de um minuto na base de dados de métricas, mas demoram mais 3 minutos a serem exportadas para o ponto de ingestão de Registos do Azure Monitor.
  • Normalmente, os registos de recursos adicionam 30 a 90 segundos, dependendo do serviço do Azure. Alguns serviços do Azure (especificamente, base de dados SQL do Azure e Rede Virtual do Azure) comunicam atualmente os seus registos em intervalos de 5 minutos. O trabalho está em curso para melhorar ainda mais desta vez. Para examinar esta latência no seu ambiente, veja a consulta que se segue.
  • Os dados do registo de atividades são ingeridos em 30 segundos quando utiliza as definições de diagnóstico recomendadas ao nível da subscrição para os enviar para os Registos do Azure Monitor. Poderão demorar entre 10 a 15 minutos se, em vez disso, utilizar a integração legada.

Coleção de soluções de gestão

Varia

Algumas soluções não recolhem os dados de um agente e podem utilizar um método de recolha que introduz mais latência. Algumas soluções recolhem dados em intervalos regulares sem tentar recolher quase em tempo real. Exemplos específicos incluem:

  • A solução do Microsoft 365 consulta os registos de atividades com a API de Atividade de Gestão, que atualmente não fornece garantias de latência quase em tempo real.
  • Os dados das soluções do Windows Analytics (Conformidade de Atualizações, por exemplo) são recolhidos pela solução com uma frequência diária.

Para determinar a frequência de coleção de uma solução, veja a documentação de cada solução.

Tempo do processo de pipeline

30 a 60 segundos

Depois de os dados estarem disponíveis num ponto de ingestão, demora mais 30 a 60 segundos a estarem disponíveis para consulta.

Depois de os registos serem ingeridos no pipeline do Azure Monitor (conforme identificado na propriedade _TimeReceived ), são escritos no armazenamento temporário para garantir o isolamento do inquilino e para garantir que os dados não são perdidos. Normalmente, este processo adiciona 5 a 15 segundos.

Algumas soluções de gestão implementam algoritmos mais pesados para agregar dados e obter informações à medida que os dados são transmitidos em fluxo. Por exemplo, a Monitorização do Desempenho da Rede do Azure agrega os dados recebidos em intervalos de 3 minutos, o que efetivamente adiciona latência de 3 minutos.

Outro processo que adiciona latência é o processo que processa registos personalizados. Em alguns casos, este processo pode adicionar alguns minutos de latência aos registos recolhidos dos ficheiros pelo agente.

Aprovisionamento de novos tipos de dados personalizados

Quando um novo tipo de dados personalizados é criado a partir de um registo personalizado ou da API do Recoletor de Dados, o sistema cria um contentor de armazenamento dedicado. Esta sobrecarga única ocorre apenas no primeiro aspeto deste tipo de dados.

Proteção contra picos

Normalmente, menos de 1 minuto, mas pode ser mais

A principal prioridade do Azure Monitor é garantir que não se perdem dados do cliente, pelo que o sistema tem proteção incorporada para picos de dados. Esta proteção inclui memórias intermédias para garantir que, mesmo sob uma carga imensa, o sistema continuará a funcionar. Sob carga normal, estes controlos adicionam menos de um minuto. Em condições e falhas extremas, podem adicionar tempo significativo ao mesmo tempo que garantem que os dados são seguros.

Tempo de indexação

5 minutos ou menos

Existe um equilíbrio incorporado para todas as plataformas de macrodados entre o fornecimento de capacidades de análise e de pesquisa avançada em vez de fornecer acesso imediato aos dados. Com o Azure Monitor, pode executar consultas poderosas em milhares de milhões de registos e obter resultados dentro de alguns segundos. Este desempenho é possível porque a infraestrutura transforma drasticamente os dados durante a ingestão e armazena-os em estruturas compactas exclusivas. O sistema coloca os dados em memória intermédia até estar disponível o suficiente para criar estas estruturas. Este processo tem de ser concluído antes de o registo aparecer nos resultados da pesquisa.

Atualmente, este processo demora cerca de 5 minutos quando existe um baixo volume de dados, mas pode demorar menos tempo a taxas de dados mais elevadas. Este comportamento parece contraintuitivo, mas este processo permite a otimização da latência para cargas de trabalho de produção de elevado volume.

Verificar a hora de ingestão

O tempo de ingestão pode variar para diferentes recursos em circunstâncias diferentes. Pode utilizar consultas de registo para identificar comportamentos específicos do seu ambiente. A tabela seguinte especifica como pode determinar as diferentes horas de um registo à medida que é criado e enviado para o Azure Monitor.

Passo Propriedade ou função Comentários
Registo criado na origem de dados TimeGenerated
Se a origem de dados não definir este valor, será definido como ao mesmo tempo que _TimeReceived.
Se no momento do processamento o valor Tempo Gerado for superior a 3 dias, a linha será removida.
Registo recebido pelo ponto final de ingestão do Azure Monitor _TimeReceived Este campo não está otimizado para processamento em massa e não deve ser utilizado para filtrar grandes conjuntos de dados.
Registo armazenado na área de trabalho e disponível para consultas ingestion_time() Recomendamos que utilize ingestion_time() se for necessário filtrar apenas os registos que foram ingeridos numa determinada janela de tempo. Nestes casos, recomendamos também adicionar um TimeGenerated filtro com um intervalo maior.

Atrasos na latência da ingestão

Pode medir a latência de um registo específico ao comparar o resultado da função ingestion_time() com a TimeGenerated propriedade . Estes dados podem ser utilizados com várias agregações para descobrir o comportamento da latência de ingestão. Examine algum percentil do tempo de ingestão para obter informações sobre grandes quantidades de dados.

Por exemplo, a seguinte consulta irá mostrar-lhe quais os computadores que tiveram o tempo de ingestão mais elevado nas 8 horas anteriores:

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 úteis para encontrar tendências gerais de latência. Para identificar um pico de latência a curto prazo, a utilização do máximo (max()) pode ser mais eficaz.

Se quiser desagregar o tempo de ingestão de um computador específico durante um período de tempo, utilize a seguinte consulta, que também visualiza os dados do último dia num 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

Utilize a seguinte consulta para mostrar o tempo de ingestão de computadores pelo país/região onde estão localizados, que se baseia no respetivo 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 provenientes do agente podem ter um tempo de latência de ingestão diferente, pelo que as consultas anteriores podem ser utilizadas com outros tipos. Utilize a seguinte consulta 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

Recursos que deixam de responder

Em alguns casos, um recurso pode parar de enviar dados. Para compreender se um recurso está a enviar dados ou não, veja o registo mais recente, que pode ser identificado pelo campo padrão TimeGenerated .

Utilize a Heartbeat tabela para verificar a disponibilidade de uma VM porque o agente envia um heartbeat uma vez por minuto. Utilize a seguinte consulta para listar os computadores ativos que não reportaram heartbeat recentemente:

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 

Passos seguintes

Leia o contrato de nível de serviço do Azure Monitor.