[JAVA] Essayez Health Check sur Azure App Service.

introduction

Bonjour.

Utilisez-vous App Service?

C'est un PaaS typique qui fonctionne simplement en déployant une application web, mais quand il s'agit de fonctionnement, il y a un problème en termes de résilience. Lorsque l'App Service est déployé, la vérification de l'état de l'application n'est pas activée.Ainsi, même si l'application ne répond pas normalement, l'équilibreur de charge interne continue de distribuer les demandes à l'application défectueuse. Lorsque cela se produit, cela peut être une source de problèmes, tels que des problèmes de surveillance de l'état du service ou la distribution continue de demandes d'utilisateurs spécifiques à des instances défectueuses.

Par conséquent, je vais essayer "Health Check" cette fois. Bien qu'il s'agisse d'un aperçu, vous pouvez l'essayer immédiatement sur l'environnement Azure qui peut être déployé maintenant, nous allons donc vérifier cette fonction.

Cliquez ici pour la documentation: https://github.com/projectkudu/kudu/wiki/Health-Check-(Preview)

Préparation au bilan de santé

Health Check est une fonction qui vérifie la santé HTTP de chaque instance de l'application et déconnecte l'instance si la réponse est incorrecte. Actuellement, il n'est pas possible de définir le seuil de détection, mais si HTTP Ping continue à échouer 5 fois, il sera exclu de la destination de distribution de la demande et l'instance anormale sera automatiquement redémarrée. Cela devient le comportement. Le succès ou l'échec de HTTP Ping est évalué en fonction du fait qu'une demande GET est envoyée à un URI spécifique et qu'il y a une réponse avec un code d'état dans les 200 dans les 2 minutes.

Pour tirer parti de cette fonctionnalité, vous devez modifier la ressource App Service cible directement dans Azure Resource Explorer (https://resources.azure.com/). (Actuellement, il est un peu intéressant d'utiliser l'outil de prévisualisation pour profiter de la fonction de prévisualisation)

Accédez à l'Explorateur de ressources et accédez à "abonnements" -> "Abonnements" -> "resourceGroups" -> "Target Resource Groups" -> "providers" -> "Microsoft.Web" -> "sites" -> " Développez l'arborescence avec l'AppService cible "->" config ". Entrez en mode d'édition de la ressource de configuration et réécrivez le "healthCheckPath" ci-dessous. Par défaut, il est nul et la fonction Health Check peut être activée en définissant ici un chemin arbitraire. Cette fois, j'ai choisi / status.

Ensuite, implémentez l'URI correspondant à / status du côté application. Il s'agit d'une implémentation de l'API REST qui vérifie si l'application fonctionne correctement et renvoie un code d'état 200 s'il n'y a pas de problème. Le contenu varie d'une application à l'autre, mais en général, vérifiez la communication avec les services externes (Storage Blob, SQL Database, etc.) utilisés par l'application et dites OK si c'est normal. Implémentez l'API. Puisqu'il s'agit d'une vérification, nous avons implémenté une application Spring Boot qui vous permet de spécifier le code d'état qui sera la valeur de retour dans PUT. L'exemple de code est le suivant.

StatucController.java

package com.example.springboot;
import java.net.InetAddress;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;

@RestController
@RequestMapping(value = "/status")
public class StatusController {
    private static HttpStatus status = HttpStatus.OK;

    @GetMapping
    public ResponseEntity<String> get() {
        return new ResponseEntity<String>(this.getLocalhost() + "/" + status.getReasonPhrase(), status);
    }

    @PutMapping
    public ResponseEntity<String> put(@RequestParam(name="code", defaultValue = "200") Integer code) {
        switch (code.intValue()) {
            case 200:
                status = HttpStatus.OK;
                break;
            case 500:
                status = HttpStatus.INTERNAL_SERVER_ERROR;
                break;
            case 400:
                status = HttpStatus.BAD_REQUEST;
                break;
            case 502:
                status = HttpStatus.BAD_GATEWAY;
                break;
            default:
                status = HttpStatus.OK;
                break;
        }
        return new ResponseEntity<String>(this.getLocalhost() + "/" + status.getReasonPhrase(), status);
    }

    private String getLocalhost() {
        try {
            return InetAddress.getLocalHost().getHostAddress();
        } catch(Exception e) {
            e.printStackTrace();
            return "0.0.0.0";
        }
    }
}

Contrôle de fonctionnement

Après avoir déployé l'application sur App Service, accédez à l'application dans Chrome. C'est une application simple, mais l'adresse IP (172.16.1.5) est affichée. Cette adresse IP sera l'adresse IP interne de chaque instance d'App Service, ce sera donc les informations permettant d'identifier l'instance à laquelle cette session se connecte.

Cette fois, j'ai essayé d'accéder à partir d'Edge. Seule l'adresse est différente de ce que vous voyez dans Chrome. L'équilibreur de charge interne d'App Service fonctionne sur Sticky.Par conséquent, en principe, vous accédez à la même instance à chaque fois, même si vous avez plusieurs instances de backend. (À propos, la pondération de la distribution de l'équilibreur de charge semble être liée à la quantité d'accès, et Chrome a rechargé environ 10 fois pour se connecter à différentes instances.)

Utilisez maintenant Postman pour accéder à / status. J'ai pu confirmer qu'il a été renvoyé avec un code d'état 200. Cela se connecte à une instance de 172.16.1.5. Modifions maintenant la réponse de / status afin qu'elle renvoie un code d'état 500. Dans cette application de vérification, en définissant de manière dynamique le code d'état HTTP renvoyé par / status, on s'attend à ce qu'une erreur dans l'application soit détectée et que l'instance anormale soit éliminée et redémarrée du côté App Service. Je suis.

Attendez environ 10 minutes et essayez de mettre à jour le côté Chrome. L'adresse IP a changé en 172.16.1.2 et il semble que l'instance a été redémarrée. Au cas où, je vérifierai avec Postman. De même, la destination d'accès est devenue 172.16.1.2. À partir de là, il peut être confirmé que la fonction de vérification de l'état fonctionne, que l'instance considérée comme anormale est déconnectée et redémarrée.

Je vais également le vérifier du côté du portail Azure. La ligne orange est l'instance qui a été intentionnellement modifiée pour rendre la réponse à HTTP Ping anormale cette fois. Sur la métrique, vous pouvez déterminer que l'instance n'a pas répondu de 14h59 à 15h14. Après cela, le service a été restauré car il a été redémarré automatiquement.

La fonction Health Check doit être implémentée côté application, mais c'est une fonction efficace pour améliorer la récupérabilité du service. Cette fois, je n'ai vérifié que le comportement de base, mais j'aimerais prendre le temps de vérifier le comportement détaillé.

C'est tout pour essayer Health Check sur App Service.