Exemples de règles de collecte de données (DCR) dans Azure Monitor
Cet article inclut des exemples de règles de collecte de données (DCR) pour les scénarios courants de collecte de données dans Azure Monitor. Vous pouvez modifier ces définitions DCR en fonction des besoins de votre environnement et créer la DCR en utilisant l’aide dans Créer ou modifier une règle de collecte de données. Vous pouvez également utiliser et combiner les stratégies de base dans ces exemples pour créer des DCR pour d’autres scénarios.
Ces exemples nécessitent une connaissance de la structure DCR, comme décrite dans Structure d’une règle de collecte de données dans Azure Monitor. Plusieurs peuvent être configurées en utilisant le Portail Azure, sans connaissance détaillée de la structure DCR. Utilisez ces exemples lorsque vous devez utiliser la définition DCR elle-même pour effectuer des configurations plus avancées, ou automatiser la création de DCR.
Chacun de ces exemples se concentre sur une source de données spécifique, bien que vous puissiez combiner plusieurs sources de données de différents types dans une seule DCR. Inclure un flux de données pour chacune d’elles afin d’envoyer les données à la destination appropriée. Il n’existe aucune différence fonctionnelle entre la combinaison de plusieurs sources de données dans une seule DCR ou la création de DCR distinctes pour chaque source de données. Ce choix dépend de vos besoins en matière de gestion et de surveillance de la collecte de données.
Remarque
Les exemples utilisés dans cet article fournissent le JSON source requis pour créer la DCR. Après la création, la DCR a des propriétés supplémentaires, comme décrit dans Structure d’une règle de collecte de données dans Azure Monitor.
Les DCR pour l’agent Azure Monitor
L’agent Azure Monitor s’exécute sur des machines virtuelles, des groupes de machines virtuelles identiques et des clusters Kubernetes. Il prend en charge VM Insights et container Insights et prend également en charge différents scénarios de collecte de données pour les machines virtuelles décrites dans Collecte de données de l’agent Azure Monitor.
Les exemples suivants montrent les DCR utilisées pour collecter différents types de données en utilisant l’agent Azure Monitor.
Événements Windows
Les DCP pour les événements Windows utilisent la source de données windowsEventLogs avec le flux entrant Microsoft-Event. Le schéma de ce flux est connu. Il n’a donc pas besoin d’être défini dans la section dataSources. Les événements à collecter sont spécifiés dans la propriété xPathQueries. Pour plus d’informations sur l’utilisation de XPaths pour filtrer les données spécifiques que vous souhaitez collecter, consulter Collecter des événements Windows avec l’agent Azure Monitor. Pour commencer, vous pouvez utiliser les instructions de cet article pour créer une DCR en utilisant le Portail Azure, puis inspecter le JSON à l’aide des instructions de définition DCR.
Vous pouvez ajouter une transformation à la propriété dataFlows pour les colonnes calculées et pour filtrer davantage les données, mais vous devez utiliser XPaths pour filtrer les données au niveau de l’agent autant que possible pour améliorer l’efficacité et éviter de potentiels frais d’ingestion.
L’exemple de DCR suivant effectue ces actions :
- Collecte les événements système et d’application Windows avec le niveau d’erreur Avertissement, Erreur ou Critique.
- Envoie des données à la table d’événements dans l’espace de travail.
- Utilise une transformation simple d’une
sourcequi n’apporte aucune modification aux données entrantes.
{
"location": "eastus",
"properties": {
"dataSources": {
"windowsEventLogs": [
{
"name": "eventLogsDataSource",
"streams": [
"Microsoft-Event"
],
"xPathQueries": [
"System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
"Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"centralWorkspace"
],
"transformKql": "source",
"outputStream": "Microsoft-Event"
}
]
}
}
Événements Syslog
Les DCR pour les événements Syslog utilisent la source de données syslog avec le flux Microsoft-Syslog entrant. Le schéma de ce flux est connu. Il n’a donc pas besoin d’être défini dans la section dataSources. Les événements à collecter sont spécifiés dans les propriétés facilityNames et logLevels. Pour plus d’informations, consultez Collecter des événements Syslog avec l’agent Azure Monitor. Pour commencer, vous pouvez utiliser les instructions de cet article pour créer une DCR en utilisant le Portail Azure, puis inspecter le JSON à l’aide des instructions de définition DCR.
Vous pouvez ajouter une transformation à la propriété dataFlows pour des fonctionnalités supplémentaires et mieux filtrer les données, mais vous devez utiliser facilityNames et logLevels filtrer autant que possible pour éviter plus efficacement de potentiels frais d’ingestion.
L’exemple de DCR suivant effectue ces actions :
- Collecte tous les événements du site
cron. - Collecte
Warninget les événements de niveau supérieur des sitessyslogetdaemon.- Envoie des données à la table Syslog dans l’espace de travail.
- Utilise une transformation simple d’une
sourcequi n’apporte aucune modification aux données entrantes.
{
"location": "eastus",
"properties": {
"dataSources": {
"syslog": [
{
"name": "cronSyslog",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"cron"
],
"logLevels": [
"Debug",
"Info",
"Notice",
"Warning",
"Error",
"Critical",
"Alert",
"Emergency"
]
},
{
"name": "syslogBase",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"daemon",
"syslog"
],
"logLevels": [
"Warning",
"Error",
"Critical",
"Alert",
"Emergency"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Syslog"
],
"destinations": [
"centralWorkspace"
],
"transformKql": "source",
"outputStream": "Microsoft-Syslog"
}
]
}
}
Compteurs de performance
Les DCR pour les données de niveau de performance utilisent la source de données performanceCounters avec les flux Microsoft-InsightsMetrics et Microsoft-Perf entrants. Microsoft-InsightsMetrics est utilisé pour envoyer des données à Azure Monitor Metrics, tandis que Microsoft-Perf est utilisé pour envoyer des données à un espace de travail Log Analytics. Vous pouvez inclure les deux sources de données dans la DCR si vous envoyez des données de niveau de performance aux deux destinations. Les schémas de ces flux sont connus. Ils n’ont donc pas besoin d’être définis dans la section dataSources.
Les compteurs de niveau de performance à collecter sont spécifiés dans la propriété counterSpecifiers. Pour plus d’informations, consultez Collecter les compteurs de niveau de performance avec l’agent Azure Monitor. Pour commencer, vous pouvez utiliser les instructions de cet article pour créer une DCR en utilisant le Portail Azure, puis inspecter le JSON à l’aide des instructions de définition DCR.
Vous pouvez ajouter une transformation à la propriété dataFlows pour Microsoft-Perf pour des fonctionnalités supplémentaires et mieux filtrer les données, mais vous devez sélectionner uniquement les compteurs dont vous avez besoin dans counterSpecifiers pour éviter plus efficacement de potentiels frais d’ingestion.
L’exemple de DCR suivant effectue ces actions :
- Collecte un ensemble de compteurs de niveau de performance toutes les 60 secondes et un autre ensemble toutes les 30 secondes.
- Envoie des données à Azure Monitor Metrics et à un espace de travail Log Analytics.
- Utilise une transformation simple d’une
sourcequi n’apporte aucune modification aux données entrantes.
{
"location": "eastus",
"properties": {
"dataSources": {
"performanceCounters": [
{
"name": "perfCounterDataSource60",
"streams": [
"Microsoft-Perf",
"Microsoft-InsightsMetrics"
],
"samplingFrequencyInSeconds": 60,
"counterSpecifiers": [
"\\Processor(_Total)\\% Processor Time",
"\\Memory\\Committed Bytes",
"\\LogicalDisk(_Total)\\Free Megabytes",
"\\PhysicalDisk(_Total)\\Avg. Disk Queue Length"
]
},
{
"name": "perfCounterDataSource30",
"streams": [
"Microsoft-Perf"
],
"samplingFrequencyInSeconds": 30,
"counterSpecifiers": [
"\\Process(_Total)\\Thread Count"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
],
"azureMonitorMetrics":
{
"name": "azureMonitorMetrics-default"
}
},
"dataFlows": [
{
"streams": [
"Microsoft-Perf"
],
"destinations": [
"centralWorkspace"
],
"transformKql": "source",
"outputStream": "Microsoft-Perf"
},
{
"streams": [
"Microsoft-Perf"
],
"destinations": [
"azureMonitorMetrics-default"
],
"outputStream": "Microsoft-InsightsMetrics"
}
]
}
}
Journaux texte
Les DCR pour les journaux d’activité texte ont une source de données logfiles qui contient les détails des fichiers journaux qui doivent être collectés par l’agent. Cela inclut le nom d’un flux qui doit être défini dans streamDeclarations avec les colonnes des données entrantes. Il s’agit actuellement d’une liste définie, comme décrit dans Collecter des journaux d’activité depuis un fichier texte avec l’agent Azure Monitor.
Ajoutez une transformation à la propriété dataFlows pour filtrer les enregistrements que vous ne souhaitez pas collecter et mettre en forme les données pour qu’elles correspondent au schéma de la table de destination. Un scénario courant consiste à analyser un fichier journal délimité en plusieurs colonnes, comme décrit dans Fichiers journaux délimités.
L’exemple de DCR suivant effectue ces actions :
- Collecte les entrées de tous les fichiers avec une extension
.txtdans le dossierc:\logsde l’ordinateur agent. - Utilise une transformation pour fractionner les données entrantes en colonnes en fonction d’un séparateur par virgule (
,). Cette transformation est spécifique au format du fichier journal et doit être ajustée pour les fichiers journaux avec d’autres formats. - Envoie les journaux d’activité collectés à une table personnalisée appelée
MyTable_CL. Cette table doit déjà exister et avoir la sortie des colonnes par la transformation. - Collecte
FilePathetComputerpour le journal texte, comme décrit dans Flux entrant. Ces colonnes doivent également exister dans la table de destination.
{
"location": "eastus",
"properties": {
"dataCollectionEndpointId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyLogFileFormat": {
"columns": [
{
"name": "TimeGenerated",
"type": "datetime"
},
{
"name": "RawData",
"type": "string"
},
{
"name": "FilePath",
"type": "string"
},
{
"name": "Computer",
"type": "string"
}
]
}
},
"dataSources": {
"logFiles": [
{
"streams": [
"Custom-MyLogFileFormat"
],
"filePatterns": [
"C:\\logs\\*.txt"
],
"format": "text",
"settings": {
"text": {
"recordStartTimestampFormat": "ISO 8601"
}
},
"name": "myLogFileFormat-Windows"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "MyDestination"
}
]
},
"dataFlows": [
{
"streams": [
"Custom-MyLogFileFormat"
],
"destinations": [
"MyDestination"
],
"transformKql": "source | project d = split(RawData,\",\") | project TimeGenerated=todatetime(d[0]), Code=toint(d[1]), Severity=tostring(d[2]), Module=tostring(d[3]), Message=tostring(d[4])",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
Journaux d’activité JSON
Les DCR pour les journaux d’activité JSON ont une source de données logfiles qui contient les détails des fichiers journaux qui doivent être collectés par l’agent. Cela inclut le nom d’un flux qui doit être défini dans streamDeclarations avec les colonnes des données entrantes. Pour plus d’informations, consultez Collecter les journaux d’activité d’un fichier JSON avec l’agent Azure Monitor.
Ajoutez une transformation à la propriété dataFlows pour filtrer les enregistrements que vous ne souhaitez pas collecter et mettre en forme les données pour qu’elles correspondent au schéma de la table de destination.
L’exemple de DCR suivant effectue ces actions :
- Collecte les entrées de tous les fichiers avec une extension
.jsondans le dossierc:\logsde l’ordinateur agent. Le fichier doit être mis en forme au format JSON et contenir les colonnes répertoriées dans la déclaration de flux. - Envoie les journaux d’activité collectés à une table personnalisée appelée
MyTable_CL. Cette table doit déjà exister et avoir les mêmes colonnes que le flux entrant. Si les colonnes ne correspondent pas, vous devez modifier la transformation dans la propriététransformKqlpour mettre en forme les données de la table cible.
{
"location": "eastus",
"properties": {
"dataCollectionEndpointId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-Json-stream": {
"columns": [
{
"name": "TimeGenerated",
"type": "datetime"
},
{
"name": "FilePath",
"type": "string"
},
{
"name": "Code",
"type": "int"
},
{
"name": "Module",
"type": "string"
},
{
"name": "Message",
"type": "string"
}
]
}
},
"dataSources": {
"logFiles": [
{
"streams": [
"Custom-Json-stream"
],
"filePatterns": [
"C:\\logs\\*.json"
],
"format": "json",
"name": "MyJsonFile"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "MyDestination"
}
]
},
"dataFlows": [
{
"streams": [
"Custom-Json-stream"
],
"destinations": [
"MyDestination"
],
"transformKql": "source",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
Envoyer des données à Event Hubs et Stockage
Les DCR qui envoient des données à des hubs d’événements ou des comptes de stockage utilisent les mêmes sources de données que les autres DCR qui collectent des données avec l’agent Azure Monitor (AMA), mais ont une ou plusieurs des destinations suivantes. Pour plus d’informations, consultez Envoyer des données à Event Hubs and Stockage (préversion).
eventHubsDirectstorageBlobsDirectstorageTablesDirect
Remarque
Les DCR qui envoient des données aux hubs d’événements ou aux comptes de stockage doivent avoir "kind": "AgentDirectToStore"
L’exemple de DCR suivant effectue ces actions :
- Collecte des compteurs de niveau de performance et des événements Windows depuis des machines Windows avec l’agent Azure Monitor (AMA).
- Envoie les données au hub d’événements, au stockage blob et au stockage de tables.
{
"location": "eastus",
"kind": "AgentDirectToStore",
"properties": {
"dataSources": {
"performanceCounters": [
{
"streams": [
"Microsoft-Perf"
],
"samplingFrequencyInSeconds": 10,
"counterSpecifiers": [
"\\Process(_Total)\\Working Set - Private",
"\\Memory\\% Committed Bytes In Use",
"\\LogicalDisk(_Total)\\% Free Space",
"\\Network Interface(*)\\Bytes Total/sec"
],
"name": "perfCounterDataSource"
}
],
"windowsEventLogs": [
{
"streams": [
"Microsoft-Event"
],
"xPathQueries": [
"Application!*[System[(Level=2)]]",
"System!*[System[(Level=2)]]"
],
"name": "eventLogsDataSource"
}
]
},
"destinations": {
"eventHubsDirect": [
{
"eventHubResourceId": "/subscriptions/71b36fb6-4fe4-4664-9a7b-245dc62f2930/resourceGroups/my-resource-group/providers/Microsoft.EventHub/namespaces/my-eventhub-namespace/eventhubs/my-eventhub",
"name": "myEh"
}
],
"storageBlobsDirect": [
{
"storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"containerName": "myperfblob",
"name": "PerfBlob"
},
{
"storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"containerName": "myeventblob",
"name": "EventBlob"
}
],
"storageTablesDirect": [
{
"storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"containerName": "myperftable",
"name": "PerfTable"
},
{
"storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"containerName": "mymyeventtable",
"name": "EventTable"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Perf"
],
"destinations": [
"myEh",
"PerfBlob",
"PerfTable"
]
},
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"myEh",
"EventBlob",
"EventTable"
]
},
]
}
}
API d’ingestion de journaux
Les DCR pour l’API d’ingestion des journaux d’activité doivent définir le schéma du flux entrant dans la section streamDeclarations de la définition DCR. Les données entrantes doivent être mises en forme au format JSON avec un schéma correspondant aux colonnes de cette définition. Aucune transformation n’est requise si ce schéma correspond au schéma de la table cible. Si les schémas ne correspondent pas, vous devez ajouter une transformation à la propriété dataFlows pour mettre en forme les données. Pour plus d’informations, consultez API d’ingestion des journaux d’activité dans Azure Monitor.
L’exemple de DCR ci-dessous contient les détails suivants :
- Envoie les données à une table appelée
MyTable_CLdans un espace de travail appelémy-workspace. Avant d’installer cette DCR, vous devez créer la table avec les colonnes suivantes :- TimeGenerated
- Computer
- AdditionalContext
- ExtendedColumn (défini dans la transformation)
- Applique une transformation aux données entrantes pour les mettre en forme pour la table cible.
Important
Cet exemple n’inclut pas la propriété dataCollectionEndpointId, car elle est créée automatiquement lorsque la DCR est créée. Vous avez besoin de la valeur de cette propriété, car il s’agit de l’URL à laquelle l’application envoie des données. La DCR doit avoir kind:Direct pour que cette propriété soit créée. Pour plus d’informations, consultez Propriétés.
{
"location": "eastus",
"kind": "Direct",
"properties": {
"streamDeclarations": {
"Custom-MyTable": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/cefingestion/providers/microsoft.operationalinsights/workspaces/my-workspace",
"name": "LogAnalyticsDest"
}
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTable"
],
"destinations": [
"LogAnalyticsDest"
],
"transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, ExtendedColumn=tostring(jsonContext.CounterName)",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
DCR de transformation de l’espace de travail
Les DCR de transformation d’espace de travail ont une section datasources vide, car les transformations sont appliquées à toutes les données envoyées aux tables prises en charge dans l’espace de travail. Une et une seule entrée doit être incluse pour workspaceResourceId et une entrée dans dataFlows pour chaque table avec une transformation. "kind": "WorkspaceTransforms" doit également être présent.
L’exemple de DCR ci-dessous contient les détails suivants :
- Transformation de la table
LAQueryLogsqui filtre les requêtes de la table elle-même et ajoute une colonne avec le nom de l’espace de travail. - Transformation de la table
Eventqui filtre les événements d’informations et supprime la colonneParameterXml. Ceci s’applique uniquement aux données provenant de l’agent Log Analytics déprécié et non à l’agent Azure Monitor, comme expliqué dans DCR de transformation de l’espace de travail.
{
"kind": "WorkspaceTransforms",
"location": "eastus",
"properties": {
"dataSources": {},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Table-LAQueryLogs"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | where QueryText !contains 'LAQueryLogs' | extend Context = parse_json(RequestContext) | extend Workspace_CF = tostring(Context['workspaces'][0]) | project-away RequestContext, Context"
},
{
"streams": [
"Microsoft-Table-Event"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | where EventLevelName in ('Error', 'Critical', 'Warning') | project-away ParameterXml"
}
]
}
}
Envoyer des données à plusieurs tables
Il existe plusieurs raisons pour lesquelles vous pourriez vouloir envoyer les données d’une seule source de données à plusieurs tables dans le même espace de travail Log Analytics, notamment les suivantes :
- Économiser sur les coûts d’ingestion en envoyant des enregistrements utilisés pour résoudre des problèmes occasionnels dans une table de journaux d’activité basiques.
- Envoyer des enregistrements ou des colonnes avec des données sensibles à une table avec des autorisations ou des paramètres de rétention différents.
Pour envoyer les données d’une seule source de données à plusieurs tables, créez plusieurs flux de données dans la DCR avec une requête de transformation unique et une table de sortie pour chacune, comme illustré dans le diagramme suivant.
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.
L’exemple suivant filtre les enregistrements envoyés à la table d’événements par l’agent Azure Monitor. Seuls les événements d’avertissement et d’erreur sont envoyés à la table d’événements. Les autres événements sont envoyés à une copie de la table d’événements nommée Event_CL qui est configurée pour les journaux d’activité basiques.
Remarque
Cet exemple nécessite une copie de la table d’événements créée dans le même espace de travail nommé Event_CL.
{
"location": "eastus",
"properties": {
"dataSources": {
"windowsEventLogs": [
{
"name": "eventLogsDataSource",
"streams": [
"Microsoft-Event"
],
"xPathQueries": [
"System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
"Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "MyDestination"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"MyDestination"
],
"transformKql": "source | where EventLevelName in ('Error', 'Warning')",
"outputStream": "Microsoft-Event"
},
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"MyDestination"
],
"transformKql": "source | where EventLevelName !in ('Error', 'Warning')",
"outputStream": "Custom-Event_CL"
}
]
}
}