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

Remarque

Depuis le 1er juin 2024, toutes les applications App Service nouvellement créées ont la possibilité de générer un nom d’hôte par défaut unique en utilisant la convention d’affectation de noms <app-name>-<random-hash>.<region>.azurewebsites.net. Les noms d’application existants restent inchangés.

Exemple : myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Pour plus d’informations, reportez-vous à Nom d’hôte par défaut unique pour les ressources App Service.

Cet article explique comment utiliser le contrôle d’intégrité dans le portail Azure pour surveiller les 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. Le contrôle d’intégrité procède à la surveillance en effectuant un test ping sur votre application web toutes les minutes, via un chemin d’accès que vous choisissez.

Notez que /api/health n’est qu’un exemple. Il n’existe aucun chemin de contrôle d’intégrité par défaut. Vous devez vérifier que le chemin que vous choisissez est un chemin d’accès valide qui existe dans votre application.

Fonctionnement du contrôle d’intégrité

• Quand un chemin est donné sur votre application, le contrôle d’intégrité effectue un test ping du chemin sur toutes les instances de votre application App Service par intervalles d’une 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 n’est pas 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.
• Une fois l’instance supprimée, le contrôle d’intégrité continue à effectuer les tests ping. 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é retourne 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. Cliquez sur 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 du contrôle 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 une application de fonction, vous devez utiliser un plan d’hébergement premium ou dédié.
• Vous trouverez plus d’informations sur le contrôle d’intégrité sur les applications de fonction ici : Surveiller les applications de fonction à l’aide du 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 définie sur 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, et pour éviter de surcharger les instances saines restantes, pas plus de la moitié des instances seront exclues de l’équilibreur de charge à la fois. Par exemple, si un plan App Service est mis à l’échelle vers quatre instances et que trois d’entre elles ne sont pas saines, seules deux sont exclues. Les deux autres instances (une saine et une non saine) continuent de recevoir des requêtes. Dans le 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 non saines 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. Afin de sécurisé 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

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;
}

Remarque

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

Instances

Une fois le contrôle d’intégrité activé, vous pouvez redémarrer et surveiller l’état de vos instances d’application à partir de l’onglet Instances. L’onglet Instances affiche le nom de votre instance et l’état de l’instance de cette application. Vous pouvez également redémarrer manuellement l’instance à partir de cet onglet.

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 seront également 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 Redémarrer.

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. (Une seule instance peut être remplacée par heure.) Cela affecte également toutes les applications qui utilisent le même plan App Service.

Pour les applications Windows, vous pouvez également 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é. Le fait d’activer la collecte des informations de diagnostic 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 des informations 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 volet Contrôle d’intégrité du portail, sélectionnez Métriques dans la barre d’outils du haut. Cela ouvre un nouveau volet dans lequel vous pouvez voir l’historique des états d’intégrité du site et 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 Quotas et alertes Azure App Service.

Limites

• La vérification d’intégrité peut être activée pour les plans App Service gratuits et partagés. Vous pouvez donc avoir des métriques sur l’intégrité du site et configurer des alertes. Toutefois, étant donné que les sites gratuits et partagés ne peuvent pas effectuer un scale-out, les instances non saines ne seront pas remplacées. Vous devez effectuer une mise à l’échelle vers le niveau De base ou 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 contrôle 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.

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é de 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é ne sera pas 200. Il s’agit d’une redirection (301), qui marque 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 non saine pendant plus d’une heure, l’instance est remplacée uniquement si toutes les autres applications avec le contrôle d’intégrité activé sont également non saines. Les applications pour lesquelles le contrôle d’intégrité n’est pas activé ne seront pas prises en compte.

Exemple

Imaginez que vous disposez de deux applications (ou d’une application avec un emplacement) avec le contrôle d’intégrité activé. Elles sont nommées Application A et Application B et sont sur le même plan App Service et le plan est mis à l’échelle vers quatre 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 saine. 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 non saine sur ces instances. Si Application B est saine, les instances ne sont pas remplacées.

Remarque

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

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

Si toutes les instances de votre application ne sont pas saines, App Service ne supprime pas les instances de l’équilibreur de charge. Dans ce scénario, l’exécution de toutes les instances d’application défectueuses à partir de la rotation de l’équilibreur de charge entraînerait une panne de votre application. Toutefois, le remplacement des instances se produit toujours.

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