Structure d’une règle de collecte de données (DCR) dans Azure Monitor

Cet article décrit la structure JSON des contrôleurs de domaine pour les cas où vous devez travailler directement avec leur définition.

• Pour plus d’informations sur l’utilisation du json décrit dans cet article, consultez Créer et modifier des contrôleurs de domaine.
• Pour obtenir des exemples de différents scénarios, consultez Sample DCRs dans Azure Monitor.

Propriétés

Le tableau suivant décrit les propriétés au niveau supérieur de la règle DCR.

Propriété	Descriptif
description	Description facultative de la règle de collecte de données définie par l’utilisateur.
dataCollectionEndpointId	ID de ressource du point de terminaison de collecte de données (DCE) utilisé par le DCR si vous en fournissez un lors de la création du DCR. Cette propriété n’est pas présente dans les règles DCR qui n’utilisent pas de DCE.
endpoints 1	Contient les URL logsIngestion et metricsIngestion des points de terminaison de la règle DCR. Cette section et ses propriétés sont créées automatiquement lors de la création de la règle DCR uniquement si l’attribut kind dans la règle DCR est Direct.
immutableId	Identificateur unique de la règle de collecte de données. Cette propriété et sa valeur sont créées automatiquement lors de la création de la règle DCR.
kind	Spécifie le scénario de collecte de données pour lequel la règle DCR est utilisée. Ce paramètre est décrit plus en détail dans la section suivante.
transformations	(Préversion) Tableau de pipelines de transformation nommés utilisés par des transformations à plusieurs étapes. Chaque entrée définit un processeur d’en-tête et une séquence ordonnée de processeurs. Référencé par dataSources et dataFlows via la transform propriété. Nécessite une version d’API ou une version 2025-05-11 ultérieure. Voir Transformations.

¹ Cette propriété n'a pas été créée pour les DCRs établis avant le 31 mars 2024. Les règles de collecte de données (DCRs) créées avant cette date nécessitaient un point de terminaison de collecte de données (DCE) et une spécification de la dataCollectionEndpointId propriété. Si vous souhaitez utiliser ces contrôleurs de domaine incorporés, vous devez créer une nouvelle DCR.

Genre

La propriété kind dans la règle DCR spécifie le type de collection pour lequel la règle DCR est utilisée. Chaque genre de règle DCR a une structure et des propriétés différentes.

Le tableau suivant liste les différents types de règles DCR et les détails correspondants.

Genre	Descriptif
Direct	Ingestion directe à l’aide de l’API d’ingestion de journaux. Les points de terminaison sont créés pour la règle DCR uniquement si cette valeur kind est utilisée.
AgentSettings	Configure les paramètres de l’agent Azure Monitor.
Linux	Collecte les événements et les données de performances à partir de machines Linux.
PlatformTelemetry	Exporte les métriques de la plateforme.
Windows	Collecte les événements et les données de performances à partir de machines Windows.
WorkspaceTransforms	DCR de transformation de l’espace de travail. Cette règle DCR n’inclut pas de flux d’entrée.

Vue d’ensemble du flux de données d’une règle DCR

Le flux de base d’une règle DCR est illustré dans le diagramme suivant. Chacun des composants est décrit dans les sections suivantes.

Le flux de données complet via une DCR suit cette séquence : sources de données → flux d’entrée → flux de données → Destinations. Tous les types DCR n’utilisent pas tous les éléments. Le tableau suivant montre quels éléments s’appliquent à chaque type de DCR.

Type DCR	Sources de données	Flux d’entrée	Flux de données	Destinations
RD AMA (Linux, Windows)	Oui	Oui	Oui	Oui
Contrôleurs de domaine d’ingestion directs (Direct)	Non	Oui	Oui	Oui
Contrôleurs de domaine de transformation de l’espace de travail (WorkspaceTransforms)	Non	Non	Oui	Non

Avec les transformations à plusieurs étapes, la transformations section ajoute des pipelines de processeur qui s’appliquent à l’étape de la source de données (côté client) ou à l’étape du flux de données (côté ingestion), selon l’emplacement où la transformation nommée est référencée.

Flux d’entrée

La section flux d’entrée d’une DCR définit les données entrantes qu’elle collecte. Deux types de flux entrants sont possibles en fonction du scénario de collecte de données. La plupart des scénarios de collecte de données utilisent l’un des flux d’entrée, tandis que certains scénarios utilisent les deux.

Remarque

Les DCRs de transformation de l'espace de travail n'ont pas de flux d'entrée.

Flux d'entrée	Descriptif
dataSources	Type de données connu. Ce type provient souvent des données traitées par Azure Monitor agent et remises à Azure Monitor à l’aide d’un type de données connu.
streamDeclarations	Données personnalisées qui nécessitent une définition dans la DCR.

Les données envoyées à partir de l’API d’ingestion Logs utilisent un streamDeclaration schéma des données entrantes, car l’API envoie des données personnalisées.

Les journaux de texte de Azure Monitor Agent (AMA) sont un exemple de collecte de données qui nécessite à la fois dataSources et streamDeclarations. La source de données inclut la configuration de la connexion à la source de données et streamDeclarations définit le schéma des données entrantes.

Sources de données

Les sources de données sont des sources uniques de données de surveillance, chacune avec son propre format et sa propre méthode pour exposer des données. Chaque type de source de données a un ensemble unique de paramètres que vous devez configurer pour chaque source de données. La source de données retourne généralement un type de données connu. Vous n’avez donc pas besoin de définir le schéma dans la DCR.

Par exemple, les événements et les données de performances collectés à partir d’une machine virtuelle à l’aide de l’agent Azure Monitor (AMA) utilisent des sources de données telles que windowsEventLogs et performanceCounters. Vous spécifiez des critères pour les événements et les compteurs de performances que vous souhaitez collecter, mais vous n’avez pas besoin de définir la structure des données elle-même, car ce schéma est connu pour les données entrantes potentielles.

Paramètres courants de la source de données

Tous les types de sources de données ont en commun les paramètres suivants.

Paramètre	Descriptif
name	Nom permettant d’identifier la source de données dans la règle DCR.
streams	Liste des flux collectés par la source de données. Si ce flux est un type de données standard tel qu’un événement Windows, le flux s’affiche en tant que Microsoft-<TableName>. S’il s’agit d’un type personnalisé, le flux s’affiche sous la forme Custom-<TableName>.
transform	(Préversion) Nom d’une transformation de la transformations section pour appliquer côté client. Utilisez cette propriété pour les transformations à plusieurs étapes. Consultez les transformations à plusieurs étapes.

Types de sources de données valides

Le tableau suivant répertorie les types de sources de données actuellement disponibles.

Type de source de données	Descriptif	Flux	Paramètres
eventHub	Données provenant d’Azure Event Hubs.	Personnalisé1	consumerGroup : groupe de consommateurs du hub d’événements à partir duquel effectuer la collecte.
iisLogs	Journaux IIS provenant de machines Windows	Microsoft-W3CIISLog	logDirectories : répertoire dans lequel les journaux IIS sont stockés sur le client.
logFiles	Journal de texte ou JSON sur une machine virtuelle	Personnalisé1	filePatterns - Modèle de dossier et de fichier pour les fichiers journaux à collecter à partir du client. format - json ou texte
performanceCounters	Compteurs de performances pour les machines virtuelles Windows et Linux	Microsoft-Perf Microsoft-InsightsMetrics	samplingFrequencyInSeconds : fréquence d’échantillonnage des données de performances. counterSpecifiers : objets et compteurs à collecter.
prometheusForwarder	Données Prometheus collectées à partir de cluster Kubernetes.	Microsoft-PrometheusMetrics	streams – Flux à collecter labelIncludeFilter : liste des filtres d’inclusion d’étiquette comme paires nom-valeur. Actuellement uniquement microsoft_metrics_include_label pris en charge.
syslog	Événements Syslog sur une machine virtuelle Linux Événements au format d’événement commun sur les appliances de sécurité	Microsoft-Syslog Microsoft-CommonSecurityLog pour CEF	facilityNames : installations à collecter logLevels : niveaux de journal à collecter
windowsEventLogs	Journal des événements Windows sur les machines virtuelles	Microsoft-Event	xPathQueries : XPaths spécifiant les critères des événements à collecter.
extension	Source de données basée sur l’extension utilisée par l’agent Azure Monitor.	Varie selon l’extension	extensionName : nom de l’extension extensionSettings : valeurs de chaque paramètre requis par l’extension

¹ Ces sources de données utilisent à la fois une source de données et une déclaration de flux, car le schéma des données collectées peut varier. Le flux utilisé dans la source de données doit être le flux personnalisé défini dans la déclaration de flux.

Déclarations de flux

Déclarez les différents types de données que vous envoyez dans l’espace de travail Log Analytics. Chaque flux est un objet dont la clé représente le nom du flux, qui doit commencer par Custom-. Le flux contient une liste complète des propriétés de niveau supérieur contenues dans les données JSON que vous envoyez. La forme des données que vous envoyez au point de terminaison ne doit pas nécessairement être identique à celle de la table de destination. La sortie de la transformation appliquée sur les données d’entrée doit plutôt correspondre à la forme de destination.

Types de données

Affectez les types de données suivants aux propriétés :

• string
• int
• long
• real
• boolean
• dynamic
• datetime

Le guid type n’est pas disponible dans les déclarations de flux. Si vos données sources incluent des valeurs GUID, déclarez ces colonnes en tant que string. L’API Tables prend en charge le guid type, mais les valeurs sont réellement stockées et interrogées sous forme de chaînes. Pour plus d’informations, consultez Types de donnéesColumn dans Azure Monitor Journaux.

Destinations

Incluez une entrée pour chaque destination où vous envoyez les données dans la destinations section. Mettre en correspondance ces destinations avec des flux d’entrée dans la dataFlows section.

Paramètres de destination courants

Paramètres	Descriptif
name	Nom permettant d’identifier la destination dans la section dataSources.

Destinations valides

Le tableau suivant répertorie les destinations disponibles.

Destination	Descriptif	Paramètres obligatoires
azureDataExplorer	Explorateur de données Azure	resourceId - ID de ressource du cluster ADX databaseName - Nom de la base de données dans le cluster ADX ingestionUri : URI d’ingestion du cluster
azureMonitorMetrics	Métriques Azure Monitor	Aucune configuration n’est requise, car il n’existe qu’un seul magasin de métriques pour l’abonnement.
logAnalytics	Espace de travail Log Analytics	workspaceResourceId : ID de la ressource de l’espace de travail workspaceID : ID de l’espace de travail Ce paramètre spécifie uniquement l’espace de travail, et non la table dans laquelle les données sont envoyées. S’il s’agit d’une destination connue, vous n’avez pas besoin de spécifier une table. Pour les tables personnalisées, spécifiez la table dans la source de données.
microsoftFabric	Centre d’événements Microsoft Fabric	tenantId - ID de locataire de l’espace de travail Fabric databaseName - Nom de la base de données dans l’eventhouse Fabric ingestionUri - URI d’ingestion de la base de données d’eventhouse Fabric

Important

Un flux peut uniquement envoyer vers un espace de travail Log Analytics dans un DCR. Vous pouvez avoir plusieurs dataFlow entrées pour un seul flux s’ils utilisent des tables différentes dans le même espace de travail. Si vous devez envoyer des données à plusieurs espaces de travail Log Analytics à partir d’un seul flux, créez un DCR distinct pour chaque espace de travail.

Flux de données

Les flux de données correspondent aux flux d’entrée avec des destinations. Chaque source de données peut éventuellement spécifier une transformation et, dans certains cas, spécifier une table spécifique dans l’espace de travail Log Analytics.

Propriétés des flux de données

Section	Descriptif
streams	Un ou plusieurs flux définis dans la section Flux d’entrée. Incluez plusieurs flux dans un seul flux de données si vous souhaitez envoyer plusieurs sources de données à la même destination. Utilisez un seul flux si le flux de données inclut une transformation. Utilisez un flux pour plusieurs flux de données lorsque vous souhaitez envoyer une source de données particulière à plusieurs tables dans le même espace de travail Log Analytics.
destinations	Une ou plusieurs destinations de la section destinations ci-dessus. Plusieurs destinations sont autorisées pour les scénarios multi-hébergements.
transform	(Préversion) Nom d’une transformation de la section à appliquer au moment de l’ingestion transformations . Mutuellement exclusif avec transformKql. Consultez les transformations à plusieurs étapes.
transformKql	Transformation facultative appliquée au flux entrant. La transformation doit comprendre le schéma des données entrantes et des données sortantes dans le schéma de la table cible. Si vous utilisez une transformation, le flux de données ne doit utiliser qu’un seul flux. Mutuellement exclusif avec transform.
outputStream	Décrit la table de l’espace de travail spécifiée sous la propriété destination vers laquelle les données sont envoyées. La valeur de outputStream a le format Microsoft-[tableName] lorsque les données sont ingérées dans une table standard ou Custom-[tableName] lors de l’ingestion de données dans une table personnalisée. Une seule destination est autorisée par flux. Cette propriété n’est pas utilisée pour les sources de données connues d’Azure Monitor, telles que les données d’événements et de performances, car elles sont envoyées vers des tables prédéfinies.

Transformations

Important

Les transformations à plusieurs étapes sont actuellement en préversion publique. Cette section nécessite une version d’API ou une version 2025-05-11 ultérieure. Consultez les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure pour les conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.

La transformations section définit les transformations nommées réutilisables référencées par dataSources et dataFlows. Chaque transformation définit un pipeline de processeurs appliqués séquentiellement aux données. Pour plus d’informations conceptuelles, consultez les transformations à plusieurs étapes .

"transformations": [
    {
        "name": "my_transform",
        "headerProcessor": {
            "processor": "header.Syslog",
            "configuration": { }
        },
        "processors": [
            {
                "processor": "filter.Basic",
                "configuration": {
                    "any": [
                        {
                            "all": [
                                {
                                    "columnName": "Facility",
                                    "operator": "==",
                                    "value": "auth"
                                }
                            ]
                        }
                    ]
                }
            }
        ]
    }
]

Propriétés de l’objet transformation

Propriété	Type	Obligatoire	Descriptif
name	string	Oui	Nom unique pour cette transformation. Référencé par dataSources[].transform et dataFlows[].transform.
headerProcessor	Objet	Oui	Processeur d’en-tête qui établit le schéma de démarrage. Doit être le premier élément. Consultez processeurs d’en-tête.
processors	tableau	Non	Séquence ordonnée de processeurs de transformation appliquée après l’en-tête. Consultez les types de processeurs.

Objet processeur

Chaque processeur est un bloc de construction déclaratif qui décrit une opération de transformation de données spécifique.

{
    "processor": "{family}.{Name}",
    "configuration": { }
}

Propriété	Type	Obligatoire	Descriptif
processor	string	Oui	Nom du processeur au format {family}.{Name}. Respectent la casse. Par exemple : filter.Basic.
configuration	Objet	Oui	Configuration spécifique au processeur. Consultez les sections individuelles du processeur.

Types de processeurs

Le tableau suivant indique quels processeurs sont disponibles côté client et côté ingestion.

• Les processeurs d’en-tête côté client sont utilisés pour les transformations côté client affectées aux sources de données. Ils ne nécessitent aucune configuration, car le schéma des données entrantes est connu.
• Les processeurs d’en-tête côté ingestion sont utilisés pour les transformations côté ingestion affectées aux flux de données.

Nom du processeur	Famille	Client-side	Ingestion côté
header.Syslog	Header	Oui	Non
header.WindowsEvents	Header	Oui	Non
header.WindowsPerformanceCounters	Header	Oui	Non
header.LinuxPerformanceCounters	Header	Oui	Non
header.TextLog	Header	Oui	Non
header.IISLog	Header	Oui	Non
header.WindowsFirewallLog	Header	Oui	Non
header.StandardStream	Header	Non	Oui
header.CustomStream	Header	Non	Oui
filter.Basic	Filtrer	Oui	Oui
map.Rename	Map	Oui	Oui
map.Drop	Map	Oui	Oui
parse.JsonPath	Parse	Oui	Oui
parse.XmlPath	Parse	Oui	Oui
parse.CEFAttribute	Parse	Oui	Oui
aggregate.Basic	Aggregate	Oui	Oui
enrich.DNSLookup	Enrichir	Oui	Oui
transform.KQL	Transformer	Non	Oui

Processeurs d’en-têtes

Les processeurs d’en-tête reçoivent des données brutes et les convertissent en format tabulaire connu. Un processeur d’en-tête doit être le premier processeur dans n’importe quelle transformation.

En-tête. Syslog

En-tête côté client pour les sources de données syslog.

Schéma de sortie :

Column	Type
TimeGenerated	datetime
Établissement	string
SeverityNumber	int
EventTime	datetime
IP de l'hôte	string
Message	string
ProcessId	string
Niveau de gravité	string
Host	string
Ident	string
Timestamp	datetime

En-tête. WindowsEvents

En-tête côté client pour Windows sources de données du journal des événements.

Schéma de sortie :

Column	Type
TimeGenerated	datetime
TimeCreated	datetime
ID de l’éditeur	string
Nom de l'Éditeur	string
Canal	string
LoggingComputer	string
EventNumber	int
Catégorie d'événement	int
Niveau d'Événement	string
Nom d’utilisateur	string
RawXml	string
EventDescription	string
RenderingInfo	string
EventRecordId	int

En-tête. WindowsPerformanceCounters

En-tête côté client pour Windows sources de données du compteur de performances.

Schéma de sortie :

Column	Type
TimeGenerated	datetime
CounterName	string
CounterValue	real
Samplerate	int
Compteur	string
Instance	string

En-tête. LinuxPerformanceCounters

En-tête côté client pour les sources de données du compteur de performances Linux.

Schéma de sortie :

Column	Type
TimeGenerated	datetime
Timestamp	datetime
CounterName	string
Nom de l'Objet	string
Nom de l'instance	string
Value	int
Host	string

En-tête. TextLog

En-tête côté client pour les fichiers journaux de texte personnalisés.

Schéma de sortie :

Column	Type
TimeGenerated	datetime
FilePath	string
Données brutes	string
Ordinateur	string

En-tête. IISLog

En-tête côté client pour les sources de données de journal IIS.

Schéma de sortie :

Column	Type
TimeGenerated	datetime
s_sitename	string
s_computername	string
s_ip	string
cs_method	string
cs_uri_stem	string
cs_uri_query	string
s_port	int
cs_username	string
c_ip	string
cs_version	string
cs_User_Agent_	string
cs_Cookie_	string
cs_Referer_	string
cs_host	string
sc_status	int
sc_substatus	int
sc_win32_status	int
sc_bytes	int
cs_bytes	int
time_taken	int

En-tête. WindowsFirewallLog

En-tête côté client pour Windows sources de données du journal du pare-feu.

Schéma de sortie :

Column	Type
TimeGenerated	datetime
date	string
Temps	string
action	string
protocol	string
src_ip	string
dst_ip	string
src_port	string
dst_port	string
size	string
tcpflags	string
tcpsyn	string
tcpack	string
tcpwin	string
icmptype	string
icmpcode	string
Informations	string
chemin	string
pid	string

En-tête. StandardStream

Utilisé lorsque l’entrée est un flux standard tel que Microsoft-Syslog ou Microsoft-Event.

{
    "processor": "header.StandardStream",
    "configuration": {
        "streamId": "Microsoft-Syslog"
    }
}

Propriété	Type	Obligatoire	Descriptif
streamId	string	Oui	Identificateur du flux standard, tel que Microsoft-Syslog.

Schéma de sortie : identique au schéma de table standard Log Analytics correspondant. Consultez Log Analytics référence de table pour les schémas par type de ressource.

En-tête. CustomStream

Utilisé lorsque l’entrée est un flux personnalisé défini dans streamDeclarations.

{
    "processor": "header.CustomStream",
    "configuration": {
        "streamId": "Custom-MyStream"
    }
}

Propriété	Type	Obligatoire	Descriptif
streamId	string	Oui	Identificateur du flux personnalisé. Doit correspondre à un flux défini dans streamDeclarations.

Après les processeurs d’en-tête

Ces processeurs s’exécutent après le processeur d’en-tête dans un pipeline de transformation. Tous les processeurs ne sont pas disponibles sur les deux phases. Reportez-vous à la table d’applicabilité du processeur pour déterminer quels processeurs sont pris en charge côté client, côté ingestion ou les deux.

Filtre. Base

Supprime les enregistrements entiers en fonction de l’évaluation des conditions. Les conditions sont structurées en tant que groupes OR de groupes AND.

{
    "processor": "filter.Basic",
    "configuration": {
        "any": [
            {
                "all": [
                    {
                        "columnName": "Facility",
                        "operator": "==",
                        "value": "auth"
                    }
                ]
            }
        ]
    }
}

Propriété	Type	Obligatoire	Descriptif
any	tableau de groupes AND	Oui	Groupe OR de niveau supérieur. Un enregistrement est conservé si un groupe AND prend la valeur true.

Chaque groupe AND a une all propriété contenant un tableau d’objets de condition :

Propriété	Type	Obligatoire	Descriptif
columnName	string	Oui	Colonne à évaluer.
operator	string	Oui	Opérateur de comparaison. Chaîne : ==, , !=, !containscontains. Numérique : ==, , !=, <>, >=, <=.
value	chaîne, nombre ou booléen	Oui	Valeur de référence à comparer.

Schéma de sortie : identique à l’entrée. Les enregistrements sont supprimés, et non les colonnes.

Carte. Renommer

Renomme une colonne et modifie éventuellement son type.

{
    "processor": "map.Rename",
    "configuration": {
        "all": [
            {
                "columnName": "OldName",
                "nameAs": "NewName",
                "typeAs": "string"
            }
        ]
    }
}

Propriété	Type	Obligatoire	Descriptif
columnName	string	Oui	Colonne existante pour renommer ou typecast.
nameAs	string	Non	Nouveau nom de colonne. En cas d’omission, la colonne conserve son nom.
typeAs	string	Non	Type cible : string, , longint, realbool, . datetime En cas d’échec du cast, null est retourné.

Schéma de sortie : identique à l’entrée, à l’exception des colonnes et colonnes renommées avec des types modifiés.

Carte. Goutte

Supprime une ou plusieurs colonnes des données.

{
    "processor": "map.Drop",
    "configuration": {
        "columnNames": ["Column1", "Column2"]
    }
}

Propriété	Type	Obligatoire	Descriptif
columnNames	tableau de chaînes	Oui	Colonnes à supprimer.

Schéma de sortie : identique à l’entrée, à l’exception des colonnes supprimées.

Parse. JsonPath

Analyse une chaîne au format JSON dans une colonne et extrait les clés spécifiées dans de nouvelles colonnes.

{
    "processor": "parse.JsonPath",
    "configuration": {
        "columnName": "EventData",
        "all": [
            {
                "path": "$.user.name",
                "nameAs": "UserName",
                "typeAs": "string"
            }
        ]
    }
}

Propriété	Type	Obligatoire	Descriptif
columnName	string	Oui	Colonne contenant la chaîne JSON.
all	tableau d’objets d’extraction	Oui	Clés à extraire.

Propriétés de l’objet d’extraction :

Propriété	Type	Obligatoire	Descriptif
path	string	Oui	Chemin d’accès JSON à la clé, tel que $.key ou $.nested.key.
nameAs	string	Oui	Nouveau nom de colonne de sortie.
typeAs	string	Non	Type de cible. En cas d’échec du cast, null est retourné.

Schéma de sortie : identique à l’entrée, ainsi que de nouvelles colonnes pour chaque clé extraite.

Parse. XmlPath

Analyse une chaîne au format XML dans une colonne et extrait les éléments spécifiés dans de nouvelles colonnes.

{
    "processor": "parse.XmlPath",
    "configuration": {
        "columnName": "RawXml",
        "all": [
            {
                "path": "/Event/System/EventID",
                "nameAs": "EventID",
                "typeAs": "int"
            }
        ]
    }
}

Les propriétés de configuration correspondent parse.JsonPath, à l’exception path de l’utilisation de la syntaxe XPath (par exemple, /Event/System/EventID ou /Event/EventData/Data[@Name='SubjectUserName']).

Schéma de sortie : identique à l’entrée, ainsi que de nouvelles colonnes pour chaque élément extrait.

Remarque

La syntaxe XPath valide est régie par la bibliothèque d’analyseurs à chaque étape. Les expressions XPath avancées peuvent uniquement être prises en charge dans des emplacements d’exécution spécifiques.

Parse. CEFAttribute

Analyse les données CEF (Common Event Format) dans une colonne et extrait les champs spécifiés dans de nouvelles colonnes.

{
    "processor": "parse.CEFAttribute",
    "configuration": {
        "columnName": "Message",
        "all": [
            {
                "path": "deviceAction",
                "nameAs": "Action",
                "typeAs": "string"
            }
        ]
    }
}

Les propriétés de configuration correspondent parse.JsonPath, à l’exception path des spécifications du nom de clé CEF.

Schéma de sortie : identique à l’entrée, ainsi que de nouvelles colonnes pour chaque champ extrait.

Agrégat. Base

Résume les enregistrements à l’aide d’opérateurs d’agrégation avec des dimensions de regroupement.

{
    "processor": "aggregate.Basic",
    "configuration": {
        "batchingSettings": {
            "timeWindow": "5m",
            "maxBatchRows": 1000
        },
        "aggregates": [
            {
                "columnName": "CounterValue",
                "operator": "avg",
                "nameAs": "AvgValue"
            },
            {
                "operator": "count",
                "nameAs": "RecordCount"
            }
        ],
        "dimensionColumns": ["Host", "CounterName"]
    }
}

Propriété	Type	Obligatoire	Descriptif
batchingSettings.timeWindow	string	Oui	Intervalle de temps par lot d’agrégation, tel que 5m ou 1h.
batchingSettings.maxBatchRows	int	Oui	Nombre maximal de lignes par lot d’agrégation.
aggregates	tableau	Oui	Définitions d’agrégation.
dimensionColumns	tableau de chaînes	Oui	Colonnes à regrouper. Seul string le type est pris en charge.

Propriétés d’entrée d’agrégation :

Propriété	Type	Obligatoire	Descriptif
columnName	string	Non	Colonne à agréger. Non requis pour l’opérateur count .
operator	string	Oui	Fonction d’agrégation : sum, , avgmin, max, count.
nameAs	string	Oui	Nom de colonne de sortie pour la valeur agrégée.

Schéma de sortie : l’agrégation modifie entièrement le schéma de sortie. La sortie contient uniquement les colonnes d’agrégation et les colonnes de dimension. Acheminer les données agrégées vers une table personnalisée distincte.

Enrichir. DNSLookup

Recherche une adresse IP dans une colonne et ajoute une colonne de nom DNS.

{
    "processor": "enrich.DNSLookup",
    "configuration": {
        "columnName": "IPAddress",
        "nameAs": "DNSName"
    }
}

Propriété	Type	Obligatoire	Descriptif
columnName	string	Oui	Colonne contenant l’adresse IP à rechercher.
nameAs	string	Oui	Nouveau nom de colonne de sortie pour le nom DNS résolu.

Schéma de sortie : identique à l’entrée, plus nouvelle colonne pour le nom DNS résolu. La résolution DNS est la meilleure solution. Si la recherche échoue, la colonne de sortie contient null.

Transformer. KQL

Applique une expression KQL personnalisée pour les scénarios avancés. Ce processeur est côté ingestion uniquement et fournit une validation limitée du KQL. Les contrôleurs de domaine existants utilisés transformKql dans les flux de données ont un chemin de migration simple avec ce processeur.

{
    "processor": "transform.KQL",
    "configuration": {
        "expression": "source | where SeverityNumber >= 4 | extend EnrichedMsg = strcat(Host, ': ', Message)"
    }
}

Propriété	Type	Obligatoire	Descriptif
expression	string	Oui	Chaîne de requête KQL appliquée aux données d’entrée.

Schéma de sortie : défini par KQL et ne peut pas être validé statiquement.

Contenu connexe

• Vue d’ensemble des règles et méthodes de collecte de données pour les créer
• Créer et modifier des règles de collecte de données dans Azure Monitor
• transformations Multi-stage dans Azure Monitor
• Créer une transformation dans Azure Monitor
• Collecter des données à partir de clients de machine virtuelle