Optimize log queries in Azure Monitor
Az Azure Monitor-naplók az Azure Data Explorer használatával tárolják a naplóadatokat, és lekérdezéseket futtatnak az adatok elemzéséhez. Létrehozza, kezeli és karbantartja az Azure Data Explorer-fürtöket, és optimalizálja őket a naplóelemzési számítási feladatokhoz. Lekérdezés futtatásakor a rendszer optimalizálja és átirányítja a munkaterület adatait tároló megfelelő Azure Data Explorer-fürtre.
Az Azure Monitor naplói és az Azure Data Explorer számos automatikus lekérdezésoptimalizálási mechanizmust használnak. Az automatikus optimalizálás jelentős lökést ad, de vannak olyan esetek, amikor jelentősen javíthatja a lekérdezés teljesítményét. Ez a cikk a teljesítmény szempontjait és a javításukhoz használt számos technikát ismerteti.
A legtöbb módszer gyakori a közvetlenül az Azure Data Explorerben és az Azure Monitor-naplókban futtatott lekérdezésekre. Számos egyedi Azure Monitor-naplóval is foglalkozunk. További Azure Data Explorer-optimalizálási tippekért tekintse meg a lekérdezés ajánlott eljárásait.
Az optimalizált lekérdezések a következők:
- Gyorsabban futhat, és csökkentheti a lekérdezés végrehajtásának teljes időtartamát.
- Kisebb eséllyel szabályozhatók vagy elutasíthatók.
Különös figyelmet kell fordítani az ismétlődő és egyidejű használathoz használt lekérdezésekre, például irányítópultokra, riasztásokra, Azure Logic Appsre és Power BI-ra. A hatástalan lekérdezések hatása ezekben az esetekben jelentős.
Az alábbi részletes videó bemutatja a lekérdezések optimalizálását.
Lekérdezés részletei panel
Miután lefuttat egy lekérdezést a Log Analyticsben, a képernyő jobb alsó sarkában válassza a Lekérdezés részletei lehetőséget a Lekérdezés részletei panel megnyitásához. Ez a panel a lekérdezés több teljesítménymutatójának eredményeit jeleníti meg. Ezeket a teljesítménymutatókat a következő szakaszban ismertetjük.
Lekérdezési teljesítménymutatók
A következő lekérdezési teljesítménymutatók érhetők el minden végrehajtott lekérdezéshez:
- Teljes CPU: A lekérdezés összes számítási csomóponton történő feldolgozásához használt teljes számítás. Ez a számításhoz, elemzéshez és adatlehíváshoz használt időt jelöli.
- Feldolgozott lekérdezéshez használt adatok: A lekérdezés feldolgozásához hozzáfért adatok. A céltábla mérete, a használt időtartomány, az alkalmazott szűrők és a hivatkozott oszlopok száma befolyásolja.
- A feldolgozott lekérdezés időtartama: A lekérdezés feldolgozásához elért legújabb és legrégebbi adatok közötti különbség. A lekérdezéshez megadott explicit időtartomány befolyásolja.
- A feldolgozott adatok kora: A lekérdezés feldolgozásához hozzáfért legrégebbi adatok közötti különbség. Nagy mértékben befolyásolja az adatbeolvasás hatékonyságát.
- Munkaterületek száma: Hány munkaterület érhető el a lekérdezés feldolgozása során implicit vagy explicit kijelölés alapján.
- Régiók száma: Hány régió fért hozzá a lekérdezésfeldolgozás során a munkaterületek implicit vagy explicit kiválasztása alapján. A többrégiós lekérdezések sokkal kevésbé hatékonyak, és a teljesítménymutatók részleges lefedettséget mutatnak.
- Párhuzamosság: Azt jelzi, hogy a rendszer mennyivel tudta végrehajtani ezt a lekérdezést több csomóponton. Csak a magas processzorhasználattal rendelkező lekérdezésekre vonatkozik. Adott függvények és operátorok használata befolyásolja.
Teljes PROCESSZOR
A lekérdezés feldolgozásához befektetett tényleges számítási PROCESSZOR az összes lekérdezésfeldolgozó csomóponton. Mivel a legtöbb lekérdezést nagy számú csomóponton hajtják végre, ez az összeg általában sokkal nagyobb lesz, mint a lekérdezés végrehajtásának időtartama.
A 100 másodpercnél hosszabb processzorhasználatot használó lekérdezések olyan lekérdezések, amelyek túlzott erőforrásokat használnak fel. Az 1000 másodpercnél hosszabb processzorhasználatot használó lekérdezések visszaélésszerű lekérdezésnek minősülnek, és szabályozhatók.
A lekérdezésfeldolgozási idő a következőre van fordítva:
- Adatlekérés: A régi adatok lekérése több időt vesz igénybe, mint a legutóbbi adatok lekérése.
- Adatfeldolgozás: Az adatok logikája és kiértékelése.
A lekérdezésfeldolgozó csomópontokban töltött idő mellett az Azure Monitor-naplók a következőkkel töltik az időt:
- A felhasználó hitelesítése és annak ellenőrzése, hogy jogosult-e hozzáférni ezekhez az adatokhoz.
- Az adattár keresése.
- A lekérdezés elemzése.
- A lekérdezésfeldolgozó csomópontok kiosztása.
Ez az idő nem szerepel a lekérdezés teljes processzoridejében.
Rekordok korai szűrése a magas CPU-függvények használata előtt
A lekérdezési parancsok és függvények némelyike nagy a processzorhasználatban. Ez az eset különösen igaz a JSON- és XML-elemzést vagy összetett reguláris kifejezéseket kinyerő parancsokra. Az ilyen elemzések kifejezetten parse_json() vagy parse_xml() függvényeken keresztül történhetnek, vagy implicit módon, amikor dinamikus oszlopokra hivatkoznak.
Ezek a függvények a feldolgozandó sorok számával arányos processzorhasználatot használnak fel. A leghatékonyabb optimalizálás az, ha a lekérdezés korai szakaszában feltételeket ad hozzá where . Ily módon a lehető legtöbb rekordot szűrhetik ki a processzorigényes függvény végrehajtása előtt.
A következő lekérdezések például pontosan ugyanazt az eredményt eredményezik. A második azonban a leghatékonyabb, mert az elemzés előtti feltétel számos rekordot kizár:
//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 záradékok használatát
Azok a lekérdezések, amelyek az adathalmazban fizikailag jelen lévő oszlopok helyett egy kiértékelt oszlopban lévő záradékokat tartalmaznak, elveszítik a hatékonyságukat. A kiértékelt oszlopok szűrése megakadályozza a rendszer optimalizálását nagy adathalmazok kezelésekor.
A következő lekérdezések például pontosan ugyanazt az eredményt eredményezik. A második azonban hatékonyabb, mert a feltétel egy beépített oszlopra hivatkozik:
//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 implicit módon hozza létre a lekérdezésfeldolgozó motor, mert a szűrés nem csak a mezőben történik:
//less efficient
SecurityEvent
| where tolower(Process) == "conhost.exe"
| count
//more efficient
SecurityEvent
| where Process =~ "conhost.exe"
| count
Hatékony összesítési parancsok és dimenziók használata összegzéshez és illesztéshez
Egyes összesítési parancsok, például a max(), a sum(), a count() és az avg() a logikájuk miatt alacsony processzorterhelést eredményeznek. Más parancsok összetettebbek, és olyan heurisztikai és becslési műveleteket tartalmaznak, amelyek lehetővé teszik a hatékony végrehajtásukat. A dcount() például a HyperLogLog algoritmussal közel becslést ad a nagy adathalmazok különböző számaihoz anélkül, hogy ténylegesen megszámolná az egyes értékeket.
A percentilisfüggvények hasonló közelítéseket végeznek a legközelebbi rang percentilis algoritmus használatával. Számos parancs választható paramétereket is tartalmaz a hatás csökkentése érdekében. A makeset() függvény például egy választható paramétert használ a maximális beállítási méret meghatározásához, ami jelentősen befolyásolja a processzort és a memóriát.
Az összekapcsolási és összegzési parancsok nagy mennyiségű adat feldolgozásakor magas processzorkihasználtságot okozhatnak. Összetettségük közvetlenül kapcsolódik az attribútumként vagy attribútumként summarizebyjoin használt oszlopok lehetséges értékeinek számához, más néven számossághoz. Ennek magyarázatát és optimalizálását joinsummarizea dokumentációs cikkekben és az optimalizálási tippekben találja.
Az alábbi lekérdezések például pontosan ugyanazt az eredményt eredményezik, mert CounterPath mindig egy-az-egyhez van leképezve CounterName és ObjectName. A második hatékonyabb, mert az aggregációs dimenzió kisebb:
//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 processzorhasználatot olyan feltételek vagy kiterjesztett oszlopok is befolyásolhatják where , amelyek intenzív számítást igényelnek. Az összes triviális sztring-összehasonlítás, például az equal == és a startswith, nagyjából azonos cpu-hatással rendelkezik. A speciális szöveges egyezések nagyobb hatással vannak. Pontosabban a has operátor hatékonyabb, mint a tartalmaz operátor. A sztringkezelési technikák miatt hatékonyabb a négy karakternél hosszabb karakterláncok keresése, mint a rövid sztringek.
Az alábbi lekérdezések például az elnevezési szabályzattól függően Computer hasonló eredményeket eredményeznek. De a második hatékonyabb:
//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 az azonnali fürtből származó CPU-t jeleníti meg. Egy többrégiós lekérdezésben csak az egyik régiót jelölné. Több munkaterületes lekérdezésben előfordulhat, hogy nem minden munkaterületet tartalmaz.
A sztring elemzésekor kerülje a teljes XML- és JSON-elemzést
Egy XML- vagy JSON-objektum teljes elemzése nagy processzor- és memóriaerőforrásokat is igénybe vehet. Sok esetben, ha csak egy vagy két paraméterre van szükség, és az XML- vagy JSON-objektumok egyszerűek, könnyebben elemezhetők sztringekként. Használja az elemzési operátort vagy más szövegelemző technikákat. A teljesítménynövekedés nagyobb lesz, mert az XML- vagy JSON-objektum rekordjainak száma nő. Elengedhetetlen, ha a rekordok száma eléri a több tízmilliót.
Az alábbi lekérdezés például pontosan ugyanazokat az eredményeket adja vissza, mint az előző lekérdezések teljes XML-elemzés nélkül. A lekérdezés feltételezi az XML-fájl struktúráját, például az FilePath elem után FileHash következik, és egyik sem rendelkezik attribútumokkal:
//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 adatok
A lekérdezés feldolgozásának egyik kritikus tényezője a lekérdezés feldolgozásához beolvasott és használt adatok mennyisége. Az Azure Data Explorer agresszív optimalizálásokat használ, amelyek jelentősen csökkentik az adatmennyiséget más adatplatformokhoz képest. A lekérdezésben azonban vannak olyan kritikus tényezők, amelyek befolyásolhatják a használt adatmennyiséget.
A 2000 KB-nál több adatot feldolgozó lekérdezések túl sok erőforrást használó lekérdezésnek minősülnek. A több mint 20 000 KB adatot feldolgozó lekérdezések visszaélésszerű lekérdezésnek minősülnek, és szabályozhatók.
Az Azure Monitor-naplókban az TimeGenerated oszlop az adatok indexelésére szolgál. Ha az értékeket a TimeGenerated lehető legszűkebb tartományra korlátozza, az javítja a lekérdezési teljesítményt. A szűk tartomány jelentősen korlátozza a feldolgozandó adatok mennyiségét.
A keresési és egyesítő operátorok szükségtelen használatának elkerülése
Egy másik tényező, amely növeli a feldolgozott adatokat, nagy számú tábla használata. Ez a forgatókönyv általában a search *union * parancsok használatakor fordul elő. Ezek a parancsok arra kényszerítik a rendszert, hogy kiértékelje és beolvassa az adatokat a munkaterület összes táblájából. Bizonyos esetekben több száz tábla lehet a munkaterületen. Próbálja meg elkerülni a használatot search * vagy a keresést anélkül, hogy egy adott táblára hatókört alkalmaz.
A következő lekérdezések például pontosan ugyanazt az eredményt eredményezik, de az utolsó a leghatékonyabb:
// 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éshez
Az adatmennyiség csökkentésének másik módszere, hogy a lekérdezés korai szakaszában hol vannak a feltételek. Az Azure Data Explorer platform tartalmaz egy gyorsítótárat, amely tudatja vele, hogy mely partíciók tartalmaznak egy adott where feltételhez kapcsolódó adatokat. Ha például egy lekérdezés tartalmaz where EventID == 4624, akkor a lekérdezést csak olyan csomópontokra osztja el, amelyek egyező eseményekkel rendelkező partíciókat kezelnek.
Az alábbi példában szereplő lekérdezések pontosan ugyanazt az eredményt eredményezik, de a második hatékonyabb:
//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
Kerülje el ugyanazon forrásadatok több vizsgálatát feltételes összesítési függvények és a materializálási függvény használatával
Ha egy lekérdezés több allekérdezést is használ, amelyeket összekapcsoló vagy egyesítő operátorok használatával egyesít, az egyes részlekérdezések külön-külön ellenőrzik a teljes forrást. Ezután egyesíti az eredményeket. Ez a művelet megszorozza az adatok beolvasásának hányszorosát, ami kritikus tényező a nagy adathalmazokban.
Ezt a forgatókönyvet a feltételes összesítési függvények használatával lehet elkerülni. Az összesítő operátorban használt összesítő függvények többsége rendelkezik egy feltételes verzióval, amelyet egyetlen, több feltételt tartalmazó összesítő operátorhoz használhat.
Az alábbi lekérdezések például a bejelentkezési események számát és az egyes fiókok folyamatvégrehajtási eseményeinek számát mutatják. Ugyanazokat az eredményeket adnak vissza, de az első lekérdezés kétszer ellenőrzi az adatokat. A második lekérdezés csak egyszer ellenőrzi:
//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, amikor az al lekérdezések szükségtelenek, az elemzési operátor előszűrése annak biztosítása érdekében, hogy csak egy adott mintának megfelelő rekordokat dolgozza fel. Ezek szükségtelenek, mert az elemzési operátor és más hasonló operátorok üres eredményeket adnak vissza, ha a minta nem egyezik. A következő két lekérdezés pontosan ugyanazokat az eredményeket adja vissza, de a második lekérdezés csak egyszer ellenőrzi az adatokat. A második lekérdezésben az egyes elemzési parancsok csak az események szempontjából relevánsak. Az extend operátor ezután bemutatja, hogyan hivatkozhat üres adathelyzetre:
//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 az előző lekérdezés nem teszi lehetővé az al lekérdezések használatának elkerülését, egy másik módszer, ha arra utal a lekérdezési motornak, hogy mindegyikben egyetlen adatforrást használnak a materialize() függvény használatával. Ez a technika akkor hasznos, ha a forrásadatok olyan függvényből származnak, amelyet a lekérdezésben többször is használnak. Materialize akkor hatékony, ha az al lekérdezés kimenete sokkal kisebb, mint a bemenet. A lekérdezési motor minden előfordulásban gyorsítótárazza és újra felhasználja a kimenetet.
A lekért oszlopok számának csökkentése
Mivel az Azure Data Explorer egy oszlopos adattár, minden oszlop lekérése független a többiétől. A lekért oszlopok száma közvetlenül befolyásolja a teljes adatmennyiséget. Csak azokat az oszlopokat vegye fel a kimenetbe, amelyekre szükség van az eredmények összegzésével vagy az adott oszlopok kivetítésével.
Az Azure Data Explorer számos optimalizálást tartalmaz a lekért oszlopok számának csökkentése érdekében. Ha azt állapítja meg, hogy nincs szükség egy oszlopra, például ha nem hivatkozik rá az összegző parancs, akkor nem fogja lekérni.
Előfordulhat például, hogy a második lekérdezés háromszor több adatot dolgoz fel, mert nem egy, hanem három oszlopot kell beolvasnia:
//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őtartama
Az Azure Monitor-naplókban lévő összes napló particionálása az TimeGenerated oszlopnak megfelelően van. A elért partíciók száma közvetlenül kapcsolódik az időtartamhoz. Az időtartomány csökkentése a lekérdezések gyors végrehajtásának leghatékonyabb módja.
A 15 napnál hosszabb időtartamú lekérdezések olyan lekérdezések, amelyek túlzott erőforrásokat használnak fel. A 90 napnál hosszabb időtartamú lekérdezések visszaélésszerű lekérdezésnek minősülnek, és szabályozhatók.
Az időtartományt a Log Analytics képernyő időtartomány-választójának használatával állíthatja be az Azure Monitor Log Analytics napló lekérdezési hatókörében és időtartományában leírtak szerint. Ez a módszer azért ajánlott, mert a rendszer a lekérdezés metaadataival továbbítja a kiválasztott időtartományt a háttérnek.
Egy másik módszer, ha explicit módon belefoglal egy feltételtTimeGenerated a lekérdezésbe. Ezt a módszert azért használja, mert biztosítja, hogy az időtartomány rögzített legyen, még akkor is, ha a lekérdezést egy másik felületről használják.
Győződjön meg arról, hogy a lekérdezés minden része rendelkezik TimeGenerated szűrőkkel. Ha a lekérdezések részlekérdezéseket tartalmaznak, és különböző táblákból vagy ugyanabból a táblából kérdeznek le adatokat, minden lekérdezésnek tartalmaznia kell a saját helyét .
Győződjön meg arról, hogy az összes albekérdezés rendelkezik a TimeGenerated szűrővel
A következő lekérdezésben például a Perf tábla csak az utolsó napra lesz beolvasva. A Heartbeat rendszer az összes előzményét ellenőrzi, ami akár két év is lehet:
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, amikor ilyen hiba történik, ha a arg_max() a legutóbbi előfordulás megkeresésére szolgál. Például:
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
Ezt a helyzetet egyszerűen kijavíthatja, ha egy időszűrőt ad hozzá a belső lekérdezéshez:
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
Erre a hibára egy másik példa az, amikor az időtartomány szűrését több tábla egyesítése után hajtja végre. Az egyesítés végrehajtásakor minden alküldetés hatókörrel kell rendelkeznie. A hatókörkezelési konzisztenciát let utasítással biztosíthatja.
A következő lekérdezés például nem csak az utolsó napon, hanem a HeartbeatPerf táblákban lévő összes adatot megvizsgálja:
Heartbeat
| summarize arg_min(TimeGenerated,*) by Computer
| union (
Perf
| summarize arg_min(TimeGenerated,*) by Computer)
| where TimeGenerated > ago(1d)
| summarize min(TimeGenerated) by Computer
A lekérdezés javítása:
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
Az időtartomány mérésének korlátozásai
A mérés mindig nagyobb, mint a megadott tényleges idő. Ha például a lekérdezés szűrője 7 nap, a rendszer 7,5 vagy 8,1 napot vizsgálhat. Ennek az eltérésnek az az oka, hogy a rendszer változó méretű adattömbökre particionálta az adatokat. Annak biztosítása érdekében, hogy az összes releváns rekord be legyen vizsgálva, a rendszer megvizsgálja a teljes partíciót. Ez a folyamat több órát és akár egy napot is lefedhet.
Több olyan eset is előfordul, amikor a rendszer nem tudja pontosan mérni az időtartományt. Ez a helyzet a legtöbb esetben akkor fordul elő, ha a lekérdezés időtartama egy napnál rövidebb, vagy több-munkaterületes lekérdezésekben.
Fontos
Ez a mutató csak az azonnali fürtben feldolgozott adatokat jeleníti meg. Egy többrégiós lekérdezésben csak az egyik régiót jelölné. Több munkaterületes lekérdezésben előfordulhat, hogy nem minden munkaterületet tartalmaz.
A feldolgozott adatok kora
Az Azure Data Explorer több tárolási szintet használ: a memóriában, a helyi SSD-lemezeket és a sokkal lassabb Azure Blobokat. Minél újabbak az adatok, annál nagyobb az esély arra, hogy a rendszer nagyobb teljesítményű rétegben tárolja őket, kisebb késéssel, ami csökkenti a lekérdezések időtartamát és a processzorhasználatot. Az adatokon kívül a rendszer a metaadatok gyorsítótárával is rendelkezik. Minél régebbiek az adatok, annál kisebb az esélye annak, hogy a metaadatai a gyorsítótárban lesznek.
A 14 napnál régebbi adatokat feldolgozó lekérdezések túl sok erőforrást használó lekérdezésnek minősülnek.
Egyes lekérdezések megkövetelik a régi adatok használatát, de vannak olyan esetek is, amikor a régi adatokat tévedésből használják. Ez a forgatókönyv akkor fordul elő, ha a lekérdezések anélkül futnak, hogy időtartományt adnak meg a metaadataikban, és nem minden táblahivatkozás tartalmaz szűrőt az TimeGenerated oszlopon. Ezekben az esetekben a rendszer megvizsgálja a táblában tárolt összes adatot. Ha az adatmegőrzés hosszú, hosszú időtartományokra is kiterjedhet. Ennek eredményeképpen az adatmegőrzési időszakkal egyidős adatok lesznek beolvasva.
Ilyen esetek lehetnek például:
- Nem állítja be az időtartományt a Log Analyticsben olyan al lekérdezéssel, amely nem korlátozott. Lásd az előző példát.
- Az API használata az időtartomány nem kötelező paraméterei nélkül.
- Olyan ügyfél használata, amely nem kényszeríti az időtartományt, például a Power BI-összekötőt.
Tekintse meg az előző szakaszban szereplő példákat és jegyzeteket, mert ebben az esetben is relevánsak.
Régiók száma
Vannak olyan helyzetek, amikor egyetlen lekérdezést hajtanak végre különböző régiókban. Például:
- Ha több munkaterület kifejezetten szerepel a listán, és különböző régiókban találhatók.
- Ha egy erőforrás-hatókörű lekérdezés adatokat kérdez le, és az adatokat több, különböző régióban található munkaterület tárolja.
A régiók közötti lekérdezések végrehajtásához a rendszernek szerializálnia és továbbítania kell a háttérbeli nagy mennyiségű köztes adatot, amelyek általában sokkal nagyobbak, mint a lekérdezés végleges eredményei. Emellett korlátozza a rendszer optimalizálásokat és heurisztikus műveleteket, valamint gyorsítótárak használatát.
Ha nincs ok az összes régió vizsgálatára, módosítsa a hatókört úgy, hogy kevesebb régióra terjedjen ki. Ha az erőforrás hatóköre minimálisra van csökkentve, de még mindig sok régió van használatban, előfordulhat, hogy helytelen konfiguráció miatt történik. Előfordulhat például, hogy a naplókat és a diagnosztikai beállításokat különböző régiókban található különböző munkaterületekre küldik, vagy több diagnosztikai beállítás konfigurációja is lehet.
A háromnál több régiót felölelő lekérdezések túl sok erőforrást használó lekérdezésnek minősülnek. A hatnál több régióra kiterjedő lekérdezések visszaélésszerű lekérdezésnek minősülnek, és szabályozhatók.
Fontos
Ha egy lekérdezés több régióban fut, a processzor- és adatmérések nem lesznek pontosak, és csak az egyik régió mérését jelölik.
Munkaterületek száma
A munkaterületek logikai tárolók, amelyek a naplóadatok elkülönítésére és felügyeletére szolgálnak. A háttérrendszer optimalizálja a munkaterületek elhelyezését a kijelölt régión belüli fizikai fürtökön.
Több munkaterület használata a következő esetekben következhet be:
- Több munkaterület is explicit módon szerepel a listán.
- Az erőforrás-hatókörű lekérdezések adatokat kérdeznek le, és az adatokat több munkaterület tárolja.
A lekérdezések régiók közötti és fürtök közötti végrehajtásához a rendszernek szerializálnia és továbbítania kell a háttérbeli nagy mennyiségű köztes adatot, amelyek általában sokkal nagyobbak, mint a lekérdezés végleges eredményei. Emellett korlátozza a rendszer optimalizálásokat és heurisztikus műveleteket, valamint gyorsítótárak használatát.
Az ötnél több munkaterületet felölelő lekérdezések olyan lekérdezések, amelyek túlzott erőforrásokat használnak fel. A lekérdezések legfeljebb 100 munkaterületre terjedhetnek ki.
Fontos
- Egyes több-munkaterületes forgatókönyvekben a processzor- és adatmérések nem lesznek pontosak, és csak néhány munkaterület mérését jelölik.
- A munkaterületek közötti lekérdezések explicit azonosítóval rendelkeznek: munkaterület-azonosító vagy munkaterületi Azure-erőforrás-azonosító, kevesebb erőforrást használnak fel, és teljesítményesebbek.
Párhuzamosság
Az Azure Monitor-naplók az Azure Data Explorer nagy fürtöit használják a lekérdezések futtatásához. Ezek a fürtök mérete változó, és akár több tucat számítási csomópontot is kaphatnak. A rendszer automatikusan skálázza a fürtöket a munkaterület elhelyezési logikája és kapacitása szerint.
A lekérdezés hatékony végrehajtásához particionált és elosztott lesz a számítási csomópontokon a feldolgozáshoz szükséges adatok alapján. Bizonyos esetekben a rendszer nem tudja hatékonyan elvégezni ezt a lépést, ami a lekérdezés hosszú időtartamához vezethet.
A párhuzamosságot csökkentő lekérdezési viselkedések a következők:
- Szerializálási és ablakfüggvények használata, például szerializálási operátor, next(), prev() és sorfüggvények. Ezekben az esetekben az idősorok és a felhasználóelemzési függvények használhatók. A nem hatékony szerializálás akkor is előfordulhat, ha a lekérdezés végén nem a következő operátorokat használják: tartomány, rendezés, sorrend, felső, felső és getschema.
- A dcount() aggregációs függvény használata arra kényszeríti a rendszert, hogy a különböző értékek központi másolatával rendelkezzen. Ha az adatok mérete magas, fontolja meg a függvény opcionális paramétereinek használatát a
dcountpontosság csökkentése érdekében. - Az illesztés operátora sok esetben csökkenti az általános párhuzamosságot. Vizsgálja meg
shuffle joinalternatívaként, ha a teljesítmény problémás. - Erőforrás-hatókörű lekérdezésekben a Kubernetes szerepköralapú hozzáférés-vezérlése (RBAC) vagy az Azure RBAC-ellenőrzések hosszabb ideig tarthatnak olyan helyzetekben, amikor nagy számú Azure-szerepkör-hozzárendelés van. Ez a helyzet hosszabb ellenőrzésekhez vezethet, amelyek alacsonyabb párhuzamosságot eredményeznek. Előfordulhat például, hogy egy lekérdezés olyan előfizetésen fut, amelyben több ezer erőforrás található, és mindegyik erőforrás számos szerepkör-hozzárendeléssel rendelkezik az erőforrás szintjén, nem az előfizetésben vagy az erőforráscsoportban.
- Ha egy lekérdezés kis adattömböket dolgoz fel, a párhuzamossága alacsony lesz, mert a rendszer nem fogja elosztani azokat számos számítási csomóponton.