Optimalizace dotazů na protokoly ve službě Azure Monitor

  • Článek

Protokoly služby Azure Monitor používají Azure Data Explorer k ukládání dat protokolů a spouštění dotazů pro analýzu dat. Vytváří, spravuje a udržuje clustery Azure Data Exploreru za vás a optimalizuje je pro úlohy analýzy protokolů. Když spustíte dotaz, je optimalizovaný a směrovaný do příslušného clusteru Azure Data Exploreru, který ukládá data pracovního prostoru.

Protokoly služby Azure Monitor a Azure Data Explorer používají mnoho mechanismů automatické optimalizace dotazů. Automatické optimalizace poskytují výrazné zvýšení výkonu, ale v některých případech můžete výrazně zlepšit výkon dotazů. Tento článek vysvětluje aspekty výkonu a několik technik pro jejich opravu.

Většina technik je běžná pro dotazy, které se spouštějí přímo v Azure Data Exploreru a protokolech služby Azure Monitor. Probereme také několik jedinečných aspektů protokolů služby Azure Monitor. Další tipy pro optimalizaci Azure Data Exploreru najdete v tématu Osvědčené postupy pro dotazy.

Optimalizované dotazy budou:

  • Spusťte rychleji a snižte celkovou dobu trvání provádění dotazu.
  • Máte menší šanci na omezení nebo odmítnutí.

Věnujte zvláštní pozornost dotazům, které se používají pro opakované a souběžné použití, jako jsou řídicí panely, upozornění, Azure Logic Apps a Power BI. Dopad neefektivního dotazu v těchto případech je podstatný.

Tady je podrobný návod k videu pro optimalizaci dotazů.

Podokno Podrobnosti dotazu

Po spuštění dotazu v Log Analytics výběrem podrobností dotazu v pravém dolním rohu obrazovky otevřete podokno Podrobnosti dotazu. Toto podokno zobrazuje výsledky několika indikátorů výkonu dotazu. Tyto ukazatele výkonu jsou popsány v následující části.

Screenshot that shows the Query Details pane in Azure Monitor Log Analytics.

Indikátory výkonu dotazů

Pro každý spuštěný dotaz jsou k dispozici následující indikátory výkonu dotazu:

  • Celkový procesor: Celkový výpočetní výkon používaný ke zpracování dotazu ve všech výpočetních uzlech. Představuje čas používaný pro výpočty, analýzu a načítání dat.
  • Data používaná ke zpracování dotazu: Celková data, ke kterým se přistupovalo ke zpracování dotazu. Ovlivněno velikostí cílové tabulky, použitým časovým rozsahem, použitými filtry a počtem odkazů na sloupce.
  • Časový rozsah zpracovaného dotazu: Mezera mezi nejnovějšími a nejstaršími daty, ke kterým byl dotaz přístupný. Ovlivněno explicitním časovým rozsahem zadaným pro dotaz.
  • Věk zpracovaných dat: Mezera mezi jednotlivými a nejstaršími daty, ke kterým se přistupovalo ke zpracování dotazu. Velmi ovlivňuje efektivitu načítání dat.
  • Počet pracovních prostorů: Kolik pracovních prostorů bylo během zpracování dotazů přístupné na základě implicitního nebo explicitního výběru.
  • Počet oblastí: Kolik oblastí bylo během zpracování dotazů přístupné na základě implicitního nebo explicitního výběru pracovních prostorů. Dotazy ve více oblastech jsou mnohem méně efektivní a ukazatele výkonu představují částečné pokrytí.
  • Paralelismus: Udává, kolik systém dokázal tento dotaz spustit na více uzlech. Relevantní pouze pro dotazy, které mají vysokou spotřebu procesoru. Ovlivněno používáním konkrétních funkcí a operátorů.

Celkový počet procesorů

Skutečný výpočetní procesor, který byl investován ke zpracování tohoto dotazu ve všech uzlech zpracování dotazů. Vzhledem k tomu, že většina dotazů se provádí na velkém počtu uzlů, bude tento součet obvykle mnohem větší než doba trvání, po které se dotaz provedl.

Dotaz, který používá více než 100 sekund procesoru, se považuje za dotaz, který spotřebovává nadměrné prostředky. Dotaz, který používá více než 1 000 sekund procesoru, se považuje za zneužívající dotaz a může být omezený.

Doba zpracování dotazů se věnuje:

  • Načítání dat: Načtení starých dat bude spotřebovávat více času než načítání posledních dat.
  • Zpracování dat: Logika a vyhodnocení dat.

Kromě času stráveného v uzlech zpracování dotazů tráví protokoly Služby Azure Monitor časy v:

  • Ověření uživatele a ověření, že má oprávnění k přístupu k datům.
  • Umístění úložiště dat
  • Analýza dotazu
  • Přidělování uzlů zpracování dotazů.

Tento čas není součástí celkového času procesoru dotazu.

Předčasné filtrování záznamů před použitím funkcí vysokého využití procesoru

Některé příkazy a funkce dotazů jsou náročné na spotřebu procesoru. Tento případ platí zejména pro příkazy, které analyzují JSON a XML nebo extrahují složité regulární výrazy. Taková analýza může probíhat explicitně prostřednictvím funkcí parse_json() nebo parse_xml() nebo implicitně, pokud odkazuje na dynamické sloupce.

Tyto funkce spotřebovávají procesor v poměru k počtu řádků, které zpracovávají. Nejúčinnější optimalizací je přidat where podmínky v rané fázi dotazu. Tímto způsobem můžou před spuštěním funkce náročné na procesor vyfiltrovat co nejvíce záznamů.

Například následující dotazy vytvoří přesně stejný výsledek. Druhá je ale nejúčinnější, protože podmínka před parsováním vylučuje mnoho záznamů:

//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

Vyhněte se použití vyhodnocovaných klauzulí where

Dotazy, které obsahují klauzule where v vyhodnoceném sloupci, nikoli na sloupce, které jsou fyzicky přítomné v datové sadě, ztratí efektivitu. Filtrování vyhodnocovaných sloupců zabraňuje některým optimalizacím systému při zpracování velkých sad dat.

Například následující dotazy vytvoří přesně stejný výsledek. Druhá je ale efektivnější, protože podmínka where odkazuje na předdefinovaný sloupec:

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

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

V některých případech je vyhodnocený sloupec implicitně vytvořen modulem zpracování dotazů, protože filtrování se provádí nejen u pole:

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

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

Použití efektivních agregačních příkazů a dimenzí ve shrnutí a spojení

Některé agregační příkazy, jako je max(), sum() nebo count() a avg() mají kvůli své logice nízký dopad na procesor. Další příkazy jsou složitější a zahrnují heuristiky a odhady, které jim umožňují efektivně provádět. Například dcount() používá algoritmus HyperLogLog k zajištění podrobného odhadu jedinečného počtu velkých sad dat bez skutečného počítání jednotlivých hodnot.

Funkce percentilu provádějí podobné aproximace pomocí nejbližšího percentilového algoritmu pořadí. Několik příkazů obsahuje volitelné parametry, které snižují jejich dopad. Funkce makeset() má například volitelný parametr pro definování maximální velikosti sady, která významně ovlivňuje procesor a paměť.

Spojení a shrnutí příkazů může způsobit vysoké využití procesoru při zpracování velké sady dat. Jejich složitost přímo souvisí s počtem možných hodnot, označovaných jako kardinalita, sloupců, které se používají jako by in summarize nebo jako join atributy. Vysvětlení a optimalizace a summarizeoptimalizace join najdete v článcích dokumentace a tipy pro optimalizaci.

Například následující dotazy generují přesně stejný výsledek, protože CounterPath vždy je namapován 1:1 na CounterName a ObjectName. Druhá dimenze je efektivnější, protože dimenze agregace je menší:

//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

Využití procesoru může být ovlivněno také podmínkami nebo rozšířenými where sloupci, které vyžadují náročné výpočty. Všechna triviální porovnání řetězců, jako je například equal == a startswith, mají přibližně stejný dopad na procesor. Rozšířené shody textu mají větší dopad. Konkrétně operátor has je efektivnější než operátor obsahuje . Vzhledem k technikám zpracování řetězců je efektivnější hledat řetězce, které jsou delší než čtyři znaky než krátké řetězce.

Například následující dotazy generují podobné výsledky v závislosti na Computer zásadách pojmenování. Druhá je ale efektivnější:

//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

Poznámka:

Tento indikátor představuje pouze procesor z okamžitého clusteru. V dotazu s více oblastmi by představoval pouze jednu z oblastí. V dotazu s více pracovními prostory nemusí obsahovat všechny pracovní prostory.

Vyhněte se úplnému parsování XML a JSON, když funguje analýza řetězců

Úplná analýza objektu XML nebo JSON může spotřebovávat velké prostředky procesoru a paměti. V mnoha případech, když jsou potřeba jenom jeden nebo dva parametry a objekty XML nebo JSON jsou jednoduché, je jednodušší je analyzovat jako řetězce. Použijte operátor parsování nebo jiné techniky analýzy textu. Zvýšení výkonu bude mnohem důležitější, protože se zvyšuje počet záznamů v objektu XML nebo JSON. Je důležité, když počet záznamů dosáhne desítek milionů.

Následující dotaz například vrátí přesně stejné výsledky jako předchozí dotazy, aniž by prováděl úplné analýzy XML. Dotaz provádí určité předpoklady o struktuře souborů XML, jako FilePath je element, který FileHash následuje a žádný z nich nemá atributy:

//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 používaná ke zpracování dotazu

Důležitým faktorem při zpracování dotazu je objem naskenovaných dat, která se používají ke zpracování dotazů. Azure Data Explorer používá agresivní optimalizace, které výrazně snižují objem dat v porovnání s jinými datovými platformami. Stále existují kritické faktory v dotazu, které můžou ovlivnit použitý objem dat.

Dotaz, který zpracovává více než 2 000 kB dat, se považuje za dotaz, který spotřebovává nadměrné prostředky. Dotaz, který zpracovává více než 20 000 kB dat, se považuje za zneužívající dotaz a může být omezený.

V protokolech TimeGenerated služby Azure Monitor se sloupec používá jako způsob indexování dat. Omezením TimeGenerated hodnot co nejužší rozsah zvýšíte výkon dotazů. Úzký rozsah výrazně omezuje množství dat, která je potřeba zpracovat.

Vyhněte se zbytečnému použití operátorů vyhledávání a sjednocení

Dalším faktorem, který zvyšuje množství zpracovaných dat, je použití velkého počtu tabulek. K tomuto scénáři obvykle dochází, když search * se union * použijí příkazy. Tyto příkazy vynutí systém vyhodnotit a kontrolovat data ze všech tabulek v pracovním prostoru. V některých případech může v pracovním prostoru existovat stovky tabulek. Zkuste se vyhnout použití search * nebo jakéhokoli hledání, aniž byste ho museli určit na konkrétní tabulku.

Například následující dotazy vytvářejí přesně stejný výsledek, ale poslední dotaz je nejúčinnější:

// 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

Přidání počátečních filtrů do dotazu

Dalším způsobem, jak snížit objem dat, je mít podmínky v rané fázi dotazu. Platforma Azure Data Exploreru obsahuje mezipaměť, která jí umožňuje zjistit, které oddíly obsahují data relevantní pro konkrétní where podmínku. Pokud například dotaz obsahuje where EventID == 4624, distribuuje dotaz pouze do uzlů, které zpracovávají oddíly s odpovídajícími událostmi.

Následující ukázkové dotazy vytvářejí přesně stejný výsledek, ale druhý z nich je efektivnější:

//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

Vyhněte se více kontrolám stejných zdrojových dat pomocí podmíněných agregačních funkcí a materializovat funkci.

Pokud dotaz obsahuje několik poddotazů, které jsou sloučeny pomocí operátorů spojení nebo sjednocení, každý poddotaz prohledá celý zdroj samostatně. Výsledky se pak sloučí. Tato akce vynásobí počet kontrolovaných dat, což je kritický faktor velkých datových sad.

Technika, jak se tomuto scénáři vyhnout, je použití funkcí podmíněné agregace. Většina agregačních funkcí, které se používají v operátoru souhrnu, má podmíněnou verzi, kterou můžete použít pro jeden operátor souhrnu s více podmínkami.

Například následující dotazy zobrazují počet událostí přihlášení a počet událostí spuštění procesu pro každý účet. Vrátí stejné výsledky, ale první dotaz naskenuje data dvakrát. Druhý dotaz ho prohledá pouze jednou:

//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

Dalším případem, kdy jsou poddotazy zbytečné, je předběžné filtrování operátoru analýzy, aby se zajistilo, že zpracovává pouze záznamy, které odpovídají určitému vzoru. Nejsou potřeba, protože operátor parsování a další podobné operátory vrací prázdné výsledky, pokud se vzor neshoduje. Následující dva dotazy vrátí přesně stejné výsledky, ale druhý dotaz prohledá data pouze jednou. Ve druhém dotazu je každý příkaz analýzy relevantní jenom pro své události. Operátor extend potom ukazuje, jak odkazovat na prázdnou situaci s daty:

//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

Pokud předchozí dotaz neumožňuje vyhnout se použití poddotazů, další technikou je naznačovat dotazovacímu stroji, že je v každém z nich jeden zdroj dat použitý pomocí funkce materialize(). Tato technika je užitečná, když zdrojová data pocházejí z funkce, která se v dotazu používá několikrát. Materialize je efektivní, pokud je výstup poddotazů mnohem menší než vstup. Dotazovací modul uloží výstup do mezipaměti a znovu použije výstup ve všech výskytech.

Zmenšení počtu načtených sloupců

Vzhledem k tomu, že Azure Data Explorer je sloupcové úložiště dat, načítání každého sloupce je nezávislé na ostatních. Počet načtených sloupců přímo ovlivňuje celkový objem dat. Do výstupu, které jsou potřeba, byste měli zahrnout jenom sloupce, které jsou potřeba souhrnem výsledků nebo promítnutím konkrétních sloupců.

Azure Data Explorer má několik optimalizací, aby se snížil počet načtených sloupců. Pokud zjistí, že sloupec není potřeba, například pokud není odkazován v příkazu sumarizace , nenačte ho.

Druhý dotaz může například zpracovat třikrát více dat, protože potřebuje načíst jeden sloupec, ale tři:

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

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

Časový rozsah zpracovaného dotazu

Všechny protokoly v protokolech služby Azure Monitor se dělí podle TimeGenerated sloupce. Počet oddílů, ke kterým se přistupuje, souvisí přímo s časovým rozsahem. Snížení časového rozsahu je nejúčinnější způsob, jak zajistit provedení dotazu s výzvou.

Dotaz s časovým rozsahem delším než 15 dnů se považuje za dotaz, který spotřebovává nadměrné prostředky. Dotaz s časovým rozsahem delším než 90 dnů se považuje za zneužívající dotaz a může být omezený.

Časový rozsah můžete nastavit pomocí selektoru časového rozsahu na obrazovce Log Analytics, jak je popsáno v oboru dotazu protokolu a časovém rozsahu ve službě Azure Monitor Log Analytics. Tato metoda se doporučuje, protože vybraný časový rozsah se předává back-endu pomocí metadat dotazu.

Alternativní metodou je explicitně zahrnout podmínku TimeGenerated where v dotazu. Tuto metodu použijte, protože zajišťuje, že časové rozpětí je pevné, i když se dotaz používá z jiného rozhraní.

Ujistěte se, že všechny části dotazu mají TimeGenerated filtry. Pokud dotaz obsahuje poddotazy, které načítají data z různých tabulek nebo stejné tabulky, musí každý dotaz obsahovat vlastní podmínku where .

Ujistěte se, že všechny poddotazy mají filtr TimeGenerated.

Například v následujícím dotazu Perf bude tabulka prohledávána pouze za poslední den. Tabulka Heartbeat bude prohledávána pro celou historii, což může být až dva roky:

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

Běžným případem, kdy k takové chybě dojde, je použití arg_max() k nalezení nejnovějšího výskytu. Příklad:

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

Tuto situaci můžete snadno opravit přidáním časového filtru do vnitřního dotazu:

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

Dalším příkladem této chyby je, když provádíte filtrování oboru času těsně po sjednocení několika tabulek. Při sjednocování by měl být každý poddotaz vymezený. Pomocí příkazu let můžete zajistit konzistenci rozsahu.

Například následující dotaz zkontroluje všechna data v tabulkách Heartbeat a Perf ne jenom poslední den:

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

Oprava dotazu:

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

Omezení měření časového rozsahu

Měření je vždy větší než zadaný skutečný čas. Pokud je například filtr dotazu 7 dní, může systém prohledávat 7,5 nebo 8,1 dnů. Tento rozptyl je způsoben tím, že systém rozděluje data do bloků proměnných velikostí. Aby se zajistilo, že jsou prohledány všechny relevantní záznamy, systém prohledá celý oddíl. Tento proces může pokrýt několik hodin a dokonce i více než den.

Existuje několik případů, kdy systém nemůže poskytnout přesné měření časového rozsahu. K této situaci dochází ve většině případů, kdy je rozsah dotazu menší než den nebo v dotazech s více pracovními prostory.

Důležité

Tento indikátor zobrazuje pouze data zpracovávaná v bezprostředním clusteru. V dotazu s více oblastmi by představoval pouze jednu z oblastí. V dotazu s více pracovními prostory nemusí obsahovat všechny pracovní prostory.

Stáří zpracovaných dat

Azure Data Explorer používá několik úrovní úložiště: v paměti, místní disky SSD a mnohem pomalejší objekty blob Azure. Novější data, tím vyšší je pravděpodobnost, že jsou uložená v výkonnější vrstvě s menší latencí, což snižuje dobu trvání dotazu a procesor. Kromě samotných dat má systém také mezipaměť pro metadata. Starší data, tím menší pravděpodobnost, že budou jeho metadata v mezipaměti.

Dotaz, který zpracovává data starší než 14 dnů, se považuje za dotaz, který spotřebovává nadměrné prostředky.

Některé dotazy vyžadují použití starých dat, ale existují i případy, kdy se stará data používají omylem. K tomuto scénáři dochází, když se dotazy spustí bez poskytnutí časového rozsahu v metadatech a ne všechny odkazy na tabulky obsahují filtr ve TimeGenerated sloupci. V těchto případech systém prohledá všechna data uložená v tabulce. Pokud je uchovávání dat dlouhé, může zahrnovat dlouhé časové rozsahy. V důsledku toho se kontroluje data, která jsou tak stará jako doba uchovávání dat.

Takové případy můžou být například:

  • Nenastavuje časový rozsah v Log Analytics poddotaz, který není omezený. Podívejte se na předchozí příklad.
  • Použití rozhraní API bez volitelných parametrů časového rozsahu
  • Použití klienta, který nevynucuje časový rozsah, například konektor Power BI.

Podívejte se na příklady a poznámky v předchozí části, protože jsou v tomto případě také relevantní.

Počet oblastí

Existují situace, kdy se může spustit jeden dotaz v různých oblastech. Příklad:

  • Když je explicitně uvedeno několik pracovních prostorů a nachází se v různých oblastech.
  • Když dotaz v oboru prostředků načítá data a data se ukládají do více pracovních prostorů, které jsou umístěné v různých oblastech.

Provádění dotazů napříč oblastmi vyžaduje, aby systém serializoval a přenesl do back-endu velké bloky zprostředkujících dat, které jsou obvykle mnohem větší než konečné výsledky dotazu. Omezuje také schopnost systému provádět optimalizace a heuristiky a používat mezipaměti.

Pokud není důvod prohledat všechny tyto oblasti, upravte rozsah tak, aby zahrnoval méně oblastí. Pokud je rozsah prostředků minimalizovaný, ale stále se používá mnoho oblastí, může k němu dojít kvůli chybné konfiguraci. Například protokoly auditu a nastavení diagnostiky se můžou posílat do různých pracovních prostorů v různých oblastech nebo může existovat několik konfigurací nastavení diagnostiky.

Dotaz, který zahrnuje více než tři oblasti, se považuje za dotaz, který spotřebovává nadměrné prostředky. Dotaz, který zahrnuje více než šest oblastí, se považuje za urážlivý dotaz a může být omezený.

Důležité

Když se dotaz spustí napříč několika oblastmi, měření procesoru a dat nebude přesné a bude představovat měření pouze jedné z oblastí.

Počet pracovních prostorů

Pracovní prostory jsou logické kontejnery, které slouží k oddělení a správě dat protokolů. Back-end optimalizuje umístění pracovních prostorů ve fyzických clusterech ve vybrané oblasti.

Použití více pracovních prostorů může být výsledkem instancí v těchto případech:

  • Explicitně je uvedeno několik pracovních prostorů.
  • Dotaz v oboru prostředků načítá data a data se ukládají v několika pracovních prostorech.

Provádění dotazů napříč oblastmi a napříč clustery vyžaduje, aby systém serializoval a přenesl do back-endu velké bloky mezilehlých dat, které jsou obvykle mnohem větší než konečné výsledky dotazu. Omezuje také schopnost systému provádět optimalizace a heuristiky a používat mezipaměti.

Dotaz, který zahrnuje více než pět pracovních prostorů, se považuje za dotaz, který spotřebovává nadměrné prostředky. Dotazy nemůžou zahrnovat více než 100 pracovních prostorů.

Důležité

  • V některých scénářích s více pracovními prostory nebudou měření procesoru a dat přesné a budou představovat měření pouze několika pracovních prostorů.
  • Dotazy mezi pracovními prostory s explicitním identifikátorem: ID pracovního prostoru nebo ID prostředku Azure, spotřebovávají méně prostředků a jsou výkonnější.

Paralelismus

Protokoly služby Azure Monitor používají k spouštění dotazů velké clustery Azure Data Exploreru. Tyto clustery se liší ve velkém měřítku a potenciálně se dostanou až do desítek výpočetních uzlů. Systém automaticky škáluje clustery podle logiky umístění pracovního prostoru a kapacity.

Pokud chcete efektivně spustit dotaz, rozdělí se a distribuuje do výpočetních uzlů na základě dat potřebných ke zpracování. V některých situacích systém nemůže tento krok efektivně provést, což může vést k dlouhé době trvání dotazu.

Chování dotazů, které může snížit paralelismus, patří:

  • Použití serializace a funkcí oken, jako jsou serializace operátor, next(), prev() a funkce řádku . V některých případech je možné použít časové řady a funkce analýzy uživatelů. Neefektivní serializace může také nastat, pokud se na konci dotazu nepoužívají následující operátory: rozsah, řazení, pořadí, top, top-hitter a getschema.
  • Použití agregační funkce dcount() vynutí systém, aby měl centrální kopii jedinečných hodnot. Pokud je měřítko dat vysoké, zvažte použití dcount volitelných parametrů funkce ke snížení přesnosti.
  • V mnoha případech operátor spojení snižuje celkový paralelismus. Prozkoumejte shuffle join jako alternativu, pokud je výkon problematický.
  • V dotazech v oboru prostředků může předběžné spuštění řízení přístupu na základě role Kubernetes (RBAC) nebo kontroly Azure RBAC přetrvávat v situacích, kdy existuje velký počet přiřazení rolí Azure. Tato situace může vést k delším kontrolám, které by mohly vést k nižšímu paralelismu. Například dotaz může být proveden v předplatném, kde jsou tisíce prostředků a každý prostředek má mnoho přiřazení rolí na úrovni prostředku, ne v předplatném nebo ve skupině prostředků.
  • Pokud dotaz zpracovává malé bloky dat, bude jeho paralelismus nízký, protože systém ho nerozloží do mnoha výpočetních uzlů.

Další kroky

Referenční dokumentace pro dotazovací jazyk Kusto