Transformations de la collecte de données dans Azure Monitor
Avec les transformations dans Azure Monitor, vous pouvez filtrer ou modifier des données entrantes avant qu’elles ne soient envoyées à l’espace de travail Log Analytics. Cet article fournit une description simple des transformations et de la façon dont elles sont implémentées. Il fournit des liens vers d’autres contenus permettant de créer une transformation.
Les transformations sont effectuées dans Azure Monitor dans le pipeline d’ingestion de données une fois que la source de données a remis les données et avant leur envoi à la destination. La source de données peut effectuer son propre filtrage avant d’envoyer des données, mais s’appuie ensuite sur la transformation pour d’autres manipulations avant qu’elles ne soient envoyées à destination.
Les transformations sont définies dans une règle de collecte de données (DCR) et utilisent une instruction KQL (Kusto Query Language) qui est appliquée individuellement à chaque entrée dans les données entrantes. Elle doit comprendre le format des données entrantes et créer la sortie dans la structure attendue par la destination.
Le diagramme suivant illustre le processus de transformation des données entrantes et montre un exemple de requête qui peut être utilisé. Pour plus d’informations sur la création de requêtes de transformation, consultez Structure de transformation dans Azure Monitor.
Pourquoi utiliser les transformations
Le tableau suivant décrit les différents objectifs que vous pouvez atteindre en utilisant des transformations.
| Category | Détails |
|---|---|
| Supprimer des données sensibles | Vous avez probablement une source de données qui envoie des informations que vous ne souhaitez pas stocker pour des raisons de confidentialité ou de conformité. Filtrez les informations sensibles. Filtrez des lignes entières ou des colonnes particulières qui contiennent des informations sensibles. Obfusquez les informations sensibles. Remplacez les informations, telles que les chiffres d’une adresse IP ou d’un numéro de téléphone, par un caractère commun. Envoyez à une autre table. Envoyez des enregistrements sensibles à une autre table avec une autre configuration de contrôle d’accès en fonction du rôle. |
| Enrichir des données avec des informations supplémentaires ou calculées | Utilisez une transformation pour ajouter des informations aux données qui fournissent un contexte métier ou simplifie l’interrogation des données ultérieurement. Ajoutez une colonne avec davantage d’informations. Par exemple, vous pouvez ajouter une colonne identifiant si une adresse IP dans une autre colonne est interne ou externe. Ajoutez des informations spécifiques à l’entreprise. Par exemple, vous pouvez ajouter une colonne indiquant une division d’entreprise en fonction des informations d’emplacement dans d’autres colonnes. |
| Réduire les coûts des données | Étant donné que des coûts d’ingestion vous sont facturés pour toute donnée envoyée à un espace de travail Log Analytics, vous souhaitez filtrer les données dont vous n’avez pas besoin pour réduire ces coûts. Supprimez toute la ligne. Par exemple, vous avez probablement un paramètre de diagnostic pour collecter les journaux d’une ressource en particulier, mais n’avez pas besoin de toutes les entrées de journal qu’elle génère. Créez une transformation qui filtre les enregistrements qui correspondent à un certain critère. Supprimez une colonne de chaque ligne. Par exemple, vos données incluent probablement des colonnes avec des données redondantes ou dont la valeur est minimale. Créez une transformation qui filtre les colonnes qui ne sont pas requises. Analysez les données importantes d’une colonne. Vous avez probablement une table avec des données précieuses qui se cachent dans une colonne particulière. Utilisez une transformation pour analyser les données précieuses dans une nouvelle colonne et supprimer l’original. Envoyez certaines lignes vers les journaux de base. Envoyez des lignes dans vos données qui nécessitent des fonctionnalités de requête de base à des tables de journaux de base pour un coût d’ingestion inférieur. |
| Mettre en forme les données pour la destination | Vous pouvez avoir une source de données qui envoie des données dans un format qui ne correspond pas à la structure de la table de destination. Utilisez une transformation pour reformater les données vers le schéma requis. |
Tables prises en charge
Consultez Tables qui prennent en charge les transformations dans les journaux Azure Monitor pour obtenir la liste des tables qui peuvent être utilisées avec des transformations. Vous pouvez également utiliser la référence de données Azure Monitor qui répertorie les attributs de chaque table, notamment s’il prend en charge les transformations. En plus de ces tables, toutes les tables personnalisées (suffixe de _CL) sont également prises en charge.
- Toute table Azure listée dans Tables prenant en charge les transformations dans les journaux Azure Monitor. Vous pouvez également utiliser la référence de données Azure Monitor qui répertorie les attributs de chaque table, notamment s’il prend en charge les transformations.
- Toute table personnalisée créée pour l’agent Azure Monitor. (La table personnalisée MMA ne peut pas utiliser de transformations)
Créer une transformation
Il existe plusieurs méthodes pour créer des transformations en fonction de la méthode de collecte de données. Le tableau suivant répertorie des conseils pour différentes méthodes de création de transformations.
| Collecte de données | Référence |
|---|---|
| API d’ingestion de journaux | Envoyer des données aux journaux Azure Monitor à l’aide de l’API REST (portail Azure) Envoyer des données aux journaux Azure Monitor à l’aide de l’API REST (modèles Azure Resource Manager) |
| Machine virtuelle avec l’agent Azure Monitor | Ajouter une transformation au journal Azure Monitor |
| Cluster Kubernetes avec Container Insights | Transformations de données dans Container Insights |
| Azure Event Hubs | Tutoriel : ingérer des événements d'Azure Event Hubs dans les journaux Azure Monitor (préversion publique) |
Destinations multiples
Avec les transformations, vous pouvez envoyer des données vers plusieurs destinations dans un espace de travail Log Analytics en utilisant une seule règle DCR. Vous fournissez une requête de type KQL pour chaque destination et les résultats de chaque requête sont envoyés à leur emplacement correspondant. Vous pouvez envoyer différents jeux de données vers différentes tables ou utiliser plusieurs requêtes pour envoyer différents jeux de données à la même table.
Par exemple, vous pouvez envoyer des données d’événement à Azure Monitor à l’aide de l’API d’ingestion des journaux. La plupart des événements doivent être envoyés vers une table d’analyse dans laquelle ils peuvent être interrogés régulièrement, tandis que les événements d’audit doivent être envoyés vers une table personnalisée configurée pour les journaux de base afin de réduire vos coûts.
Pour utiliser plusieurs destinations, vous devez actuellement créer manuellement une règle de collecte de données ou en modifier une existante. Consultez la section Exemples pour obtenir des exemples de règles DCR qui utilisent plusieurs destinations.
Important
Actuellement, les tables de la règle de collecte de données doivent se trouver dans le même espace de travail Log Analytics. Pour un envoi vers plusieurs espaces de travail à partir d’une seule source de données, utilisez plusieurs règles de collecte de données et configurez votre application pour envoyer les données à chacun d’eux.
Surveiller les transformations
Pour plus d’informations sur les journaux et les métriques qui surveillent l’intégrité et les performances des transformations, consultez Surveiller et résoudre les problèmes de collecte de données DCR dans Azure Monitor. Ceci inclut l’identification des erreurs qui se produisent dans le code KQL et les métriques pour suivre leur durée d’exécution.
Coût des transformations
Bien que les transformations par elles-mêmes n’entraînent pas de coûts directs, les scénarios suivants peuvent entraîner des frais supplémentaires :
- Si une transformation augmente la taille des données entrantes, par exemple en ajoutant une colonne calculée, le taux d’ingestion standard des données supplémentaires vous sera facturé.
- Si une transformation réduit les données ingérées de plus de 50 %, nous vous facturerons la quantité de données filtrées au-dessus de 50 %.
Pour calculer les frais de traitement des données résultant de transformations, utilisez la formule suivante :
[Go filtré par les transformations] – ([Total Go ingéré par le pipeline] / 2). Le tableau suivant contient des exemples.
| Données ingérées par le pipeline | Données déposées par transformation | Données ingérées par l’espace de travail Log Analytics | Frais de traitement des données | Frais d’ingestion |
|---|---|---|---|---|
| 20 Go | 12 Go | 8 Go | 2 Go 1 | 8 Go |
| 20 Go | 8 Go | 12 Go | 0 Go | 12 Go |
1 Ces frais excluent les frais pour les données ingérées par l’espace de travail Log Analytics.
Pour éviter ces frais, nous vous recommandons de filtrer les données entrantes à l’aide d’autres méthodes avant d’appliquer des transformations. En procédant ainsi, vous pouvez réduire la quantité de données traitées par les transformations et, par conséquent, réduire les coûts supplémentaires.
Consultez les Tarifs Azure Monitor pour connaître les frais actuels d’ingestion et de conservation des données de journal dans Azure Monitor.
Important
Si Azure Sentinel est activé pour l’espace de travail Log Analytics, l’ingestion de filtrage n’est pas facturé, quelle que soit la quantité de données filtrées par la transformation.
Exemples
Les modèles Resource Manager suivants montrent des exemples de règles DCR avec différents modèles. Vous pouvez utiliser ces modèles comme point de départ pour créer des collectes de données avec des transformations pour vos propres scénarios.
Destination du fichier
L’exemple suivant est une règle DCR pour l’agent Azure Monitor qui envoie des données à la table Syslog. Dans cet exemple, la transformation filtre les données pour les enregistrements avec une error dans le message.
{
"$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"
]
}
]
}
}
]
}
Plusieurs tables Azure
L’exemple suivant est une règle DCR de l’API d’ingestion de journaux qui envoie des données aux tables Syslog et SecurityEvent. Cette règle DCR nécessite un dataFlow distinct pour chacune avec un transformKql et un OutputStream pour chacune. Dans cet exemple, toutes les données entrantes sont envoyées à la table Syslog tandis que les données malveillantes sont également envoyées à la table SecurityEvent. Si vous ne souhaitez pas répliquer les données malveillantes dans les deux tables, vous pouvez ajouter une instruction where à la première requête pour supprimer ces enregistrements.
{
"$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"
}
]
}
}
]
}
Combinaison de tables Azure et personnalisées
L’exemple suivant est une règle DCR pour les données de l’API d’ingestion de journaux qui envoie des données à la table Syslog et une table personnalisée avec les données dans un autre format. Cette règle DCR nécessite un dataFlow distinct pour chacune avec un transformKql et un OutputStream pour chacune. Lorsque vous utilisez des tables personnalisées, il est important de s’assurer que le schéma de la destination (votre table personnalisée) contient les colonnes personnalisées (comment ajouter ou supprimer des colonnes personnalisées) qui correspondent au schéma des enregistrements que vous envoyez. Par exemple, si votre enregistrement possède un champ appelé SyslogMessage, mais que la table personnalisée de destination dispose uniquement des champs TimeGenerated et RawData, vous recevrez un événement dans la table personnalisée. Le champ TimeGenerated sera rempli et le champ RawData sera vide. Le champ SyslogMessage est supprimé, car le schéma de la table de destination ne contient aucun champ de chaîne appelé 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"
}
]
}
}
]
}