Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Monitor es un servicio de datos a gran escala que envía terabytes de datos cada mes y continúa creciendo. En las operaciones normales de servicio, el tiempo que tardan en estar disponibles los datos de registro después de su recopilación es predecible y coherente. En este artículo se explican los factores que afectan a esta latencia.
Latencia promedio
La latencia hace referencia al tiempo entre el momento en que se crean los datos en el sistema supervisado y cuándo está disponible para el análisis en Azure Monitor. La latencia media para ingerir datos de registro es inferior a 10 segundos. La latencia específica de los datos concretos varía en función de varios factores que se explican en este artículo.
Factores que afectan a la latencia
El tiempo total de ingesta de un conjunto determinado de datos es el tiempo acumulado del cliente al servicio Azure Monitor.
Diagrama de arquitectura que muestra el proceso de ingesta de Azure Monitor.
- Hora del cliente: la hora de detectar un evento, recopilarlo y enviarlo a un punto de conexión de recopilación de datos como registro. En la mayoría de los casos, un agente como Azure Monitor Agent (AMA) controla este proceso. Las aplicaciones personalizadas que usan la API de ingesta de registros no forman parte de los cálculos de este artículo, pero pueden tener sus propias características de latencia similares al tiempo del cliente AMA.
- Tiempo de Azure Monitor: una vez que el cliente entrega a Azure Monitor, se mide el tiempo de ingesta para procesar el registro. En este tiempo se incluye el análisis de las propiedades del evento y la incorporación potencial de información calculada.
En las secciones siguientes se describen las distintas latencias introducidas en este proceso.
Latencia de la recopilación de agente
Latencia: el tiempo varía
Los agentes usan estrategias diferentes para recopilar datos, 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 rotación configurada en IIS. |
Para obtener más información sobre el rendimiento del agente, consulte Azure Supervisar el rendimiento del agente.
Frecuencia de carga del agente
Latencia: menos de 1 minuto
Para mantener ligero el agente de Azure Monitor, 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
Latencia: varía
La red entre un cliente y el punto de conexión de recopilación de datos de Azure Monitor puede agregar retrasos inesperados. Al medir la latencia de ingesta, esta latencia de red se incluye como parte del cálculo en las AgentLatency consultas de ejemplo en la sección medir la latencia de ingesta.
métricas de Azure, registros de recursos, registros de actividad
Latencia: 30 segundos a 20 minutos
Azure tarda más en que los datos estén disponibles en un punto de recolección de datos para su procesamiento.
- Métricas de la plataforma Azure están disponibles en menos de un minuto en la base de datos de métricas, pero tardan otros tres minutos en exportarse al punto de recogida de datos.
- Registros de recursos normalmente están disponibles en un plazo de 3 a 10 minutos de un extremo a otro, en función de la complejidad del servicio y de los servicios de Azure implicados. Por ejemplo, Azure SQL Database y Azure Virtual Network proporcionan actualmente sus registros cada cinco minutos. Para examinar esta latencia en su entorno, vea esta consulta.
- Los Registros de actividad están disponibles para su análisis y alerta en un plazo de 3 a 20 minutos.
Azure Monitor tiempo de proceso
Latencia: menos de 10 segundos
Después de que los datos lleguen al punto de conexión de recopilación, tardan menos de 10 segundos en que se puedan consultar.
Cuando Azure Monitor ingiere registros de registro (como se muestra en la propiedad _TimeReceived), los escribe en storage temporales. Este paso garantiza el aislamiento de inquilinos y evita la pérdida de datos. Este paso suele agregar de 5 a 15 segundos.
Algunas soluciones usan algoritmos más complejos para agregar datos y derivar información mientras se transmiten los datos. Por ejemplo, Application Insights calcula los datos del mapa de la aplicación. Azure Network Performance Monitoring agrega datos entrantes durante intervalos de tres minutos, lo que agrega eficazmente tres minutos de latencia en este caso.
Si la recopilación de datos incluye una transformación ingestion-time, esta transformación agrega cierta latencia al tiempo de proceso Azure Monitor. 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 podría agregar unos minutos de latencia a los registros que un agente recopila de archivos.
Aprovisionamiento de nuevos tipos de datos personalizados
Cuando se crea un nuevo tipo de datos personalizados a partir de un registro custom o la API de ingesta de Logs, el sistema crea un contenedor de storage dedicado. Esta sobrecarga única ocurre solo la primera vez que aparece este tipo de datos.
Comprobación del tiempo de ingesta
El tiempo de ingesta podría variar para diferentes recursos en diferentes circunstancias. Use consultas de registro para identificar un comportamiento específico del entorno. En la tabla siguiente se especifica cómo se determinan las distintas horas de un registro a medida que se crean y se envían a Azure Monitor. Para más información sobre las consultas de registro, consulte Introducción a Log Analytics.
Advertencia
Al ingerir registros en el nivel auxiliar de Azure Monitor, evite enviar una sola carga que contenga marcas de tiempo TimeGenerated que abarquen más de 30 minutos en una llamada API. Esta llamada API podría provocar el siguiente código de error de ingesta RecordsTimeRangeIsMoreThan30Minutes. Se trata de una limitación conocida que se quita.
Esta restricción no se aplica a los registros auxiliares que usan transformaciones.
| Paso | Propiedad o función | Comentarios |
|---|---|---|
| Registro creado en el origen de datos | TimeGenerated | El valor TimeGenerated no puede ser más de dos días antes de la hora recibida ni más de un día en el futuro. De lo contrario, Azure Monitor Logs reemplaza el valor de TimeGenerated por el tiempo real en que se recibió. Si el origen de datos no establece este valor, Azure Monitor Logs establece el valor en la misma hora que _TimeReceived. |
| Registro recibido por el extremo de recopilación de datos | _TimeReceived | No use este campo para filtrar grandes conjuntos de datos. No está optimizado para el procesamiento masivo. |
| Registro almacenado en el área de trabajo y disponible para las consultas. | ingestion_time() | Use ingestion_time() si necesita filtrar solo los registros que se han ingerido en un período de tiempo determinado. En tales casos, agregue también un TimeGenerated filtro con un intervalo mayor. |
Medición de la latencia de ingesta
Mida la latencia de un registro específico al comparar el resultado de la función ingestion_time() con la propiedad TimeGenerated. Descubra cómo se comporta la latencia de ingesta al usar varias agregaciones de estos datos. Examine un percentil del tiempo de ingestión para obtener información sobre grandes volúmenes de datos.
Por ejemplo, la siguiente consulta muestra qué equipos tenían el tiempo de ingesta más alto 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 consulta siguiente para examinar el tiempo de ingesta de varios 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 las métricas basadas en registros de 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 dejan de responder
En algunos casos, un recurso deja de enviar datos. Para comprender si un recurso envía datos, compruebe su registro más reciente, que identifica el campo estándar TimeGenerated .
Use la tabla Heartbeat para comprobar la disponibilidad de una máquina virtual, dado 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 acuerdo de nivel de servicio para Azure Monitor.