Transformaciones en Azure Monitor

Las transformaciones de Azure Monitor filtran o modifican los datos entrantes antes de enviarlos a un área de trabajo de Log Analytics. Las transformaciones se ejecutan después de que el origen de datos entregue los datos y antes de enviarlos al destino. Se definen en una regla de recopilación de datos (DCR).

Las transformaciones estándar usan una instrucción del lenguaje de consulta kusto (KQL) aplicada individualmente a cada entrada de los datos entrantes. Las transformaciones de varias fases amplían este modelo con una canalización de procesadores declarativos, donde una consulta KQL es uno de muchos tipos de procesador disponibles en la cadena de transformación.

En el diagrama siguiente se muestra el proceso de transformación de los datos entrantes y se muestra una consulta de ejemplo que se puede usar. En este ejemplo, solo se recopilan los registros en los que la columna message contiene la palabra error.

Tablas admitidas

Las tablas siguientes de un área de trabajo de Log Analytics admiten transformaciones.

Cualquier tabla de Azure que aparezca en Tablas que admitan transformaciones en los registros de Azure Monitor. La referencia de datos Azure Monitor también incluye si la tabla admite transformaciones y enumera otros atributos para cada tabla.
Cualquier tabla personalizada creada para el agente de Azure Monitor.
Tablas personalizadas con el plan auxiliar.

Creación de una transformación

Algunos escenarios de recopilación de datos admiten la adición de una transformación a través del portal de Azure, pero la mayoría de los escenarios requieren la creación de un controlador de dominio nuevo mediante su definición JSON o la adición de una transformación a un DCR existente. Consulte Crear una transformación en Azure Monitor para conocer las distintas opciones y Procedimientos recomendados y ejemplos de transformaciones en Azure Monitor para consultar ejemplos de consultas de transformación para escenarios habituales.

Transformaciones de varias fases (versión preliminar)

Importante

Las transformaciones de varias fases se encuentran actualmente en versión preliminar pública. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Las transformaciones estándar aplican una única consulta KQL a los datos entrantes durante la ingesta. Las transformaciones de varias fases amplían este modelo al permitirle definir una canalización de procesamiento compuesta de varias fases de procesamiento ordenadas, aplicadas como flujos de datos a través del sistema.

Con las transformaciones de varias fases, un DCR define una canalización de procesamiento de datos en lugar de un solo paso de transformación. Los datos fluyen por las siguientes fases:

Recogida de datos. Azure Monitor Agent (AMA) recopila datos del recurso en función de la configuración del origen de datos en el DCR.
Procesamiento del lado cliente. Las transformaciones se ejecutan localmente en el agente antes de que los datos se envíen a través de la red. La transformación se aplica a los datos en su forma sin procesar, lo que podría diferir de la representación de tabla estándar.
Procesamiento en el momento de la ingestión. Después de que los datos alcancen Azure Monitor, las transformaciones se aplican durante la ingesta antes de que los datos se escriban en su tabla de destino en Log Analytics. Esta transformación se aplica después de que los datos estén completamente esquematizados y enriquecidos.
Entrega de datos. Los registros procesados se entregan a su destino final.

Procesadores

Las transformaciones en DCR de varias fases se definen utilizando procesadores: bloques modulares pequeños y declarativos, cada uno de los cuales realiza un tipo específico de operación. Los procesadores tienen las siguientes características:

Compatibilidad con la composición. Varios procesadores se pueden encadenar juntos en una sola transformación.
Realizado. Los procesadores se ejecutan secuencialmente en el orden definido en la transformación.
Independiente de la fase. El mismo tipo de procesador se puede usar en diferentes orígenes de datos, fases o escenarios, con algunas limitaciones durante la versión preliminar.

Cada transformación comienza con un procesador de encabezados que convierte datos sin procesar en un formato tabular esquematizado conocido. Después del encabezado, puede encadenar procesadores adicionales para filtrar, asignar, analizar, agregar, enriquecer o aplicar expresiones KQL a los datos.

Están disponibles las siguientes familias de procesadores:

Familia	Procesadores	Description
Cabecera	`header.Syslog`, `header.WindowsEvents`, `header.TextLog`, `header.StandardStream`, `header.CustomStream`, y otros	Esquematizar datos sin procesar en un formato tabular. Debe ser el primer procesador.
Filter	`filter.Basic`	Elimina registros en función de la evaluación de una condición.
Map	`map.Rename`, `map.Drop`	Cambiar el nombre, definir el tipo o eliminar columnas.
Parse	`parse.JsonPath`, , `parse.XmlPath`, `parse.CEFAttribute`	Extraiga campos de cadenas con formato JSON, XML o CEF.
Agregación	`aggregate.Basic`	Resumir registros mediante operadores de agregación con dimensiones de agrupación.
Enriquecimiento	`enrich.DNSLookup`	Busque una dirección IP y agregue una columna de nombre DNS.
Transformación personalizada	`transform.KQL`	Aplique una expresión KQL arbitraria. Solo del lado de la ingesta.

Para obtener la referencia completa del procesador, incluidos los esquemas de configuración y los esquemas de salida, consulte Estructura DCR: Transformaciones.

Transformaciones del lado cliente frente a transformaciones del lado de ingesta

Cada transformación se asigna a una fase de procesamiento específica. Esta distinción determina dónde se produce el proceso, qué datos se envían a través de la red y qué costos se pueden optimizar antes.

Aspecto	Client-side	Tiempo de ingesta
Asignación	Origen de datos (`dataSources`)	Flujo de datos (`dataFlows`)
Se ejecuta en	Agente de Azure Monitor (VM)	servicio Azure Monitor
Procesador de encabezados	Específico del origen de datos (por ejemplo, `header.Syslog`)	`header.StandardStream` o `header.CustomStream`
Ventaja del costo	Reduce los costos de red y ingesta mediante el filtrado o la agregación antes de que los datos abandonen el recurso.	Se aplica después de que los datos se esquematizan y enriquecen con columnas de tabla adicionales.

Un único DCR puede combinar transformaciones en tiempo de ingesta y del lado cliente. La salida de la fase del lado cliente se convierte automáticamente en la entrada de la fase de tiempo de ingesta.

Consideraciones sobre DCR multietapa

Las transformaciones de varias fases requieren una versión 2025-05-11 de API o posterior. La sección transformations y la propiedad transform de los orígenes de datos y los flujos de datos no son reconocidas por las versiones anteriores de la API.
La propiedad transform es mutuamente excluyente con transformKql en cada flujo de datos. Un DCR puede mezclar flujos de datos antiguos y nuevos entre distintos flujos.
En la vista previa, debe coordinar manualmente el encabezado de la transformación posterior con la salida de la transformación anterior. Por ejemplo, si se aplica una agregación a un flujo sin procesar de eventos de Windows, es posible que el resultado no sea compatible con la tabla Event correspondiente, y la transformación en el momento de la ingesta debe comenzar con un encabezado de flujo personalizado.

Enfoque de diseño para el procesamiento de varias fases

Siga estos pasos al diseñar un DCR de varias fases:

Evaluar orígenes de datos y destinos. Identifique los tipos de origen de datos y decida dónde se encuentra cada uno: la tabla estándar predeterminada o una tabla personalizada.
Identificar las necesidades de agregación. Los registros agregados deben ir a una tabla independiente porque su forma difiere del formulario sin procesar.
Planifique el procesamiento diferencial. Si necesita procesar partes de los mismos registros de forma diferente, cree varios orígenes de datos del mismo tipo con diferentes configuraciones de recopilación y aplique transformaciones del lado cliente diferentes a cada uno.
Cree transformaciones del lado del cliente. Use secuencias estándar (Microsoft-*) si la salida conserva el esquema de encabezado o secuencias personalizadas (Custom-*) si no lo hace. Defina secuencias personalizadas en streamDeclarations.
Definir flujos de datos. Para cada flujo, cree un flujo de datos. Use flujos de datos en tiempo de ingesta para dividir un único flujo en varias tablas de destino aplicando distintos criterios de filtro por flujo de datos.

DCR de transformación del área de trabajo

Las transformaciones se definen en una regla de recopilación de datos (DCR), pero todavía hay colecciones de datos en Azure Monitor que aún no usan un DCR. Entre los ejemplos se incluyen los registros de recursos recopilados por la configuración de diagnóstico y los datos de la aplicación recopilados por Application Insights.

La regla de recopilación de datos de transformación del área de trabajo (DCR) es un DCR especial que se aplica directamente a un área de trabajo de Log Analytics. El propósito de este DCR es realizar transformaciones en los datos que aún no usan un DCR para su recopilación de datos y, por tanto, no tiene ningún medio para definir una transformación.

Solo puede haber una DCR de área de trabajo para cada área de trabajo, pero puede incluir transformaciones para cualquier número de tablas admitidas. Estas transformaciones se aplican a todos los datos enviados a estas tablas a menos que esos datos procedan de otro DCR.

Por ejemplo, la tabla Event se usa para almacenar eventos de máquinas virtuales Windows. Si crea una transformación en el DCR de transformación del área de trabajo para la tabla Event, se aplicará a los eventos recopilados por las máquinas virtuales que ejecutan el agente de Log Analytics¹ porque este agente no usa un DCR. La transformación se omitiría aunque cualquier dato enviado desde el Agente de Azure Monitor (AMA) porque usa un DCR para definir su recopilación de datos. Todavía puede usar una transformación con el agente de Azure Monitor, pero incluiría esa transformación en el DCR asociado al agente y no al DCR de transformación del área de trabajo.

¹ El agente de Log Analytics ha quedado en desuso, pero algunos entornos podrían seguir utilizándolo. Solo es un ejemplo de un origen de datos que no usa un DCR.

Transformaciones de canalización de Azure Monitor

Las transformaciones de datos de la canalización de Azure Monitor ofrecen una funcionalidad similar a la de las transformaciones en el lado cliente de Azure Monitor. Ambos permiten aplicar una consulta KQL a los datos entrantes para filtrar o modificar esos datos antes de enviarlos al siguiente paso del flujo de datos.

Las transformaciones en tiempo de ingesta de Azure Monitor se ejecutan después de que Azure Monitor reciba los datos, pero antes de que se ingieran en el área de trabajo de Log Analytics. Las transformaciones de canalización de Azure Monitor se aplican anteriormente en el flujo de datos, lo que permite dar forma y filtrar datos antes de que los datos se envíen a Azure Monitor. Esto hace que las transformaciones de canalización sean útiles para reducir el volumen de datos y el ancho de banda de red al enviar datos desde entornos perimetrales o multinube.

En la tabla siguiente se resumen las diferencias clave entre las transformaciones de la canalización de Azure Monitor y las transformaciones en el momento de la ingesta de Azure Monitor:

Característica	Transformaciones de canalización de Azure Monitor	Transformaciones durante la ingesta en Azure Monitor
Cuando se aplica	Antes de enviar datos a Azure Monitor	Una vez recibidos los datos por Azure Monitor. Antes de almacenarlo en el área de trabajo de Log Analytics
Definición	Se define en flujos de datos en la canalización de Azure Monitor	Definido en Reglas de recopilación de datos (DCR) en Azure Monitor
Language	Lenguaje de consulta de Kusto (KQL)	Lenguaje de consulta de Kusto (KQL)
¿Se admiten agregaciones?	Sí	No
¿Se admite la plantilla?	Sí	No

Los datos que se ingieren en Azure Monitor son una combinación de la transformación de la canalización y las transformaciones en el tiempo de la ingesta posteriores de Azure Monitor. El único requisito es que el esquema de salida de la transformación de la canalización debe coincidir con el esquema de entrada esperado por la transformación en tiempo de ingesta de Azure Monitor. Aunque puede filtrar los datos en cualquier transformación, suele ser más eficaz filtrar los datos en las transformaciones de canalización, ya que esto reduce la cantidad de datos enviados a través de la red. El esquema de los datos generados por la transformación en el momento de la ingesta de Azure Monitor debe coincidir con el de la tabla de destino en el área de trabajo de Log Analytics.

Coste de las transformaciones

Los registros de procesamiento (transformación y filtrado) en la canalización en la nube de Azure Monitor tienen diferentes implicaciones de facturación en función del tipo de tabla en el que se ingieren datos en un área de trabajo de Log Analytics.

Registros auxiliares

Los registros auxiliares asignan un costo para los datos procesados y los datos ingeridos en un área de trabajo de Log Analytics. El cargo de procesamiento de datos se aplica a todos los datos entrantes recibidos por el Azure Monitor si el destino de un área de trabajo de Log Analytics es una tabla de registros auxiliares. Esto incluye la cantidad de datos procesados por cualquier transformación en el momento de la ingesta de Azure Monitor. El cargo por la ingesta de datos solo se aplica a los datos tras la transformación en el momento de la ingesta, enviados a una tabla Registros auxiliares. Las transformaciones pueden aumentar o disminuir el tamaño de los datos.

La siguiente tabla muestra algunos ejemplos:

Tamaño de los datos entrantes	Datos eliminados o agregados por transformación	Datos integrados en un espacio de trabajo de Log Analytics como una tabla de registros auxiliares	GB facturables de procesamiento de datos	GB facturables por ingestión de datos
20 GB	12 GB perdidos	8 GB	20 GB	8 GB
20 GB	8 GB descartados	12 GB	20 GB	12 GB
20 GB	Se han agregado 4 GB	24 GB	20 GB	24 GB

Consulte Precios de Azure Monitor para conocer los precios de la ingesta de datos de registro y procesamiento de registros.

Análisis o registros básicos

En el caso de los registros básicos o de Análisis, las transformaciones no suelen incurrir en costos, pero los escenarios siguientes pueden dar lugar a cargos adicionales:

Si una transformación aumenta el tamaño de los datos entrantes, por ejemplo, agregando una columna calculada, se le cobrará la tasa de ingesta estándar de los datos adicionales.
Si una transformación reduce los datos ingeridos en más de 50%, se le cobra por la cantidad de datos filtrados por encima de 50%.

Para calcular el cargo de procesamiento de datos resultante de las transformaciones, use la fórmula siguiente:

[GB de datos descartados por transformación] - ([GB de tamaño de datos entrantes] / 2).

En la tabla siguiente se muestran ejemplos.

Tamaño de los datos entrantes	Datos eliminados o agregados por transformación	Datos ingeridos en un área de trabajo de Log Analytics como una tabla de registros básicos o de análisis	GB facturables de procesamiento de datos	GB facturables por ingestión de datos
20 GB	12 GB perdidos	8 GB	2 GB	8 GB
20 GB	8 GB descartados	12 GB	0 GB	12 GB
20 GB	Se han agregado 4 GB	24 GB	0 GB	24 GB

Para evitar este cargo, debería filtrar los datos ingeridos mediante métodos alternativos antes de aplicar transformaciones. Al hacerlo, puede reducir la cantidad de datos procesados por transformaciones y, por lo tanto, minimizar los costos adicionales.

Consulte Precios de Azure Monitor para obtener precios para el procesamiento de registros y la ingesta de datos de registro.