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 ici, consultez Créer et modifier des règles de collecte de données (DCR) dans Azure Monitor.
- Pour obtenir des exemples de règles DCR pour différents scénarios, consultez Exemple de règles de collecte de données (DCR) dans Azure Monitor.
Le tableau suivant décrit les propriétés au niveau supérieur de la règle DCR.
Propriété | Description |
---|---|
description |
Description facultative de la règle de collecte de données définie par l’utilisateur. |
dataCollectionEndpointId |
ID de la ressource du point de terminaison de collecte de données (DCE) utilisé par la règle DCR si vous en avez fourni un lors de la création de la règle 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 ci-dessous. |
1Cette propriété n’a pas été créée pour les règles DCR créées avant le 31 mars 2024. Les contrôleurs de domaine créés avant cette date nécessitaient un point de terminaison de collecte de données (DCE) et la propriété dataCollectionEndpointId
à spécifier. Si vous souhaitez utiliser ces contrôleurs de domaine incorporés, vous devez créer une DCR.
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.
Type | Description |
---|---|
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. |
AgentDirectToStore |
Envoie les données collectées à Stockage Azure et Event Hubs. |
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. |
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.
La section Flux d’entrée d’une règle DCR définit les données entrantes qui sont collectées. Il existe deux types de flux entrants, selon le scénario de collecte de données particulier. La plupart des scénarios de collecte de données utilisent un seul des flux d’entrée, mais certains peuvent utiliser les deux.
Notes
Les règles DCR de transformation d’espace de travail n’ont pas de flux d’entrée.
Flux d'entrée | Description |
---|---|
dataSources |
Type de données connu. Il s’agit souvent de données traitées par l’agent Azure Monitor et transmises à Azure Monitor à l’aide d’un type de données connu. |
streamDeclarations |
Données personnalisées qui doivent être définies dans la règle DCR. |
Les données envoyées à partir de l’API d’ingestion de journaux utilisent streamDeclaration
avec le schéma des données entrantes. Cela est dû au fait que l’API envoie des données personnalisées qui peuvent avoir n’importe quel schéma.
Les journaux de texte d’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
Les sources de données sont des sources uniques de données de surveillance qui ont chacune leur propre format et leur propre méthode pour exposer leurs données. Chaque type de source de données dispose d’un ensemble unique de paramètres qui doivent être configurés pour chaque source de données. Le type des données retournées par la source de données étant généralement connu, le schéma n’a pas besoin d’être défini dans la règle DCR.
Par exemple, les événements et les données de performances collectés à partir d’une machine virtuelle avec 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 dans la mesure où il s’agit d’un schéma connu pour les données entrantes potentielles.
Tous les types de sources de données ont en commun les paramètres suivants.
Paramètre | Description |
---|---|
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. S’il s’agit d’un type de données standard tel qu’un événement Windows, le flux se présente sous la forme Microsoft-<TableName> . S’il s’agit d’un type personnalisé, il se présente sous la forme Custom-<TableName> |
Les types de sources de données actuellement disponibles sont indiqués dans le tableau suivant.
Type de source de données | Description | 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 au format texte ou JSON sur une machine virtuelle | Personnalisé1 | filePatterns : modèle de dossier et de fichier pour les fichiers journaux à collecter auprès du client.format - json ou text |
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 à collecterlabelIncludeFilter : liste des filtres d’inclusion d’étiquette comme paires nom-valeur. Seul « microsoft_metrics_include_label » est actuellement 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 à collecterlogLevels : 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’extensionextensionSettings : valeurs de chaque paramètre requis par l’extension |
1 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 qu’elles collectent 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éclaration des différents types de données envoyés 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 qui seront envoyées. 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.
Les types de données possibles qui peuvent être affectés aux propriétés sont :
string
int
long
real
boolean
dynamic
datetime
.
La section destinations
inclut une entrée pour chaque destination où les données seront envoyées. Ces destinations sont mises en correspondance avec les flux d’entrée dans la section dataFlows
.
Paramètres | Description |
---|---|
name |
Nom permettant d’identifier la destination dans la section dataSources . |
Les destinations actuellement disponibles sont listées dans le tableau suivant.
Destination | Description | Paramètres obligatoires |
---|---|---|
logAnalytics |
Espace de travail Log Analytics | workspaceResourceId : ID de la ressource de l’espace de travailworkspaceID : ID de l’espace de travailSpécifie uniquement l’espace de travail, et non la table dans laquelle les données seront envoyées. S’il s’agit d’une destination connue, aucune table n’a besoin d’être spécifiée. Pour les tables personnalisées, la table est spécifiée dans la source de données. |
azureMonitorMetrics |
Métriques d’Azure Monitor | Aucune configuration n’est requise, car il n’existe qu’un seul magasin de métriques pour l’abonnement. |
storageTablesDirect |
Stockage Table Azure | storageAccountResourceId : ID de la ressource du compte de stockagetableName : nom de la table |
storageBlobsDirect |
stockage d’objets blob Azure | storageAccountResourceId : ID de la ressource du compte de stockagecontainerName : nom du conteneur d’objets blob |
eventHubsDirect |
Event Hubs | eventHubsDirect : ID de la ressource du hub d’événements |
Important
Un flux peut uniquement envoyer vers un espace de travail Log Analytics dans un DCR. Vous pouvez avoir plusieurs entrées dataFlow
pour un seul flux si elles 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.
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, une table spécifique dans l’espace de travail Log Analytics.
Section | Description |
---|---|
streams |
Un ou plusieurs flux définis dans la section Flux d’entrée. Vous pouvez inclure plusieurs flux dans un seul flux de données si vous souhaitez envoyer plusieurs sources de données vers la même destination. Utilisez un seul flux si le flux de données comprend une transformation. Un flux peut également être utilisé par plusieurs flux de données lorsque vous souhaitez envoyer une source de données particulière vers 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. |
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. |
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. |
Vue d’ensemble des règles de collecte des données et des méthodes pour les créer