Azure'da görev açısından kritik iş yüklerinin sistem durumu modellemesi ve gözlemlenebilirliği

Sistem durumu modellemesi ve gözlemlenebilirliği, sağlam ve bağlamsal izleme özelliklerine odaklanan güvenilirliği en üst düzeye çıkarmak için temel kavramlardır. Bu kavramlar uygulama durumuyla ilgili kritik içgörüler sağlayarak sorunların hızla tanımlanmasını ve çözülmesini teşvik ediyor.

Görev açısından kritik uygulamaların çoğu hem ölçek hem de karmaşıklık açısından önemlidir ve bu nedenle yüksek hacimli işletimsel veriler oluşturur ve bu da en uygun operasyonel eylemi değerlendirmeyi ve belirlemeyi zorlaştırır. Sistem durumu modellemesi sonunda ham izleme günlüklerini ve ölçümlerini uygulama durumunu ölçmek için önemli iş gereksinimleriyle artırarak gözlemlenebilirliği en üst düzeye çıkarmaya çalışır ve tutarlı ve hızlandırılmış işlemler elde etmek için sistem durumu durumlarının otomatik olarak değerlendirilmesini sağlar.

Bu tasarım alanı, operasyonel olgunluğa ulaşmak için gözlemlenebilirlik ve operasyonel yapılar aracılığıyla nicelleştirilmiş uygulama durumu durumlarını eşleyen sağlam bir sistem durumu modeli tanımlama sürecine odaklanır.

Önemli

Bu makale, Azure Well-Architected görev açısından kritik iş yükü serisinin bir parçasıdır. Bu seriyi bilmiyorsanız görev açısından kritik iş yükü nedir? ile başlamanızı öneririz.

Güvenilirliği en üst düzeye çıkarmaya çalışırken üç ana operasyonel olgunluk düzeyi vardır.

1. Sorunları olduğu gibi algılayın ve yanıtlayın.
2. Oluşan veya zaten oluşan sorunları tanılayın.
3. Sorunları gerçekleşmeden önce tahmin edin ve önleyin.

Video: Görev açısından kritik iş yükünüz için bir sistem durumu modeli tanımlama

Katmanlı uygulama durumu

Sistem durumu modeli oluşturmak için, önce katmanlı ve ölçülebilir bir biçimde 'iyi durumda' ve 'iyi durumda olmayan' durumları ölçerek uygulama durumunu önemli iş gereksinimleri bağlamında tanımlayın. Ardından, her uygulama bileşeni için tanımı kararlı bir çalışma durumu bağlamında geliştirin ve uygulama kullanıcı akışlarına göre toplanır. Performans ve kullanılabilirlik için önemli işlevsel olmayan iş gereksinimleriyle üst üste bindirin. Son olarak, genel uygulama durumunun kabul edilebilir bir gösterimini oluşturmak için her bir kullanıcı akışının sistem durumu durumlarını birleştirin. Oluşturulduktan sonra, bu katmanlı sistem durumu tanımları tüm sistem bileşenleri genelinde kritik izleme ölçümlerini bilgilendirmek ve işletimsel alt sistem bileşimini doğrulamak için kullanılmalıdır.

Önemli

Hangi 'iyi durumda değil' durumlarını tanımlarken, uygulamanın tüm düzeylerini temsil eder. Hizmet düşüşü kullanım dışılığa göre nitelenmek için geçici ve geçici olmayan hata durumlarını ayırt etmek önemlidir.

Tasarım konusunda dikkat edilmesi gerekenler

• Sistem durumunu modelleme işlemi, tüm kullanıcı akışlarını tanımlamak ve işlevsel ve mantıksal bileşenler arasındaki bağımlılıkları eşlemek ve bu sayede Azure kaynakları arasındaki bağımlılıkları örtük olarak eşlemek için bir mimari alıştırmayla başlayan yukarıdan aşağıya tasarım etkinliğidir.

• Sistem durumu modeli tamamen temsil ettiği çözümün bağlamını kullanır ve bu nedenle 'tek bir boyut tümüne uymadığından' 'kullanıma açık' çözüm çözülemez.

  • Uygulamalar oluşturma ve bağımlılıklar açısından farklılık gösterir
  • Kaynaklar için ölçümler ve ölçüm eşikleri, hangi değerlerin iyi durumda ve iyi durumda olmayan durumları temsil ettiği konusunda da hassas bir şekilde ayarlanmalıdır. Bunlar, kapsanan uygulama işlevselliğinden büyük ölçüde etkilenir ve işlevsel olmayan gereksinimleri hedefler.

• Katmanlı sistem durumu modeli, uygulama durumunun daha düşük düzey bağımlılıklara geri döndürülerek hizmet düşüşlerine hızlı bir şekilde kök neden olmasına yardımcı olur.

• Tek bir bileşenin sistem durumu durumlarını yakalamak için, bu bileşenin farklı işletimsel özellikleri üretim yükünü yansıtan sabit bir durum altında anlaşılmalıdır. Bu nedenle performans testi, uygulama durumunu tanımlamak ve sürekli değerlendirmek için önemli bir özelliktir.

• Bulut çözümündeki hatalar yalıtımlı olarak gerçekleşmeyebilir. Tek bir bileşende kesinti olması, çeşitli özelliklerin veya ek bileşenlerin kullanılamaz duruma gelmesine neden olabilir.

  • Bu tür hatalar hemen gözlemlenebilir olmayabilir.

Tasarım önerileri

• Tüm uygulamanın operasyonel olarak net bir şekilde anlaşılmasını sağlamak için öncelik olarak ölçülebilir bir sistem durumu modeli tanımlayın.

  • Sistem durumu modeli katmanlı olmalı ve uygulama yapısını yansıtmalıdır.
  • Temel katman, Azure kaynakları gibi tek tek uygulama bileşenlerini dikkate almalıdır.
  • Temel bileşenler, sistem akışlarının durumuna yönelik iş bağlamı odaklı bir mercek oluşturmak için temel işlevsel olmayan gereksinimlerle birlikte toplanmalıdır.
  • Sistem akışları, genel uygulama durumunun anlamlı bir tanımını oluşturmak için iş açısından kritiklik temelinde uygun ağırlıklarla toplanmalıdır. Finansal açıdan önemli veya müşteriye yönelik kullanıcı akışlarına öncelik verilmelidir.
  • Sistem durumu modelinin her katmanı , 'sağlıklı' ve 'iyi durumda olmayan' durumların neyi temsil yaptığını yakalamalıdır.
  • Hizmetin bozulmasını kullanılamazlıktan yalıtmak için heath modelinin geçici ve geçici olmayan iyi durumda olmayan durumları ayırt edebildiğinden emin olun.

• İşlevsel olmayan temel gereksinimleri katsayılar olarak dikkate alarak eşlenmiş bağımlı bileşenler için sistem durumu puanlarını toplayarak her ayrı uygulama bileşeni ve her kullanıcı akışı için ayrıntılı bir sistem durumu puanı kullanarak sistem durumu durumlarını temsil edin.

  • Bir kullanıcı akışının sistem durumu puanı, tüm eşlenen bileşenlerdeki en düşük puanla temsil edilmeli ve kullanıcı akışı için işlevsel olmayan gereksinimlere göre elde edilmeyi dikkate almalıdır.
  • Sistem durumu puanlarını hesaplamak için kullanılan modelin işletim durumunu tutarlı bir şekilde yansıtması gerekir ve aksi takdirde modelin yeni öğrenmeleri yansıtacak şekilde ayarlanması ve yeniden dağıtılması gerekir.
  • Sistem durumu durumunu yansıtmak için sistem durumu puanı eşiklerini tanımlayın.

• Sistem durumu puanı, gözlemlenebilirlik desenleri aracılığıyla görselleştirilebilen ve otomatik operasyonel yordamlar aracılığıyla işlem yapılan temel ölçümlere göre otomatik olarak hesaplanmalıdır.

  • İşletim ekiplerinin artık işletimsel verileri yorumlamak ve uygulama durumuyla eşlemek zorunda kalmaması için sistem durumu puanının izleme çözümünün temelini oluşturması gerekir.

• Kullanılabilirlik Hizmet Düzeyi Hedefi (SLO) elde edilmesini ham kullanılabilirlik yerine hesaplamak için sistem durumu modelini kullanın ve hizmet düşüşü ile kullanım dışı olma arasındaki ayırmanın ayrı SLO'lar olarak yansıtılmasını sağlayın.

• Kod ve yapılandırma güncelleştirmelerinden sonra uygulama durumunun korunup korunmaz olduğunu doğrulamak için CI/CD işlem hatları ve test döngüleri içindeki sistem durumu modelini kullanın.

  • Ci/CD işlemlerinin bir parçası olarak yük testi ve kaos testi sırasında sistem durumunu gözlemlemek ve doğrulamak için sistem durumu modeli kullanılmalıdır.

• Sağlık modeli oluşturmak ve bakımını yapmak yinelemeli bir süreçtir ve sürekli iyileştirmeler sağlamak için mühendislik yatırımı uyumlu hale gelmelidir.

  • Modelin doğruluğunu sürekli olarak değerlendirip hassas ayarlamalar yapmak için bir süreç tanımlayın ve modeli daha fazla eğitmek için makine öğrenmesi modellerine yatırım yapmayı göz önünde bulundurun.

Örnek - Katmanlı sistem durumu modeli

Bu, gösterim amacıyla katmanlı uygulama durumu modelinin basitleştirilmiş bir gösterimidir. Mission-Critical başvuru uygulamalarında kapsamlı ve bağlamsal bir sistem durumu modeli sağlanır:

• Görev Açısından Kritik Çevrimiçi
• Görev Açısından Kritik Bağlı

Sistem durumu modeli uygulanırken, temel kaynak düzeyi ölçümlerin toplanması ve yorumlanması yoluyla tek tek bileşenlerin sistem durumunu tanımlamak önemlidir. Kaynak ölçümlerinin nasıl kullanılabileceğini gösteren bir örnek aşağıdaki görüntüdür:

Bu durum tanımı daha sonra bir KQL sorgusuyla temsil edilebilir. Aşağıdaki örnek sorguda gösterildiği gibi InsightsMetrics (Kapsayıcı içgörüleri) ve AzureMetrics 'i (AKS kümesi için tanılama ayarı) toplar ve modellenmiş sistem durumu eşikleriyle karşılaştırır (iç birleşim).

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

Sonuçta elde edilen tablo çıktısı daha sonra sistem durumu modelinin daha yüksek düzeylerinde daha kolay toplama için bir sistem durumu puanına dönüştürülebilir.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Toplanan bu puanlar daha sonra sistem durumu modelini göstermek için Grafana gibi görselleştirme araçları kullanılarak bir bağımlılık grafiği olarak gösterilebilir.

Bu görüntüde, Azure Mission-Critical çevrimiçi başvuru uygulamasından örnek bir katmanlı sistem durumu modeli gösterilir ve temel bir bileşenin sistem durumu değişikliğinin kullanıcı akışları ve genel uygulama durumu üzerinde nasıl basamaklı bir etkisi olabileceğini gösterir (örnek değerler önceki görüntüdeki tabloya karşılık gelir).

Tanıtım videosu: İzleme ve sistem durumu modelleme tanıtımı

Bağıntılı analiz için birleşik veri havuzu

Hem uygulama bileşenlerinden hem de temel alınan Azure kaynaklarından gelen günlükler ve ölçümler dikkate alınarak tanımlanmış bir ısı modelini doğru bir şekilde göstermek için tüm sistem bileşenlerinden birçok işletimsel veri kümesinin toplanması gerekir. Bu büyük miktarda verinin nihai olarak, hızlı işlem eylemlerini kolaylaştırmak için neredeyse gerçek zamanlı yorumlamaya olanak tanıyan bir biçimde depolanması gerekir. Ayrıca, etkin analizin ilişkisiz olduğundan emin olmak için tüm kapsayan veri kümeleri arasında bağıntı gereklidir ve bu da sistem durumunun katmanlı gösterimine olanak tanır.

Tüm işletimsel verilerin hızlı bir şekilde depolandığından ve uygulama durumunun 'tek bölmeli' gösterimini oluşturmak için bağıntılı analiz için kullanılabilir hale getirildiğinden emin olmak için birleşik bir veri havuzu gereklidir. Azure, Azure İzleyici çatısı altında birkaç farklı işletim teknolojisi sağlar ve Log Analytics çalışma alanı, işletimsel verileri depolamak ve analiz etmek için temel Azure'a özel veri havuzu görevi görür.

Tasarım konusunda dikkat edilmesi gerekenler

Azure İzleyici

• Azure İzleyici tüm Azure abonelikleri için varsayılan olarak etkindir, ancak Azure İzleyici Günlükleri (Log Analytics çalışma alanı) ve Application Insights kaynaklarının dağıtılması ve veri toplama ve sorgulama özelliklerini içerecek şekilde yapılandırılması gerekir.

• Azure İzleyici üç tür gözlemlenebilirlik verisini destekler: günlükler, ölçümler ve dağıtılmış izlemeler.

  • Günlükler, Azure Veri Gezgini'ı temel alan Log Analytics çalışma alanlarında depolanır. Günlük sorguları abonelikler arasında paylaşılabilen sorgu paketlerinde depolanır ve panolar, çalışma kitapları veya diğer raporlama ve görselleştirme araçları gibi gözlemlenebilirlik bileşenlerini yönlendirmek için kullanılır.
  • Ölçümler bir iç zaman serisi veritabanında depolanır. Çoğu Azure kaynağı için ölçümler otomatik olarak toplanır ve 93 gün boyunca saklanır . Ölçüm verileri, kaynağın tanılama ayarı kullanılarak Log Analytics çalışma alanına da gönderilebilir.

• Tüm Azure kaynakları günlükleri ve ölçümleri kullanıma sunar, ancak tanılama verilerini istediğiniz veri havuzuna yönlendirmek için kaynakların uygun şekilde yapılandırılması gerekir.

İpucu

Azure, dağıtılan kaynakların günlükleri ve ölçümleri Log Analytics çalışma alanına gönderecek şekilde yapılandırıldığından emin olmak için uygulanabilecek çeşitli Yerleşik İlkeler sağlar.

• Yasal denetimler için işlem verilerinin kaynak coğrafyalarda veya ülkelerde/bölgelerde kalmasını gerektirmesi yaygın bir durum değildir. Mevzuat gereksinimleri, kritik veri türlerinin uzun bir süre boyunca saklanmasını gerektirebilir. Örneğin, düzenlenen bankacılıkta denetim verilerinin en az yedi yıl saklanması gerekir.

• Farklı işletimsel veri türleri farklı saklama süreleri gerektirebilir. Örneğin, performans verilerinin AIOps bağlamı dışında uzun süreli saklama gerektirme olasılığı düşük olsa da, güvenlik günlüklerinin uzun süre saklanması gerekebilir.

• Veriler, uzun süreli saklama ve/veya denetim amacıyla Log Analytics çalışma alanlarından arşivlenebilir veya dışarı aktarılabilir .

• Ayrılmış Kümeler, desteklenen Azure bölgelerindeki bölgesel hatalara karşı koruma için Kullanılabilirlik Alanları sağlayan bir dağıtım seçeneği sağlar. Ayrılmış Kümeler için minimum günlük veri alma taahhüdü gerekir.

• Log Analytics çalışma alanları belirli bir Azure bölgesine dağıtılır.

• Log Analytics çalışma alanının kullanılamama durumuyla ilgili veri kaybına karşı koruma sağlamak için kaynaklar birden çok tanılama ayarıyla yapılandırılabilir. Her tanılama ayarı ölçümleri ve günlükleri ayrı bir Log Analytics çalışma alanına gönderebilir.

  • Her ek Log Analytics çalışma alanına gönderilen veriler ek maliyet doğuracaktır.
  • Yedekli Log Analytics çalışma alanı aynı Azure bölgesine veya ek bölgesel yedeklilik için ayrı Azure bölgelerine dağıtılabilir.
  • Azure kaynağından farklı bir bölgedeki Log Analytics çalışma alanına günlüklerin ve ölçümlerin gönderilmesi bölgeler arası veri çıkış maliyetlerine neden olur.
  • Bazı Azure kaynakları, kaynağın kendisiyle aynı bölgede log analytics çalışma alanı gerektirir.
  • Log Analytics çalışma alanının diğer kullanılabilirlik seçenekleri için bkz. Azure İzleyici Günlükleri için en iyi yöntemler .

• Log Analytics çalışma alanı verileri Azure Depolama'ya aktarılabilir veya sürekli, zamanlanmış veya tek seferlik olarak Azure Event Hubs.

  • Veri dışarı aktarma, uzun süreli veri arşivlemesine olanak tanır ve kullanılamama nedeniyle olası işletimsel veri kaybına karşı koruma sağlar.
  • Kullanılabilir dışarı aktarma hedefleri Azure Depolama veya Azure Event Hubs. Azure Depolama, bölgesel veya bölgesel de dahil olmak üzere farklı yedeklilik düzeyleri için yapılandırılabilir. Azure Depolama'ya veri dışarı aktarma işlemi, verileri .json dosyaları içinde depolar.
  • Veri dışarı aktarma hedefleri Log Analytics çalışma alanıyla aynı Azure bölgesinde olmalıdır. Olay hub'ı veri dışarı aktarma hedefi, Log Analytics çalışma alanıyla aynı bölgede yer alır. Azure Event Hubs coğrafi olağanüstü durum kurtarma bu senaryo için geçerli değildir.
  • Çeşitli veri dışarı aktarma sınırlamaları vardır. Veri dışarı aktarma için yalnızca çalışma alanında belirli tablolar desteklenir .
  • Arşivleme , verileri dışarı aktarmadan daha düşük bir maliyetle uzun süreli saklama için Log Analytics çalışma alanında depolamak için kullanılabilir.

• Azure İzleyici Günlükleri, gözlemlenebilirlik panoları gibi istemciler için daha az kullanılabilirlik olarak görünen kullanıcı sorgusu azaltma sınırlarına sahiptir.

  • Kullanıcı başına beş eşzamanlı sorgu: Zaten beş sorgu çalışıyorsa, çalışan bir sorgu bitene kadar kullanıcı başına eşzamanlılık kuyruğuna ek sorgular yerleştirilir.
  • Eşzamanlılık kuyruğundaki süre: Bir sorgu üç dakikadan uzun süre eşzamanlılık kuyruğunda yer alırsa, sonlandırılır ve 429 hata kodu döndürülür.
  • Eşzamanlılık kuyruğu derinlik sınırı: Eşzamanlılık kuyruğu 200 sorguyla sınırlıdır ve ek sorgular 429 hata koduyla reddedilir.
  • Sorgu hızı sınırı: Tüm çalışma alanlarında kullanıcı başına 30 saniyede 200 sorgu sınırı vardır.

• Sorgu paketleri, Log Analytics çalışma alanı kullanılamıyorsa günlük sorgularını korumak ve kurtarmak için kullanılabilen Azure Resource Manager kaynaklarıdır.

  • Sorgu paketleri JSON olarak sorgular içerir ve diğer kod olarak altyapı varlıklarına benzer şekilde Azure dışında depolanabilir.
    • Microsoft.Insights REST API aracılığıyla dağıtılabilir.
    • Log Analytics çalışma alanının yeniden oluşturulması gerekiyorsa, sorgu paketi harici olarak depolanan bir tanımdan yeniden dağıtılabilir.

• Application Insights, tüm verilerin depolandığı Log Analytics çalışma alanı tarafından temel alınan çalışma alanı tabanlı bir dağıtım modelinde dağıtılabilir.

• Gönderilen telemetri miktarını azaltmak ve veri alma maliyetlerini iyileştirmek için Application Insights'ta örnekleme etkinleştirilebilir.

• Application Insights da dahil olmak üzere Azure İzleyici tarafından toplanan tüm veriler alınan veri hacmine ve verilerin tutulma süresine göre ücretlendirilir .

  • Log Analytics çalışma alanına alınan veriler ilk 31 güne kadar (Sentinel etkinse 90 gün) ek ücret ödemeden saklanabilir
  • Çalışma alanı tabanlı Application Insights'a alınan veriler ek ücret ödemeden ilk 90 gün boyunca saklanır.

• Log Analytics taahhüt katmanı fiyatlandırma modeli, düşük maliyet ve veri alma ücretlerine yönelik öngörülebilir bir yaklaşım sağlar.

  • Rezervasyon düzeyinin üzerindeki tüm kullanımlar geçerli katmanla aynı fiyatla faturalandırılır.

• Log Analytics, Application Insights ve Azure Veri Gezgini Kusto Sorgu Dili (KQL) kullanır.

• Log Analytics sorguları Log Analytics çalışma alanına (savedSearches ) işlev olarak kaydedilir.

Tasarım önerileri

• Tüm işletimsel veri kümelerinde 'tek bir bölme' sağlamak için Log Analytics çalışma alanını birleşik veri havuzu olarak kullanın.

  • Kullanılan tüm dağıtım bölgelerinde Log Analytics çalışma alanlarını merkezileştirin. Uygulama dağıtımı olan her Azure bölgesi, bu bölgeden kaynaklanan tüm işletimsel verileri toplamak için log analytics çalışma alanını dikkate almalıdır. Tüm genel kaynaklar, birincil dağıtım bölgesinde dağıtılması gereken ayrı bir ayrılmış Log Analytics çalışma alanı kullanmalıdır.
    • Tüm işlem verilerinin tek bir Log Analytics çalışma alanına gönderilmesi tek bir hata noktası oluşturur.
    • Veri yerleşimi gereksinimleri, verilerin kaynak bölgeden ayrılmasını engelleyebilir ve federasyon çalışma alanları bu gereksinimi varsayılan olarak çözer.
    • Günlüklerin ve ölçümlerin bölgeler arasında aktarılmasıyla ilişkili önemli bir çıkış maliyeti vardır.
  • Aynı bölgedeki tüm dağıtım damgaları aynı bölgesel Log Analytics çalışma alanını kullanabilir.

• Daha az bölgesel dağıtım damgasına sahip uygulamalarda Azure İzleyici'nin kullanılamama durumunu korumak için kaynakları farklı Log Analytics çalışma alanlarına işaret eden birden çok tanılama ayarıyla yapılandırmayı göz önünde bulundurun.

• Uygulama günlüklerini, ölçümlerini ve izlemelerini toplamak için application Insights'ı tüm uygulama bileşenlerinde tutarlı bir Uygulama Performansı İzleme (APM) aracı olarak kullanın.

  • Her bölgesel Log Analytics çalışma alanının hem uygulama bileşenlerinden hem de temel alınan Azure kaynaklarından günlükler ve ölçümler içerdiğinden emin olmak için Application Insights'ı çalışma alanı tabanlı bir yapılandırmada dağıtın.

• Farklı çalışma alanlarında birleşik bir 'tek bölme' tutmak için Çalışma Alanları arası sorguları kullanın.

• Çalışma alanının kullanılamadığı durumlarda günlük sorgularını korumak için sorgu paketlerini kullanın.

  • Sorgu paketlerini uygulama git deposu içinde kod olarak altyapı varlıkları olarak depolayın.

• Tüm Log Analytics çalışma alanları, bölgesel dağıtım damgası içindeki uygulama kaynakları için farklı bir yaşam döngüsüne sahip uzun süre çalışan kaynaklar olarak ele alınmalıdır.

• Temel alınan sistem durumu modelini iyileştirmek ve tahmine dayalı eylemi bilgilendirmek amacıyla AIOps ve gelişmiş analizi kolaylaştırmak amacıyla uzun süreli saklama ve analiz için Log Analytics çalışma alanından kritik operasyonel verileri dışarı aktarın.

• Uzun süreli saklama için hangi veri deposu kullanılması gerektiğini dikkatle değerlendirin; tüm verilerin sık erişimli ve sorgulanabilir bir veri deposunda depolanmasına gerek yok.

  • Azure Depolama'nın uzun vadeli işletimsel veri depolaması için grs yapılandırmasında kullanılması kesinlikle önerilir.
    • Kullanılabilir tüm veri kaynaklarını Azure Depolama'ya aktarmak için Log Analytics çalışma alanı dışarı aktarma özelliğini kullanın.

• Log Analytics'in içindeki işletimsel veri türleri için uygun saklama sürelerini seçerek çalışma alanında 'sık erişimli' gözlemlenebilirlik gereksinimlerinin mevcut olduğu daha uzun saklama sürelerini yapılandırabilirsiniz.

• Tüm bölgesel kaynakların operasyonel verileri doğru Log Analytics çalışma alanına yönlendirdiğinden emin olmak için Azure İlkesi kullanın.

Not

Azure giriş bölgesine dağıtım yaparken, işletimsel verilerin merkezi olarak depolanmasına yönelik bir gereksinim varsa, örnek oluşturma sırasında verilerin çatalını oluşturarak hem merkezi araçlara hem de uygulamaya ayrılmış Log Analytics çalışma alanlarına alınabilmesini sağlayabilirsiniz. Alternatif olarak, merkezi ekiplerin uygulama verilerini sorgu edebilmesi için uygulama Log Analytics çalışma alanlarına erişimi kullanıma sunar. Çözümden kaynaklanan işletimsel verilerin uygulamaya ayrılmış Log Analytics çalışma alanlarında kullanılabilir olması son olarak kritik önem taşır.

SIEM tümleştirmesi gerekiyorsa ham günlük girdileri göndermeyin, bunun yerine kritik uyarılar gönderin.

• Yalnızca performansı iyileştirmek için gerekliyse veya örnekleme yapılmadıysa Application Insights'ta örneklemeyi yapılandırın.

  • Aşırı örnekleme, eksik veya yanlış operasyonel sinyallere yol açabilir.

• Tüm izleme olayları ve günlük iletilerini belirli bir isteğe bağlamak için bağıntı kimliklerini kullanın.

  • Yalnızca başarısız istekler için değil, tüm çağrılar için çağırana bağıntı kimlikleri döndür.

• Uygulama kodunun sistem durumu modelini bilgilendirmek ve gerektiğinde sonraki sorun giderme veya kök neden analizini kolaylaştırmak için uygun izleme ve günlüğe kaydetmeyi içerdiğinden emin olun.

  • Uygulama kodu, bir hata oluştuğunda çağıranın bağıntı kimliğini içeren kapsamlı bir hata iletisi sağlayarak Dağıtılmış İzleme'yi kolaylaştırmak için Application Insights'ı kullanmalıdır.

• Tüm günlük iletileri için yapılandırılmış günlüğe kaydetmeyi kullanın.

• Tüm uygulama bileşenlerine anlamlı durum yoklamaları ekleyin.

  • AKS kullanırken, Kubernetes'in bir pod'un iyi durumda veya iyi durumda olmadığını doğru şekilde belirleyebilmesi için her dağıtım (pod) için sistem durumu uç noktalarını yapılandırın.
  • Azure App Service kullanırken, henüz hazır olmayan örneklere trafik göndererek ve iyi durumda olmayan örneklerin hızla geri dönüştürülmesini sağlayarak ölçeği genişletme işlemlerinin hatalara neden olmaması için Sistem Durumu Denetimlerini yapılandırın.

Uygulama Microsoft Mission-Critical Desteği'ne aboneyse, uygulama durumunun Microsoft Desteği tarafından daha doğru modellenmesi için önemli sistem durumu yoklamalarını Microsoft Desteği'a kullanıma sunun.

• Analitik modelleme için ek içgörüler sağladığından, artan veri hacimleri uygulama performansı bağlamında tolere edilmedikçe başarılı sistem durumu denetimi isteklerini günlüğe kaydedin.

• Üretim Log Analytics çalışma alanlarını, işletimsel verilerin günlük alımını sınırlayan günlük üst sınır uygulayacak şekilde yapılandırmayın, çünkü bu durum kritik işletimsel verilerin kaybına yol açabilir.

  • Geliştirme ve Test gibi düşük ortamlarda günlük üst sınır isteğe bağlı maliyet tasarrufu mekanizması olarak değerlendirilebilir.

• İşletimsel veri alma birimlerinin en düşük katman eşiğini karşılaması koşuluyla Log Analytics çalışma alanlarını taahhüt katmanı tabanlı fiyatlandırmayı kullanarak 'kullandıkça öde' fiyatlandırma modeline göre maliyet verimliliklerini kullanacak şekilde yapılandırın.

• Kaynak denetimini kullanarak Log Analytics sorgularını depolamanız ve ci/CD otomasyonu kullanarak bunları ilgili Log Analytics çalışma alanı örneklerine dağıtmanız kesinlikle önerilir.

Görselleştirme

Etkili operasyonlar elde etmek ve güvenilirliği en üst düzeye çıkarmak için sistem durumu modelini kritik işletimsel verilerle görsel olarak temsil etmek çok önemlidir. Panolar nihai olarak DevOps ekipleri için uygulama durumu hakkında neredeyse gerçek zamanlı içgörüler sağlamak ve kararlı durumdan sapmaların hızlı tanısını kolaylaştırmak için kullanılmalıdır.

Microsoft, Azure Panoları, Power BI ve Azure Yönetilen Grafana (şu anda önizlemede) dahil olmak üzere çeşitli veri görselleştirme teknolojileri sağlar. Azure Panoları, Azure İzleyici içindeki işletimsel veriler için sıkı bir şekilde tümleşik kullanıma hazır görselleştirme çözümü sağlayacak şekilde konumlandırılır. Bu nedenle, görev açısından kritik bir iş yükü için operasyonel verilerin ve uygulama durumunun görsel gösteriminde oynaması gereken temel bir role sahiptir. Bununla birlikte, Azure Panolarının bütünsel bir gözlemlenebilirlik platformu olarak konumlandırılması açısından çeşitli sınırlamalar vardır ve sonuç olarak, Azure içinde yönetilen bir çözüm olarak sağlanan Grafana gibi pazar lideri gözlemlenebilirlik çözümlerinin ek kullanımına dikkat edilmelidir.

Bu bölümde Azure Panoları ve Grafana'nın kullanımına odaklanarak uygulama durumuna teknik ve iş lensleri sağlayıp DevOps ekiplerine ve etkili çalışmalara olanak tanıyabilen sağlam bir pano oluşturma deneyimi elde edebilirsiniz. Sağlam pano oluşturma, zaten oluşan sorunları tanılamak ve operasyonel ekiplerin sorunları oluştukları anda algılama ve yanıtlama konusunda desteklenmesi için önemlidir.

Tasarım konusunda dikkat edilmesi gerekenler

• Günlük sorgularını kullanarak sistem durumu modelini görselleştirirken, eşzamanlı ve kuyruğa alınmış sorgularda Log Analytics sınırlarının yanı sıra sonraki sorguların kuyruğa alınıp kısıtlanmış olduğu genel sorgu oranı olduğunu unutmayın.

• Sistem durumu puanlarını hesaplamak ve göstermek için kullanılan işletimsel verileri almaya yönelik sorgular Log Analytics veya Azure Veri Gezgini yazılabilir ve yürütülebilir.

  • Örnek sorgular burada bulunabilir.

• Log Analytics, operasyonel panolar tasarlanırken tasarlanması gereken çeşitli sorgu sınırları uygular.

• CPU kullanımı veya ağ aktarım hızı gibi ham kaynak ölçümlerinin görselleştirmesi, sistem durumu etkilerini belirlemek için operasyon ekipleri tarafından el ile değerlendirme yapılmasını gerektirir ve bu durum etkin bir olay sırasında zor olabilir.

• Grafana gibi bir araçta birden çok kullanıcı pano kullanıyorsa Log Analytics'e gönderilen sorgu sayısı hızla çarpılır.

  • Log Analytics'te eşzamanlı sorgu sınırına ulaşmak, izleyen sorguları kuyruğa alır ve pano deneyiminin 'yavaş' hissetmesini sağlar.

Tasarım Önerileri

• Uygulama durumunun birleşik bir görünümünü oluşturmak için tüm bölgesel Log Analytics Çalışma Alanlarından ve genel Log Analytics Çalışma Alanından sorgulanan çıktıları toplayın ve sunun.

Not

Azure giriş bölgesine dağıtıyorsanız, şirket içi iletişim için ExpressRoute gibi platform kaynaklarına yönelik önemli bağımlılıklar varsa merkezi platform Log Analytics çalışma alanını sorgulamayı göz önünde bulundurun.

• 'Trafik ışığı' modeli, 'iyi durumda' ve 'iyi durumda olmayan' durumları görsel olarak temsil etmek için kullanılmalı ve temel işlevsel olmayan gereksinimlerin ne zaman tam olarak karşılanıp kaynakların en iyi şekilde kullanıldığını göstermek için yeşil kullanılmalıdır. "Sağlıklı", "Düzeyi Düşürülmüş" ve "Kullanılamıyor" durumlarını temsil etmek için "Yeşil", "Sarı ve "Kırmızı" kullanın.

• Azure Front Door için istek sayısı, Azure Cosmos DB için sunucu tarafı gecikme süresi, Event Hubs için gelen/giden iletiler ve AKS için CPU kullanımı veya dağıtım durumları gibi önemli ölçümleri temsil eden genel kaynaklar ve bölgesel dağıtım damgaları için operasyonel lensler oluşturmak için Azure Panolarını kullanın. Panolar, DevOps ekiplerinin önemli ölçümlere doğrudan görünürlük sağladığından emin olmak için hata senaryolarından elde edilen öğrenmeleri kullanarak operasyonel verimliliği artıracak şekilde uyarlanmalıdır.

• Azure Panoları sistem durumu modelini ve gerekli iş gereksinimlerini doğru bir şekilde göstermek için kullanılamıyorsa Grafana'yı pazar lideri özellikler ve kapsamlı bir açık kaynak eklenti ekosistemi sağlayan alternatif bir görselleştirme çözümü olarak değerlendirmenizi öneririz. Grafana altyapısını yönetmenin operasyonel karmaşıklıklarını önlemek için yönetilen Grafana önizleme teklifini değerlendirin.

• Şirket içinde barındırılan Grafana'yı dağıtırken kritik operasyonel panoların bölgesel platform hatalarına ve basamaklı hata senaryolarına dayanıklı olmasını sağlamak için yüksek oranda kullanılabilir ve coğrafi olarak dağıtılmış bir tasarım kullanın.

  • Grafana uygulama düğümlerinin durum bilgisi olmayan kalmasını sağlamak için yapılandırma durumunu Postgres için Azure Veritabanı veya MySQL gibi bir dış veri deposuna ayırın.

    • Dağıtım bölgeleri arasında veritabanı çoğaltmayı yapılandırın.

  • Kapsayıcı tabanlı dağıtımları kullanarak Grafana düğümlerini bir bölgedekiler arasında yüksek oranda kullanılabilir bir yapılandırmayla App Services'e dağıtın.

    • App Service örnekleri dikkate alınması gereken dağıtım bölgelerine dağıtın.

    App Services, işletimsel panolar gibi düşük ölçekli senaryolar için ideal olan ve Grafana'yı AKS'den yalıtan, birincil uygulama platformu ile söz konusu platformun operasyonel gösterimleri arasında net bir endişe ayrımı sağlayan, düşük uyuşmaya neden olan bir kapsayıcı platformu sağlar. Daha fazla yapılandırma önerisi için lütfen Uygulama Platformu'na başvurun.

  • Özel görselleri ve eklentileri barındırmak ve yönetmek için GRS yapılandırmasında Azure Depolama'yı kullanın.

  • Uygulama hizmeti ve veritabanı okuma amaçlı çoğaltma Grafana bileşenlerini en az iki dağıtım bölgesine dağıtın ve Grafana'nın tüm kabul edilen dağıtım bölgelerine dağıtıldığı bir model kullanmayı göz önünde bulundurun.

= %99,99 SLO'yu hedefleyen >senaryolarda grafana, temel işletimsel panoların genel güvenilirliğini en üst düzeye çıkarmak için en az 3 dağıtım bölgesi içinde dağıtılmalıdır.

• Log Analytics sorgu sınırlarını azaltmak için sorguları KQL 'union' işlecini kullanma gibi tek veya az sayıda sorguda toplayarak ve panoda uygun yenileme hızını ayarlayın.

  • Uygun bir maksimum yenileme hızı, pano sorgularının sayısına ve karmaşıklığına bağlıdır; uygulanan sorguların analizi gereklidir.

• Log Analytics'in eşzamanlı sorgu sınırına ulaşılıyorsa, pano için gereken verileri Azure SQL gibi yüksek performanslı bir veri deposunda depolayarak (geçici olarak) alma desenini iyileştirmeyi göz önünde bulundurun.

Otomatik olay yanıtı

Uygulama durumunun görsel gösterimleri, sorun algılamayı ve tanılamayı desteklemek için değerli operasyonel ve iş içgörüleri sağlarken, operasyonel ekiplerin hazır olma ve yorumlamalarının yanı sıra insan tarafından tetiklenen sonraki yanıtların etkililiğine dayanır. Bu nedenle, güvenilirliği en üst düzeye çıkarmak için proaktif olarak algılamak ve sorunları neredeyse gerçek zamanlı olarak yanıtlamak için kapsamlı uyarılar uygulamak gerekir.

Azure İzleyici , Eylem Grupları aracılığıyla operasyonel sinyalleri algılamak, kategorilere ayırmak ve yanıtlamak için kapsamlı bir uyarı çerçevesi sağlar. Bu nedenle bu bölüm, iyi durumdaki bir uygulama durumundan geçerli veya olası sapmalara yanıt olarak otomatik eylemler oluşturmak için Azure İzleyici uyarılarının kullanımına odaklanacaktır.

Önemli

Uyarı ve otomatik eylem, daha fazla olumsuz etki oluşmadan önce sorunları meydana geldikçe etkili bir şekilde algılamak ve bunlara hızlı bir şekilde yanıt vermek için kritik öneme sahiptir. Uyarı ayrıca gelen sinyalleri yorumlamak ve sorunları oluşmadan önce yanıtlamak için bir mekanizma sağlar.

Tasarım konusunda dikkat edilmesi gerekenler

• Uyarı kuralları, ölçümler, günlük sorguları veya kullanılabilirlik testleri gibi çeşitli veri kaynaklarını içerebilen gelen sinyaller için koşullu ölçütler karşılandığında tetiklenen şekilde tanımlanır.

• Uyarılar, belirli bir kaynakta Log Analytics veya Azure İzleyici içinde tanımlanabilir.

• Bazı ölçümler yalnızca Azure İzleyici'de sorgulanabilir, çünkü tüm tanılama veri noktaları Log Analytics'in içinde kullanılamaz.

• Etkin ve geçmiş uyarıları almak için Azure İzleyici Uyarıları API'sini kullanabilirsiniz.

• Uyarı ve eylem gruplarıyla ilgili abonelik sınırları vardır ve bunlar şunlar için tasarlanmalıdır:

  • Yapılandırılabilir uyarı kurallarının sayısı için sınırlar vardır.
  • Uyarılar API'sinin azaltma sınırları vardır ve bu sınır aşırı kullanım senaryolarında dikkate alınmalıdır.
  • Eylem Grupları, yapılandırılabilir yanıt sayısı için tasarlanması gereken birkaç sabit sınıra sahiptir.
    • Her yanıt türünün e-posta dışında 10 eylem sınırı vardır ve bu sınır 1.000 eylemdir.

• Uyarılar, modelin 'kök' puanlama işlevinden kaydedilmiş bir günlük arama sorgusu için bir Uyarı Kuralı oluşturularak katmanlı sistem durumu modeliyle tümleştirilebilir. Örneğin, 'WebsiteHealthScore' kullanmak ve 'İyi durumda değil' durumunu temsil eden sayısal bir değer üzerinde uyarı oluşturmak.

Tasarım önerileri

• Kaynak odaklı uyarı için, uyarı kuralı ölçütleri için tüm tanılama verilerinin kullanılabilir olduğundan emin olmak için Azure İzleyici'de uyarı kuralları oluşturun.

• DevOps yaklaşımını desteklemek için hizmet ekipleriyle uyumlu, minimum sayıda Eylem Grubu içinde otomatik eylemleri birleştirin.

• Mümkün olduğunda Azure'a özel otomatik ölçeklendirme özelliklerini kullanarak otomatik ölçeklendirme işlemleriyle aşırı kaynak kullanımı sinyallerine yanıt verin. Yerleşik otomatik ölçeklendirme işlevselliğinin geçerli olmadığı durumlarda, sinyalleri modellemek ve otomatik ölçeklendirme işlemleriyle ne zaman yanıt verileceğini belirlemek için bileşen sistem durumu puanını kullanın. Otomatik ölçeklendirme işlemlerinin, bileşenler arasındaki ölçek ilişkilerini ölçen bir kapasite modeline göre tanımlandığından emin olun; böylece ölçek yanıtları, diğer bileşenlere göre ölçeklendirilmesi gereken bileşenleri kapsar.

• İş etkisine göre belirlenmesi gereken, önceliklendirilmiş bir sıralamaya uyum sağlamak için eylemleri modelleme.

• Gelişmiş analiz için "soğuk" işletimsel depolama alanına dahil etmek üzere geçmişe dönük uyarılar toplamak için Azure İzleyici Uyarıları API'sini kullanın.

• Otomatik yanıtla karşılanabilen kritik hata senaryoları için el ile yorumlama ve oturumu kapatma sağlandıktan sonra hızlı ve tutarlı eylem sağlamak için operasyonel 'runbook otomasyonu'nun yerinde olduğundan emin olun. El ile yorumlama gerektiren sorunların hızla tanımlanmasını sağlamak için uyarı bildirimlerini kullanma

• Daha önce dikkate alınmamış yeni hata senaryolarının yeni otomatik eylemlere tam olarak uyum sağlanabilmesini sağlamak için mühendislik sprint'lerinde artımlı iyileştirmeler oluşturmak için izinler oluşturun.

• Dağıtım güncelleştirmeleri için temel uyarı kurallarını doğrulamak için CI/CD işlemlerinin bir parçası olarak operasyonel hazırlık testleri gerçekleştirin.

Tahmine dayalı eylem ve yapay zeka işlemleri (AIOps)

Makine öğrenmesi modelleri, operasyonel verileri ilişkilendirmek ve önceliklendirmek için uygulanabilir; aşırı uyarıyı filtrelemeyle ilgili kritik içgörülerin toplanmasına ve sorunların etkilenmeden önce tahmin edilmesine yardımcı olur ve bunu yaptıklarında olay yanıtını hızlandırır.

Daha açık belirtmek gerekirse, sistemin, kullanıcıların ve DevOps işlemlerinin davranışıyla ilgili kritik içgörülere bir AIOps metodolojisi uygulanabilir. Bu içgörüler, şimdi gerçekleşen bir sorunu belirlemeyi (algılamayı), sorunun neden gerçekleştiğini belirlemeyi (tanılamayı) veya gelecekte ne olacağını bildirmeyi (tahmin etmeyi) içerebilir. Bu tür içgörüler, önemli iş ölçümlerini, sistem kalitesi ölçümlerini ve DevOps üretkenlik ölçümlerini kullanarak etkin veya olası sorunları azaltmak için uygulamayı ayarlayan ve en iyi duruma getiren eylemleri iş etkisine göre önceliklendirmek için kullanılabilir. Gerçekleştirilen eylemler, temel alınan modeli ek verimlilikler sağlamak üzere daha fazla eğiten bir geri bildirim döngüsü aracılığıyla sisteme dahil edilebilir.

Azure'da AIOps için analiz modelleri oluşturmak ve eğitmek için kullanılabilecek Azure Synapse ve Azure Databricks gibi birden çok analiz teknolojisi vardır. Bu bölüm bu nedenle bu teknolojilerin AIOps'a uyum sağlamak ve tahmine dayalı eylem sağlamak için bir uygulama tasarımında nasıl konumlandırılabildiğine odaklanacak ve Güçlü yeni özelliklerle birlikte Azure'ın veri hizmetlerinin en iyilerini bir araya getirerek uyuşma oranını azaltan Azure Synapse odaklanacaktır.

AIOps, sorunlara oluşmadan önce daha iyi yanıt vermek ve bunları önlemek amacıyla sürekli bir süre boyunca gözlemlenen karmaşık operasyonel sinyalleri yorumlamak ve ilişkilendirmek için tahmine dayalı eyleme, yorumlamaya ve ilişkilendirmeye yardımcı olmak için kullanılır.

Tasarım konusunda dikkat edilmesi gerekenler

• Azure Synapse Analytics birden çok Machine Learning (ML) özelliği sunar.

  • ML modelleri MLLib, SparkML ve MMLSpark gibi kitaplıkların yanı sıra Scikit Learn gibi popüler açık kaynak kitaplıklarla Synapse Spark Havuzlarında eğitilebilir ve çalıştırılabilir.
  • ML modelleri PySpark/Python, Scala veya .NET gibi yaygın veri bilimi araçlarıyla eğitilebilir.

• Synapse Analytics, Azure Synapse Not Defterleri aracılığıyla Azure ML ile tümleşiktir. Bu sayede ML modelleri Otomatik ML kullanılarak Azure ML Çalışma Alanında eğitilebilir.

• Synapse Analytics, Anomali Algılama gibi çeşitli etki alanlarındaki genel sorunları çözmek için Azure Bilişsel Hizmetler'i kullanarak ML özelliklerini de etkinleştirir. Bilişsel Hizmetler Azure Synapse, Azure Databricks'te ve istemci uygulamalarında SDK'lar ve REST API'ler aracılığıyla kullanılabilir.

• Azure Synapse düzenleme işlem hatlarında verileri ayıklamak, dönüştürmek ve yüklemek (ETL) veya almak için Azure Data Factory araçlarıyla yerel olarak tümleşir.

• Azure Synapse, Azure Blob depolama veya Azure Data Lake Storage depolanan verilere dış veri kümesi kaydını etkinleştirir.

  • Kayıtlı veri kümeleri Synapse Spark havuzu veri analizi görevlerinde kullanılabilir.

• Azure Databricks, ek Spark özellikleri için Azure Synapse Analytics işlem hatlarıyla tümleştirilebilir.

  • Synapse, verileri okumayı ve bir Databricks kümesine göndermeyi düzenler ve burada ml modeli eğitimi için dönüştürülebilir ve hazırlanabilir.

• Kaynak verilerin genellikle analiz ve ML için hazırlanması gerekir.

  • Synapse; Apache Spark, Synapse Notebooks ve T-SQL ile yerleşik görselleştirmeler içeren sunucusuz SQL havuzları dahil olmak üzere veri hazırlamaya yardımcı olacak çeşitli araçlar sunar.

• Eğitilmiş, kullanıma hazır ve dağıtılmış ML modelleri Synapse'te toplu puanlama için kullanılabilir.

  • CI/CD işlem hattında regresyon veya düşüş tahminlerini çalıştırma gibi AIOps senaryoları gerçek zamanlı puanlama gerektirebilir.

• AIOps metodolojisi bağlamında tam olarak anlaşılması gereken Azure Synapse abonelik sınırları vardır.

• AIOps'yi tam olarak dahil etmek için neredeyse gerçek zamanlı gözlemlenebilirlik verilerinin sürekli olarak gerçek zamanlı ML çıkarım modellerine beslenmesi gerekir.

  • Anomali algılama gibi özellikler gözlemlenebilirlik veri akışı içinde değerlendirilmelidir.

Tasarım önerileri

• AIOps model eğitimi için eksiksiz bir işletimsel veri kümesinin kullanılabilir olması için tüm Azure kaynaklarının ve uygulama bileşenlerinin tam olarak izlendiğinden emin olun.

• Log Analytics işletimsel verilerini genel ve bölgesel Azure Depolama Hesaplarından analiz için Azure Synapse alın.

• Azure İzleyici Uyarıları API'sini kullanarak geçmişe dönük uyarıları alın ve işlem verilerinin daha sonra ML modellerinde kullanması için bunu soğuk depolamada depolayın. Log Analytics verilerini dışarı aktarma kullanılıyorsa, geçmiş uyarı verilerini dışarı aktarılan Log Analytics verileriyle aynı Azure Depolama hesaplarında depolayın.

• Alınan veriler ML eğitimi için hazırlandıktan sonra, Synapse veri hazırlama işlem kaynaklarının çalıştırılmasına gerek kalmadan ML modeli eğitimi için kullanılabilir olması için verileri Azure Depolama'ya geri yazın.

• ML modelini kullanıma hazır hale getirmenin hem toplu hem de gerçek zamanlı puanlama desteklediğini doğrulayın.

• AIOps modelleri oluşturulduktan sonra MLOps'u uygulayın ve eğitim, operasyonelleştirme, puanlama ve sürekli geliştirme için ML yaşam döngüsünü otomatikleştirmek için DevOps uygulamaları uygulayın. AIOps ML modelleri için yinelemeli bir CI/CD işlemi oluşturun.

• Düşük yönetim ve tümleştirme ek yükü nedeniyle belirli tahmine dayalı senaryolar için Azure Bilişsel Hizmetler'i değerlendirin. Gözlemlenebilirlik veri akışlarında beklenmeyen varyansları hızla işaretlemek için Anomali Algılamayı göz önünde bulundurun.

Sonraki adım

Dağıtım ve test konusunda dikkat edilmesi gereken noktaları gözden geçirin.

Dağıtım ve test