Configurer des règles de collecte de données Azure Monitor

Effectué

Une autre façon de normaliser les données de journal consiste à transformer les données au moment de l’ingestion. Cela offre l’avantage de stocker les données dans un format analysé pour une utilisation dans Microsoft Sentinel.

Règles de collecte de données dans Azure Monitor

Les règles de collecte des données (DCR) fournissent un pipeline de type ETL dans Azure Monitor, ce qui vous permet de définir la façon dont les données entrantes dans Azure Monitor doivent être gérées. Selon le type de workflow, les DCR peuvent spécifier l’emplacement où les données doivent être envoyées et elles peuvent filtrer ou transformer les données avant qu’elles ne soient stockées dans les journaux Azure Monitor. Certaines règles de collecte de données sont créées et gérées par Azure Monitor, tandis que vous pouvez en créer d’autres pour personnaliser la collecte des données selon vos besoins spécifiques.

Types de règles de collecte de données

Il existe actuellement deux types de règle de collecte de données dans Azure Monitor :

  • DCR standard. Utilisée avec différents workflows qui envoient des données à Azure Monitor. Les workflows actuellement pris en charge sont l’agent Azure Monitor et les journaux personnalisés.

  • DCR de transformation de l’espace de travail. Utilisée avec un espace de travail Log Analytics pour appliquer des transformations au moment de l’ingestion à des workflows qui ne prennent actuellement pas en charge les DCR.

Transformations

Les transformations dans une règle de collecte de données (DCR) vous permettent de filtrer ou de modifier les données entrantes avant qu’elles soient stockées dans un espace de travail Log Analytics. Les transformations de données sont définies à l’aide d’une instruction KQL (Kusto Query Language) appliquée individuellement à chaque entrée de la source de données. Elle doit comprendre le format des données entrantes et créer la sortie dans la structure de la table cible.

Structure de transformation

Le flux d’entrée est représenté par une table virtuelle nommée source avec des colonnes correspondant à la définition du flux de données d’entrée. Voici un exemple typique de transformation. Cet exemple inclut la fonctionnalité suivante :

  • Filtre les données entrantes avec une instruction where
  • Ajoute une nouvelle colonne à l’aide de l’opérateur extend
  • Met en forme la sortie pour qu’elle corresponde aux colonnes de la table cible à l’aide de l’opérateur project
source  
| where severity == "Critical" 
| extend Properties = parse_json(properties)
| project
    TimeGenerated = todatetime(["time"]),
    Category = category,
    StatusDescription = StatusDescription,
    EventName = name,
    EventId = tostring(Properties.EventId)