Hibamód elemzése Azure-alkalmazásokhoz

  • Cikk

A hibamód-elemzés (FMA) a rendszer rugalmasságának kiépítésére szolgáló folyamat a rendszer lehetséges meghibásodási pontjainak azonosításával. Az FMA-nak az architektúra és a tervezési fázisok részét kell képeznie, hogy a rendszer a kezdetektől építhesse a hibahelyreállítást.

Az FMA elvégzésének általános folyamata a következő:

  1. Azonosítsa a rendszer összes összetevőjét. Külső függőségeket is tartalmazhat, például identitásszolgáltatókat, külső szolgáltatásokat stb.

  2. Minden egyes összetevő esetében azonosítsa a lehetséges hibákat, amelyek előfordulhatnak. Egyetlen összetevő több meghibásodási móddal is rendelkezhet. Érdemes lehet például külön megfontolni az olvasási és írási hibákat, mert a hatás és a lehetséges kockázatcsökkentési lépések eltérőek lesznek.

  3. Értékelje az egyes meghibásodási módokat az általános kockázatnak megfelelően. Vegye figyelembe az alábbi tényezőket:

    • Mi a hiba valószínűsége. Viszonylag gyakori? Rendkívül ritka? Nincs szükség pontos számokra; a cél az, hogy segítsen rangsorolni a prioritást.
    • Milyen hatással van az alkalmazásra a rendelkezésre állás, az adatvesztés, a pénzügyi költségek és az üzleti zavarok szempontjából?

  4. Az egyes hibamódok esetében határozza meg, hogy az alkalmazás hogyan reagál majd és hogyan fog helyreállni. Fontolja meg a költség- és alkalmazásbonyolultság kompromisszumoit.

Az FMA-folyamat kiindulópontjaként ez a cikk egy katalógust tartalmaz a lehetséges meghibásodási módokról és azok megoldási lépéseiről. A katalógus technológia vagy Azure-szolgáltatás szerint van rendszerezve, valamint egy általános kategória az alkalmazásszintű tervezéshez. A katalógus nem teljes, de számos alapvető Azure-szolgáltatást lefed.

App Service

Az App Service-alkalmazás leáll.

Észlelés. Lehetséges okok:

  • Várható leállítás

    • Egy operátor leállítja az alkalmazást; például az Azure Portal használatával.
    • Az alkalmazás ki lett ürítve, mert tétlen volt. (Csak akkor, ha a Always On beállítás le van tiltva.)

  • Váratlan leállítás

    • Az alkalmazás összeomlik.
    • Egy App Service virtuálisgép-példány elérhetetlenné válik.

Application_End naplózás az alkalmazástartomány leállását (helyreállítható folyamat összeomlását) fogja észlelni, és ez az egyetlen módja az alkalmazástartomány leállásának.

Helyreállítási:

  • Ha a leállítás várható volt, használja az alkalmazás leállítási eseményét a kecses leállításhoz. Például a ASP.NET használja a metódust Application_End .
  • Ha az alkalmazás inaktív állapotban lett kiürítve, a rendszer automatikusan újraindul a következő kérelemben. A "hidegindítás" költsége azonban felmerül.
  • Ha meg szeretné akadályozni, hogy az alkalmazás inaktív állapotban legyen, engedélyezze a Always On beállítást a webalkalmazásban. Lásd: Webalkalmazások konfigurálása Azure-alkalmazás Szolgáltatásban.
  • Ha meg szeretné akadályozni, hogy egy operátor leállítsa az alkalmazást, állítson be egy erőforrás-zárolást szinttel ReadOnly . Lásd: Erőforrások zárolása az Azure Resource Managerrel.
  • Ha az alkalmazás összeomlik, vagy egy App Service virtuális gép elérhetetlenné válik, az App Service automatikusan újraindítja az alkalmazást.

Diagnosztika. Alkalmazásnaplók és webkiszolgáló-naplók. Lásd: Diagnosztikai naplózás engedélyezése webalkalmazásokhoz a Azure-alkalmazás Szolgáltatásban.

Egy adott felhasználó ismételten hibás kéréseket küld, vagy túlterheli a rendszert.

Észlelés. Felhasználók hitelesítése és felhasználói azonosító felvétele az alkalmazásnaplókba.

Helyreállítási:

Diagnosztika. Naplózza az összes hitelesítési kérést.

Rossz frissítés lett üzembe helyezve.

Észlelés. Az alkalmazás állapotának monitorozása az Azure Portalon (lásd az Azure-webalkalmazás teljesítményének monitorozását) vagy az állapotvégpont monitorozási mintájának implementálása.

Helyreállítás:. Használjon több üzembehelyezési pontot , és térjen vissza az utolsó ismert üzembe helyezéshez. További információ: Alapszintű webalkalmazás.

Microsoft Entra ID

Az OpenID Csatlakozás hitelesítés sikertelen.

Észlelés. A lehetséges hibamódok a következők:

  1. A Microsoft Entra-azonosító nem érhető el, vagy hálózati probléma miatt nem érhető el. A hitelesítési végpontra való átirányítás sikertelen, és az OpenID Csatlakozás köztes szoftver kivételt eredményez.
  2. A Microsoft Entra-bérlő nem létezik. A hitelesítési végpontra való átirányítás HTTP-hibakódot ad vissza, és az OpenID Csatlakozás köztes szoftver kivételt okoz.
  3. A felhasználó nem tud hitelesíteni. Nincs szükség észlelési stratégiára; A Microsoft Entra ID kezeli a bejelentkezési hibákat.

Helyreállítási:

  1. A köztes szoftver nem kezelt kivételeinek észlelése.
  2. Események kezelése AuthenticationFailed .
  3. Átirányítja a felhasználót egy hibalapra.
  4. A felhasználó újrapróbálkozik.

Nem sikerül adatokat írni az Azure Searchbe.

Észlelés. Fogási Microsoft.Rest.Azure.CloudException hibák.

Helyreállítási:

A Search .NET SDK automatikusan újrapróbálkozott az átmeneti hibák után. Az ügyfél SDK által bevezetett kivételeket nem átmeneti hibákként kell kezelni.

Az alapértelmezett újrapróbálkozási szabályzat exponenciális visszalépést használ. Egy másik újrapróbálkozési szabályzat használatához hívja meg SetRetryPolicy az osztályt vagy SearchServiceClient az osztálytSearchIndexClient. További információ: Automatikus újrapróbálkozás.

Diagnosztika. Használja a Search Traffic Analytics szolgáltatást.

Az Azure Search adatainak beolvasása sikertelen.

Észlelés. Fogási Microsoft.Rest.Azure.CloudException hibák.

Helyreállítási:

A Search .NET SDK automatikusan újrapróbálkozott az átmeneti hibák után. Az ügyfél SDK által bevezetett kivételeket nem átmeneti hibákként kell kezelni.

Az alapértelmezett újrapróbálkozási szabályzat exponenciális visszalépést használ. Egy másik újrapróbálkozési szabályzat használatához hívja meg SetRetryPolicy az osztályt vagy SearchServiceClient az osztálytSearchIndexClient. További információ: Automatikus újrapróbálkozás.

Diagnosztika. Használja a Search Traffic Analytics szolgáltatást.

Cassandra

A csomópontra való olvasás vagy írás sikertelen.

Észlelés. A kivétel elfogása. A .NET-ügyfelek esetében ez általában System.Web.HttpExceptiona . Más ügyfél más kivételtípusokkal is rendelkezhet. További információ: Cassandra hibakezelés helyesen.

Helyreállítási:

  • Minden Cassandra-ügyfél saját újrapróbálkozési szabályzatokkal és képességekkel rendelkezik. További információ: Cassandra hibakezelés helyesen.
  • Használjon állványalapú üzembe helyezést, amely során az adatcsomópontok a tartalék tartományok között vannak elosztva.
  • Üzembe helyezés több régióban helyi kvórumkonzisztenciával. Ha nem átmeneti hiba történik, a feladatátvétel egy másik régióba történik.

Diagnosztika. Alkalmazásnaplók

Felhőszolgáltatás

A webes vagy feldolgozói szerepkörök váratlanul leállnak.

Észlelés. A RoleEnvironment.Leállító esemény aktiválva van.

Helyreállítás. Bírálja felül a RoleEntryPoint.OnStop metódust a kecses tisztítás érdekében. További információ: Az Azure OnStop-események kezelésének megfelelő módja (blog).

Azure Cosmos DB

Az adatok olvasása sikertelen.

Észlelés. Catch System.Net.Http.HttpRequestException vagy Microsoft.Azure.Documents.DocumentClientException.

Helyreállítási:

  • Az SDK automatikusan újrapróbálkozott a sikertelen kísérletekkel. Az újrapróbálkozések számának és a maximális várakozási időnek a beállításához konfigurálja a beállítást ConnectionPolicy.RetryOptions. Az ügyfél által okozott kivételek vagy túlmutatnak az újrapróbálkozási szabályzaton, vagy nem átmeneti hibák.
  • Ha az Azure Cosmos DB szabályozza az ügyfelet, HTTP 429-hiba jelenik meg. Ellenőrizze a DocumentClientException állapotkódját. Ha következetesen 429-et kap, fontolja meg a gyűjtemény átviteli sebességének növelését.
    • Ha a MongoDB API-t használja, a szolgáltatás 16500-es hibakódot ad vissza szabályozáskor.
  • Engedélyezze a zónaredundanciát, ha olyan régióval dolgozik, amely támogatja a rendelkezésre állási zónákat. Zónaredundancia használata esetén az Azure Cosmos DB automatikusan meghiúsul zónakimaradás esetén. További információ: Magas rendelkezésre állás elérése az Azure Cosmos DB-vel.
  • Ha többrégiós megoldást tervez, replikálja az Azure Cosmos DB-adatbázist két vagy több régióra. Minden replika olvasható. Az ügyféloldali SDK-k használatával adja meg a paramétert PreferredLocations . Ez az Azure-régiók rendezett listája. A rendszer minden olvasást a lista első elérhető régiójába küld. Ha a kérés sikertelen, az ügyfél a listában szereplő többi régiót is kipróbálja, sorrendben. További információ: A globális disztribúció beállítása az Azure Cosmos DB for NoSQL-ben.

Diagnosztika. Naplózza az ügyféloldali összes hibát.

Az adatok írása sikertelen.

Észlelés. Catch System.Net.Http.HttpRequestException vagy Microsoft.Azure.Documents.DocumentClientException.

Helyreállítási:

  • Az SDK automatikusan újrapróbálkozott a sikertelen kísérletekkel. Az újrapróbálkozések számának és a maximális várakozási időnek a beállításához konfigurálja a beállítást ConnectionPolicy.RetryOptions. Az ügyfél által okozott kivételek vagy túlmutatnak az újrapróbálkozási szabályzaton, vagy nem átmeneti hibák.
  • Ha az Azure Cosmos DB szabályozza az ügyfelet, HTTP 429-hiba jelenik meg. Ellenőrizze a DocumentClientException állapotkódját. Ha következetesen 429-et kap, fontolja meg a gyűjtemény átviteli sebességének növelését.
  • Engedélyezze a zónaredundanciát, ha olyan régióval dolgozik, amely támogatja a rendelkezésre állási zónákat. Zónaredundancia használata esetén az Azure Cosmos DB szinkron módon replikálja az összes írást a rendelkezésre állási zónák között. További információ: Magas rendelkezésre állás elérése az Azure Cosmos DB-vel.
  • Ha többrégiós megoldást tervez, replikálja az Azure Cosmos DB-adatbázist két vagy több régióra. Ha az elsődleges régió meghibásodik, a rendszer előléptet egy másik régiót írásra. A feladatátvételt manuálisan is elindíthatja. Az SDK automatikus felderítést és útválasztást végez, így az alkalmazáskód a feladatátvétel után is működik. A feladatátvételi időszak (általában perc) során az írási műveletek nagyobb késéssel fognak rendelkezni, mivel az SDK megkeresi az új írási régiót. További információ: A globális disztribúció beállítása az Azure Cosmos DB for NoSQL-ben.
  • Tartalékként őrizze meg a dokumentumot egy biztonsági mentési üzenetsorban, és dolgozza fel később.

Diagnosztika. Naplózza az ügyféloldali összes hibát.

Queue Storage

Az üzenet Azure Queue Storage-ba való írása nem sikerül következetesen.

Észlelés. Az N újrapróbálkozása után az írási művelet továbbra is meghiúsul.

Helyreállítási:

  • Tárolja az adatokat egy helyi gyorsítótárban, és a szolgáltatás elérhetővé válása után később továbbítsa az írásokat a tárolóba.
  • Hozzon létre egy másodlagos üzenetsort, és írjon az üzenetsorba, ha az elsődleges üzenetsor nem érhető el.

Diagnosztika. Használjon tárolási metrikákat.

Az alkalmazás nem tud feldolgozni egy adott üzenetet az üzenetsorból.

Észlelés. Alkalmazásspecifikus. Az üzenet például érvénytelen adatokat tartalmaz, vagy az üzleti logika valamilyen okból meghiúsul.

Helyreállítási:

Helyezze át az üzenetet egy külön üzenetsorba. Futtasson egy külön folyamatot az üzenetsorban lévő üzenetek vizsgálatához.

Fontolja meg az Azure Service Bus Üzenetkezelési üzenetsorok használatát, amely erre a célra kézbesítetlen üzenetsor-funkciót biztosít.

Feljegyzés

Ha Storage-üzenetsorokat használ a WebJobs szolgáltatással, a WebJobs SDK beépített méregüzenet-kezelést biztosít. Lásd : Az Azure Queue Storage használata a WebJobs SDK-val.

Diagnosztika. Alkalmazásnaplózás használata.

Azure Cache for Redis

A gyorsítótárból való olvasás sikertelen.

Észlelés. Catch StackExchange.Redis.RedisConnectionException.

Helyreállítási:

  1. Próbálkozzon újra az átmeneti hibákon. Az Azure Cache for Redis támogatja a beépített újrapróbálkozási elemet. További információkért tekintse meg az Azure Cache for Redis újrapróbálkozási irányelveit.
  2. Kezelje a nem átmeneti hibákat gyorsítótár-hibaként, és térjen vissza az eredeti adatforráshoz.

Diagnosztika. Használja az Azure Cache for Redis diagnosztikát.

A gyorsítótárba való írás sikertelen.

Észlelés. Catch StackExchange.Redis.RedisConnectionException.

Helyreállítási:

  1. Próbálkozzon újra az átmeneti hibákon. Az Azure Cache for Redis támogatja a beépített újrapróbálkozási elemet. További információkért tekintse meg az Azure Cache for Redis újrapróbálkozási irányelveit.
  2. Ha a hiba nem átmeneti, hagyja figyelmen kívül, és hagyja, hogy a többi tranzakció később írjon a gyorsítótárba.

Diagnosztika. Használja az Azure Cache for Redis diagnosztikát.

SQL Database

Az elsődleges régióban nem lehet csatlakozni az adatbázishoz.

Észlelés. Csatlakozás ion sikertelen.

Helyreállítási:

  • Zónaredundancia engedélyezése. A zónaredundancia engedélyezésével az Azure SQL Database automatikusan replikálja az írásokat több Azure rendelkezésre állási zónában a támogatott régiókban. További információ: Zónaredundáns rendelkezésre állás.

  • Engedélyezze a georeplikációt. Ha többrégiós megoldást tervez, fontolja meg az SQL Database aktív georeplikálásának engedélyezését.

    Előfeltétel: Az adatbázist aktív georeplikációs célra kell konfigurálni. Lásd: AZ SQL Database aktív georeplikálása.

    A replika egy másik kapcsolati sztring használ, ezért frissítenie kell a kapcsolati sztring az alkalmazásban.

Az ügyfélnek elfogynak a kapcsolatai a kapcsolatkészletben.

Észlelés. Fogási System.InvalidOperationException hibák.

Helyreállítási:

  • Próbálja meg újra a műveletet.
  • Megoldási tervként elkülönítse a kapcsolatkészleteket minden használati esethez, hogy egy használati eset ne uralja az összes kapcsolatot.
  • Növelje a maximális kapcsolatkészleteket.

Diagnosztika. Alkalmazásnaplók.

Elérte az adatbázis-kapcsolat korlátját.

Észlelés. Az Azure SQL Database korlátozza az egyidejű feldolgozók, bejelentkezések és munkamenetek számát. A korlátok a szolgáltatási szinttől függenek. További információkért tekintse meg az Azure SQL Database erőforráskorlátait.

A hibák észleléséhez keresse meg System.Data.SqlClient.SqlException és ellenőrizze az SQL-hibakód értékét SqlException.Number . A vonatkozó hibakódok listáját az SQL Database-ügyfélalkalmazások SQL-hibakódjaiban találja : Adatbázis-kapcsolati hiba és egyéb problémák.

Helyreállítás. Ezek a hibák átmenetinek minősülnek, ezért az újrapróbálkozás megoldhatja a problémát. Ha következetesen eléri ezeket a hibákat, fontolja meg az adatbázis skálázását.

Diagnosztika. – A sys.event_log lekérdezés sikeres adatbázis-kapcsolatokat, csatlakozási hibákat és holtpontokat ad vissza.

Service Bus-üzenetkezelés

Egy Service Bus-üzenetsor üzeneteinek olvasása sikertelen.

Észlelés. Kivételeket észlel az ügyfél SDK-jából. A Service Bus-kivételek alaposztálya a MessagingException. Ha a hiba átmeneti, a IsTransient tulajdonság igaz.

További információ: Service Bus üzenetkezelési kivételek.

Helyreállítási:

  1. Próbálkozzon újra az átmeneti hibákon. Lásd a Service Bus újrapróbálkozési irányelveit.
  2. A címzettek számára nem kézbesíthető üzenetek holt betűs üzenetsorba kerülnek. Ezzel az üzenetsor használatával megtekintheti, hogy mely üzenetek nem érkeztek meg. A kézbesítetlen levelek üzenetsorának automatikus törlése nem történik meg. Az üzenetek mindaddig ott maradnak, amíg ön nem kéri le őket. Lásd a Service Bus kézbesítetlen levelek üzenetsorainak áttekintését.

Az üzenet Service Bus-üzenetsorba való írása sikertelen.

Észlelés. Kivételeket észlel az ügyfél SDK-jából. A Service Bus-kivételek alaposztálya a MessagingException. Ha a hiba átmeneti, a IsTransient tulajdonság igaz.

További információ: Service Bus üzenetkezelési kivételek.

Helyreállítási:

  • A Service Bus-ügyfél automatikusan újrapróbálkozza az átmeneti hibák után. Alapértelmezés szerint exponenciális visszakapcsolást használ. Az újrapróbálkozások maximális száma vagy a maximális időtúllépési időszak után az ügyfél kivételt jelez. További információ: Service Bus újrapróbálkozás irányelvei.

  • Ha túllépi az üzenetsorkvótát, az ügyfél a QuotaExceededException értéket dobja. A kivételről szóló üzenet további részleteket tartalmaz. Az újrapróbálkozás előtt ürítsen ki néhány üzenetet az üzenetsorból, és fontolja meg az áramkör-megszakító minta használatát, hogy elkerülje a kvóta túllépése során végzett további újrapróbálkozást. Győződjön meg arról is, hogy a BrokeredMessage.TimeToLive tulajdonság nincs túl magasan beállítva.

  • Egy régión belül a rugalmasság particionált üzenetsorok vagy témakörök használatával javítható. A rendszer egy nem particionált üzenetsort vagy témakört rendel egy üzenettárhoz. Ha ez az üzenettár nem érhető el, az adott üzenetsor vagy témakör összes művelete sikertelen lesz. A particionált üzenetsorok vagy témakörök több üzenetkezelési tárolóban vannak particionálva.

  • A zónaredundancia használatával automatikusan replikálhatja a módosításokat több rendelkezésre állási zóna között. Ha egy rendelkezésre állási zóna meghibásodik, a feladatátvétel automatikusan megtörténik. További információ: Ajánlott eljárások az alkalmazások Service Bus-kimaradások és katasztrófák elleni szigetelésével kapcsolatban.

  • Ha többrégiós megoldást tervez, hozzon létre két Service Bus-névteret különböző régiókban, és replikálja az üzeneteket. Használhat aktív replikációt vagy passzív replikációt.

    • Aktív replikáció: Az ügyfél minden üzenetet mindkét üzenetsorba küld. A fogadó mindkét üzenetsort figyeli. Egyedi azonosítóval ellátott üzenetek címkézése, így az ügyfél elvetheti az ismétlődő üzeneteket.
    • Passzív replikáció: Az ügyfél egy üzenetsorba küldi az üzenetet. Hiba esetén az ügyfél visszaesik a másik üzenetsorba. A fogadó mindkét üzenetsort figyeli. Ez a módszer csökkenti az elküldött ismétlődő üzenetek számát. A fogadónak azonban továbbra is kezelnie kell az ismétlődő üzeneteket.

    További információ: GeoReplication minta és ajánlott eljárások az alkalmazások Service Bus-kimaradások és katasztrófák elleni szigetelésével kapcsolatban.

Ismétlődő üzenet.

Észlelés. Vizsgálja meg az MessageId üzenet tulajdonságait és DeliveryCount tulajdonságait.

Helyreállítási:

  • Ha lehetséges, tervezzen az üzenetfeldolgozási műveleteket idempotensnek. Ellenkező esetben tárolja a már feldolgozott üzenetek üzenetazonosítóit, és ellenőrizze az azonosítót az üzenet feldolgozása előtt.

  • Az ismétlődő észlelés engedélyezéséhez hozza létre az üzenetsort igaz értékre RequiresDuplicateDetection állítva. Ezzel a beállítással a Service Bus automatikusan törli a korábban elküldött MessageId üzeneteket. Vegye figyelembe a következőket:

    • Ez a beállítás megakadályozza, hogy ismétlődő üzenetek kerülnek az üzenetsorba. Ez nem akadályozza meg, hogy a fogadó többször feldolgozze ugyanazt az üzenetet.
    • Az ismétlődő észlelésnek van egy időablaka. Ha a rendszer ezen az ablakon túl küld másolatot, az nem lesz észlelhető.

Diagnosztika. Ismétlődő üzenetek naplózása.

Az alkalmazás nem tud feldolgozni egy adott üzenetet az üzenetsorból.

Észlelés. Alkalmazásspecifikus. Az üzenet például érvénytelen adatokat tartalmaz, vagy az üzleti logika valamilyen okból meghiúsul.

Helyreállítási:

Két hibamódot kell figyelembe venni.

  • A fogadó észleli a hibát. Ebben az esetben helyezze át az üzenetet a kézbesítetlen levelek üzenetsorába. Később futtasson egy külön folyamatot a kézbesítetlen levelek üzenetsorában lévő üzenetek vizsgálatához.
  • A fogadó az üzenet feldolgozása közben meghiúsul – például kezeletlen kivétel miatt. Az eset kezeléséhez használja a módot PeekLock . Ebben a módban, ha a zárolás lejár, az üzenet elérhetővé válik más fogadók számára. Ha az üzenet túllépi a maximális kézbesítési számot vagy az élettartamot, a rendszer automatikusan áthelyezi az üzenetet a kézbesítetlen levelek üzenetsorába.

További információ: A Service Bus kézbesítetlen levelek üzenetsorainak áttekintése.

Diagnosztika. Amikor az alkalmazás áthelyez egy üzenetet a kézbesítetlen levelek üzenetsorába, írjon egy eseményt az alkalmazásnaplókba.

Tárolás

Nem sikerül adatokat írni az Azure Storage-ba

Észlelés. Az ügyfél hibaüzeneteket kap írás közben.

Helyreállítási:

  1. Próbálkozzon újra a művelettel az átmeneti hibák utáni helyreállításhoz. Ezt az ügyféloldali SDK újrapróbálkozési szabályzata automatikusan kezeli.

  2. Implementálja az áramkör-megszakító mintát a túlterhelt tárolás elkerülése érdekében.

  3. Ha az N újrapróbálkozási kísérlet sikertelen, végezzen kecses tartalékot. Példa:

    • Tárolja az adatokat egy helyi gyorsítótárban, és a szolgáltatás elérhetővé válása után később továbbítsa az írásokat a tárolóba.
    • Ha az írási művelet tranzakciós hatókörben volt, kompenzálja a tranzakciót.

Diagnosztika. Használjon tárolási metrikákat.

Az Azure Storage-ból való adatolvasás sikertelen.

Észlelés. Az ügyfél olvasáskor hibaüzenetet kap.

Helyreállítási:

  1. Próbálkozzon újra a művelettel az átmeneti hibák utáni helyreállításhoz. Ezt az ügyféloldali SDK újrapróbálkozési szabályzata automatikusan kezeli.
  2. Az RA-GRS-tároló esetében, ha az elsődleges végpontról történő olvasás sikertelen, próbálkozzon a másodlagos végpontról való olvasással. Ezt az ügyféloldali SDK automatikusan képes kezelni. Lásd: Azure Storage-replikáció.
  3. Ha az N újrapróbálkozási kísérletei sikertelenek, hajtsa végre a tartalék műveletet a kecsesen romló teljesítmény érdekében. Ha például egy termékkép nem kérhető le a tárolóból, mutasson egy általános helyőrző lemezképet.

Diagnosztika. Használjon tárolási metrikákat.

Virtuális gép

Csatlakozás háttérbeli virtuális gépre való átirányítás sikertelen.

Észlelés. Hálózati csatlakozási hibák.

Helyreállítási:

  • Helyezzen üzembe legalább két háttérbeli virtuális gépet egy rendelkezésre állási csoportban egy terheléselosztó mögött.
  • Ha a kapcsolati hiba átmeneti, előfordulhat, hogy a TCP sikeresen újra megpróbálja elküldeni az üzenetet.
  • Újrapróbálkoztatási szabályzat implementálása az alkalmazásban.
  • Állandó vagy nem átmeneti hibák esetén implementálja az áramkör-megszakító mintát.
  • Ha a hívó virtuális gép túllépi a hálózati kimenő forgalom korlátját, a kimenő üzenetsor megtelik. Ha a kimenő üzenetsor folyamatosan megtelt, fontolja meg a horizontális felskálázást.

Diagnosztika. Naplózza a szolgáltatáshatárokon történő eseményeket.

A virtuálisgép-példány elérhetetlenné vagy nem kifogástalanná válik.

Észlelés. Konfiguráljon egy Load Balancer állapotmintát , amely jelzi, hogy a virtuálisgép-példány kifogástalan állapotú-e. A mintavételnek ellenőriznie kell, hogy a kritikus függvények megfelelően válaszolnak-e.

Helyreállítás. Minden alkalmazásszinthez helyezzen több virtuálisgép-példányt ugyanabba a rendelkezésre állási csoportba, és helyezzen egy terheléselosztót a virtuális gépek elé. Ha az állapotadat-mintavétel sikertelen, a Terheléselosztó nem küld új kapcsolatokat a nem kifogástalan példánynak.

Diagnosztika. - Használja a Load Balancer naplóelemzését.

  • Konfigurálja a monitorozási rendszert az összes állapotmonitorozási végpont figyelésére.

Az operátor véletlenül leállítja a virtuális gépet.

Észlelés. n/a

Helyreállítás. Állítson be egy erőforrás-zárolást szinttel ReadOnly . Lásd: Erőforrások zárolása az Azure Resource Managerrel.

Diagnosztika. Azure-tevékenységnaplók használata.

WebJobs

A folyamatos feladat leáll, ha az SCM-gazdagép tétlen.

Észlelés. Adjon át egy lemondási jogkivonatot a WebJob függvénynek. További információ: Graceful shutdown.

Helyreállítás. Engedélyezze a Always On beállítást a webalkalmazásban. További információ: Háttérfeladatok futtatása WebJobs használatával.

Az alkalmazás kialakítása

Az alkalmazás nem tudja kezelni a bejövő kérések csúcsát.

Észlelés. Az alkalmazástól függ. Jellemző tünetek:

  • A webhely http 5xx hibakódokat ad vissza.
  • A függő szolgáltatások, például az adatbázis vagy a tár, megkezdik a kérések szabályozását. Keresse meg a HTTP-hibákat, például a HTTP 429-et (túl sok kérést) a szolgáltatástól függően.
  • A HTTP-üzenetsor hossza nő.

Helyreállítási:

  • Vertikális felskálázás a megnövekedett terhelés kezeléséhez.

  • A hibák elhárításával elkerülheti, hogy a kaszkádolt hibák megzavarják a teljes alkalmazást. A kockázatcsökkentési stratégiák a következők:

    • A szabályozási minta implementálása a háttérrendszerek túlterheltségének elkerülése érdekében.
    • A kérések puffereléséhez és megfelelő ütemben történő feldolgozásához használjon üzenetsor-alapú terheléselegyenlítést .
    • Rangsoroljon bizonyos ügyfeleket. Ha például az alkalmazás ingyenes és fizetős rétegekkel rendelkezik, az ingyenes szinten szabályozni kell az ügyfeleket, de a fizetős ügyfeleket nem. Lásd: Prioritási üzenetsor mintája.

Diagnosztika. Az App Service diagnosztikai naplózásának használata. A diagnosztikai naplók megértéséhez használjon olyan szolgáltatást, mint az Azure Log Analytics, az Alkalmazás Elemzések vagy a New Relic.

A minta itt érhető el. A Pollyt használja az alábbi kivételekhez:

  • 429 – Szabályozás
  • 408 – Időtúllépés
  • 401 – Jogosulatlan
  • 503 vagy 5xx – A szolgáltatás nem érhető el

A munkafolyamat vagy az elosztott tranzakció egyik művelete meghiúsul.

Észlelés. Az N újrapróbálkozása után az továbbra is sikertelen lesz.

Helyreállítási:

  • Kockázatcsökkentési tervként implementálja a Scheduler-ügynök felügyelői mintáját a teljes munkafolyamat kezeléséhez.
  • Ne próbálkozzon újra az időtúllépésekkel. Ennek a hibának a sikerességi aránya alacsony.
  • Az üzenetsor működik, hogy később újrapróbálkozhasson.

Diagnosztika. Naplózza az összes műveletet (sikeres és sikertelen), beleértve a kompenzáló műveleteket is. Használjon korrelációs azonosítókat, hogy nyomon tudja követni az összes műveletet ugyanazon a tranzakción belül.

A távoli szolgáltatás hívása sikertelen.

Észlelés. HTTP-hibakód.

Helyreállítási:

  1. Próbálkozzon újra az átmeneti hibákon.
  2. Ha a hívás az N-kísérlet után meghiúsul, tegyen tartalék műveletet. (Alkalmazásspecifikus.)
  3. Implementálja az áramkör-megszakító mintát a kaszkádolt hibák elkerülése érdekében.

Diagnosztika. Naplózza az összes távoli híváshibát.

Következő lépések

Tekintse meg a rugalmasságot és a függőségeket az Azure Well-Architected Frameworkben. A hibák helyreállításának a rendszerbe történő kiépítésének az architektúra és a tervezési fázisok részét kell képeznie az elejétől kezdve a meghibásodás kockázatának elkerülése érdekében.