Esempi di regole di raccolta dati in Monitoraggio di Azure
Questo articolo include regole di raccolta dati di esempio per scenari comuni di raccolta dati in Monitoraggio di Azure. È possibile modificare queste definizioni DCR in base alle esigenze per l'ambiente e creare il Registro Azure Container usando le indicazioni riportate in Creare o modificare una regola di raccolta dati. È anche possibile usare e combinare le strategie di base in questi esempi per creare controller di dominio per altri scenari.
Questi esempi richiedono una conoscenza della struttura DCR come descritto in Struttura di una regola di raccolta dati in Monitoraggio di Azure. È possibile configurare diversi elementi usando l'portale di Azure senza alcuna conoscenza dettagliata della struttura DCR. Usare questi esempi quando è necessario usare la definizione DCR stessa per eseguire configurazioni più avanzate o per automatizzare la creazione di controller di dominio.
Ognuno di questi esempi è incentrato su una particolare origine dati, anche se è possibile combinare più origini dati di tipi diversi in un singolo DCR. Includere un flusso di dati per ognuno per inviare i dati alla destinazione appropriata. Non esiste alcuna differenza funzionale tra la combinazione di più origini dati in un singolo DCR o la creazione di controller di dominio separati per ogni origine dati. La scelta dipende dai requisiti per la gestione e il monitoraggio della raccolta dati.
Nota
Questi esempi illustrati in questo articolo forniscono il codice JSON di origine necessario per creare il record di controllo di dominio. Dopo la creazione, la regola di raccolta dati avrà proprietà aggiuntive, come descritto in Struttura di una regola di raccolta dati in Monitoraggio di Azure.
Controller di dominio per l'agente di Monitoraggio di Azure
L'agente di Monitoraggio di Azure viene eseguito in macchine virtuali, set di scalabilità di macchine virtuali e cluster Kubernetes. Supporta informazioni dettagliate sulle macchine virtuali e informazioni dettagliate sui contenitori e supporta diversi scenari di raccolta dati per le macchine virtuali descritte nella raccolta dati dell'agente di Monitoraggio di Azure.
Gli esempi seguenti illustrano i controller di dominio per la raccolta di diversi tipi di dati usando l'agente di Monitoraggio di Azure.
Eventi Windows
I controller di dominio per gli eventi di Windows usano l'origine windowsEventLogs
dati con il Microsoft-Event
flusso in ingresso. Lo schema di questo flusso è noto, quindi non deve essere definito nella dataSources
sezione . Gli eventi da raccogliere vengono specificati nella xPathQueries
proprietà . Per altri dettagli sull'uso di XPaths per filtrare i dati specifici da raccogliere, vedere Raccogliere eventi di Windows con l'agente di Monitoraggio di Azure. Per iniziare, è possibile usare le linee guida contenute in questo articolo per creare un record di dominio usando il portale di Azure e quindi esaminare il codice JSON usando le linee guida riportate nella definizione del Registro Azure Container.
È possibile aggiungere una trasformazione alla dataFlows
proprietà per le colonne calcolate e per filtrare ulteriormente i dati, ma è consigliabile usare XPath per filtrare i dati nell'agente il più possibile per l'efficienza ed evitare potenziali addebiti per l'inserimento.
Il DCR di esempio seguente esegue le azioni seguenti:
- Raccoglie gli eventi di sistema e dell'applicazione Windows con livello di errore Avviso, Errore o Critico.
- Invia i dati alla tabella Event nell'area di lavoro.
- Usa una semplice trasformazione di un oggetto
source
che non apporta alcuna modifica ai dati in ingresso.
{
"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"
}
]
}
}
Eventi SysLog
I controller di dominio per gli eventi Syslog usano l'origine syslog
dati con il flusso in ingresso Microsoft-Syslog
. Lo schema di questo flusso è noto, quindi non deve essere definito nella dataSources
sezione . Gli eventi da raccogliere vengono specificati nelle facilityNames
proprietà e logLevels
. Per altri dettagli, vedere Raccogliere eventi Syslog con l'agente di Monitoraggio di Azure. Per iniziare, è possibile usare le linee guida contenute in questo articolo per creare un record di dominio usando il portale di Azure e quindi esaminare il codice JSON usando le linee guida riportate nella definizione del Registro Azure Container.
È possibile aggiungere una trasformazione alla dataFlows
proprietà per funzionalità aggiuntive e per filtrare ulteriormente i dati, ma è consigliabile usare facilityNames
e logLevels
per filtrare il più possibile in modo da evitare potenziali addebiti per l'inserimento.
Il DCR di esempio seguente esegue le azioni seguenti:
- Raccoglie tutti gli eventi dalla
cron
struttura. Warning
Raccoglie e più eventi dasyslog
edaemon
strutture.- Invia dati alla tabella Syslog nell'area di lavoro.
- Usa una semplice trasformazione di un oggetto
source
che non apporta alcuna modifica ai dati in ingresso.
{
"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"
}
]
}
}
Contatori delle prestazioni
I controller di dominio per i dati sulle prestazioni usano l'origine performanceCounters
dati con i flussi e Microsoft-Perf
in ingressoMicrosoft-InsightsMetrics
. Microsoft-InsightsMetrics
viene usato per inviare dati alle metriche di Monitoraggio di Azure, mentre Microsoft-Perf
viene usato per inviare dati a un'area di lavoro Log Analytics. È possibile includere entrambe le origini dati nel Registro Azure Container se si inviano dati sulle prestazioni a entrambe le destinazioni. Gli schemi di questi flussi sono noti, quindi non devono essere definiti nella dataSources
sezione .
I contatori delle prestazioni da raccogliere vengono specificati nella counterSpecifiers
proprietà . Per altri dettagli, vedere Raccogliere contatori delle prestazioni con l'agente di Monitoraggio di Azure. Per iniziare, è possibile usare le linee guida contenute in questo articolo per creare un record di dominio usando il portale di Azure e quindi esaminare il codice JSON usando le linee guida riportate nella definizione del Registro Azure Container.
È possibile aggiungere una trasformazione alla dataFlows
proprietà per Microsoft-Perf
altre funzionalità e per filtrare ulteriormente i dati, ma è consigliabile selezionare solo i contatori necessari per counterSpecifiers
garantire l'efficienza in per evitare potenziali addebiti per l'inserimento.
Il DCR di esempio seguente esegue le azioni seguenti:
- Raccoglie un set di contatori delle prestazioni ogni 60 secondi e un altro set ogni 30 secondi.
- Invia dati alle metriche di Monitoraggio di Azure e a un'area di lavoro Log Analytics.
- Usa una semplice trasformazione di un oggetto
source
che non apporta alcuna modifica ai dati in ingresso.
{
"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"
}
]
}
}
Log di testo
I controller di dominio per i log di testo hanno un'origine logfiles
dati con i dettagli per i file di log che devono essere raccolti dall'agente. Questo include il nome di un flusso che deve essere definito in streamDeclarations
con le colonne dei dati in ingresso. Questo è attualmente un elenco di set come descritto in Raccogliere i log da un file di testo con l'agente di Monitoraggio di Azure.
Aggiungere una trasformazione alla dataFlows
proprietà per filtrare i record che non si desidera raccogliere e formattare i dati in modo che corrispondano allo schema della tabella di destinazione. Uno scenario comune consiste nell'analizzare un file di log delimitato in più colonne, come descritto in File di log delimitati.
Il DCR di esempio seguente esegue le azioni seguenti:
- Raccoglie le voci da tutti i file con estensione di
.txt
nellac:\logs
cartella del computer agente. - Usa una trasformazione per suddividere i dati in ingresso in colonne in base a un delimitatore virgola (
,
). Questa trasformazione è specifica del formato del file di log e deve essere modificata per i file di log con altri formati. - Invia i log raccolti a una tabella personalizzata denominata
MyTable_CL
. Questa tabella deve esistere già e avere l'output delle colonne dalla trasformazione . - Raccoglie e per il
FilePath
log di testo come descritto in Flusso in ingresso.Computer
Queste colonne devono esistere anche nella tabella di destinazione.
{
"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"
}
]
}
}
Log JSON
I controller di dominio per i log JSON hanno un'origine logfiles
dati con i dettagli per i file di log che devono essere raccolti dall'agente. Questo include il nome di un flusso che deve essere definito in streamDeclarations
con le colonne dei dati in ingresso. Per altri dettagli, vedere Raccogliere log da un file JSON con l'agente di Monitoraggio di Azure.
Aggiungere una trasformazione alla dataFlows
proprietà per filtrare i record che non si desidera raccogliere e formattare i dati in modo che corrispondano allo schema della tabella di destinazione.
Il DCR di esempio seguente esegue le azioni seguenti:
- Raccoglie le voci da tutti i file con estensione di
.json
nellac:\logs
cartella del computer agente. Il file deve essere formattato in json e avere le colonne elencate nella dichiarazione del flusso. - Invia i log raccolti a una tabella personalizzata denominata
MyTable_CL
. Questa tabella deve esistere già e avere le stesse colonne del flusso in ingresso. Se le colonne non corrispondono, è necessario modificare la trasformazione nellatransformKql
proprietà per formattare i dati per la tabella di destinazione.
{
"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"
}
]
}
}
Inviare dati a Hub eventi o archiviazione
I controller di dominio che inviano dati agli hub eventi o agli account di archiviazione usano le stesse origini dati di altri controller di dominio che raccolgono dati con l'agente di Monitoraggio di Azure, ma hanno una o più delle destinazioni seguenti. Per altri dettagli, vedere Inviare dati a Hub eventi e archiviazione (anteprima).
eventHubsDirect
storageBlobsDirect
storageTablesDirect
Nota
I controller di dominio che inviano dati agli hub eventi o agli account di archiviazione devono avere "kind": "AgentDirectToStore"
Il DCR di esempio seguente esegue le azioni seguenti:
- Raccoglie i contatori delle prestazioni e gli eventi di Windows dai computer Windows con l'agente di Monitoraggio di Azure .
- Invia i dati all'hub eventi, all'archiviazione BLOB e all'archiviazione tabelle.
{
"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 di inserimento dei log
I controller di dominio per l'API di inserimento dei log devono definire lo schema del flusso in ingresso nella streamDeclarations
sezione della definizione DCR. I dati in ingresso devono essere formattati in JSON con uno schema corrispondente alle colonne in questa definizione. Non è necessaria alcuna trasformazione se questo schema corrisponde allo schema della tabella di destinazione. Se gli schemi non corrispondono, è necessario aggiungere una trasformazione alla dataFlows
proprietà per formattare i dati. Per altri dettagli, vedere l'API di inserimento dei log in Monitoraggio di Azure.
Il DCR di esempio seguente contiene i dettagli seguenti:
- Invia dati a una tabella denominata
MyTable_CL
in un'area di lavoro denominatamy-workspace
. Prima di installare questo DCR, è necessario creare la tabella con le colonne seguenti:- TimeGenerated
- Computer
- AdditionalContext
- ExtendedColumn (definito nella trasformazione)
- Applica una trasformazione ai dati in ingresso per formattare i dati per la tabella di destinazione.
Importante
Questo esempio non include la dataCollectionEndpointId
proprietà perché viene creata automaticamente al momento della creazione del record di dominio. È necessario il valore di questa proprietà perché si tratta dell'URL a cui l'applicazione invierà i dati. Per creare questa proprietà, è necessario che kind:Direct
il record di controllo di dominio sia necessario. Per altri dettagli, vedere Proprietà .
{
"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"
}
]
}
}
Regole di raccolta dati per la trasformazione dell'area di lavoro
I controller di dominio di trasformazione dell'area di lavoro hanno una sezione vuota datasources
perché le trasformazioni vengono applicate a tutti i dati inviati alle tabelle supportate nell'area di lavoro. Deve includere una voce e solo per workspaceResourceId
e una voce in dataFlows
per ogni tabella con una trasformazione. Deve anche avere "kind": "WorkspaceTransforms"
.
Il DCR di esempio seguente contiene i dettagli seguenti:
- Trasformazione per la
LAQueryLogs
tabella che filtra le query della tabella stessa e aggiunge una colonna con il nome dell'area di lavoro. - Trasformazione per la
Event
tabella che filtra gli eventi Di informazioni e rimuove laParameterXml
colonna. Questo vale solo per i dati provenienti dall'agente di Log Analytics deprecato e non dall'agente di Monitoraggio di Azure, come illustrato in DCR trasformazione Area di lavoro.
{
"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"
}
]
}
}
Inviare dati a più tabelle
Esistono diversi motivi per cui è consigliabile inviare dati da una singola origine dati a più tabelle nella stessa area di lavoro Log Analytics, tra cui:
- Risparmiare sui costi di inserimento inviando record usati per la risoluzione dei problemi occasionali in una tabella dei log di base.
- Inviare record o colonne con dati sensibili a una tabella con autorizzazioni o impostazioni di conservazione diverse.
Per inviare dati da una singola origine dati a più tabelle, creare più flussi di dati nel Registro Azure Container con una query di trasformazione e una tabella di output univoca per ognuna, come illustrato nel diagramma seguente.
Importante
Attualmente, le tabelle nel Registro Azure Container devono trovarsi nella stessa area di lavoro Log Analytics. Per inviare a più aree di lavoro da una singola origine dati, usare più controller di dominio e configurare l'applicazione per inviare i dati a ognuno.
L'esempio seguente filtra i record inviati alla tabella eventi dall'agente di Monitoraggio di Azure. Solo gli eventi di avviso e di errore vengono inviati alla tabella Event. Altri eventi vengono inviati a una copia della tabella eventi denominata Event_CL configurata per i log di base.
Nota
Questo esempio richiede una copia della tabella Event creata nella stessa area di lavoro denominata 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"
}
]
}
}