Log Analytics çalışma alanınızı bölgeler arasında çoğaltarak dayanıklılığı artırma (Önizleme)

Makale
09/23/2024

Log Analytics çalışma alanınızı bölgeler arasında çoğaltmak, çoğaltılan çalışma alanına geçmenize ve bölgesel bir hata olduğunda işlemlere devam etmenize olanak sağlayarak dayanıklılığı artırır. Bu makalede Log Analytics çalışma alanı çoğaltmanın nasıl çalıştığı, çalışma alanınızı çoğaltma, geçiş ve geri geçiş yapma ve çoğaltılan çalışma alanları arasında ne zaman geçiş yapmanız gerektiğine karar verme işlemleri açıklanır.

Log Analytics çalışma alanı çoğaltmasının nasıl çalıştığına hızlı bir genel bakış sağlayan bir video aşağıda verilmiştir:

Önemli

Bazen örneğin API çağrısında yük devretme terimini kullansak da, yük devretme genellikle otomatik bir işlemi tanımlamak için de kullanılır. Bu nedenle, bu makalede çoğaltılan çalışma alanına geçişin el ile tetiklediğiniz bir eylem olduğunu vurgulayan geçiş terimi kullanılır.

Gerekli izinler

Eylem	Gerekli izinler
Çalışma alanı çoğaltmasını etkinleştirme	`Microsoft.OperationalInsights/workspaces/write` ve `Microsoft.Insights/dataCollectionEndpoints/write` izinler, İzleme Katkıda Bulunanı yerleşik rolü tarafından sağlandığı gibi, örneğin
Geçiş yapma ve geri dönme (yük devretmeyi tetikleme ve yeniden çalışma)	`Microsoft.OperationalInsights/locations/workspaces/failover`, `Microsoft.OperationalInsights/workspaces/failback`ve `Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action` izinleri, İzleme Katkıda Bulunanı yerleşik rolü tarafından sağlandığı şekilde, örneğin
Çalışma alanı durumunu denetleme	`Microsoft.OperationalInsights/workspaces/read`örneğin İzleme Katkıda Bulunanı yerleşik rolü tarafından sağlanan Log Analytics çalışma alanı izinleri

Log Analytics çalışma alanı çoğaltma nasıl çalışır?

Özgün çalışma alanınız ve bölgeniz birincil olarak adlandırılır. Çoğaltılan çalışma alanı ve alternatif bölge ikincil olarak adlandırılır.

Çalışma alanı çoğaltma işlemi, ikincil bölgede çalışma alanınızın bir örneğini oluşturur. İşlem, birincil çalışma alanınızla aynı yapılandırmaya sahip ikincil çalışma alanını oluşturur ve Azure İzleyici ikincil çalışma alanını birincil çalışma alanı yapılandırmanızda gelecekteki değişikliklerinizle otomatik olarak güncelleştirir.

İkincil çalışma alanı, yalnızca dayanıklılık amacıyla "gölge" bir çalışma alanıdır. Azure portalında ikincil çalışma alanını göremezsiniz ve doğrudan yönetemez veya erişemezsiniz.

Çalışma alanı çoğaltmasını etkinleştirdiğinizde Azure İzleyici, birincil çalışma alanınıza alınan yeni günlükleri ikincil bölgenize de gönderir. Çalışma alanı çoğaltmasını etkinleştirmeden önce çalışma alanına alınan günlükler kopyalanmamıştır.

Birincil bölgenizi etkileyen bir kesinti varsa, tüm alım ve sorgu isteklerini ikincil bölgenize devredebilir ve yeniden yönlendirebilirsiniz. Azure kesintiyi azalttıktan ve birincil çalışma alanınız yeniden iyi duruma geldikten sonra birincil bölgenize geri dönebilirsiniz.

Geçiş yaptığınızda ikincil çalışma alanı etkin olur ve birincil çalışma alanınız etkin değildir. Ardından Azure İzleyici, birincil bölge yerine ikincil bölgenizdeki alım işlem hattı aracılığıyla yeni verileri alır. İkincil bölgenize geçiş yaptığınızda Azure İzleyici, ikincil bölgeden aldığınız tüm verileri birincil bölgeye çoğaltır. İşlem zaman uyumsuzdur ve alım gecikmenizi etkilemez.

Önemli

İkincil bölgeye geçiş yaptıktan sonra, birincil bölge gelen günlük verilerini işleyemiyorsa, Azure İzleyici ikincil bölgedeki verileri 11 güne kadar arabelleğe alır. İlk dört gün boyunca Azure İzleyici, verileri düzenli aralıklarla çoğaltmak için otomatik olarak yeniden dener.

Desteklenen bölgeler

Çalışma alanı çoğaltması şu anda bölge gruplarına (coğrafi olarak bitişik bölgelerden oluşan gruplar) göre düzenlenmiş sınırlı bir bölge kümesindeki çalışma alanları için desteklenmektedir. Çoğaltmayı etkinleştirdiğinizde, çalışma alanı birincil konumuyla aynı bölge grubundaki desteklenen bölgeler listesinden ikincil bir konum seçin. Örneğin, Batı Avrupa'daki bir çalışma alanı Kuzey Avrupa'da çoğaltılabilir, ancak bu bölgeler farklı bölge gruplarında olduğundan Batı ABD 2'de çoğaltılamaz.

Bu bölge grupları ve bölgeleri şu anda desteklenmektedir:

Bölge grubu	Bölgeler	Notlar
Kuzey Amerika	Doğu ABD	Doğu ABD 2 bölgesine veya bölgesinden çoğaltma desteklenmez.
	Doğu ABD 2	Doğu ABD bölgesine veya bölgesinden çoğaltma desteklenmez.
	Batı ABD
	Batı ABD 2
	Orta ABD
	Orta Güney ABD
	Orta Kanada
Avrupa	West Europe
	Kuzey Avrupa
	Güney Birleşik Krallık
	Batı Birleşik Krallık
	Orta Batı Almanya
	Orta Fransa

Veri yerleşimi gereksinimleri

Farklı müşterilerin farklı veri yerleşimi gereksinimleri vardır, bu nedenle verilerinizin nerede depolandığını denetlemeniz önemlidir. Azure İzleyici günlükleri seçtiğiniz birincil ve ikincil bölgelerde işler ve depolar. Daha fazla bilgi için bkz . Desteklenen bölgeler.

Sentinel ve diğer hizmetler için destek

Log Analytics çalışma alanlarını kullanan çeşitli hizmetler ve özellikler çalışma alanı çoğaltma ve geçiş ile uyumludur. İkincil çalışma alanına geçiş yaptığınızda bu hizmetler ve özellikler çalışmaya devam eder.

Örneğin, günlük alımı gecikmesine neden olan bölgesel ağ sorunları Sentinel müşterilerini etkileyebilir. Çoğaltılmış çalışma alanları kullanan müşteriler, Log Analytics çalışma alanları ve Sentinel ile çalışmaya devam etmek için ikincil bölgelerine geçiş yapabilir. Ancak ağ sorunu Sentinel hizmetinin durumunu etkiliyorsa, başka bir bölgeye geçmek sorunu azaltmaz.

Application Insights ve VM Insights gibi bazı Azure İzleyici deneyimleri şu anda yalnızca çalışma alanı çoğaltma ve geçiş ile kısmen uyumludur. Tam liste için bkz . Kısıtlamalar ve sınırlamalar.

Çalışma alanı çoğaltmasını etkinleştirme ve devre dışı bırakma

REST komutu kullanarak çalışma alanı çoğaltmasını etkinleştirir ve devre dışı bırakırsınız. Komutu uzun süre çalışan bir işlemi tetikler, yani yeni ayarların uygulanması birkaç dakika sürebilir. Çoğaltmayı etkinleştirdikten sonra tüm tabloların (veri türleri) çoğaltmaya başlaması bir saat kadar sürebilir ve bazı veri türleri diğerlerinden önce çoğaltmaya başlayabilir. Çalışma alanı çoğaltmasını etkinleştirdikten sonra tablo şemalarında yaptığınız değişiklikler (örneğin, yeni özel günlük tabloları veya oluşturduğunuz özel alanlar veya yeni kaynak türleri için ayarlanmış tanılama günlükleri) çoğaltmanın başlatılması bir saat kadar sürebilir.

Önemli

Ayrılmış bir kümeye bağlı Log Analytics çalışma alanlarının çoğaltılma işlemi şu anda desteklenmemektedir.

Çalışma alanı çoğaltmasını etkinleştirme

Log Analytics çalışma alanınızda çoğaltmayı etkinleştirmek için şu PUT komutu kullanın:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

Where:

<subscription_id>: Çalışma alanınızla ilgili abonelik kimliği.
<resourcegroup_name> : Log Analytics çalışma alanı kaynağınızı içeren kaynak grubu.
<workspace_name>: Çalışma alanınızın adı.
<primary_region>: Log Analytics çalışma alanınızın birincil bölgesi.
<secondary_region>: Azure İzleyici'nin ikincil çalışma alanını oluşturduğu bölge.

Desteklenen location değerler için bkz . Desteklenen bölgeler.

PUT komutu uzun süre çalışan ve tamamlanması biraz zaman alabilen bir işlemdir. Başarılı bir çağrı bir 200 durum kodu döndürür. İsteğinizin sağlama durumunu, İstek sağlama durumunu denetleme bölümünde açıklandığı gibi izleyebilirsiniz.

İstek sağlama durumunu denetleme

İsteğinizin sağlama durumunu denetlemek için şu GET komutu çalıştırın:

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

Where:

<subscription_id>: Çalışma alanınızla ilgili abonelik kimliği.
<resourcegroup_name>: Log Analytics çalışma alanı kaynağınızı içeren kaynak grubu.
<workspace_name>: Log Analytics çalışma alanınızın adı.

GET komutunu kullanarak çalışma alanı sağlama durumunun olarak değiştiğini Updating Succeededve ikincil bölgenin beklendiği gibi ayarlandığını doğrulayın.

Not

Sentinel ile etkileşim kuran çalışma alanları için çoğaltmayı etkinleştirdiğinizde İzleme Listesi ve Tehdit Bilgileri verilerinin ikincil çalışma alanına tam olarak çoğaltılması 12 gün kadar sürebilir.

Veri toplama kurallarını sistem veri toplama uç noktasıyla ilişkilendirme

Azure İzleyici Aracısı ve Günlük Alımı API'sini kullanarak günlük verilerini toplamak için veri toplama kurallarını (DCR) kullanırsınız.

Birincil çalışma alanınıza veri gönderen veri toplama kurallarınız varsa, kuralları çalışma alanı çoğaltmasını etkinleştirdiğinizde Azure İzleyici'nin oluşturduğu bir sistem veri toplama uç noktasıyla (DCE) ilişkilendirmeniz gerekir. Sistem veri toplama uç noktasının adı, çalışma alanı kimliğiniz ile aynıdır. Yalnızca çalışma alanının sistem veri toplama uç noktasıyla ilişkilendirdiğiniz veri toplama kuralları çoğaltmayı ve geçişi etkinleştirir. Bu davranış, çoğaltma maliyetlerinizi denetlemenize yardımcı olan çoğaltılacak günlük akışları kümesini belirtmenize olanak tanır.

Veri toplama kurallarını kullanarak topladığınız verileri çoğaltmak için, veri toplama kurallarınızı Log Analytics çalışma alanınızın sistem veri toplama uç noktasıyla ilişkilendirin:

Azure portalında Veri toplama kuralları'nı seçin.
Veri toplama kuralları ekranından, birincil Log Analytics çalışma alanınıza veri gönderen bir veri toplama kuralı seçin.
Veri toplama kuralına Genel Bakış sayfasında DCE'yi Yapılandır'ı seçin ve kullanılabilir listeden sistem veri toplama uç noktasını seçin:

Sistem DCE'sinin ayrıntıları için çalışma alanı nesne özelliklerine bakın.

Önemli

Çalışma alanının sistem veri toplama uç noktasına bağlı veri toplama kuralları yalnızca belirli bir çalışma alanını hedefleyebilir. Veri toplama kuralları , diğer çalışma alanları veya Azure Depolama hesapları gibi diğer hedefleri hedeflememelidir .

Çalışma alanı çoğaltmayı devre dışı bırakma

Çalışma alanında çoğaltmayı devre dışı bırakmak için şu PUT komutu kullanın:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

Where:

<subscription_id>: Çalışma alanınızla ilgili abonelik kimliği.
<resourcegroup_name> : Çalışma alanı kaynağınızı içeren kaynak grubu.
<workspace_name>: Çalışma alanınızın adı.
<primary_region>: Çalışma alanınız için birincil bölge.

Çalışma alanı ve hizmet durumunu izleme

Alma gecikmesi veya sorgu hataları, genellikle ikincil bölgenize yük devredilerek işlenebilen sorunlara örnek olarak verilebilir. Bu tür sorunlar, Hizmet Durumu bildirimleri ve günlük sorguları kullanılarak algılanabilir.

Hizmet Durumu bildirimleri, hizmetle ilgili sorunlar için yararlıdır. Belirli çalışma alanınızı etkileyen sorunları (ve büyük olasılıkla hizmetin tamamını değil) belirlemek için diğer ölçüleri kullanabilirsiniz:

Çalışma alanı kaynak durumunu temel alan uyarılar oluşturma
Çalışma alanı sistem durumu ölçümleri için kendi eşiklerinizi ayarlama
Çalışma alanınız için özel sistem durumu göstergeleri görevi görecek kendi izleme sorgularınızı oluşturun. Bunun için, Sorgu kullanarak çalışma alanı performansını izleme bölümünde açıklandığı gibi:
- Tablo başına veri alımı gecikme süresini ölçme
- Gecikme kaynağının koleksiyon aracıları mı yoksa alım işlem hattı mı olduğunu belirleme
- Tablo ve kaynak başına alım hacmi anomalilerini izleme
- Tablo, kullanıcı veya kaynak başına sorgu başarı oranını izleme
- Sorgularınızı temel alan uyarılar oluşturma

Not

İkincil çalışma alanınızı izlemek için günlük sorgularını da kullanabilirsiniz, ancak günlük çoğaltmanın toplu işlemlerde yapıldığını unutmayın. Ölçülen gecikme süresi dalgalanabilir ve ikincil çalışma alanınızla ilgili herhangi bir sistem durumu sorununa işaret etmez. Daha fazla bilgi için bkz . Etkin olmayan çalışma alanını denetleme.

İkincil çalışma alanınıza geçiş yapma

Geçiş sırasında çoğu işlem, birincil çalışma alanını ve bölgeyi kullandığınız zaman ile aynı şekilde çalışır. Ancak bazı işlemlerin davranışı biraz farklıdır veya engellenir. Daha fazla bilgi için bkz . Kısıtlamalar ve sınırlamalar.

Ne zaman geçiş yapmalıyım?

İkincil çalışma alanınıza ne zaman geçiş yapmanız gerektiğine ve devam eden performans ve sistem durumu izleme ile sistem standartlarınız ve gereksinimleriniz temelinde birincil çalışma alanınıza ne zaman geri döneceğine karar verirsiniz.

Geçiş planınızda, aşağıdaki alt bölümlerde açıklandığı gibi dikkate almanız gereken birkaç nokta vardır.

Sorun türü ve kapsamı

Geçiş işlemi, alma ve sorgu isteklerini genellikle birincil bölgenizde gecikmeye veya hataya neden olan tüm hatalı bileşenleri atlayan ikincil bölgenize yönlendirir. Sonuç olarak, geçiş şu durumda yardımcı olmaz:

Temel alınan kaynakla ilgili bölgeler arası bir sorun var. Örneğin, aynı kaynak türleri hem birincil hem de ikincil bölgelerinizde başarısız olursa.
Çalışma alanı saklamayı değiştirme gibi çalışma alanı yönetimiyle ilgili bir sorunla karşılaşırsınız. Çalışma alanı yönetim işlemleri her zaman birincil bölgenizde işlenir. Geçiş sırasında çalışma alanı yönetim işlemleri engellenir.

Sorun süresi

Geçiş anlık bir işlem değildir. İstekleri yeniden yönlendirme işlemi, bazı istemcilerin dakikalar içinde aldığı ve diğerlerinin daha fazla zaman alabildiği DNS güncelleştirmelerine dayanır. Bu nedenle, sorunun birkaç dakika içinde çözülebilir olup olmadığını anlamak yararlı olur. Gözlemlenen sorun tutarlı veya sürekliyse geçiş yapmak için beklemeyin. Burada bazı örnekler verilmiştir:

Alma: Birincil bölgenizdeki alma işlem hattıyla ilgili sorunlar, ikincil çalışma alanınıza veri çoğaltmayı etkileyebilir. Geçiş sırasında günlükler bunun yerine ikincil bölgedeki alım işlem hattına gönderilir.
Sorgu: Birincil çalışma alanınızdaki sorgular başarısız olursa veya zaman aşımına ularsa günlük araması uyarıları etkilenebilir. Bu senaryoda, tüm uyarılarınızın doğru tetiklendiğinden emin olmak için ikincil çalışma alanınıza geçin.

İkincil çalışma alanı verileri

Çoğaltmayı etkinleştirmeden önce birincil çalışma alanınıza alınan günlükler ikincil çalışma alanına kopyalanmamıştır. Çalışma alanı çoğaltmasını üç saat önce etkinleştirdiyseniz ve şimdi ikincil çalışma alanınıza geçiş yaparsanız, sorgularınız yalnızca son üç saat içindeki verileri döndürebilir.

Geçiş sırasında bölgeleri değiştirmeden önce, ikincil çalışma alanınızın kullanışlı bir günlük hacmi içermesi gerekir. Geçişi tetiklemeden önce çoğaltmayı etkinleştirdikten sonra en az bir hafta beklemenizi öneririz. Yedi gün, ikincil bölgenizde yeterli verilerin kullanılabilir olmasını sağlar.

Geçiş tetikleme

Geçiş öncesinde çalışma alanı çoğaltma işleminin başarıyla tamamlandığını onaylayın. Geçiş yalnızca ikincil çalışma alanı doğru yapılandırıldığında başarılı olur.

İkincil çalışma alanınıza geçmek için şu POST komutu kullanın:

POST 
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/locations/<secondary_region>/workspaces/<workspace_name>/failover?api-version=2023-01-01-preview

Where:

<subscription_id>: Çalışma alanınızla ilgili abonelik kimliği.
<resourcegroup_name> : Çalışma alanı kaynağınızı içeren kaynak grubu.
<secondary_region>: Geçiş sırasında geçiş yapılan bölge.
<workspace_name>: Geçiş sırasında geçiş yapılan çalışma alanının adı.

POST komutu uzun süre çalışan ve tamamlanması biraz zaman alabilen bir işlemdir. Başarılı bir çağrı bir 202 durum kodu döndürür. İsteğinizin sağlama durumunu, İstek sağlama durumunu denetleme bölümünde açıklandığı gibi izleyebilirsiniz.

Birincil çalışma alanınıza geri dönme

Geri geçiş işlemi sorguların ve günlük alımı isteklerinin ikincil çalışma alanına yeniden yönlendirilmesini iptal eder. Geri döndüğünüzde Azure İzleyici, sorguları yönlendirmeye ve günlük alma isteklerini birincil çalışma alanınıza geri döner.

İkincil bölgenize geçtiğinizde Azure İzleyici, günlükleri ikincil çalışma alanınızdan birincil çalışma alanınıza çoğaltır. Kesinti birincil bölgedeki günlük alımı işlemini etkiliyorsa, Azure İzleyici'nin çoğaltılan günlüklerin birincil çalışma alanınıza alımını tamamlaması zaman alabilir.

Ne zaman geri dönmeliyim?

Aşağıdaki alt bölümlerde açıklandığı gibi, geri geçiş planınızda göz önünde bulundurmanız gereken birkaç nokta vardır.

Günlük çoğaltma durumu

Geri dönmeden önce Azure İzleyici'nin birincil bölgeye geçiş sırasında alınan tüm günlükleri çoğaltmayı tamamladığını doğrulayın. Tüm günlükler birincil çalışma alanına çoğaltılmadan önce geri dönerseniz, günlük alımı tamamlanana kadar sorgularınız kısmi sonuçlar döndürebilir.

Etkin olmayan çalışma alanını denetleme bölümünde açıklandığı gibi, azure portalında etkin olmayan bölge için birincil çalışma alanınızı sorgulayabilirsiniz.

Birincil çalışma alanı durumu

Birincil çalışma alanınıza geri dönme hazırlığında denetlenecek iki önemli sistem durumu öğesi vardır:

Birincil çalışma alanı ve bölge için bekleyen Hizmet Durumu bildirimi olmadığını onaylayın.
Birincil çalışma alanınızın günlükleri alıp sorguları beklendiği gibi işleyişini onaylayın.

İkincil çalışma alanınız etkin olduğunda birincil çalışma alanınızı sorgulama ve isteklerin ikincil çalışma alanınıza yeniden yönlendirilip yönlendirilip atlanmasına ilişkin örnekler için bkz . Etkin olmayan çalışma alanını denetleme.

Geri dönüş tetikleme

Geri dönmeden önce Birincil çalışma alanının sistem durumunu onaylayın ve günlüklerin çoğaltmasını tamamlayın.

Geri geçiş işlemi DNS kayıtlarınızı güncelleştirir. DNS kayıtları güncelleştirildikten sonra, tüm istemcilerin güncelleştirilmiş DNS ayarlarını alması ve birincil çalışma alanına yönlendirmeyi sürdürmesi zaman alabilir.

Birincil çalışma alanınıza geri dönmek için şu POST komutu kullanın:

POST

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/failback?api-version=2023-01-01-preview

Where:

<subscription_id>: Çalışma alanınızla ilgili abonelik kimliği.
<resourcegroup_name> : Çalışma alanı kaynağınızı içeren kaynak grubu.
<workspace_name>: Geri geçiş sırasında geçiş yapılan çalışma alanının adı.

Etkin olmayan çalışma alanını denetleme

Varsayılan olarak, çalışma alanınızın etkin bölgesi çalışma alanını oluşturduğunuz bölgedir ve etkin olmayan bölge ise Azure İzleyici'nin çoğaltılan çalışma alanını oluşturduğu ikincil bölgedir.

Yük devretmeyi tetiklediğinizde, bu anahtarlar – ikincil bölge etkinleştirilir ve birincil bölge etkin değildir. Günlük alımı ve sorgu isteklerinin doğrudan hedefi olmadığından etkin olmadığını söyleriz.

Etkin olmayan bölgedeki çalışma alanında görmeyi beklediğiniz günlüklerin bulunduğunu doğrulamak için bölgeler arasında geçiş yapmadan önce etkin olmayan bölgeyi sorgulamak yararlı olur.

Etkin olmayan bölgeyi sorgulama

Etkin olmayan bölgedeki günlük verilerini sorgulamak için şu GET komutunu kullanın:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=<query>&timespan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>

Örneğin, ikincil bölgenizde geçen gün gibi Perf | count basit bir sorgu çalıştırmak için şunu kullanın:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=Perf%20|%20count&timespan=P1D&overrideWorkspaceRegion=secondary

Log Analytics çalışma alanınızda sorgu denetimini etkinleştirdiğinizde oluşturulan tabloda bu alanları LAQueryLogs denetleyerek Azure İzleyici'nin sorgunuzu istenen bölgede çalıştırdığını onaylayabilirsiniz:

isWorkspaceInFailover: Çalışma alanının sorgu sırasında geçiş modunda olup olmadığını gösterir. Veri türü Boole değeridir (True, False).
workspaceRegion: Sorgu tarafından hedeflenen çalışma alanının bölgesi. Veri türü Dize'dir.

Sorguları kullanarak çalışma alanı performansını izleme

Olası çalışma alanı durumu veya performans sorunları hakkında sizi bilgilendiren uyarı kuralları oluşturmak için bu bölümdeki sorguları kullanmanızı öneririz. Ancak, geçiş yapma kararı dikkatli bir şekilde değerlendirmenizi gerektirir ve otomatik olarak yapılmamalıdır.

Sorgu kuralında, belirtilen sayıda ihlalden sonra ikincil çalışma alanınıza geçiş yapmak için bir koşul tanımlayabilirsiniz. Daha fazla bilgi için bkz . Günlük araması uyarı kuralı oluşturma veya düzenleme.

Çalışma alanı performansının iki önemli ölçümü alım gecikmesi ve alım hacmidir. Aşağıdaki bölümlerde bu izleme seçenekleri incelenmektedir.

Uçtan uca alım gecikmesini izleme

Alma gecikmesi, günlüklerin çalışma alanına alınması için gereken süreyi ölçer. Zaman ölçümü ilk günlüğe kaydedilen olay gerçekleştiğinde başlar ve günlük çalışma alanınızda depolandığında biter. Toplam alım gecikme süresi iki bölümden oluşur:

Aracı gecikme süresi: Aracının bir olayı raporlaması için gereken süre.
Alım işlem hattı (arka uç) gecikme süresi: Alma işlem hattının günlükleri işlemesi ve çalışma alanınıza yazması için gereken süre.

Farklı veri türlerinin farklı alım gecikme süresi vardır. Her veri türü için veri alımını ayrı olarak ölçebilir veya tüm türler için genel bir sorgu ve sizin için daha yüksek öneme sahip belirli türler için daha ayrıntılı bir sorgu oluşturabilirsiniz. Alım gecikme süresinin 90. yüzdebirliğini ölçmenizi öneririz. Bu değer, değişiklik açısından ortalamaya veya 50. yüzdebirliğe (ortanca) göre daha hassastır.

Aşağıdaki bölümlerde, çalışma alanınızın alım gecikme süresini denetlemek için sorguların nasıl kullanılacağı gösterilmektedir.

Belirli tabloların temel alma gecikme süresini değerlendirme

Birkaç gün içinde belirli tabloların temel gecikme süresini belirleyerek başlayın.

Bu örnek sorgu, Performans tablosunda alım gecikmesinin 90. yüzdebirlik dilimini içeren bir grafik oluşturur:

// Assess the ingestion latency baseline for a specific data type
Perf
| where TimeGenerated > ago(3d) 
| project TimeGenerated, 
IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize LatencyIngestion90Percentile=percentile(IngestionDurationSeconds, 90) by bin(TimeGenerated, 1h) 
| render timechart

Sorguyu çalıştırdıktan sonra, bu tablo için beklenen gecikme süresini belirlemek üzere sonuçları ve işlenmiş grafiği gözden geçirin.

Geçerli alım gecikme süresini izleme ve uyarı alma

Belirli bir tablo için temel alma gecikme süresini oluşturduktan sonra, kısa bir süre boyunca gecikme süresindeki değişikliklere göre tablo için bir günlük araması uyarı kuralı oluşturun.

Bu sorgu, son 20 dakika içindeki alım gecikmesini hesaplar:

// Track the recent ingestion latency (in seconds) of a specific table
Perf
| where TimeGenerated > ago(20m) 
| extend IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize Ingestion90Percent_seconds=percentile(IngestionDurationSeconds, 90)

Bazı dalgalanmalar bekleyebileceğiniz için, sorgunun taban çizgisinden önemli ölçüde daha büyük bir değer döndürip döndürmediğini denetlemek için bir uyarı kuralı koşulu oluşturun.

Alım gecikmesinin kaynağını belirleme

Toplam alım gecikmenizin yukarı doğru gittiğini fark ettiğinizde, gecikme süresinin kaynağının aracılar mı yoksa alım işlem hattı mı olduğunu belirlemek için sorguları kullanabilirsiniz.

Bu sorgu aracıların ve işlem hattının 90. yüzdebirlik gecikme süresini ayrı ayrı grafikler:

// Assess agent and pipeline (backend) latency
Perf
| where TimeGenerated > ago(1h) 
| extend AgentLatencySeconds = (_TimeReceived-TimeGenerated)/1s,
	  PipelineLatencySeconds=(ingestion_time()-_TimeReceived)/1s
| summarize percentile(AgentLatencySeconds,90), percentile(PipelineLatencySeconds,90) by bin(TimeGenerated,5m)
| render columnchart

Not

Grafik 90. yüzdebirlik verileri yığılmış sütunlar olarak görüntülese de, iki grafikteki verilerin toplamı toplam alım 90. yüzdebirlik değere eşit değildir.

Alma hacmini izleme

Alma hacmi ölçümleri, çalışma alanınız için toplam veya tabloya özgü alım hacminde beklenmeyen değişiklikleri tanımlamaya yardımcı olabilir. Sorgu birimi ölçümleri, günlük alımıyla ilgili performans sorunlarını belirlemenize yardımcı olabilir. Bazı yararlı birim ölçümleri şunlardır:

Tablo başına toplam alım hacmi
Sabit alım hacmi (bekleme)
Alım anomalileri - alım hacmindeki ani artışlar ve düşüşler

Aşağıdaki bölümlerde, çalışma alanınızın alım hacmini denetlemek için sorguların nasıl kullanılacağı gösterilmektedir.

Tablo başına toplam alım hacmini izleme

Çalışma alanınızdaki tablo başına alım hacmini izlemek için bir sorgu tanımlayabilirsiniz. Sorgu, toplam veya tabloya özgü birimlerde beklenmeyen değişiklikleri denetleyan bir uyarı içerebilir.

Bu sorgu, tablo başına son bir saat içindeki toplam alım hacmini saniyede megabayt (MB) cinsinden hesaplar:

// Calculate total ingestion volume over the past hour per table
Usage 
| where TimeGenerated > ago(1h) 
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated,1h), DataType

Veri alımının beklemede olup olmadığını denetleyin

Günlükleri aracılar aracılığıyla alırsanız, bağlantıyı algılamak için aracının sinyalini kullanabilirsiniz. Hareketsiz bir sinyal, çalışma alanınıza günlük alımında bir duraklama olduğunu ortaya çıkarabilir. Sorgu verileri bir veri alımının beklemede olduğunu ortaya çıkardığında, istenen yanıtı tetikleyen bir koşul tanımlayabilirsiniz.

Aşağıdaki sorgu, bağlantı sorunlarını algılamak için aracı sinyalini denetler:

// Count agent heartbeats in the last ten minutes
Heartbeat 
| where TimeGenerated>ago(10m) 
| count

Veri alımı anomalilerini izleme

Çalışma alanı alma hacminizdeki ani artışları ve düşüşleri çeşitli yollarla belirleyebilirsiniz. çalışma alanınızda izlediğiniz alım birimlerinden anomalileri ayıklamak için series_decompose_anomalies() işlevini kullanın veya benzersiz çalışma alanı senaryolarınızı desteklemek için kendi anomali algılayıcınızı oluşturun.

series_decompose_anomalies kullanarak anomalileri tanımlama

İşlev, series_decompose_anomalies() bir dizi veri değerindeki anomalileri tanımlar. Bu sorgu Log Analytics çalışma alanınızdaki her tablonun saatlik alım hacmini hesaplar ve anomalileri tanımlamak için kullanır series_decompose_anomalies() :

// Calculate hourly ingestion volume per table and identify anomalies
Usage
| where TimeGenerated > ago(24h)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| summarize
    Timestamp=make_list(TimeGenerated),
    IngestionVolumeMB=make_list(IngestionVolumeMB)
    by DataType
| extend series_decompose_anomalies(IngestionVolumeMB)
| mv-expand
    Timestamp,
    IngestionVolumeMB,
    series_decompose_anomalies_IngestionVolumeMB_ad_flag,
    series_decompose_anomalies_IngestionVolumeMB_ad_score,
    series_decompose_anomalies_IngestionVolumeMB_baseline
| where series_decompose_anomalies_IngestionVolumeMB_ad_flag != 0

Günlük verilerindeki anomalileri algılamak için kullanma series_decompose_anomalies() hakkında daha fazla bilgi için bkz . Azure İzleyici'de KQL makine öğrenmesi özelliklerini kullanarak anomalileri algılama ve analiz etme.

Kendi anomali algılayıcınızı oluşturma

Çalışma alanı yapılandırmanıza yönelik senaryo gereksinimlerini desteklemek için özel bir anomali algılayıcısı oluşturabilirsiniz. Bu bölüm, işlemi göstermek için bir örnek sağlar.

Aşağıdaki sorgu hesaplar:

Beklenen alım hacmi: Saat başına, tabloya göre (ortanca değerlerin ortanca değeri temelinde, ancak mantığı özelleştirebilirsiniz)
Gerçek alım hacmi: Tabloya göre saat başına

Beklenen ve gerçek alma birimi arasındaki önemsiz farkları filtrelemek için sorgu iki filtre uygular:

Değişiklik oranı: Tablo başına beklenen hacmin %150'sinin üzerinde veya %66'nın altında
Değişiklik hacmi: Artan veya azaltılan birimin bu tablonun aylık hacminin %0,1'inden fazla olup olmadığını gösterir

// Calculate expected vs actual hourly ingestion per table
let TimeRange=24h;
let MonthlyIngestionByType=
    Usage
    | where TimeGenerated > ago(30d)
    | summarize MonthlyIngestionMB=sum(Quantity) by DataType;
// Calculate the expected ingestion volume by median of hourly medians
let ExpectedIngestionVolumeByType=
    Usage
    | where TimeGenerated > ago(TimeRange)
    | project TimeGenerated, DataType, Quantity
    | summarize IngestionMedian=percentile(Quantity, 50) by bin(TimeGenerated, 1h), DataType
    | summarize ExpectedIngestionVolumeMB=percentile(IngestionMedian, 50) by DataType;
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| join kind=inner (ExpectedIngestionVolumeByType) on DataType
| extend GapVolumeMB = round(IngestionVolumeMB-ExpectedIngestionVolumeMB,2)
| where GapVolumeMB != 0
| extend Trend=iff(GapVolumeMB > 0, "Up", "Down")
| extend IngestedVsExpectedAsPercent = round(IngestionVolumeMB * 100 / ExpectedIngestionVolumeMB, 2)
| join kind=inner (MonthlyIngestionByType) on DataType
| extend GapAsPercentOfMonthlyIngestion = round(abs(GapVolumeMB) * 100 / MonthlyIngestionMB, 2)
| project-away DataType1, DataType2
// Determine whether the spike/deep is substantial: over 150% or under 66% of the expected volume for this data type
| where IngestedVsExpectedAsPercent > 150 or IngestedVsExpectedAsPercent < 66
// Determine whether the gap volume is significant: over 0.1% of the total monthly ingestion volume to this workspace
| where GapAsPercentOfMonthlyIngestion > 0.1
| project
    Timestamp=format_datetime(todatetime(TimeGenerated), 'yyyy-MM-dd HH:mm:ss'),
    Trend,
    IngestionVolumeMB,
    ExpectedIngestionVolumeMB,
    IngestedVsExpectedAsPercent,
    GapAsPercentOfMonthlyIngestion

Sorgu başarısını ve başarısızlığını izleme

Her sorgu, başarılı veya başarısız olduğunu gösteren bir yanıt kodu döndürür. Sorgu başarısız olduğunda, yanıt hata türlerini de içerir. Yüksek hata artışı, çalışma alanı kullanılabilirliği veya hizmet performansıyla ilgili bir sorunu gösterebilir.

Bu sorgu, sunucu hata kodu döndüren sorgu sayısını sayar:

// Count query errors
LAQueryLogs 
| where ResponseCode>=500 and ResponseCode<600 
| count

Kısıtlamalar ve sınırlamalar

Ayrılmış bir kümeye bağlı Log Analytics çalışma alanlarının çoğaltılma işlemi şu anda desteklenmemektedir.
Çalışma alanından kayıtları silen temizleme işlemi, hem birincil hem de ikincil çalışma alanlarından ilgili kayıtları kaldırır. Çalışma alanı örneklerinden biri kullanılamıyorsa temizleme işlemi başarısız olur.
Uyarı kurallarının bölgeler arasında çoğaltılma işlemi şu anda desteklenmiyor. Azure İzleyici etkin olmayan bölgeyi sorgulamayı desteklediğinden, etkin bölgedeki Uyarılar hizmeti düzgün çalışmadığı veya uyarı kuralları kullanılamadığı sürece bölgeler arasında geçiş yaptığınızda sorgu tabanlı uyarılar çalışmaya devam eder.
Sentinel ile etkileşim kuran çalışma alanları için çoğaltmayı etkinleştirdiğinizde İzleme Listesi ve Tehdit Bilgileri verilerinin ikincil çalışma alanına tam olarak çoğaltılması 12 gün kadar sürebilir.
Geçiş sırasında, çalışma alanı yönetim işlemleri desteklenmez, örneğin:
- Çalışma alanı bekletmeyi, fiyatlandırma katmanını, günlük üst sınırı vb. değiştirme
- Ağ ayarlarını değiştirme
- Şemayı yeni özel günlükler aracılığıyla değiştirme veya yeni kaynak sağlayıcılarından platform günlüklerini bağlama(yeni bir kaynak türünden tanılama günlükleri gönderme gibi)
Geçiş sırasında eski Log Analytics aracısının çözüm hedefleme özelliği desteklenmez. Bu nedenle, geçiş sırasında çözüm verileri tüm aracılardan alınılır.
Yük devretme işlemi, tüm alım isteklerini işlenmek üzere ikincil bölgenize yeniden yönlendirmek için Etki Alanı Adı Sistemi (DNS) kayıtlarınızı güncelleştirir. Bazı HTTP istemcilerinin "yapışkan bağlantıları" vardır ve DNS'nin güncelleştirilmiş DNS'sini alması daha uzun sürebilir. Geçiş sırasında, bu istemciler bir süre için günlükleri birincil bölge üzerinden almaya çalışabilir. Günlükleri birincil çalışma alanınıza eski Log Analytics Aracısı, Azure İzleyici Aracısı, kod (Günlük Alımı API'sini veya eski HTTP veri toplama API'sini kullanarak) ve Sentinel gibi diğer hizmetleri kullanarak alıyor olabilirsiniz.

Bu özellikler şu anda desteklenmiyor veya yalnızca kısmen destekleniyor:

Özellik	Destek
Yardımcı masa planları	Desteklenmiyor. Azure İzleyici, Yardımcı günlük planıyla tablolardaki verileri ikincil çalışma alanınıza çoğaltmaz. Bu nedenle, bölgesel bir hata durumunda bu veriler veri kaybına karşı korunmaz ve ikincil çalışma alanınıza geçiş yaptığınızda kullanılamaz.
arama işleri, Geri Yükleme	Kısmen desteklenir - Arama işi ve geri yükleme işlemleri tablolar oluşturur ve bunları arama sonuçları veya geri yüklenen verilerle doldurur. Çalışma alanı çoğaltmasını etkinleştirdikten sonra, bu işlemler için oluşturulan yeni tablolar ikincil çalışma alanınıza çoğaltılır. Çoğaltmayı etkinleştirmeden önce doldurulan tablolar çoğaltılamaz. Geçiş yaptığınızda bu işlemler devam ederse, sonuç beklenmedik olur. Çalışma alanınızın durumuna ve tam zamanlamaya bağlı olarak başarıyla tamamlanabilir ancak yinelenmeyebilir veya başarısız olabilir.
Log Analytics çalışma alanları üzerinden Application Insights	Desteklenmez
VM İçgörüleri	Desteklenmez
Kapsayıcı İçgörüleri	Desteklenmez
Özel bağlantılar	Yük devretme sırasında desteklenmez

Aracılığıyla paylaş

Log Analytics çalışma alanınızı bölgeler arasında çoğaltarak dayanıklılığı artırma (Önizleme)

Gerekli izinler

Log Analytics çalışma alanı çoğaltma nasıl çalışır?

Desteklenen bölgeler

Veri yerleşimi gereksinimleri

Sentinel ve diğer hizmetler için destek

Çalışma alanı çoğaltmasını etkinleştirme ve devre dışı bırakma

Çalışma alanı çoğaltmasını etkinleştirme

İstek sağlama durumunu denetleme

Veri toplama kurallarını sistem veri toplama uç noktasıyla ilişkilendirme

Çalışma alanı çoğaltmayı devre dışı bırakma

Çalışma alanı ve hizmet durumunu izleme

İkincil çalışma alanınıza geçiş yapma

Ne zaman geçiş yapmalıyım?

Sorun türü ve kapsamı

Sorun süresi

İkincil çalışma alanı verileri

Geçiş tetikleme

Birincil çalışma alanınıza geri dönme

Ne zaman geri dönmeliyim?

Günlük çoğaltma durumu

Birincil çalışma alanı durumu

Geri dönüş tetikleme

Etkin olmayan çalışma alanını denetleme

Etkin olmayan bölgeyi sorgulama

Sorguları kullanarak çalışma alanı performansını izleme

Uçtan uca alım gecikmesini izleme

Belirli tabloların temel alma gecikme süresini değerlendirme

Geçerli alım gecikme süresini izleme ve uyarı alma

Alım gecikmesinin kaynağını belirleme

Alma hacmini izleme

Tablo başına toplam alım hacmini izleme

Veri alımının beklemede olup olmadığını denetleyin

Veri alımı anomalilerini izleme

series_decompose_anomalies kullanarak anomalileri tanımlama

Kendi anomali algılayıcınızı oluşturma

Sorgu başarısını ve başarısızlığını izleme

Kısıtlamalar ve sınırlamalar

İlgili içerik

Geri Bildirim

Ek kaynaklar