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

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.

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.

Configuration

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

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.

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

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

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

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

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.

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