[JAVA] Versuchen Sie Health Check für Azure App Service.

Einführung

Hallo.

Verwenden Sie den App Service?

Es ist ein typisches PaaS, das nur durch die Bereitstellung einer Webanwendung funktioniert. Beim Betrieb gibt es jedoch ein Problem hinsichtlich der Ausfallsicherheit. In dem Zustand, in dem App Service bereitgestellt wird, ist die Integritätsprüfung für die App nicht aktiviert. Selbst wenn die App nicht normal reagiert, verteilt der interne Load Balancer weiterhin Anforderungen an die fehlerhafte App. In diesem Fall kann dies zu Problemen führen, z. B. zu Problemen bei der Überwachung des Dienstzustands oder zur fortgesetzten Verteilung bestimmter Benutzeranforderungen an fehlerhafte Instanzen.

Daher werde ich diesmal "Health Check" versuchen. Obwohl es sich um eine Vorschau handelt, können Sie sie sofort in der Azure-Umgebung ausprobieren, die jetzt bereitgestellt werden kann. Daher werden wir diese Funktion überprüfen.

Klicken Sie hier für die Dokumentation: https://github.com/projectkudu/kudu/wiki/Health-Check-(Preview)

Vorbereitung auf den Gesundheitscheck

Health Check ist eine Funktion, die den HTTP-Zustand jeder Anwendungsinstanz überprüft und die Instanz trennt, wenn die Antwort falsch ist. Derzeit ist es nicht möglich, den Erkennungsschwellenwert festzulegen. Wenn HTTP-Ping jedoch fünfmal nicht erfolgreich ist, wird es vom Anforderungsverteilungsziel ausgeschlossen und die abnormale Instanz wird automatisch neu gestartet. Es wird das Verhalten. Der Erfolg oder Misserfolg von HTTP-Ping wird basierend darauf beurteilt, ob eine GET-Anforderung an einen bestimmten URI gesendet wird und innerhalb von 2 Minuten eine Antwort mit einem Statuscode in den 200er Jahren erfolgt.

Um diese Funktion nutzen zu können, müssen Sie die App Service-Zielressource direkt im Azure Resource Explorer (https://resources.azure.com/) bearbeiten. (Derzeit ist es etwas interessant, das Vorschau-Tool zu verwenden, um die Vorschaufunktion zu nutzen.)

Gehen Sie zum Ressourcen-Explorer und gehen Sie zu "Abonnements" -> "Abonnements" -> "Ressourcengruppen" -> "Zielressourcengruppen" -> "Anbieter" -> "Microsoft.Web" -> "Websites" -> " Erweitern Sie den Baum mit dem Ziel-AppService "->" config ". Rufen Sie den Bearbeitungsmodus der Konfigurationsressource auf und schreiben Sie den folgenden "healthCheckPath" neu. Standardmäßig ist es null, und die Health Check-Funktion kann aktiviert werden, indem hier ein beliebiger Pfad definiert wird. Dieses Mal habe ich / status gewählt.

Implementieren Sie als Nächstes den URI, der / status auf der Anwendungsseite entspricht. Dies ist eine Implementierung der REST-API, die überprüft, ob die App ordnungsgemäß funktioniert, und einen 200-Statuscode zurückgibt, wenn keine Probleme auftreten. Der Inhalt variiert von App zu App. Überprüfen Sie jedoch im Allgemeinen die Kommunikation mit externen Diensten (Storage Blob, SQL-Datenbank usw.), die von der App verwendet werden, und sagen Sie OK, wenn dies normal ist. Implementieren Sie die API. Da dies eine Überprüfung ist, haben wir eine Spring Boot-App implementiert, mit der Sie den Statuscode angeben können, der der Rückgabewert in PUT sein soll. Der Beispielcode lautet wie folgt.

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

Funktionsprüfung

Greifen Sie nach der Bereitstellung der App im App Service auf die App in Chrome zu. Es ist eine einfache App, aber die IP-Adresse (172.16.1.5) wird angezeigt. Diese IP-Adresse ist die interne IP-Adresse für jede Instanz des App-Dienstes. Sie gibt also an, mit welcher Instanz diese Sitzung eine Verbindung herstellt.

Diesmal habe ich versucht, von Edge aus zuzugreifen. Nur die Adresse unterscheidet sich von der in Chrome. Der interne Load Balancer von App Service funktioniert mit Sticky, sodass Sie im Prinzip jedes Mal zur gleichen Instanz wechseln, auch wenn Sie mehrere Backend-Instanzen haben. (Übrigens scheint die Gewichtung der Load-Balancer-Verteilung mit der Zugriffsmenge in Beziehung zu stehen, und Chrome wurde etwa zehnmal neu geladen, um eine Verbindung zu verschiedenen Instanzen herzustellen.)

Verwenden Sie jetzt Postman, um auf / status zuzugreifen. Ich konnte bestätigen, dass es mit einem 200-Statuscode zurückgegeben wurde. Dies stellt eine Verbindung zu einer Instanz von 172.16.1.5 her. Ändern wir nun die Antwort von / status so, dass ein 500-Statuscode zurückgegeben wird. In dieser Überprüfungs-App wird durch dynamisches Festlegen des von / status zurückgegebenen HTTP-Statuscodes erwartet, dass ein Fehler in der App erkannt wird und die abnormale Instanz auf der Seite des App-Dienstes beseitigt und neu gestartet wird. Ich bin.

Warten Sie etwa 10 Minuten und versuchen Sie, die Chrome-Seite zu aktualisieren. Die IP wurde in 172.16.1.2 geändert und es scheint, dass die Instanz neu gestartet wurde. Nur für den Fall, ich werde es mit Postman überprüfen. Ebenso wurde das Zugriffsziel in 172.16.1.2 geändert. Daraus kann bestätigt werden, dass die Health Check-Funktion ausgeführt wird, die als abnormal ermittelte Instanz getrennt und neu gestartet wird.

Ich werde es auch auf der Azure-Portalseite überprüfen. Die orange Linie ist die Instanz, die absichtlich geändert wurde, um die Antwort auf HTTP-Ping diesmal abnormal zu machen. Anhand der Metrik können Sie feststellen, dass die Instanz von 14:59 bis 15:14 nicht reagiert hat. Danach wurde der Dienst wiederhergestellt, da er automatisch neu gestartet wurde.

Die Health Check-Funktion muss auf der Anwendungsseite implementiert werden, ist jedoch eine effektive Funktion zur Verbesserung der Wiederherstellbarkeit des Dienstes. Dieses Mal habe ich nur das grundlegende Verhalten überprüft, aber ich möchte mir etwas Zeit nehmen, um das detaillierte Verhalten zu überprüfen.

Das war's, um Health Check on App Service auszuprobieren.