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

  • Článek

Protokoly Azure Monitoru používají Azure Data Explorer k ukládání dat protokolů a spouštění dotazů pro analýzu těchto dat. Vytváří, spravuje a udržuje clustery Azure Data Explorer 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 Explorer, který ukládá data pracovního prostoru.

Protokoly Azure Monitoru 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, jak je opravit.

Většina technik je běžná pro dotazy, které se spouští přímo v protokolech Azure Data Explorer a Azure Monitor. Probíráme také 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:

  • Rychlejší spuštění a zkrácení celkové doby trvání provádění dotazu
  • Máte menší šanci, že budete omezeni nebo odmítnuti.

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

Tady je podrobné video s návodem k optimalizaci dotazů.

Podokno Podrobnosti dotazu

Po spuštění dotazu v Log Analytics výběrem možnosti Podrobnosti dotazu v pravém dolním rohu obrazovky otevřete podokno Podrobnosti dotazu . V tomto podokně se zobrazují výsledky několika indikátorů výkonu dotazu. Tyto ukazatele výkonu jsou popsány v následující části.

Snímek obrazovky znázorňující podokno Podrobnosti dotazu v Azure Monitor Log Analytics

Indikátory výkonu dotazů

Následující ukazatele výkonu dotazů jsou k dispozici pro každý spuštěný dotaz:

  • Celkový procesor: Celkový výpočetní výkon použitý ke zpracování dotazu napříč všemi výpočetními uzly. Představuje čas používaný k výpočtům, parsování a načítání dat.
  • Data používaná ke zpracování dotazu: Celková data, která byla použita ke zpracování dotazu. Ovlivněno velikostí cílové tabulky, použitým časovým rozsahem, použitými filtry a počtem odkazovaných sloupců.
  • Časové rozpětí zpracovaného dotazu: Mezera mezi nejnovějšími a nejstaršími daty, ke kterým se přistupovalo za účelem zpracování dotazu. Ovlivněno explicitním časovým rozsahem zadaným pro dotaz.
  • Stáří zpracovaných dat: Rozdíl mezi aktuálně a nejstaršími daty, ke kterým se přistupovalo ke zpracování dotazu. Výrazně ovlivňuje efektivitu načítání dat.
  • Počet pracovních prostorů: Kolik pracovních prostorů bylo při zpracování dotazu přistupováno na základě implicitního nebo explicitního výběru.
  • Počet oblastí: Počet oblastí, ke kterým se přistupovalo během zpracování dotazu na základě implicitního nebo explicitního výběru pracovních prostorů. Dotazy na více oblastí jsou mnohem méně efektivní a indikátory výkonu představují částečné pokrytí.
  • Paralelismus: Udává, do jaké míry byl systém schopen provést tento dotaz na více uzlech. Relevantní pouze pro dotazy s vysokým využitím 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 ve všech uzlech zpracování dotazů. Vzhledem k tomu, že většina dotazů se spouští na velkém počtu uzlů, bude tento součet obvykle mnohem větší než doba trvání provádění dotazu.

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

Čas zpracování dotazů se věnuje:

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

Kromě času stráveného v uzlech zpracování dotazů se protokoly Azure Monitoru věnují také:

  • Ověření uživatele a ověření, že má povolený přístup k datům.
  • Vyhledání úložiště dat
  • Parsování dotazu
  • Přidělování uzlů zpracování dotazů.

Tato doba není zahrnutá do celkového času procesoru dotazu.

Vč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 využití procesoru. Tento případ platí zejména pro příkazy, které parsují 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ě, 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řidání where podmínek v rané fázi dotazu. Tímto způsobem mohou vyfiltrovat co nejvíce záznamů před spuštěním funkce náročné na procesor.

Například následující dotazy přivedou přesně stejný výsledek. Druhý je ale nejúčinnější, protože podmínka where před analýzou 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í vyhodnocených klauzulí where

Dotazy, které obsahují klauzule where u vyhodnoceného sloupce, nikoli ve sloupcích, které jsou fyzicky přítomné v datové sadě, ztratí efektivitu. Filtrování vyhodnocený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 přivedou 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 se vyhodnocovaný sloupec vytvoří implicitně modulem zpracování dotazů, protože filtrování neprobíná jenom v poli:

//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í v souhrnu a spojení

Některé agregační příkazy, jako jsou max(), sum(), count() a avg(), mají kvůli logice nízký dopad na procesor. Jiné příkazy jsou složitější a obsahují heuristika a odhady, které umožňují jejich efektivní provádění. Například dcount() používá algoritmus HyperLogLog k poskytnutí 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í algoritmu nejbližšího percentilu pořadí. Některé příkazy obsahují volitelné parametry, které snižují jejich dopad. Například funkce makeset() má volitelný parametr, který definuje maximální velikost sady, což výrazně ovlivňuje procesor a paměť.

Příkazy join a summarize můžou 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 atributy v summarize nebo jako join atributy. Vysvětlení a optimalizaci a summarizenajdete v join jejich článcích v dokumentaci a v tipech pro optimalizaci.

Například následující dotazy generují přesně stejný výsledek, protože CounterPath jsou vždy 1:1 namapované na CounterName a ObjectName. Druhý 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

Spotřebu procesoru můžou ovlivnit where také podmínky nebo rozšířené sloupce, které vyžadují intenzivní výpočetní výkon. Všechna triviální porovnání řetězců, například rovná se == 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 contains . 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í. Ale druhý 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 bezprostředního clusteru. V dotazu na více oblastí by představoval pouze jednu z oblastí. Dotaz s více pracovními prostory nemusí zahrnovat všechny pracovní prostory.

Pokud analýza řetězců funguje, vyhněte se úplné analýze XML a JSON.

Úplná analýza objektu XML nebo JSON může spotřebovávat velké množství prostředků procesoru a paměti. V mnoha případech, kdy je potřeba jenom jeden nebo dva parametry a objekty XML nebo JSON jsou jednoduché, je jednodušší je parsovat jako řetězce. Použijte operátor parse nebo jiné techniky analýzy textu. Zvýšení výkonu bude významnější, protože se zvýší počet záznamů v objektu XML nebo JSON. Je to nezbytné, když počet záznamů dosáhne desítek milionů.

Například následující dotaz vrátí přesně stejné výsledky jako předchozí dotazy, aniž by provedl úplnou analýzu XML. Dotaz provádí určité předpoklady o struktuře souborů XML, například FilePath element následuje 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žívaná pro zpracovaný dotaz

Důležitým faktorem při zpracování dotazu je objem kontrolovaných dat, která se používají ke zpracování dotazu. Azure Data Explorer používá agresivní optimalizace, které výrazně snižují objem dat v porovnání s jinými datovými platformami. Přesto jsou v dotazu kritické faktory, které můžou mít vliv na objem používaných dat.

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

V protokolech služby Azure Monitor se TimeGenerated sloupec používá jako způsob indexování dat. Omezení TimeGenerated hodnot na co nejužší rozsah zlepší 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 sjednocování

Dalším faktorem, který zvyšuje počet zpracovávaných dat, je použití velkého počtu tabulek. K tomuto scénáři obvykle dochází při search * použití příkazů a union * . Tyto příkazy vynutí systém vyhodnotit a prohledávat data ze všech tabulek v pracovním prostoru. V některých případech můžou být v pracovním prostoru stovky tabulek. Pokuste se vyhnout použití search * nebo jakémukoli hledání, aniž byste ho museli určit na konkrétní tabulku.

Například následující dotazy přivedou úplně stejný výsledek, ale poslední z nich 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ší metodou, jak snížit objem dat, je použití podmínek v rané fázi dotazu. Platforma Azure Data Explorer obsahuje mezipaměť, která jí dává vědět, které oddíly obsahují data, která jsou 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í příklad dotazů vygeneruje přesně stejný výsledek, ale druhý dotaz 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.

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

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

Následující dotazy například 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 zkontroluje data dvakrát. Druhý dotaz ho zkontroluje jenom 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 nejsou poddotazy nutné, je předběžné filtrování pro operátor parse , aby se zajistilo, že zpracovává pouze záznamy, které odpovídají určitému vzoru. Jsou zbytečné, protože operátor parse a další podobné operátory vrací prázdné výsledky, když se vzor neshoduje. Následující dva dotazy vrátí přesně stejné výsledky, ale druhý dotaz zkontroluje data jenom jednou. Ve druhém dotazu je každý příkaz parse relevantní jenom pro jeho události. Operátor extend pak ukazuje, jak odkazovat na situaci s prázdnými 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čit dotazovacímu stroji, že se v každém z nich používá jeden zdroj dat, a to pomocí funkce materialize(). Tato technika je užitečná, když zdrojová data pocházejí z funkce, která se v rámci dotazu používá několikrát. Materialize je efektivní, když je výstup poddotazů mnohem menší než vstup. Dotazovací modul uloží výstup do mezipaměti a opakovaně ho použije ve všech výskytech.

Snížení počtu načítaných sloupců

Vzhledem k tomu, že Azure Data Explorer je sloupcové úložiště dat, načtení 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 byste měli zahrnout pouze sloupce, které jsou potřeba shrnutím výsledků nebo promítnutím konkrétních sloupců.

Azure Data Explorer nabízí několik optimalizací, které snižují počet načtených sloupců. Pokud zjistí, že sloupec není potřeba, například pokud na něj není odkazováno v příkazu summarize , nenačte ho.

Druhý dotaz může například zpracovat třikrát více dat, protože potřebuje načíst ne 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é rozpětí zpracovaného dotazu

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

Dotaz s časovým rozsahem delším než 15 dnů se považuje za dotaz, který spotřebovává nadměrné množství prostředků. Dotaz s časovým rozsahem delším než 90 dnů se považuje za urážlivý 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 tématu Obor dotazu na protokol a časový rozsah ve službě Azure Monitor Log Analytics. Tato metoda se doporučuje, protože vybraný časový rozsah se předává do back-endu pomocí metadat dotazu.

Alternativní metodou je explicitně zahrnout podmínku where on TimeGenerated do dotazu. Tuto metodu použijte, protože zajišťuje, že časový rozsah 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 svoji 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. V Heartbeat tabulce se prohledá veškerá její historie, která 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 vyhledání poslední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 filtru času 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ž provedete filtrování časového rozsahu těsně po sjednocení několika tabulek. Při provádění sjednocení by měl být každý poddotaz vymezený. K zajištění konzistence oborů můžete použít příkaz let .

Například následující dotaz zkontroluje všechna data v Heartbeat tabulkách 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ž skutečný zadaný čas. Pokud je například filtr dotazu 7 dní, systém může kontrolovat 7,5 nebo 8,1 dne. Tato odchylka je způsobená tím, že systém rozděluje data do bloků proměnných velikostí. Aby se zajistilo, že jsou zkontrolovány všechny relevantní záznamy, systém prohledá celý oddíl. Tento proces může pokrývat několik hodin a dokonce i déle než jeden den.

Existuje několik případů, kdy systém nedokáž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 na více oblastí by představoval pouze jednu z oblastí. Dotaz s více pracovními prostory nemusí zahrnovat 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. Čím novější jsou data, tím větší je pravděpodobnost, že se uloží na výkonnější úrovni s menší latencí, což zkracuje dobu trvání dotazu a zkracuje využití procesoru. Kromě samotných dat má systém také mezipaměť pro metadata. Čím jsou data starší, tím menší je pravděpodobnost, že jejich metadata budou v mezipaměti.

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

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ž jsou dotazy spuštěny bez zadání časového rozsahu v metadatech a ne všechny odkazy na tabulky obsahují filtr sloupce TimeGenerated . V těchto případech systém zkontroluje všechna data uložená v tabulce. Pokud je uchovávání dat dlouhé, může pokrývat dlouhé časové rozsahy. V důsledku toho se kontroluje data, která jsou stejně stará jako doba uchovávání dat.

Takové případy mohou být například:

  • Nenastavuje časový rozsah v Log Analytics s poddotazem, 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 relevantní i v tomto případě.

Počet oblastí

V některých situacích může být v různých oblastech proveden jeden dotaz. Příklad:

  • Když je explicitně uvedeno několik pracovních prostorů, které se nacházejí v různých oblastech.
  • Když dotaz s rozsahem prostředků načítá data a data jsou uložená ve více pracovních prostorech, které se nacházejí v různých oblastech.

Provádění dotazů mezi oblastmi vyžaduje, aby systém serializoval a přenášel v 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 heuristiku a používat mezipaměti.

Pokud není důvod kontrolovat 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 tomu dojít kvůli chybné konfiguraci. Protokoly auditu a nastavení diagnostiky se můžou například odesílat do různých pracovních prostorů v různých oblastech nebo může existovat více konfigurací nastavení diagnostiky.

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

Důležité

Při spuštění dotazu napříč několika oblastmi nebudou měření procesoru a dat přesná a budou 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ů na 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:

  • Několik pracovních prostorů je explicitně uvedeno.
  • Dotaz s oborem prostředků načítá data a data se ukládají ve více pracovních prostorech.

Provádění dotazů mezi oblastmi a mezi clustery vyžaduje, aby systém serializoval a přenášel v 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 heuristiku a používat mezipaměti.

Dotaz, který pokrývá více než pět pracovních prostorů, se považuje za dotaz, který spotřebovává nadměrné množství prostředků. Dotazy nemohou 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í jenom několika pracovních prostorů.
  • Dotazy mezi pracovními prostory, které mají explicitní identifikátor: ID pracovního prostoru nebo ID prostředku pracovního prostoru Azure, spotřebovávají méně prostředků a jsou výkonnější. Viz Vytvoření dotazu protokolu ve více pracovních prostorech.

Paralelnost

Protokoly služby Azure Monitor používají ke spouštění dotazů velké clustery Azure Data Explorer. Tyto clustery se liší škálováním a potenciálně můžou získat až desítky výpočetních uzlů. Systém automaticky škáluje clustery podle logiky a kapacity umístění pracovního prostoru.

Aby bylo možné efektivně spustit dotaz, je rozdělený do oddílů a distribuovaný do výpočetních uzlů na základě dat potřebných pro jeho zpracování. V některých situacích systém nemůže tento krok provést efektivně, což může vést k dlouhému trvání dotazu.

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

  • Použití funkcí serializace a oken, jako je například operátor serializace, next(), prev() a funkce řádků . V některých z těchto případů je možné použít funkce časové řady a analýzy uživatelů. K neefektivní serializaci může dojít také v případě, že se na konci dotazu nepoužívají následující operátory: range, sort, order, top, top-hitters a getschema.
  • Použití agregační funkce dcount() vynutí, aby systém měl centrální kopii jedinečných hodnot. Pokud je škálování dat vysoké, zvažte použití volitelných dcount parametrů funkce ke snížení přesnosti.
  • V mnoha případech operátor join snižuje celkový paralelismus. Prozkoumejte shuffle join jako alternativu, pokud je výkon problematický.
  • V dotazech na obor prostředků můžou kontroly řízení přístupu na základě role (RBAC) nebo Azure RBAC před spuštěním Kubernetes 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 vedly k nižšímu paralelismu. Dotaz může být například 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, nikoli v předplatném nebo skupině prostředků.
  • Pokud dotaz zpracovává malé bloky dat, jeho paralelismus bude nízký, protože systém ho nerozloží mezi mnoho výpočetních uzlů.

Další kroky

Referenční dokumentace k dotazovací jazyk Kusto