Procedure consigliate ed esempi per le trasformazioni in Monitoraggio di Azure
Le trasformazioni in Monitoraggio di Azure consentono di filtrare o modificare i dati in ingresso prima dell'invio a un'area di lavoro Log Analytics. Questo articolo fornisce procedure consigliate e consigli per l'uso delle trasformazioni per garantire che siano affidabili e convenienti. Include anche esempi per scenari comuni che è possibile usare per iniziare a creare una trasformazione personalizzata.
Monitorare le trasformazioni
Poiché le trasformazioni non vengono eseguite in modo interattivo, è importante monitorarle per assicurarsi che siano in esecuzione correttamente e non impiegano tempo eccessivo per elaborare i dati. Per informazioni dettagliate sui log e sulle metriche che monitorano l'integrità e le prestazioni delle trasformazioni, vedere Monitorare e risolvere i problemi di raccolta dei dati DCR in Monitoraggio di Azure. Ciò include l'identificazione di eventuali errori che si verificano nel KQL e nelle metriche per tenere traccia della durata di esecuzione.
Importante
Le trasformazioni che richiedono un tempo eccessivo per l'esecuzione possono influire sulle prestazioni della pipeline di raccolta dati e comportano la perdita di dati. Se si nota che una trasformazione richiede troppo tempo, è consigliabile riscrivere la query per ottimizzarne le prestazioni.
Le metriche seguenti vengono raccolte automaticamente per le trasformazioni e devono essere esaminate regolarmente per verificare che le trasformazioni siano ancora in esecuzione come previsto. È anche possibile abilitare i log degli errori DCR per tenere traccia di eventuali errori che si verificano nelle trasformazioni o in altre query.
- Durata della trasformazione dei log al minuto
- Errori di trasformazione dei log al minuto
Inviare dati a una singola destinazione
L'esempio seguente è un DCR per l'agente di Monitoraggio di Azure che invia i dati alla tabella Syslog. In questo esempio la trasformazione filtra i dati per i record con error nel messaggio.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "singleDestinationDCR",
"apiVersion": "2021-09-01-preview",
"location": "eastus",
"properties": {
"dataSources": {
"syslog": [
{
"name": "sysLogsDataSource",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"auth",
"authpriv",
"cron",
"daemon",
"mark",
"kern",
"mail",
"news",
"syslog",
"user",
"uucp"
],
"logLevels": [
"Debug",
"Critical",
"Emergency"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Syslog"
],
"transformKql": "source | where message has 'error'",
"destinations": [
"centralWorkspace"
]
}
]
}
}
]
}
Inviare dati a più destinazioni
Con le trasformazioni, è possibile inviare dati a più destinazioni in un'area di lavoro Log Analytics usando un singolo DCR. Si fornisce una query KQL per ogni destinazione e i risultati di ogni query vengono inviati alla posizione corrispondente. È possibile inviare diversi set di dati a tabelle diverse o usare più query per inviare set di dati diversi alla stessa tabella. Per usare più destinazioni, è attualmente necessario creare manualmente un nuovo record di dominio o modificarne una esistente.
Ad esempio, è possibile inviare i dati degli eventi in Monitoraggio di Azure usando l'API di inserimento dei log. La maggior parte degli eventi deve essere inviata a una tabella di analisi in cui è possibile eseguire query regolarmente, mentre gli eventi di controllo devono essere inviati a una tabella personalizzata configurata per log di base per ridurre i costi.
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 è un record di registrazione dati per i dati dell'API di inserimento log che invia i dati alle tabelle Syslog e SecurityEvent. Questo record di controllo di dominio richiede un dataFlow separato per ognuno con transformKql e OutputStream diversi per ognuno di essi. In questo esempio tutti i dati in ingresso vengono inviati alla tabella Syslog, mentre i dati dannosi vengono inviati anche alla tabella SecurityEvent. Se non si desidera replicare i dati dannosi in entrambe le tabelle, è possibile aggiungere un'istruzione where alla prima query per rimuovere tali record.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "multiDestinationDCR",
"location": "eastus",
"apiVersion": "2021-09-01-preview",
"properties": {
"dataCollectionEndpointId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers//Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyTableRawData": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
},
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | project TimeGenerated = Time, Computer, Message = AdditionalContext",
"outputStream": "Microsoft-Syslog"
},
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | where (AdditionalContext has 'malicious traffic!' | project TimeGenerated = Time, Computer, Subject = AdditionalContext",
"outputStream": "Microsoft-SecurityEvent"
}
]
}
}
]
}
Combinazione di tabelle personalizzate e di Azure
L'esempio seguente è un record di registrazione dati per i dati dell'API di inserimento log che invia dati sia alla tabella Syslog che a una tabella personalizzata con i dati in un formato diverso. Questo record di controllo di dominio richiede un dataFlow separato per ognuno con transformKql e OutputStream diversi per ognuno di essi. Quando si usano tabelle personalizzate, è importante assicurarsi che lo schema della destinazione (tabella personalizzata) contenga le colonne personalizzate (procedura per aggiungere o eliminare colonne personalizzate) che corrispondono allo schema dei record inviati. Ad esempio, se il record ha un campo denominato SyslogMessage, ma la tabella personalizzata di destinazione ha solo TimeGenerated e RawData, si riceverà un evento nella tabella personalizzata con solo il campo TimeGenerated popolato e il campo RawData sarà vuoto. Il campo SyslogMessage verrà eliminato perché lo schema della tabella di destinazione non contiene un campo stringa denominato SyslogMessage.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "multiDestinationDCR",
"location": "eastus",
"apiVersion": "2021-09-01-preview",
"properties": {
"dataCollectionEndpointId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers//Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyTableRawData": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
},
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | project TimeGenerated = Time, Computer, SyslogMessage = AdditionalContext",
"outputStream": "Microsoft-Syslog"
},
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, ExtendedColumn=tostring(jsonContext.CounterName)",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
]
}
Analizzare i dati
Un uso comune delle trasformazioni consiste nell'analizzare i dati in ingresso in più colonne in modo che corrispondano allo schema della tabella di destinazione. Ad esempio, è possibile raccogliere voci da un file di log che non è in un formato strutturato ed è necessario analizzare i dati in colonne per la tabella. Usare l'operatore parse in KQL per estrarre i dati in colonne, ma prestare attenzione a limitare il numero di colonne estratte in una singola istruzione. Un numero eccessivo di estrazione in una singola istruzione può comportare un aumento significativo del tempo di elaborazione. Suddividere invece le estrazioni in più parse istruzioni.
Ad esempio, la query seguente estrae dieci campi da una voce di log usando una singola istruzione di analisi.
source
| parse Message with
* "field1=" Field1: string
" field2=" Field2: string
" field3=" Field3: string
" field4=" Field4: string
" field5=" Field5: string
" field6=" Field6: string
" field7=" Field7: string
" field8=" Field8: string
" field9=" Field9: string
" field10=" Field10: string *
L'istruzione precedente può essere riscritta nel modo seguente per suddividere le estrazione in due istruzioni.
source
| parse Message with
* "field1=" Field1: string
" field2=" Field2: string
" field3=" Field3: string
" field4=" Field4: string
" field5=" Field5: string *
| parse Message with
* " field6=" Field6: string
" field7=" Field7: string
" field8=" Field8: string
" field9=" Field9: string
" field10=" Field10: string *