Azure İzleyici’de günlük sorgularını iyileştirme

Azure İzleyici Günlükleri, günlük verilerini depolamak ve bu verileri analiz etmek için sorgu çalıştırmak için Azure Veri Gezgini kullanır. Azure Veri Gezgini kümelerini sizin için oluşturur, yönetir ve korur ve bunları günlük analizi iş yükünüz için iyileştirir. Bir sorgu çalıştırdığınızda, bu sorgu iyileştirilir ve çalışma alanı verilerini depolayan uygun Azure Veri Gezgini kümesine yönlendirilir.

Azure İzleyici Günlükleri ve Azure Veri Gezgini birçok otomatik sorgu iyileştirme mekanizması kullanır. Otomatik iyileştirmeler önemli bir artış sağlar, ancak bazı durumlarda sorgu performansınızı önemli ölçüde geliştirebilirsiniz. Bu makalede performansla ilgili önemli noktalar ve bunları düzeltmek için çeşitli teknikler açıklanmaktadır.

Tekniklerin çoğu doğrudan Azure Veri Gezgini ve Azure İzleyici Günlüklerinde çalıştırılacak sorgular için yaygındır. Çeşitli benzersiz Azure İzleyici Günlükleri konuları da ele alınmalıdır. Daha fazla Azure Veri Gezgini iyileştirme ipuçları için bkz. Sorgu en iyi yöntemleri.

İyileştirilmiş sorgular:

• Daha hızlı çalıştırın ve sorgu yürütmenin genel süresini azaltın.
• Azaltılma veya reddedilma ihtimali daha düşük olur.

Panolar, uyarılar, Azure Logic Apps ve Power BI gibi yinelenen ve eşzamanlı kullanım için kullanılan sorgulara özellikle dikkat edin. Bu gibi durumlarda etkisiz bir sorgunun etkisi önemlidir.

Sorguları iyileştirmeye yönelik ayrıntılı bir video kılavuzu aşağıdadır.

Sorgu Ayrıntıları bölmesi

Log Analytics'te bir sorgu çalıştırdıktan sonra ekranın sağ alt köşesindeki Sorgu ayrıntıları'nı seçerek Sorgu Ayrıntıları bölmesini açın. Bu bölmede sorgu için çeşitli performans göstergelerinin sonuçları gösterilir. Bu performans göstergeleri aşağıdaki bölümde açıklanmıştır.

Sorgu performansı göstergeleri

Yürütülen her sorgu için aşağıdaki sorgu performansı göstergeleri kullanılabilir:

• Toplam CPU: Sorguyu tüm işlem düğümleri arasında işlemek için kullanılan genel işlem. Bilgi işlem, ayrıştırma ve veri getirme için kullanılan zamanı temsil eder.
• İşlenen sorgu için kullanılan veriler: Sorguyu işlemek için erişilen genel veriler. Hedef tablonun boyutu, kullanılan zaman aralığı, uygulanan filtreler ve başvuruda bulunan sütun sayısından etkilenir.
• İşlenen sorgunun zaman aralığı: Sorguyu işlemek için erişilen en yeni ve en eski veriler arasındaki boşluk. Sorgu için belirtilen açık zaman aralığından etkilenir.
• İşlenen verilerin yaşı: Şimdi ile sorguyu işlemek için erişilen en eski veriler arasındaki boşluk. Veri getirme işleminin verimliliğini büyük ölçüde etkiler.
• Çalışma alanı sayısı: Örtük veya açık seçime göre sorgu işleme sırasında erişilen çalışma alanı sayısı.
• Bölge sayısı: Çalışma alanlarının örtük veya açık seçimine göre sorgu işleme sırasında erişilen bölge sayısı. Çok bölgeli sorgular çok daha az verimlidir ve performans göstergeleri kısmi kapsam sunar.
• Paralellik: Sistemin bu sorguyu birden çok düğümde ne kadar yürütebildiğinden emin olur. Yalnızca yüksek CPU tüketimine sahip sorgular için geçerlidir. Belirli işlevlerin ve işleçlerin kullanımından etkilenir.

Toplam CPU

Bu sorguyu tüm sorgu işleme düğümleri arasında işlemek için yatırılan gerçek işlem CPU'su. Sorguların çoğu çok sayıda düğümde yürütülür çünkü bu toplam genellikle sorgunun yürütülmesi için geçen sürenin çok üzerinde olur.

100 saniyeden fazla CPU kullanan bir sorgu, aşırı kaynak kullanan bir sorgu olarak kabul edilir. 1.000 saniyeden fazla CPU kullanan bir sorgu kötü amaçlı sorgu olarak kabul edilir ve kısıtlanabilir.

Sorgu işleme süresi şu tarihler için harcandı:

• Veri alma: Eski verilerin alınması, son verilerin alınmasından daha fazla zaman alır.
• Veri işleme: Verilerin mantığı ve değerlendirmesi.

Azure İzleyici Günlükleri, sorgu işleme düğümlerinde harcanan süreye ek olarak şu işlemlerde de zaman harcar:

• Kullanıcının kimliğini doğrulama ve bu verilere erişme izni olduğunu doğrulama.
• Veri depoyu bulma.
• Sorgu ayrıştırma.
• Sorgu işleme düğümlerini ayırma.

Bu süre sorgu toplam CPU süresine dahil değildir.

Yüksek CPU işlevlerini kullanmadan önce kayıtların erken filtrelenmesi

Sorgu komutlarının ve işlevlerinin bazıları CPU tüketiminde ağırdır. Bu durum özellikle JSON ve XML ayrıştıran veya karmaşık normal ifadeleri ayıklayan komutlar için geçerlidir. Bu tür ayrıştırma, parse_json() veya parse_xml() işlevleri aracılığıyla veya dinamik sütunlara başvurduğunda örtük olarak gerçekleşebilir.

Bu işlevler, işledikleri satır sayısıyla orantılı olarak CPU tüketir. En verimli iyileştirme, sorgunun erken aşamalarında koşulları eklemektir where . Bu şekilde, CPU yoğunluklu işlev yürütülmeden önce mümkün olduğunca çok kaydı filtreleyebilirler.

Örneğin, aşağıdaki sorgular tam olarak aynı sonucu üretir. Ancak ikinci en verimli olanıdır çünkü ayrıştırmadan önceki koşul birçok kaydı dışlar:

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

Değerlendirilen where yan tümcelerini kullanmaktan kaçının

Veri kümesinde fiziksel olarak bulunan sütunlar yerine değerlendirilen bir sütundaki where yan tümcelerini içeren sorgular verimliliği kaybeder. Değerlendirilen sütunlara göre filtreleme, büyük veri kümeleri işlendiğinde bazı sistem iyileştirmelerini engeller.

Örneğin, aşağıdaki sorgular tam olarak aynı sonucu üretir. Ancak koşul yerleşik bir sütuna başvurduğundan ikincisi daha verimlidir:

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

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

Bazı durumlarda, filtre uygulama yalnızca alanda yapılmadığından, değerlendirilen sütun sorgu işleme altyapısı tarafından örtük olarak oluşturulur:

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

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

Özetleme ve birleştirmede etkili toplama komutlarını ve boyutlarını kullanma

max(), sum(), count() ve avg() gibi bazı toplama komutlarının mantığı nedeniyle CPU etkisi düşüktür. Diğer komutlar daha karmaşıktır ve bunların verimli bir şekilde yürütülmesini sağlayan buluşsal yöntemler ve tahminler içerir. Örneğin, dcount() her değeri saymadan farklı bir büyük veri kümesi sayısına yakın tahmin sağlamak için HyperLogLog algoritmasını kullanır.

Yüzde birlik işlevleri, en yakın sıralama yüzdebirliği algoritmasını kullanarak benzer yaklaşık değerler gerçekleştirmektedir. Komutların bazıları, etkilerini azaltmak için isteğe bağlı parametreler içerir. Örneğin makeset() işlevinin, cpu ve belleği önemli ölçüde etkileyen maksimum küme boyutunu tanımlamak için isteğe bağlı bir parametresi vardır.

Birleştirme ve özetleme komutları, büyük bir veri kümesini işlerken yüksek CPU kullanımına neden olabilir. Karmaşıklıkları, içinde veya öznitelikleri olarak kullanılan sütunların kardinalitesi olarak adlandırılan olası değerlerin sayısıyla bysummarizejoin doğrudan ilgilidir. ve summarizeiçin join açıklama ve iyileştirme için belge makalelerine ve iyileştirme ipuçlarına bakın.

Örneğin, aşağıdaki sorgular ve ile her zaman bire bir eşlendiğinden CounterNameObjectNametam olarak aynı sonucu CounterPath üretir. Toplama boyutu daha küçük olduğundan ikincisi daha verimlidir:

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

CPU tüketimi, yoğun bilgi işlem gerektiren koşullardan veya genişletilmiş sütunlardan da etkilenebilir where . equal == ve startswith gibi tüm önemsiz dize karşılaştırmaları kabaca aynı CPU etkisine sahiptir. Gelişmiş metin eşleşmelerinin etkisi daha fazladır. Özellikle has işleci contains işlecinden daha verimlidir. Dize işleme teknikleri nedeniyle, kısa dizelerden dört karakterden daha uzun dizeleri aramak daha verimlidir.

Örneğin, aşağıdaki sorgular adlandırma ilkesine bağlı Computer olarak benzer sonuçlar üretir. Ancak ikincisi daha verimlidir:

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

Dekont

Bu gösterge yalnızca anlık kümeden CPU gösterir. Çok bölgeli bir sorguda, bölgelerden yalnızca birini temsil eder. Birden çok çalışma alanı sorgusunda tüm çalışma alanlarını içermeyebilir.

Dize ayrıştırma çalışırken tam XML ve JSON ayrıştırmasından kaçının

Xml veya JSON nesnesinin tam ayrıştırılması yüksek CPU ve bellek kaynakları tüketebilir. Çoğu durumda, yalnızca bir veya iki parametre gerektiğinde ve XML veya JSON nesneleri basit olduğunda, bunları dize olarak ayrıştırmak daha kolaydır. Ayrıştırma işlecini veya diğer metin ayrıştırma tekniklerini kullanın. XML veya JSON nesnesindeki kayıt sayısı arttığından performans artışı daha önemli olacaktır. Kayıt sayısı on milyona ulaştığında çok önemlidir.

Örneğin, aşağıdaki sorgu tam XML ayrıştırma gerçekleştirmeden önceki sorgularla tam olarak aynı sonuçları döndürür. Sorgu xml dosya yapısı hakkında bazı varsayımlar yapar, örneğin FilePath öğesi sonra FileHash gelir ve bunların hiçbiri öznitelikleri vardır:

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

İşlenen sorgu için kullanılan veriler

Sorgunun işlenmesinde kritik bir faktör, taranan ve sorgu işleme için kullanılan veri hacmidir. Azure Veri Gezgini, diğer veri platformlarına kıyasla veri hacmini önemli ölçüde azaltan agresif iyileştirmeler kullanır. Yine de sorguda kullanılan veri birimini etkileyebilecek kritik faktörler vardır.

2.000 KB'tan fazla veri işleyen bir sorgu, aşırı kaynak kullanan bir sorgu olarak kabul edilir. 20.000 KB'tan fazla veri işleyen bir sorgu kötü amaçlı sorgu olarak kabul edilir ve kısıtlanabilir.

Azure İzleyici Günlükleri'nde TimeGenerated sütun, verilerin dizinini oluşturmanın bir yolu olarak kullanılır. Değerlerin TimeGenerated mümkün olduğunca dar bir aralıkla kısıtlanması sorgu performansını artırır. Dar aralık, işlenmesi gereken veri miktarını önemli ölçüde sınırlar.

Arama ve birleşim işleçlerinin gereksiz kullanımından kaçının

İşlenen verileri artıran bir diğer faktör de çok sayıda tablonun kullanılmasıdır. Bu senaryo genellikle ve union * komutları kullanıldığında gerçekleşirsearch *. Bu komutlar, sistemi çalışma alanı içindeki tüm tablolardaki verileri değerlendirmeye ve taramaya zorlar. Bazı durumlarda, çalışma alanında yüzlerce tablo olabilir. Belirli bir tabloya kapsam belirlemeden veya arama yapmaktan search * kaçınmaya çalışın.

Örneğin, aşağıdaki sorgular tam olarak aynı sonucu üretir, ancak sonuncusu en verimli olanıdır:

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

Sorguya erken filtreler ekleme

Veri hacmini azaltmanın bir diğer yöntemi de koşulların sorgunun erken aşamalarında olmasıdır. Azure Veri Gezgini platformu, belirli where bir koşulla ilgili verileri içeren bölümleri bilmesini sağlayan bir önbellek içerir. Örneğin, bir sorgu içeriyorsa where EventID == 4624sorguyu yalnızca eşleşen olaylara sahip bölümleri işleyen düğümlere dağıtır.

Aşağıdaki örnek sorgular tam olarak aynı sonucu üretir, ancak ikincisi daha verimlidir:

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

Koşullu toplama işlevlerini ve materialize işlevini kullanarak aynı kaynak verilerde birden çok tarama yapmaktan kaçının

Sorguda birleştirme veya birleşim işleçleri kullanılarak birleştirilen birkaç alt sorgu olduğunda, her alt sorgu kaynağın tamamını ayrı ayrı tarar. Ardından sonuçları birleştirir. Bu eylem, büyük veri kümelerinde kritik bir faktör olan verilerin taranma sayısını çarpar.

Bu senaryodan kaçınmanın bir tekniği, koşullu toplama işlevlerini kullanmaktır. Özet işlecinde kullanılan toplama işlevlerinin çoğu, birden çok koşula sahip tek bir özet işleci için kullanabileceğiniz koşullu bir sürüme sahiptir.

Örneğin, aşağıdaki sorgular oturum açma olaylarının sayısını ve her hesap için işlem yürütme olaylarının sayısını gösterir. Aynı sonuçları döndürür, ancak ilk sorgu verileri iki kez tarar. İkinci sorgu bunu yalnızca bir kez tarar:

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

Alt sorguların gereksiz olduğu bir diğer durum da ayrıştırma işlecinin yalnızca belirli bir desenle eşleşen kayıtları işlediğine emin olmak için ön filtrelemedir. Ayrıştırma işleci ve diğer benzer işleçler, desen eşleşmediğinde boş sonuçlar döndüreceği için gereksizdir. Aşağıdaki iki sorgu tam olarak aynı sonuçları döndürür, ancak ikinci sorgu verileri yalnızca bir kez tarar. İkinci sorguda, her ayrıştırma komutu yalnızca olaylarıyla ilgilidir. Daha extend sonra işleç boş bir veri durumuna nasıl başvuracaklarını gösterir:

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

Yukarıdaki sorgu alt sorguları kullanmaktan kaçınmanıza izin vermediğinde, bir diğer teknik de sorgu altyapısına materialize() işlevini kullanarak her birinde tek bir veri kaynağı kullanıldığını ima etmektir. Bu teknik, kaynak veriler sorgu içinde birkaç kez kullanılan bir işlevden geldiğinde yararlıdır. Materialize , alt sorgunun çıkışı girişten çok daha küçük olduğunda etkilidir. Sorgu altyapısı, çıktıyı tüm oluşumlarda önbelleğe alır ve yeniden kullanır.

Alınan sütun sayısını azaltma

Azure Veri Gezgini sütunlu bir veri deposu olduğundan, her sütunun alınması diğerlerinden bağımsızdır. Alınan sütun sayısı, genel veri hacmini doğrudan etkiler. Çıktıya yalnızca sonuçları özetleyerek veya belirli sütunları yansıtarak gereken sütunları dahil etmelisiniz.

Azure Veri Gezgini, alınan sütun sayısını azaltmak için çeşitli iyileştirmeler içerir. Örneğin, bir sütuna gerek olmadığını belirlerse, özetleme komutunda başvurulmazsa sütunu almaz.

Örneğin, ikinci sorgu bir sütun değil üç sütun getirmesi gerektiğinden üç kat daha fazla veri işleyebilecek:

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

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

İşlenen sorgunun zaman aralığı

Azure İzleyici Günlüklerindeki tüm günlükler sütuna TimeGenerated göre bölümlenir. Erişilen bölüm sayısı zaman aralığıyla doğrudan ilgilidir. Zaman aralığını azaltmak, istem sorgusu yürütmeyi sağlamanın en verimli yoludur.

Süresi 15 günden uzun olan bir sorgu, aşırı kaynak kullanan bir sorgu olarak kabul edilir. 90 günden uzun bir zaman aralığına sahip bir sorgu kötü amaçlı sorgu olarak kabul edilir ve kısıtlanabilir.

Azure İzleyici Log Analytics'teki Günlük sorgusu kapsamı ve zaman aralığı bölümünde açıklandığı gibi Log Analytics ekranındaki zaman aralığı seçicisini kullanarak zaman aralığını ayarlayabilirsiniz. Seçilen zaman aralığı sorgu meta verileri kullanılarak arka uca geçirildiğinden bu yöntem önerilir.

Alternatif bir yöntem, sorguya açık bir where koşulu TimeGenerated eklemektir. Sorgu farklı bir arabirimden kullanıldığında bile zaman aralığının sabit olduğundan emin olduğundan bu yöntemi kullanın.

Sorgunun TimeGenerated tüm bölümlerinde filtre olduğundan emin olun. Sorguda çeşitli tablolardan veya aynı tablodan veri getiren alt sorgular olduğunda, her sorgunun kendi where koşulunu içermesi gerekir.

Tüm alt sorgularda TimeGenerated filtresinin olduğundan emin olun

Örneğin, aşağıdaki sorguda Perf tablo yalnızca son gün için taranır. Heartbeat Tablo, iki yıla kadar olabilecek tüm geçmişi için taranır:

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

Bu tür bir hatanın oluştuğu yaygın bir durum, en son oluşumu bulmak için arg_max() kullanılmasıdır. Örneğin:

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

İç sorguya bir zaman filtresi ekleyerek bu durumu kolayca düzeltebilirsiniz:

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

Bu hatanın bir diğer örneği, birkaç tablo üzerinde birleşimden hemen sonra zaman kapsamı filtrelemesi gerçekleştirmenizdir. Birleşim gerçekleştirdiğinizde, her alt sorgunun kapsamı belirlenmiş olmalıdır. Kapsam tutarlılığı sağlamak için let deyimini kullanabilirsiniz.

Örneğin, aşağıdaki sorgu yalnızca son gün değil ve Perf tablolarındaki Heartbeat tüm verileri tarar:

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

Sorguyu düzeltmek için:

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

Zaman aralığı ölçüm sınırlamaları

Ölçüm her zaman belirtilen gerçek süreden daha büyük olur. Örneğin, sorgudaki filtre 7 günse, sistem 7,5 veya 8,1 gün tarayabilir. Bu varyansın nedeni, sistemin verileri değişken boyutlardaki öbeklere ayırmasıdır. Tüm ilgili kayıtların tarandığından emin olmak için sistem tüm bölümü tarar. Bu işlem birkaç saati ve hatta bir günden daha fazlasını kapsayabilir.

Sistemin zaman aralığı için doğru bir ölçüm sağlayabildiği birkaç durum vardır. Bu durum, sorgunun yayılma süresinin bir günden kısa olduğu veya çok çalışma alanılı sorgularda çoğu durumda ortaya çıkar.

Önemli

Bu gösterge yalnızca anlık kümede işlenen verileri gösterir. Çok bölgeli bir sorguda, bölgelerden yalnızca birini temsil eder. Birden çok çalışma alanı sorgusunda tüm çalışma alanlarını içermeyebilir.

İşlenen verilerin yaşı

Azure Veri Gezgini çeşitli depolama katmanları kullanır: bellek içi, yerel SSD diskler ve çok daha yavaş Azure Blobları. Veriler ne kadar yeni olursa, daha düşük gecikme süresiyle daha yüksek performanslı bir katmanda depolanma olasılığı o kadar yüksek olur ve bu da sorgu süresini ve CPU'yu azaltır. Verilerin kendisi dışında, sistemin meta veriler için bir önbelleği de vardır. Veriler ne kadar eski olursa meta verilerinin önbellekte olma olasılığı o kadar az olur.

14 günden eski verileri işleyen bir sorgu, aşırı kaynak kullanan bir sorgu olarak kabul edilir.

Bazı sorgular eski verilerin kullanılmasını gerektirir, ancak eski verilerin yanlışlıkla kullanıldığı durumlar da vardır. Bu senaryo, sorgular meta verilerinde bir zaman aralığı sağlamadan yürütülürse ve tüm tablo başvuruları sütunda TimeGenerated bir filtre içermediğinde gerçekleşir. Bu gibi durumlarda sistem, tabloda depolanan tüm verileri tarar. Veri saklama uzun olduğunda, uzun zaman aralıklarını kapsayabilir. Sonuç olarak, veri saklama süresi kadar eski olan veriler taranır.

Bu tür durumlar, örneğin:

• Log Analytics'te zaman aralığını sınırlı olmayan bir alt sorguyla ayarlamaz. Önceki örne bakın.
• API'yi zaman aralığı isteğe bağlı parametreler olmadan kullanma.
• Power BI bağlayıcısı gibi bir zaman aralığını zorlamayan bir istemci kullanma.

Bu durumda da ilgili olduklarından, önceki bölümdeki örneklere ve notlara bakın.

Bölge sayısı

Tek bir sorgu farklı bölgelerde yürütülebilir durumlar vardır. Örneğin:

• Birkaç çalışma alanı açıkça listelendiğinde ve farklı bölgelerde bulunduğunda.
• Kaynak kapsamlı bir sorgu verileri getirirken ve veriler farklı bölgelerde bulunan birden çok çalışma alanında depolandığında.

Bölgeler arası sorgu yürütme, sistemin arka uçta genellikle sorgu son sonuçlarından çok daha büyük olan büyük ara veri öbeklerini seri hale getirmesini ve aktarmasını gerektirir. Ayrıca sistemin iyileştirmeler ve buluşsal yöntemler gerçekleştirme ve önbellekleri kullanma yeteneğini de sınırlar.

Tüm bu bölgeleri taramak için bir neden yoksa kapsamı daha az bölgeyi kaplayacak şekilde ayarlayın. Kaynak kapsamı simge durumuna küçültülmüşse ancak birçok bölge hala kullanılıyorsa, yanlış yapılandırma nedeniyle bu durum oluşabilir. Örneğin, denetim günlükleri ve tanılama ayarları farklı bölgelerdeki farklı çalışma alanlarına gönderilebilir veya birden çok tanılama ayarı yapılandırması olabilir.

Üçten fazla bölgeye yayılan bir sorgu, aşırı kaynak kullanan bir sorgu olarak kabul edilir. Altıdan fazla bölgeye yayılan bir sorgu kötü amaçlı sorgu olarak kabul edilir ve kısıtlanabilir.

Önemli

Bir sorgu birkaç bölgede çalıştırıldığında CPU ve veri ölçümleri doğru olmaz ve bölgelerden yalnızca birinin ölçümlerini temsil eder.

Çalışma alanı sayısı

Çalışma alanları, günlük verilerini ayrıştırmak ve yönetmek için kullanılan mantıksal kapsayıcılardır. Arka uç, seçili bölge içindeki fiziksel kümelerdeki çalışma alanı yerleşimlerini iyileştirir.

Birden çok çalışma alanının kullanılması aşağıdaki durumlarda örneklerden kaynaklanabilir:

• Birkaç çalışma alanı açıkça listelenir.
• Kaynak kapsamlı bir sorgu verileri getiriyor ve veriler birden çok çalışma alanında depolanıyor.

Sorguların bölgeler arası ve kümeler arası yürütülmesi, sistemin arka uçta genellikle sorgu son sonuçlarından çok daha büyük olan büyük ara veri öbeklerini seri hale getirmesini ve aktarmasını gerektirir. Ayrıca sistemin iyileştirmeler ve buluşsal yöntemler gerçekleştirme ve önbellekleri kullanma yeteneğini de sınırlar.

Beşten fazla çalışma alanına yayılan bir sorgu, aşırı kaynak kullanan bir sorgu olarak kabul edilir. Sorgular 100'den fazla çalışma alanına yayılamaz.

Önemli

• Bazı çoklu çalışma alanı senaryolarında CPU ve veri ölçümleri doğru olmaz ve yalnızca birkaç çalışma alanının ölçümlerini temsil eder.
• Açık tanımlayıcıya sahip çalışma alanları arası sorgular: çalışma alanı kimliği veya çalışma alanı Azure Kaynak Kimliği, daha az kaynak kullanır ve daha performanslıdır.

Paralellik

Azure İzleyici Günlükleri sorguları çalıştırmak için büyük Azure Veri Gezgini kümeleri kullanır. Bu kümeler büyük ölçekte farklılık gösterir ve onlarca işlem düğümüne kadar ulaşabilir. Sistem, çalışma alanı yerleştirme mantığına ve kapasitesine göre kümeleri otomatik olarak ölçeklendirir.

Bir sorguyu verimli bir şekilde yürütmek için bölümlendirilir ve işlenmesi için gereken verilere göre işlem düğümlerine dağıtılır. Bazı durumlarda sistem bu adımı verimli bir şekilde gerçekleştiremez ve bu da sorgunun uzun sürmesine neden olabilir.

Paralelliği azaltabilecek sorgu davranışları şunlardır:

• Serileştirme işleci, next(), prev() ve satır işlevleri gibi serileştirme ve pencere işlevlerinin kullanımı. Zaman serisi ve kullanıcı analizi işlevleri bu durumların bazılarında kullanılabilir. Sorgunun sonunda şu işleçler kullanılmadığında da verimsiz serileştirme gerçekleşebilir: aralık, sıralama, sıralama, sıralama, üst, en çok isabet alan ve getschema.
• dcount() toplama işlevinin kullanılması, sistemi ayrı değerlerin merkezi bir kopyasına sahip olacak şekilde zorlar. Veri ölçeği yüksek olduğunda, doğruluğu azaltmak için isteğe bağlı işlev parametrelerini kullanmayı dcount göz önünde bulundurun.
• Çoğu durumda birleştirme işleci genel paralelliği düşürür. Performans sorunlu olduğunda alternatif olarak inceleyin shuffle join .
• Kaynak kapsamı sorgularında, yürütme öncesi Kubernetes rol tabanlı erişim denetimi (RBAC) veya Azure RBAC denetimleri, çok sayıda Azure rol atamasının olduğu durumlarda devam edebilir. Bu durum, daha düşük paralelliğe neden olacak daha uzun denetimlere yol açabilir. Örneğin, binlerce kaynağın bulunduğu ve her kaynağın abonelik veya kaynak grubunda değil, kaynak düzeyinde birçok rol ataması olduğu bir abonelikte sorgu yürütülebilir.
• Bir sorgu küçük veri öbeklerini işliyorsa, sistem bunu birçok işlem düğümüne yaymayacağı için paralelliği düşük olur.

Sonraki adımlar

Kusto Sorgu Dili için başvuru belgeleri