Analýza režimu selhání pro aplikace Azure

Analýza režimu selhání (FMA) je proces pro vytvoření odolnosti systému tím, že identifikuje možné body selhání v systému. FMA by měla být součástí fází architektury a návrhu, takže od začátku můžete do systému zabudovat zotavení po selhání.

Tady je obecný postup provedení FMA:

1. Identifikujte všechny komponenty v systému. Zahrňte externí závislosti, jako jsou zprostředkovatelé identity, služby třetích stran atd.

2. Pro každou komponentu identifikujte potenciální selhání, ke kterým může dojít. Jedna komponenta může mít více než jeden režim selhání. Měli byste například zvážit selhání čtení a selhání zápisu samostatně, protože dopad a možné kroky pro zmírnění rizik se budou lišit.

3. Ohodnoťte jednotlivé režimy selhání podle celkového rizika. Zvažte tyto faktory:

   • Jaká je pravděpodobnost selhání. Je to relativně běžné? Velmi vzácné? Nepotřebujete přesná čísla. účelem je pomoct seřadit prioritu.
   • Jaký je dopad na aplikaci z hlediska dostupnosti, ztráty dat, peněžních nákladů a přerušení podnikání?

4. U každého režimu selhání určete, jak bude aplikace reagovat a obnovit. Zvažte kompromisy v nákladech a složitosti aplikací.

Jako výchozí bod pro váš proces FMA obsahuje tento článek katalog potenciálních režimů selhání a jejich kroků pro zmírnění rizik. Katalog je uspořádaný podle technologií nebo služby Azure a obecné kategorie pro návrh na úrovni aplikace. Katalog není vyčerpávající, ale pokrývá mnoho základních služeb Azure.

App Service

Aplikace App Service se vypne.

Detekce. Možné příčiny:

• Očekávané vypnutí

  • Operátor vypne aplikaci; Například pomocí webu Azure Portal.
  • Aplikace byla uvolněna, protože byla nečinná. (Pouze pokud Always On je nastavení zakázané.)

• Neočekávané vypnutí

  • Aplikace se chybově ukončí.
  • Instance virtuálního počítače služby App Service přestane být k dispozici.

Application_End protokolování zachytí vypnutí domény aplikace (chybové ukončení softwarového procesu) a je jediným způsobem, jak zachytit vypnutí domény aplikace.

Obnovení:

• Pokud se očekávalo vypnutí, pomocí události vypnutí aplikace řádně vypněte. Například v ASP.NET použijte metodu Application_End .
• Pokud byla aplikace uvolněna během nečinnosti, automaticky se restartuje při dalším požadavku. Budou se vám ale účtují náklady na "studený start".
• Pokud chcete zabránit uvolnění aplikace během nečinnosti, povolte Always On nastavení ve webové aplikaci. Viz Konfigurace webových aplikací ve službě Aplikace Azure Service.
• Pokud chcete zabránit operátoru v vypnutí aplikace, nastavte zámek prostředku s ReadOnly úrovní. Viz Uzamčení prostředků pomocí Azure Resource Manageru.
• Pokud dojde k chybovému ukončení aplikace nebo se virtuální počítač služby App Service stane nedostupným, služba App Service aplikaci automaticky restartuje.

Diagnostika: Protokoly aplikací a protokoly webového serveru. Viz Povolení protokolování diagnostiky pro webové aplikace ve službě Aplikace Azure Service.

Konkrétní uživatel opakovaně provádí chybné požadavky nebo přetěžuje systém.

Detekce. Ověřte uživatele a zahrňte ID uživatele do protokolů aplikací.

Obnovení:

• Pomocí služby Azure API Management omezte požadavky od uživatele. Zobrazení rozšířeného omezování požadavků pomocí služby Azure API Management
• Zablokujte uživatele.

Diagnostika: Protokolujte všechny žádosti o ověření.

Byla nasazena chybná aktualizace.

Detekce. Sledujte stav aplikace prostřednictvím webu Azure Portal (viz Monitorování výkonu webové aplikace Azure) nebo implementujte model monitorování koncových bodů stavu.

Obnovení:. Použijte více slotů nasazení a vraťte se k poslednímu známému dobrému nasazení. Další informace naleznete v tématu Základní webová aplikace.

Microsoft Entra ID

OpenID Připojení ověřování selže.

Detekce. Mezi možné režimy selhání patří:

1. ID Microsoft Entra není k dispozici nebo není dosaženo kvůli problému se sítí. Přesměrování na koncový bod ověřování selže a middleware OpenID Připojení vyvolá výjimku.
2. Tenant Microsoft Entra neexistuje. Přesměrování na koncový bod ověřování vrátí kód chyby HTTP a middleware OpenID Připojení vyvolá výjimku.
3. Uživatel se nemůže ověřit. Není nutná žádná strategie detekce; ID Microsoft Entra zpracovává selhání přihlášení.

Obnovení:

1. Zachyťte neošetřené výjimky z middlewaru.
2. Zpracování AuthenticationFailed událostí
3. Přesměrujte uživatele na chybovou stránku.
4. Uživatel opakuje pokusy.

Azure Search

Zápis dat do služby Azure Search selže.

Detekce. Zachyťte Microsoft.Rest.Azure.CloudException chyby.

Obnovení:

Sada Search .NET SDK se po přechodných selháních automaticky opakuje. Všechny výjimky vyvolané klientskou sadou SDK by se měly považovat za nepřehledné chyby.

Výchozí zásada opakování používá exponenciální zpětné vypnutí. Pokud chcete použít jinou zásadu opakování, zavolejte SetRetryPolicy metodu SearchIndexClient nebo SearchServiceClient třídu. Další informace naleznete v tématu Automatické opakování.

Diagnostika: Použijte analýzu provozu vyhledávání.

Čtení dat ze služby Azure Search selže.

Detekce. Zachyťte Microsoft.Rest.Azure.CloudException chyby.

Obnovení:

Sada Search .NET SDK se po přechodných selháních automaticky opakuje. Všechny výjimky vyvolané klientskou sadou SDK by se měly považovat za nepřehledné chyby.

Výchozí zásada opakování používá exponenciální zpětné vypnutí. Pokud chcete použít jinou zásadu opakování, zavolejte SetRetryPolicy metodu SearchIndexClient nebo SearchServiceClient třídu. Další informace naleznete v tématu Automatické opakování.

Diagnostika: Použijte analýzu provozu vyhledávání.

Cassandra

Čtení nebo zápis do uzlu selže.

Detekce. Zachyťte výjimku. Pro klienty .NET to obvykle bude System.Web.HttpException. Jiný klient může mít jiné typy výjimek. Další informace najdete v tématu Zpracování chyb Cassandra správně.

Obnovení:

• Každý klient Cassandra má vlastní zásady opakování a možnosti. Další informace najdete v tématu Zpracování chyb Cassandra správně.
• Použití nasazení s podporou racku s datovými uzly distribuovanými napříč doménami selhání.
• Nasazení do více oblastí s konzistencí místního kvora Pokud dojde k nepřehledné chybě, převzetí služeb při selhání do jiné oblasti.

Diagnostika: Protokoly aplikací

Cloudová služba

Webové role nebo role pracovního procesu se neočekávaně vypínají.

Detekce. Aktivuje se událost RoleEnvironment.Stopping .

Obnovení. Přepište Metodu RoleEntryPoint.OnStop pro řádné vyčištění. Další informace najdete v tématu Správný způsob zpracování událostí Azure OnStop (blog).

Azure Cosmos DB

Čtení dat selže.

Detekce. Zachytávání System.Net.Http.HttpRequestException nebo Microsoft.Azure.Documents.DocumentClientException.

Obnovení:

• Sada SDK automaticky opakuje neúspěšné pokusy. Chcete-li nastavit počet opakování a maximální dobu čekání, nakonfigurujte ConnectionPolicy.RetryOptions. Výjimky vyvolané klientem jsou nad rámec zásad opakování nebo to nejsou přechodné chyby.
• Pokud Azure Cosmos DB omezí klienta, vrátí chybu HTTP 429. Zkontrolujte stavový kód v DocumentClientException. Pokud dochází k chybě 429 konzistentně, zvažte zvýšení hodnoty propustnosti kolekce.
  • Pokud používáte rozhraní MongoDB API, vrátí služba kód chyby 16500 při omezování.
• Povolte redundanci zón při práci s oblastí, která podporuje zóny dostupnosti. Když použijete redundanci zóny, Azure Cosmos DB automaticky převezme služby při selhání v případě výpadku zóny. Další informace najdete v tématu Dosažení vysoké dostupnosti se službou Azure Cosmos DB.
• Pokud navrhujete řešení pro více oblastí, replikujte databázi Azure Cosmos DB do dvou nebo více oblastí. Všechny repliky jsou čitelné. Pomocí klientských sad SDK zadejte PreferredLocations parametr. Toto je uspořádaný seznam oblastí Azure. Všechna čtení se odešlou do první dostupné oblasti v seznamu. Pokud požadavek selže, klient vyzkouší ostatní oblasti v seznamu v pořadí. Další informace najdete v tématu Nastavení globální distribuce ve službě Azure Cosmos DB for NoSQL.

Diagnostika: Protokolujte všechny chyby na straně klienta.

Zápis dat selže.

Detekce. Zachytávání System.Net.Http.HttpRequestException nebo Microsoft.Azure.Documents.DocumentClientException.

Obnovení:

• Sada SDK automaticky opakuje neúspěšné pokusy. Chcete-li nastavit počet opakování a maximální dobu čekání, nakonfigurujte ConnectionPolicy.RetryOptions. Výjimky vyvolané klientem jsou nad rámec zásad opakování nebo to nejsou přechodné chyby.
• Pokud Azure Cosmos DB omezí klienta, vrátí chybu HTTP 429. Zkontrolujte stavový kód v DocumentClientException. Pokud dochází k chybě 429 konzistentně, zvažte zvýšení hodnoty propustnosti kolekce.
• Povolte redundanci zón při práci s oblastí, která podporuje zóny dostupnosti. Když používáte redundanci zón, Azure Cosmos DB synchronně replikuje všechny zápisy napříč zónami dostupnosti. Další informace najdete v tématu Dosažení vysoké dostupnosti se službou Azure Cosmos DB.
• Pokud navrhujete řešení pro více oblastí, replikujte databázi Azure Cosmos DB do dvou nebo více oblastí. Pokud primární oblast selže, upřednostní se pro zápis jinou oblast. Převzetí služeb při selhání můžete aktivovat také ručně. Sada SDK provede automatické zjišťování a směrování, takže kód aplikace bude fungovat i po převzetí služeb při selhání. Během období převzetí služeb při selhání (obvykle minut) budou operace zápisu mít vyšší latenci, protože sada SDK najde novou oblast zápisu. Další informace najdete v tématu Nastavení globální distribuce ve službě Azure Cosmos DB for NoSQL.
• Jako záložní zálohu zachovají dokument do záložní fronty a později frontu zpracuje.

Diagnostika: Protokolujte všechny chyby na straně klienta.

Queue Storage

Zápis zprávy do azure Queue Storage konzistentně selže.

Detekce. Po pokusech o opakování N operace zápisu stále selže.

Obnovení:

• Uložte data do místní mezipaměti a předejte zápisy do úložiště později, až bude služba dostupná.
• Vytvořte sekundární frontu a zapište ji do této fronty, pokud primární fronta není k dispozici.

Diagnostika: Použijte metriky úložiště.

Aplikace nemůže zpracovat konkrétní zprávu z fronty.

Detekce. Specifické pro aplikaci. Zpráva například obsahuje neplatná data nebo obchodní logika z nějakého důvodu selže.

Obnovení:

Přesuňte zprávu do samostatné fronty. Spuštěním samostatného procesu zkontrolujte zprávy v této frontě.

Zvažte použití front zasílání zpráv služby Azure Service Bus, které pro tento účel poskytují funkci fronty nedoručených zpráv.

Poznámka:

Pokud používáte fronty služby Storage s webovými úlohami, sada WebJobs SDK poskytuje integrované zpracování otrávených zpráv. Přečtěte si , jak používat Azure Queue Storage se sadou WebJobs SDK.

Diagnostika: Použijte protokolování aplikace.

Azure Cache for Redis

Čtení z mezipaměti selže.

Detekce. Chytit StackExchange.Redis.RedisConnectionException.

Obnovení:

1. Zkuste to znovu u přechodných selhání. Azure Cache for Redis podporuje integrované opakování. Další informace najdete v pokynech k opakování služby Azure Cache for Redis.
2. Zacházejte s nepřehlednou chybou jako s chybou mezipaměti a vraťte se k původnímu zdroji dat.

Diagnostika: Použijte diagnostiku Azure Cache for Redis.

Zápis do mezipaměti selže.

Detekce. Chytit StackExchange.Redis.RedisConnectionException.

Obnovení:

1. Zkuste to znovu u přechodných selhání. Azure Cache for Redis podporuje integrované opakování. Další informace najdete v pokynech k opakování služby Azure Cache for Redis.
2. Pokud je chyba nepřehledná, ignorujte ji a nechte ostatní transakce zapisovat do mezipaměti později.

Diagnostika: Použijte diagnostiku Azure Cache for Redis.

SQL Database

Nelze se připojit k databázi v primární oblasti.

Detekce. Připojení ion selže.

Obnovení:

• Povolte redundanci zón. Díky povolení redundance zón azure SQL Database automaticky replikuje vaše zápisy napříč několika zónami dostupnosti Azure v rámci podporovaných oblastí. Další informace najdete v tématu Zónově redundantní dostupnost.

• Povolte geografickou replikaci. Pokud navrhujete řešení pro více oblastí, zvažte povolení aktivní geografické replikace služby SQL Database.

  Předpoklad: Databáze musí být nakonfigurovaná pro aktivní geografickou replikaci. Viz Aktivní geografická replikace služby SQL Database.

  • U dotazů se načítá ze sekundární repliky.
  • Pro vložení a aktualizace ručně převezme služby při selhání sekundární repliky. Viz Zahájení plánovaného nebo neplánovaného převzetí služeb při selhání pro Azure SQL Database.

  Replika používá jiný připojovací řetězec, takže budete muset aktualizovat připojovací řetězec ve vaší aplikaci.

Klient vyčerpá připojení ve fondu připojení.

Detekce. Zachyťte System.InvalidOperationException chyby.

Obnovení:

• Zkuste operaci zopakovat.
• Jako plán pro zmírnění rizik izolujte fondy připojení pro každý případ použití, aby jeden případ použití nemohl dominovat všem připojením.
• Zvyšte maximální počet fondů připojení.

Diagnostika: Protokoly aplikací

Bylo dosaženo limitu připojení k databázi.

Detekce. Azure SQL Database omezuje počet souběžných pracovních procesů, přihlášení a relací. Omezení závisí na úrovni služby. Další informace najdete v tématu Omezení prostředků služby Azure SQL Database.

Pokud chcete tyto chyby rozpoznat, zachyťte System.Data.SqlClient.SqlException a zkontrolujte hodnotu SqlException.Number kódu chyby SQL. Seznam příslušných kódů chyb najdete v tématu Kódy chyb SQL pro klientské aplikace SQL Database: Chyba připojení k databázi a další problémy.

Obnovení. Tyto chyby jsou považovány za přechodné, takže opakování může problém vyřešit. Pokud tyto chyby konzistentně dosáhnete, zvažte škálování databáze.

Diagnostika: – Dotaz sys.event_log vrátí úspěšná připojení k databázi, selhání připojení a zablokování.

• Vytvořte pravidlo upozornění pro neúspěšná připojení.
• Povolte auditování služby SQL Database a zkontrolujte neúspěšná přihlášení.

Service Bus Messaging

Čtení zprávy z fronty služby Service Bus selže.

Detekce. Zachyťte výjimky z klientské sady SDK. Základní třída výjimek služby Service Bus je MessagingException. Pokud je chyba přechodná, IsTransient je vlastnost pravdivá.

Další informace najdete v tématu Výjimky zasílání zpráv služby Service Bus.

Obnovení:

1. Zkuste to znovu u přechodných selhání. Viz pokyny pro opakování služby Service Bus.
2. Zprávy, které nelze doručit do žádného příjemce, jsou umístěny do fronty nedoručených zpráv. Pomocí této fronty můžete zjistit, které zprávy nelze přijímat. Fronta nedoručených zpráv neobsahuje automatické vyčištění. Zprávy zůstanou tam, dokud je explicitně nenačtete. Viz Přehled front s nedoručenou zprávou služby Service Bus.

Zápis zprávy do fronty služby Service Bus selže.

Detekce. Zachyťte výjimky z klientské sady SDK. Základní třída výjimek služby Service Bus je MessagingException. Pokud je chyba přechodná, IsTransient je vlastnost pravdivá.

Další informace najdete v tématu Výjimky zasílání zpráv služby Service Bus.

Obnovení:

• Klient služby Service Bus se po přechodných chybách automaticky opakuje. Ve výchozím nastavení používá exponenciální zpětné vypnutí. Po uplynutí maximálního počtu opakování nebo maximálního časového limitu klient vyvolá výjimku. Další informace najdete v tématu Pokyny pro opakování služby Service Bus.

• Pokud dojde k překročení kvóty fronty, klient vyvolá výjimku QuotaExceededException. Zpráva o výjimce poskytuje další podrobnosti. Před opakováním vyprázdněte některé zprávy z fronty a zvažte použití vzoru Jistič, abyste se vyhnuli dalším opakovaným pokusům při překročení kvóty. Také se ujistěte, že BrokeredMessage.TimeToLive vlastnost není nastavena příliš vysoká.

• V rámci oblasti je možné zlepšit odolnost pomocí dělených front nebo témat. K jednomu úložišti pro zasílání zpráv je přiřazena nedělaná fronta nebo téma. Pokud toto úložiště zpráv není k dispozici, všechny operace v této frontě nebo tématu selžou. Dělená fronta nebo téma je rozdělena do více úložišť zpráv.

• Pomocí redundance zón můžete automaticky replikovat změny mezi několika zónami dostupnosti. Pokud jedna zóna dostupnosti selže, převzetí služeb při selhání proběhne automaticky. Další informace najdete v tématu Osvědčené postupy pro izolaci aplikací před výpadky a haváriemi služby Service Bus.

• Pokud navrhujete řešení pro více oblastí, vytvořte dva obory názvů služby Service Bus v různých oblastech a replikujte zprávy. Můžete použít aktivní replikaci nebo pasivní replikaci.

  • Aktivní replikace: Klient odešle každou zprávu do obou front. Příjemce naslouchá v obou frontách. Označte zprávy jedinečným identifikátorem, aby klient mohl zahodit duplicitní zprávy.
  • Pasivní replikace: Klient odešle zprávu do jedné fronty. Pokud dojde k chybě, klient se vrátí do druhé fronty. Příjemce naslouchá v obou frontách. Tento přístup snižuje počet odeslaných duplicitních zpráv. Příjemce ale musí stále zpracovávat duplicitní zprávy.

  Další informace najdete v ukázce GeoReplication a osvědčených postupech pro izolaci aplikací před výpadky a haváriemi služby Service Bus.

Duplicitní zpráva

Detekce. MessageId Prozkoumejte vlastnosti zprávy a DeliveryCount vlastnosti zprávy.

Obnovení:

• Pokud je to možné, navrhněte operace zpracování zpráv tak, aby byly idempotentní. V opačném případě uložte ID zpráv o již zpracovaných zprávách a před zpracováním zprávy zkontrolujte ID.

• Povolte detekci duplicit vytvořením fronty s RequiresDuplicateDetection nastavenou na true. Díky tomuto nastavení Service Bus automaticky odstraní všechny zprávy odeslané se stejnou MessageId zprávou jako předchozí zpráva. Je potřeba upozornit na následující:

  • Toto nastavení zabraňuje vložení duplicitních zpráv do fronty. Nezabrání příjemci ve zpracování stejné zprávy více než jednou.
  • Zjišťování duplicit má časové okno. Pokud se duplikát odešle za tímto oknem, nezjistí se.

Diagnostika: Protokolování duplicitních zpráv

Aplikace nemůže zpracovat konkrétní zprávu z fronty.

Detekce. Specifické pro aplikaci. Zpráva například obsahuje neplatná data nebo obchodní logika z nějakého důvodu selže.

Obnovení:

Existují dva režimy selhání, které je potřeba zvážit.

• Příjemce zjistí selhání. V tomto případě přesuňte zprávu do fronty nedoručených zpráv. Později spusťte samostatný proces pro zkoumání zpráv ve frontě nedoručených zpráv.
• Příjemce uprostřed zpracování zprávy selže – například kvůli neošetřené výjimce. Pokud chcete tento případ zpracovat, použijte PeekLock režim. Pokud zámek vyprší, v tomto režimu se zpráva zpřístupní ostatním příjemcům. Pokud zpráva překročí maximální počet doručení nebo časový limit, zpráva se automaticky přesune do fronty nedoručených zpráv.

Další informace najdete v tématu Přehled front nedoručených zpráv služby Service Bus.

Diagnostika: Pokaždé, když aplikace přesune zprávu do fronty nedoručených zpráv, napište do protokolů aplikace událost.

Úložiště

Zápis dat do služby Azure Storage selže

Detekce. Klient při zápisu obdrží chyby.

Obnovení:

1. Zkuste operaci zopakovat, abyste se zotavili z přechodných selhání. Zásady opakování v klientské sadě SDK to zpracovávají automaticky.

2. Implementujte model Jistič, abyste se vyhnuli zahlcení úložiště.

3. Pokud pokusy o opakování N selžou, proveďte elegantní náhradní akci. Příklad:

   • Uložte data do místní mezipaměti a předejte zápisy do úložiště později, až bude služba dostupná.
   • Pokud byla akce zápisu v transakčním rozsahu, kompenzace transakce.

Diagnostika: Použijte metriky úložiště.

Čtení dat ze služby Azure Storage selže.

Detekce. Klient při čtení obdrží chyby.

Obnovení:

1. Zkuste operaci zopakovat, abyste se zotavili z přechodných selhání. Zásady opakování v klientské sadě SDK to zpracovávají automaticky.
2. Pokud u úložiště RA-GRS selže čtení z primárního koncového bodu, zkuste číst ze sekundárního koncového bodu. Klientská sada SDK to zvládne automaticky. Viz replikace Azure Storage.
3. Pokud pokusy o opakování N selžou, proveďte akci pro použití náhradní lokality, abyste mohli řádně snížit výkon. Pokud se například obrázek produktu nedá načíst z úložiště, zobrazí se obecný zástupný obrázek.

Diagnostika: Použijte metriky úložiště.

Virtuální počítač

Připojení na back-endový virtuální počítač selže.

Detekce. Chyby síťového připojení.

Obnovení:

• Nasaďte alespoň dva back-endové virtuální počítače ve skupině dostupnosti za nástrojem pro vyrovnávání zatížení.
• Pokud je chyba připojení přechodná, někdy se tcp úspěšně pokusí zprávu odeslat znovu.
• Implementujte zásadu opakování v aplikaci.
• U trvalých nebo nepřerušných chyb implementujte model Jistič .
• Pokud volající virtuální počítač překročí limit odchozího přenosu dat sítě, zaplní se odchozí fronta. Pokud je odchozí fronta konzistentně plná, zvažte horizontální navýšení kapacity.

Diagnostika: Protokolování událostí na hranicích mezi službami.

Instance virtuálního počítače přestane být dostupná nebo není v pořádku.

Detekce. Nakonfigurujte sondu stavu Load Balanceru, která signalizuje, jestli je instance virtuálního počítače v pořádku. Sonda by měla zkontrolovat, jestli kritické funkce správně reagují.

Obnovení. Pro každou aplikační vrstvu vložte více instancí virtuálních počítačů do stejné skupiny dostupnosti a umístěte nástroj pro vyrovnávání zatížení před virtuální počítače. Pokud sonda stavu selže, Load Balancer přestane odesílat nová připojení k instanci, která není v pořádku.

Diagnostika: – Použijte Log Analytics Load Balanceru.

• Nakonfigurujte monitorovací systém tak, aby monitorovali všechny koncové body monitorování stavu.

Operátor omylem vypne virtuální počítač.

Detekce. –

Obnovení. Nastavte zámek prostředku s ReadOnly úrovní. Viz Uzamčení prostředků pomocí Azure Resource Manageru.

Diagnostika: Použijte protokoly aktivit Azure.

WebJobs

Průběžná úloha přestane běžet, když je hostitel SCM nečinný.

Detekce. Předání tokenu zrušení do funkce WebJob. Další informace najdete v tématu Řádné vypnutí.

Obnovení. Always On Povolte nastavení ve webové aplikaci. Další informace najdete v tématu Spouštění úloh na pozadí pomocí webových úloh.

Návrh aplikací

Aplikace nemůže zpracovat špičku příchozích požadavků.

Detekce. Závisí na aplikaci. Typické příznaky:

• Web začne vracet kódy chyb HTTP 5xx.
• Závislé služby, jako je databáze nebo úložiště, začnou omezovat požadavky. V závislosti na službě vyhledejte chyby HTTP, jako je HTTP 429 (Příliš mnoho požadavků).
• Délka fronty HTTP roste.

Obnovení:

• Horizontální navýšení kapacity pro zpracování zvýšené zátěže

• Zmírnění selhání, aby nedocházelo k kaskádové selhání, narušují celou aplikaci. Mezi strategie zmírnění rizik patří:

  • Implementujte model omezování, abyste se vyhnuli zahlcení back-endových systémů.
  • Pomocí vyrovnávání zatížení založeného na frontě můžete požadavky ukládat do vyrovnávací paměti a zpracovávat je odpovídajícím tempem.
  • Určete prioritu určitých klientů. Pokud má aplikace například bezplatné a placené úrovně, omezte zákazníky na úrovni Free, ale ne placené zákazníky. Viz Vzor prioritní fronty.

Diagnostika: Použijte protokolování diagnostiky služby App Service. K pochopení diagnostických protokolů použijte službu, jako je Azure Log Analytics, application Přehledy nebo New Relic.

Tady je k dispozici ukázka. Používá Polly pro tyto výjimky:

• 429 – Omezování
• 408 – Časový limit
• 401 – Neautorizováno
• 503 nebo 5xx – Služba není k dispozici

Jedna z operací v pracovním postupu nebo distribuované transakci selže.

Detekce. Po pokusech o opakování N se stále nezdaří.

Obnovení:

• Jako plán zmírnění rizik implementujte model Scheduler Agent Supervisor pro správu celého pracovního postupu.
• Neprovádějte opakování časových limitů. U této chyby existuje nízká míra úspěšnosti.
• Fronta funguje, abyste to mohli zopakovat později.

Diagnostika: Protokolovat všechny operace (úspěšné a neúspěšné), včetně kompenzačních akcí. Použijte ID korelace, abyste mohli sledovat všechny operace ve stejné transakci.

Volání vzdálené služby selže.

Detekce. Kód chyby HTTP.

Obnovení:

1. Zkuste to znovu u přechodných selhání.
2. Pokud volání selže po N pokusech, proveďte akci pro použití náhradní lokality. (Specifické pro aplikaci.)
3. Implementujte model Jistič, abyste se vyhnuli kaskádovaným chybám.

Diagnostika: Protokolovat všechna selhání vzdáleného volání

Další kroky

Viz odolnost a závislosti v architektuře Azure Well-Architected Framework. Sestavení zotavení po selhání do systému by mělo být součástí fází architektury a návrhu od začátku, aby se zabránilo riziku selhání.