Tiempo de la ingesta de datos de registro en Azure Monitor

  • Artículo

Azure Monitor es un servicio de datos a gran escala que atiende a miles de clientes que envían terabytes de datos cada mes a un ritmo creciente. Con frecuencia se plantean preguntas sobre el tiempo necesario para que los datos de registro estén disponibles una vez que se han recopilado. En este artículo se explican los distintos factores que afectan a esta latencia.

Latencia promedio

La latencia hace referencia al momento en el que los datos se crean en el sistema supervisado y el momento en el que están disponibles para su análisis en Azure Monitor. La latencia promedio para ingerir datos de registro es de entre 20 segundos y 3 minutos. La latencia específica para cualquier dato determinado variará en función de una serie de factores que se explican en este artículo.

Factores que afectan a la latencia

El tiempo total de ingesta para un conjunto determinado de datos puede dividirse en las siguientes áreas de alto nivel:

  • Tiempo del agente: el tiempo para descubrir un evento, recopilarlo y luego enviarlo a un punto de conexión de recopilación de datos como un registro. En la mayoría de los casos, este proceso se controla mediante un agente. La red podría introducir más latencia.
  • Tiempo de canalización: se trata del tiempo que le lleva a la canalización de ingesta procesar la entrada del registro. En este tiempo se incluye el análisis de las propiedades del evento y la incorporación potencial de información calculada.
  • Tiempo de indexación: es el tiempo dedicado a la ingesta de una entrada de registro en un almacén de macrodatos de Azure Monitor.

En las secciones siguientes se describen los detalles de las diferentes latencias que se presentan en este proceso.

Latencia de la recopilación de agente

El tiempo varía

Los agentes y las soluciones de administración usan diferentes estrategias para recopilar datos de una máquina virtual, lo que podría afectar a la latencia. En la tabla siguiente se muestran algunos ejemplos específicos.

Tipo de datos Frecuencia de recopilación Notas
Eventos de Windows, eventos de Syslog y métricas de rendimiento Se recopilan inmediatamente.
Contadores de rendimiento de Linux Se sondean a intervalos de 30 segundos.
Registros de texto y registros de IIS Se recopilan después de que cambie su marca de tiempo. Para los registros de IIS, esta programación viene determinada por la programación de sustitución configurada en IIS.
Solución de Active Directory Replication Se evalúa cada cinco días. El agente recopila los registros solo cuando se completa la evaluación.
Solución de Active Directory Assessment Se evalúa la infraestructura de Active Directory semanalmente. El agente recopila los registros solo cuando se completa la evaluación.

Frecuencia de carga del agente

Menos de 1 minuto

Para asegurarse de que el agente de Log Analytics es ligero, el agente almacena en búfer los registros y los carga periódicamente en Azure Monitor. La frecuencia de carga varía entre 30 segundos y 2 minutos, según el tipo de datos. La mayoría de los datos se carga en menos de 1 minuto.

Red

Varía

Las condiciones de red pueden afectar negativamente a la latencia de estos datos para alcanzar un punto de conexión de recopilación de datos.

Métricas de Azure, registros de recursos, registro de actividad

De 30 segundos hasta 15 minutos

Los datos de Azure agregan más tiempo para estar disponibles en un punto de conexión de recopilación de datos para su procesamiento:

  • Las métricas de la plataforma Azure están disponibles en menos de un minuto en la base de datos de métricas, pero tardan 3 minutos más en exportarse al punto de conexión de recopilación de datos.
  • Normalmente, los registros de recursos agregan entre 30 y 90 segundos, según el servicio de Azure. Algunos servicios de Azure (específicamente, Azure SQL Database y Azure Virtual Network) notifican actualmente sus registros a intervalos de cinco minutos. Se está trabajando para mejorar este tiempo aún más. Para examinar esta latencia en su entorno, vea esta consulta.
  • Los registros de actividad están disponibles para el análisis en un plazo de 3 a 10 minutos.

Recopilación de las soluciones de administración

Varía

Algunas soluciones no recopilan los datos de un agente y podrían usar un método de recopilación que introduce más latencia. Algunas soluciones recopilan los datos a intervalos regulares sin intentar la recopilación casi en tiempo real. A continuación se muestran algunos ejemplos específicos:

  • La solución Microsoft 365 sondea los registros de actividad mediante la API de actividad de administración, que actualmente no proporciona garantías de latencia casi en tiempo real.
  • Los datos de las soluciones de Windows Analytics (Update Compliance, por ejemplo) se recopilan con una frecuencia diaria por la solución.

Para determinar la frecuencia de recopilación de una solución, consulte la documentación de cada solución.

Tiempo del proceso de canalización

De 30 a 60 segundos

Una vez que los datos están disponibles en el punto de conexión de recopilación de datos, tardan otros 30 a 60 segundos en estar disponibles para su consulta.

Una vez que las entradas de registro se han ingerido en la canalización de Azure Monitor (como se indica en la propiedad _TimeReceived), se escriben en un almacenamiento temporal para garantizar el aislamiento de inquilinos y para asegurarse de que no se pierden datos. Normalmente, este proceso agrega de 5 a 15 segundos.

Algunas soluciones implementan algoritmos más pesados para agregar datos y obtener perspectivas a medida que los datos van entrando. Por ejemplo, Application Insights calcula los datos del mapa de aplicación; Azure Network Performance Monitor agrega los datos de entrada en intervalos de tres minutos, lo que agrega una latencia de tres minutos.

Si la recopilación de datos incluye una transformación en tiempo de ingesta, esto agregará cierta latencia a la canalización. Use la métrica Duración de la transformación de registros por minuto para supervisar la eficacia de la consulta de transformación.

Otro proceso que agrega latencia es el proceso que controla los registros personalizados. En algunos casos, este proceso puede agregar algunos minutos de latencia a los registros que el agente recopila de los archivos.

Aprovisionamiento de nuevos tipos de datos personalizados

Cuando se crea un nuevo tipo de datos personalizados desde un registro personalizado o la API del recopilador de datos, el sistema crea un contenedor de almacenamiento dedicado. Esta sobrecarga de un solo uso se produce solo con la primera aparición de este tipo de datos.

Protección para los picos de datos

Normalmente menos de un minuto, pero puede ser más

La máxima prioridad de Azure Monitor es asegurarse de que no se pierda ningún dato de cliente, por ello el sistema tiene protección integrada para los picos en los que los datos aumentan. Esta protección incluye los búferes para asegurarse de que incluso con una carga enorme, el sistema seguirá funcionando. Bajo una carga normal, estos controles agregan menos de un minuto. En condiciones extremas y con errores, pueden agregar un tiempo considerable mientras se aseguran de que los datos no se pierdan.

Tiempo de indexación

5 minutos como máximo

Hay un equilibrio integrado para cada plataforma de macrodatos entre, por un lado, proporcionar análisis y funcionalidades de búsqueda avanzada y, por otro, proporcionar acceso inmediato a los datos. Con Azure Monitor, puede ejecutar consultas muy eficaces en miles de millones de registros y obtener resultados en cuestión de segundos. Este rendimiento es posible porque la infraestructura transforma los datos de forma drástica durante su ingesta y los almacena en estructuras compactas únicas. El sistema almacena en búfer los datos hasta que haya disponibles los suficientes para crear estas estructuras. Este proceso se tiene que completar antes de que aparezca la entrada de registro en los resultados de búsqueda.

Actualmente, este proceso tarda aproximadamente cinco minutos cuando hay bajo volumen de datos, pero podría tardar menos con una frecuencia de datos más alta. Este comportamiento parece contradictorio, pero este proceso permite la optimización de la latencia para cargas de trabajo de producción de gran volumen.

Comprobación del tiempo de ingesta

El tiempo de ingesta podría variar para diferentes recursos en diferentes circunstancias. Puede usar consultas de registro para identificar el comportamiento específico de su entorno. En la tabla siguiente se especifica cómo se pueden determinar los distintos tiempos de un registro a medida que se crea y se envía a Azure Monitor.

Paso Propiedad o función Comentarios
Registro creado en el origen de datos TimeGenerated
Si el origen de datos no establece este valor, se establecerá en el mismo tiempo que _TimeReceived.		 Si durante el tiempo de procesamiento el valor de TimeGenerated es anterior a dos días, se descartará la fila.
Registro recibido por el punto de conexión de recopilación de datos _TimeReceived Este campo no está optimizado para el procesamiento masivo y no debe usarse para filtrar grandes conjuntos de datos.
Registro almacenado en el área de trabajo y disponible para las consultas. ingestion_time() Se recomienda usar ingestion_time() si hay necesidad de filtrar solo los registros ingeridos en un período de tiempo determinado. En tales casos, también se recomienda agregar un filtro TimeGenerated con un intervalo mayor.

Retrasos de latencia de la ingesta

Puede medir la latencia de un registro específico si compara el resultado de la función ingestion_time() con la propiedad TimeGenerated. Estos datos se pueden usar con diversas agregaciones para conocer el funcionamiento de la latencia de ingesta. Examine algunos percentiles del tiempo de ingesta para obtener información de grandes cantidades de datos.

Por ejemplo, la consulta siguiente muestra los equipos que tenían el mayor tiempo de ingesta durante las ocho 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

Las comprobaciones de percentiles anteriores son adecuadas para buscar tendencias generales en la latencia. Para identificar un pico a corto plazo en la latencia, puede resultar más eficaz usar el máximo (max()).

Si quiere profundizar en el tiempo de ingesta de un equipo específico durante un período de tiempo, use la siguiente consulta, que también visualiza los datos del día anterior en un 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 la consulta siguiente para mostrar la hora de ingesta del equipo por el país o región en el que está ubicado, según su dirección 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

Los diferentes tipos de datos que se originan desde el agente pueden tener diferentes horas de latencia de ingestión, por lo que las consultas anteriores se pueden usar con otros tipos. Use la siguiente consulta para examinar la hora de la ingesta de diversos servicios de 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 la misma lógica de consulta para diagnosticar las condiciones de latencia de los datos de 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

Las dos consultas anteriores se pueden emparejar con cualquier otra tabla de Application Insights que no sea "solicitudes".

Recursos que dejan de responder

En algunos casos, un recurso pudo detener el envío de datos. Para saber si un recurso está enviando datos o no, examine su registro más reciente, que puede identificarse por el campo TimeGenerated estándar.

Use la tabla Heartbeat para comprobar la disponibilidad de una máquina virtual, puesto que el agente envía un latido una vez por minuto. Use la siguiente consulta para mostrar una lista de los equipos activos que no han comunicado latidos recientemente:

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

Pasos siguientes

Lea el contrato de nivel de servicio de Azure Monitor.