Analyse du mode d'échec pour les applications Azure

L’analyse du mode d’échec (FMA) est un processus de création de résilience dans un système, en identifiant les points de défaillance possibles. La FMA doit faire partie des phases de conception et d’architecture, afin que vous puissiez générer une récupération après une défaillance dans le système depuis le début.

Voici le processus général pour effectuer une FMA :

1. Identifiez tous les composants dans le système. Incluez les dépendances externes, telles que les fournisseurs d'identité, les services tiers, etc.

2. Pour chaque composant, identifiez les défaillances qui peuvent se produire. Un seul composant peut avoir plusieurs modes d’échec. Par exemple, vous devez prendre en compte séparément les échecs de lecture et d'écriture, car les impacts et les mesures d'atténuation possibles seront différents.

3. Évaluez chaque mode d’échec en fonction de son niveau de risque global. Tenez compte de ces facteurs :

   • Quelle est la probabilité de l’échec. Est-il relativement courant ? Extrêmement rare ? Vous n’avez pas besoin de chiffres exacts, le but est d’aider à classer par ordre priorité.
   • Quel est l’impact sur l’application, en termes de disponibilité, de pertes de données, de coût monétaire et d’interruption de service ?

4. Pour chaque mode de défaillance, déterminez comment l’application va répondre et récupérer. Étudiez les compromis au niveau du le coût et de la complexité de l’application.

Point de départ pour votre processus FMA, cet article contient un catalogue des modes d'échec potentiels et les mesures d'atténuation associées. Le catalogue est organisé par technologie ou service Azure, ainsi qu’une catégorie générale pour la conception au niveau de l’application. Le catalogue n’est pas exhaustif, mais traite beaucoup des principaux services Azure.

App Service

L’application App Service s’arrête.

Détection. Causes possibles :

• Arrêt planifié

  • Un opérateur arrête l’application ; via le portail Azure par exemple.
  • L’application a été déchargée, car elle était inactive. (Uniquement si le paramètre Always On est désactivé.)

• Arrêt inattendu

  • L’application se bloque.
  • Une instance de machine virtuelle de App Service est indisponible.

L’enregistrement Application_End interceptera l’arrêt du domaine d’application (panne de processus logicielle) et il s’agit de la seule façon d’intercepter les arrêts de domaine d’application.

Récupération :

• Si l’arrêt était attendu, utilisez l’événement d’arrêt de l’application pour arrêter l’application de manière appropriée. Par exemple, dans ASP.NET, utilisez la méthode Application_End.
• Si l’application a été déchargée une fois inactive, elle est automatiquement redémarrée lors de la prochaine requête. Toutefois, cela occasionne le coût du « démarrage à froid ».
• Pour empêcher le déchargement de l’application une fois inactive, vous devez activer la paramètre Always On dans l’application web. Consultez Configurer des applications web dans Azure App Service.
• Pour empêcher un opérateur d’arrêter l’application, définissez un verrou de ressource avec un niveau ReadOnly. Consultez Verrouiller des ressources avec Azure Resource Manager.
• En cas de blocage de l’application ou si une machine virtuelle de App Service devient indisponible, App Service redémarre automatiquement l’application.

Diagnostics. Journaux d’activité des serveurs web et d’applications. Consultez la page Activer la journalisation des diagnostics pour les applications web dans Azure App Service.

Un utilisateur particulier effectue des requêtes incorrectes ou surcharge le système à plusieurs reprises.

Détection. Authentifiez les utilisateurs et incluez l’ID d’utilisateur dans les journaux d’activité d’applications.

Récupération :

• Utilisez Gestion des API Azure pour limiter les requêtes de l'utilisateur. Consultez Limitation de requêtes avancée avec Gestion des API Azure.
• Bloquez l’utilisateur.

Diagnostics. Journalisation de toutes les requêtes d’authentification.

Une mise à jour incorrecte a été déployée.

Détection. Surveillez l'intégrité de l'application via le portail Azure (consultez Surveiller les performances de l'application web Azure) ou implémentez le modèle de contrôle d'intégrité de point de terminaison.

Récupération : . Utilisez plusieurs emplacements de déploiement et revenez au dernier déploiement correct connu. Pour plus d’informations, voir la rubrique Application web de base.

Microsoft Entra ID

L'authentification OpenID Connect échoue.

Détection. Les modes d’échec possibles sont les suivantes :

1. Microsoft Entra ID n’est pas disponible ou ne peut pas être atteint en raison d’un problème réseau. La redirection vers le point de terminaison de l'authentification échoue, et l'intergiciel OpenID Connect lève une exception.
2. Le locataire Microsoft Entra n’existe pas. La redirection vers le point de terminaison de l'authentification renvoie un code d'erreur HTTP, et l'intergiciel OpenID Connect lève une exception.
3. L’utilisateur ne peut pas s’authentifier. Aucune stratégie de détection n’est nécessaire ; Microsoft Entra ID gère les échecs de connexion.

Récupération :

1. Interceptez des exceptions non gérées à partir de l’intergiciel (middleware).
2. Gérez les événements AuthenticationFailed.
3. Redirigez l’utilisateur vers une page d’erreur.
4. L’utilisateur essaye de nouveau.

Recherche Azure

L’écriture des données sur Recherche Azure échoue.

Détection. Interceptez les erreurs Microsoft.Rest.Azure.CloudException.

Récupération :

Le kit de développement logiciel (SDK) .NET effectue automatiquement une nouvelle tentative après des échecs temporaires. Toutes les exceptions levées par le kit de développement logiciel client doivent être traitées comme des erreurs non temporaires.

La stratégie de nouvelles tentatives par défaut utilise une temporisation exponentielle. Pour utiliser une stratégie de nouvelles tentatives différente, appelez SetRetryPolicy sur la classe SearchIndexClient ou SearchServiceClient. Pour plus d'informations, consultez Nouvelles tentatives automatiques.

Diagnostics. Utilisez Rechercher l'analyse du trafic.

La lecture des données à partir de Recherche Azure échoue.

Détection. Interceptez les erreurs Microsoft.Rest.Azure.CloudException.

Récupération :

Le kit de développement logiciel (SDK) .NET effectue automatiquement une nouvelle tentative après des échecs temporaires. Toutes les exceptions levées par le kit de développement logiciel client doivent être traitées comme des erreurs non temporaires.

La stratégie de nouvelles tentatives par défaut utilise une temporisation exponentielle. Pour utiliser une stratégie de nouvelles tentatives différente, appelez SetRetryPolicy sur la classe SearchIndexClient ou SearchServiceClient. Pour plus d'informations, consultez Nouvelles tentatives automatiques.

Diagnostics. Utilisez Rechercher l'analyse du trafic.

Cassandra

La lecture ou l’écriture dans un nœud échoue.

Détection. Interceptez l’exception. Pour les clients .NET, il s’agira généralement de System.Web.HttpException. Les autres clients peuvent être sujets à d’autres types d’exceptions. Pour plus d’informations, consultez Gestion correcte des erreurs Cassandra.

Récupération :

• Chaque client de Cassandra possède ses propres fonctionnalités et stratégies de nouvelles tentatives. Pour plus d’informations, consultez Gestion correcte des erreurs Cassandra.
• Utilisez un déploiement en mode rack, avec les nœuds de données répartis entre les domaines d’erreur.
• Déployez dans plusieurs régions avec une cohérence de quorum locale. Si une défaillance non temporaire se produit, basculez vers une autre région.

Diagnostics. Journaux d’activité d’application

Service cloud

Les rôles web ou de travail sont arrêtés de façon inattendue.

Détection. L'événement RoleEnvironment.Stopping est déclenché.

Récupération. Remplacez la méthode RoleEntryPoint.OnStop pour effectuer un nettoyage approprié. Pour plus d'informations, consultez La bonne manière de gérer les événements d'Azure OnStop (blog).

Azure Cosmos DB

Échec de la lecture des données.

Détection. Interceptez System.Net.Http.HttpRequestException ou Microsoft.Azure.Documents.DocumentClientException.

Récupération :

• Le kit de développement logiciel retente automatiquement les tentatives ayant échoué. Pour définir le nombre de nouvelles tentatives et le délai d’attente maximal, configurez ConnectionPolicy.RetryOptions. Les exceptions déclenchées par le client sont au-delà de la stratégie de nouvelle tentative ou ne sont pas des erreurs temporaires.
• Si Azure Cosmos DB limite le client, il renvoie une erreur HTTP 429. Vérifiez le code d’état dans DocumentClientException. Si l’erreur 429 se produit régulièrement, envisagez d’augmenter la valeur de débit de la collection.
  • Si vous utilisez l’API MongoDB, le service retourne le code d’erreur 16500 lors de la limitation.
• Activez la redondance de zone lorsque vous travaillez avec une région qui prend en charge les zones de disponibilité. Lorsque vous utilisez la redondance de zone, Azure Cosmos DB bascule automatiquement en cas de panne de zone. Pour plus d’informations, consultez Obtenir la haute disponibilité avec Azure Cosmos DB.
• Si vous concevez une solution multirégionale, répliquez la base de données Azure Cosmos DB dans deux régions ou plus. Tous les réplicas sont lisibles. À l’aide des kits de développement logiciel, spécifiez le paramètre PreferredLocations. Il s’agit d’une liste ordonnée des régions Azure. Toutes les lectures sont envoyées vers la première région disponible dans la liste. Si la requête échoue, le client va essayer les autres régions dans la liste, dans l’ordre. Pour plus d'informations, consultez Comment configurer la distribution mondiale dans Azure Cosmos DB for NoSQL.

Diagnostics. Journalisation de toutes les erreurs côté client.

Échec de l’écriture des données.

Détection. Interceptez System.Net.Http.HttpRequestException ou Microsoft.Azure.Documents.DocumentClientException.

Récupération :

• Le kit de développement logiciel retente automatiquement les tentatives ayant échoué. Pour définir le nombre de nouvelles tentatives et le délai d’attente maximal, configurez ConnectionPolicy.RetryOptions. Les exceptions déclenchées par le client sont au-delà de la stratégie de nouvelle tentative ou ne sont pas des erreurs temporaires.
• Si Azure Cosmos DB limite le client, il renvoie une erreur HTTP 429. Vérifiez le code d’état dans DocumentClientException. Si l’erreur 429 se produit régulièrement, envisagez d’augmenter la valeur de débit de la collection.
• Activez la redondance de zone lorsque vous travaillez avec une région qui prend en charge les zones de disponibilité. Lorsque vous utilisez la redondance de zone, Azure Cosmos DB réplique de manière synchrone toutes les écritures dans les zones de disponibilité. Pour plus d’informations, consultez Obtenir la haute disponibilité avec Azure Cosmos DB.
• Si vous concevez une solution multirégionale, répliquez la base de données Azure Cosmos DB dans deux régions ou plus. Si la région principale échoue, une autre région sera promue pour l’écriture. Vous pouvez également déclencher le basculement manuellement. Le kit de développement logiciel effectue une découverte et un routage automatique, le code de l’application continue donc de fonctionner après un basculement. Pendant la période de basculement (généralement quelques minutes), les opérations d’écriture ont une latence plus élevée, étant donné que le kit de développement logiciel est en train de trouver la nouvelle zone d’écriture. Pour plus d'informations, consultez Comment configurer la distribution mondiale dans Azure Cosmos DB for NoSQL.
• Comme solution de secours, conservez le document dans une file d’attente de sauvegarde et traitez cette file plus tard.

Diagnostics. Journalisation de toutes les erreurs côté client.

Stockage de files d'attente

L’écriture d’un message sur le Stockage File d’attente Azure échoue régulièrement.

Détection. Après N nouvelles tentatives, l’opération d’écriture échoue encore.

Récupération :

• Stockez les données dans un cache local et transférez les écritures dans le stockage plus tard, lorsque le service devient disponible.
• Créez une file d’attente secondaire et écrivez dans cette file d’attente si la file d’attente principale n’est pas disponible.

Diagnostics. Utilisez les métriques de stockage.

L’application ne peut pas traiter un message particulier à partir de la file d’attente.

Détection. Spécifique à l’application. Par exemple, le message contient des données non valides, ou la logique métier échoue pour une raison quelconque.

Récupération :

Déplacez le message vers une file d’attente distincte. Exécutez un processus séparé pour examiner les messages dans cette file d’attente.

Envisagez d'utiliser des files d'attente de messagerie Azure Service Bus qui fournissent une fonctionnalité de file d'attente de lettres mortes à cet effet.

Notes

Si vous utilisez des files d’attente de stockage avec WebJobs, le kit de développement logiciel WebJobs fournit la gestion intégrée des messages incohérents. Consultez Utilisation du stockage de file d'attente Azure avec le kit de développement logiciel (SDK) WebJobs.

Diagnostics. Utilisez la journalisation des applications.

Cache Azure pour Redis

La lecture à partir du cache échoue.

Détection. Interceptez StackExchange.Redis.RedisConnectionException.

Récupération :

1. Relance en cas d’échecs temporaires. Azure Cache pour Redis prend en charge la fonctionnalité de nouvelles tentatives intégrée. Pour plus d'informations, consultez Instructions relatives aux nouvelles tentatives d'Azure Cache pour Redis.
2. Traitez les défaillances non temporaires comme un échec de cache, et revenez à la source de données d'origine.

Diagnostics. Utilisez les diagnostics Azure Cache pour Redis.

L’écriture dans le cache échoue.

Détection. Interceptez StackExchange.Redis.RedisConnectionException.

Récupération :

1. Relance en cas d’échecs temporaires. Azure Cache pour Redis prend en charge la fonctionnalité de nouvelles tentatives intégrée. Pour plus d'informations, consultez Instructions relatives aux nouvelles tentatives d'Azure Cache pour Redis.
2. Si l'erreur n'est pas temporaire, ignorez-la et laissez ensuite les autres transactions écrire dans le cache.

Diagnostics. Utilisez les diagnostics Azure Cache pour Redis.

SQL Database

Impossible de se connecter à la base de données dans la région principale.

Détection. La connexion échoue.

Récupération :

• Activer la redondance de zone. En activant la redondance de zone, Azure SQL Database réplique automatiquement vos écritures sur plusieurs zones de disponibilité Azure dans les régions prises en charge. Pour plus d'informations, voir Disponibilité redondante de zone.

• Activez la géo-réplication. Si vous concevez une solution multirégionale, envisagez d'activer la géoréplication active de SQL Database.

  Condition préalable : La base de données doit être configurée pour la géoréplication active. Consultez Géoréplication active de SQL Database.

  • Pour les requêtes, lisez à partir d’un réplica secondaire.
  • Pour les insertions et les mises à jour, basculez manuellement vers un réplica secondaire. Consultez Lancer un basculement planifié ou non planifié pour Azure SQL Database.

  Le réplica utilise une chaîne de connexion différente, vous devrez donc la mettre à jour dans votre application.

Client à court de connexions dans le pool de connexions.

Détection. Interceptez les erreurs System.InvalidOperationException.

Récupération :

• Retentez l’opération.
• En tant qu’un plan d’atténuation, isolez les pools de connexions pour chaque cas d’usage, de sorte qu’un seul cas d’usage ne puisse pas dominer toutes les connexions.
• Augmentez les pools de connexions maximales.

Diagnostics. Journaux d’activité d’application.

La limite de connexion de base de données est atteinte.

Détection. Azure SQL Database limite le nombre de rôles de travail, de connexions et de sessions simultanés. Les limites dépendent du niveau de service. Pour plus d'informations, consultez Limites de ressources Azure SQL Database.

Pour détecter ces erreurs, interceptez System.Data.SqlClient.SqlException et vérifiez la valeur de SqlException.Number pour le code d’erreur SQL. Pour obtenir la liste des codes d’erreur pertinents, consultez l’article Codes d’erreur SQL pour les applications clientes SQL Database : erreurs de connexion de base de données et autres problèmes.

Récupération. Ces erreurs sont considérées comme transitoires, une nouvelle tentative peut donc résoudre le problème. Si vous rencontrez régulièrement ces erreurs, envisagez une mise à l’échelle de la base de données.

Diagnostics. - La requête sys.event_log renvoie les interblocages, les échecs de connexion et les réussites de connexion de base de données.

• Créez une règle d'alerte pour les connexions qui ont échoué.
• Activez l'audit de SQL Database et recherchez les échecs de connexion.

Messagerie Service Bus

Échec de la lecture d’un message à partir d’une file d’attente Service Bus.

Détection. Interceptez les exceptions à partir du kit de développement logiciel client. La classe de base des exceptions Service Bus est MessagingException. Si l’erreur est temporaire, la propriété IsTransient a la valeur True.

Pour plus d’informations, consultez Exceptions de la messagerie Service Bus.

Récupération :

1. Relance en cas d’échecs temporaires. Consultez Instructions relatives aux nouvelles tentatives de Service Bus.
2. Les messages ne pouvant être remis au récepteur sont placés dans une file d’attente de lettres mortes. Utilisez cette file d’attente pour voir les messages non reçus. Notez que la file d’attente de lettres mortes n’est pas nettoyée automatiquement. Les messages y restent jusqu'à ce que vous les récupériez. Consultez Vue d'ensemble des files d'attente de lettres mortes Service Bus.

Échec de l’écriture d’un message vers une file d’attente Service Bus.

Détection. Interceptez les exceptions à partir du kit de développement logiciel client. La classe de base des exceptions Service Bus est MessagingException. Si l’erreur est temporaire, la propriété IsTransient a la valeur True.

Pour plus d’informations, consultez Exceptions de la messagerie Service Bus.

Récupération :

• Le client Service Bus fait automatiquement une nouvelle tentative après les erreurs transitoires. Par défaut, il utilise une temporisation exponentielle. Après avoir atteint le nombre de tentatives ou le délai d’attente maximal, le client lève une exception. Pour plus d'informations, consultez Instructions relatives aux nouvelles tentatives Service Bus.

• Si le quota de file d'attente est dépassé, le client lève l'exception QuotaExceededException. Le message de l'exception donne plus d'informations. Retirez des messages de la file d’attente avant une nouvelle tentative et envisagez l’utilisation du modèle disjoncteur pour éviter les tentatives continues lorsque le quota est dépassé. En outre, assurez-vous que la propriété BrokeredMessage.TimeToLive n’est pas définie sur une valeur trop élevée.

• Dans une région, la résilience peut être améliorée en utilisant des files d'attente ou rubriques partitionnées. Une file d’attente ou une rubrique non partitionnée est affectée à une banque de messagerie. Si cette banque de messagerie n’est pas disponible, toutes les opérations sur cette file d’attente ou rubrique échoueront. Une file d’attente ou une rubrique partitionnée est partitionnée entre plusieurs banques de messagerie.

• Utilisez la redondance de zone pour répliquer automatiquement les modifications entre plusieurs zones de disponibilité. Si une zone de disponibilité échoue, le basculement se produit automatiquement. Pour plus d’informations, consultez la section Meilleures pratiques pour protéger les applications contre les pannes de Service Bus et les sinistres.

• Si vous concevez une solution multirégionale, créez deux espaces de noms Service Bus dans différentes régions et répliquez les messages. Vous pouvez utiliser une réplication active ou passive.

  • Réplication active : le client envoie tous les messages à chaque file d’attente. Le récepteur écoute chaque file d’attente. Les messages ont une balise avec un identificateur unique, afin que le client puisse ignorer les messages en double.
  • Réplication passive : le client envoie les messages à une seule file d’attente. En cas d’erreur, le client effectue un envoi vers une autre file d’attente. Le récepteur écoute chaque file d’attente. Cette approche réduit le nombre de messages en double envoyés. Toutefois, le récepteur doit toujours gérer les messages en double.

  Pour plus d'informations, consultez Exemple de géoréplication et Meilleures pratiques pour protéger les applications contre les pannes de Service Bus et les sinistres.

Messages en double.

Détection. Examinez les propriété MessageId et DeliveryCount du message.

Récupération :

• Si possible, concevez vos opérations de traitement des messages de sorte qu’elles soient idempotentes. Dans le cas contraire, stockez les ID des messages déjà traités et vérifiez l’ID avant de traiter un message.

• Activez la détection des doublons, en créant la file d’attente avec RequiresDuplicateDetection défini sur True. Avec ce paramètre, Service Bus supprime automatiquement n’importe quel message envoyé avec le même MessageId qu’un message précédent. Notez les points suivants :

  • Ce paramètre empêche les messages en double d’être placés dans la file d’attente. Il n’empêche pas un récepteur de traiter le même message plusieurs fois.
  • La détection des doublons est dotée d’une fenêtre de temps. Si un doublon est envoyé au-delà de cette fenêtre, il ne sera pas détecté.

Diagnostics. Journalisation des messages en double.

L’application ne peut pas traiter un message particulier dans la file d’attente.

Détection. Spécifique à l’application. Par exemple, le message contient des données non valides, ou la logique métier échoue pour une raison quelconque.

Récupération :

Il existe deux modes d’échec à prendre en compte.

• Le récepteur détecte l’échec. Dans un tel cas, déplacez le message vers la file d'attente de lettres mortes. Plus tard, exécutez un processus séparé pour examiner les messages dans cette file d’attente.
• Le récepteur échoue au milieu du traitement du message, par exemple en raison d’une exception non prise en charge. Pour gérer ce cas, utilisez le mode PeekLock. Dans ce mode, si le verrou expire, le message est rendu disponible aux autres récepteurs. Si le message dépasse le nombre maximal de diffusions ou la durée de vie, il est automatiquement déplacé vers la file d’attente de lettres mortes.

Pour en savoir plus, consultez Vue d’ensemble des files d’attente de lettres mortes Service Bus.

Diagnostics. Chaque fois que l’application déplace un message dans la file d’attente de lettres mortes, écrivez un événement dans les journaux des applications.

Stockage

L’écriture de données sur Stockage Azure échoue

Détection. Le client reçoit des erreurs lors de l’écriture.

Récupération :

1. Recommencez l’opération pour récupérer après des défaillances temporaires. La stratégie de nouvelles tentatives du kit de développement logiciel client gère cela automatiquement.

2. Implémentez le modèle disjoncteur pour éviter une surcharge de stockage.

3. Si N tentatives échouent, exécutez une procédure de secours appropriée. Par exemple :

   • Stockez les données dans un cache local et transférez les écritures dans le stockage plus tard, lorsque le service devient disponible.
   • Si l’action d’écriture se trouvait dans une étendue transactionnelle, compensez la transaction.

Diagnostics. Utilisez les métriques de stockage.

La lecture des données à partir de Stockage Azure échoue.

Détection. Le client reçoit des erreurs lors de la lecture.

Récupération :

1. Recommencez l’opération pour récupérer après des défaillances temporaires. La stratégie de nouvelles tentatives du kit de développement logiciel client gère cela automatiquement.
2. Pour le stockage RA-GRS, si la lecture depuis le point de terminaison principal échoue, essayez de lire à partir du point de terminaison secondaire. Le kit de développement logiciel client permet de gérer cela automatiquement. Voir Réplication Azure Storage.
3. Si N nouvelles tentatives échouent, effectuez une action de secours pour une dégradation normale. Par exemple, si une image du produit ne peut pas être récupérée à partir du stockage, affichez une image générique d’espace réservé.

Diagnostics. Utilisez les métriques de stockage.

Machine virtuelle

Échec de la connexion à une machine virtuelle principale.

Détection. Erreurs de connexion réseau.

Récupération :

• Déployez au moins deux machines virtuelles principales dans un groupe à haute disponibilité, derrière un équilibreur de charge.
• Si l’erreur de connexion est temporaire, il est possible que TCP arrive à envoyer le message correctement lors d’une nouvelle tentative.
• Implémentez une stratégie de nouvelles tentatives dans l’application.
• Pour les erreurs persistantes ou non temporaires, vous devez implémenter le modèle disjoncteur.
• Si la machine virtuelle appelante dépasse sa limite de sortie réseau, la file d’attente sortante va saturer. Si la file d’attente sortante est constamment pleine, envisagez une montée en charge.

Diagnostics. Journalisation des événements au niveau des limites de service.

Une instance de machine virtuelle est indisponible ou défectueuse.

Détection. Configurez une sonde d’intégrité de Load Balancer, qui signale si l'instance de machine virtuelle est saine. La sonde devrait vérifier si les fonctions essentielles répondent correctement.

Récupération. Pour chaque couche d’application, placez plusieurs instances de machine virtuelle dans le même groupe à haute disponibilité et placez un équilibreur de charge devant les machines virtuelles. Si une sonde ne répond pas, l’équilibreur de charge n’envoie plus de nouvelles connexions à l’instance défectueuse.

Diagnostics. - Utilisez l'analytique des journaux d'activité de Load Balancer.

• Configurer votre système de surveillance pour surveiller tous les points de terminaison d’analyse du fonctionnement.

Un opérateur arrête accidentellement une machine virtuelle.

Détection. N/A

Récupération. Définissez un verrou de ressource avec un niveau ReadOnly. Consultez Verrouiller des ressources avec Azure Resource Manager.

Diagnostics. Utilisez les Journaux d'activité Azure.

WebJobs

La tâche en continu s’arrête lorsque l’hôte SCM est inactif.

Détection. Passez un jeton d’annulation à la fonction WebJob. Pour plus d'informations, consultez Arrêt correct.

Récupération. Activez le paramètre Always On dans l’application web. Pour plus d’informations, consultez Exécuter des tâches en arrière-plan avec les tâches web.

Conception des applications

L’application ne peut pas gérer un pic de requêtes entrantes.

Détection. Dépend de l’application. Symptômes courants :

• Le site Web démarre en renvoyant des codes d’erreur HTTP 5xx.
• Les services dépendants, tels que la base de données ou le stockage, commencent à limiter les requêtes. Recherchez des erreurs HTTP tels que HTTP 429 (trop de demandes), en fonction du service.
• La longueur de la file d’attente HTTP augmente.

Récupération :

• Effectuez un scale-out pour traiter une charge accrue.

• Atténuez les échecs pour éviter que les pannes en cascade interrompent toute l’application. Les stratégies d’atténuation comprennent :

  • Implémentez le Modèle de limitation pour éviter de saturer les systèmes back-end.
  • Utilisez le nivellement de la charge basé sur une file d'attente pour mettre les requêtes en mémoire tampon et les traiter à un rythme approprié.
  • Classez certains clients par priorité. Par exemple, si l’application possède des niveaux gratuits et payants, limitez les clients disposant du niveau gratuit, mais pas ceux disposant d’un niveau payant. Consultez Modèle de file d'attente de priorité.

Diagnostics. Utilisez la Journalisation des diagnostics d'App Service. Utilisez un service tel qu'Azure Log Analytics, Application Insights ou New Relic pour comprendre les journaux de diagnostics.

Un exemple est disponible ici. Il utilise Polly pour les exceptions suivantes :

• 429 – Limitation
• 408 – Délai d’expiration
• 401 – Non autorisé
• 503 ou 5xx – Service indisponible

L’une des opérations d’un flux de travail ou d’une transaction distribuée a échoué.

Détection. Après N nouvelles tentatives, elle échoue toujours.

Récupération :

• En guise de plan d'atténuation, implémentez le modèle Superviseur de l'agent du planificateur pour gérer l'intégralité du workflow.
• N’effectuez pas de nouvelles tentatives après un délai d’expiration. Cette erreur a un faible taux de réussite.
• La file d’attente fonctionne, pour réessayer ultérieurement.

Diagnostics. Journalisation de toutes les opérations (réussies et échouées), y compris les actions de compensation. Utilisez les ID de corrélation pour suivre toutes les opérations situées dans une même transaction.

Un appel vers un service distant a échoué.

Détection. Code d'erreur HTTP.

Récupération :

1. Relance en cas d’échecs temporaires.
2. Si l’appel échoue après N tentatives, effectuez une action de secours. (Spécifique à l’application.)
3. Implémentez le modèle disjoncteur pour éviter des erreurs en cascade.

Diagnostics. Journalisation de tous les échecs d’appel distant.

Étapes suivantes

Consultez Résilience et dépendances dans le Azure Well-Architected Framework. La création d’une récupération après défaillance dans le système doit faire partie intégrante des phases d’architecture et de conception afin d’éviter le risque de défaillance.