Log Analytics çalışma alanınızı bölgeler arasında çoğaltarak dayanıklılığı artırın

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.

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 Monitor birincil çalışma alanınıza aktarılan 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 kopyalanmaz.

Not

Çalışma alanı çoğaltması bütün tablo şemalarını çoğaltır, ancak yalnızca çoğaltma etkinleştirildikten sonra kaydedilen yeni günlükleri gönderir. Çalışma alanı çoğaltmasını etkinleştirmeden önce çalışma alanına alınan günlükler kopyalanmaz.

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.

Not

İ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.

Bölgesel bir hata sırasında aktarımdaki veri kaybına karşı koruma

Azure İzleyici,birincil bölgede bir hata olduğunda aktarımdaki verilerin kaybolmamasını sağlayan çeşitli mekanizmalara sahiptir.

Azure İzleyici, birincil bölgedeki veri alma uç noktasına ulaşan verileri, birincil bölgenin işlem hattı verileri işlemek için kullanılamadığında korur. İşlem hattı kullanılabilir olduğunda, aktarımda olan verileri işlemeye devam eder ve Azure İzleyici verileri alır ve ikincil bölgeye çoğaltır.

Birincil bölgenin alım uç noktası kullanılamıyorsa, Azure İzleyici Aracısı günlük verilerini uç noktaya göndermeyi düzenli olarak tekrar dener. İkincil bölgedeki veri alımı uç noktası, geçiş tetikledikten birkaç dakika sonra aracılardan veri almaya başlar.

Log Analytics çalışma alanınıza günlük verileri göndermek için kendi istemcinizi yazarsanız, istemcinizin başarısız alma isteklerini işlediğinden emin olun.

Dağıtma konuları

Not

Çalışma alanı çoğaltması şu anda Yardımcı tabloların çoğaltılması için destek vermemektedir ve Yardımcı tabloları içeren çalışma alanlarında etkinleştirilmemelidir. Yardımcı tablolar çoğaltılamaz ve bu nedenle bölgesel bir hata durumunda veri kaybına karşı korunmaz ve ikincil çalışma alanınıza geçiş yaptığınızda kullanılamaz.

• Geçiş sırasında çalışma alanı yönetim işlemleri başlatılamaz, örneğin:

  • Çalışma alanı saklama süresi, fiyatlandırma katmanı, günlük üst sınır gibi unsurların değiştirilmesi
  • 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 (örneğin, tanılama günlüklerini yeni bir kaynak türünden gönderme)

• 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 güncelleştirmelerini almak daha uzun sürebilir. Geçiş sırasında, bu istemciler bir süre için günlükleri birincil bölge üzerinden kaydetmeye çalışabilir. Birincil çalışma alanınıza, eski Log Analytics Aracısı, Azure İzleme Aracısı, kod (Günlük Alımı API'si veya eski HTTP veri toplama API'sini kullanarak) ve Microsoft Sentinel gibi diğer hizmetler de dahil olmak üzere çeşitli istemcilerle günlükleri alıyor olabilirsiniz.

Önemli

Günlük arama uyarı kuralları, bölgeler arasında geçiş yaptığınızda çalışmaya devam eder, etkin bölgedeki Uyarılar hizmeti düzgün çalışmadıkça veya uyarı kuralları mevcut olmadıkça. Örneğin uyarı kurallarının oluşturulduğu bölge tamamen çalışmıyorsa bu durum oluşabilir. Uyarı kurallarının bölgeler arasında çoğaltılması çalışma alanı çoğaltmasının bir parçası olarak otomatik olarak yapılmaz, ancak kullanıcı tarafından yapılabilir (örneğin, birincil bölgeden dışarı aktararak ve ikincil bölgeye aktararak).

• Ç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.

• Microsoft Sentinel, İzleme Listesi ve Tehdit Bilgileri tablolarındaki günlükleri 12 günde bir yeniler. Bu nedenle, çoğaltılan çalışma alanına yalnızca yeni günlüklerin işlendiği için, İzleme Listesi ve Tehdit İstihbaratı verilerinin ikincil konuma tamamen çoğaltılması 12 gün kadar sürebilir.

• Geçiş sırasında eski Log Analytics aracısının çözüm hedefleme özelliği desteklenmez. Geçiş sırasında, çözüm verileri tüm aracılardan alınır.

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

  Özellik	Destek
  Yardımcı masa planları	Desteklenmiyor. Azure Monitor, Yardımcı günlük planıyla tablolardaki verileri ikincil çalışma alanınıza kopyalamaz. 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, Geri Yükle	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. Bu işlemler geçiş yaptığınızda devam ediyorsa, 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.
  Application Insights, Log Analytics çalışma alanları üzerinden	Desteklenmez
  VM İçgörüleri	Desteklenmez
  Konteyner İçgörüleri	Desteklenmez
  Özel bağlantılar	Yük devretme sırasında desteklenmez

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	Birincil bölgeler	İkincil bölgeler (çoğaltma konumları)
Kuzey Amerika	Orta Kanada Doğu Kanada Orta ABD Doğu ABD* Doğu ABD 2* Orta Kuzey ABD Orta Güney ABD* Orta Batı ABD Batı ABD Batı ABD 2 Batı ABD 3	Orta Kanada Orta ABD Doğu ABD* Doğu ABD 2* Batı ABD Batı ABD 2
Güney Amerika	Güney Brezilya Güneydoğu Brezilya	Güney Brezilya Güneydoğu Brezilya
Avrupa	Orta Fransa Güney Fransa Kuzey Almanya Orta Batı Almanya kuzey İtalya Kuzey Avrupa Doğu Norveç Batı Norveç Orta Polonya Güney Birleşik Krallık İspanya Orta İsveç Orta İsveç Güney Kuzey İsviçre Batı İsviçre Batı Avrupa Batı Birleşik Krallık	Orta Fransa Kuzey Avrupa Güney Birleşik Krallık Batı Avrupa
Orta Doğu	Orta Katar Orta BAE Kuzey Birleşik Arap Emirlikleri	Orta Katar Orta BAE Kuzey Birleşik Arap Emirlikleri
Hindistan	Orta Hindistan Güney Hindistan	Orta Hindistan Güney Hindistan
Asya Pasifik	Doğu Asya Doğu Japonya Batı Japonya Kore Orta Güney Kore Güneydoğu Asya	Doğu Asya Doğu Japonya Kore Orta
Okyanusya	Orta Avustralya Orta Avustralya 2 Doğu Avustralya Güneydoğu Avustralya	Orta Avustralya Doğu Avustralya Güneydoğu Avustralya
Afrika	Güney Afrika Kuzey Güney Afrika Batı	Güney Afrika Kuzey Güney Afrika Batı

Not

Doğu ABD, Doğu ABD 2 ve Orta Güney ABD'de bulunan çalışma alanları yalnızca bu üç kümenin dışındaki ikincil bölgelere çoğaltılabilir. Lütfen Kuzey Amerika bölge grubundan başka bir ikincil konum seçin.

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.

Microsoft 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ında gecikmeye neden olan bölgesel ağ sorunları, Microsoft 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 . Dağıtımla ilgili dikkat edilmesi gerekenler.

Fiyatlandırma modeli

Çalışma alanı çoğaltmasını etkinleştirdiğinizde, çalışma alanınıza kaydedilen tüm verilerin çoğaltılması için ücretlendirilirsiniz.

Önemli

Azure İzleyici Aracısını, Günlükleri Alma API'sini, Azure Event Hubs'ı veya veri toplama kurallarını kullanan diğer veri kaynaklarını kullanarak çalışma alanınıza veri gönderiyorsanız, veri toplama kurallarınızı çalışma alanınızın veri toplama uç noktasıyla ilişkilendirdiğinizden emin olun. Bu ilişkilendirme, alınan verilerin ikincil çalışma alanınıza çoğaltılmasını sağlar. Veri toplama kurallarınızı çalışma alanı veri toplama uç noktasıyla ilişkilendirmezseniz, veriler çoğaltılmasa bile çalışma alanınıza alınan tüm veriler için ücretlendirilirsiniz.

Gerekli izinler

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

Çalışma alanı replikasyonunu etkinleştir ve devre dışı bırak

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.

Ayrılmış küme mi kullanıyorsunuz?

Çalışma alanınız ayrılmış bir kümeye bağlıysa, önce kümede ve yalnızca o zaman çalışma alanında çoğaltmayı etkinleştirmeniz gerekir. Bu işlem, başka bir kümeye geçiş yapsanız bile çalışma alanınızın ayrılmış bir kümeyi kullanmaya devam edebilmesi için ikincil bölgenizde ikinci bir küme oluşturur (çoğaltma ücretleri dışında ek ücret yoktur). Bu, yük devretme sırasında küme tarafından yönetilen anahtarlar (CMK) gibi özelliklerin çalışmaya (aynı anahtarla) devam etmesi anlamına da gelir. Bölgeler arası çoğaltma etkinleştirildikten sonra, bu kümeye bağlı bir veya daha fazla çalışma alanı için çoğaltmayı etkinleştirmeye devam edin.

Önemli

Küme çoğaltma etkinleştirildikten sonra, çoğaltma hedefini değiştirmek için çoğaltmanın devre dışı bırakılması ve farklı bir konumda yeniden etkinleştirilmesi gerekir.

Ayrılmış kümenizde çoğaltmayı etkinleştirmek için aşağıdaki PUT komutunu kullanın. Bu çağrı 202 kodunu döndürür. Uzun süre çalışan ve tamamlanması zaman alabilen bir işlemdir ve küme sağlama durumunu denetleme bölümünde açıklandığı gibi tam durumunu izleyebilirsiniz.

Küme ç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/clusters/<cluster_name>?api-version=2025-02-01

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

Nerede:

• <subscription_id>: Kümenizle ilgili abonelik kimliği
• <resourcegroup_name> : Log Analytics küme kaynağınızı içeren kaynak grubu
• <cluster_name>: Ayrılmış kümenizin adı
• <primary_region>: Log Analytics ayrılmış kümeniz için birincil bölge
• <secondary_region>: Azure İzleyici'nin ikincil ayrılmış kümeyi oluşturduğu bölge

Küme sağlama durumunu denetleme

Kümenizin 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/clusters/<cluster_name>?api-version=2025-02-01

Nerede:

• <subscription_id>: Kümenizle ilgili abonelik kimliği
• <resourcegroup_name>: Log Analytics küme kaynağınızı içeren kaynak grubu
• <cluster_name>: Log Analytics kümenizin adı

GET komutunu kullanarak küme sağlama durumunun Updating'den Succeeded'ye değiştiğini ve ikincil bölgenin beklendiği gibi ayarlandığını doğrulayın.

Not

Küme çoğaltmayı etkinleştirdiğinizde, ikincil konumda yeni bir küme sağlanıyor. Bu işlem 1-2 saat sürebilir.

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

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=2025-02-01

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

Nerede:

• <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 için birincil bölge
• <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. Çalışma alanı sağlama durumunu denetleme bölümünde açıklandığı gibi isteğinizin sağlama durumunu izleyebilirsiniz.

Önemli

Çalışma alanınız ayrılmış bir kümeye bağlıysa, önce kümede çoğaltmayı etkinleştirin. Ayrıca, çalışma alanınızın ikincil konumunun ayrılmış kümesinin ikincil konumuyla aynı olması gerektiğini unutmayın.

Çalışma alanı sağlama durumunu denetleme

Çalışma alanınızın 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=2025-02-01

Nerede:

• <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 Updating'den Succeeded'ye değiştiğini ve 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.

Çalışma alanında çoğaltmanın etkinleştirilip etkinleştirilmediğini denetleme

Çalışma alanı çoğaltmanın etkinleştirilip etkinleştirilmediğini ve nerede etkinleştirildiğini denetlemek için bu ayarları gözden geçirin.

Azure portalında çalışma alanına >Genel Bakış'ı seçin. Çoğaltma etkinleştirilirse , Essentials bölümünde çoğaltılan çalışma alanının bölgesini gösteren İkincil konum görüntülenir.

Aynı Temel Parçalar bölümünde, çoğaltma ayrıntılarını JSON nesnesi olarak görüntüleyen ve REST/CLI aracılığıyla da kullanılabilen bir JSON Görünümü vardır.

Veri toplama kurallarını çalışma alanı veri toplama uç noktasıyla ilişkilendirme

Azure İzleyici Aracısı, Günlük Alımı API'si ve Azure Event Hubs, veri toplama kurallarınızı (DCR) nasıl ayarladığınıza bağlı olarak verileri toplar ve bunları belirttiğiniz hedefe gönderir.

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. Çalışma alanı veri toplama uç noktasının adı, çalışma alanı kimliğiniz ile aynıdır. Yalnızca çalışma alanı 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ı çalışma alanı veri toplama uç noktasıyla ilişkilendirin:

1. Azure portalında Veri toplama kuralları'nı seçin.

2. Veri toplama kuralları ekranından, birincil Log Analytics çalışma alanınıza veri gönderen bir veri toplama kuralı seçin.

3. Veri toplama kuralına Genel Bakış sayfasında DCE'yi Yapılandır'ı seçin ve kullanılabilir listeden çalışma alanı 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ı 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ğaltması başarısız olursa neyi kontrol etmeli

• Çalışma alanı ayrılmış bir kümeye bağlı mı?
  • Çoğaltmanın çalışma alanında etkinleştirilmesi için kümede etkinleştirilmesi gerekir.
  • Hem küme hem de çalışma alanı çoğaltması aynı ikincil konuma ayarlanmalıdır. Örneğin, küme Kuzey Avrupa'ya çoğaltılırsa, kümeye bağlı çalışma alanları yalnızca Kuzey Avrupa'ya da çoğaltılabilir.
• Çoğaltmayı etkinleştirmek için REST API'yi kullandınız mı?
  • API 2025-02-01 veya sonraki bir sürümünü kullandığınızı doğrulayın.
• Birincil çalışma alanı Doğu ABD, Doğu ABD 2 veya Orta Güney ABD'de mi bulunuyor?
  • Doğu ABD, Doğu ABD 2 ve Orta Güney ABD birbirleriyle replikasyon yapamaz.
• Birincil çalışma alanı nerede ve ikincil çalışma alanı nerede? Her iki konum da aynı bölge grubunda olmalıdır. Örneğin, ABD bölgelerinde yer alan çalışma alanlarının Avrupa'da çoğaltma (ikincil bölge) yapması mümkün değildir ve bunun tersi de geçerli değildir. Bölge gruplarının listesi için bkz . Desteklenen bölgeler.
• Gerekli izinlere sahip misiniz?
• Çoğaltma işleminin tamamlanması için yeterli süreye izin ettiniz mi? çoğaltma uzun süre çalışan bir işlemdir. Çalışma alanı sağlama durumunu denetleme bölümünde açıklandığı gibi işlemin durumunu izleyin.
• Çalışma alanı ikincil konumunu değiştirmek için çoğaltmayı yeniden etkinleştirmeyi denediniz mi? İkincil çalışma alanınızın konumunu değiştirmek için önce çalışma alanı çoğaltmasını devre dışı bırakmanız, işlemin tamamlanmasına izin vermeli ve ancak sonra başka bir ikincil konuma çoğaltmayı etkinleştirmelisiniz.

Çalışma alanı çoğaltma özelliği ayarlandığında ancak günlükler çoğaltılmıyorsa kontrol edilecekler nelerdir?

• Çoğaltmanın uygulanması bir saat kadar sürebilir ve bazı veri türleri diğerlerinden önce çoğaltmaya başlayabilir.
• Çoğaltma etkinleştirilmeden önce çalışma alanına yüklenen günlükler ikincil çalışma alanına kopyalanmaz. Replikasyon etkinleştirildikten sonra alınan günlükler çoğaltılır.
• Bazı günlükler çoğaltılır ama diğerleri çoğaltılmadıysa, çalışma alanına günlükleri aktaran tüm veri toplama kurallarının (DCR) düzgün yapılandırıldığını doğrulayın. Çalışma alanını hedefleyen DCR'leri gözden geçirmek için Azure portalındaki Log Analytics Çalışma Alanı İçgörüleri Veri Toplama sekmesine bakın.

Ç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=2025-02-01

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

Nerede:

• <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.

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. Çalışma alanı sağlama durumunu denetleme bölümünde açıklandığı gibi isteğinizin sağlama durumunu izleyebilirsiniz.

Önemli

Ayrılmış bir küme kullanıyorsanız, bu kümeye bağlı her çalışma alanı için çoğaltmayı devre dışı bırakdıktan sonra küme çoğaltmasını devre dışı bırakmanız gerekir.

Küme çoğaltmayı devre dışı bırakma

Küme çoğaltmasını devre dışı bırakma işlemi ancak bu kümeye bağlı tüm çalışma alanları için çoğaltma devre dışı bırakıldıktan sonra (daha önce etkinleştirildiyse) yapılabilir. Ç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/clusters/<cluster_name>?api-version=2025-02-01

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

Nerede:

• <subscription_id>: Kümenizle ilgili abonelik kimliği.
• <resourcegroup_name> : Küme kaynağınızı içeren kaynak grubu.
• <workspace_name>: Kümenizin adı.
• <primary_region>: Kümenizin birincil bölgesi.

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. Çalışma alanı sağlama durumunu denetleme bölümünde açıklandığı gibi isteğinizin sağlama durumunu izleyebilirsiniz.

Not

Çoğaltma devre dışı bırakıldıktan ve çoğaltılan küme temizlendikten sonra, çoğaltılan günlükler silinir ve yeniden erişemez. Ana konumunuzdaki özgün kopyası bu işlemde değiştirilmez.

Önemli

Küme çoğaltmasını kaldırma işlemi 14 gün sürer. Bu işlemin daha hızlı tamamlanması gerekiyorsa bir Azure destek isteği oluşturun.

Çalışma alanının ve hizmetin durumunu izleme

Veri alma gecikmesi veya sorgu hataları, genellikle ikincil bölgenize yük devredilerek yönetilebilen 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 veri alımı hacmi anomalilerini izleyin
  • Tablo, kullanıcı veya kaynak başına sorgu başarı oranını izleme
  • Sorgularınıza dayanarak uyarılar oluşturun

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 . Dağıtımla ilgili dikkat edilmesi gerekenler.

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, veri alma ve sorgu isteklerinizi, birincil bölgenizde gecikmeye veya hataya neden olan hatalı bileşenleri genellikle atlayarak ikincil bölgenize yönlendirir. Sonuç olarak, geçiş şu durumda yardımcı olmaz:

• Bölgeler arası bir sorun, temel alınan kaynakla ilgili. Örneğin, aynı kaynak türleri hem birincil hem de ikincil bölgelerinizde başarısız olursa.
• Çalışma alanı yönetimiyle ilgili, çalışma alanı korumasını değiştirme gibi 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:

• Veri Alma: Birincil bölgenizdeki veri alma işlem hattıyla ilgili sorunlar, ikincil çalışma alanınıza veri çoğaltımını etkileyebilir. Geçiş sırasında günlükler bunun yerine ikincil bölgedeki veri toplama işlem hattına gönderilir.

• Sorgu: Birincil çalışma alanınızdaki sorgular başarısız olursa veya zaman aşımına uğrarsa günlük 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ş yapmadan önce bölgeleri değiştirmeden önce, ikincil çalışma alanınızda yeterli miktarda faydalı günlük verisi bulunmalıdır. 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şi tetikle

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=2025-02-01

Nerede:

• <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şte seçilecek 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. Çalışma alanı sağlama durumunu denetleme bölümünde açıklandığı gibi isteğinizin sağlama durumunu izleyebilirsiniz.

Geçiş (yük devretme) başarısız olduğunda kontrol edilecekler

• Geçiş (yük devretme) işlemi için REST API'sini kullandınız mı?
  • API 2025-02-01 veya sonraki bir sürümünü kullandığınızı doğrulayın.
  • Yük devretme komutunda sağlanan ikincil konumun bu çalışma alanı için ayarlanan ikincil konum olduğunu doğrulayın. Bu bilgiler, çalışma alanının Azure portalı görünümünde ve API üzerinden sağlanır.
• Bölgeler arasında geçiş yapmak için çalışma alanının kendisinde değil, çalışma alanına ait kaynak grubunda Log Analytics Katkıda Bulunanı rolüne sahip olmanız gerekir.

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

Geriye dönüş işlemi, sorguların ve günlük kayıtlarının yedek çalışma alanına yönlendirilmesi işlemini iptal eder. Azure İzleyici, geri döndüğünüzde sorguları ve günlük alma isteklerini birincil çalışma alanınıza yönlendirmeye 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. Eğer bir kesinti birincil bölgedeki günlük toplama sürecini etkiliyorsa, Azure İzleyici'nin çoğaltılan günlükleri birincil çalışma alanınıza toplaması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.

Kayıt çoğaltma durumu

Geri dönmeden önce, Azure Monitor'un 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, sorgularınız, günlük alımı işlemi tamamlanana kadar 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 beklemede olan herhangi bir Hizmet Durumu bildirimi bulunmadığını onaylayın.
• Birincil çalışma alanınızın günlükleri alıp sorguları beklendiği gibi işlediğini onaylayın.

İkincil çalışma alanınız etkin olduğunda ana çalışma alanınızı sorgulama ve taleplerin ikincil çalışma alanına yönlendirilmesini atlama yollarına dair örnekler için bkz Etkin olmayan çalışma alanını denetleme.

Geri dönüş tetikleme

Geri dönmeden önce Birincil çalışma alanı sağlığını onaylayın ve günlüklerin çoğaltılması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=2025-02-01

Nerede:

• <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ı.

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. Çalışma alanı sağlama durumunu denetleme bölümünde açıklandığı gibi isteğinizin sağlama durumunu izleyebilirsiniz.

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 değişir – ikincil bölge etkinleştirilir ve birincil bölge etkinliğini kaybeder. Bunun günlük alımı ve sorgu isteklerinin doğrudan hedefi olmadığı için pasif olduğunu 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 kısa 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ü Boolean'dır (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 arama 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 veri alımı gecikmesini izleyin

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

• Aracı gecikmesi: Aracının bir olayı raporlamak için ihtiyaç duyduğu 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, Perf tablosunda alım gecikmesinin 90. yüzdelik diliminin grafiğini 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.

Mevcut alım gecikme süresini izle ve uyar

Belirli bir tablo için temel veri işleme gecikmesini belirledikten sonra, kısa süreli gecikme değişikliklerine göre tablo için bir günlük arama 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. persentil gecikme süresini ayrı ayrı grafik haline getirir.

// 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österse de, iki grafikteki verilerin toplamı toplam alımın 90. yüzdebirlik değeriyle eşleşmemektedir.

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 hacmi ö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 yutma hacmi (durgunluk)
• 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 izleyin

Ç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 işleme işlemlerinin durup durmadığını kontrol edin.

Günlükleri ajanlar aracılığıyla alırsanız, bağlantıyı algılamak için ajanın kalp atışını kullanabilirsiniz. Durağan bir nabız sinyali, çalışma alanınızdaki günlüklerin alımında bir duraklamayı ortaya çıkarabilir. Sorgu verileri bir veri alımının durduğ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 ajan sinyalini kontrol eder.

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

İş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 series_decompose_anomalies() nasıl kullanılacağını öğrenmek üzere, Azure İzleyici'de KQL makine öğrenmesi özelliklerini kullanarak anomalileri algılama ve analiz etme hakkında bilgi için bakınız.

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 şu hesaplamayı yapar:

• Beklenen alım hacmi: Saat başına, her tablo için (ortancaların ortancası temelinde, ancak hesaplama mantığını ö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

İlgili içerik

• Log Analytics çalışma alanı durumunu izleme
• Azure Monitor Log Analytics çalışma alanınızdaki operasyonel sorunların izlenmesi