Configure health checks - Serverless App Engine - Centre de documentation Alibaba Cloud

Après avoir déployé une application sur SAE, utilisez la fonctionnalité de contrôle d’intégrité pour vérifier le bon fonctionnement de votre application et identifier les anomalies. SAE permet de configurer les contrôles d’intégrité lors de la création et du déploiement des applications. Cette rubrique explique comment configurer les contrôles d’intégrité dans la console SAE.

Contexte

Fonctionnement des contrôles d’intégrité

Un contrôle d’intégrité utilise une sonde de liveness (vivacité), de readiness (prêt) ou de startup (démarrage) pour vérifier périodiquement une instance d’application et transmettre les résultats à la console SAE. Cela vous permet de comprendre l’état de santé global de votre service dans un environnement clusterisé et de localiser les incidents.

SAE est construit sur Kubernetes et propose les types de contrôles d’intégrité suivants.

Sonde de liveness (Liveness probe) : détermine si une instance d’application est en cours d’exécution.
- Si la sonde réussit : l’instance d’application est saine et SAE ne prend aucune mesure.
- Si la sonde échoue : l’instance d’application est considérée comme malsaine et SAE redémarre l’instance.
Sonde de readiness (Readiness probe) : détermine si une instance d’application est prête à traiter le trafic entrant.
- Si la sonde réussit : l’instance d’application est prête et SAE lui alloue du trafic.
- Si la sonde échoue : l’instance d’application n’est pas prête. SAE signale une anomalie pour l’instance et ne lui alloue aucun trafic.
Sonde de startup (Startup probe) : détermine si une instance d’application a démarré avec succès.
- Si la sonde réussit : l’instance d’application a démarré avec succès. Les sondes de liveness et de readiness, si elles sont configurées, ne commencent qu’après la réussite de la sonde de startup.
- Si la sonde échoue : l’instance d’application n’a pas réussi à démarrer. SAE signale une anomalie et redémarre automatiquement l’instance.

Critères de réussite et d’échec

Réussite : une sonde est considérée comme réussie lorsque le nombre de vérifications consécutives réussies atteint le seuil de santé spécifié.
Échec : si une seule vérification d’intégrité échoue, SAE continue d’effectuer des vérifications à l’intervalle configuré. Si le nombre d’échecs consécutifs atteint le seuil d’insalubrité spécifié, SAE prend des mesures. En cas d’échec de la sonde de liveness, SAE redémarre l’instance d’application. En cas d’échec de la sonde de readiness, SAE retire l’instance de l’endpoint de service afin qu’elle ne reçoive plus de trafic.

Paramètres des contrôles d’intégrité

SAE utilise les paramètres suivants pour vérifier l’état des applications et des instances d’application.

Délai initial (Initial delay)

Le délai, en secondes, après le démarrage d’une application avant que la première sonde ne commence. Cette valeur doit être supérieure au temps de démarrage de l’application afin d’éviter les échecs des sondes et les redémarrages ultérieurs pendant le déploiement.
Délai d’expiration (Timeout)

Le délai d’expiration d’une seule sonde, en secondes. La valeur par défaut est 1. Par exemple, si vous définissez cette valeur sur 10, une sonde échoue si elle ne reçoit pas de réponse dans un délai de 10 secondes. Si vous définissez ce paramètre sur 0 ou si vous le laissez vide, le délai d’expiration par défaut de 1 seconde est utilisé.
Période (Period)

L’intervalle entre les contrôles d’intégrité, en secondes. La valeur par défaut est 30. Par exemple, si vous définissez cette valeur sur 5, une vérification est effectuée toutes les 5 secondes. Pour accélérer le démarrage, SAE peut exécuter la sonde de readiness plus fréquemment que la période configurée immédiatement après le démarrage d’une instance, ce qui lui permet de recevoir du trafic plus rapidement.

Procédure

Créer une application

Dans la liste des applications SAE, sélectionnez la région et le namespace cibles en haut de la page, puis cliquez sur Create Application. Après avoir configuré les paramètres sur la page basic information, cliquez sur Next: advanced settings.

Modifier une application en cours d’exécution

Avertissement
Le redéploiement d’une application entraîne son redémarrage. Pour éviter les interruptions de service ou d’autres erreurs inattendues, effectuez les opérations de déploiement pendant les heures creuses.

Dans la liste des applications SAE, sélectionnez la région et le namespace cibles en haut de la page, puis cliquez sur l’Application ID de votre application pour accéder à sa page de détails. Dans le volet de navigation de gauche, cliquez sur basic information, puis cliquez sur deploy application dans le coin supérieur droit.

Modifier une application arrêtée

Dans la liste des applications SAE, sélectionnez la région et le namespace cibles en haut de la page, puis cliquez sur l’Application ID de votre application pour accéder à sa page de détails. Cliquez sur basic information, puis cliquez sur Modify Application Configuration.
Développez la section Application health check settings et configurez les paramètres selon vos besoins.

Configuration

Selon vos besoins, activez Enable application instance liveness check (Liveness configuration), Enable application readiness probe (Readiness configuration) ou Enable startup probe configuration. Les paramètres de configuration sont identiques pour les trois types de sondes.
Remarque
- Vous pouvez configurer les sondes de liveness, de readiness et de startup individuellement ou dans n’importe quelle combinaison. Nous vous recommandons de configurer les trois.
- Lorsque les trois contrôles d’intégrité sont configurés, la sonde de startup s’exécute en premier. Les sondes de liveness et de readiness ne commencent qu’après la réussite de la sonde de startup, chacune respectant son délai initial configuré.

Sélectionnez une Check method et configurez ses paramètres.

HTTP request check : vérifie l’intégrité de l’instance en envoyant une requête HTTP. L’instance est saine si le code de statut est compris entre 200 et 399 ; sinon, elle est considérée comme malsaine.
TCP port check : vérifie l’intégrité de l’instance en établissant une connexion socket TCP. L’instance est saine si la connexion réussit ; sinon, elle est considérée comme malsaine.
Executable command check : vérifie l’intégrité de l’instance en exécutant une commande à l’intérieur de celle-ci. L’instance est saine si la commande renvoie un code de sortie égal à 0 ; sinon, elle est considérée comme malsaine.

Requête HTTP

|
**Parameter**
|
**Description**
| | --- | --- | |
**Path**
|
Le chemin d’accès à atteindre sur le serveur HTTP.
| |
**Port**
|
Le port à atteindre sur le serveur HTTP.
| |
**Advanced settings**
|
Développez **advanced settings** pour configurer une vérification facultative qui permet de vérifier si le corps de la réponse contient un mot-clé spécifié.
| |
**Protocol**
|
Sélectionnez **HTTP** ou **HTTPS**.
| |
**initial delay (seconds)**
|
Le délai, en secondes, après le démarrage d’une application avant que la première sonde ne commence. Cette valeur doit être supérieure au temps de démarrage de l’application afin d’éviter les échecs des sondes et les redémarrages ultérieurs pendant le déploiement.
| |
**timeout (seconds)**
|
Le délai d’expiration d’une seule sonde, en secondes. La valeur par défaut est 1. Par exemple, si vous définissez cette valeur sur 10, une sonde échoue si elle ne reçoit pas de réponse dans un délai de 10 secondes. Si vous définissez ce paramètre sur 0 ou si vous le laissez vide, le délai d’expiration par défaut de 1 seconde est utilisé.
| |
**period (seconds)**
|
L’intervalle entre les contrôles d’intégrité, en secondes. La valeur par défaut est 30. Par exemple, si vous définissez cette valeur sur 5, une vérification est effectuée toutes les 5 secondes. Pour accélérer le démarrage, SAE peut exécuter la sonde de readiness plus fréquemment que la période configurée immédiatement après le démarrage d’une instance, ce qui lui permet de recevoir du trafic plus rapidement.
| |
**healthy threshold (times)**
|
Le nombre minimal de réussites consécutives requis pour qu’une sonde soit considérée comme réussie après un échec. Pour une sonde de liveness, cette valeur doit être égale à 1.
| |
**unhealthy threshold (times)**
|
Le nombre d’échecs consécutifs après lequel une sonde est considérée comme ayant échoué.
|

Port TCP

|
**Parameter**
|
**Description**
| | --- | --- | |
**TCP port**
|
Le port TCP à atteindre pour le contrôle d’intégrité.
| |
**initial delay (seconds)**
|
Le délai, en secondes, après le démarrage d’une application avant que la première sonde ne commence. Cette valeur doit être supérieure au temps de démarrage de l’application afin d’éviter les échecs des sondes et les redémarrages ultérieurs pendant le déploiement.
| |
**timeout (seconds)**
|
Le délai d’expiration d’une seule sonde, en secondes. La valeur par défaut est 1. Par exemple, si vous définissez cette valeur sur 10, une sonde échoue si elle ne reçoit pas de réponse dans un délai de 10 secondes. Si vous définissez ce paramètre sur 0 ou si vous le laissez vide, le délai d’expiration par défaut de 1 seconde est utilisé.
| |
**period (seconds)**
|
L’intervalle entre les contrôles d’intégrité, en secondes. La valeur par défaut est 30. Par exemple, si vous définissez cette valeur sur 5, une vérification est effectuée toutes les 5 secondes. Pour accélérer le démarrage, SAE peut exécuter la sonde de readiness plus fréquemment que la période configurée immédiatement après le démarrage d’une instance, ce qui lui permet de recevoir du trafic plus rapidement.
| |
**healthy threshold (times)**
|
Le nombre minimal de réussites consécutives requis pour qu’une sonde soit considérée comme réussie après un échec. Pour une sonde de liveness, cette valeur doit être égale à 1.
| |
**unhealthy threshold (times)**
|
Le nombre d’échecs consécutifs après lequel une sonde est considérée comme ayant échoué.
|

Commande exécutable

Parameter	Description
initial delay (seconds)	Le délai, en secondes, après le démarrage d’une application avant que la première sonde ne commence. Cette valeur doit être supérieure au temps de démarrage de l’application afin d’éviter les échecs des sondes et les redémarrages ultérieurs pendant le déploiement.
timeout (seconds)	Le délai d’expiration d’une seule sonde, en secondes. La valeur par défaut est 1. Par exemple, si vous définissez cette valeur sur 10, une sonde échoue si elle ne reçoit pas de réponse dans un délai de 10 secondes. Si vous définissez ce paramètre sur 0 ou si vous le laissez vide, le délai d’expiration par défaut de 1 seconde est utilisé.
period (seconds)	L’intervalle entre les contrôles d’intégrité, en secondes. La valeur par défaut est 30. Par exemple, si vous définissez cette valeur sur 5, une vérification est effectuée toutes les 5 secondes. Pour accélérer le démarrage, SAE peut exécuter la sonde de readiness plus fréquemment que la période configurée immédiatement après le démarrage d’une instance, ce qui lui permet de recevoir du trafic plus rapidement.
healthy threshold (times)	Le nombre minimal de réussites consécutives requis pour qu’une sonde soit considérée comme réussie après un échec. Pour une sonde de liveness, cette valeur doit être égale à 1.
unhealthy threshold (times)	Le nombre d’échecs consécutifs après lequel une sonde est considérée comme ayant échoué.
Command	La commande à exécuter à l’intérieur de l’instance. Pour plus d’informations sur les commandes de sonde, consultez Configure Probes dans la documentation Kubernetes. Remarque SAE fournit deux interpréteurs shell : >_ /bin/sh >_ /bin/bash Exemple : la commande `cat /tmp/healthy` vérifie périodiquement l’existence du fichier `/tmp/healthy`. La vérification réussit (renvoie 0) si le fichier existe.

Vérifier les résultats

Après avoir configuré les contrôles d’intégrité, accédez à la page basic information de l’application et cliquez sur l’onglet Instances. Dans la zone Default Group, vous pouvez afficher l’état d’exécution de chaque instance. Placez le curseur sur l’icône d’état pour afficher les détails de la configuration du contrôle d’intégrité.

Running status	Description
Contrôle d’intégrité de liveness non configuré Un avertissement recommande de configurer une sonde de liveness pour les opérations et la maintenance automatisées. L’état actuel de l’instance est Running. Contrôle d’intégrité de readiness non configuré La console vous invite à configurer une sonde de readiness pour les opérations et la maintenance automatisées. L’état actuel de l’instance est Running. Contrôles d’intégrité de liveness et de readiness non configurés L’état de l’instance d’application est Running, mais un avertissement en haut de la page recommande de configurer des sondes de liveness et de readiness pour les opérations et la maintenance automatisées.	Indique qu’aucun contrôle d’intégrité n’est configuré pour l’instance. Remarque Nous vous recommandons de configurer à la fois les sondes de liveness et de readiness. Pour en savoir plus sur la configuration des contrôles d’intégrité, cliquez sur View Details pour ouvrir la documentation.
Échec des contrôles d’intégrité de liveness et de readiness L’état de l’instance est Running, mais un message rouge Health check failed s’affiche.	Indique que le contrôle d’intégrité a échoué et que l’instance est malsaine. Remarque Placez le curseur sur l’état de l’instance pour afficher la raison de l’échec. Pour connaître les étapes de résolution, cliquez sur Troubleshooting Guide.
Contrôle d’intégrité réussi L’état de l’instance est Running en vert, sans message d’avertissement.	Indique que le contrôle d’intégrité a réussi et que l’instance est saine.

Causes courantes d’échec des contrôles d’intégrité

Le délai initial est trop court, ce qui entraîne le démarrage du contrôle d’intégrité avant que l’application ne soit entièrement initialisée. Augmentez le délai et réessayez.
La configuration du contrôle d’intégrité est incorrecte. Vérifiez le port et le chemin d’accès.
Le service subit une charge excessive. Vérifiez les données de surveillance de l’application pour le confirmer. Si tel est le cas, augmentez le nombre d’instances, utilisez un type d’instance plus puissant ou réduisez la taille du tas JVM.
L’application ne parvient pas à démarrer. Essayez de désactiver les contrôles d’intégrité pour diagnostiquer le problème. Si l’application ne parvient toujours pas à démarrer, il peut être nécessaire d’optimiser votre code.