Immer noch gesund? Änderungen von MicroProfile Health 2.0 vs. 1.0

In meinem Post https://javaeeblog.wordpress.com/2019/01/27/alles-gesund-health-checking-mit-microprofile-health habe ich einen Überblick über MicroProfile Health in der Version 1.0 gegeben. Mittlerweile ist die Version 2.0 erschienen (als Teil von MicroProfile 3.0), woduch einige – teilweise inkompatible – Änderungen einhergehen:

  • Die Prüfungen werden nun in Tests der Verfügbarkeit (Liveness) und Bereitschaft (Readiness) unterteilt, um so besser die Anforderungen von Container-Infrastrukturen zu unterstützen (vgl. entsprechende Probes in Kubernetes). Statt des bisherigen Qualifiers @Health werden nun @Live bzw. @Ready zur Definition von HealthCheck-Beans verwendet:
    @ApplicationScoped
    @Liveness
    public class LivenessCheck implements HealthCheck {
    
      @Override
      public HealthCheckResponse call() {
        return HealthCheckResponse
            .named("Service1")
            .up()
            .build();
    

    @Health steht noch zur Verfügung, ist aber deprecated.

  • Die neuen Endpunkte /health/live und /health/ready veröffentlichen den Zustand von Liveness bzw Readiness:
    GET /health/live
    
    200 OK
    {
      "status": "UP",
      "checks": [{
        "name": "Service1",
        "status": "UP"
      }]
    }
    

    Der bisherige Endpunkt /health existiert weiterhin.

  • Im JSON-Format wurden die Attribute outcome und state durch status ersetzt.

Ausblenden von Default-Checks in MicroProfile Health 2.1

Die Implementierung von Healthchecks als CDI-Beans ermöglicht es, dass auch Plattform-Implementierungen/Bibliotheken Prüfergebnisse bereitstellen (bspw. ein DB Connection Pool). Setzt man die neue MicroProfile Configuration Property mp.health.disable-default-procedures auf true, werden solche Default-Checks nicht aktiviert, d. h. im Response der o. a. Endpoints befinden sich nur von der Anwendung selbst bereitgestellte Werte.

Demo

Ich habe das Beispielprojekt mit anderen MicroProfile-Demos kombiniert in https://github.com/GEDOPLAN/microprofile-demo eingecheckt. Im Verzeichnis microprofile-health finden Sie ein Demoprojekt mit zwei Health Checks, deren Ergebnis über eine Webseite beeinflusst werden kann. Die Anwendung kann als WAR-File auf einen Server mit Unterstützung von MicroProfile 3.0 deployt werden. Alternativ können über vorkonfigurierte Maven-Profile Docker-Images zum direkten Ausprobieren erstellt werden.

Bis bald – vielleicht in einem unserer Trainings in Berlin, Bielefeld, Köln oder bei Ihnen!
https://gedoplan-it-training.de/

Alles gesund? Health checking mit MicroProfile Health

Im Bereich von Microservices und verteilten Systemen – aber nicht nur dort – ist es wichtig zu wissen, ob ein Service/System ordnungsgemäß läuft oder gestört ist. Im MicroProfile (https://microprofile.io) ist mit MicroProfile Health ein Teil enthalten, der es in Kombination mit CDI sehr einfach macht, Health Checking in EE-Anwendungen zu integrieren.

Health Check Callbacks

Die Idee von MicroProfile Health ist, dass Anwendungen auf EE-Servern oder auf Basis von MicroProfile-Frameworks ein oder mehrere Methoden zum Prüfen des Gesundheitszustandes enthalten. Der Server sammelt die Zustände bei Bedarf ein und aggregiert daraus einen Gesamtzustand, der auf dem Rest-Endpoint /health veröffentlicht wird:

GET /health

200 OK
{
  "outcome": "UP",
  "checks": [{
    "name": "Service1",
    "state": "UP",
    "data": {
      "memory": 180672240
    }
  }, {
    "name": "Service2",
    "state": "UP"
  }]
}

Die Callback-Methoden heißen – etwas uninspiriert – call und stammen aus dem Interface org.eclipse.microprofile.health.HealthCheck. Der Server sucht sich automatisch alle Klassen zusammen, die dieses Interface implementieren und mit dem CDI-Qualifier org.eclipse.microprofile.health.Health versehen sind:

@ApplicationScoped
@Health
public class HealthCheck1 implements HealthCheck {

  @Override
  public HealthCheckResponse call() {
    ...

Das Prüfergebnis können die Methoden bequem mittels Builder-Pattern zusammensetzen:

  public HealthCheckResponse call() {
    return HealthCheckResponse
        .named("Service1")
        .up()
        .withData("memory", Runtime.getRuntime().freeMemory())
        .build();

Neben up gibt es auch down sowie die Methode status, der der Gesundheitszustand als Parameter übergeben wird.

Gesamtgesundheit

Bei einem GET-Request auf den Pfad /health werden alle verfügbaren call-Methoden aus allen Anwendungen des Servers aufgerufen und zu einem Gesamtzustand kombiniert. Liefern alle Checks UP, ist das Attribut outcome im Gesamtergebnis ebenfalls UP und der Response hat den Status 200 OK. Andernfalls wird der Response mit 503 Service unavailable ausgeliefert und outcome ist darin DOWN.

Plattformen

MicroProfile Health wird u. a. von folgenden JEE-Servern unterstützt:

  • OpenLiberty (mit aktiviertem Feature mpHealth-1.0).
  • Payara.
  • WildFly (Achtung: WildFly hat unterschiedliche Ports für Applikations- und Management-Zugriffe, im Default 8080 und 9990. Der o. a. REST-Endpoint /health steht über den Management-Port zur Verfügung).

Die genannten Klassen befinden sich bspw. in der Maven-Dependency org.eclipse.microprofile:microprofile.

Demo

In https://github.com/GEDOPLAN/health-demo finden Sie ein Beispielprojekt mit zwei Health Checks, deren Ergebnis über eine Webseite beeinflusst werden kann. Die Anwendung kann als WAR-File auf einen der genannten Server deployt werden. Alternativ können über vorkonfigurierte Maven-Profile Docker-Images zum direkten Ausprobieren erstellt werden.

Ausblick

Im Beispiel wird als Zusatzinformation die Menge freien Speichers hinzugefügt, was im Kontext von Health Checking nicht grundsätzlich falsch ist, aber doch eher eine Metrik darstellt. Für deren Veröffentlichung hält MicroProfile eine weitere Teilspezifikation bereit: MicroProfile Metrics. Sie wird Gegenstand eines der nächsten Blog Posts sein – stay tuned!

Bis bald – vielleicht auch in einem unserer Trainings in Berlin, Bielefeld, Köln oder bei Ihnen!
https://gedoplan-it-training.de/