© Excellent backgrounds/Shutterstock.com
Teil 6: Java EE und Microservices mit einem Dashboard überwachen

Monitoren Sie noch, oder beobachten Sie schon?


Ein beobachtbarer Microservice muss genügend Information für die externe Bestimmung seines Zustands (Health) veröffentlichen. Die Fähigkeit, die notwendigen Daten zu veröffentlichen, wird zu einer nicht funktionalen Eigenschaft des Systems. Java EE bringt von Haus aus viele Funktionalitäten mit, da ist etwas Langeweile schon fast vorprogrammiert.

Video: APIs von Microservices mit DDD fachlich schneiden

Artikelserie

Teil 1: Microservices mit Java EE

Teil 2: Microservices mit Java EE, Application Server und Docker

Teil 3: Microservices mit Java EE, Fehlerbehandlung und Konfiguration

Teil 4: Java EE Microservices überwachen

Teil 5: Java EE Microservices anwendungsbezogen überwachen

Teil 6: Java EE und Microservices mit einem Dashboard überwachen

Im „Embrace Boredom“-Post [1] wird vorgeschlagen, auf möglichst langweilige Technologien zu setzen und jeweils erst nach dem Erreichen einer bestimmten Reife Neues auszuprobieren. Solche Experimente sollten die Ausnahme und nicht die Regel sein. Dabei sind langweilige Technologien keinesfalls schlecht, gelten als bereits etabliert, ohne Überraschungen, zeigen bekanntes Verhalten und möglichst viele Antworten auf Stack Overflow. Java-EE-Applikationsserver sind langweilig. Sie können als das Betriebssystem für die Fachlichkeit angesehen werden. Der Anwendungscode ist klar und strikt von der Laufzeitumgebung getrennt. Diese strikte Trennung ist besonders in Docker- und Cloud-Umgebungen vorteilhaft, in denen das Thin WAR (die Anwendung) und der Java-EE-Server sogar binär durch aufeinander aufbauende Layer separiert sind.

Applikationsserver sind gut observierbar. Von dem HTTP Stack über Transaktionen bis zu Data Sources veröffentlichen alle Subsysteme fleißig Metriken, und das seit über fünfzehn Jahren. Die Metriken werden mehr oder weniger bunt visualisiert. Grafische Darstellung und nachträgliche Auswertung der Metriken sind eindeutig die Schwäche der meisten Applikationsserver.

Was geht

Die JAX-RS-Ressource PingResource wurde mit großem Vertrauen bezüglich der Performance der Java-EE-Applikationsserver implementiert:

@Path("ping") public class PingResource { @GET public void ping(@Suspended AsyncResponse response) { response.setTimeout(1, TimeUnit.NANOSECONDS); response.resume("Java EE 8 is crazy fast"); }

Der Timeout wurde mit einer Nanosekunde konfiguriert, was den 503-HTTP-Status verursachen sollte. Die Abfrage: curl -i http://localhost:8080/problematic/resources/ping liefert tatsächlich

HTTP/1.1 503 Service Un...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang