Surveiller l’intégrité des flux de travail standard dans Azure Logic Apps avec un Contrôle d’intégrité (préversion)
S’applique à : Azure Logic Apps (Standard)
Remarque
Cette fonctionnalité est en préversion et est soumise aux conditions d’utilisation supplémentaires des préversions de Microsoft Azure.
Pour permettre à vos flux de travail d’application logique standard de s’exécuter avec une haute disponibilité et des performances de qualité, configurez la fonctionnalité Contrôle d’intégrité sur votre application logique pour surveiller l’intégrité du flux de travail. Cette fonctionnalité garantit la résilience de votre application en vous offrant les avantages suivants :
Surveillance proactive qui vous permet de détecter et résoudre les problèmes avant qu’ils n’affectent vos clients.
Disponibilité accrue grâce à la suppression des instances non saines de l’équilibreur de charge dans Azure.
Récupération automatique grâce au remplacement des instances non saines.
Comment fonctionne le Contrôle d’intégrité dans Azure Logic Apps ?
Le Contrôle d’intégrité est une fonctionnalité de la plateforme Azure App Service qui redirige les requêtes destinées à des instances non saines et les remplace si elles ne deviennent pas saines. Pour une application logique standard, vous pouvez spécifier un chemin d’accès à un flux de travail « intégrité » que vous créez à cet effet et pour que la plateforme Azure App Service effectue un test ping à intervalles réguliers. L’échantillon suivant montre par exemple le flux de travail minimal de base :
Après avoir activé le Contrôle d’intégrité, la plateforme App Service effectue un test ping sur le chemin d’accès au flux de travail spécifié pour toutes les instances d’application logique toutes les minutes. Si l’application logique nécessite un scale-out, Azure crée immédiatement une nouvelle instance. La plateforme App Service effectue un test ping sur le chemin d’accès du flux de travail pour garantir que la nouvelle instance est prête.
Si un flux de travail s’exécutant sur une instance ne répond pas au test ping après 10 requêtes, la plateforme App Service détermine que l’instance n’est pas saine et la supprime de l’équilibreur de charge dans Azure pour cette application logique spécifique. Avec un minimum de deux requêtes, vous pouvez spécifier le nombre requis de requêtes ayant échoué pour déterminer qu’une instance n’est pas saine. Pour plus d’informations sur la substitution du comportement par défaut, consultez Configuration : Surveiller les instances App Service à l’aide d’un Contrôle d’intégrité.
Après que le Contrôle d’intégrité a supprimé l’instance non saine, la fonctionnalité continue d’effectuer un test ping sur l’instance. Si l’instance répond avec un code d’état sain, y compris ceux allant de 200 à 299, le Contrôle d’intégrité renvoie l’instance à l’équilibreur de charge. Toutefois, si l’instance reste non saine pendant une heure, le Contrôle d’intégrité la remplace par une nouvelle. Pour plus d’informations, consultez Que fait App Service des contrôles d’intégrité ?.
Prérequis
Un compte et un abonnement Azure. Si vous n’avez pas encore d’abonnement, vous pouvez vous inscrire pour obtenir un compte Azure gratuitement.
Une ressource d’application logique standard présentant les attributs suivants :
Un plan App Service mis à l’échelle vers deux instances ou plus.
Un flux de travail « intégrité » spécifiquement dédié à l’exécution du contrôle d’intégrité et des éléments suivants :
Se déclenche avec le déclencheur de requête nommé Lors de la réception d’une requête HTTP.
Inclut l’action de requête nommée Réponse. Définissez cette action pour retourner un code de statut inclus entre 200 et 299.
Vous pouvez aussi éventuellement amener ce flux de travail à exécuter d’autres contrôles pour garantir que les services dépendants sont disponibles et fonctionnent comme prévu. En guise de bonne pratique, assurez-vous que le chemin d’accès du Contrôle d’intégrité surveille les composants critiques de votre flux de travail. Par exemple, si votre application dépend d’un système de base de données et de messagerie, assurez-vous que le Contrôle d’intégrité peut accéder à ces composants.
Limites
La longueur du chemin d’accès spécifié doit comporter moins de 65 caractères.
Les modifications apportées au chemin spécifié pour le Contrôle d’intégrité entraînent le redémarrage de votre application logique. Pour réduire l’incidence sur les applications de production, configurez et utilisez des emplacements de déploiement.
Le Contrôle d’intégrité ne suit pas les redirections pour le code de statut 302. Par conséquent, évitez les redirections et veillez à sélectionner un chemin valide qui existe dans votre application.
Configuration du Contrôle d’intégrité
Dans le portail Azure, ouvrez votre ressource d’application logique standard.
Dans le menu de l’application logique, sélectionnez Diagnostiquer et résoudre les problèmes.
Dans la page Diagnostiquer et résoudre les problèmes, dans la zone de recherche, recherchez et sélectionnez Fonctionnalité Contrôle d’intégrité.
Dans la section Fonctionnalité Contrôle d’intégrité, sélectionnez Afficher la solution.
Dans le volet qui s’ouvre, sélectionnez Configurer et activer la fonctionnalité de contrôle d’intégrité.
Sous l’onglet Contrôle d’intégrité, en à côté de Contrôle d’intégrité, sélectionnez Activer.
Sous Chemin d’accès du contrôle d’intégrité, entrez un chemin d’URL valide pour votre flux de travail dans le champ Chemin d'accès, par exemple :
/api/{workflow-name}/triggers/{request-trigger-name}/invoke?api-version=2022-05-01
Enregistrez vos modifications. Dans la barre d’outils, sélectionnez Enregistrer.
Dans votre ressource d’application logique, mettez à jour le fichier host.json en procédant comme suit :
Dans le menu de l’application logique, sous Outils de développement, sélectionnez Outils avancés>Aller.
Dans la barre d’outils KuduPlus, depuis le menu Console de débogage, sélectionnez CMD.
Accédez au dossier site/wwwroot, et à côté du fichier host.json, sélectionnez Modifier.
Dans l’éditeur de fichiers host.json, ajoutez la propriété Workflows.HealthCheckWorkflowName et le nom du flux de travail pour l’intégrité pour activer l’authentification et l’autorisation de contrôle d’intégrité, par exemple :
"extensions": { "workflow": { "settings": { "Workflows.HealthCheckWorkflowName" : "{workflow-name}" } } }
Lorsque vous avez terminé, sélectionnez Enregistrer.
Dépannage
Une fois que j’ai défini le chemin d’accès pour l’intégrité, mon flux de travail pour l’intégrité ne se déclenche pas.
Dans le menu de l’application logique, sélectionnez Diagnostiquer et résoudre les problèmes.
Sous Catégories de résolution des problèmes, sélectionnez Disponibilité et performances.
Recherchez et vérifiez la section code de statut.
Si le code de statut est 401, vérifiez les éléments suivants :
Vérifiez que la propriété Workflows.HealthCheckWorkflowName et le nom de votre flux de travail pour l’intégrité apparaissent correctement.
Confirmez que le chemin spécifié correspond au flux de travail et au nom du déclencheur de requête .
Problèmes courants d’intégrité
Ma ressource d’application logique n’a pas de flux de travail, mais la ressource effectue toujours un scale‑out pour plusieurs instances, ce qui entraîne des coûts.
Ce comportement peut se produire si la ressource d’application logique n’est pas saine, ou typiquement, lorsque la ressource ne peut pas accéder au compte de stockage associé. Essayez de vérifier si le compte de stockage possède un paramètre réseau qui bloque l’accès ou si vous avez une stratégie de pare-feu réseau qui bloque l’accès.
Ma ressource d’application logique a des flux de travail, mais ils ne sont pas en cours d’exécution ou sont peu exécutés. Toutefois, la ressource effectue toujours des scale‑out vers plusieurs instances, ce qui entraîne des coûts.
Vérifiez si la ressource peut accéder au compte de stockage associé.
Par exemple, le compte de stockage a-t-il un paramètre réseau qui bloque l’accès ? Avez-vous une stratégie de pare-feu réseau qui bloque l’accès ?
Si votre flux de travail démarre avec un déclencheur basé sur un fournisseur de services, assurez-vous que le déclencheur fonctionne correctement comme prévu.
L’échec d’un déclencheur basé sur un fournisseur de services peut engendrer une mise à l’échelle inutile, ce qui peut augmenter considérablement vos coûts de facturation.
Par exemple, une erreur courante consiste à définir un déclencheur sans accorder à votre application logique l’autorisation ou l’accès à la destination, comme une file d’attente Service Bus, un conteneur Stockage Blob Azure, etc.
Assurez-vous également de surveiller en permanence ces déclencheurs afin de pouvoir détecter et résoudre rapidement des problèmes.
Mon flux de travail cesse de traiter les messages par intermittence pendant des heures, mais s’exécute correctement la plupart du temps.
Si votre application logique standard utilise l’option d’hébergement nommée Plan de service de flux de travail et qu’elle n’est pas hébergée dans un environnement App Service, vérifiez que la surveillance de l’échelle du runtime est activée et que les instances Always Ready ont une disponibilité définie au moins sur 1.
Dans le Portail Azure, recherchez et ouvrez votre application logique, si elle n’est pas déjà ouverte.
Dans le menu de l’application logique, sous Paramètres, sélectionnez Configuration.
Dans l'onglet Paramètres d'exécution du flux de travail, pour Surveillance de l'échelle d'exécution, sélectionnez le bouton attenant Activé.
Dans la barre d’outils de la page Configuration, sélectionnez Enregistrer.
Dans le menu de l’application logique, sous Paramètres, sélectionnez Scale-out (plan App Service).
Sous App Scale-out, vérifiez que la valeur des instances Always Ready n’est pas définie sur 0.