Superviser des instances App Service à l’aide du contrôle d’intégrité

Cet article utilise le contrôle d’intégrité dans le portail Azure pour superviser des instances App Service. Le contrôle de santé augmente la disponibilité de votre application en reroutant les requêtes en dehors des instances non saines et en remplaçant les instances si elles demeurent non saines. Pour ce faire, il effectue un test ping chaque minute sur le chemin de votre application web de votre choix.

Notez que /api/health n’est qu’un exemple ajouté à des fins d’illustration. Nous ne créons pas de chemin d’accès de contrôle d’intégrité par défaut. Vous devez vérifier que le chemin que vous sélectionnez est un chemin d’accès valide qui existe dans votre application

Que fait App Service avec les contrôles d’intégrité ?

• Quand un chemin est donné sur votre application, le contrôle d’intégrité effectue un test ping de ce chemin sur toutes les instances de votre application App Service par intervalles de 1 minute.
• Si une application web qui s’exécute sur une instance donnée ne répond pas avec un code d’état compris entre 200 et 299 (inclus) après 10 requêtes, App Service détermine qu’elle est non saine et la supprime de l’équilibreur de charge pour cette application web. Pour qu’une instance soit considérée comme non saine, le nombre requis de requêtes en échec peut être configuré avec un minimum de 2 requêtes.
• Après cette suppression, le contrôle d’intégrité continue d’effectuer un test ping sur l’instance qui n’est pas saine. Si l’instance commence à répondre avec un code d’état sain (200-299), elle est retournée à l’équilibreur de charge.
• Si l’application web qui s’exécute sur une instance reste non saine pendant une heure, l’instance est remplacée par une nouvelle.
• Dans le cadre d’un scale-out, App Service effectue un test ping sur le chemin de contrôle d’intégrité pour vérifier que de nouvelles instances sont prêtes.

Notes

• Le contrôle d’intégrité ne suit pas les redirections 302.
• Une instance au plus sera remplacée chaque heure, avec un maximum de trois instances par jour et par plan App Service.
• Si votre contrôle d’intégrité donne l’état Waiting for health check response, la vérification est susceptible d’échouer en raison d’un code d’état HTTP 307, ce qui peut se produire si vous avez activé la redirection HTTPS, mais avez désactivé HTTPS Only.

Activer le contrôle d’intégrité

1. Pour activer le contrôle d’intégrité, accédez au portail Azure et sélectionnez votre application App Service.
2. Sous Supervision, sélectionnez Contrôle d’intégrité.
3. Sélectionnez Activer et fournissez un chemin d’URL valide pour votre application, par exemple /health ou /api/health.
4. Sélectionnez Enregistrer.

Notes

• Votre plan App Service doit être mis à l’échelle vers deux instances ou plus pour utiliser pleinement le contrôle d’intégrité.
• Le chemin du contrôle d’intégrité doit vérifier les composants critiques de votre application. Par exemple, si votre application dépend d’une base de données et d’un système de messagerie, le point de terminaison de contrôle d’intégrité doit se connecter à ces composants. Si l’application ne peut pas se connecter à un composant critique, le chemin doit retourner un code de réponse de niveau 500 pour indiquer que l’application est non saine. En outre, si le chemin ne retourne pas de réponse dans un délai d’une minute, le test ping de vérification d’intégrité est considéré comme non sain.
• Lors de la sélection du chemin d’accès de contrôle d’intégrité, veillez à sélectionner un chemin qui renvoie un code d’état 200 uniquement lorsque l’application est complètement initiée.
• Pour utiliser le bilan de santé sur votre application de fonction, vous devez utiliser un plan d'hébergement premium ou dédié.
• Vous trouverez des détails sur le contrôle d’intégrité sur les applications de fonction ici : Surveiller les applications de fonction en utilisant le contrôle d’intégrité.

Attention

Les modifications apportées à la configuration du contrôle d’intégrité entraînent le redémarrage de votre application. Pour réduire l’impact sur les applications de production, nous vous recommandons de configurer des emplacements de préproduction et de basculer vers des emplacements de production.

Configuration

En plus de la configuration des options de contrôle d’intégrité, vous pouvez aussi configurer les paramètres d’application suivants :

Nom du paramètre d’application	Valeurs autorisées	Description
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	Nombre requis de demandes ayant échoué pour qu’une instance soit considérée comme défectueuse et supprimée de l’équilibreur de charge. Par exemple, quand la valeur est 2, vos instances sont supprimées à l’issue de 2 échecs de test ping. (La valeur par défaut est 10)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Par défaut, pas plus de la moitié des instances seront exclues de l’équilibreur de charge en une fois pour éviter de surcharger les instances intègres restantes. Par exemple, si un plan App Service est mis à l’échelle vers quatre instances et que trois d’entre elles ne sont pas intègres, seules deux sont exclues. Les deux autres instances (une saine et une non saine) continuent de recevoir des requêtes. Dans le pire des cas, où aucune instance n’est saine, aucune n’est exclue. Pour remplacer ce comportement, définissez le paramètre d’application sur une valeur comprise entre 1 et 100. Plus la valeur est élevée, plus le nombre d’instances défectueuses supprimées est élevé (la valeur par défaut est 50).

Authentification et sécurité

Le contrôle d’intégrité s’intègre aux fonctionnalités d’authentification et d’autorisation d’App Service. Aucun autre paramètre n’est nécessaire si ces fonctionnalités de sécurité sont activées.

Si vous utilisez votre propre système d’authentification, le chemin du contrôle d’intégrité doit autoriser l’accès anonyme. Pour sécuriser le point de terminaison du contrôle d’intégrité, vous devez d’abord utiliser des fonctionnalités comme des restrictions d’adresse IP, des certificats clients ou un réseau virtuel pour restreindre l’accès à l’application. Une fois ces fonctionnalités en place, vous pouvez authentifier la demande de contrôle d’intégrité en inspectant l’en-tête x-ms-auth-internal-token et en vérifiant qu’elle correspond au hachage SHA256 de la variable d’environnement WEBSITE_AUTH_ENCRYPTION_KEY. En cas de correspondance, la requête de contrôle d’intégrité est valide et provient d’App Service.

Remarque

Spécifiquement pour l’authentification Azure Functions, la fonction qui sert de point de terminaison de contrôle d’intégrité doit autoriser un accès anonyme.

.NET

using System;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
    var sha = System.Security.Cryptography.SHA256.Create();
    String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return hash == headerValue;
}

Python

from hashlib import sha256
import base64
import os

def header_matches_env_var(header_value):
    """
    Returns true if SHA256 of header_value matches WEBSITE_AUTH_ENCRYPTION_KEY.
    
    :param header_value: Value of the x-ms-auth-internal-token header.
    """
    
    env_var = os.getenv('WEBSITE_AUTH_ENCRYPTION_KEY')
    hash = base64.b64encode(sha256(env_var.encode('utf-8')).digest()).decode('utf-8')
    return hash == header_value

Java

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import java.nio.charset.StandardCharsets;

public static Boolean headerMatchesEnvVar(String headerValue) throws NoSuchAlgorithmException {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    String envVar = System.getenv("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = new String(Base64.getDecoder().decode(digest.digest(envVar.getBytes(StandardCharsets.UTF_8))));
    return hash.equals(headerValue);
}

Node.JS

var crypto = require('crypto');

function envVarMatchesHeader(headerValue) {
    let envVar = process.env.WEBSITE_AUTH_ENCRYPTION_KEY;
    let hash = crypto.createHash('sha256').update(envVar).digest('base64');
    return hash == headerValue;
}

Notes

L’en-tête x-ms-auth-internal-token est disponible uniquement sur Windows App Service.

Instances

Une fois la vérification d’intégrité activée, vous pouvez redémarrer et surveiller l’état de vos instances d’application par l’onglet Instances. L’onglet Instances affiche le nom de votre instance et l’état de l’instance de cette application, tout en vous donnant la possibilité de redémarrer manuellement l’instance.

Si l’état de votre instance d’application est non sain, vous pouvez la redémarrer manuellement à l’aide du bouton Redémarrer dans la table. N’oubliez pas que toutes les autres applications hébergées sur le même plan App Service que l’instance vont également être affectées par le redémarrage. Si d’autres applications utilisent le même plan App Service que l’instance, elles sont répertoriées dans le panneau d’ouverture à partir du bouton de redémarrage.

Si vous redémarrez l’instance et que le processus de redémarrage échoue, vous aurez alors la possibilité de remplacer le rôle de travail (1 seule instance peut être remplacée par heure). Cela affecte également toutes les applications qui utilisent le même plan App Service.

Les applications Windows ont aussi la possibilité d’afficher les processus via l’Explorateur de processus. Cela vous apporte des informations supplémentaires sur les processus de l’instance, notamment le nombre de threads, la mémoire privée et le temps processeur total.

Collecte d’informations de diagnostic

Pour les applications Windows, vous avez la possibilité de collecter des informations de diagnostic sous l’onglet Contrôle d’intégrité. L’activation de la collecte de diagnostics ajoute une règle de réparation automatique qui crée des vidages de mémoire pour les instances non saines et les enregistre dans un compte de stockage désigné. L’activation de cette option modifie les configurations de réparation automatique. S’il existe des règles de réparation automatique, nous vous recommandons de la configurer via App Service diagnostics.

Une fois la collecte de diagnostics activée, vous pouvez créer ou choisir un compte de stockage existant pour vos fichiers. Vous pouvez uniquement sélectionner des comptes de stockage dans la même région que votre application. N’oubliez pas que l’enregistrement redémarre votre application. Après l’enregistrement, si vos instances de site sont jugées non saines après des tests ping continus, vous pouvez accéder à votre ressource de compte de stockage et afficher les vidages de mémoire.

Surveillance

Après avoir fourni le chemin de contrôle d’intégrité de votre application, vous pouvez superviser l’intégrité de votre site à l’aide d’Azure Monitor. Dans le panneau Contrôle d’intégrité du portail, sélectionnez Métriques dans la barre d’outils du haut. Un nouveau panneau s’ouvre, dans lequel vous pouvez voir l’état d’intégrité historique du site et une option pour créer une règle d’alerte. Les métriques de contrôle d’intégrité agrègent les tests Ping réussis et les échecs d’affichage uniquement quand l’instance est considérée comme non saine d’après la configuration du contrôle d’intégrité. Pour plus d’informations sur la surveillance de vos sites, consultez le guide sur Azure Monitor.

Limites

• Le contrôle d’intégrité peut être activé pour les Plans App Service Gratuits et Partagés : vous pouvez donc obtenir des métriques concernant l’intégrité du site et définir des alertes, mais comme les sites Gratuits et Partagés ne peuvent pas faire l’objet d’un scale-out, les instances non saines ne seront pas remplacées. Vous devez effectuer une mise à l’échelle vers le niveau de Baseou une version ultérieure, afin de pouvoir effectuer une progression jusqu’à 2 instances ou plus et tirer parti de tous les avantages du contrôle d’intégrité. Cette option est recommandée pour les applications de production, car elle augmente la disponibilité et les performances de votre application.
• Le plan App Service peut avoir un maximum d’une instance défectueuse remplacée par heure et, au maximum, trois instances par jour.
• Il existe une limite non configurable sur le nombre total d’instances remplacées par le contrôle d’intégrité par unité d’échelle. Si cette limite est atteinte, aucune instance non saine n’est remplacée. Cette valeur est réinitialisée toutes les 12 heures.

Forum Aux Questions

Que se passe-t-il si mon application s’exécute sur une seule instance ?

Si votre application est mise à l’échelle vers une seule instance et que celle-ci devient non saine, elle ne sera pas supprimée de l’équilibreur de charge, car cela entraînerait l’arrêt complet de votre application. Cependant, après une heure de pings non sains continus, l’instance est remplacée. Effectuez un scale-out vers deux instances ou plus pour profiter du reroutage du contrôle d’intégrité. Si votre application s’exécute sur une instance unique, vous pouvez toujours utiliser la fonctionnalité de surveillance du contrôle d’intégrité pour effectuer le suivi de l’intégrité de votre application.

Pourquoi les requêtes de contrôle d’intégrité ne s’ouvrent-elles pas dans mes journaux de serveur web ?

La demande de contrôle d’intégrité étant envoyée en interne à votre site, la demande n’apparaît pas dans les journaux du serveur web. Vous pouvez ajouter des instructions de journal dans votre code de contrôle d’intégrité pour conserver les journaux lorsque votre chemin d’accès de contrôle d’intégrité est interrogé.

Les demandes de contrôle d’intégrité sont-elles envoyées via HTTP ou HTTPS ?

Sur Windows App Service, les demandes de vérification d’intégrité sont envoyées via HTTPS quand HTTPS uniquement est activé sur le site. Dans le cas contraire, elles sont envoyées via HTTP. Sur Linux App Service, les requêtes de vérification d’intégrité sont envoyées sur seulement HTTP et ne peuvent pas être envoyées sur HTTPS à l’heure actuelle.

Le contrôle d’intégrité suivant le code d’application configuré redirige-t-il entre le domaine par défaut et le domaine personnalisé ?

Non, la fonctionnalité Contrôle d’intégrité effectue un test ping sur le chemin du domaine par défaut de l’application web. S’il existe une redirection du domaine par défaut vers un domaine personnalisé, le code d’état retourné par le contrôle d’intégrité n’est pas 200, mais une redirection (301), qui va marquer le Worker comme non sain.

Que se passe-t-il si j’ai plusieurs applications sur le même Plan App Service ?

Les instances non saines seront toujours supprimées de la rotation de l’équilibreur de charge, quelles que soient les autres applications du plan App Service (jusqu’au pourcentage spécifié dans WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT). Quand une application sur une instance reste défectueuse pendant plus d’une heure, l’instance est remplacée uniquement si toutes les autres applications avec contrôle d’intégrité activé sont également défectueuses. Les applications pour lesquelles le contrôle d’intégrité n’est pas activé ne seront pas prises en compte.

Exemple

Imaginez que vous avez deux applications (ou une application avec un emplacement) avec le contrôle d’intégrité activé, appelées Application A et Application B. Elles se trouvent sur le même plan App Service et le plan fait l’objet d’un scale-out vers 4 instances. Si l’application A devient défectueuse sur deux instances, l’équilibreur de charge cesse d’envoyer des demandes à l’application A sur ces deux instances. Les demandes sont toujours acheminées vers l’application B sur les instances en supposant que l’application B est intègre. Si l’application A reste défectueuse pendant plus d’une heure sur ces deux instances, ces instances sont remplacées uniquement si l’application B est également défectueuse sur ces instances. Si Application B est saine, l’instance n’est pas remplacée.

Notes

S’il existe un autre site ou un autre emplacement du Plan (Site C) sans contrôle d’intégrité activé, celui-ci ne sera pas pris en compte pour le remplacement de l’instance.

Que se passe-t-il si aucune de mes instances n’est intègre ?

Dans le cas où toutes les instances de votre application sont non saines, App Service supprime des instances de l’équilibreur de charge. Dans ce scénario, l’exécution de toutes les instances d’application non saines à partir de la rotation de l’équilibreur de charge entraînera une panne de votre application. Toutefois, le remplacement d’instance sera honoré.

Le contrôle d’intégrité fonctionne-t-il sur App Service Environment ?

Oui, le contrôle d’intégrité est disponible pour App Service Environment v3, mais pas pour les versions 1 ou 2. Si vous utilisez les versions antérieures d’App Service Environment, vous pouvez utiliser la fonctionnalité de migration pour migrer votre App Service Environment vers la version 3.

Étapes suivantes

• Créez une alerte de journal d’activité pour surveiller toutes les opérations du moteur de mise à l’échelle automatique dans votre abonnement.
• Créez une alerte de journal d’activité pour surveiller tous les échecs d’opérations de diminution et d’augmentation de la taille des instances de la mise à l’échelle automatique dans votre abonnement
• Informations de référence sur les variables d’environnement et les paramètres d’application