Transformeringar i Azure Monitor

Transformeringar i Azure Monitor filtrera eller ändra inkommande data innan de skickas till en Log Analytics arbetsyta. Transformeringar körs efter att datakällan levererar data och innan de skickas till målet. De definieras i en datainsamlingsregel (DCR).

Standardtransformeringar använder en KQL-instruktion (Kusto Query Language) som tillämpas individuellt på varje post i inkommande data. Omvandlingar i flera steg utökar den här modellen med en pipeline med deklarativa processorer, där en KQL-fråga är en av många tillgängliga processortyper i transformeringskedjan.

Följande diagram illustrerar omvandlingsprocessen för inkommande data och visar en exempelfråga som kan användas. I det här exemplet samlas endast poster in där kolumnen message innehåller ordet error.

Diagram som visar inmatningstidstransformering för inkommande data.

Tabeller som stöds

Följande tabeller i en Log Analytics-arbetsyta stöder transformeringar.

Skapa en transformation

Vissa scenarier för datainsamling stöder tillägg av en transformering via Azure-portalen, men de flesta scenarier kräver att du skapar en ny DCR med dess JSON-definition eller lägger till en transformering i en befintlig DCR. Se Skapa en transformering i Azure Monitor för olika alternativ och Best-metoder och exempel för omvandlingar i Azure Monitor för exempeltransformeringsfrågor i vanliga scenarier.

Omvandlingar i flera steg (förhandsversion)

Viktigt!

Omvandlingar i flera steg är för närvarande i offentlig förhandsversion. Se Tilläggsvillkor för användning av Microsoft Azure-förhandsversioner för juridiska villkor som gäller för Azure-funktioner som är i beta, förhandsvisning eller på annat sätt ännu inte släppta för allmän tillgänglighet.

Standardtransformeringar tillämpar en enda KQL-fråga på inkommande data under inmatning. Omvandlingar i flera steg utökar den här modellen genom att du kan definiera en bearbetningspipeline som består av flera ordnade bearbetningssteg, som tillämpas som dataflöden genom systemet.

Med transformeringar i flera steg definierar en DCR en databearbetningspipeline i stället för ett enda transformeringssteg. Data flödar genom följande steg:

  1. Datainsamling. Azure Monitor Agent (AMA) samlar in data från resursen baserat på datakällans inställningar i DCR.
  2. Bearbetning på klientsidan. Transformeringar körs lokalt på agenten innan data skickas via nätverket. Omvandlingen gäller för data i dess rådataform, vilket kan skilja sig från standardtabellrepresentationen.
  3. Inmatningstidsbearbetning. När data når Azure Monitor tillämpas transformeringar under inmatningen innan data skrivs till måltabellen i Log Analytics. Den här omvandlingen gäller när data är helt schematiserade och berikade.
  4. Dataleverans. Bearbetade loggar levereras till slutmålet.

Processors

Transformeringar i dcr:er i flera steg definieras med hjälp av processorer – små, deklarativa byggstenar som var och en utför en viss typ av åtgärd. Processorer har följande egenskaper:

  • Komponerbar. Flera processorer kan länkas samman i en enda transformering.
  • Beställd. Processorer körs sekventiellt i den ordning som definieras i omvandlingen.
  • Scenagnostisk. Samma processortyp kan användas mellan olika datakällor, faser eller scenarier, med vissa begränsningar under förhandsversionen.

Varje transformering börjar med en huvudprocessor som konverterar rådata till ett känt schemaiserat tabellformat. Efter rubriken kan du länka ytterligare processorer för att filtrera, mappa, parsa, aggregera, berika eller tillämpa KQL-uttryck på data.

Följande processorfamiljer är tillgängliga:

Familj Processors beskrivning
Header header.Syslog, header.WindowsEvents, header.TextLog, header.StandardStream, header.CustomStreamoch andra Schemaisera rådata i tabellformat. Måste vara den första processorn.
Filter filter.Basic Ta bort poster baserat på villkorsutvärdering.
Map map.Rename, map.Drop Byt namn på, typomvandla eller ta bort kolumner.
Parse parse.JsonPath, parse.XmlPath, parse.CEFAttribute Extrahera fält från JSON-, XML- eller CEF-formaterade strängar.
Aggregation aggregate.Basic Sammanfatta poster med hjälp av aggregeringsoperatorer och grupperingsdimensioner.
Berikning enrich.DNSLookup Slå upp en IP-adress och lägg till en DNS-namnkolumn.
Anpassad omvandling transform.KQL Använd ett godtyckligt KQL-uttryck. Endast på ingestionssidan.

Fullständig processorreferens, inklusive konfigurationsscheman och utdatascheman, finns i DCR-struktur – transformeringar.

Omvandlingar på klientsidan jämfört med inmatningssidan

Varje transformering tilldelas till en specifik bearbetningsfas. Den här skillnaden avgör var beräkning sker, vilka data som skickas via nätverket och vilka kostnader som kan optimeras tidigt.

Aspect Client-side Inmatningstid
Tilldelning Datakälla (dataSources) Dataflöde (dataFlows)
Körs på Azure Monitor Agent (VM) Azure Monitor tjänst
Processor för sidhuvud Datakällaspecifik (till exempel header.Syslog) header.StandardStream eller header.CustomStream
Kostnadsförmån Minskar kostnaderna för nätverk och inmatning genom att filtrera/aggregera innan data lämnar resursen Gäller efter att data schemaiserats och berikats med ytterligare tabellkolumner

En enda DCR kan kombinera både omvandlingar på klientsidan och inmatningstid. Utdata från fasen på klientsidan blir automatiskt indata till inmatningstidssteget.

Överväganden för DCR i flera steg

  • Omvandlingar i flera steg kräver API-version 2025-05-11 eller senare. Avsnittet transformations och transform egenskapen för datakällor och dataflöden identifieras inte av tidigare API-versioner.
  • Egenskapen transform kan inte användas tillsammans med transformKql i varje dataflöde. En DCR kan blanda gamla och nya dataflöden mellan olika strömmar.
  • I förhandsgranskningen måste du manuellt matcha rubrikraden för den efterföljande transformationen mot resultatet från den föregående transformationen. Om du till exempel tillämpar aggregering på en råström med Windows händelser kanske resultatet inte är kompatibelt med motsvarande händelsetabell och inmatningstidstransformeringen bör börja med ett anpassat flödeshuvud.

Designmetod för bearbetning i flera steg

Följ dessa steg när du utformar en DCR i flera steg:

  1. Utvärdera datakällor och mål. Identifiera dina datakälltyper och bestäm var varje typ ska hamna: i standardtabellen som standard eller i en anpassad tabell.
  2. Identifiera aggregeringsbehov. Aggregerade loggar bör gå till en separat tabell eftersom deras form skiljer sig från det råa formuläret.
  3. Planera för differentiell bearbetning. Om du behöver bearbeta delar av samma loggar på olika sätt skapar du flera datakällor av samma typ med olika samlingsinställningar och tillämpar olika omvandlingar på klientsidan på var och en.
  4. Skapa omvandlingar på klientsidan. Använd standardströmmar (Microsoft-*) om utdata behåller huvudschemat eller anpassade strömmar (Custom-*) om det inte gör det. Definiera anpassade strömmar i streamDeclarations.
  5. Definiera dataflöden. Skapa ett dataflöde för varje ström. Använd dataflöden för inmatningstid för att dela en enda ström över flera måltabeller genom att tillämpa olika filtervillkor per dataflöde.

DCR för arbetsytetransformering

Transformeringar definieras i en datainsamlingsregel (DCR), men det finns fortfarande datasamlingar i Azure Monitor som ännu inte använder en DCR. Exempel är resursloggar som samlas in av diagnostikinställningar och programdata som samlas in av Application Insights.

Datainsamlingsregeln för arbetsytetransformering (DCR) är en särskild DCR som tillämpas direkt på en Log Analytics-arbetsyta. Syftet med denna DCR är att utföra transformeringar på data som ännu inte använder en DCR för sin datainsamling och därför inte har något sätt att definiera en transformering.

Det kan bara finnas en arbetsyte-DCR för varje arbetsyta, men den kan innehålla transformeringar för valfritt antal tabeller som stöds. Dessa transformeringar tillämpas på alla data som skickas till dessa tabeller om inte dessa data kom från en annan DCR.

Diagram som visar funktionen av arbetsytans transformations-DCR.

Händelsetabellen används till exempel för att lagra händelser från virtuella Windows-datorer. Om du skapar en transformering i arbetsytans transformerings-DCR för händelsetabellen tillämpas den på händelser som samlas in av virtuella datorer som kör Log Analytics-agenten1 eftersom den här agenten inte använder någon DCR. Omvandlingen ignoreras dock av data som skickas från Azure Monitor Agent (AMA) eftersom den använder en DCR för att definiera sin datainsamling. Du kan fortfarande använda en transformation med Azure Monitor-agenten, men du inkluderar den transformationen i den DCR som är associerad med agenten och inte i DCR:n för arbetsytetransformationer.

Diagram som jämför DCR-standardtransformeringar med DCR för arbetsytetransformering.

1 Log Analytics-agenten har blivit inaktuell, men vissa miljöer kan fortfarande använda den. Det är bara ett exempel på en datakälla som inte använder en DCR.

Azure Monitor-pipeline-transformationer

Azure Monitor pipeline-datatransformeringar erbjuder liknande funktioner som transformeringar på klientsidan i Azure Monitor. Båda låter dig tillämpa en KQL-fråga på inkommande data för att filtrera eller ändra dessa data innan de skickas till nästa steg i dataflödet.

Azure Monitor-transformeringar vid inmatning körs efter att data har tagits emot av Azure Monitor men innan den matas in i Log Analytics-arbetsytan. Azure Monitor-pipelinetransformeringar tillämpas tidigare i dataflödet, vilket möjliggör dataformning och filtrering innan data skickas till Azure Monitor. Detta gör pipelinetransformeringar användbara för att minska datavolymen och nätverksbandbredden när data skickas från kantmiljöer eller miljöer med flera moln.

I följande tabell sammanfattas de viktigaste skillnaderna mellan Azure Monitor pipelinetransformeringar och Azure Monitor inmatningstidstransformationer:

Egenskap Azure Monitor-pipelineomvandlingar Azure Monitor-transformeringar vid inmatning
När det används Innan data skickas till Azure Monitor När data har tagits emot av Azure Monitor.
Innan den lagras på Log Analytics-arbetsytan
Definition Definieras i dataflöden i Azure Monitor-pipeline Definieras i datainsamlingsregler (DCR) i Azure Monitor
Language Kusto Query Language (KQL) Kusto Query Language (KQL)
Stöds sammansättningar? Yes Nej
Är mallen stödd? Yes Nej

De data som matas in i Azure Monitor är en kombination av transformeringen i pipelinen och eventuella efterföljande transformeringar vid inmatning i Azure Monitor. Det enda kravet är att utdataschemat för pipelinetransformeringen måste matcha indataschemat som förväntas av Azure Monitor inmatningstidstransformering. Även om du kan filtrera data i någon av transformeringarna är det i allmänhet mer effektivt att filtrera data i pipelinetransformeringar eftersom det minskar mängden data som skickas via nätverket. Schemat för utdata från Azure Monitor-transformeringen vid inmatning måste matcha schemat för destinationstabellen i Log Analytics-arbetsytan.

Diagram som visar dataflödet från pipelinetransformering till Azure Monitor-transformering till Log Analytics-arbetsyta.

Kostnad för transformeringar

Bearbetning av loggar (transformering och filtrering) i Azure Monitor-molnpipelinen har olika faktureringskonsekvenser beroende på vilken typ av tabell som data matas in i på en Log Analytics-arbetsyta.

Tilläggsloggar

Hjälploggar medför en kostnad för data som bearbetas och data som matas in i en Log Analytics-arbetsyta. Databehandlingsavgiften gäller för alla inkommande data som tas emot av Azure Monitor när målet i en Log Analytics-arbetsyta är en hjälploggstabell. Detta omfattar mängden data som bearbetas av alla transformeringar vid inmatning i Azure Monitor. Avgiften för datainmatning gäller endast de data efter transformeringen vid inmatningstillfället som skickas till en Auxiliary Logs-tabell. Transformeringar kan antingen öka eller minska datastorleken.

Följande tabell visar några exempel:

Inkommande datastorlek Data som har tagits bort eller lagts till genom transformeringens process Data som importeras i en Log Analytics-arbetsyta som en hjälploggstabell Fakturerbara GB:er för databearbetning Fakturerbara GB:er för datainmatning
20 GB 12 GB har förlorats 8 GB 20 GB 8 GB
20 GB 8 GB minskat 12 GB 20 GB 12 GB
20 GB 4 GB har lagts till 24 GB 20 GB 24 GB

Se Prissättning för Azure Monitor för priser för loggbearbetning och loggdatainmatning.

Analys- eller grundläggande loggar

För analys- eller grundläggande loggar medför transformeringar i sig vanligtvis inte några kostnader, men följande scenarier kan resultera i ytterligare avgifter:

  • Om en transformering ökar storleken på inkommande data, till exempel genom att lägga till en beräknad kolumn, debiteras du standardinmatningshastigheten för extra data.
  • Om en transformering minskar inmatade data med mer än 50%debiteras du för mängden filtrerade data över 50%.

Använd följande formel för att beräkna databearbetningsavgiften till följd av transformeringar:

[GB data som förlorats vid transformering] – ([GB inkommande datavolym] / 2).

Följande tabell visar exempel.

Inkommande datastorlek Data som har tagits bort eller lagts till genom transformeringens process Data som matas in i en Log Analytics-arbetsyta som en Analys- eller Basic Logs-tabell Fakturerbara GB:er för databearbetning Fakturerbara GB:er för datainmatning
20 GB 12 GB har förlorats 8 GB 2 GB 8 GB
20 GB 8 GB minskat 12 GB 0 GB 12 GB
20 GB 4 GB har lagts till 24 GB 0 GB 24 GB

För att undvika den här avgiften bör du filtrera inmatade data med hjälp av alternativa metoder innan du tillämpar transformeringar. På så sätt kan du minska mängden data som bearbetas av transformeringar och därmed minimera eventuella ytterligare kostnader.

Se Prissättning för Azure Monitor för priser för loggbearbetning och loggdatainmatning.

Viktigt!

Om Microsoft Sentinel är aktiverat för Log Analytics-arbetsytan kostar det ingen kostnad för transformering till Analytics-tabeller oavsett hur mycket data transformeringsfiltren filtrerar.