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 atende milhares de clientes que enviam terabytes de dados todos os meses em um ritmo crescente. Muitas vezes, há dúvidas sobre o tempo que leva para os dados de log ficarem disponíveis depois de coletados. Este artigo explica os diferentes fatores que afetam essa latência.

Latência média

A latência refere-se ao tempo em que os dados são criados no sistema monitorado e ao tempo em que ficam disponíveis para análise no Azure Monitor. A latência média para ingerir dados de log é entre 20 segundos e 3 minutos. A latência específica para qualquer dado específico variará dependendo de 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:

• Tempo do agente: o tempo para descobrir um evento, coletá-lo e, em seguida, enviá-lo para um ponto de extremidade de coleta de dados como um registro de log. Na maioria dos casos, esse processo é tratado por um agente. Mais latência pode ser introduzida pela rede.
• Tempo de 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 potencialmente a adição de informações calculadas.
• Tempo de indexação: o tempo gasto para ingerir um registro de log em um armazenamento de big data do Azure Monitor.

Os detalhes sobre as diferentes latências introduzidas neste processo são descritos nas seções a seguir.

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

O tempo varia

Agentes e 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 estão listados na tabela a seguir.

Tipo de dados	Frequência da recolha	Notas
Eventos do Windows, eventos Syslog e métricas de desempenho	Recolhido imediatamente
Contadores de desempenho do Linux	Sondagem em intervalos de 30 segundos
Logs do IIS e logs de texto	Coletados após as alterações de carimbo de data/hora	Para logs do IIS, esse agendamento é influenciado pelo agendamento de substituição configurado no IIS.
Solução de replicação do Ative Directory	Avaliação a cada cinco dias	O agente coleta os logs somente quando a avaliação é concluída.
Solução de avaliação do Ative Directory	Avaliação semanal da infraestrutura do Ative Directory	O agente coleta os logs somente quando a avaliação é concluída.

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

Menos de 1 minuto

Para garantir que o agente do Log Analytics seja leve, o agente armazena logs em buffer e os carrega periodicamente no 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 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 Azure estão disponíveis em menos de um minuto no banco de dados de métricas, mas levam mais 3 minutos para serem exportadas para o ponto de extremidade de coleta de dados.
• Os logs de recursos normalmente adicionam de 30 a 90 segundos, dependendo do serviço do Azure. Alguns serviços do Azure (especificamente, o Banco de Dados SQL do Azure e a Rede Virtual do Azure) atualmente relatam seus logs em intervalos de 5 minutos. Estão em curso trabalhos para melhorar ainda mais esta situação. Para examinar essa latência em seu ambiente, consulte a consulta a seguir.
• Os registros de atividades estão disponíveis para análise em 3 a 20 minutos.

Recolha de soluções de gestão

Varia

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

• A solução Microsoft 365 sonda os logs de atividade usando a API de Atividade de Gerenciamento, que atualmente não fornece nenhuma garantia de latência quase em tempo real.
• Os dados das soluções do Windows Analytics (Update Compliance, por exemplo) são coletados pela solução diariamente.

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

Tempo de processo de pipeline

30 a 60 segundos

Depois que os dados estiverem disponíveis no ponto de extremidade de coleta de dados, levará mais 30 a 60 segundos para estar disponível para consulta.

Depois que os registros de log são ingeridos no pipeline do Azure Monitor (conforme identificado na propriedade _TimeReceived), eles são gravados no armazenamento temporário para garantir o isolamento do locatário e garantir que os dados não sejam perdidos. Este processo normalmente adiciona 5 a 15 segundos.

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

Se a coleta de dados incluir uma transformação de tempo de ingestão, isso adicionará alguma latência ao pipeline. Use a métrica Logs Transformation Duration per Min para monitorar a eficiência da consulta de transformação.

Outro processo que adiciona latência é o processo que manipula 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 a partir de um log personalizado ou da API do coletor de dados, o sistema cria um contêiner de armazenamento dedicado. Essa sobrecarga única ocorre somente na primeira aparição desse tipo de dados.

Proteção contra picos

Normalmente menos de 1 minuto, mas pode ser mais

A principal prioridade do Azure Monitor é garantir que nenhum dado do cliente seja perdido, portanto, o sistema tem proteção interna para picos de dados. Esta proteção inclui buffers para garantir que, mesmo sob imensa carga, o sistema continuará funcionando. Em carga normal, esses controles adicionam menos de um minuto. Em condições extremas e falhas, eles podem adicionar tempo significativo, garantindo a segurança dos dados.

Indexing time (Tempo de indexação)

5 minutos ou menos

Há um equilíbrio integrado para cada plataforma de big data entre o fornecimento de recursos de análise e pesquisa avançada, em vez de fornecer acesso imediato aos dados. Com o Azure Monitor, você pode executar consultas poderosas em bilhões de registros e obter resultados em poucos segundos. Esse desempenho é possível porque a infraestrutura transforma drasticamente os dados durante sua ingestão e os armazena em estruturas compactas exclusivas. O sistema armazena os dados em buffer até que o suficiente esteja disponível para criar essas estruturas. Esse processo deve ser concluído antes que o registro de log apareça nos resultados da pesquisa.

Atualmente, esse processo leva cerca de 5 minutos quando há um baixo volume de dados, mas pode levar menos tempo em taxas de dados mais altas. Esse comportamento parece contraintuitivo, mas esse processo permite a otimização da latência para cargas de trabalho de produção de alto volume.

Verificar o tempo de ingestão

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

Passo	Propriedade ou função	Comentários
Registro criado na fonte de dados	TimeGenerated Se a fonte de dados não definir esse valor, ele será definido ao mesmo tempo que _TimeReceived.	Se, no momento do processamento, o valor de tempo gerado for superior a dois dias, a linha será descartada.
Registro recebido pelo ponto de extremidade de coleta de dados	_TimeReceived	Este 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 ingestion_time() se houver necessidade de filtrar apenas os registros que foram ingeridos em uma determinada janela de tempo. Nesses casos, recomendamos também adicionar um TimeGenerated filtro com um intervalo maior.

Atrasos na latência de ingestão

Você pode medir a latência de um registro específico comparando o resultado da função ingestion_time() com a TimeGenerated propriedade. 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 para grandes quantidades de dados.

Por exemplo, a consulta a seguir mostrará quais computadores tiveram o maior tempo de ingestão 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 percentis anteriores são boas para encontrar tendências gerais de latência. Para identificar um pico de latência de curto prazo, usar o máximo (max()) pode ser mais eficaz.

Se você quiser detalhar o tempo de ingestão de um computador específico durante um período de tempo, 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 onde eles estão localizados, que é baseado em seu 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 originários do agente podem ter tempo de latência de ingestão diferente, portanto, 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 condições de latência para 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 emparelhadas 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, olhe para seu registro mais recente, que pode ser identificado pelo campo padrão TimeGenerated .

Use a Heartbeat tabela para verificar a disponibilidade de uma VM porque uma pulsação é enviada uma vez por minuto pelo agente. Use a seguinte consulta para listar os computadores ativos que não relataram pulsação 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 

Próximos passos

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