Analyse van foutmodus voor Azure-toepassingen

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 mislukking? 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 belangrijkste Azure-services.

Notitie

Storingen moeten worden onderscheiden van fouten. Een fout is een onverwachte gebeurtenis binnen een systeem die voorkomt dat deze normaal blijft functioneren. Een hardwarestoring die een netwerkpartitie veroorzaakt, is bijvoorbeeld een storing. Fouten vereisen meestal interventie of specifiek ontwerp voor die klasse van fouten. Fouten zijn daarentegen een verwacht onderdeel van normale bewerkingen, worden onmiddellijk behandeld en het systeem blijft op dezelfde capaciteit werken na een fout. Fouten die tijdens de invoervalidatie worden gedetecteerd, kunnen bijvoorbeeld worden verwerkt via bedrijfslogica.

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 registreert het afsluiten van het applicatiedomein (zoals bij een soft process crash) en is de enige manier om het afsluiten van applicatiedomeinen vast te leggen.

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 ontladen 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:

• Gebruik Azure API Management om aanvragen van de gebruiker te beperken. Zie Geavanceerde aanvraagbeperking met Azure API Management
• De gebruiker blokkeren.

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 Connect-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 Connect-middleware genereert een uitzondering.
2. Microsoft Entra-tenant bestaat niet. Omleiding naar het verificatie-eindpunt retourneert een HTTP-foutcode en de OpenID Connect-middleware genereert een uitzondering.
3. De gebruiker kan zich niet verifiëren. Er is geen detectiestrategie nodig; Microsoft Entra ID verwerkt aanmeldingsfouten.

Herstel:

1. Ondervang niet-verwerkte uitzonderingen afkomstig van de middleware.
2. Verwerk AuthenticationFailed gebeurtenissen.
3. De gebruiker omleiden naar een foutpagina.
4. Nieuwe pogingen van gebruikers.

Azure AI Search

Het schrijven van gegevens naar Azure AI Search mislukt.

Detectie. Fouten opsporen 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 u SetRetryPolicy aan in de SearchIndexClient of SearchServiceClient klassen. Raadpleeg Automatische nieuwe pogingen voor meer informatie.

Diagnostiek. Gebruik Search Traffic Analytics.

Het lezen van gegevens uit Azure AI Search mislukt.

Detectie. Fouten opsporen 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 herhalingsbeleid wilt gebruiken, roept u SetRetryPolicy aan op de SearchIndexClient-klasse of SearchServiceClient-klasse. Voor meer informatie, zie Automatische nieuwe pogingen.

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. Voor meer informatie, zie Cassandra-foutafhandeling op de juiste manier.

Herstel:

• Elke Cassandra-client heeft een eigen beleid en mogelijkheden voor opnieuw proberen. Zie Cassandra-foutafhandeling op de juiste manier 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, schakelt u over 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 zorgvuldig op te ruimen. 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 opwerpt, vallen buiten het herhalingsbeleid of zijn geen tijdelijke fouten.
• Als Azure Cosmos DB de client beperkt, retourneert deze een HTTP 429-fout. Controleer de statuscode in DocumentClientException. Als u fout 429 consistent krijgt, kunt u overwegen om de doorvoerwaarde van de collectie te verhogen.
  • Als u de MongoDB-API gebruikt, retourneert de service de foutcode 16500 bij throttling.
• 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 zijn leesbaar. 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 opwerpt, vallen onder het opnieuw proberen beleid, of zijn geen tijdelijke fouten.
• Als Azure Cosmos DB de client beperkt, wordt er een HTTP 429-fout geretourneerd. Controleer de statuscode in DocumentClientException. Wanneer je foutmelding 429 consistent krijgt, kun je 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 uitvalt, wordt een andere regio gepromoveerd om te 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.

Wachtrijopslag

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 opslagmetingen.

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 dead-letter queue functie bieden voor dit doel.

Notitie

Als u Opslagwachtrijen met WebJobs gebruikt, 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. Vang StackExchange.Redis.RedisConnectionException.

Herstel:

1. Probeer het opnieuw bij tijdelijke fouten. Azure Cache voor Redis ondersteunt ingebouwde nieuwe pogingen.
2. Behandel niet-tijdelijke fouten als een cache-miss 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.
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. De verbinding 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.

• Inschakelen van 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.

  • Lees voor het uitvoeren van opdrachten een secundaire replica.
  • Voor invoegingen en updates voert u handmatig een failover uit naar een secundaire replica. Zie Een geplande of niet-geplande failover initiëren voor Azure SQL Database.

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

De client loopt uit verbindingen in de verbindingspool.

Detectie. Vang fouten op 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.

Om deze fouten te detecteren, vangt u System.Data.SqlClient.SqlException op en controleert u de waarde van SqlException.Number op de SQL-foutcode. 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 steeds tegen deze fouten aanloopt, overweeg dan 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-berichtenuitwisseling

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

Detectie. Uitzonderingen van de client SDK opvangen. 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.
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 dead-letter wachtrijen van de 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.

• Als het wachtrijquotum wordt overschreden, genereert de client QuotaExceededException. Het uitzonderingsbericht geeft meer details. Haal enkele berichten uit de wachtrij voordat u het opnieuw probeert. Overweeg het gebruik van het Circuit Breaker-patroon 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 de veerkracht worden verbeterd door het gebruik 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 zodat ze idempotent 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 een afzonderlijk proces uit om later de berichten in de dead-letter queue te onderzoeken.
• De ontvanger mislukt midden in het verwerken van het bericht, bijvoorbeeld vanwege een onverwerkte uitzondering. Gebruik PeekLock modus om dit geval af te handelen. In deze modus, als de vergrendeling verloopt, wordt het bericht beschikbaar voor andere ontvangers. Als het bericht het maximale aantal bezorgpogingen of de levensduur overschrijdt, wordt het bericht automatisch verplaatst naar de dead-letter queue.

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.

Opslag

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 de Circuit Breaker-patroon om te voorkomen dat de opslag wordt overspoeld.

3. Als N nieuwe pogingen mislukken, voer een soepele 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 transactionele sfeer bevindt, compenseer de transactie.

Diagnostiek. Gebruik opslagmetriek.

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 herhaalde pogingen mislukken, neem dan een terugvalactie om zorgvuldig terug te schakelen. Als een productafbeelding bijvoorbeeld niet kan worden opgehaald uit de opslag, geeft u een algemene tijdelijke aanduiding weer.

Diagnostiek. Gebruik opslagmetingen.

Virtuele machine

De verbinding met 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 Circuit Breaker-patroon voor aanhoudende of niet-voorbijgaande fouten.
• Als de aanroepende VM de limiet voor uitgaand netwerk overschrijdt, loopt de uitgaande wachtrij vol. 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 ongezond.

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 diensten, zoals databases of opslag, beginnen met het beperken van aanvragen. 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 de toegenomen werklast aan te kunnen.

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

  • Implementeer het beperkingspatroon om overweldigende back-endsystemen te voorkomen.
  • Gebruik load leveling op basis van wachtrijen om aanvragen te bufferen en te verwerken in een geschikt tempo.
  • Geef prioriteit aan bepaalde clients. Als de toepassing bijvoorbeeld gratis en betaalde niveaus heeft, knijpt u klanten in de gratis laag af, maar niet de betalende klanten. Zie Prioriteitswachtrijpatroon.

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 - Tariefbeperking
• 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 een mitigatieplan 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.