Trasformazioni in Monitoraggio di Azure

Le trasformazioni in Monitoraggio di Azure filtrano o modificano i dati in ingresso prima che vengano inviati a un'area di lavoro Log Analytics. Le trasformazioni vengono eseguite dopo che l'origine dati recapita i dati e prima che vengano inviati alla destinazione. Sono definiti in una regola di raccolta dati (DCR).

Le trasformazioni standard utilizzano un'istruzione KQL (Kusto Query Language) applicata singolarmente a ogni elemento dei dati in ingresso. Le trasformazioni in più fasi estendono questo modello con una pipeline di processori dichiarativi, in cui una query KQL è uno dei molti tipi di processori disponibili nella catena di trasformazione.

Il diagramma seguente illustra il processo di trasformazione per i dati in ingresso e mostra una query di esempio che potrebbe essere usata. In questo esempio vengono raccolti solo i record in cui la message colonna contiene la parola error .

Tabelle supportate

Le tabelle seguenti in un'area di lavoro Log Analytics supportano le trasformazioni.

Qualsiasi tabella di Azure elencata in tabelle che supportano le trasformazioni nei log di Monitoraggio di Azure. Il riferimento ai dati Monitoraggio di Azure include anche se la tabella supporta trasformazioni ed elenca altri attributi per ogni tabella.
Qualsiasi tabella personalizzata creata per l'agente di Monitoraggio di Azure
Tabelle personalizzate con il Piano ausiliario.

Creare una trasformazione

Alcuni scenari di raccolta dati supportano l'aggiunta di una trasformazione tramite il portale di Azure, ma la maggior parte degli scenari richiede la creazione di un nuovo record di dominio usando la definizione JSON o l'aggiunta di una trasformazione a un record di dominio esistente. Vedere Creare una trasformazione in Monitoraggio di Azure per le diverse opzioni e Procedure consigliate ed esempi per le trasformazioni in Monitoraggio di Azure per esempi di query di trasformazione per scenari comuni.

Trasformazioni in più fasi (anteprima)

Importante

Le trasformazioni in più fasi sono attualmente in anteprima pubblica. Vedi le Condizioni supplementari d'uso per le anteprime di Microsoft Azure per conoscere le condizioni legali applicabili alle funzionalità di Azure che sono in beta, in anteprima o non ancora rilasciate nella disponibilità generale.

Le trasformazioni standard applicano una singola query KQL ai dati in ingresso durante l'inserimento. Le trasformazioni in più fasi estendono questo modello consentendo di definire una pipeline di elaborazione composta da più fasi di elaborazione ordinate, applicate come flussi di dati attraverso il sistema.

Con le trasformazioni multifase, un DCR definisce una pipeline di elaborazione dei dati anziché una singola fase di trasformazione. I dati passano attraverso le fasi seguenti:

Raccolta dei dati. Monitoraggio di Azure Agent (AMA) raccoglie dati dalla risorsa in base alle impostazioni dell'origine dati nella DCR.
Elaborazione lato client. Le trasformazioni vengono eseguite localmente nell'agente prima dell'invio dei dati in rete. La trasformazione si applica ai dati nel formato non elaborato, che potrebbero differire dalla rappresentazione di tabella standard.
Elaborazione del tempo di ingestione. Dopo che i dati raggiungono Monitoraggio di Azure, le trasformazioni vengono applicate durante l'inserimento prima che i dati vengano scritti nella tabella di destinazione in Log Analytics. Questa trasformazione si applica dopo che i dati sono completamente schematizzati e arricchiti.
Recapito dei dati. I log elaborati vengono recapitati alla destinazione finale.

Processors

Le trasformazioni nei DCR multi-stage sono definite mediante processori, piccoli blocchi costitutivi dichiarativi, ciascuno dei quali esegue un tipo specifico di operazione. I processori hanno le caratteristiche seguenti:

Componibile. È possibile concatenare più processori in una singola trasformazione.
Ordinato. I processori vengono eseguiti in sequenza nell'ordine definito nella trasformazione.
Indipendente dall'ambiente. Lo stesso tipo di processore può essere usato in diverse origini dati, fasi o scenari, con alcune limitazioni durante l'anteprima.

Ogni trasformazione inizia con un processore di intestazione che converte i dati non elaborati in un formato tabulare schematizzato noto. Dopo l'intestazione, è possibile concatenare processori aggiuntivi per filtrare, mappare, analizzare, aggregare, arricchire o applicare espressioni KQL ai dati.

Sono disponibili le famiglie di processori seguenti:

Famiglia	Processors	Descrizione
Intestazione	`header.Syslog`, `header.WindowsEvents`, , `header.TextLog`, `header.StandardStreamheader.CustomStream`e altri	Schematizza i dati non elaborati in un formato tabulare. Deve essere il primo processore.
Filter	`filter.Basic`	Elimina i record in base alla valutazione della condizione.
Map	`map.Rename`, `map.Drop`	Rinominare, digitare o eliminare colonne.
Parse	`parse.JsonPath`, `parse.XmlPath`, `parse.CEFAttribute`	Estrarre campi da stringhe in formato JSON, XML o CEF.
Aggregazione	`aggregate.Basic`	Riepilogare i record usando operatori di aggregazione con dimensioni di raggruppamento.
Arricchimento	`enrich.DNSLookup`	Cercare un indirizzo IP e aggiungere una colonna del nome DNS.
Trasformazione personalizzata	`transform.KQL`	Applica una qualsiasi espressione KQL. Solo lato ingestione.

Per informazioni di riferimento complete sul processore, inclusi gli schemi di configurazione e gli schemi di output, vedere Struttura DCR - Trasformazioni.

Trasformazioni lato client rispetto a quelle lato ingestione

Ogni trasformazione viene assegnata a una fase di elaborazione specifica. Questa distinzione determina dove avviene il calcolo, quali dati vengono inviati in rete e quali costi possono essere ottimizzati in anticipo.

Aspect	Lato client	Tempo di ingestione
Assegnazione	Origine dati (`dataSources`)	Flusso di dati (`dataFlows`)
Viene eseguita in	Agente di Monitoraggio di Azure (VM)	servizio Monitoraggio di Azure
Processore di intestazione	Specifico dell'origine dati (ad esempio, `header.Syslog`)	`header.StandardStream` oppure `header.CustomStream`
Vantaggi economici	Riduce i costi di rete e inserimento filtrando/aggregando prima che i dati lascino la risorsa	Si applica dopo che i dati vengono schematizzati e arricchiti con colonne di tabella aggiuntive

Un singolo DCR può combinare sia trasformazioni lato client sia trasformazioni in fase di inserimento. Il risultato della fase lato client diventa automaticamente l'input della fase di ingestione.

Considerazioni sul DCR in più fasi

Le trasformazioni in più fasi richiedono la versione 2025-05-11 dell'API o versioni successive. La transformations sezione e la transform proprietà sulle origini dati e i flussi di dati non vengono riconosciute dalle versioni precedenti dell'API.
La proprietà transform è mutuamente esclusiva con transformKql per flusso di dati. Un DCR può combinare flussi di dati vecchi e nuovi tra flussi diversi.
In fase di anteprima, è necessario coordinare manualmente l'intestazione della trasformazione a valle con l'output della trasformazione a monte. Ad esempio, se si applica l'aggregazione a un flusso non elaborato di eventi Windows, il risultato potrebbe non essere compatibile con la tabella Event corrispondente e la trasformazione in fase di inserimento deve iniziare con un'intestazione di flusso personalizzata.

Approccio di progettazione per l'elaborazione a più fasi

Seguire questi passaggi durante la progettazione di un DCR multistadio:

Valutare le origini dati e le destinazioni. Identificate i tipi di origine dei dati e decidete dove collocare ciascuno: nella tabella standard predefinita o in una tabella personalizzata.
Identificare le esigenze di aggregazione. I log aggregati devono passare a una tabella separata perché la forma è diversa dal formato non elaborato.
Pianificare l'elaborazione differenziale. Se è necessario elaborare parti degli stessi log in modo diverso, creare più origini dati dello stesso tipo con impostazioni di raccolta diverse e applicare trasformazioni lato client diverse a ognuna.
Autore di trasformazioni lato client. Usare i flussi standard (Microsoft-*) se l'output mantiene lo schema dell'intestazione, oppure i flussi personalizzati (Custom-*) in caso contrario. Definire flussi personalizzati in streamDeclarations.
Definire i flussi di dati. Per ogni flusso, creare un flusso di dati. Usare i flussi di dati in fase di inserimento per suddividere un singolo flusso tra più tabelle di destinazione applicando criteri di filtro diversi per ogni flusso di dati.

DCR di trasformazione dell'area di lavoro

Le trasformazioni vengono definite in una regola di raccolta dati (DCR), ma esistono ancora raccolte di dati in Monitoraggio di Azure che non usano ancora una DCR. Alcuni esempi includono i log delle risorse raccolti dalle impostazioni di diagnostica e dai dati dell'applicazione raccolti da Application Insights.

La regola di raccolta dati (DCR) della trasformazione dell'area di lavoro è una DCR speciale applicata direttamente a un'area di lavoro Log Analytics. Lo scopo di questo DCR consiste nell'eseguire trasformazioni sui dati che non utilizzano ancora un DCR per la loro raccolta e quindi non hanno modo di definire una trasformazione.

Per ogni area di lavoro può essere presente una sola DCR; tuttavia, la suddetta può includere trasformazioni per un numero qualsiasi di tabelle supportate. Queste trasformazioni vengono applicate a tutti i dati inviati a queste tabelle, a meno che tali dati non provengano da un'altra DCR.

Ad esempio, la tabella Event viene usata per archiviare gli eventi dalle macchine virtuali Windows. Se si crea una trasformazione per la tabella Eventi nella DCR di trasformazione dell'area di lavoro, la trasformazione verrà applicata agli eventi raccolti dalle macchine virtuali che eseguono l'agente di Log Analytics ¹ perché questo agente non usa una DCR. La trasformazione verrebbe ignorata dai dati inviati dall'Agente di Monitoraggio di Azure (AMA) in quanto utilizza una DCR per definire la propria raccolta dei dati. È comunque possibile usare una trasformazione con l'Agente di Monitoraggio di Azure, ma è necessario includerla nella DCR associata all'agente e non a quella di trasformazione dell'area di lavoro.

¹ L'agente Log Analytics è stato deprecato, ma alcuni ambienti potrebbero comunque usarlo. È solo un esempio di una fonte di dati che non utilizza un DCR.

Trasformazioni della pipeline di Monitoraggio di Azure

Le trasformazioni dei dati della pipeline di Monitoraggio di Azure offrono funzionalità simili a quelle delle trasformazioni lato client in Monitoraggio di Azure. Entrambi consentono di applicare una query KQL ai dati in ingresso per filtrare o modificare tali dati prima che venga inviato al passaggio successivo del flusso di dati.

Le trasformazioni in fase di acquisizione di Monitoraggio di Azure vengono eseguite dopo che i dati sono stati ricevuti da Monitoraggio di Azure, ma prima che vengano acquisiti nell'area di lavoro Log Analytics. Le trasformazioni della pipeline di Monitoraggio di Azure vengono applicate all'inizio del flusso di dati, consentendo la modellatura e il filtraggio dei dati prima dell'invio ad Monitoraggio di Azure. Ciò rende le trasformazioni della pipeline utili per ridurre il volume di dati e la larghezza di banda di rete quando si inviano dati da ambienti perimetrali o multicloud.

La tabella seguente riepiloga le principali differenze tra le trasformazioni della pipeline di Monitoraggio di Azure e le trasformazioni in fase di inserimento di Monitoraggio di Azure:

Caratteristica / Funzionalità	Trasformazioni della pipeline di Monitoraggio di Azure	Trasformazioni del tempo di ingestione in Monitoraggio di Azure
Se applicato	Prima dell'invio dei dati ad Monitoraggio di Azure	Dopo che i dati vengono ricevuti da Monitoraggio di Azure. Prima di archiviarla nell'area di lavoro Log Analytics
Definition	Definito nei flussi di dati nella pipeline di Monitoraggio di Azure	Definito nelle regole di raccolta dati (DCR) in Monitoraggio di Azure
Language	Linguaggio di query Kusto (KQL)	Linguaggio di query Kusto (KQL)
Aggregazioni supportate?	Yes	NO
Modello supportato?	Yes	NO

I dati acquisiti in monitoraggio di Azure derivano dalla combinazione della trasformazione della pipeline e di eventuali successive trasformazioni in fase di acquisizione in monitoraggio di Azure. L'unico requisito è che lo schema di output della trasformazione della pipeline corrisponda allo schema di input previsto dalla trasformazione in fase di inserimento di Monitoraggio di Azure. Sebbene sia possibile filtrare i dati in una delle due trasformazioni, è in genere più efficiente filtrare i dati nelle trasformazioni della pipeline, in quanto ciò riduce la quantità di dati inviati in rete. Lo schema dei dati in output dalla trasformazione in fase di inserimento di Monitoraggio di Azure deve corrispondere allo schema della tabella di destinazione nell'area di lavoro Log Analytics.

Costo per le trasformazioni

L'elaborazione dei log (trasformazione e filtro) nella pipeline cloud di Monitoraggio di Azure ha implicazioni di fatturazione diverse a seconda del tipo di tabella in cui vengono inseriti i dati in un'area di lavoro Log Analytics.

Log ausiliari

I log ausiliari assegnano un costo per i dati elaborati e i dati inseriti in un'area di lavoro Log Analytics. L'addebito per l'elaborazione dati si applica a tutti i dati in ingresso ricevuti dal Monitoraggio di Azure se la destinazione in un'area di lavoro Log Analytics è una tabella Log ausiliari. Questo include la quantità di dati elaborati da eventuali trasformazioni in fase di ingestione di Monitoraggio di Azure. L'addebito per l'acquisizione dei dati si applica solo ai dati dopo la trasformazione eseguita in fase di acquisizione e inviati a una tabella Auxiliary Logs. Le trasformazioni possono aumentare o ridurre le dimensioni dei dati.

La tabella seguente illustra alcuni esempi:

Dimensioni dei dati in ingresso	Dati eliminati o aggiunti dalla trasformazione	Dati acquisiti in uno spazio di lavoro di Log Analytics come tabella di log ausiliari	GB fatturabili per l'elaborazione dei dati	GB fatturabili per l'inserimento dati
20 GB	12 GB eliminati	8GB	20 GB	8GB
20 GB	8 GB eliminati	12 GB	20 GB	12 GB
20 GB	4 GB aggiunti	24 GB	20 GB	24 GB

Vedere Prezzi di Monitoraggio di Azure per i prezzi per l'elaborazione dei log e l'inserimento dei dati di log.

Log analitici o di base

Per l'analisi o i log di base, le trasformazioni in genere non comportano costi, ma gli scenari seguenti possono comportare costi aggiuntivi:

Se una trasformazione aumenta le dimensioni dei dati in ingresso, ad esempio aggiungendo una colonna calcolata, viene addebitata la tariffa di inserimento standard per i dati aggiuntivi.
Se una trasformazione riduce i dati inseriti di oltre il 50%, verrà addebitato l'importo dei dati filtrati superiore al 50%.

Per calcolare l'addebito per l'elaborazione dati risultante dalle trasformazioni, usare la formula seguente:

[GB dati scartati dalla trasformazione] - ([GB dati in ingresso] / 2).

Nella tabella seguente sono illustrati alcuni esempi.

Dimensioni dei dati in ingresso	Dati eliminati o aggiunti dalla trasformazione	Dati inseriti in un'area di lavoro di Log Analytics come tabella di analisi o log di base	GB fatturabili per l'elaborazione dei dati	GB fatturabili per l'inserimento dati
20 GB	12 GB eliminati	8GB	2GB	8GB
20 GB	8 GB eliminati	12 GB	0 GB	12 GB
20 GB	4 GB aggiunti	24 GB	0 GB	24 GB

Per evitare questo addebito, è consigliabile filtrare i dati inseriti usando metodi alternativi prima di applicare trasformazioni. In questo modo, è possibile ridurre la quantità di dati elaborati dalle trasformazioni e, di conseguenza, ridurre al minimo eventuali costi aggiuntivi.