Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Azure Monitor é um serviço de dados de grande escala que envia terabytes de dados todos os meses e continua a crescer. Em operações normais de serviço, o tempo que demora até os dados de registo ficarem disponíveis após a recolha é previsível e consistente. Este artigo explica os fatores que afetam esta latência.
Latência média
Latência refere-se ao tempo entre a criação dos dados no sistema monitorizado e o momento em que ficam disponíveis para análise no Azure Monitor. A latência média para ingerir dados de log é inferior a 10 segundos. A latência específica para cada dado em particular varia dependendo de vários fatores explicados neste artigo.
Fatores que afetam a latência
O tempo total de ingestão para um determinado conjunto de dados é o tempo cumulativo desde o cliente até ao serviço Azure Monitor.
- Tempo do cliente: O tempo para descobrir um evento, recolhê-lo e depois enviá-lo para um endpoint de recolha de dados como registo de log. Na maioria dos casos, um agente como o Azure Monitor Agent (AMA) trata deste processo. Aplicações personalizadas que utilizam a API de ingestão Logs não fazem parte dos cálculos deste artigo, mas podem ter características de latência próprias semelhantes ao tempo do cliente AMA.
- Tempo do Azure Monitor: Depois de o cliente transferir para o Azure Monitor, é o tempo que a ingestão demora a processar o registo. Esse período de tempo inclui a análise das propriedades do evento e potencialmente a adição de informações calculadas.
As secções seguintes descrevem as diferentes latências introduzidas neste processo.
Agent collection latency (Latência de recolha do agente)
Latência: O tempo varia
Os agentes usam estratégias diferentes para recolher dados, 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 | Recolhidos após as alterações da marca temporal | Para logs do IIS, este agendamento é influenciado pelo agendamento de rotação configurado no IIS. |
Para mais informações sobre o desempenho do agente, consulte Azure Monitorizar o desempenho do agente.
Agent upload frequency (Frequência de carregamento do agente)
Latência: Menos de 1 minuto
Para manter o Azure Monitor Agent leve, ele armazena os logs 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
Latência: varia
A rede entre um cliente e o endpoint de recolha de dados do Azure Monitor pode adicionar atrasos inesperados. Quando mede a latência de ingestão, esta latência de rede é incluída como parte do AgentLatency cálculo na secção medição da latência de ingestão nas consultas de exemplo.
Métricas do Azure, registos de recursos, registos de atividades
Latência: 30 segundos a 20 minutos
Os dados do Azure adicionam mais tempo para ficarem disponíveis num endpoint de recolha de dados para processamento:
- Métricas da plataforma Azure estão disponíveis em menos de um minuto na base de dados de métricas, mas demoram mais três minutos para serem exportadas para o ponto de recolha de dados.
- Registos de recursos estão geralmente disponíveis entre 3 a 10 minutos de ponta a ponta, dependendo da complexidade do serviço e dos Azure serviços envolvidos. Por exemplo, Azure SQL Database e Azure Virtual Network atualmente fornecem os seus registos a cada cinco minutos. Para examinar essa latência em seu ambiente, consulte a consulta a seguir.
- Os registros de atividades estão disponíveis para análise e alertas em 3 a 20 minutos.
Tempo de processamento do Azure Monitor
Latência: Menos de 10 segundos
Depois de os dados chegarem ao endpoint de recolha de dados, demora menos de 10 segundos até poderes consultá-los.
Quando Azure Monitor ingere registos de log (como mostra a propriedade _TimeReceived), escreve-os em storage temporários. Esta etapa assegura o isolamento do inquilino e previne a perda de dados. Este passo normalmente acrescenta entre 5 a 15 segundos.
Algumas soluções usam algoritmos mais complexos para agregar dados e obter insights enquanto os dados fluem. Por exemplo, o Application Insights calcula dados de mapas de aplicação. O Azure Network Performance Monitoring agrega dados recebidos em intervalos de três minutos, o que adiciona efetivamente três minutos de latência neste caso.
Se a recolha de dados incluir uma transformação durante a ingestão, esta transformação adiciona alguma latência ao tempo de processo do Azure Monitor. 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, este processo pode adicionar alguns minutos de latência aos registos que um agente recolhe dos ficheiros.
Provisionamento de novos tipos de dados personalizados
Quando um novo tipo de dados personalizados é criado a partir de um registo personalizado ou da API de ingestão Logs, o sistema cria um contentor de storage dedicado. Essa sobrecarga única ocorre somente na primeira aparição desse tipo de dados.
Verificar o tempo de ingestão
O tempo de ingestão pode variar para diferentes recursos em diferentes circunstâncias. Use consultas de log para identificar o comportamento específico do seu ambiente. A tabela seguinte especifica como determina os diferentes horários de um registo à medida que é criado e enviado para o Azure Monitor. Para obter mais informações sobre consultas de log, consulte Visão geral do Log Analytics.
Advertência
Ao ingerir logs na camada Auxiliar do Azure Monitor, evite enviar uma única mensagem com TimeGenerated timestamps que cubram mais de 30 minutos numa única chamada de API. Esta chamada de API pode levar ao seguinte código RecordsTimeRangeIsMoreThan30Minutesde erro de ingestão. Esta é uma limitação conhecida que está sendo removida.
Esta restrição não se aplica a registos auxiliares que usam transformações.
| Passo | Propriedade ou função | Comentários |
|---|---|---|
| Registro criado na fonte de dados | HoraGerada | O valor TimeGenerated não pode ser superior a dois dias antes da hora de receção ou superior a um dia no futuro. Caso contrário, o Azure Monitor Logs substitui o valor TimeGenerated pela hora de recepção efetiva. Se a fonte de dados não definir este valor, Azure Monitor Logs define o valor para o mesmo tempo que _TimeReceived. |
| Registo recebido pelo ponto final de recolha de dados | _TimeReceived | Não use este campo para filtrar grandes conjuntos de dados. Não está otimizado para processamento em massa. |
| Registro armazenado no espaço de trabalho e disponível para consultas | ingestion_time() | Use ingestion_time() se for necessário filtrar apenas os registos que foram ingeridos numa determinada janela de tempo. Nesses casos, adicione também um TimeGenerated filtro com um alcance maior. |
Medir a latência de ingestão
Mede a latência de um registo específico ao comparar o resultado da função ingestion_time() com a propriedade TimeGenerated. Descubra como a latência de ingestão se comporta quando utiliza várias agregações destes dados. Examine algum percentil do tempo de ingestão para obter insights para grandes quantidades de dados.
Por exemplo, a seguinte consulta mostra quais os computadores que tiveram o maior tempo de ingestão nas oito 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 análises de percentis anteriores são boas para identificar 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 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
Use a mesma lógica de consulta para diagnosticar condições de latência para métricas baseadas em log do Application Insights:
// Workspace-based Application Insights schema
// This query can be paired with any other Application Insights table other than "requests"
let start=datetime("2026-01-21 05:00:00");
let end=datetime("2026-01-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
Recursos que param de responder
Em alguns casos, um recurso deixa de enviar dados. Para perceber se um recurso está a enviar dados, verifique o seu registo mais recente, que o campo padrão TimeGenerated identifica.
Usa a Heartbeat tabela para verificar a disponibilidade de uma VM porque o agente envia um batimento cardíaco uma vez por minuto. Use a seguinte consulta para listar os computadores ativos que não reportaram um batimento cardíaco 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 acordo de nível de serviço para Azure Monitor.