1. Überblick
In diesem Artikel schauen wir uns an, wie man die Kommunikation zwischen Microservices nachverfolgen kann. Mit Spring Cloud Sleuth erweitern wir das Logging um Span IDs und stellen diese anschließend mit Jaeger UI grafisch dar.
Im Artikel Kommunikation von Microservices auf OpenShift – REST mit OpenFeign haben wir drei Microservices, die miteinander über REST kommunizieren, entwickelt. Dieses Projekt werden wir im Rahmen dieses Artikels erweitern, um das verteilte Tracing zu demonstrieren.
2. Installation von Jaeger als All-in-One Lösung für OpenShift
Jaeger ist ein Monitoring-System für komplexe verteilte Anwendungssysteme. Es ist sehr einfach den gesamten Stack auf OpenShift mit folgendem oc-Befehl zu installieren:
oc process -f https://raw.githubusercontent.com/jaegertracing/
jaeger-openshift/master/all-in-one/jaeger-all-in-one-template.yml
| oc create -f -
Nach erfolgreicher Installation sehen wir in der OpenShift Konsole den gesamten Stack der All-in-One Lösung. Siehe nächste Abbildung.
Die Installation über das OpenShift Template ist für Beispielanwendungen sehr komfortabel, dies ist aber nicht für den Produktiveinsatz geeignet, da bei dieser Installation unter anderem keine Persistenz eingerichtet wird.
Für uns ist der Port und der Servicename von Zipkin entscheidend http://zipkin:9411. Im nächsten Schritt werden wir Spring Sleuth auf diese URL konfigurieren, damit Tracinginformationen bereitgestellt werden können.
3. Spring Cloud Sleuth und Spring Cloud Zipkin Dependencies einbinden
Die Kernfunktionalität von Spring Cloud Sleuth ist die Bereitstellung von zusätzlichen Span-Informationen für jeden Request. Diese zusätzliche Information wird zum einen im Logging sichtbar, zum anderen besteht die Möglichkeit die Span-Information direkt an ein Distributed Tracing System wie z.B. Zipkin zu schicken. Zipkin sammelt diese Informationen und stellt bequeme Lookup Funktionalitäten bereit, die wir uns später anschauen.
Jeder Microservice wird um zwei neue Dependencies erweitert:
- spring-cloud-starter-sleuth
- spring-cloud-starter-zipkin
pom.xml
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
<version>2.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
<version>2.2.1.RELEASE</version>
</dependency>
Mit der zweiten Dependency spring-cloud-starter-zipkin erkennt Spring Boot durch Autocofiguration, dass es die Span-Informationen an den Zipkin Server schicken muss. Die URL des Zipkin Servers tragen wir in unsere application.properties ein:
application.properties
spring.zipkin.baseUrl: http://zipkin:9411/
Mit diesen Anpassungen haben wir das Tracing bereits aktiviert. Im nächsten Abschnitt zeigen wir, wie die Span-Informationen grafisch in Jaeger UI dargestellt werden.
4. Distributed Tracing von Aufrufen
Um etwas Traffic zwischen den Microservices zu verursachen, rufen wir order-service auf folgendem REST Endpoint /orders/3 auf. Hierbei wird implizit customer-service aufgerufen, um die Kundeninformationen zu bekommen und es werden mehrere Aufrufe vom product-service für die Produktinformationen getätigt.
Ein Aufruf verursacht damit ziemlich viel Traffic, was wir auf dem Jaeger Dashboard sehen können, siehe nächste Abbildung.
Jaeger UI präsentiert uns den kompletten Trafficverlauf ziemlich übersichtlich. Wir sehen anhand der Abbildung, dass es nur ein Aufruf vom customer-service gibt und vier Aufrufe vom product-service. Wir sehen ebenfalls, wie lange jeder Aufruf gedauert hat und in welcher Reihenfolge diese ausgeführt wurden.
Wir können auf die einzelnen Services klicken und erhalten nähere Information zu jedem Request:
- IP Adresse
- http.mehtod
- http.path
- mvc.controller.class
- mvc.controller.method
- peer.ipv4
5. Fazit
Spring Boot macht wie immer die Magie. Zwei neue Dependencies, eine Anpassung der application.yaml und schon senden unsere Microservices Tracinginformationen an ein Monitoring-Tool.
Spring Cloud Sleuth erhebt die Daten und sendet es an Zipkin. Jaeger UI bereitet für uns die verteilten Kommunikationsdaten intuitiv auf und hilft uns damit eine bessere Übersicht über unsere verteilte Anwendung zu bekommen. Bei größeren Microservices-Architekturen kommt man über solch ein Monitoring-Tool nicht herum.
Das Projekt findet ihr in GitHub unter dem branch sample-openshift-sleuth-jaeger