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

Protokoly služby Azure Monitor používají k ukládání dat protokolů a spouštění dotazů pro analýzu těchto dat azure Data Explorer (ADX). Vytvoří, spravuje a udržuje clustery ADX za vás a optimalizuje je pro vaši úlohu analýzy protokolů. Když spustíte dotaz, je optimalizovaný a směrovaný do příslušného clusteru ADX, který ukládá data pracovního prostoru. Protokoly Azure Monitoru i Azure Data Explorer používají mnoho mechanismů automatické optimalizace dotazů. I když automatické optimalizace poskytují výrazný nárůst, existují některé případy, kdy můžete výrazně zlepšit výkon dotazů. Tento článek vysvětluje aspekty výkonu a několik technik k jejich opravě.

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

Optimalizované dotazy budou:

  • Spusťte rychleji, snižte celkovou dobu trvání provádění dotazu.
  • Máte menší šanci být omezeni nebo odmítnuti.

Měli byste věnovat zvláštní pozornost dotazům, které se používají pro opakované a roztrhlé využití, jako jsou řídicí panely, výstrahy, 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 vyberte Podrobnosti dotazu v pravém dolním rohu obrazovky a otevřete boční podokno Podrobnosti dotazu . Toto podokno zobrazuje výsledky několika indikátorů výkonu dotazu. Tyto ukazatele výkonu jsou popsané v následující části.

A screenshot showing 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 dotazů:

  • Celkový procesor: Celkový výpočetní výkon používaný ke zpracování dotazu napříč všemi výpočetními uzly. Představuje čas používaný pro výpočty, parsování a načítání dat.

  • Data použitá ke zpracování dotazu: Celková data, ke kterým byl přístup ke zpracování dotazu. Ovlivněná velikostí cílové tabulky, použitým časovým rozsahem, použitými filtry a počtem odkazů na sloupce

  • Časový rozsah zpracovávaného dotazu: Mezera mezi nejnovějšími a nejstaršími daty, ke kterým byl přístup ke zpracování dotazu. Ovlivněný explicitním časovým rozsahem určeným pro dotaz.

  • Věk zpracovaných dat: Rozdíl mezi jednotlivými daty a nejstaršími daty, ke kterým byl přistupován 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é z důvodu implicitního nebo explicitního výběru.

  • Počet oblastí: Kolik oblastí bylo během zpracování dotazů přístupné z důvodu 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: Označuje, kolik systém mohl tento dotaz spustit na více uzlech. Relevantní pouze pro dotazy, které mají vysokou spotřebu procesoru. Ovlivněno použitím konkrétních funkcí a operátorů.

Celkový procesor

Skutečný výpočetní procesor, který byl investován do zpracování tohoto dotazu napříč všemi uzly zpracování dotazů. Vzhledem k tomu, že většina dotazů se spouští na velkém počtu uzlů, obvykle bude mnohem větší než doba trvání, jakou dotaz skutečně provedl.

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

Čas zpracování dotazů je strávený na:

  • Načítání dat – načítání 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ů stráví protokoly Služby Azure Monitor čas ověřováním uživatele a ověřením, že má oprávnění k přístupu k datům, vyhledání úložiště dat, parsování dotazu a přidělení uzlů zpracování dotazů. Tentokrát není součástí celkového času procesoru dotazu.

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

Některé příkazy a funkce dotazů jsou náročné na využití procesoru. To platí hlavně pro příkazy, které analyzují JSON a XML nebo extrahují složité regulární výrazy. K takové analýze může dojít explicitně prostřednictvím funkcí parse_json() nebo parse_xml() nebo implicitně při odkazování na dynamické sloupce.

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

Například následující dotazy vytvářejí přesně stejný výsledek, ale druhý je zdaleka nejúčinnější jako podmínka, kdy před parsováním se vyloučí 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 u vyhodnoceného sloupce, a ne na sloupcích, které jsou fyzicky přítomné v datové sadě, ztratí efektivitu. Filtrování vyhodnocovaných sloupců brání optimalizacím některých systémů při zpracování velkých sad dat. Například následující dotazy vytvářejí přesně stejný výsledek, ale druhý dotaz je efektivnější jako podmínka , ve které se podmínka 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 pro zpracování dotazů, protože filtrování se provádí nejen v poli:

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

Použití efektivních příkazů agregace a dimenzí v souhrnu a spojení

I když některé příkazy agregace , jako je max(),sum(),count() a avg() mají kvůli své logice nízký dopad na procesor, jiné jsou složitější a zahrnují heuristické 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; percentilové funkce provádějí podobné aproximace pomocí nejbližšího algoritmu percentilu pořadí. Několik příkazů obsahuje volitelné parametry, které snižují jejich dopad. Například funkce makeset() má volitelný parametr pro definování maximální velikosti sady, která výrazně 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é používají jako by souhrn nebo jako atributy spojení. Vysvětlení a optimalizace spojení a shrnutí najdete v článcích dokumentace a tipy pro optimalizaci.

Například následující dotazy vytvářejí přesně stejný výsledek, protože CounterPath je vždy 1:1 namapovaný na CounterName a ObjectName. Druhá z nich 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 mít vliv také na podmínky nebo rozšířené sloupce, které vyžadují náročný výpočetní výkon. Všechna triviální porovnání řetězců, jako je rovná == a startwith , mají přibližně stejný dopad na procesor, zatímco rozšířené shody textu mají větší dopad. Konkrétně operátor has je efektivnější, že 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 vytvářejí podobné výsledky v závislosti na zásadách pojmenování počítače, ale druhý dotaz je 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 ve více oblastech 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é analýze XML a JSON, když funguje analýza řetězců.

Úplná analýza objektu XML nebo JSON může spotřebovávat vysoké prostředky procesoru a paměti. V mnohapřípadechch kódech je v mnoha případech jednoduché, když jsou potřeba jenom jeden nebo dva parametry a objekty XML nebo JSON jsou jednoduché, je jednodušší je analyzovat jako řetězce. Zvýšení výkonu bude 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 dotazy uvedené výše, aniž by provedl úplnou analýzu XML. Dotaz provádí určité předpoklady o struktuře souborů XML, například, že element FilePath přichází za FileHash 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žitá pro zpracovávaný dotaz

Kritickým faktorem při zpracování dotazu je objem dat, která se kontroluje a používá pro 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 služby Azure Monitor se sloupec TimeGenerated používá jako způsob indexování dat. Omezení hodnot TimeGenerated tak, aby co nejvíce zúžil rozsah, výrazně zlepší výkon dotazů tím, že výrazně omezí 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 data, která je procesem, je použití velkého počtu tabulek. K tomu 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 co nejvíce použití "hledání *" 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 zdaleka 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í dřívější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 Explorer obsahuje mezipaměť, která jí umožňuje zjistit, které oddíly obsahují data, která jsou relevantní pro konkrétní podmínku. Pokud například dotaz obsahuje where EventID == 4624 , distribuuje dotaz pouze uzlům, 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í funkcí podmíněné agregace a materializace funkce

Pokud má dotaz několik poddotazů, které jsou sloučené pomocí operátorů spojení nebo sjednocení, každý poddotaz prohledá celý zdroj samostatně a pak sloučí výsledky. Tím se vynásobí počet kontrol dat – kritický faktor ve velmi velkých datových sadách.

Technika, která se tomu vyhnout, je použití podmíněných agregačních funkcí. Většina agregačních funkcí , které se používají v operátoru souhrnu, má podmíněnou verzi, která umožňuje použít 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í provádění procesů pro každý účet. Vrátí stejné výsledky, ale první kontroluje data dvakrát, druhá kontrola je 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 poddotaze nejsou nutné, je předběžné filtrování operátoru parsování , aby se zajistilo, že zpracovává pouze záznamy, které odpovídají konkrétnímu vzoru. To není nutné, protože operátor parsování a další podobné operátory vrací prázdné výsledky, když se vzor neshoduje. Tady jsou dva dotazy, které vrací přesně stejné výsledky, zatímco druhý dotaz prohledává data pouze jednou. V druhém dotazu je každý příkaz analýzy relevantní pouze pro jeho události. Operátor rozšíření pak ukazuje, jak odkazovat na prázdnou situaci dat.

//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 výše uvedené příkazy neumožňují vyhnout se používání poddotazů, je další technikou naznačovat dotazovací modul, že se v každém z nich používá jedna zdrojová data pomocí funkce materialize(). To je užitečné, když zdrojová data pocházejí z funkce, která se používá několikrát v dotazu. Materializace je účinná, pokud je výstup poddotazů mnohem menší než vstup. Dotazovací modul uloží 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 sloupcích. Počet načtených sloupců přímo ovlivňuje celkový objem dat. Do výstupu byste měli zahrnout jenom sloupce potřebné souhrnem výsledků nebo projektováním konkrétních sloupců. Azure Data Explorer má několik optimalizací, které snižují 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 zpracovávat třikrát více dat, protože musí 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 zpracovávaného dotazu

Všechny protokoly v protokolech služby Azure Monitor jsou rozdělené podle sloupce TimeGenerated . 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 výzvy.

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 je možné 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. Toto je doporučená metoda, protože vybraný časový rozsah se předává do back-endu pomocí metadat dotazu.

Alternativní metodou je explicitně zahrnout podmínku where v TimeGenerated v dotazu. Tuto metodu byste měli použít, protože zajišťuje, že časový rozsah je opravený, i když se dotaz používá z jiného rozhraní. Měli byste zajistit, aby všechny části dotazu měly filtry TimeGenerated . Pokud dotaz obsahuje poddotazy, které načítají data z různých tabulek nebo stejné tabulky, musí každý obsahovat vlastní podmínku where .

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

Například v následujícím dotazu bude tabulka Perf prohledávána pouze za poslední den, bude tabulka prezentování prohledávána pro všechny její historie, 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ě dochází, 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

To lze 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 provádění filtrování rozsahu času těsně po sjednocení několika tabulek. Při sjednocování by měly být všechny poddotazy vymezeny. Příkaz let můžete použít k zajištění konzistence rozsahu.

Následující dotaz například zkontroluje všechna data v tabulkách Prezenčních signálů a perf , nejen posledních 1 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

Tento dotaz by měl být opraven následujícím způsobem:

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ů. Důvodem je to, že systém rozděluje data do bloků proměnných velikostí. Aby se zajistilo, že se naskenují všechny relevantní záznamy, systém prohledá celý oddíl, který může pokrýt několik hodin a dokonce více než den.

Existuje několik případů, kdy systém nemůže poskytnout přesné měření časového rozsahu. K tomu 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 okamžitém clusteru. V dotazu ve více oblastech by představoval pouze jednu z oblastí. V dotazu s více pracovními prostory nemusí obsahovat všechny pracovní prostory.

Věk 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. Čím novější data, tím vyšší je šance, že je 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 metadata uložená 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.

I když některé dotazy vyžadují použití starých dat, existují případy, kdy se stará data používají omylem. K tomu dochází, když se dotazy spustí bez poskytnutí časového rozsahu v jejich meta-datech a ne všechny odkazy na tabulky zahrnují filtr ve sloupci TimeGenerated . V těchto případech systém prohledá všechna data uložená v této tabulce. Pokud je uchovávání dat dlouhé, může pokrýt dlouhé časové rozsahy a 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 s poddotazem, který není omezený. Viz příklad výše.
  • Použití rozhraní API bez volitelných parametrů časového rozsahu
  • Použití klienta, který nevynutí časový rozsah, jako je konektor Power BI.

Podívejte se na příklady a poznámky v oddílu, který je v tomto případě relevantní.

Počet oblastí

Existuje několik situací, kdy se může spustit jeden dotaz v různých oblastech:

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

Provádění dotazů mezi oblastmi vyžaduje, aby systém serializoval a přenesl do back-endových velkých bloků 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, heuristiku a využívat mezipaměti. Pokud neexistuje žádný skutečný důvod ke kontrole všech těchto oblastí, měli byste upravit rozsah tak, aby zahrnoval méně oblastí. Pokud je rozsah prostředků minimalizovaný, ale stále se používá mnoho oblastí, může k tomu dojít kvůli chybné konfiguraci. Například protokoly auditu a nastavení diagnostiky se odesílají do různých pracovních prostorů v různých oblastech nebo existuje několik konfigurací nastavení diagnostiky.

Dotaz, který zahrnuje více než 3 oblasti, se považuje za dotaz, který spotřebovává nadměrné prostředky. Dotaz, který zahrnuje více než 6 oblastí, se považuje za zneužívající dotaz a může být omezený.

Důležité

Když se dotaz spustí v několika oblastech, nebude měření procesoru a dat přesné a bude představovat měření pouze v 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ů na fyzických clusterech v rámci vybrané oblasti.

Využití více pracovních prostorů může mít za následek:

  • Kde je explicitně uvedeno několik pracovních prostorů.
  • Když dotaz s oborem prostředků načítá data a data se ukládají do více pracovních prostorů.

Provádění dotazů napříč oblastmi a napříč clustery vyžaduje, aby systém serializoval a přenesl do back-endových velkých bloků 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, heuristicky a využívat mezipaměti.

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

Důležité

V některých scénářích s více pracovními prostory nebude měření procesoru a dat přesné a bude představovat měření pouze pro několik pracovních prostorů.

Paralelnost

Protokoly Azure Monitoru používají k spouštění dotazů velké clustery Azure Data Explorer a tyto clustery se liší ve velkém měřítku a potenciálně se zvětšují až na desítky výpočetních uzlů. Systém automaticky škáluje clustery podle logiky a kapacity umístění pracovního prostoru.

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 to systém nedokáže efektivně provést. To může vést k dlouhé době trvání dotazu.

Mezi chování dotazů, které můžou snížit paralelismus, patří:

  • Použití serializace a okenních funkcí, jako je operátor serializace, next(), prev() a funkce řádků . Funkce časové řady a analýzy uživatelů se dají v některých případech použít. Neefektivní serializace může také nastat, pokud se na konci dotazu nepoužívají následující operátory: rozsah, řazení, pořadí, top, top-hitters, getschema.
  • Použití agregační funkce dcount() vynutí, aby systém měl centrální kopii jedinečných hodnot. Pokud je měřítko dat vysoké, zvažte použití volitelných parametrů funkce dcount ke snížení přesnosti.
  • V mnoha případech operátor spojení snižuje celkový paralelismus. Prozkoumejte spojení shuffle jako alternativu, pokud je výkon problematický.
  • V dotazech na rozsah prostředků může předběžné provádění kontrol RBAC kubernetes nebo Azure RBAC trvat v situacích, kdy existuje velmi velký počet přiřazení rolí Azure. To může vést k delším kontrolám, které by mohly vést k nižší paralelismu. Dotaz se například provádí 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 u předplatného nebo skupiny prostředků.
  • Pokud dotaz zpracovává malé bloky dat, bude jeho paralelismus nízký, protože systém ho nerozloží mezi mnoho výpočetních uzlů.

Další kroky