Transformaciones de recopilación de datos en Azure Monitor
Con las transformaciones en Azure Monitor puede filtrar o modificar los datos entrantes antes de que se envíen a un área de trabajo de Log Analytics. En este artículo se proporciona una descripción básica de las transformaciones y de cómo se implementan. Proporciona vínculos a otro contenido para crear una transformación.
Por qué usar transformaciones
En la tabla siguiente se describen los distintos objetivos que se pueden conseguir con el uso de transformaciones.
| Category | Detalles |
|---|---|
| Eliminación de datos confidenciales | Es posible que tenga un origen de datos que envía información que no quiera almacenar por motivos de privacidad o cumplimiento. Filtre información confidencial. Filtre filas completas o columnas concretas que contengan información confidencial. Ofusque información confidencial. Remplaza información como los dígitos de una dirección IP o un número de teléfono por un carácter común. Envío a una tabla alternativa. Envíe registros confidenciales a una tabla alternativa con una configuración de control de acceso basado en rol diferente. |
| Enriquecimiento de datos con información adicional o calculada | Use una transformación para agregar información a los datos que proporcionan contexto empresarial o simplifican la consulta de los datos más adelante. Agregue una columna con más información. Por ejemplo, puede agregar una columna que identifique si una dirección IP de otra columna es interna o externa. Agregue información específica de la empresa. Por ejemplo, puede agregar una columna que indique una división de la empresa en función de la información de ubicación de otras columnas. |
| Reducción de los costos de datos | Puesto que se le cobra el costo de ingesta de los datos enviados a un área de trabajo de Log Analytics, para reducirlo, se recomienda filtrar los datos que no necesite. Quite filas completas. Por ejemplo, puede tener un diagnóstico para recopilar los registros de un determinado recurso, pero quizá no necesite todas las entradas de registro que genera. Cree una transformación que filtre los registros que coinciden con determinados criterios. Quite una columna de cada fila. Por ejemplo, los datos pueden incluir columnas con datos redundantes o con un valor mínimo. Cree una transformación que filtre las columnas que no son necesarias. Analice datos importantes de una columna. Es posible que tenga una tabla con datos importantes incluidos en una columna determinada. Use una transformación para analizar los datos importantes en una nueva columna y elimine la original. Enviar determinadas filas a registros básicos. Envíe filas de los datos que requieran funcionalidades de consulta básicas a tablas de registros básicas para un costo de ingesta menor. |
Tablas admitidas
Puede aplicar transformaciones a las tablas siguientes de un área de trabajo de Log Analytics:
- Cualquier tabla de Azure que aparezca en Tablas que admiten transformaciones en registros de Azure Monitor
- Cualquier tabla personalizada creada para el agente de Azure Monitor. (La tabla personalizada de MMA no puede usar transformaciones)
Funcionamiento de las transformaciones
Las transformaciones se realizan en Azure Monitor en la canalización de ingesta de datos después de que el origen de datos entregue los datos y antes de enviarlos al destino. El origen de datos puede realizar su propio filtrado antes de enviar datos, pero basarse en la transformación para manipularlos antes de enviarlos a su destino.
Las transformaciones se definen en una regla de recopilación de datos (DCR) y usan una instrucción del Lenguaje de consulta Kusto (KQL) que se aplica individualmente a cada entrada de los datos entrantes. Debe comprender el formato de los datos entrantes y crear la salida en la estructura esperada por el destino.
Por ejemplo, un DCR que recopila datos de una máquina virtual mediante el agente de Azure Monitor especificaría datos concretos para recopilar del sistema operativo cliente. También podría incluir una transformación que se aplicaría a esos datos después de enviarlos a la canalización de ingesta de datos que filtra aún más los datos o agrega una columna calculada. Consulte Creación de transformaciones de agente. En el siguiente diagrama se ilustra este flujo de trabajo.
Otro ejemplo son los datos enviados desde una aplicación personalizada mediante la API de ingesta de registros. En este caso, la aplicación envía los datos a un punto de conexión de recopilación de datos y especifica una regla de recopilación de datos en la llamada a la API REST. DCR incluye la transformación y el área de trabajo y la tabla de destino.
DCR de transformación del área de trabajo
El DCR de transformación del área de trabajo es un DCR especial que se aplica directamente a un área de trabajo de Log Analytics. Incluye transformaciones predeterminadas para una o más tablas compatibles. Estas transformaciones se aplican a todos los datos enviados a estas tablas a menos que esos datos procedan de otro DCR.
Por ejemplo, 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, ya que este agente no usa un DCR. Sin embargo, cualquier dato enviado desde el agente de Azure Monitor omitiría la transformación, ya que usa un DCR y se espera que proporcione una transformación propia.
Un uso común del DCR de transformación del área de trabajo es la recopilación de registros de recursos que se configuran con una configuración de diagnóstico. El ejemplo siguiente muestra este proceso.
Múltiples destinos
Con las transformaciones puede enviar datos a varios destinos de un área de trabajo de Log Analytics con un único DCR. Se proporciona una consulta KQL para cada destino, y los resultados de cada consulta se envían a su ubicación correspondiente. Puede enviar conjuntos de datos distintos a tablas diferentes, o usar varias consultas para enviar conjuntos de datos distintos a la misma tabla.
Por ejemplo, puede enviar datos de eventos a Azure Monitor mediante la API de ingesta de registros. La mayoría de los eventos deberían enviarse a una tabla de análisis donde podrían consultarse regularmente, mientras que los eventos de auditoría deberían enviarse a una tabla personalizada configurada para registros básicos para reducir el costo.
Para usar múltiples destinos, actualmente debe crear manualmente un nuevo DCR o editar uno existente. Consulte la sección Ejemplos para ejemplos de DCR con varios destinos.
Importante
Por el momento, las tablas de la DCR deben encontrarse en la misma área de trabajo de Log Analytics. Para enviar a múltiples áreas de trabajo desde una única fuente de datos, use múltiples DCR y configure su aplicación para enviar los datos a cada una de ellas.
Creación de una transformación
Hay varios métodos para crear transformaciones en función del método de recopilación de datos. En la tabla siguiente se enumeran las instrucciones de diferentes métodos para crear transformaciones.
| Tipo | Referencia |
|---|---|
| API de ingesta de registros con transformación | Envío de datos a los registros de Azure Monitor mediante la API REST (Azure Portal) Envío de datos a los registros de Azure Monitor mediante la API REST (plantillas de Resource Manager) |
| Transformación en un DCR del área de trabajo | Incorporación de la transformación del área de trabajo a los registros de Azure Monitor mediante Azure Portal Incorporación de la transformación del área de trabajo a los registros de Azure Monitor mediante plantillas de Resource Manager |
| Transformaciones de agente en un DCR | Adición de la transformación al registro de Azure Monitor |
Coste de las transformaciones
Aunque las propias transformaciones no incurren en costos directos, los siguientes escenarios pueden dar lugar a cargos adicionales:
- Si una transformación aumenta el tamaño de los datos entrantes, como al agregar 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 del 50 %, se le cobrará por la ingesta cantidad de datos filtrados por encima del 50 %.
Para calcular el cargo de procesamiento de datos resultante de las transformaciones, use la fórmula siguiente:
[GB filtrados por transformaciones] - ([GB datos ingeridos por canalización] / 2). En la tabla siguiente se muestran ejemplos.
| Datos ingeridos por canalización | Datos eliminados por transformación | Datos ingeridos por el área de trabajo de Log Analytics | Cambio de procesamiento de datos | Cargo de la ingesta |
|---|---|---|---|---|
| 20 GB | 12 GB | 8 GB | 2 GB 1 | 8 GB |
| 20 GB | 8 GB | 12 GB | 0 GB | 12 GB |
1 Este cargo excluye el cargo por los datos ingeridos por el área de trabajo de Log Analytics.
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 ver los cargos actuales por la ingesta y la retención de datos de registro en Azure Monitor.
Importante
Si Azure Sentinel está habilitado para el área de trabajo de Log Analytics, no hay ningún cargo por la ingesta de filtrado, independientemente de la cantidad de datos que filtre la transformación.
Ejemplos
Las siguientes plantillas de Resource Manager muestran ejemplos de DCR con diferentes patrones. Puede usar estas plantillas como punto de partida para crear DCR con transformaciones para sus propios escenarios.
Destino único
El siguiente ejemplo es una DCR para el agente Azure Monitor que envía datos a la tabla Syslog. En este ejemplo, la transformación filtra los datos para registros con error en el mensaje.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "singleDestinationDCR",
"apiVersion": "2021-09-01-preview",
"location": "eastus",
"properties": {
"dataSources": {
"syslog": [
{
"name": "sysLogsDataSource",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"auth",
"authpriv",
"cron",
"daemon",
"mark",
"kern",
"mail",
"news",
"syslog",
"user",
"uucp"
],
"logLevels": [
"Debug",
"Critical",
"Emergency"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Syslog"
],
"transformKql": "source | where message has 'error'",
"destinations": [
"centralWorkspace"
]
}
]
}
}
]
}
Múltiples tablas Azure
El siguiente ejemplo es una DCR para datos de Logs Ingestion API que envía datos a las tablas Syslog y SecurityEvent. Esta DCR requiere un dataFlow separado para cada una con un transformKql y un OutputStream diferentes para cada una. En este ejemplo, todos los datos entrantes se envían a la tabla Syslog mientras que los datos maliciosos también se envían a la tabla SecurityEvent. Si no quiere replicar los datos maliciosos en ambas tablas, puede agregar una instrucción where a la primera consulta para eliminar esos registros.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "multiDestinationDCR",
"location": "eastus",
"apiVersion": "2021-09-01-preview",
"properties": {
"dataCollectionEndpointId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers//Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyTableRawData": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
},
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | project TimeGenerated = Time, Computer, Message = AdditionalContext",
"outputStream": "Microsoft-Syslog"
},
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | where (AdditionalContext has 'malicious traffic!' | project TimeGenerated = Time, Computer, Subject = AdditionalContext",
"outputStream": "Microsoft-SecurityEvent"
}
]
}
}
]
}
Combinación de tablas Azure y personalizadas
El siguiente ejemplo es una DCR para los datos de Logs Ingestion API, que envía datos tanto a la tabla Syslog, como a una tabla personalizada con los datos en otro formato. Esta DCR requiere un dataFlow separado para cada una con un transformKql y un OutputStream diferentes para cada una. Cuando se usan tablas personalizadas, es importante asegurarse de que el esquema del destino (la tabla personalizada) contiene las columnas personalizadas (cómo agregar o eliminar columnas personalizadas) que coinciden con el esquema de los registros que se envían. Por ejemplo, si el registro tiene un campo denominado SyslogMessage, pero la tabla personalizada de destino solo tiene TimeGenerated y RawData, recibirá un evento en la tabla personalizada solo con el campo TimeGenerated relleno y el campo RawData estará vacío. El campo SyslogMessage se quitará porque el esquema de la tabla de destino no contiene un campo de cadena denominado SyslogMessage.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "multiDestinationDCR",
"location": "eastus",
"apiVersion": "2021-09-01-preview",
"properties": {
"dataCollectionEndpointId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers//Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyTableRawData": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
},
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | project TimeGenerated = Time, Computer, SyslogMessage = AdditionalContext",
"outputStream": "Microsoft-Syslog"
},
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, ExtendedColumn=tostring(jsonContext.CounterName)",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
]
}
Pasos siguientes
Cree una regla de recopilación de datos y una asociación con ella desde una máquina virtual mediante el agente de Azure Monitor.