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

Azure İzleyici, her ay terabaytlarce veri gönderen ve büyümeye devam eden binlerce müşteri için yüksek ölçekli bir veri hizmetidir. Günlük verilerinin toplandıktan sonra kullanılabilir duruma gelmesi için gereken süreyi ve bu gecikme süresini etkileyen faktörleri anlamak, bu makalede açıklanacak bir kavramdı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 kaydetme 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ğ nedeniyle daha fazla gecikme süresi ortaya çıkabilir.
• İşlem hattı süresi: Alma işlem hattının log 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 Monitor büyük veri deposuna bir günlük kaydını aktarmak 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.

Veri türü	Toplama sıklığı	Notlar
Windows olayları, Syslog olayları ve performans ölçümleri	Derhal toplanır
Linux performans sayaçları	30 saniyelik aralıklarla yoklandı
IIS günlükleri ve metin günlükleri	Zaman damgası değişikliklerinin ardından toplanır	IIS günlükleri için bu zamanlama, IIS'de yapılandırılan geçiş zamanlaması tarafından etkilenir.
Active Directory Senkronizasyon çözümü	Beş günde bir değerlendirme	Aracı günlükleri yalnızca değerlendirme tamamlandığında toplar.
Active Directory Değerlendirme çözümü	Active Directory altyapınızın haftalık değerlendirmesi	Aracı günlükleri yalnızca değerlendirme tamamlandığında toplar.

Aracı yükleme sıklığı

1 dakikadan daha altında

Log Analytics aracısının hafif olduğundan emin olmak için, aracı günlükleri arabelleğe alır ve düzenli aralıklarla Azure İzleme'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 kısa sürede karşıya yükleniyor.

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 20 dakika

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

• Azure platformu metrikleri ölçüm veritabanında bir dakikadan kısa süre içinde mevcuttur, ancak veri toplama uç noktasına ihraç edilmesi 3 dakika daha sürer.
• Kaynak günlükleri genellikle hizmetin karmaşıklığı ve ilgili Azure hizmetlerine bağlı olarak uçtan uca 3-10 dakika içinde kullanılabilir. Örneğin, Azure SQL Veritabanı ve Azure Sanal Ağ şu anda günlüklerini her 5 dakikada bir sağlar. 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 ve uyarı için kullanılabilir.

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ü, Yönetim Etkinliği API'sini kullanarak neredeyse gerçek zamanlı gecikme garantisi sağlamadan etkinlik günlüklerini sorgular.
• 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 sürer.

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 bir veri alma zamanı dönüşümü içeriyorsa, bu işlem hattına biraz gecikme süresi ekler. Dönüştürme sorgusunun verimliliğini izlemek için Günlük Dönüştürme Süresi Dakika Başına ö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şturabilmek için yeterli veri mevcut oluncaya 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ı kullanın. Aşağıdaki tablo, kaydın oluşturulduğu ve Azure İzleyici'ye gönderildiği farklı zamanları nasıl belirleyebileceğinizi belirtir. Günlük sorguları hakkında daha fazla bilgi için bkz. Log Analytics'e genel bakış.

Uyarı

Azure Monitor'un Yardımcı katmanına kayıtları alırken, 30 dakikadan uzun süreye yayılan TimeGenerated zaman damgaları içeren tek bir veri yükünü tek bir API çağrısında göndermekten kaçının. Bu API çağrısı aşağıdaki alma hata koduna RecordsTimeRangeIsMoreThan30Minutesyol açabilir. Bu, kaldırılmakta olan bilinen bir sınırlamadır.

Bu kısıtlama, dönüştürmeleri kullanan Yardımcı günlükler için geçerli değildir.

Adım	Özellik veya işlev	Açıklamalar
Veri kaynağında oluşturulan kayıt	TimeGenerated	TimeGenerated değeri, alınan zamandan iki günden fazla önce ya da gelecekte bir günden fazla olamaz. Aksi takdirde Azure İzleyici Günlükleri, TimeGenerated değerini alınan gerçek saatle değiştirir. Veri kaynağı bu değeri ayarlamazsa, Azure İzleyici Günlükleri değeri _TimeReceived ile aynı zamana ayarlar.
Veri toplama uç noktası tarafından alınan kayıt	_TimeReceived	Bu alan toplu işleme için iyileştirilmemiştir ve büyük veri kümelerini filtrelemek için kullanılmamalıdır.
Çalışma alanında depolanan ve sorgular için kullanılabilen kayıt	ingestion_time()	Yalnızca belirli bir zaman penceresinde alınan kayıtları filtrelemeniz gerekiyorsa kullanmanızı ingestion_time() öneririz. Bu gibi durumlarda, daha geniş bir aralığa sahip bir TimeGenerated filtre de eklemenizi öneririz.

Veri alımı gecikmesi

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 belirli bir zaman diliminde alıcılık zamanını incelemek istiyorsanız, aşağıdaki sorguyu kullanarak geçtiğimiz güne ait verileri bir grafikte görselleştirebilirsiniz.

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.

VM'nin kullanılabilirliğini kontrol etmek için tabloyu kullanın, çünkü her dakika bir kez aracı tarafından bir sinyal gönderilir. 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.