Naplók optimalizálása Azure MonitorbanOptimize log queries in Azure Monitor

Azure Monitor naplók az Azure adatkezelő (ADX) használatával tárolják a naplófájlokat, és lekérdezéseket futtatnak az adatok elemzéséhez.Azure Monitor Logs uses Azure Data Explorer (ADX) to store log data and run queries for analyzing that data. Létrehozza, kezeli és karbantartja a ADX-fürtöket, és optimalizálja azokat a log Analysis számítási feladatokhoz.It creates, manages, and maintains the ADX clusters for you, and optimizes them for your log analysis workload. Amikor lekérdezést futtat, az optimalizált, és a munkaterület-adatok tárolására szolgáló megfelelő ADX-fürtre irányítja.When you run a query, it's optimized, and routed to the appropriate ADX cluster that stores the workspace data. A Azure Monitor-naplók és az Azure Adatkezelő számos automatikus lekérdezés-optimalizálási mechanizmust használ.Both Azure Monitor Logs and Azure Data Explorer uses many automatic query optimization mechanisms. Míg az automatikus optimalizálás jelentős lökést nyújt, bizonyos esetekben jelentősen növelheti a lekérdezési teljesítményt.While automatic optimizations provide significant boost, there are some cases where you can dramatically improve your query performance. Ez a cikk ismerteti a teljesítménnyel kapcsolatos szempontokat és számos technikát a kijavításához.This article explains the performance considerations and several techniques to fix them.

A módszerek többsége gyakori az Azure-Adatkezelő és Azure Monitor naplókon futtatott lekérdezések esetében, bár számos egyedi Azure Monitor naplózási szempontot ismertetünk.Most of the techniques are common to queries that are run directly on Azure Data Explorer and Azure Monitor Logs, though there are several unique Azure Monitor Logs considerations that are discussed here. További Azure Adatkezelő optimalizálási tippek: lekérdezés – ajánlott eljárások.For more Azure Data Explorer optimization tips, see Query best practices.

Az optimalizált lekérdezések a következőket teszik:Optimized queries will:

  • A lekérdezés-végrehajtás teljes időtartamának csökkentése a gyorsabb futtatással.Run faster, reduce overall duration of the query execution.
  • Kisebb eséllyel szabályozható vagy elutasított.Have smaller chance of being throttled or rejected.

Ügyeljen arra, hogy az ismétlődő és a burst használatra használt lekérdezések, például az irányítópultok, a riasztások, a Logic Apps és a Power BI.You should give particular attention to queries that are used for recurrent and bursty usage such as dashboards, alerts, Logic Apps and Power BI. A nem hatékony lekérdezések hatása ezekben az esetekben jelentős.The impact of an ineffective query in these cases is substantial.

Lekérdezési teljesítmény ablaktáblaQuery performance pane

Miután lefuttatott egy lekérdezést a Log Analyticsban, a lekérdezési eredmények fölötti lefelé mutató nyílra kattintva megtekintheti a lekérdezési teljesítmény panelt, amely a lekérdezés számos teljesítménymutatójának eredményét jeleníti meg.After you run a query in Log Analytics, click the down arrow above the query results to view the query performance pane that shows the results of several performance indicators for the query. Ezeket a teljesítménymutatókat a következő szakaszban ismertetjük.These performance indicators are each described in the following section.

Lekérdezési teljesítmény ablaktábla

Lekérdezési teljesítménymutatókQuery performance indicators

A következő lekérdezési teljesítménymutatók érhetők el minden végrehajtott lekérdezéshez:The following query performance indicators are available for every query that is executed:

  • Összes CPU: teljes számítási művelet, amely a lekérdezés feldolgozására szolgál az összes számítási csomóponton.Total CPU: Overall compute used to process the query across all compute nodes. Ez a módszer a számítástechnikai, elemzési és beolvasási időt jelöli.It represents time used for computing, parsing, and data fetching.

  • Feldolgozott lekérdezéshez használt adatmennyiség: a lekérdezés feldolgozásához elért összesített adatmennyiség.Data used for processed query: Overall data that was accessed to process the query. A cél tábla mérete, a használt időtartomány, az alkalmazott szűrők és a hivatkozott oszlopok száma befolyásolja.Influenced by the size of the target table, time span used, filters applied, and the number of columns referenced.

  • A feldolgozott lekérdezés időbeliidőtartama: a lekérdezés feldolgozásához használt legújabb és legrégebbi adatmennyiség közötti különbség.Time span of the processed query: The gap between the newest and the oldest data that was accessed to process the query. A lekérdezéshez megadott explicit időtartomány befolyásolja.Influenced by the explicit time range specified for the query.

  • A feldolgozott adatmennyiség kora: a jelenlegi és a legrégebbi, a lekérdezés feldolgozásához elért adatmennyiség.Age of processed data: The gap between now and the oldest data that was accessed to process the query. Ez nagy mértékben befolyásolja az beolvasás hatékonyságát.It highly influences the efficiency of data fetching.

  • Munkaterületek száma: az implicit vagy explicit kijelölés miatt a lekérdezés feldolgozásakor hány munkaterület érhető el.Number of workspaces: How many workspaces were accessed during the query processing due to implicit or explicit selection.

  • Régiók száma: a lekérdezés feldolgozásakor hány régió fér hozzá a munkaterületek implicit vagy explicit kiválasztása miatt.Number of regions: How many regions were accessed during the query processing based due to implicit or explicit selection of workspaces. A többrégiós lekérdezések sokkal kevésbé hatékonyak, a teljesítménymutatók pedig részleges lefedettséget jelentenek.Multi-region queries are much less efficient and performance indicators present partial coverage.

  • Párhuzamosság: azt jelzi, hogy a rendszer milyen mértékben tudta végrehajtani ezt a lekérdezést több csomóponton.Parallelism: Indicates how much the system was able to execute this query on multiple nodes. Csak a nagy CPU-fogyasztással rendelkező lekérdezésekre vonatkozik.Relevant only to queries that have high CPU consumption. Az adott függvények és operátorok használatának befolyásolására.Influenced by usage of specific functions and operators.

Teljes CPUTotal CPU

A tényleges számítási CPU, amely a lekérdezés feldolgozására lett befektetve az összes lekérdezés-feldolgozó csomóponton.The actual compute CPU that was invested to process this query across all the query processing nodes. Mivel a legtöbb lekérdezés nagy számú csomóponton fut, ez általában sokkal nagyobb, mint a lekérdezés tényleges végrehajtásának időtartama.Since most queries are executed on large numbers of nodes, this will usually be much larger than the duration the query actually took to execute.

A több mint 100 másodperces CPU-t használó lekérdezés olyan lekérdezésnek minősül, amely túlzott erőforrásokat használ fel.Query that utilizes more than 100 seconds of CPU is considered a query that consumes excessive resources. A több mint 1 000 másodperces CPU-t használó lekérdezések visszaélésszerű lekérdezésnek minősülnek, és lehetséges, hogy szabályozva vannak.Query that utilizes more than 1,000 seconds of CPU is considered an abusive query and might be throttled.

A lekérdezés feldolgozási idejének elköltése:Query processing time is spent on:

  • Adatok beolvasása – a régi adatok lekérése több időt vesz igénybe, mint a legutóbbi adatok beolvasása.Data retrieval – retrieval of old data will consume more time than retrieval of recent data.
  • Adatfeldolgozás – az adatgyűjtés logikája és kiértékelése.Data processing – logic and evaluation of the data.

A lekérdezés-feldolgozási csomópontokon töltött idő kivételével további időt Azure Monitor naplók is töltenek: hitelesítse a felhasználót, és ellenőrizze, hogy engedélyezett-e az ilyen adathozzáférés, az adattár megkeresése, a lekérdezés elemzése és a lekérdezés-feldolgozási csomópontok lefoglalása.Other than time spent in the query processing nodes, there is additional time that is spend by Azure Monitor Logs to: authenticate the user and verify that they are permitted to access this data, locate the data store, parse the query, and allocate the query processing nodes. Ez az idő nem szerepel a lekérdezés teljes CPU-ideje alatt.This time is not included in the query total CPU time.

A rekordok korai szűrése a nagy CPU-függvények használata előttEarly filtering of records prior of using high CPU functions

A lekérdezési parancsok és függvények némelyike nehéz a CPU-használatban.Some of the query commands and functions are heavy in their CPU consumption. Ez különösen igaz azokra a parancsokra, amelyek a JSON-t és az XML-t elemezik, vagy az összetett reguláris kifejezéseketThis is especially true for commands that parse JSON and XML or extract complex regular expressions. Az ilyen elemzések parse_json () vagy parse_xml () függvények vagy implicit módon történhetnek, amikor dinamikus oszlopokra hivatkoznak.Such parsing can happen explicitly via parse_json() or parse_xml() functions or implicitly when referring to dynamic columns.

Ezek a függvények a feldolgozott sorok számának arányában használják a PROCESSZORt.These functions consume CPU in proportion to the number of rows they are processing. A leghatékonyabb optimalizálás a lekérdezés korai szakaszában való hozzáadás, amely a CPU-igényes funkció végrehajtása előtt a lehető legtöbb rekordot képes kiszűrni.The most efficient optimization is to add where conditions early in the query that can filter out as many records as possible before the CPU intensive function is executed.

Például a következő lekérdezések pontosan ugyanazt az eredményt eredményezik, de a második a leghatékonyabb, mint a Where feltétel, mielőtt az elemzés során kizárja a sok rekordot:For example, the following queries produce exactly the same result but the second one is by far the most efficient as the where condition before parsing excludes many records:

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

Kerülje a kiértékelt where záradékok használatátAvoid using evaluated where clauses

Azok a lekérdezések, amelyek Where záradékot tartalmaznak egy kiértékelt oszlopon, és nem az adathalmazban fizikailag szereplő oszlopok, elvesztik a hatékonyságot.Queries that contain where clauses on an evaluated column rather than on columns that are physically present in the dataset lose efficiency. A kiértékelt oszlopok szűrése megakadályozza a rendszeroptimalizálást, ha nagy adathalmazok vannak kezelve.Filtering on evaluated columns prevents some system optimizations when large sets of data are handled. Például a következő lekérdezések pontosan ugyanazt az eredményt eredményezik, a második pedig hatékonyabb, mivel a Where feltétel a beépített oszlopra hivatkozik.For example, the following queries produce exactly the same result but the second one is more efficient as the where condition refers to built-in column

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

Bizonyos esetekben a kiértékelt oszlopot a lekérdezés-feldolgozó motor implicit módon hozza létre, mivel a szűrés nem csupán a következő mezőn történik:In some cases the evaluated column is created implicitly by the query processing engine since the filtering is done not just on the field:

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

Hatékony aggregációs parancsok és méretek használata az összegzésben és a csatlakozáshozUse effective aggregation commands and dimensions in summarize and join

Míg egyes aggregációs parancsok, például a Max (), a Sum (), a Count ()és az AVG () az alacsony CPU-hatást okoznak a logikájuk miatt, más összetettebbek, és olyan becsléseket tartalmaznak, amelyek lehetővé teszik a hatékony végrehajtást.While some aggregation commands like max(), sum(), count(), and avg() have low CPU impact due to their logic, other are more complex and include heuristics and estimations that allow them to be executed efficiently. Például a DCount () a HyperLogLog algoritmus használatával közelíti meg a nagy adathalmazok különböző számú adatát az egyes értékek tényleges számbavétele nélkül. a percentilis függvények hasonló közelítéseket végeznek a legközelebbi rangsorú percentilis algoritmus használatával.For example, dcount() uses the HyperLogLog algorithm to provide close estimation to distinct count of large sets of data without actually counting each value; the percentile functions are doing similar approximations using the nearest rank percentile algorithm. A parancsok közül több olyan választható paramétereket is tartalmaz, amelyek csökkentik a hatásukat.Several of the commands include optional parameters to reduce their impact. Például a makeset () függvény nem kötelező paraméterrel határozhatja meg a maximálisan megengedett méretet, ami jelentősen befolyásolja a processzort és a memóriát.For example, the makeset() function has an optional parameter to define the maximum set size, which significantly affects the CPU and memory.

A Csatlakozás és a parancsok összefoglalása magas CPU-kihasználtságot okozhat, ha nagy mennyiségű adathalmazt dolgoz fel.Join and summarize commands may cause high CPU utilization when they are processing a large set of data. Az összetettségük közvetlenül kapcsolódik a lehetséges értékek számához, amelyet az by Összefoglalásként vagy illesztési attribútumokként használt oszlopok közül a függvénynek nevezünk.Their complexity is directly related to the number of possible values, referred to as cardinality, of the columns that are using as the by in summarize or as the join attributes. A JOIN és az összefoglalás ismertetését és optimalizálását a dokumentációs cikkek és optimalizálási tippek című cikkben találja.For explanation and optimization of join and summarize, see their documentation articles and optimization tips.

Például a következő lekérdezések pontosan ugyanazt az eredményt eredményezik, mivel a CounterPath mindig egy-az-egyhez van leképezve a CounterName és a ObjectName.For example, the following queries produce exactly the same result because CounterPath is always one-to-one mapped to CounterName and ObjectName. A második egy hatékonyabb, mivel az összesítési dimenzió kisebb:The second one is more efficient as the aggregation dimension is smaller:

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

A CPU-használatot befolyásolhatja az olyan feltételek vagy kibővített oszlopok esetében is, amelyek intenzív számítástechnikai Igényűek.CPU consumption might also be impacted by where conditions or extended columns that require intensive computing. Minden olyan triviális karakterlánc-összehasonlítás, mint például az EQUAL = = és a startswith , nagyjából ugyanaz a CPU-hatás, míg a speciális szöveges találatok nagyobb hatással vannak.All trivial string comparisons such as equal == and startswith have roughly the same CPU impact while advanced text matches have more impact. Pontosabban a has operátora hatékonyabb, hogy a tartalmazza az operátort.Specifically, the has operator is more efficient that the contains operator. A karakterlánc-kezelési technikák miatt hatékonyabb a rövid sztringnél hosszabb karakterláncok megkeresése.Due to string handling techniques, it is more efficient to look for strings that are longer than four characters than short strings.

Az alábbi lekérdezések például a számítógép elnevezési házirendjétől függően hasonló eredményeket hoznak létre, a második pedig hatékonyabb:For example, the following queries produce similar results, depending on Computer naming policy, but the second one is more efficient:

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

Megjegyzés

Ez a mutató csak a közvetlen fürtből származó CPU-t jeleníti meg.This indicator presents only CPU from the immediate cluster. A többrégiós lekérdezésekben csak az egyik régiót jelöli.In multi-region query, it would represent only one of the regions. Több munkaterület lekérdezése esetén előfordulhat, hogy nem tartalmazza az összes munkaterületet.In multi-workspace query, it might not include all workspaces.

A karakterlánc-elemzés működése során Kerülje a teljes XML-és JSON-elemzéstAvoid full XML and JSON parsing when string parsing works

Egy XML-vagy JSON-objektum teljes elemzése nagy mennyiségű processzor-és memória-erőforrást is igénybe vehet.Full parsing of an XML or JSON object may consume high CPU and memory resources. Sok esetben, ha csak egy vagy két paraméterre van szükség, és az XML-vagy JSON-objektumok egyszerűek, az elemzési operátor vagy más szöveges elemzési módszerekhasználatával könnyebben elemezheti őket karakterláncként.In many cases, when only one or two parameters are needed and the XML or JSON objects are simple, it is easier to parse them as strings using the parse operator or other text parsing techniques. A teljesítmény növelése nagyobb jelentőséggel bír, mert az XML-vagy JSON-objektumban lévő rekordok száma növekszik.The performance boost will be more significant as the number of records in the XML or JSON object increases. Elengedhetetlen, ha a rekordok száma több tízezer milliót is elér.It is essential when the number of records reaches tens of millions.

A következő lekérdezés például pontosan ugyanazokat az eredményeket fogja visszaadni, mint a fenti lekérdezéseket anélkül, hogy teljes XML-elemzést végezne.For example, the following query will return exactly the same results as the queries above without performing full XML parsing. Vegye figyelembe, hogy az XML-fájl struktúrájában bizonyos feltételezések merülnek fel, például az, hogy a FilePath elem a FileHash után jön, és ezek egyike sem rendelkezik attribútumokkal.Note that it makes some assumptions on the XML file structure such as that FilePath element comes after FileHash and none of them has attributes.

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

Feldolgozott lekérdezéshez használt adatértékekData used for processed query

A lekérdezés feldolgozásának kritikus tényezője a lekérdezett és a lekérdezések feldolgozásához használt adatmennyiség.A critical factor in the processing of the query is the volume of data that is scanned and used for the query processing. Az Azure Adatkezelő agresszív optimalizációt használ, amely jelentősen csökkenti az adatmennyiséget más adatplatformokhoz képest.Azure Data Explorer uses aggressive optimizations that dramatically reduce the data volume compared to other data platforms. A lekérdezésben kritikus tényezők is vannak, amelyek befolyásolhatják a használt adatmennyiséget.Still, there are critical factors in the query that can impact the data volume that is used.

A kettőnél több 000KB feldolgozó lekérdezés olyan lekérdezésnek minősül, amely túlzott erőforrást használ.Query that processes more than 2,000KB of data is considered a query that consumes excessive resources. A 20-nál több 000KB feldolgozás alatt álló lekérdezések visszaélésszerű lekérdezésnek minősülnek, és lehetséges, hogy szabályozva vannak.Query that is processing more than 20,000KB of data is considered an abusive query and might be throttled.

Azure Monitor naplókban a TimeGenerated oszlop használható az adatindexeléshez.In Azure Monitor Logs, the TimeGenerated column is used as a way to index the data. Ha a TimeGenerated értékeket úgy korlátozzák, hogy a lehető legkeskenyebbek legyenek, jelentős javulást eredményez a lekérdezési teljesítmény, mivel jelentősen korlátozza a feldolgozandó adatok mennyiségét.Restricting the TimeGenerated values to as narrow a range as possible will make a significant improvement to query performance by significantly limiting the amount of data that has to be processed.

A keresési és a Union operátorok szükségtelen használatának elkerüléseAvoid unnecessary use of search and union operators

Egy másik tényező, amely növeli a feldolgozott adatmennyiséget, nagy számú tábla használata.Another factor that increases the data that is process is the use of large number of tables. Ez általában akkor fordul elő, ha a search * és a union * parancsokat használja.This usually happens when search * and union * commands are used. Ezek a parancsok kényszerítik a rendszertől a munkaterület összes táblájából származó adatok kiértékelését és vizsgálatát.These commands force the system to evaluate and scan data from all tables in the workspace. Bizonyos esetekben előfordulhat, hogy több száz tábla található a munkaterületen.In some cases, there might be hundreds of tables in the workspace. Próbálja meg a lehető legnagyobb mértékben elkerülni a "keresés *" vagy bármilyen keresés használatát anélkül, hogy egy adott táblára kellene azt használni.Try to avoid as much as possible using "search *" or any search without scoping it to a specific table.

Például a következő lekérdezések pontosan ugyanazt az eredményt eredményezik, de az utolsó a leghatékonyabb:For example, the following queries produce exactly the same result but the last one is by far the most efficient:

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

Korai szűrők hozzáadása a lekérdezéshezAdd early filters to the query

Az adatmennyiség csökkentésének egy másik módja, Ha a lekérdezésben korai feltételek vannak.Another method to reduce the data volume is to have where conditions early in the query. Az Azure Adatkezelő platform egy olyan gyorsítótárat tartalmaz, amely lehetővé teszi, hogy mely partíciók tartalmazzák az adott feltételhez kapcsolódó adatokat.The Azure Data Explorer platform includes a cache that lets it know which partitions include data that is relevant for a specific where condition. Ha például egy lekérdezés tartalmazza, where EventID == 4624 akkor a lekérdezés csak olyan csomópontokra terjeszthető, amelyek a megfelelő eseményekkel rendelkező partíciókat kezelik.For example, if a query contains where EventID == 4624 then it would distribute the query only to nodes that handle partitions with matching events.

A következő példában a lekérdezések pontosan ugyanazt az eredményt eredményezik, a második pedig hatékonyabb:The following example queries produce exactly the same result but the second one is more efficient:

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

A feltételes összesítési függvények és a megvalósult függvények használatával ne vizsgáljon meg azonos forrásadatokatAvoid multiple scans of same source data using conditional aggregation functions and materialize function

Ha egy lekérdezés több allekérdezéssel is egyesítve van a JOIN vagy a Union operátorral, akkor minden allekérdezés külön ellenőrzi a teljes forrást, majd egyesíti az eredményeket.When a query has several sub-queries that are merged using join or union operators, each sub-query scans the entire source separately and then merge the results. Ez többszörösen ellenőrzi, hogy az adat hányszor van beolvasva – kritikus tényező a nagyon nagy adatkészletekben.This multiples the number of times data is scanned - critical factor in very large data sets.

Ennek elkerülésére szolgáló módszer a feltételes összesítési függvények használatával.A technique to avoid this is by using the conditional aggregation functions. Az összegző operátorban használt aggregációs függvények többsége egy feltételes verzió, amely lehetővé teszi egyetlen, több feltételt tartalmazó összefoglaló operátor használatát.Most of the aggregation functions that are used in summary operator has a conditioned version that allow you to use a single summarize operator with multiple conditions.

Az alábbi lekérdezések például a bejelentkezési események számát és az egyes fiókok folyamat-végrehajtási eseményeinek számát mutatják.For example, the following queries show the number of login events and the number of process execution events for each account. Ugyanezeket az eredményeket adják vissza, de az első az, hogy kétszer vizsgálja meg a második vizsgálatot:They return the same results but the first is scanning the data twice, the second scan it only once:

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

Egy másik eset, ahol az allekérdezések szükségtelenek az elemzési operátor előzetes szűrésével, így biztosítható, hogy csak az adott mintának megfelelő rekordokat dolgozza fel.Another case where sub-queries are unnecessary is pre-filtering for parse operator to make sure that it processes only records that match specific pattern. Ez szükségtelen, mert az elemzési operátor és más hasonló operátorok üres eredményeket adnak vissza, ha a minta nem egyezik.This is unnecessary as the parse operator and other similar operators return empty results when the pattern doesn't match. Az alábbiakban két olyan lekérdezés látható, amely pontosan ugyanazokat az eredményeket jeleníti meg, míg a második lekérdezési adatvizsgálat csak egyszer történik meg.Here are two queries that return exactly the same results while the second query scan data only once. A második lekérdezésben minden elemzési parancs csak az eseményeire vonatkozik.In the second query, each parse command is relevant only for its events. A kibővítő operátor ezt követően azt mutatja be, hogyan lehet az üres adathelyzetekre hivatkozni.The extend operator afterwards shows how to refer to empty data situation.

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

Ha a fentiek nem teszik lehetővé az allekérdezések használatának elkerülését, egy másik megoldás a lekérdezési motorra mutat, hogy az egyes példányok mindegyike a () függvénythasználja.When the above doesn't allow to avoid using sub-queries, another technique is to hint to the query engine that there is a single source data used in each one of them using the materialize() function. Ez akkor hasznos, ha a forrásadatok olyan függvényből érkeznek, amely többször is szerepel a lekérdezésben.This is useful when the source data is coming from a function that is used several times within the query. A beléptetés akkor lép életbe, ha az allekérdezés kimenete sokkal kisebb, mint a bemenet.Materialize is effective when the output of the sub-query is much smaller than the input. A lekérdezési motor gyorsítótárazza és újra felhasználja a kimenetet az összes előfordulásban.The query engine will cache and reuse the output in all occurrences.

Csökkentse a beolvasott oszlopok számátReduce the number of columns that is retrieved

Mivel az Azure Adatkezelő egy oszlopos adattár, minden oszlop lekérése független a többitől.Since Azure Data Explorer is a columnar data store, retrieval of every column is independent of the others. A beolvasott oszlopok száma közvetlenül befolyásolja a teljes adatmennyiséget.The number of columns that are retrieved directly influences the overall data volume. Az eredmények összesítésével vagy az adott oszlopok kivetítésével csak a szükséges kimeneti oszlopokat kell tartalmaznia.You should only include the columns in the output that are needed by summarizing the results or projecting the specific columns. Az Azure Adatkezelő számos optimalizálással rendelkezik, hogy csökkentse a beolvasott oszlopok számát.Azure Data Explorer has several optimizations to reduce the number of retrieved columns. Ha úgy dönt, hogy nincs szükség oszlopra, például ha az Összefoglaló parancs nem hivatkozik rá, nem fogja lekérni.If it determines that a column isn't needed, for example if it's not referenced in the summarize command, it won't retrieve it.

Előfordulhat például, hogy a második lekérdezés háromszor feldolgozza az adatfeldolgozást, mivel nem egy oszlopot kell beolvasnia, hanem hármat:For example, the second query may process three times more data since it needs to fetch not one column but three:

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

A feldolgozott lekérdezés időbeli időtartamaTime span of the processed query

Azure Monitor naplókban lévő összes napló particionálva van a TimeGenerated oszlop szerint.All logs in Azure Monitor Logs are partitioned according to the TimeGenerated column. Az elérni kívánt partíciók száma közvetlenül kapcsolódik az időtartományhoz.The number of partitions that are accessed are directly related to the time span. Az időtartomány csökkentése a leghatékonyabb megoldás a gyors lekérdezés-végrehajtás biztosításához.Reducing the time range is the most efficient way of assuring a prompt query execution.

A 15 napnál hosszabb időtartamú lekérdezések olyan lekérdezések, amelyek túlzott erőforrást használnak.Query with time span of more than 15 days is considered a query that consumes excessive resources. A 90 napnál hosszabb időtartamú lekérdezések visszaélésszerű lekérdezésnek minősülnek, és lehetséges, hogy szabályozva vannak.Query with time span of more than 90 days is considered an abusive query and might be throttled.

Az időtartomány beállítható az időtartomány-választóval a Log Analytics képernyőn a lekérdezési hatókör és az időtartomány Azure Monitor log Analyticsbanleírt módon.The time range can be set using the time range selector in the Log Analytics screen as described in Log query scope and time range in Azure Monitor Log Analytics. Ez az ajánlott módszer, mivel a kiválasztott időtartomány átadása a háttérnek a lekérdezés metaadatainak használatával történik.This is the recommended method as the selected time range is passed to the backend using the query metadata.

Egy másik módszer, ha explicit módon belefoglalja a lekérdezés TimeGenerated a Where feltételt.An alternative method is to explicitly include a where condition on TimeGenerated in the query. Ezt a módszert kell használnia, mivel biztosítja, hogy az időtartam rögzített, még akkor is, ha a lekérdezés más felületről van használatban.You should use this method as it assures that the time span is fixed, even when the query is used from a different interface. Győződjön meg arról, hogy a lekérdezés minden részén van TimeGenerated szűrő.You should ensure that all parts of the query have TimeGenerated filters. Ha egy lekérdezés allekérdezéseket tartalmaz a különböző táblákból vagy ugyanabból a táblából származó adatok beolvasására, akkor mindegyiknek saját, Where feltételt kell tartalmaznia.When a query has sub-queries fetching data from various tables or the same table, each has to include its own where condition.

Győződjön meg arról, hogy az összes allekérdezés rendelkezik TimeGenerated-szűrővelMake sure all sub-queries have TimeGenerated filter

Például a következő lekérdezésben, míg a perf tábla csak az elmúlt napra lesz megvizsgálva, a szívverési tábla az összes előzményét megvizsgálja, ami akár két évig is tarthat:For example, in the following query, while the Perf table will be scanned only for the last day, the Heartbeat table will be scanned for all of its history, which might be up to two years:

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

Gyakori eset, ha az ilyen hiba akkor fordul elő, amikor a arg_max () a legutóbbi előfordulás megkeresésére szolgál.A common case where such a mistake occurs is when arg_max() is used to find the most recent occurrence. Például:For example:

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

Ez a belső lekérdezésben egy Időszűrő hozzáadásával egyszerűen kijavítható:This can be easily corrected by adding a time filter in the inner query:

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

Egy másik példa erre a hibára, ha az időtartomány-szűrést csak az Unió több táblázata után végezze el.Another example for this fault is when performing the time scope filtering just after a union over several tables. Az Unió végrehajtásakor minden allekérdezés hatókörnek kell lennie.When performing the union, each sub-query should be scoped. A let utasítás használatával biztosíthatja a hatókör egységességét.You can use let statement to assure scoping consistency.

Például a következő lekérdezés a szívverés és a perf tábla összes adatát megvizsgálja, nem csak az utolsó 1 nap:For example, the following query will scan all the data in the Heartbeat and Perf tables, not just the last 1 day:

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

Ezt a lekérdezést a következőképpen kell kijavítani:This query should be fixed as follows:

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

Időtartomány-mérési korlátozásokTime span measurement limitations

A mérés mindig nagyobb, mint a megadott tényleges idő.The measurement is always larger than the actual time specified. Ha például a lekérdezés szűrője 7 nap, a rendszer 7,5 vagy 8,1 napot vizsgálhat.For example, if the filter on the query is 7 days, the system might scan 7.5 or 8.1 days. Ennek az az oka, hogy a rendszer a változó méretű adattömbökbe particionálja az adathalmazokat.This is because the system is partitioning the data into chunks in variable size. Annak biztosítása érdekében, hogy a rendszer az összes releváns rekordot megvizsgálja, megvizsgálja a teljes partíciót, amely több óráig is eltarthat, és akár egy napnál is hosszabb időt is igénybe vehet.To assure that all relevant records are scanned, it scans the entire partition that might cover several hours and even more than a day.

Több eset is létezik, ha a rendszer nem tud pontos mérési értéket biztosítani az időtartományhoz.There are several cases where the system cannot provide an accurate measurement of the time range. Ez a legtöbb esetben fordul elő, amikor a lekérdezés egy napnál rövidebb ideig vagy több-munkaterület lekérdezésekben van.This happens in most of the cases where the query's span less than a day or in multi-workspace queries.

Fontos

Ez a kijelző csak a közvetlen fürtben feldolgozott adatfeldolgozást jeleníti meg.This indicator presents only data processed in the immediate cluster. A többrégiós lekérdezésekben csak az egyik régiót jelöli.In multi-region query, it would represent only one of the regions. Több munkaterület lekérdezése esetén előfordulhat, hogy nem tartalmazza az összes munkaterületet.In multi-workspace query, it might not include all workspaces.

Feldolgozott adatmennyiség koraAge of processed data

Az Azure Adatkezelő számos tárolási szintet használ: memóriabeli, helyi SSD-lemezeket és sokkal lassabb Azure-blobokat.Azure Data Explorer uses several storage tiers: in-memory, local SSD disks and much slower Azure Blobs. Minél újabb adatról van szó, annál nagyobb a valószínűsége, hogy egy nagyobb teljesítményű, kisebb késéssel rendelkező, a lekérdezés időtartamát és a PROCESSZORt is csökkenti.The newer the data, the higher is the chance that it is stored in a more performant tier with smaller latency, reducing the query duration and CPU. Az adatoktól eltérő esetben a rendszer gyorsítótárat is tartalmaz a metaadatokhoz.Other than the data itself, the system also has a cache for metadata. Minél régebbiek az adatok, annál kisebb a metaadatok a gyorsítótárban.The older the data, the less chance its metadata will be in cache.

A 14 napnál hosszabb ideig feldolgozó lekérdezések olyan lekérdezésnek minősülnek, amely túlzott erőforrást használ.Query that processes data than is more than 14 days old is considered a query that consumes excessive resources.

Míg egyes lekérdezések a régi adatok használatát igénylik, vannak olyan esetek, amikor a régi adatokat tévesen használják.While some queries require usage of old data, there are cases where old data is used by mistake. Ez akkor fordul elő, ha a lekérdezések végrehajtása nem biztosít időtartományt a meta-adatokban, és nem minden táblázat hivatkozása tartalmazza a TimeGenerated oszlop szűrőjét.This happens when queries are executed without providing time range in their meta-data and not all table references include filter on the TimeGenerated column. Ezekben az esetekben a rendszer megvizsgálja az adott táblázatban tárolt összes adattípust.In these cases, the system will scan all the data that is stored in that table. Ha az adatok megőrzése hosszú, akkor a hosszú időtartományokra, így az adatmegőrzési időszakot megelőzően lévő adatokra is vonatkozhat.When the data retention is long, it can cover long time ranges and thus data that is as old as the data retention period.

Ilyen eset például a következő lehet:Such cases can be for example:

  • A Log Analytics időtartományának beállítása nem korlátozott allekérdezéssel.Not setting the time range in Log Analytics with a sub-query that isn't limited. Lásd a fenti példát.See example above.
  • Az API használata az időtartomány választható paramétereinek megadása nélkül.Using the API without the time range optional parameters.
  • Olyan ügyfél használata, amely nem kényszeríti az időtartományt, például az Power BI-összekötőt.Using a client that doesn't force a time range such as the Power BI connector.

Tekintse meg a példákat és a megjegyzéseket a áteresztő szakaszban, mivel ezek a jelen esetben is relevánsak.See examples and notes in the pervious section as they are also relevant in this case.

Régiók számaNumber of regions

Több olyan helyzet is előfordulhat, amikor egyetlen lekérdezést hajthat végre különböző régiókban:There are several situations where a single query might be executed across different regions:

  • Ha több munkaterület van explicit módon listázva, és különböző régiókban találhatók.When several workspaces are explicitly listed, and they are located in different regions.
  • Ha egy erőforrás-hatókörű lekérdezés beolvassa az adatgyűjtést, és az adatai több munkaterületen vannak tárolva, amelyek különböző régiókban találhatók.When a resource-scoped query is fetching data and the data is stored in multiple workspaces that are located in different regions.

A régiók közötti lekérdezés végrehajtása megköveteli, hogy a rendszer szerializálást és átvitelt hajtson végre a közbenső adatok háttérbeli nagy adattömbökben, amelyek általában jóval nagyobbak a lekérdezés végső eredményeinél.Cross-region query execution requires the system to serialize and transfer in the backend large chunks of intermediate data that are usually much larger than the query final results. Emellett korlátozza a rendszerek optimalizálási, heurisztikus és használati lehetőségeit is.It also limits the system's ability to perform optimizations, heuristics, and utilize caches. Ha nincs valós ok az összes ilyen régió vizsgálatára, állítsa be úgy a hatókört, hogy kevesebb régióra kiterjedjen.If there is no real reason to scan all these regions, you should adjust the scope so it covers fewer regions. Ha az erőforrás hatóköre kisebb, de még sok régiót használ, előfordulhat, hogy helytelen a konfiguráció.If the resource scope is minimized but still many regions are used, it might happen due to misconfiguration. A naplókat és a diagnosztikai beállításokat például különböző régiókban lévő különböző munkaterületekre küldik, vagy több diagnosztikai beállítási konfiguráció is van.For example, audit logs and diagnostic settings are sent to different workspaces in different regions or there are multiple diagnostic settings configurations.

A több mint 3 régiót átölelő lekérdezés olyan lekérdezésnek minősül, amely túlzott erőforrást használ.Query that spans more than 3 regions is considered a query that consumes excessive resources. A több mint 6 régióra kiterjedő lekérdezések visszaélésszerű lekérdezésnek minősülnek, és lehetséges, hogy szabályozva vannak.Query that spans more than 6 regions is considered an abusive query and might be throttled.

Fontos

Ha egy lekérdezés több régióban fut, a processzor és az adatmérések nem lesznek pontosak, és csak az egyik régióban jelennek meg a mérések.When a query is run across several regions, the CPU and data measurements will not be accurate and will represent the measurement only on one of the regions.

Munkaterületek számaNumber of workspaces

A munkaterületek logikai tárolók, amelyek a naplók adatai elkülönítésére és felügyeletére szolgálnak.Workspaces are logical containers that are used to segregate and administer logs data. A háttérrendszer a kiválasztott régióban található fizikai fürtökön a munkaterület elhelyezéseit optimalizálja.The backend optimizes workspace placements on physical clusters within the selected region.

Több munkaterület használata a következő eredményekből járhat:Usage of multiple workspaces can result from:

  • Ahol több munkaterület van kifejezetten felsorolva.Where several workspaces are explicitly listed.
  • Ha egy erőforrás-hatókörű lekérdezés beolvassa az adatgyűjtést, és az adattárolás több munkaterületen történik.When a resource-scoped query is fetching data and the data is stored in multiple workspaces.

A lekérdezések régiók közötti és több fürtre kiterjedő végrehajtása megköveteli, hogy a rendszer szerializálja és átvigye a háttérbeli adatok nagy részét, amely általában jóval nagyobb a lekérdezés végső eredményeinél.Cross-region and cross-cluster execution of queries requires the system to serialize and transfer in the backend large chunks of intermediate data that are usually much larger than the query final results. Emellett korlátozza az optimalizálások, a heurisztikus műveletek és a gyorsítótárak kihasználásának rendszerképességét is.It also limits the system ability to perform optimizations, heuristics and utilizing caches.

A több mint 5 munkaterületre kiterjedő lekérdezés olyan lekérdezésnek minősül, amely túlzott erőforrást használ.Query that spans more than 5 workspace is considered a query that consumes excessive resources. A lekérdezések legfeljebb 100 munkaterületre terjedhetnek ki.Queries cannot span to to more than 100 workspaces.

Fontos

Egyes többmunkaterületos helyzetekben a processzor-és adatmérések nem pontosak, és a mérések csak néhány munkaterületnek felelnek meg.In some multi-workspace scenarios, the CPU and data measurements will not be accurate and will represent the measurement only to few of the workspaces.

PárhuzamosságParallelism

Azure Monitor naplók az Azure Adatkezelő nagyméretű fürtjét használják a lekérdezések futtatásához, és ezek a fürtök mérettől függően változhatnak, akár több tucat számítási csomópontra is.Azure Monitor Logs is using large clusters of Azure Data Explorer to run queries, and these clusters vary in scale, potentially getting up to dozens of compute nodes. A rendszer a munkaterület elhelyezési logikája és kapacitása alapján automatikusan méretezi a fürtöket.The system automatically scales the clusters according to workspace placement logic and capacity.

A lekérdezés hatékony végrehajtásához particionálni és terjeszteni kell a számítási csomópontokat a feldolgozáshoz szükséges adatok alapján.To efficiently execute a query, it is partitioned and distributed to compute nodes based on the data that is required for its processing. Vannak olyan helyzetek, amikor a rendszer nem tudja ezt hatékonyan végrehajtani.There are some situations where the system cannot do this efficiently. Ez hosszú időtartamot eredményezhet a lekérdezésben.This can lead to a long duration of the query.

A párhuzamosságot csökkentő lekérdezési viselkedések például a következők:Query behaviors that can reduce parallelism include:

  • Szerializálási és ablakos függvények, például a szerializálási operátor, a Next (), a Prev ()és a Row függvények használata.Use of serialization and window functions such as the serialize operator, next(), prev(), and the row functions. Ezekben az esetekben a Time Series és a User Analytics functions is használható.Time series and user analytics functions can be used in some of these cases. A nem hatékony szerializálás akkor is előfordulhat, ha a következő operátorok nem a lekérdezés végén vannak használatban: Range, sort, Order, Top, Top-ütős, GetSchema.Inefficient serialization may also happen if the following operators are used not at the end of the query: range, sort, order, top, top-hitters, getschema.
  • A DCount () aggregációs függvény használata azt kényszeríti, hogy a rendszeren a különböző értékek központi másolata legyen.Usage of dcount() aggregation function force the system to have central copy of the distinct values. Ha az adatok terjedelme magas, érdemes lehet a DCount függvényt a választható paraméterekkel csökkenteni a pontosság csökkentése érdekében.When the scale of data is high, consider using the dcount function optional parameters to reduced accuracy.
  • Sok esetben a JOIN operátor csökkenti az általános párhuzamosságot.In many cases, the join operator lowers overall parallelism. A teljesítménnyel kapcsolatos probléma megoldásakor vizsgálja meg a shuffle illesztést.Examine shuffle join as an alternative when performance is problematic.
  • Az erőforrás-hatókörű lekérdezésekben a végrehajtás előtti Kubernetes RBAC vagy az Azure RBAC-ellenőrzések olyan helyzetekben merülhetnek fel, amikor nagyon nagy számú Azure-szerepkör-hozzárendelés van.In resource-scope queries, the pre-execution Kubernetes RBAC or Azure RBAC checks may linger in situations where there is very large number of Azure role assignments. Ez több ellenőrzéshez vezethet, ami alacsonyabb párhuzamosságot eredményezhet.This may lead to longer checks that would result in lower parallelism. Egy lekérdezés például egy olyan előfizetésen történik, ahol több ezer erőforrás van, és az egyes erőforrások számos szerepkör-hozzárendeléssel rendelkeznek az erőforrás szintjén, nem az előfizetéshez vagy az erőforráscsoporthoz.For example, a query is executed on a subscription where there are thousands of resources and each resource has many role assignments in the resource level, not on the subscription or resource group.
  • Ha egy lekérdezés kis adattömböket dolgoz fel, a párhuzamossága alacsony lesz, mivel a rendszer nem fogja elosztani számos számítási csomópont között.If a query is processing small chunks of data, its parallelism will be low as the system will not spread it across many compute nodes.

Következő lépésekNext steps