Adam Bien Selbstständig

Bei der Entwicklung von Java EE Microservices gilt der Zero-Dependency-Deployments- oder Thin-WARs-Ansatz insbesondere für das Monitoring.

Autos informieren den Fahrer über Geschwindigkeit, Drehzahl, Tankanzeige, Temperatur und manchmal auch über Ladedruck oder das aktuelle Drehmoment des Motors. Außerdem verfügen alle modernen Fahrzeuge über eine Diagnoseschnittstelle. Espressomaschinen zeigen Druck und Temperatur des Kessels an. Sogar Rasierer messen die Zeit und informieren den Benutzer über bevorstehenden Klingenwechsel. Komplexe Enterprise-Anwendungen dagegen werden meistens ohne jegliches Monitoring betrieben. Das soll bei unserer Microservices-Anwendung mit Java EE nicht der Fall sein.

Alle Monitoring- und Diagnostik-Use-Cases und -User-Stories werden in der Entwicklung bewusst ignoriert. Man verlässt sich lieber auf die in Produktion installierte Monitoring- und Diagnostiksoftware und hofft, dass man ohne jegliche Entwicklungsaufwände hilfreiche Information aus der Software nachträglich extrahieren kann. Die JVM sieht die Installation von Agenten vor. Diese haben direkten Zugriff auf den Bytecode während der Ausführung und werden oft von den Monitoringsystemen verwendet. Andere Performancemonitoring- und Diagnostiksysteme basieren auf Bytecodemanipulationen und dekorieren so die relevanten Methoden. Man betrachtet das Monitoring als ein Cross-Cutting Concern und versucht mit Methoden der aspektorientierten Programmierung (AOP), wertvolle Informationen nachträglich zu erhalten: Eine Benutzeranfrage kann auf dem Server von dem Parsing des HTTP Requests bis zur Kommunikation mit der Datenbank überwacht werden. So lassen sich Statistiken über SQL-Statements, Threads, Performance, Speicherbedarf, Flaschenhälse und die am häufigsten aufgerufenen Methoden sammeln. Man erhält eine transaktionale Sicht auf das System und versucht, wichtige Use Cases nachträglich hoffentlich sinnvoll benannten Methoden zuzuordnen. Diese Strategie übertragen auf PKWs bedeutet: Moderne PKWs würde man ohne Geschwindigkeitsanzeige oder Drehzahlmesser ausliefern und sich dann auf das bereits existierende GPS-Satellitensystem und Ultraschall verlassen.

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

Vergessene Fähigkeiten

Was viele vergessen: Ein Applikationsserver verfügt bereits über detailliertes Wissen über die Vorgänge in den deployten Komponenten. Denn Applikationsserver verwalten den Lebenszyklus von Servlets, EJBs sowie CDI-Komponenten und sind für das Pooling von JDBC Connections und Threads zuständig. Die Sicherheit, Nebenläufigkeit, Transaktionalität wird bereits intern mit AOP-Mitteln implementiert. Ein Applikationsserver nutzt die Dependency Injection für die Dekoration von Komponenten mit standardisierten Querschnittsaspekten. So werden beispielsweise für jede mit @Stateless annotierte Klasse Transaktions-, Sicherheits- und Nebenläufigkeitsaspekte installiert.

Seit Dezember 2001 implementieren alle Java-EE-Applikationsserver den JSR 77 „J2EE Management Spezifikation“. So realisieren alle deployten Komponenten des Applikationsservers das spezifische J2EEManagedObject (z. B. StatelessSessionBean) und veröffentlichen auch eine Reihe von im Paket javax.management.j2ee.statistics (TimeStatistic, RangeStatistic, BoundaryStatistic, CountStatistic) standardisierten Statistiken. Allerdings bleibt jedem Hersteller freigestellt, über welches Protokoll er die Statistiken der Außenwelt zur Verfügung stellt. Von der Kommandozeile über JMX zu REST-Schnittstellen – der Weg zu den Schnittstellen ist leider nicht standardisiert.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 10.17 - "Java 9"

Alle Infos zum Heft
579810703Microservices mit Java EE überwachen
X
- Gib Deinen Standort ein -
- or -