Compartir vía


Configuración del entorno de ejecución de integración autohospedado (SHIR) para la recopilación de análisis de registros

SE APLICA A: Azure Data Factory Azure Synapse Analytics

Sugerencia

Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. Obtenga información sobre cómo iniciar una nueva evaluación gratuita.

Prerrequisitos

Para este enfoque se necesita un área de trabajo de Log Analytics disponible. Se recomienda que anote el identificador del área de trabajo y la clave de autenticación del área de trabajo de Log Analytics, ya que es posible que los necesite para determinados escenarios. Esta solución aumentará los datos que se enviarán al área de trabajo de Log Analytics y tendrá un pequeño impacto en el costo general. Siga leyendo para obtener más información sobre cómo mantener la cantidad de datos al mínimo.

Objetivos y escenarios

Centralice los eventos y los datos del contador de rendimiento en el área de trabajo de Log Analytics; en primer lugar, la máquina virtual que hospeda el SHIR debe instrumentarse correctamente. Elija entre dos escenarios principales a continuación.

Instrumentación de máquinas virtuales locales

En el artículo Instalación del agente de Log Analytics en equipos Windows se describe cómo instalar el cliente en una máquina virtual hospedada normalmente en el entorno local. Puede ser un servidor físico o una máquina virtual hospedada en un hipervisor administrado por el cliente. Como se mencionó en la sección de requisitos previos, al instalar el agente de Log Analytics, tendrá que proporcionar el identificador del área de trabajo de Log Analytics y la clave del área de trabajo para finalizar la conexión.

Instrumentación de máquinas virtuales de Azure

El enfoque recomendado para instrumentar un SHIR basado en máquinas virtuales de Azure es usar la información de la máquina virtual, tal como se describe en el artículo Introducción a la habilitación de la información de la máquina virtual. Hay varias maneras de configurar el agente de Log Analytics cuando el SHIR se hospeda en una máquina virtual de Azure. Todas las opciones se describen en el artículo Introducción al agente de Log Analytics.

Configuración del registro de eventos y la captura del contador de rendimiento

En este paso se resalta cómo configurar los registros del visor de eventos y los contadores de rendimiento que se van a enviar a Log Analytics. Los pasos que se describen a continuación son comunes, independientemente de cómo se haya implementado el agente.

Selección de los diarios del visor de eventos

En primer lugar, debe recopilar los diarios del visor de eventos correspondientes a SHIR, tal y como se describe en el artículo Recopilación de orígenes de datos del registro de eventos de Windows con el agente de Log Analytics en Azure Monitor.

Es importante tener en cuenta que, al elegir los registros de eventos mediante la interfaz, es normal que no vea todos los diarios que puedan existir en una máquina. Por lo tanto, los dos diarios que necesitamos para la supervisión de SHIR no se mostrarán en esta lista. Si escribe el nombre del diario exactamente como aparece en la máquina virtual local, se capturará y enviará al área de trabajo de Log Analytics.

El nombre del diario de eventos que se debe configurar es el siguiente:

  • Conectores: Integration Runtime
  • Integration Runtime

Captura de pantalla de la selección de los registros pertinentes de SHIR con errores y advertencias activadas.

Importante

Si deja activado el nivel de información, aumentará significativamente el volumen de datos si tiene muchos hosts SHIR implementados y un mayor número de exámenes. Le recomendamos encarecidamente que mantenga solo Error y Advertencia.

Selección de los contadores de rendimiento

En el mismo panel de configuración, puede hacer clic en Contadores de rendimiento de Windows para seleccionar contadores de rendimiento individuales para enviarlos a Log Analytics.

Importante

Tenga en cuenta que los contadores de rendimiento son, por su naturaleza, un flujo de datos continuo. Por lo tanto, es fundamental tener en cuenta el impacto de la recopilación de datos en el costo total de la implementación de Azure Monitor o Log Analytics. A menos que se haya concedido un presupuesto de ingesta de datos permitido y se haya permitido y presupuestado una ingesta de datos constante, la recopilación de contadores de rendimiento solo debe configurarse durante un período definido para establecer una línea base de rendimiento.

En la interfaz, al configurarla por primera vez, se recomienda un conjunto de contadores sugerido. Seleccione los que se aplican al tipo de análisis de rendimiento que desea realizar. % de CPU y Memoria disponible son contadores supervisados normalmente, pero otros como el consumo de ancho de banda de red pueden ser útiles en escenarios donde el volumen de datos es grande y el ancho de banda o el tiempo de ejecución están restringidos.

Captura de pantalla de la interfaz de selección de contadores en Azure Portal.

Visualización de eventos y datos del contador de rendimiento en Log Analytics

Para obtener más información sobre cómo analizar datos de supervisión en el almacén de registros de Azure Monitor o Log Analytics mediante el lenguaje de consulta Kusto (KQL), vea consultas de Kusto.

Las dos tablas donde se guarda la telemetría se denominan Perf y Event, respectivamente. La consulta siguiente comprueba el recuento de filas para ver si hay datos que fluyen. Esto confirma si la instrumentación descrita anteriormente funciona.

Consultas de KQL de ejemplo

Comprobación de recuentos de filas

(
        Event 
        | extend TableName = "Event"
        | summarize count() by TableName
)     
| union
(     
        Perf
        | extend TableName = "Perf"
        | summarize count() by TableName
)

Consulta de eventos

Recuperación de las 10 primeras filas de eventos
Event
| take 10
Recuperación del recuento de eventos por gravedad del mensaje
Event
| summarize count() by EventLevelName
Representación de un gráfico circular de recuento por gravedad del mensaje
Event
| summarize count() by EventLevelName
| render piechart 
Recuperación de todos los errores con una cadena de texto determinada

Aquí buscamos todos los mensajes que tienen la palabra desconectado.

Event
| where RenderedDescription has "disconnected"
Búsqueda de varias tablas para una palabra clave sin conocer el esquema

El comando de búsqueda es útil cuando no se sabe en qué columna se encuentra la información. Esta consulta devuelve todas las filas de las tablas especificadas que tienen al menos una columna que contiene el término de búsqueda. La palabra es desconectado en este ejemplo.

search in (Perf, Event) "disconnected"
Recuperación de todos los eventos de un diario de registro específico

En este ejemplo, vamos a restringir la consulta al diario de registro denominado Conectores: Integration Runtime.

Event 
| where EventLog == "Connectors - Integration Runtime"
Uso de los intervalos de tiempo para restringir los resultados de la consulta

Esta consulta usa la misma consulta que la anterior, pero restringe los resultados a los que se han producido hace 2 días o más recientemente.

Event 
| where EventLog      == "Connectors - Integration Runtime"
  and   TimeGenerated >= ago(2d)

consultar datos de contadores de rendimiento

Recuperación de las 10 primeras lecturas del contador de rendimiento
Perf
| take 10
Recuperación de un contador específico con restricciones de tiempo
Perf
| where     TimeGenerated >= ago(24h)
        and ObjectName    == "Network Adapter"
        and InstanceName  == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
        and CounterName   == "Bytes Received/sec"

Los contadores de rendimiento son jerárquicos por naturaleza, por lo que debe tener suficientes predicados where en la consulta para seleccionar solo el contador específico que necesita.

Recuperación del percentil 95 para un contador determinado que se ha discretizado por segmentos de 30 minutos de las últimas 24 horas

Este ejemplo consiste en todos los contadores de un adaptador de red específico.

Perf
| where     TimeGenerated >= ago(24h)
        and ObjectName    == "Network Adapter"
        and InstanceName  == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
| project TimeGenerated, Computer, ObjectName, InstanceName, CounterName, CounterValue
| summarize percentile(CounterValue, 95) by bin(TimeGenerated, 30m), Computer, ObjectName, InstanceName, CounterName
Uso de variables para la reusabilidad del código

Aquí estamos haciendo que el nombre del objeto y el nombre del contador sean una variable, por lo que no es necesario cambiar el cuerpo de la consulta KQL para realizar cambios en esas selecciones más adelante.

let pObjectName  = "Memory"; // Required to select the right counter
let pCounterName = "Available MBytes"; // Required to select the right counter
Perf
| where Type == "Perf" and ObjectName == pObjectName and CounterName == pCounterName
| project TimeGenerated, Computer, CounterName, CounterValue
| order by TimeGenerated asc 
| summarize Value=max(CounterValue) by CounterName, TimeStamps=TimeGenerated