Azure İzleyici'de günlük verileri alım süresi

Azure İzleyici, her ay artan bir hızla terabaytlarce veri gönderen binlerce müşteriye hizmet veren yüksek ölçekli bir veri hizmetidir. Günlük verilerinin toplandıktan sonra kullanılabilir duruma gelmesi için gereken süre hakkında sık sık sorular vardır. Bu makalede, bu gecikme süresini etkileyen farklı faktörler açıklanmaktadır.

Ortalama gecikme

Gecikme süresi, verilerin izlenen sistemde oluşturulma süresini ve Azure İzleyici'de analiz için kullanılabilir hale geldiği zamanı ifade eder. Günlük verilerini almak için ortalama gecikme süresi 20 saniye ile 3 dakika arasındadır. Belirli veriler için belirli bir gecikme süresi, bu makalede açıklanan çeşitli faktörlere bağlı olarak değişir.

Gecikme süresini etkileyen faktörler

Belirli bir veri kümesinin toplam alım süresi aşağıdaki üst düzey alanlara ayrılabilir:

• Aracı süresi: Bir olayı bulma, toplama ve ardından günlük kaydı olarak veri toplama uç noktasına gönderme zamanı. Çoğu durumda, bu işlem bir aracı tarafından işlenir. Ağ tarafından daha fazla gecikme süresi ortaya çıkabilir.
• İşlem hattı süresi: Alma işlem hattının günlük kaydını işleme süresi. Bu zaman aralığı, olayın özelliklerini ayrıştırma ve hesaplanmış bilgiler eklemeyi içerir.
• Dizin oluşturma süresi: Azure İzleyici büyük veri deposuna günlük kaydı almak için harcanan süre.

Bu işlemde sunulan farklı gecikme süresiyle ilgili ayrıntılar aşağıdaki bölümlerde açıklanmıştır.

Aracı toplama gecikme süresi

Zaman değişir

Aracılar ve yönetim çözümleri, bir sanal makineden veri toplamak için farklı stratejiler kullanır ve bu da gecikme süresini etkileyebilir. Bazı belirli örnekler aşağıdaki tabloda listelenmiştir.

Aracı karşıya yükleme sıklığı

1 dakikadan daha altında

Log Analytics aracısının basit olduğundan emin olmak için aracı günlükleri arabelleğe alır ve düzenli aralıklarla Azure İzleyici'ye yükler. Karşıya yükleme sıklığı, veri türüne bağlı olarak 30 saniye ile 2 dakika arasında değişir. Çoğu veri 1 dakikadan daha sonra karşıya yüklenir.

Ağ

Değişir

Ağ koşulları, veri toplama uç noktasına ulaşmak için bu verilerin gecikme süresini olumsuz etkileyebilir.

Azure ölçümleri, kaynak günlükleri, etkinlik günlüğü

30 saniye ile 15 dakika

Azure verileri, işlenmek üzere bir veri toplama uç noktasında kullanılabilir duruma gelmek için daha fazla zaman ekler:

• Azure platformu ölçümleri ölçüm veritabanında bir dakikadan daha küçük bir süre içinde kullanılabilir ancak veri toplama uç noktasına aktarılması 3 dakika daha sürer.
• Kaynak günlükleri genellikle Azure hizmetine bağlı olarak 30 ile 90 saniye arasında bir zaman ekler. Bazı Azure hizmetleri (özellikle Azure SQL Veritabanı ve Azure Sanal Ağ) şu anda günlüklerini 5 dakikalık aralıklarla bildirmektedir. Bu süreyi daha da geliştirmek için çalışmalar devam ediyor. Ortamınızda bu gecikme süresini incelemek için aşağıdaki sorguya bakın.
• Etkinlik günlükleri 3-20 dakika içinde analiz edilebilir.

Yönetim çözümleri koleksiyonu

Değişir

Bazı çözümler bir aracıdan verilerini toplamaz ve daha fazla gecikme süresi sağlayan bir toplama yöntemi kullanabilir. Bazı çözümler, neredeyse gerçek zamanlı toplamaya çalışmadan düzenli aralıklarla veri toplar. Belirli örnekler şunlardır:

• Microsoft 365 çözümü, şu anda neredeyse gerçek zamanlı gecikme süresi garantisi sağlamayan Yönetim Etkinliği API'sini kullanarak etkinlik günlüklerini yoklar.
• Windows Analytics çözümleri (Örneğin Güncelleştirme Uyumluluğu) verileri çözüm tarafından günlük sıklıkta toplanır.

Bir çözümün koleksiyon sıklığını belirlemek için her çözümün belgelerine bakın.

İşlem hattı işlem süresi

30 - 60 saniye

Verilerin veri toplama uç noktasında kullanılabilir duruma gelmesi, sorgu için 30 ile 60 saniye daha sürer.

Günlük kayıtları Azure İzleyici işlem hattına alındıktan sonra (_TimeReceived özelliğinde tanımlandığı gibi), kiracı yalıtımını sağlamak ve verilerin kaybolmadığından emin olmak için geçici depolama alanına yazılır. Bu işlem genellikle 5 ile 15 saniye arasında bir işlem ekler.

Bazı çözümler, veri akışı yapılırken verileri toplamak ve içgörüler türetmek için daha ağır algoritmalar uygular. Örneğin, Application Insights uygulama eşleme verilerini hesaplar; Azure Ağ Performans İzleyicisi gelen verileri 3 dakikalık aralıklarla toplar ve bu da 3 dakikalık gecikme süresini etkili bir şekilde artırır.

Veri toplama işlemi alma zamanı dönüşümü içeriyorsa işlem hattına biraz gecikme süresi ekler. Dönüştürme sorgusunun verimliliğini izlemek için Günlükleri Dönüştürme Süresi /Min ölçümünü kullanın.

Gecikme süresi ekleyen bir diğer işlem de özel günlükleri işleyen işlemdir. Bazı durumlarda, bu işlem aracı tarafından dosyalardan toplanan günlüklere birkaç dakika gecikme süresi ekleyebilir.

Yeni özel veri türleri sağlama

Özel bir günlükten veya Veri Toplayıcı API'sinden yeni bir özel veri türü oluşturulduğunda, sistem ayrılmış bir depolama kapsayıcısı oluşturur. Bu tek seferlik ek yük yalnızca bu veri türünün ilk görünümünde oluşur.

Aşırı gerilim koruması

Genellikle 1 dakikadan kısadır, ancak daha fazla olabilir

Azure İzleyici'nin en önemli önceliği müşteri verilerinin kaybolmadığından emin olmaktır. Bu nedenle sistem, veri dalgalanmaları için yerleşik koruma sağlar. Bu koruma, çok büyük bir yük altında bile sistemin çalışmaya devam etmesini sağlamak için arabellekleri içerir. Normal yük altında, bu denetimler bir dakikadan kısa bir süre ekler. Aşırı koşullarda ve hatalarda, verilerin güvenli olduğundan emin olurken önemli ölçüde zaman ekleyebilirler.

Dizin oluşturma süresi

5 dakika veya daha kısa

Verilere anında erişim sağlamanın aksine analiz ve gelişmiş arama özellikleri sağlama arasında her büyük veri platformu için yerleşik bir denge vardır. Azure İzleyici ile milyarlarca kayıt üzerinde güçlü sorgular çalıştırabilir ve birkaç saniye içinde sonuç alabilirsiniz. Altyapı veri alımı sırasında verileri önemli ölçüde dönüştürdüğü ve benzersiz kompakt yapılarda depoladığı için bu performans mümkün hale getirilir. Sistem, bu yapıları oluşturmak için yeterince kullanılabilir olana kadar verileri arabelleğe alır. Günlük kaydı arama sonuçlarında görünmeden önce bu işlemin tamamlanması gerekir.

Bu işlem şu anda düşük hacimli veriler olduğunda yaklaşık 5 dakika sürer, ancak daha yüksek veri hızlarında daha az zaman alabilir. Bu davranış uygun görünse de bu işlem yüksek hacimli üretim iş yükleri için gecikme süresinin iyileştirilmesine olanak tanır.

Alım süresini denetleme

Alım süresi farklı koşullar altında farklı kaynaklar için farklılık gösterebilir. Ortamınızın belirli davranışlarını belirlemek için günlük sorgularını kullanabilirsiniz. Aşağıdaki tablo, kaydın oluşturulduğu ve Azure İzleyici'ye gönderildiği farklı zamanları nasıl belirleyebileceğinizi belirtir.

Alım gecikmesi gecikmeleri

ingestion_time() işlevinin sonucunu özelliğiyle karşılaştırarak belirli bir kaydın gecikme süresini TimeGenerated ölçebilirsiniz. Bu veriler, alım gecikme süresinin nasıl davrandığını keşfetmek için çeşitli toplamalarla birlikte kullanılabilir. Büyük miktarlardaki veriler için içgörüler elde etmek için alım süresinin yüzdebirlik dilimlerini inceleyin.

Örneğin, aşağıdaki sorgu, hangi bilgisayarların önceki 8 saat içinde en yüksek alım süresine sahip olduğunu gösterir:

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

Önceki yüzde birlik denetimler, gecikme süresindeki genel eğilimleri bulmak için uygundur. Gecikme süresindeki kısa vadeli ani artışı belirlemek için en yüksek (max()) sayısını kullanmak daha etkili olabilir.

Belirli bir bilgisayarın alım süresinde belirli bir süre boyunca detaya gitmek istiyorsanız, aşağıdaki sorguyu kullanın ve bu sorguyu kullanarak önceki güne ait verileri bir grafikte görselleştirin:

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

Bilgisayar alım süresini bulundukları ülkeye/bölgeye göre (IP adreslerine göre) göstermek için aşağıdaki sorguyu kullanın:

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry 

Aracıdan kaynaklanan farklı veri türlerinin farklı alım gecikme süresi olabilir, bu nedenle önceki sorgular diğer türlerle kullanılabilir. Çeşitli Azure hizmetlerinin alım süresini incelemek için aşağıdaki sorguyu kullanın:

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

Application Insights verileri için gecikme koşullarını tanılamak için aynı sorgu mantığını kullanın:

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

Yukarıdaki iki sorgu, "istekler" dışında herhangi bir Application Insights tablosuyla eşleştirilebilir.

Yanıt vermeyi durduran kaynaklar

Bazı durumlarda, bir kaynak veri göndermeyi durdurabilir. Kaynağın veri gönderip göndermediğini anlamak için, standart TimeGenerated alan tarafından tanımlanabilen en son kaydına bakın.

Heartbeat Aracı tarafından dakikada bir sinyal gönderildiğinden, vm'nin kullanılabilirliğini denetlemek için tablosunu kullanın. Yakın zamanda sinyal bildirmemiş etkin bilgisayarları listelemek için aşağıdaki sorguyu kullanın:

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc 

Sonraki adımlar

Azure İzleyici için hizmet düzeyi sözleşmesini okuyun.