Optimera loggfrågor i Azure Monitor

Azure Monitor-loggar använder Azure Data Explorer för att lagra loggdata och köra frågor för att analysera dessa data. Den skapar, hanterar och underhåller Azure Data Explorer-kluster åt dig och optimerar dem för din logganalysarbetsbelastning. När du kör en fråga optimeras den och dirigeras till lämpligt Azure Data Explorer-kluster som lagrar arbetsytedata.

Azure Monitor-loggar och Azure Data Explorer använder många mekanismer för automatisk frågeoptimering. Automatiska optimeringar ger en betydande ökning, men det finns vissa fall där du kan förbättra frågeprestandan avsevärt. Den här artikeln beskriver prestandaöverväganden och flera tekniker för att åtgärda dem.

De flesta av teknikerna är vanliga för frågor som körs direkt i Azure Data Explorer och Azure Monitor-loggar. Flera unika överväganden för Azure Monitor-loggar diskuteras också. Fler optimeringstips för Azure Data Explorer finns i Avsnittet om metodtips för frågor.

Optimerade frågor kommer att:

• Kör snabbare och minska den totala varaktigheten för frågekörningen.
• Har mindre chans att begränsas eller avvisas.

Var särskilt uppmärksam på frågor som används för återkommande och samtidig användning, till exempel instrumentpaneler, aviseringar, Azure Logic Apps och Power BI. Effekten av en ineffektiv fråga i dessa fall är betydande.

Här är en detaljerad videogenomgång om hur du optimerar frågor.

Fönstret Frågeinformation

När du har kört en fråga i Log Analytics väljer du Frågeinformation längst ned till höger på skärmen för att öppna fönstret Frågeinformation . Det här fönstret visar resultatet av flera prestandaindikatorer för frågan. Dessa prestandaindikatorer beskrivs i följande avsnitt.

Frågeprestandaindikatorer

Följande frågeprestandaindikatorer är tillgängliga för varje fråga som körs:

• Total CPU: Övergripande beräkning som används för att bearbeta frågan över alla beräkningsnoder. Den representerar den tid som används för databehandling, parsning och datahämtning.
• Data som används för bearbetad fråga: Övergripande data som användes för att bearbeta frågan. Påverkas av måltabellens storlek, det tidsintervall som används, vilka filter som används och antalet kolumner som refereras till.
• Tidsintervall för den bearbetade frågan: Klyftan mellan de nyaste och äldsta data som användes för att bearbeta frågan. Påverkas av det explicita tidsintervall som angetts för frågan.
• Ålder på bearbetade data: Klyftan mellan nu och de äldsta data som användes för att bearbeta frågan. Det påverkar datahämtningens effektivitet.
• Antal arbetsytor: Hur många arbetsytor som användes under frågebearbetningen baserat på implicit eller explicit val.
• Antal regioner: Hur många regioner som användes under frågebearbetningen baserat på implicit eller explicit val av arbetsytor. Frågor i flera regioner är mycket mindre effektiva och prestandaindikatorer visar delvis täckning.
• Parallellitet: Anger hur mycket systemet kunde köra den här frågan på flera noder. Relevant endast för frågor som har hög CPU-förbrukning. Påverkas av användning av specifika funktioner och operatorer.

Total CPU

Den faktiska beräknings-CPU som investerades för att bearbeta den här frågan över alla frågebearbetningsnoder. Eftersom de flesta frågor körs på ett stort antal noder är den här summan vanligtvis mycket större än den varaktighet som frågan tog att köra.

En fråga som använder mer än 100 sekunders PROCESSOR anses vara en fråga som förbrukar överdrivna resurser. En fråga som använder mer än 1 000 sekunders PROCESSOR anses vara en missbrukande fråga och kan begränsas.

Frågebearbetningstiden ägnas åt:

• Datahämtning: Hämtning av gamla data förbrukar mer tid än hämtning av senaste data.
• Databearbetning: Logik och utvärdering av data.

Utöver den tid som ägnas åt frågebearbetningsnoderna lägger Azure Monitor-loggarna tid på:

• Autentisera användaren och verifiera att de har behörighet att komma åt dessa data.
• Hitta datalagret.
• Parsa frågan.
• Allokera frågebearbetningsnoderna.

Den här tiden ingår inte i frågans totala CPU-tid.

Tidig filtrering av poster innan du använder hög CPU-funktioner

Vissa av frågekommandona och funktionerna är tunga i cpu-förbrukningen. Det här fallet gäller särskilt för kommandon som parsar JSON och XML eller extraherar komplexa reguljära uttryck. Sådan parsning kan ske explicit via funktioner parse_json() eller parse_xml() eller implicit när den refererar till dynamiska kolumner.

Dessa funktioner förbrukar CPU i proportion till antalet rader som de bearbetar. Den mest effektiva optimeringen är att lägga where till villkor tidigt i frågan. På så sätt kan de filtrera bort så många poster som möjligt innan den CPU-intensiva funktionen körs.

Följande frågor ger till exempel exakt samma resultat. Men den andra är den mest effektiva eftersom where-villkoret före parsning exkluderar många poster:

//less efficient
SecurityEvent
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32"  // Problem: irrelevant results are filtered after all processing and parsing is done
| summarize count() by FileHash, FilePath

//more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32"  // exact removal of results. Early filter is not accurate enough
| summarize count() by FileHash, FilePath
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before

Undvik att använda utvärderade satser

Frågor som innehåller var satser i en utvärderad kolumn i stället för på kolumner som finns fysiskt i datamängden förlorar effektiviteten. Filtrering på utvärderade kolumner förhindrar vissa systemoptimeringar när stora datamängder hanteras.

Följande frågor ger till exempel exakt samma resultat. Men den andra är mer effektiv eftersom where-villkoret refererar till en inbyggd kolumn:

//less efficient
Syslog
| extend Msg = strcat("Syslog: ",SyslogMessage)
| where  Msg  has "Error"
| count 

//more efficient
Syslog
| where  SyslogMessage  has "Error"
| count 

I vissa fall skapas den utvärderade kolumnen implicit av frågebearbetningsmotorn eftersom filtreringen inte bara görs i fältet:

//less efficient
SecurityEvent
| where tolower(Process) == "conhost.exe"
| count 

//more efficient
SecurityEvent
| where Process =~ "conhost.exe"
| count 

Använd effektiva aggregeringskommandon och dimensioner i sammanfatta och koppla

Vissa aggregeringskommandon som max(), sum(), count()och avg() har låg CPU-effekt på grund av deras logik. Andra kommandon är mer komplexa och innehåller heuristik och uppskattningar som gör att de kan köras effektivt. Till exempel använder dcount() HyperLogLog-algoritmen för att ge nära uppskattning till ett distinkt antal stora datamängder utan att faktiskt räkna varje värde.

Percentilfunktionerna gör liknande approximationer med hjälp av närmaste rangprocentilalgoritm. Flera av kommandona innehåller valfria parametrar för att minska deras påverkan. Funktionen makeset() har till exempel en valfri parameter för att definiera den maximala uppsättningsstorleken, vilket avsevärt påverkar processorn och minnet.

Anslutnings - och sammanfattningskommandon kan orsaka hög CPU-användning när de bearbetar en stor uppsättning data. Deras komplexitet är direkt relaterad till antalet möjliga värden, som kallas kardinalitet, för de kolumner som används som by i summarize - eller som join attribut. Förklaring och optimering av join och summarizefinns i deras dokumentationsartiklar och optimeringstips.

Följande frågor ger till exempel exakt samma resultat eftersom CounterPath de alltid är en-till-en-mappade till CounterName och ObjectName. Den andra är effektivare eftersom aggregeringsdimensionen är mindre:

//less efficient
Perf
| summarize avg(CounterValue) 
by CounterName, CounterPath, ObjectName

//make the group expression more compact improve the performance
Perf
| summarize avg(CounterValue), any(CounterName), any(ObjectName) 
by CounterPath

CPU-förbrukningen kan också påverkas av where villkor eller utökade kolumner som kräver intensiv databehandling. Alla triviala strängjämförelser, till exempel lika med == och startswith, har ungefär samma CPU-effekt. Avancerade textmatchningar har större inverkan. Mer specifikt är has-operatorn effektivare än contains-operatorn. På grund av stränghanteringstekniker är det mer effektivt att leta efter strängar som är längre än fyra tecken än korta strängar.

Följande frågor ger till exempel liknande resultat, beroende på Computer namngivningsprincip. Men den andra är mer effektiv:

//less efficient – due to filter based on contains
Heartbeat
| where Computer contains "Production" 
| summarize count() by ComputerIP 

//less efficient – due to filter based on extend
Heartbeat
| extend MyComputer = Computer
| where MyComputer startswith "Production" 
| summarize count() by ComputerIP 

//more efficient
Heartbeat
| where Computer startswith "Production" 
| summarize count() by ComputerIP 

Kommentar

Den här indikatorn visar endast CPU från det omedelbara klustret. I en fråga i flera regioner skulle den bara representera en av regionerna. I en fråga med flera arbetsytor kanske den inte innehåller alla arbetsytor.

Undvik fullständig XML- och JSON-parsning när strängparsning fungerar

Fullständig parsning av ett XML- eller JSON-objekt kan förbruka stora PROCESSOR- och minnesresurser. I många fall är det enklare att parsa dem som strängar när endast en eller två parametrar behövs och XML- eller JSON-objekten är enkla. Använd parsningsoperatorn eller andra textparsningstekniker. Prestandaökningen blir mer betydande eftersom antalet poster i XML- eller JSON-objektet ökar. Det är viktigt när antalet poster når tiotals miljoner.

Följande fråga returnerar till exempel exakt samma resultat som föregående frågor utan att utföra fullständig XML-parsning. Frågan gör vissa antaganden om XML-filstrukturen, till exempel att elementet FilePath kommer efter FileHash och ingen av dem har attribut:

//even more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| summarize count() by FileHash, FilePath
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before

Data som används för bearbetad fråga

En viktig faktor i bearbetningen av frågan är mängden data som genomsöks och används för frågebearbetningen. Azure Data Explorer använder aggressiva optimeringar som avsevärt minskar datavolymen jämfört med andra dataplattformar. Det finns dock kritiska faktorer i frågan som kan påverka den datavolym som används.

En fråga som bearbetar mer än 2 000 KB data anses vara en fråga som förbrukar överdrivna resurser. En fråga som bearbetar mer än 20 000 KB data anses vara en missbrukande fråga och kan begränsas.

I Azure Monitor-loggar TimeGenerated används kolumnen som ett sätt att indexera data. Om TimeGenerated du begränsar värdena till ett så begränsat intervall som möjligt förbättras frågeprestandan. Det snäva intervallet begränsar avsevärt mängden data som måste bearbetas.

Undvik onödig användning av sök- och fackföreningsoperatörer

En annan faktor som ökar de data som bearbetas är användningen av ett stort antal tabeller. Det här scenariot inträffar vanligtvis när search * och union * kommandon används. Dessa kommandon tvingar systemet att utvärdera och skanna data från alla tabeller på arbetsytan. I vissa fall kan det finnas hundratals tabeller på arbetsytan. Försök att undvika att använda search * eller någon sökning utan att omfångssöka den till en specifik tabell.

Följande frågor ger till exempel exakt samma resultat, men den sista är den mest effektiva:

// This version scans all tables though only Perf has this kind of data
search "Processor Time" 
| summarize count(), avg(CounterValue)  by Computer

// This version scans all strings in Perf tables – much more efficient
Perf
| search "Processor Time" 
| summarize count(), avg(CounterValue)  by Computer

// This is the most efficient version 
Perf 
| where CounterName == "% Processor Time"  
| summarize count(), avg(CounterValue)  by Computer

Lägga till tidiga filter i frågan

En annan metod för att minska datavolymen är att ha var villkor tidigt i frågan. Azure Data Explorer-plattformen innehåller en cache som låter den veta vilka partitioner som innehåller data som är relevanta för ett specifikt where villkor. Om en fråga till exempel innehåller distribueras where EventID == 4624frågan endast till noder som hanterar partitioner med matchande händelser.

Följande exempelfrågor ger exakt samma resultat, men det andra är mer effektivt:

//less efficient
SecurityEvent
| summarize LoginSessions = dcount(LogonGuid) by Account

//more efficient
SecurityEvent
| where EventID == 4624 //Logon GUID is relevant only for logon event
| summarize LoginSessions = dcount(LogonGuid) by Account

Undvik flera genomsökningar av samma källdata med hjälp av villkorsstyrda aggregeringsfunktioner och funktionen materialisera

När en fråga har flera underfrågor som sammanfogas med hjälp av kopplings- eller fackföreningsoperatorer genomsöker varje underfråga hela källan separat. Sedan sammanfogas resultatet. Den här åtgärden multiplicerar antalet gånger som data genomsöks, vilket är en viktig faktor i stora datamängder.

En teknik för att undvika det här scenariot är att använda de villkorliga aggregeringsfunktionerna. De flesta aggregeringsfunktioner som används i en sammanfattningsoperator har en villkorad version som du kan använda för en enskild sammanfattningsoperator med flera villkor.

Följande frågor visar till exempel antalet inloggningshändelser och antalet processkörningshändelser för varje konto. De returnerar samma resultat, men den första frågan söker igenom data två gånger. Den andra frågan söker bara igenom den en gång:

//Scans the SecurityEvent table twice and perform expensive join
SecurityEvent
| where EventID == 4624 //Login event
| summarize LoginCount = count() by Account
| join 
(
    SecurityEvent
    | where EventID == 4688 //Process execution event
    | summarize ExecutionCount = count(), ExecutedProcesses = make_set(Process) by Account
) on Account

//Scan only once with no join
SecurityEvent
| where EventID == 4624 or EventID == 4688 //early filter
| summarize LoginCount = countif(EventID == 4624), ExecutionCount = countif(EventID == 4688), ExecutedProcesses = make_set_if(Process,EventID == 4688)  by Account

Ett annat fall där underfrågor är onödiga är förfiltrering för en parsningsoperator för att se till att den endast bearbetar poster som matchar ett specifikt mönster. De är onödiga eftersom parsningsoperatorn och andra liknande operatorer returnerar tomma resultat när mönstret inte matchar. Följande två frågor returnerar exakt samma resultat, men den andra frågan söker bara igenom data en gång. I den andra frågan är varje parsningskommando endast relevant för dess händelser. Operatorn extend visar efteråt hur du refererar till en tom datasituation:

//Scan SecurityEvent table twice
union(
SecurityEvent
| where EventID == 8002 
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| distinct FilePath
),(
SecurityEvent
| where EventID == 4799
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" * 
| distinct CallerProcessName1
)

//Single scan of the SecurityEvent table
SecurityEvent
| where EventID == 8002 or EventID == 4799
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" * //Relevant only for event 8002
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" *  //Relevant only for event 4799
| extend FilePath = iif(isempty(CallerProcessName1),FilePath,"")
| distinct FilePath, CallerProcessName1

När föregående fråga inte tillåter att du undviker att använda underfrågor är en annan teknik att antyda för frågemotorn att det finns en enda datakälla som används i var och en av dem med hjälp av funktionen materialize(). Den här tekniken är användbar när källdata kommer från en funktion som används flera gånger i frågan. Materialize är effektivt när utdata från underfrågan är mycket mindre än indata. Frågemotorn cachelagrar och återanvänder utdata i alla förekomster.

Minska antalet kolumner som hämtas

Eftersom Azure Data Explorer är ett kolumndatalager är hämtningen av varje kolumn oberoende av de andra. Antalet kolumner som hämtas påverkar den totala datavolymen direkt. Du bör bara inkludera kolumnerna i de utdata som behövs genom att sammanfatta resultaten eller projicera de specifika kolumnerna.

Azure Data Explorer har flera optimeringar för att minska antalet hämtade kolumner. Om den fastställer att en kolumn inte behövs, till exempel om den inte refereras till i sammanfattningskommandot , kommer den inte att hämta den.

Den andra frågan kan till exempel bearbeta tre gånger mer data eftersom den inte behöver hämta en kolumn utan tre:

//Less columns --> Less data
SecurityEvent
| summarize count() by Computer  

//More columns --> More data
SecurityEvent
| summarize count(), dcount(EventID), avg(Level) by Computer  

Tidsintervall för den bearbetade frågan

Alla loggar i Azure Monitor-loggar partitioneras enligt TimeGenerated kolumnen . Antalet partitioner som används är direkt relaterade till tidsintervallet. Att minska tidsintervallet är det mest effektiva sättet att säkerställa körning av en fråga.

En fråga med ett tidsintervall på mer än 15 dagar anses vara en fråga som förbrukar överdrivna resurser. En fråga med ett tidsintervall på mer än 90 dagar anses vara en missbrukande fråga och kan begränsas.

Du kan ange tidsintervallet med hjälp av tidsintervallväljaren på Log Analytics-skärmen enligt beskrivningen i Log Query-omfång och tidsintervall i Azure Monitor Log Analytics. Den här metoden rekommenderas eftersom det valda tidsintervallet skickas till serverdelen med hjälp av frågemetadata.

En alternativ metod är att uttryckligen inkludera ett where-villkorTimeGenerated i frågan. Använd den här metoden eftersom den säkerställer att tidsintervallet är fast, även när frågan används från ett annat gränssnitt.

Kontrollera att alla delar av frågan har TimeGenerated filter. När en fråga har underfrågor som hämtar data från olika tabeller eller samma tabell måste varje fråga innehålla sitt eget where-villkor .

Kontrollera att alla underfrågor har TimeGenerated-filtret

I följande fråga genomsöks till Perf exempel tabellen endast för den senaste dagen. Tabellen Heartbeat genomsöks efter hela dess historik, vilket kan vara upp till två år:

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    //No time span filter in this part of the query
    | summarize IPs = makeset(ComputerIP, 10) by  Computer
) on Computer

Ett vanligt fall där ett sådant misstag inträffar är när arg_max() används för att hitta den senaste förekomsten. Till exempel:

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    //No time span filter in this part of the query
    | summarize arg_max(TimeGenerated, *), min(TimeGenerated)   
by Computer
) on Computer

Du kan enkelt korrigera den här situationen genom att lägga till ett tidsfilter i den inre frågan:

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    | where TimeGenerated > ago(1d) //filter for this part
    | summarize arg_max(TimeGenerated, *), min(TimeGenerated)   
by Computer
) on Computer

Ett annat exempel på det här felet är när du utför tidsomfångsfiltreringen strax efter en union över flera tabeller. När du utför unionen bör varje underfråga begränsas. Du kan använda en let-instruktion för att säkerställa omfångskonsekvens.

Följande fråga söker till exempel igenom alla data i tabellerna Heartbeat och Perf , inte bara den sista dagen:

Heartbeat 
| summarize arg_min(TimeGenerated,*) by Computer
| union (
    Perf 
    | summarize arg_min(TimeGenerated,*) by Computer) 
| where TimeGenerated > ago(1d)
| summarize min(TimeGenerated) by Computer

Så här åtgärdar du frågan:

let MinTime = ago(1d);
Heartbeat 
| where TimeGenerated > MinTime
| summarize arg_min(TimeGenerated,*) by Computer
| union (
    Perf 
    | where TimeGenerated > MinTime
    | summarize arg_min(TimeGenerated,*) by Computer) 
| summarize min(TimeGenerated) by Computer

Begränsningar för tidsintervallmätning

Mätningen är alltid större än den faktiska tid som angetts. Om filtret på frågan till exempel är 7 dagar kan systemet skanna 7,5 eller 8,1 dagar. Den här variansen beror på att systemet partitionerar data i segment med variabelstorlekar. För att säkerställa att alla relevanta poster genomsöks genomsöker systemet hela partitionen. Den här processen kan omfatta flera timmar och till och med mer än en dag.

Det finns flera fall där systemet inte kan ge en korrekt mätning av tidsintervallet. Den här situationen inträffar i de flesta fall där frågans intervall är mindre än en dag eller i frågor med flera arbetsytor.

Viktigt!

Den här indikatorn visar endast data som bearbetas i det omedelbara klustret. I en fråga i flera regioner skulle den bara representera en av regionerna. I en fråga med flera arbetsytor kanske den inte innehåller alla arbetsytor.

Ålder på bearbetade data

Azure Data Explorer använder flera lagringsnivåer: minnesintern, lokala SSD-diskar och mycket långsammare Azure Blobs. Ju nyare data, desto större är chansen att den lagras på en mer högpresterande nivå med mindre svarstid, vilket minskar frågevaraktigheten och PROCESSORn. Förutom själva data har systemet också en cache för metadata. Ju äldre data, desto mindre chans är dess metadata i en cache.

En fråga som bearbetar data som är mer än 14 dagar gammal anses vara en fråga som förbrukar överdrivna resurser.

Vissa frågor kräver användning av gamla data, men det finns också fall där gamla data används av misstag. Det här scenariot inträffar när frågor körs utan att ange ett tidsintervall i sina metadata och inte alla tabellreferenser innehåller ett filter i TimeGenerated kolumnen. I dessa fall genomsöker systemet alla data som lagras i tabellen. När datakvarhållningen är lång kan den omfatta långa tidsintervall. Därför genomsöks data som är lika gamla som datakvarhållningsperioden.

Sådana fall kan till exempel vara:

• Inte ange tidsintervallet i Log Analytics med en underfråga som inte är begränsad. Se föregående exempel.
• Använda API:et utan valfria tidsintervallparametrar.
• Att använda en klient som inte tvingar fram ett tidsintervall, till exempel som Power BI-anslutningsappen.

Se exempel och anteckningar i föregående avsnitt eftersom de också är relevanta i det här fallet.

Antal regioner

Det finns situationer där en enskild fråga kan köras i olika regioner. Till exempel:

• När flera arbetsytor uttryckligen visas och de finns i olika regioner.
• När en resursomfattande fråga hämtar data och data lagras på flera arbetsytor som finns i olika regioner.

Frågekörning mellan regioner kräver att systemet serialiserar och överför stora delar av mellanliggande data i serverdelen som vanligtvis är mycket större än frågeslutresultatet. Det begränsar också systemets förmåga att utföra optimeringar och heuristik och använda cacheminnen.

Om det inte finns någon anledning att söka igenom alla dessa regioner justerar du omfånget så att det omfattar färre regioner. Om resursomfånget minimeras men många regioner fortfarande används kan det inträffa på grund av felkonfiguration. Granskningsloggar och diagnostikinställningar kan till exempel skickas till olika arbetsytor i olika regioner eller så kan det finnas flera konfigurationer för diagnostikinställningar.

En fråga som sträcker sig över mer än tre regioner anses vara en fråga som förbrukar överdrivna resurser. En fråga som sträcker sig över mer än sex regioner anses vara en missbrukande fråga och kan begränsas.

Viktigt!

När en fråga körs i flera regioner är cpu- och datamätningarna inte korrekta och representerar bara mätningen av en av regionerna.

Antal arbetsytor

Arbetsytor är logiska containrar som används för att separera och administrera loggdata. Serverdelen optimerar arbetsyteplaceringar på fysiska kluster i den valda regionen.

Användning av flera arbetsytor kan bero på instanser när:

• Flera arbetsytor visas uttryckligen.
• En resursomfattande fråga hämtar data och data lagras på flera arbetsytor.

Körning mellan regioner och mellan kluster av frågor kräver att systemet serialiserar och överför stora delar av mellanliggande data i serverdelen som vanligtvis är mycket större än frågeslutresultatet. Det begränsar också systemets förmåga att utföra optimeringar och heuristik och använda cacheminnen.

En fråga som sträcker sig över mer än fem arbetsytor anses vara en fråga som förbrukar överdrivna resurser. Frågor får inte omfatta fler än 100 arbetsytor.

Viktigt!

• I vissa scenarier med flera arbetsytor är cpu- och datamätningarna inte korrekta och representerar bara några få av arbetsytorna.
• Frågor mellan arbetsytor som har en explicit identifierare: arbetsyte-ID eller azure-resurs-ID för arbetsyta, förbrukar mindre resurser och är mer högpresterande.

Parallellitet

Azure Monitor-loggar använder stora kluster i Azure Data Explorer för att köra frågor. Dessa kluster varierar i skala och kan komma upp till dussintals beräkningsnoder. Systemet skalar automatiskt klustren enligt arbetsytans placeringslogik och kapacitet.

För att effektivt köra en fråga partitioneras och distribueras den till beräkningsnoder baserat på de data som krävs för bearbetningen. I vissa situationer kan systemet inte utföra det här steget effektivt, vilket kan leda till en lång varaktighet för frågan.

Frågebeteenden som kan minska parallelliteten är:

• Användning av serialiserings- och fönsterfunktioner, till exempel serialiseringsoperatorn, next(), prev()och radfunktionerna. Tidsserie- och användaranalysfunktioner kan användas i vissa av dessa fall. Ineffektiv serialisering kan också inträffa om följande operatorer inte används i slutet av frågan: intervall, sortering, ordning, topp, top-hitters och getschema.
• Användningen av aggregeringsfunktionen dcount() tvingar systemet att ha en central kopia av de distinkta värdena. När dataskalan är hög bör du överväga att använda funktionens dcount valfria parametrar för att minska noggrannheten.
• I många fall sänker kopplingsoperatorn den övergripande parallelliteten. Granska shuffle join som ett alternativ när prestanda är problematiskt.
• I frågor med resursomfattning kan förkörningen av Rollbaserad åtkomstkontroll för Kubernetes (RBAC) eller Azure RBAC-kontroller dröja kvar i situationer där det finns ett stort antal Rolltilldelningar i Azure. Den här situationen kan leda till längre kontroller som skulle leda till lägre parallellitet. En fråga kan till exempel köras i en prenumeration där det finns tusentals resurser och varje resurs har många rolltilldelningar på resursnivå, inte i prenumerationen eller resursgruppen.
• Om en fråga bearbetar små datasegment blir parallelliteten låg eftersom systemet inte sprider den över många beräkningsnoder.

Nästa steg

Referensdokumentation för Kusto-frågespråk