Analyse van foutmodus voor Azure-toepassingen

  • Artikel

Analyse van foutmodus (FMA) is een proces voor het bouwen van tolerantie in een systeem door mogelijke foutpunten in het systeem te identificeren. De FMA moet deel uitmaken van de architectuur- en ontwerpfasen, zodat u vanaf het begin herstel van fouten in het systeem kunt bouwen.

Dit is het algemene proces voor het uitvoeren van een FMA:

  1. Identificeer alle onderdelen in het systeem. Neem externe afhankelijkheden op, zoals id-providers, services van derden, enzovoort.

  2. Identificeer voor elk onderdeel mogelijke fouten die kunnen optreden. Eén onderdeel kan meer dan één foutmodus hebben. U moet bijvoorbeeld afzonderlijk rekening houden met leesfouten en schrijffouten, omdat de impact en mogelijke risicobeperkingsstappen anders zijn.

  3. Beoordeel elke foutmodus op basis van het totale risico. Houd rekening met deze factoren:

    • Wat is de kans op de fout. Is het relatief gebruikelijk? Extreem zeldzaam? U hebt geen exacte getallen nodig; het doel is om de prioriteit te rangschikken.
    • Wat is de impact op de toepassing, wat betreft beschikbaarheid, gegevensverlies, monetaire kosten en bedrijfsonderbreking?

  4. Bepaal voor elke foutmodus hoe de toepassing reageert en herstelt. Overweeg compromissen in kosten- en toepassingscomplexiteit.

Als uitgangspunt voor uw FMA-proces bevat dit artikel een catalogus met mogelijke foutmodi en de bijbehorende oplossingsstappen. De catalogus is georganiseerd op basis van technologie of Azure-service, plus een algemene categorie voor ontwerp op toepassingsniveau. De catalogus is niet volledig, maar omvat veel van de kernservices van Azure.

App Service

De App Service-app wordt afgesloten.

Detectie. Mogelijke oorzaken:

  • Verwachte afsluiting

    • Een operator sluit de toepassing af; Bijvoorbeeld met behulp van Azure Portal.
    • De app is uitgepakt omdat deze niet actief was. (Alleen als de Always On instelling is uitgeschakeld.)

  • Onverwacht afsluiten

    • De app loopt vast.
    • Een App Service VM-exemplaar is niet meer beschikbaar.

Application_End logboekregistratie het afsluiten van het app-domein (soft process crash) ondervangt en is de enige manier om het afsluiten van het toepassingsdomein te ondervangen.

Herstel:

  • Als het afsluiten werd verwacht, gebruikt u de afsluitgebeurtenis van de toepassing om op een juiste manier af te sluiten. Gebruik bijvoorbeeld in ASP.NET de Application_End methode.
  • Als de toepassing tijdens inactiviteit is verwijderd, wordt deze automatisch opnieuw opgestart bij de volgende aanvraag. Er worden echter kosten in rekening gebracht voor 'koude start'.
  • Schakel de instelling in de web-app in om te voorkomen dat de toepassing wordt verwijderd terwijl deze niet actief Always On is. Zie Web-apps configureren in Azure-app Service.
  • Als u wilt voorkomen dat een operator de app afsluit, stelt u een resourcevergrendeling met ReadOnly niveau in. Zie Resources vergrendelen met Azure Resource Manager.
  • Als de app vastloopt of een App Service-VM niet meer beschikbaar is, start App Service de app automatisch opnieuw op.

Diagnostiek. Toepassingslogboeken en webserverlogboeken. Zie Diagnostische logboekregistratie inschakelen voor web-apps in Azure-app Service.

Een bepaalde gebruiker doet herhaaldelijk onjuiste aanvragen of overbelast het systeem.

Detectie. Gebruikers verifiëren en gebruikers-id opnemen in toepassingslogboeken.

Herstel:

Diagnostiek. Alle verificatieaanvragen registreren.

Er is een ongeldige update geïmplementeerd.

Detectie. Bewaak de status van de toepassing via Azure Portal (zie Prestaties van Azure-web-apps bewaken) of implementeer het statuseindpuntbewakingspatroon.

Herstel:. Gebruik meerdere implementatiesites en draai terug naar de laatst bekende goede implementatie. Zie Basic-webtoepassing voor meer informatie.

Microsoft Entra ID

OpenID Verbinding maken verificatie mislukt.

Detectie. Mogelijke foutmodi zijn:

  1. Microsoft Entra-id is niet beschikbaar of kan niet worden bereikt vanwege een netwerkprobleem. Omleiding naar het verificatie-eindpunt mislukt en de OpenID Verbinding maken middleware genereert een uitzondering.
  2. Microsoft Entra-tenant bestaat niet. Omleiding naar het verificatie-eindpunt retourneert een HTTP-foutcode en de OpenID-Verbinding maken middleware genereert een uitzondering.
  3. De gebruiker kan zich niet verifiëren. Er is geen detectiestrategie nodig; Microsoft Entra ID verwerkt aanmeldingsfouten.

Herstel:

  1. Niet-verwerkte uitzonderingen van de middleware ondervangen.
  2. Gebeurtenissen verwerken AuthenticationFailed .
  3. De gebruiker omleiden naar een foutpagina.
  4. Nieuwe pogingen van gebruikers.

Het schrijven van gegevens naar Azure Search mislukt.

Detectie. Fouten vangen Microsoft.Rest.Azure.CloudException .

Herstel:

De Search .NET SDK probeert automatisch opnieuw na tijdelijke fouten. Eventuele uitzonderingen die door de client-SDK worden gegenereerd, moeten worden behandeld als niet-tijdelijke fouten.

Het standaardbeleid voor opnieuw proberen maakt gebruik van exponentieel uitstel. Als u een ander beleid voor opnieuw proberen wilt gebruiken, roept SetRetryPolicy u de SearchIndexClient of SearchServiceClient klasse aan. Zie Automatische nieuwe pogingen voor meer informatie.

Diagnostiek. Gebruik Search Traffic Analytics.

Het lezen van gegevens uit Azure Search mislukt.

Detectie. Fouten vangen Microsoft.Rest.Azure.CloudException .

Herstel:

De Search .NET SDK probeert automatisch opnieuw na tijdelijke fouten. Eventuele uitzonderingen die door de client-SDK worden gegenereerd, moeten worden behandeld als niet-tijdelijke fouten.

Het standaardbeleid voor opnieuw proberen maakt gebruik van exponentieel uitstel. Als u een ander beleid voor opnieuw proberen wilt gebruiken, roept SetRetryPolicy u de SearchIndexClient of SearchServiceClient klasse aan. Zie Automatische nieuwe pogingen voor meer informatie.

Diagnostiek. Gebruik Search Traffic Analytics.

Cassandra

Lezen of schrijven naar een knooppunt mislukt.

Detectie. De uitzondering vangen. Voor .NET-clients is System.Web.HttpExceptiondit doorgaans . Andere client kan andere uitzonderingstypen hebben. Zie Cassandra-foutafhandeling juist voor meer informatie.

Herstel:

  • Elke Cassandra-client heeft een eigen beleid en mogelijkheden voor opnieuw proberen. Zie Cassandra-foutafhandeling juist voor meer informatie.
  • Gebruik een rackbewuste implementatie, met gegevensknooppunten die zijn verdeeld over de foutdomeinen.
  • Implementeren in meerdere regio's met lokale quorumconsistentie. Als er een niet-tijdelijke fout optreedt, voert u een failover uit naar een andere regio.

Diagnostiek. Toepassingslogboeken

Cloudservice

Web- of werkrollen worden onverwacht afgesloten.

Detectie. De gebeurtenis RoleEnvironment.Stop wordt geactiveerd.

Herstel. Overschrijf de methode RoleEntryPoint.OnStop om probleemloos op te schonen. Zie De juiste manier om Azure OnStop-gebeurtenissen (blog) te verwerken voor meer informatie.

Azure Cosmos DB

Het lezen van gegevens mislukt.

Detectie. Vangen System.Net.Http.HttpRequestException of Microsoft.Azure.Documents.DocumentClientException.

Herstel:

  • De SDK probeert mislukte pogingen automatisch opnieuw uit te proberen. Als u het aantal nieuwe pogingen en de maximale wachttijd wilt instellen, configureert u ConnectionPolicy.RetryOptions. Uitzonderingen die de client retourneert, vallen buiten het beleid voor opnieuw proberen of zijn geen tijdelijke fouten.
  • Als Azure Cosmos DB de client beperkt, wordt er een HTTP 429-fout geretourneerd. Controleer de statuscode in DocumentClientException. Als u fout 429 consistent krijgt, kunt u overwegen om de doorvoerwaarde van de verzameling te verhogen.
    • Als u de MongoDB-API gebruikt, retourneert de service foutcode 16500 bij het beperken.
  • Schakel zoneredundantie in wanneer u werkt met een regio die beschikbaarheidszones ondersteunt. Wanneer u zoneredundantie gebruikt, voert Azure Cosmos DB automatisch een failover uit in het geval van een zonestoring. Zie Hoge beschikbaarheid bereiken met Azure Cosmos DB voor meer informatie.
  • Als u een oplossing voor meerdere regio's ontwerpt, repliceert u de Azure Cosmos DB-database in twee of meer regio's. Alle replica's kunnen worden gelezen. Geef de PreferredLocations parameter op met behulp van de client-SDK's. Dit is een geordende lijst met Azure-regio's. Alle leesbewerkingen worden verzonden naar de eerste beschikbare regio in de lijst. Als de aanvraag mislukt, probeert de client de andere regio's in de lijst, in volgorde. Zie Voor meer informatie het instellen van wereldwijde distributie in Azure Cosmos DB voor NoSQL.

Diagnostiek. Registreer alle fouten aan de clientzijde.

Het schrijven van gegevens mislukt.

Detectie. Vangen System.Net.Http.HttpRequestException of Microsoft.Azure.Documents.DocumentClientException.

Herstel:

  • De SDK probeert mislukte pogingen automatisch opnieuw uit te proberen. Als u het aantal nieuwe pogingen en de maximale wachttijd wilt instellen, configureert u ConnectionPolicy.RetryOptions. Uitzonderingen die de client retourneert, vallen buiten het beleid voor opnieuw proberen of zijn geen tijdelijke fouten.
  • Als Azure Cosmos DB de client beperkt, wordt er een HTTP 429-fout geretourneerd. Controleer de statuscode in DocumentClientException. Als u fout 429 consistent krijgt, kunt u overwegen om de doorvoerwaarde van de verzameling te verhogen.
  • Schakel zoneredundantie in wanneer u werkt met een regio die beschikbaarheidszones ondersteunt. Wanneer u zoneredundantie gebruikt, repliceert Azure Cosmos DB synchroon alle schrijfbewerkingen in beschikbaarheidszones. Zie Hoge beschikbaarheid bereiken met Azure Cosmos DB voor meer informatie.
  • Als u een oplossing voor meerdere regio's ontwerpt, repliceert u de Azure Cosmos DB-database in twee of meer regio's. Als de primaire regio mislukt, wordt een andere regio gepromoveerd tot schrijven. U kunt ook handmatig een failover activeren. De SDK voert automatische detectie en routering uit, dus de toepassingscode blijft werken na een failover. Tijdens de failoverperiode (meestal minuten) hebben schrijfbewerkingen een hogere latentie, omdat de SDK de nieuwe schrijfregio vindt. Zie Voor meer informatie het instellen van wereldwijde distributie in Azure Cosmos DB voor NoSQL.
  • Als terugval houdt u het document vast aan een back-upwachtrij en verwerkt u de wachtrij later.

Diagnostiek. Registreer alle fouten aan de clientzijde.

Queue Storage

Het schrijven van een bericht naar Azure Queue Storage mislukt consistent.

Detectie. Na nieuwe pogingen met N mislukt de schrijfbewerking nog steeds.

Herstel:

  • Sla de gegevens op in een lokale cache en stuur de schrijfbewerkingen later door naar de opslag wanneer de service beschikbaar is.
  • Maak een secundaire wachtrij en schrijf naar die wachtrij als de primaire wachtrij niet beschikbaar is.

Diagnostiek. Gebruik metrische opslaggegevens.

De toepassing kan een bepaald bericht uit de wachtrij niet verwerken.

Detectie. Toepassingsspecifiek. Het bericht bevat bijvoorbeeld ongeldige gegevens of de bedrijfslogica mislukt om een of andere reden.

Herstel:

Verplaats het bericht naar een afzonderlijke wachtrij. Voer een afzonderlijk proces uit om de berichten in die wachtrij te onderzoeken.

Overweeg het gebruik van Azure Service Bus Messaging-wachtrijen, die een functie voor wachtrijen met onbestelbare letters biedt voor dit doel.

Notitie

Als u Storage-wachtrijen gebruikt met WebJobs, biedt de WebJobs SDK ingebouwde verwerking van gifberichten. Zie Hoe u Azure Queue Storage gebruikt met de WebJobs SDK.

Diagnostiek. Gebruik toepassingslogboekregistratie.

Azure Cache voor Redis

Lezen vanuit de cache mislukt.

Detectie. Catch StackExchange.Redis.RedisConnectionException.

Herstel:

  1. Probeer het opnieuw bij tijdelijke fouten. Azure Cache voor Redis ondersteunt ingebouwde nieuwe pogingen. Zie Azure Cache voor Redis richtlijnen voor opnieuw proberen voor meer informatie.
  2. Behandel niet-tijdelijke fouten als een cachemisser en val terug op de oorspronkelijke gegevensbron.

Diagnostiek. Gebruik Azure Cache voor Redis diagnostische gegevens.

Schrijven naar de cache mislukt.

Detectie. Catch StackExchange.Redis.RedisConnectionException.

Herstel:

  1. Probeer het opnieuw bij tijdelijke fouten. Azure Cache voor Redis ondersteunt ingebouwde nieuwe pogingen. Zie Azure Cache voor Redis richtlijnen voor opnieuw proberen voor meer informatie.
  2. Als de fout niet-tijdelijk is, negeert u deze en laat u andere transacties later naar de cache schrijven.

Diagnostiek. Gebruik Azure Cache voor Redis diagnostische gegevens.

SQL Database

Kan geen verbinding maken met de database in de primaire regio.

Detectie. Verbinding maken ion mislukt.

Herstel:

  • Schakel zoneredundantie in. Door zoneredundantie in te schakelen, repliceert Azure SQL Database automatisch uw schrijfbewerkingen in meerdere Azure-beschikbaarheidszones binnen ondersteunde regio's. Zie Zone-redundante beschikbaarheid voor meer informatie.

  • Actieve geo-replicatie. Als u een oplossing voor meerdere regio's ontwerpt, kunt u overwegen om actieve geo-replicatie van SQL Database in te schakelen.

    Vereiste: De database moet worden geconfigureerd voor actieve geo-replicatie. Zie actieve geo-replicatie van SQL Database.

    De replica maakt gebruik van een andere verbindingsreeks, dus u moet de verbindingsreeks in uw toepassing bijwerken.

De client heeft geen verbindingen meer in de verbindingsgroep.

Detectie. Fouten vangen System.InvalidOperationException .

Herstel:

  • Voer de bewerking opnieuw uit.
  • Als oplossingsplan moet u de verbindingsgroepen voor elke use-case isoleren, zodat één use-case niet alle verbindingen kan overheersten.
  • Verhoog de maximale verbindingsgroepen.

Diagnostiek. Toepassingslogboeken.

De limiet voor de databaseverbinding is bereikt.

Detectie. Azure SQL Database beperkt het aantal gelijktijdige werkrollen, aanmeldingen en sessies. De limieten zijn afhankelijk van de servicelaag. Zie Azure SQL Database-resourcelimieten voor meer informatie.

Als u deze fouten wilt detecteren, haalt System.Data.SqlClient.SqlException u de waarde van SqlException.Number de SQL-foutcode op en controleert u deze. Zie SQL-foutcodes voor SQL Database-clienttoepassingen: Databaseverbindingsfout en andere problemen voor een lijst met relevante foutcodes.

Herstel. Deze fouten worden beschouwd als tijdelijk, zodat opnieuw proberen het probleem kan oplossen. Als u deze fouten consistent bereikt, kunt u overwegen om de database te schalen.

Diagnostiek. - De sys.event_log query retourneert geslaagde databaseverbindingen, verbindingsfouten en impasses.

  • Maak een waarschuwingsregel voor mislukte verbindingen.
  • Schakel sql Database-controle in en controleer op mislukte aanmeldingen.

Service Bus-berichten

Het lezen van een bericht uit een Service Bus-wachtrij mislukt.

Detectie. Uitzonderingen van de client-SDK ondervangen. De basisklasse voor Service Bus-uitzonderingen is MessagingException. Als de fout tijdelijk is, is de IsTransient eigenschap waar.

Zie Service Bus Messaging-uitzonderingen voor meer informatie.

Herstel:

  1. Probeer het opnieuw bij tijdelijke fouten. Raadpleeg de richtlijnen voor opnieuw proberen van Service Bus.
  2. Berichten die niet aan een ontvanger kunnen worden bezorgd, worden in een wachtrij met dode letters geplaatst. Gebruik deze wachtrij om te zien welke berichten niet kunnen worden ontvangen. Er is geen automatische opschoning van de wachtrij met dode letters. Berichten blijven daar staan totdat u ze expliciet ophaalt. Zie Overzicht van wachtrijen met dead-letter van Service Bus.

Het schrijven van een bericht naar een Service Bus-wachtrij mislukt.

Detectie. Uitzonderingen van de client-SDK ondervangen. De basisklasse voor Service Bus-uitzonderingen is MessagingException. Als de fout tijdelijk is, is de IsTransient eigenschap waar.

Zie Service Bus Messaging-uitzonderingen voor meer informatie.

Herstel:

  • De Service Bus-client probeert automatisch opnieuw na tijdelijke fouten. Standaard wordt gebruikgemaakt van exponentiële back-off. Na het maximale aantal nieuwe pogingen of de maximale time-outperiode genereert de client een uitzondering. Zie de richtlijnen voor opnieuw proberen van Service Bus voor meer informatie.

  • Als het wachtrijquotum wordt overschreden, genereert de client QuotaExceededException. Het uitzonderingsbericht geeft meer details. Maak enkele berichten uit de wachtrij leeg voordat u het opnieuw probeert en overweeg om het circuitonderbrekerpatroon te gebruiken om te voorkomen dat er steeds nieuwe pogingen worden gedaan terwijl het quotum wordt overschreden. Zorg er ook voor dat de eigenschap BrokeredMessage.TimeToLive niet te hoog is ingesteld.

  • Binnen een regio kan tolerantie worden verbeterd met behulp van gepartitioneerde wachtrijen of onderwerpen. Een niet-gepartitioneerde wachtrij of onderwerp wordt toegewezen aan één berichtenarchief. Als dit berichtenarchief niet beschikbaar is, mislukken alle bewerkingen in die wachtrij of het onderwerp. Een gepartitioneerde wachtrij of onderwerp wordt gepartitioneerd in meerdere berichtenarchieven.

  • Gebruik zoneredundantie om wijzigingen tussen meerdere beschikbaarheidszones automatisch te repliceren. Als één beschikbaarheidszone mislukt, vindt failover automatisch plaats. Zie Best practices voor het isoleren van toepassingen tegen Service Bus-storingen en -noodgevallen voor meer informatie.

  • Als u een oplossing voor meerdere regio's ontwerpt, maakt u twee Service Bus-naamruimten in verschillende regio's en repliceert u de berichten. U kunt actieve replicatie of passieve replicatie gebruiken.

    • Actieve replicatie: de client verzendt elk bericht naar beide wachtrijen. De ontvanger luistert op beide wachtrijen. Tag berichten met een unieke id, zodat de client dubbele berichten kan negeren.
    • Passieve replicatie: de client verzendt het bericht naar één wachtrij. Als er een fout optreedt, valt de client terug naar de andere wachtrij. De ontvanger luistert op beide wachtrijen. Deze aanpak vermindert het aantal dubbele berichten dat wordt verzonden. De ontvanger moet echter nog steeds dubbele berichten verwerken.

    Zie GeoReplication-voorbeeld en Aanbevolen procedures voor het isoleren van toepassingen tegen Service Bus-storingen en -noodgevallen voor meer informatie.

Dubbel bericht.

Detectie. Bekijk de MessageId en DeliveryCount eigenschappen van het bericht.

Herstel:

  • Ontwerp indien mogelijk uw berichtverwerkingsbewerkingen om idempotent te zijn. Anders slaat u bericht-id's op van berichten die al zijn verwerkt en controleert u de id voordat u een bericht verwerkt.

  • Schakel dubbele detectie in door de wachtrij te maken met RequiresDuplicateDetection ingesteld op true. Met deze instelling verwijdert Service Bus automatisch elk bericht dat wordt verzonden met hetzelfde MessageId als een eerder bericht. Let op het volgende:

    • Met deze instelling voorkomt u dat dubbele berichten in de wachtrij worden geplaatst. Het voorkomt niet dat een ontvanger hetzelfde bericht meer dan één keer verwerkt.
    • Dubbele detectie heeft een tijdvenster. Als een duplicaat buiten dit venster wordt verzonden, wordt deze niet gedetecteerd.

Diagnostiek. Gedupliceerde berichten vastleggen.

De toepassing kan een bepaald bericht niet uit de wachtrij verwerken.

Detectie. Toepassingsspecifiek. Het bericht bevat bijvoorbeeld ongeldige gegevens of de bedrijfslogica mislukt om een of andere reden.

Herstel:

Er zijn twee foutmodi om rekening mee te houden.

  • De ontvanger detecteert de fout. In dit geval verplaatst u het bericht naar de wachtrij met dode letters. Voer later een afzonderlijk proces uit om de berichten in de wachtrij met dode letters te onderzoeken.
  • De ontvanger mislukt midden in het verwerken van het bericht, bijvoorbeeld vanwege een onverwerkte uitzondering. Gebruik de modus om dit geval PeekLock af te handelen. In deze modus, als de vergrendeling verloopt, wordt het bericht beschikbaar voor andere ontvangers. Als het bericht het maximale aantal bezorgingen of de time-to-live overschrijdt, wordt het bericht automatisch verplaatst naar de wachtrij met dode brieven.

Zie Overview of Service Bus dead-letter queues (Overzicht van Service Bus-wachtrijen voor onbestelbare berichten) voor meer informatie.

Diagnostiek. Wanneer de toepassing een bericht naar de wachtrij met dode letters verplaatst, schrijft u een gebeurtenis naar de toepassingslogboeken.

Storage

Het schrijven van gegevens naar Azure Storage mislukt

Detectie. De client ontvangt fouten bij het schrijven.

Herstel:

  1. Voer de bewerking opnieuw uit om te herstellen van tijdelijke fouten. Het beleid voor opnieuw proberen in de client-SDK verwerkt dit automatisch.

  2. Implementeer het circuitonderbrekerpatroon om overweldigende opslag te voorkomen.

  3. Als N nieuwe pogingen mislukken, voert u een probleemloze terugval uit. Voorbeeld:

    • Sla de gegevens op in een lokale cache en stuur de schrijfbewerkingen later door naar de opslag wanneer de service beschikbaar is.
    • Als de schrijfactie zich in een transactioneel bereik bevond, compenseert u de transactie.

Diagnostiek. Gebruik metrische opslaggegevens.

Het lezen van gegevens uit Azure Storage mislukt.

Detectie. De client ontvangt fouten bij het lezen.

Herstel:

  1. Voer de bewerking opnieuw uit om te herstellen van tijdelijke fouten. Het beleid voor opnieuw proberen in de client-SDK verwerkt dit automatisch.
  2. Als het lezen van het primaire eindpunt mislukt voor RA-GRS-opslag, kunt u het lezen van het secundaire eindpunt proberen. De client-SDK kan dit automatisch afhandelen. Zie Azure Storage-replicatie.
  3. Als N nieuwe pogingen mislukken, voert u een terugvalactie uit om probleemloos te verslechteren. Als een productafbeelding bijvoorbeeld niet kan worden opgehaald uit de opslag, geeft u een algemene tijdelijke aanduiding weer.

Diagnostiek. Gebruik metrische opslaggegevens.

Virtuele machine

Verbinding maken van een back-end-VM mislukt.

Detectie. Netwerkverbindingsfouten.

Herstel:

  • Implementeer ten minste twee back-end-VM's in een beschikbaarheidsset achter een load balancer.
  • Als de verbindingsfout tijdelijk is, probeert TCP het bericht soms opnieuw te verzenden.
  • Implementeer een beleid voor opnieuw proberen in de toepassing.
  • Implementeer het circuitonderbrekerpatroon voor permanente of niet-tijdelijke fouten.
  • Als de aanroepende VM de limiet voor uitgaand netwerk overschrijdt, wordt de uitgaande wachtrij gevuld. Als de uitgaande wachtrij consistent vol is, kunt u overwegen om uit te schalen.

Diagnostiek. Registreer gebeurtenissen aan de grenzen van services.

VM-exemplaar is niet meer beschikbaar of beschadigd.

Detectie. Configureer een load balancer-statustest die aangeeft of het VM-exemplaar in orde is. De test moet controleren of kritieke functies correct reageren.

Herstel. Plaats voor elke toepassingslaag meerdere VM-exemplaren in dezelfde beschikbaarheidsset en plaats een load balancer vóór de VM's. Als de statustest mislukt, stopt de Load Balancer met het verzenden van nieuwe verbindingen naar het beschadigde exemplaar.

Diagnostiek. - Gebruik Log Analytics van Load Balancer.

  • Configureer uw bewakingssysteem om alle statuscontrole-eindpunten te bewaken.

De operator sluit per ongeluk een VIRTUELE machine af.

Detectie. N.v.t.

Herstel. Stel een resourcevergrendeling in met ReadOnly niveau. Zie Resources vergrendelen met Azure Resource Manager.

Diagnostiek. Azure-activiteitenlogboeken gebruiken.

WebJobs

Continue taak wordt niet meer uitgevoerd wanneer de SCM-host niet actief is.

Detectie. Geef een annuleringstoken door aan de functie WebJob. Zie Graceful afsluiten voor meer informatie.

Herstel. Schakel de Always On instelling in de web-app in. Zie Achtergrondtaken uitvoeren met WebJobs voor meer informatie.

Toepassingsontwerp

De toepassing kan geen piek in binnenkomende aanvragen verwerken.

Detectie. Is afhankelijk van de toepassing. Typische symptomen:

  • De website retourneert HTTP 5xx-foutcodes.
  • Afhankelijke services, zoals database of opslag, beginnen aanvragen te beperken. Zoek naar HTTP-fouten, zoals HTTP 429 (Te veel aanvragen), afhankelijk van de service.
  • De lengte van de HTTP-wachtrij neemt toe.

Herstel:

  • Uitschalen om verhoogde belasting te verwerken.

  • Beperk fouten om te voorkomen dat trapsgewijze fouten de hele toepassing verstoren. Risicobeperkingsstrategieën zijn onder andere:

Diagnostiek. Gebruik diagnostische logboekregistratie van App Service. Gebruik een service zoals Azure Log Analytics, Application Insights of New Relic om inzicht te krijgen in de diagnostische logboeken.

Hier is een voorbeeld beschikbaar. Polly wordt gebruikt voor deze uitzonderingen:

  • 429 - Beperking
  • 408 - Time-out
  • 401 - Onbevoegd
  • 503 of 5xx - Service niet beschikbaar

Een van de bewerkingen in een werkstroom of gedistribueerde transactie mislukt.

Detectie. Na nieuwe pogingen van N mislukt het nog steeds.

Herstel:

  • Implementeer als beperkingsplan het patroon Scheduler Agent Supervisor om de hele werkstroom te beheren.
  • Probeer het niet opnieuw bij time-outs. Er is een laag slagingspercentage voor deze fout.
  • Werk in de wachtrij om het later opnieuw te proberen.

Diagnostiek. Alle bewerkingen registreren (geslaagd en mislukt), inclusief compenserende acties. Gebruik correlatie-id's, zodat u alle bewerkingen binnen dezelfde transactie kunt bijhouden.

Een aanroep naar een externe service mislukt.

Detectie. HTTP-foutcode.

Herstel:

  1. Probeer het opnieuw bij tijdelijke fouten.
  2. Als de aanroep mislukt na N-pogingen , voert u een terugvalactie uit. (Toepassingsspecifiek.)
  3. Implementeer het circuitonderbrekerpatroon om trapsgewijze fouten te voorkomen.

Diagnostiek. Alle mislukte externe aanroepen registreren.

Volgende stappen

Zie Tolerantie en afhankelijkheden in het Azure Well-Architected Framework. Herstel van bouwfouten in het systeem moet deel uitmaken van de architectuur- en ontwerpfasen vanaf het begin om het risico op fouten te voorkomen.