Azure uygulamaları için hata modu analizi

Hata modu analizi (FMA), sistemdeki olası hata noktalarını belirleyerek sisteme dayanıklılık oluşturmaya yönelik bir işlemdir. FMA mimarinin ve tasarım aşamalarının bir parçası olmalıdır, böylece sistemde baştan hata kurtarma oluşturabilirsiniz.

FMA yürütmeye yönelik genel süreç aşağıdadır:

1. Sistemdeki tüm bileşenleri tanımlayın. Kimlik sağlayıcıları, üçüncü taraf hizmetleri gibi dış bağımlılıkları dahil edin.

2. Her bileşen için oluşabilecek olası hataları belirleyin. Tek bir bileşenin birden fazla hata modu olabilir. Örneğin, etki ve olası risk azaltma adımları farklı olacağı için okuma hatalarını ve yazma hatalarını ayrı ayrı göz önünde bulundurmalısınız.

3. Her hata modunu genel riskine göre derecelendirin. Şu faktörleri göz önünde bulundurun:

   • Hata olasılığı nedir? Nispeten yaygın mı? Son derece nadir mi? Tam sayılara ihtiyacınız yoktur; amacı, önceliği sıralamaya yardımcı olmaktır.
   • Kullanılabilirlik, veri kaybı, parasal maliyet ve iş kesintisi açısından uygulama üzerindeki etkisi nedir?

4. Her hata modu için uygulamanın nasıl yanıt vereceğini ve kurtaracağını belirleyin. Maliyet ve uygulama karmaşıklığındaki dengeleri göz önünde bulundurun.

FMA işleminizin başlangıç noktası olarak, bu makalede olası hata modlarının bir kataloğu ve bunların risk azaltma adımları yer alır. Katalog teknolojiye veya Azure hizmetine göre ve uygulama düzeyinde tasarım için genel bir kategoriye göre düzenlenmiştir. Katalog kapsamlı değildir, ancak temel Azure hizmetlerinin birçoğunu kapsar.

App Service

App Service uygulaması kapatılır.

Algılama. Olası nedenler:

• Beklenen kapatma

  • Bir işleç uygulamayı kapatır; örneğin, Azure portalını kullanma.
  • Uygulama boşta olduğundan kaldırıldı. (Yalnızca ayar devre dışıysa Always On .)

• Beklenmeyen kapatma

  • Uygulama kilitleniyor.
  • App Service VM örneği kullanılamaz duruma gelir.

Application_End günlüğü, uygulama etki alanı kapatmayı (geçici işlem kilitlenmesi) yakalar ve uygulama etki alanı kapatmalarını yakalamanın tek yoludur.

Kurtarma:

• Kapatma bekleniyorsa, düzgün bir şekilde kapatmak için uygulamanın kapatma olayını kullanın. Örneğin, ASP.NET yöntemini Application_End kullanın.
• Uygulama boştayken kaldırıldıysa, sonraki istekte otomatik olarak yeniden başlatılır. Ancak, "soğuk başlangıç" maliyeti doğuracaksınız.
• Uygulamanın boştayken kaldırılmasını önlemek için web uygulamasında ayarı etkinleştirin Always On . Bkz. Azure Uygulaması Hizmetinde web uygulamalarını yapılandırma.
• Bir operatörün uygulamayı kapatmasını önlemek için düzeyli ReadOnly bir kaynak kilidi ayarlayın. Bkz. Azure Resource Manager ile kaynakları kilitleme.
• Uygulama kilitlenirse veya App Service VM kullanılamaz duruma gelirse, App Service uygulamayı otomatik olarak yeniden başlatır.

Tanılama. Uygulama günlükleri ve web sunucusu günlükleri. Bkz. Azure Uygulaması Hizmeti'nde web uygulamaları için tanılama günlüğünü etkinleştirme.

Belirli bir kullanıcı sürekli olarak hatalı isteklerde bulunur veya sistemi aşırı yükler.

Algılama. Kullanıcıların kimliğini doğrulama ve uygulama günlüklerine kullanıcı kimliği ekleme.

Kurtarma:

• Kullanıcıdan gelen istekleri kısıtlamak için Azure API Management'ı kullanın. Bkz. Azure API Management ile gelişmiş istek azaltma
• Kullanıcıyı engelleyin.

Tanılama. Tüm kimlik doğrulama isteklerini günlüğe kaydetme.

Hatalı bir güncelleştirme dağıtıldı.

Algılama. Azure portalı aracılığıyla uygulama durumunu izleyin (bkz. Azure web uygulaması performansını izleme) veya sistem durumu uç noktası izleme desenini uygulama.

Kurtarma:. Birden çok dağıtım yuvası kullanın ve bilinen son iyi dağıtıma geri dönün. Daha fazla bilgi için bkz . Temel web uygulaması.

Microsoft Entra Kimlik

OpenID Bağlan kimlik doğrulaması başarısız oluyor.

Algılama. Olası hata modları şunlardır:

1. Microsoft Entra Id kullanılamıyor veya bir ağ sorunu nedeniyle erişilemiyor. Kimlik doğrulama uç noktasına yeniden yönlendirme başarısız olur ve OpenID Bağlan ara yazılımı bir özel durum oluşturur.
2. Microsoft Entra kiracısı yok. Kimlik doğrulama uç noktasına yeniden yönlendirme bir HTTP hata kodu döndürür ve OpenID Bağlan ara yazılımı bir özel durum oluşturur.
3. Kullanıcı kimlik doğrulaması yapamıyor. Algılama stratejisi gerekli değildir; Microsoft Entra Id, oturum açma hatalarını işler.

Kurtarma:

1. Ara yazılımdan işlenmeyen özel durumları yakalayın.
2. Olayları işleme AuthenticationFailed .
3. Kullanıcıyı bir hata sayfasına yönlendirin.
4. Kullanıcı yeniden denemeleri.

Azure Search

Azure Search'e veri yazma işlemi başarısız oluyor.

Algılama. Hataları yakalayın Microsoft.Rest.Azure.CloudException .

Kurtarma:

Arama .NET SDK'sı, geçici hatalardan sonra otomatik olarak yeniden denenir. İstemci SDK'sı tarafından oluşan tüm özel durumlar geçici olmayan hatalar olarak ele alınmalıdır.

Varsayılan yeniden deneme ilkesi üstel geri alma kullanır. Farklı bir yeniden deneme ilkesi kullanmak için veya SearchServiceClient sınıfında çağrısı SetRetryPolicy yapınSearchIndexClient. Daha fazla bilgi için bkz . Otomatik Yeniden Denemeler.

Tanılama. Arama Trafik Analizi'ni kullanın.

Azure Search'ten veri okuma işlemi başarısız oluyor.

Algılama. Hataları yakalayın Microsoft.Rest.Azure.CloudException .

Kurtarma:

Arama .NET SDK'sı, geçici hatalardan sonra otomatik olarak yeniden denenir. İstemci SDK'sı tarafından oluşan tüm özel durumlar geçici olmayan hatalar olarak ele alınmalıdır.

Varsayılan yeniden deneme ilkesi üstel geri alma kullanır. Farklı bir yeniden deneme ilkesi kullanmak için veya SearchServiceClient sınıfında çağrısı SetRetryPolicy yapınSearchIndexClient. Daha fazla bilgi için bkz . Otomatik Yeniden Denemeler.

Tanılama. Arama Trafik Analizi'ni kullanın.

Cassandra

Bir düğüme okuma veya yazma işlemi başarısız oluyor.

Algılama. Özel durumu yakalayın. .NET istemcileri için bu genellikle olur System.Web.HttpException. Diğer istemcinin başka özel durum türleri olabilir. Daha fazla bilgi için bkz . Cassandra hata işleme doğru yapıldı.

Kurtarma:

• Her Cassandra istemcisinin kendi yeniden deneme ilkeleri ve özellikleri vardır. Daha fazla bilgi için bkz . Cassandra hata işleme doğru yapıldı.
• Veri düğümlerinin hata etki alanları arasında dağıtıldığı, rafa duyarlı bir dağıtım kullanın.
• Yerel çekirdek tutarlılığıyla birden çok bölgeye dağıtın. Geçici olmayan bir hata oluşursa, başka bir bölgeye yük devretme gerçekleştirin.

Tanılama. Uygulama günlükleri

Bulut Hizmeti

Web veya çalışan rolleri beklenmedik şekilde kapatılıyor.

Algılama. RoleEnvironment.Stopping olayı tetiklenir.

Kurtarma. Düzgün bir şekilde temizlemek için RoleEntryPoint.OnStop yöntemini geçersiz kılın. Daha fazla bilgi için bkz . Azure OnStop Olaylarını İşlemenin Doğru Yolu (blog).

Azure Cosmos DB

Veri okuma işlemi başarısız oluyor.

Algılama. Catch System.Net.Http.HttpRequestException veya Microsoft.Azure.Documents.DocumentClientException.

Kurtarma:

• SDK başarısız denemeleri otomatik olarak yeniden dener. Yeniden deneme sayısını ve maksimum bekleme süresini ayarlamak için yapılandırın ConnectionPolicy.RetryOptions. İstemcinin oluşturduğu özel durumlar, yeniden deneme ilkesi dışındadır veya geçici hatalar değildir.
• Azure Cosmos DB istemciyi kısıtlarsa http 429 hatası döndürür. DocumentClientException içindeki durum kodunu denetleyin. Tutarlı olarak 429 hatası alıyorsanız koleksiyonun aktarım hızı değerini artırmayı göz önünde bulundurun.
  • MongoDB API'sini kullanıyorsanız hizmet azaltma sırasında hata kodu 16500 döndürür.
• Kullanılabilirlik alanlarını destekleyen bir bölgeyle çalışırken bölge yedekliliğini etkinleştirin. Alanlar arası yedeklilik kullandığınızda Azure Cosmos DB, bir bölge kesintisi durumunda otomatik olarak yük devreder. Daha fazla bilgi için bkz . Azure Cosmos DB ile yüksek kullanılabilirlik elde edin.
• Çok bölgeli bir çözüm tasarlarsanız Azure Cosmos DB veritabanını iki veya daha fazla bölgede çoğaltın. Tüm çoğaltmalar okunabilir. İstemci SDK'larını kullanarak parametresini PreferredLocations belirtin. Bu, Azure bölgelerinin sıralı bir listesidir. Tüm okumalar listedeki kullanılabilir ilk bölgeye gönderilir. İstek başarısız olursa, istemci listedeki diğer bölgeleri sırayla dener. Daha fazla bilgi için bkz . NoSQL için Azure Cosmos DB'de genel dağıtımı ayarlama.

Tanılama. İstemci tarafındaki tüm hataları günlüğe kaydeder.

Veri yazma işlemi başarısız oluyor.

Algılama. Catch System.Net.Http.HttpRequestException veya Microsoft.Azure.Documents.DocumentClientException.

Kurtarma:

• SDK başarısız denemeleri otomatik olarak yeniden dener. Yeniden deneme sayısını ve maksimum bekleme süresini ayarlamak için yapılandırın ConnectionPolicy.RetryOptions. İstemcinin oluşturduğu özel durumlar, yeniden deneme ilkesi dışındadır veya geçici hatalar değildir.
• Azure Cosmos DB istemciyi kısıtlarsa http 429 hatası döndürür. DocumentClientException içindeki durum kodunu denetleyin. Tutarlı olarak 429 hatası alıyorsanız koleksiyonun aktarım hızı değerini artırmayı göz önünde bulundurun.
• Kullanılabilirlik alanlarını destekleyen bir bölgeyle çalışırken bölge yedekliliğini etkinleştirin. Alanlar arası yedeklilik kullandığınızda, Azure Cosmos DB tüm yazmaları kullanılabilirlik alanları arasında zaman uyumlu bir şekilde çoğaltır. Daha fazla bilgi için bkz . Azure Cosmos DB ile yüksek kullanılabilirlik elde edin.
• Çok bölgeli bir çözüm tasarlarsanız Azure Cosmos DB veritabanını iki veya daha fazla bölgede çoğaltın. Birincil bölge başarısız olursa, başka bir bölge yazılacak şekilde yükseltilecektir. Yük devretmeyi el ile de tetikleyebilirsiniz. SDK otomatik bulma ve yönlendirme yapar, bu nedenle yük devretme sonrasında uygulama kodu çalışmaya devam eder. Sdk yeni yazma bölgesini bulduğundan, yük devretme süresi boyunca (genellikle dakika), yazma işlemleri daha yüksek gecikme süresine sahip olur. Daha fazla bilgi için bkz . NoSQL için Azure Cosmos DB'de genel dağıtımı ayarlama.
• Geri dönüş olarak, belgeyi bir yedekleme kuyruğunda kalıcı hale getirip kuyruğu daha sonra işleyin.

Tanılama. İstemci tarafındaki tüm hataları günlüğe kaydeder.

Kuyruk depolama

Azure Kuyruk depolamaya ileti yazma işlemi tutarlı bir şekilde başarısız oluyor.

Algılama. N yeniden deneme denemelerinden sonra, yazma işlemi yine başarısız olur.

Kurtarma:

• Verileri yerel bir önbellekte depolayın ve daha sonra hizmet kullanılabilir olduğunda yazmaları depolama alanına iletin.
• İkincil bir kuyruk oluşturun ve birincil kuyruk kullanılamıyorsa bu kuyruğa yazın.

Tanılama. Depolama ölçümlerini kullanın.

Uygulama kuyruktan belirli bir iletiyi işleyemiyor.

Algılama. Uygulamaya özgü. Örneğin, ileti geçersiz veriler içeriyor veya iş mantığı bir nedenle başarısız oluyor.

Kurtarma:

İletiyi ayrı bir kuyruğa taşıyın. Bu kuyruktaki iletileri incelemek için ayrı bir işlem çalıştırın.

Bu amaçla teslim edilemeyen bir kuyruk işlevi sağlayan Azure Service Bus Mesajlaşma kuyruklarını kullanmayı göz önünde bulundurun.

Not

Webjobs ile Depolama kuyrukları kullanıyorsanız, Web İşleri SDK'sı yerleşik zehirli ileti işleme sağlar. Bkz. Web İşleri SDK'sı ile Azure kuyruk depolamayı kullanma.

Tanılama. Uygulama günlüğünü kullanın.

Redis için Azure Önbelleği

Önbellekten okuma başarısız oluyor.

Algılama. öğesini yakalayın StackExchange.Redis.RedisConnectionException.

Kurtarma:

1. Geçici hataları yeniden deneyin. Redis için Azure Cache yerleşik yeniden denemeyi destekler. Daha fazla bilgi için bkz. Redis için Azure Cache yeniden deneme yönergeleri.
2. Geçici olmayan hataları önbellek hatası olarak değerlendirin ve özgün veri kaynağına geri dönün.

Tanılama. Redis için Azure Cache tanılamayı kullanın.

Önbelleğe yazma işlemi başarısız oluyor.

Algılama. öğesini yakalayın StackExchange.Redis.RedisConnectionException.

Kurtarma:

1. Geçici hataları yeniden deneyin. Redis için Azure Cache yerleşik yeniden denemeyi destekler. Daha fazla bilgi için bkz. Redis için Azure Cache yeniden deneme yönergeleri.
2. Hata geçici değilse yoksayın ve diğer işlemlerin daha sonra önbelleğe yazmasına izin verin.

Tanılama. Redis için Azure Cache tanılamayı kullanın.

SQL Veritabanı

Birincil bölgedeki veritabanına bağlanılamıyor.

Algılama. Bağlan başarısız oluyor.

Kurtarma:

• Alanlar arası yedekliliği etkinleştirin. Alanlar arası yedekliliği etkinleştirerek Azure SQL Veritabanı yazma işlemlerinizi desteklenen bölgelerdeki birden çok Azure kullanılabilirlik alanına otomatik olarak çoğaltır. Daha fazla bilgi için bkz . Alanlar arası yedekli kullanılabilirlik.

• Coğrafi çoğaltmayı etkinleştirin. Çok bölgeli bir çözüm tasarlarsanız etkin coğrafi çoğaltma SQL Veritabanı etkinleştirmeyi göz önünde bulundurun.

  Önkoşul: Veritabanı etkin coğrafi çoğaltma için yapılandırılmalıdır. Bkz. Etkin Coğrafi Çoğaltma SQL Veritabanı.

  • Sorgular için ikincil çoğaltmadan okuma.
  • Eklemeler ve güncelleştirmeler için ikincil çoğaltmaya el ile yük devretme yapın. bkz. Azure SQL Veritabanı için planlı veya plansız yük devretme başlatma.

  Çoğaltma farklı bir bağlantı dizesi kullandığından uygulamanızdaki bağlantı dizesi güncelleştirmeniz gerekir.

İstemcinin bağlantı havuzundaki bağlantıları tükeniyor.

Algılama. Hataları yakalayın System.InvalidOperationException .

Kurtarma:

• İşlemi yeniden deneyin.
• Azaltma planı olarak, her kullanım örneğinin bağlantı havuzlarını yalıtarak tek kullanım örneğinin tüm bağlantılara hakim olabilmesini sağlayın.
• Maksimum bağlantı havuzu sayısını artırın.

Tanılama. Uygulama günlükleri.

Veritabanı bağlantı sınırına ulaşıldı.

Algılama. Azure SQL Veritabanı eş zamanlı çalışan, oturum açma ve oturum sayısını sınırlar. Sınırlar hizmet katmanına bağlıdır. Daha fazla bilgi için bkz. Azure SQL Veritabanı kaynak sınırları.

Bu hataları algılamak için SQL hata kodunun değerini SqlException.Number yakalayın System.Data.SqlClient.SqlException ve denetleyin. İlgili hata kodlarının listesi için bkz. SQL Veritabanı istemci uygulamaları için SQL hata kodları: Veritabanı bağlantı hatası ve diğer sorunlar.

Kurtarma. Bu hatalar geçici olarak kabul edilir, bu nedenle yeniden denemek sorunu çözebilir. Bu hatalara tutarlı bir şekilde isabet ederseniz veritabanını ölçeklendirmeyi göz önünde bulundurun.

Tanılama. - sys.event_log sorgusu başarılı veritabanı bağlantıları, bağlantı hataları ve kilitlenmeler döndürür.

• Başarısız bağlantılar için bir uyarı kuralı oluşturun.
• SQL Veritabanı denetimini etkinleştirin ve başarısız oturum açma bilgilerini denetleyin.

Service Bus Mesajlaşması

Service Bus kuyruğundan ileti okunamıyor.

Algılama. İstemci SDK'sından özel durumları yakalayın. Service Bus özel durumlarının temel sınıfı MessagingException'dır. Hata geçiciyse özelliği IsTransient true olur.

Daha fazla bilgi için bkz . Service Bus mesajlaşma özel durumları.

Kurtarma:

1. Geçici hataları yeniden deneyin. Bkz. Service Bus yeniden deneme yönergeleri.
2. Hiçbir alıcıya teslim edilemeyen iletiler, teslim edilemeyen ileti kuyruğuna yerleştirilir. Hangi iletilerin alınamadığını görmek için bu kuyruğu kullanın. Teslim edilemeyen ileti kuyruğunun otomatik temizlemesi yoktur. İletiler siz açıkça alınana kadar orada kalır. Bkz . Service Bus teslim edilemeyen ileti kuyruklarına genel bakış.

Service Bus kuyruğuna ileti yazma işlemi başarısız oluyor.

Algılama. İstemci SDK'sından özel durumları yakalayın. Service Bus özel durumlarının temel sınıfı MessagingException'dır. Hata geçiciyse özelliği IsTransient true olur.

Daha fazla bilgi için bkz . Service Bus mesajlaşma özel durumları.

Kurtarma:

• Service Bus istemcisi geçici hatalardan sonra otomatik olarak yeniden denenir. Varsayılan olarak üstel geri alma kullanır. Yeniden deneme sayısı üst sınırından veya en fazla zaman aşımı süresinden sonra istemci bir özel durum oluşturur. Daha fazla bilgi için bkz . Service Bus yeniden deneme yönergeleri.

• Kuyruk kotası aşılırsa istemci QuotaExceededException oluşturur. Özel durum iletisi daha fazla ayrıntı verir. Yeniden denemeden önce kuyruktan bazı iletileri boşaltın ve kota aşılırken devam eden yeniden denemeleri önlemek için Devre Kesici düzenini kullanmayı göz önünde bulundurun. Ayrıca BrokeredMessage.TimeToLive özelliğinin çok yüksek ayarlanmadığından emin olun.

• Bölge içinde, bölümlenmiş kuyruklar veya konular kullanılarak dayanıklılık geliştirilebilir. Bölümlenmemiş bir kuyruk veya konu başlığı bir mesajlaşma deposuna atanır. Bu mesajlaşma deposu kullanılamıyorsa, bu kuyrukta veya konudaki tüm işlemler başarısız olur. Bölümlenmiş bir kuyruk veya konu birden çok mesajlaşma deposu arasında bölümlenmiştir.

• Değişiklikleri birden çok kullanılabilirlik alanı arasında otomatik olarak çoğaltmak için bölge yedekliliğini kullanın. Bir kullanılabilirlik alanı başarısız olursa yük devretme otomatik olarak gerçekleşir. Daha fazla bilgi için bkz . Service Bus kesintilerine ve olağanüstü durumlarına karşı uygulamaları yalıtma için en iyi yöntemler.

• Çok bölgeli bir çözüm tasarlarsanız, farklı bölgelerde iki Service Bus ad alanı oluşturun ve iletileri çoğaltın. Etkin çoğaltmayı veya pasif çoğaltmayı kullanabilirsiniz.

  • Etkin çoğaltma: İstemci her iletiyi her iki kuyruğa gönderir. Alıcı her iki kuyruğu da dinler. İstemcinin yinelenen iletileri atabilmesi için iletileri benzersiz bir tanımlayıcıyla etiketleyin.
  • Pasif çoğaltma: İstemci iletiyi bir kuyruğa gönderir. Bir hata varsa, istemci diğer kuyruğa geri döner. Alıcı her iki kuyruğu da dinler. Bu yaklaşım, gönderilen yinelenen iletilerin sayısını azaltır. Ancak, alıcının yine de yinelenen iletileri işlemesi gerekir.

  Daha fazla bilgi için bkz . GeoReplication örneği ve Service Bus kesintilerine ve olağanüstü durumlarına karşı uygulamaları yalıtma için en iyi yöntemler.

yinelenen ileti.

Algılama. İletinin MessageId ve DeliveryCount özelliklerini inceleyin.

Kurtarma:

• Mümkünse, ileti işleme işlemlerinizi bir kez etkili olacak şekilde tasarlayın. Aksi takdirde, önceden işlenmiş iletilerin ileti kimliklerini depolayın ve bir iletiyi işlemeden önce kimliği denetleyin.

• True olarak ayarlanmış bir kuyruk RequiresDuplicateDetection oluşturarak yinelenen algılamayı etkinleştirin. Bu ayar sayesinde Service Bus, önceki iletiyle aynı MessageId iletiyle gönderilen tüm iletileri otomatik olarak siler. Aşağıdakileri dikkate alın:

  • Bu ayar, yinelenen iletilerin kuyruğa konulmasını engeller. Alıcının aynı iletiyi birden çok kez işlemesini engellemez.
  • Yinelenen algılamanın bir zaman penceresi vardır. Bu pencerenin ötesinde bir yineleme gönderilirse, bu algılanamaz.

Tanılama. Yinelenen iletileri günlüğe kaydetme.

Uygulama kuyruktan belirli bir iletiyi işleyemiyor.

Algılama. Uygulamaya özgü. Örneğin, ileti geçersiz veriler içeriyor veya iş mantığı bir nedenle başarısız oluyor.

Kurtarma:

Dikkate alınması gereken iki hata modu vardır.

• Alıcı hatayı algılar. Bu durumda, iletiyi teslim edilemeyen ileti kuyruğuna taşıyın. Daha sonra, teslim edilemeyen ileti kuyruğundaki iletileri incelemek için ayrı bir işlem çalıştırın.
• Alıcı, iletinin işlenmesinin ortasında başarısız olur; örneğin, işlenmeyen bir özel durum nedeniyle. Bu durumu işlemek için modu kullanın PeekLock . Bu modda, kilidin süresi dolarsa ileti diğer alıcıların kullanımına sunulur. İleti en fazla teslim sayısını veya yaşam süresini aşarsa, ileti otomatik olarak teslim edilemeyen ileti kuyruğuna taşınır.

Daha fazla bilgi için bkz . Service Bus teslim edilemeyen ileti kuyruklarına genel bakış.

Tanılama. Uygulama bir iletiyi teslim edilemeyen ileti kuyruğuna her taşırken, uygulama günlüklerine bir olay yazın.

Depolama

Azure Depolama'a veri yazma işlemi başarısız oluyor

Algılama. İstemci yazarken hata alır.

Kurtarma:

1. Geçici hatalardan kurtarmak için işlemi yeniden deneyin. İstemci SDK'sında yeniden deneme ilkesi bunu otomatik olarak işler.

2. Aşırı depolamayı önlemek için Devre Kesici düzenini uygulayın.

3. N yeniden deneme girişimleri başarısız olursa, düzgün bir geri dönüş gerçekleştirin. Örneğin:

   • Verileri yerel bir önbellekte depolayın ve daha sonra hizmet kullanılabilir olduğunda yazmaları depolama alanına iletin.
   • Yazma eylemi işlem kapsamındaysa, işlemi telafi edin.

Tanılama. Depolama ölçümlerini kullanın.

Azure Depolama'dan veri okuma işlemi başarısız oluyor.

Algılama. İstemci okurken hata alır.

Kurtarma:

1. Geçici hatalardan kurtarmak için işlemi yeniden deneyin. İstemci SDK'sında yeniden deneme ilkesi bunu otomatik olarak işler.
2. RA-GRS depolaması için birincil uç noktadan okuma başarısız olursa ikincil uç noktadan okumayı deneyin. İstemci SDK'sı bunu otomatik olarak işleyebilir. Bkz. Azure Depolama çoğaltma.
3. N yeniden deneme girişimleri başarısız olursa, düzgün bir şekilde düşürülmesi için bir geri dönüş eylemi gerçekleştirin. Örneğin, bir ürün görüntüsü depolama alanından alınamıyorsa genel bir yer tutucu görüntü gösterin.

Tanılama. Depolama ölçümlerini kullanın.

Sanal makine

Arka uç VM'sine Bağlan başarısız oluyor.

Algılama. Ağ bağlantısı hataları.

Kurtarma:

• Kullanılabilirlik kümesinde, yük dengeleyicinin arkasında en az iki arka uç VM'sini dağıtın.
• Bağlantı hatası geçiciyse, bazen TCP iletiyi göndermeyi başarıyla yeniden dener.
• Uygulamada bir yeniden deneme ilkesi uygulayın.
• Kalıcı veya geçici olmayan hatalar için Devre Kesici düzenini uygulayın.
• Çağıran VM ağ çıkış sınırını aşarsa giden kuyruk dolar. Giden kuyruğu sürekli doluysa ölçeği genişletmeyi göz önünde bulundurun.

Tanılama. Hizmet sınırlarındaki olayları günlüğe kaydedin.

VM örneği kullanılamaz duruma gelir veya iyi durumda değildir.

Algılama. VM örneğinin iyi durumda olup olmadığını belirten bir Load Balancer sistem durumu yoklaması yapılandırın. Yoklama, kritik işlevlerin doğru yanıt verip vermediğini denetlemelidir.

Kurtarma. Her uygulama katmanı için birden çok VM örneğini aynı kullanılabilirlik kümesine yerleştirin ve VM'lerin önüne bir yük dengeleyici yerleştirin. Durum yoklaması başarısız olursa Load Balancer iyi durumda olmayan örneğe yeni bağlantılar göndermeyi durdurur.

Tanılama. - Load Balancer günlük analizini kullanın.

• İzleme sisteminizi tüm sistem durumu izleme uç noktalarını izleyecek şekilde yapılandırın.

İşleç bir VM'i yanlışlıkla kapatır.

Algılama. Yok

Kurtarma. Düzeyi olan ReadOnly bir kaynak kilidi ayarlayın. Bkz. Azure Resource Manager ile kaynakları kilitleme.

Tanılama. Azure Etkinlik Günlüklerini kullanma.

Web İşleri

SCM konağı boşta olduğunda sürekli iş çalışmayı durdurur.

Algılama. Web İşi işlevine bir iptal belirteci geçirin. Daha fazla bilgi için bkz . Düzgün kapatma.

Kurtarma. Always On Web uygulamasında ayarı etkinleştirin. Daha fazla bilgi için bkz . Web İşleri ile Arka Plan görevlerini çalıştırma.

Uygulama tasarımı

Uygulama gelen isteklerdeki ani artışları işleyemez.

Algılama. Uygulamaya bağlıdır. Tipik belirtiler:

• Web sitesi HTTP 5xx hata kodlarını döndürmeye başlar.
• Veritabanı veya depolama gibi bağımlı hizmetler istekleri kısıtlamaya başlar. Hizmete bağlı olarak HTTP 429 (Çok Fazla İstek) gibi HTTP hatalarını arayın.
• HTTP kuyruğu uzunluğu artar.

Kurtarma:

• Artan yükü işlemek için ölçeği genişletme.

• Basamaklı hataların uygulamanın tamamını kesintiye uğratmasını önlemek için hataları azaltın. Azaltma stratejileri şunlardır:

  • Aşırı arka uç sistemlerini önlemek için Azaltma desenini uygulayın.
  • İstekleri arabelleğe almak ve uygun bir hızda işlemek için kuyruk tabanlı yük dengelemeyi kullanın.
  • Belirli istemcilerin önceliklerini belirleyin. Örneğin, uygulamanın ücretsiz ve ücretli katmanları varsa, ücretsiz katmandaki müşterileri kısıtlar, ancak ücretli müşterileri kısıtlamaz. Bkz. Öncelik sırası düzeni.

Tanılama. App Service tanılama günlüğünü kullanın. Tanılama günlüklerini anlamanıza yardımcı olması için Azure Log Analytics, Application Analizler veya New Relic gibi bir hizmet kullanın.

Burada bir örnek verilmiştir. Bu özel durumlar için Polly kullanır:

• 429 - Azaltma
• 408 - Zaman Aşımı
• 401 - Yetki Yok
• 503 veya 5xx - Hizmet kullanılamıyor

bir iş akışındaki veya dağıtılmış işlemdeki işlemlerden biri başarısız olur.

Algılama. N yeniden deneme denemelerinden sonra da başarısız olur.

Kurtarma:

• Bir risk azaltma planı olarak, iş akışının tamamını yönetmek için Zamanlayıcı Aracısı Gözetmeni desenini uygulayın.
• Zaman aşımlarını yeniden denemeyin. Bu hata için düşük bir başarı oranı vardır.
• Daha sonra yeniden denemek için kuyruk çalışması.

Tanılama. Telafi eylemleri de dahil olmak üzere tüm işlemleri günlüğe kaydetme (başarılı ve başarısız). Aynı işlemdeki tüm işlemleri izleyebilebilmeniz için bağıntı kimliklerini kullanın.

Uzak hizmete yapılan çağrı başarısız oluyor.

Algılama. HTTP hata kodu.

Kurtarma:

1. Geçici hataları yeniden deneyin.
2. N denemelerinden sonra çağrı başarısız olursa bir geri dönüş eylemi gerçekleştirin. (Uygulamaya özgü.)
3. Basamaklı hataları önlemek için Devre Kesici düzenini uygulayın.

Tanılama. Tüm uzak arama hatalarını günlüğe kaydetme.

Sonraki adımlar

Bkz . Azure İyi Tasarlanmış Çerçeve'de dayanıklılık ve bağımlılıklar . Hata riskini önlemek için sisteme hata kurtarmanın oluşturulması, mimarinin ve tasarım aşamalarının başından itibaren bir parçası olmalıdır.