Vierte Erweiterung aus M6. Ein Geschaeftsvorfall (z. B. eine Schadenmeldung) durchlaeuft in
der modernen Landschaft mehrere Prozessgrenzen: REST-Aufruf in novaris-claims-modern ->
Kafka-Request/Reply nach novaris-policy-core-modern -> Kafka-Publish an
novaris-notification-modern. Ohne verteiltes Tracing ist so ein Vorfall in drei getrennten
Log-Dateien nur ueber manuelles Grep nach Geschaeftsschluesseln (Policennummer o. ae.)
rekonstruierbar - genau das Problem, das WebSphere/Liberty im Legacy-Teil durch einen
gemeinsamen Applikationsserver-Prozess gar nicht erst hatte (ein EAR, ein Prozess, ein
Thread-Stack pro Request).
Micrometer Tracing ist die von Spring Boot 3 offiziell unterstuetzte Tracing-Abstraktion (Nachfolger von Spring Cloud Sleuth) und propagiert Trace-/Span-IDs automatisch durch Spring-MVC-Request-Handling und Spring-Kafka-Producer/Consumer - ohne das manuelle Weiterreichen von Korrelations-IDs durch jede Methode, das reines strukturiertes Logging erfordern wuerde. Zipkin ist der leichtgewichtigste verbreitete Trace-Collector (ein Single-Binary-Docker-Image, kein Schema-Setup), passend zum Lernprojekt-Massstab.
novaris-policy-core-modern, novaris-claims-modern,
novaris-notification-modern): micrometer-tracing-bridge-brave +
zipkin-reporter-brave, management.tracing.sampling.probability: 1.0 (jeder Request
getraced - bewusst hoch fuer ein Lernprojekt, produktiv typischerweise deutlich niedriger),
management.zipkin.tracing.endpoint.spring.kafka.template.observation-enabled /
spring.kafka.listener.observation-enabled: true in application.yml fuer die per
Spring-Boot-Autokonfiguration erzeugten Kafka-Beans; zusaetzlich manuell
KafkaTemplate.setObservationEnabled(true) und
ContainerProperties.setObservationEnabled(true) fuer die von Hand gebauten Kafka-Beans
(ReplyingKafkaTemplate in KafkaClaimClientConfig, Producer/Consumer-Factories in
KafkaProducerConfig/KafkaConsumerConfig) - die YAML-Property allein instrumentiert nur
Autokonfigurations-Beans, keine selbst konstruierten.claims-modern/notification-modernSpring Boots ZipkinAutoConfiguration faellt bei fehlendem HTTP-Client fuer den
Zipkin-Sender ueber eine Kette zurueck (RestTemplate -> WebClient ->
URLConnectionSender). novaris-claims-modern und novaris-notification-modern haben keinen
spring-boot-starter-web (reine Kafka-Consumer/Producer-Module ohne eigene REST-API), also
war weder RestTemplate noch WebClient auf dem Classpath - Traces wurden korrekt erzeugt und
der Trace-Kontext korrekt propagiert (per uebereinstimmenden Trace-IDs in den Logs bestaetigt),
aber nie an Zipkin exportiert, weil kein HTTP-Client zum Senden vorhanden war. Behoben durch
explizites Hinzufuegen von io.zipkin.reporter2:zipkin-sender-urlconnection in beiden
Modulen - ein minimaler, abhaengigkeitsarmer Fallback-Sender ohne Web-Starter-Anforderung.
Real gegen einen laufenden Zipkin-Container (openzipkin/zipkin, Docker) und einen
laufenden Kafka-Broker verifiziert: alle drei Module gebootet, ein realer
Schadenmeldungs-Request per curl ausgeloest, anschliessend in der Zipkin-UI
(http://localhost:9411) der vollstaendige Trace ueber alle drei Prozesse hinweg
nachvollzogen (REST-Eingang in claims-modern, Kafka-Request/Reply-Span nach
policy-core-modern, Kafka-Publish-Span an notification-modern) - kein
Konfigurationstest, sondern ein echter End-to-End-Trace mit sichtbaren Spans in der UI.
Beim manuellen Test ohne erreichbaren Kafka-Broker blockierte
PolicyEventPublisherAdapter.publish(...) (ueber KafkaTemplate.send()) den
HTTP-Request-Thread von activatePolicy fuer die volle max.block.ms-Dauer des
Kafka-Producers (Default ca. 60s) statt schnell fehlzuschlagen. Urspruenglich hier nur als
realer Fund dokumentiert, ohne Behebung - in einer spaeteren Session tatsaechlich behoben:
siehe 12-blocking-bugs-behoben.md fuer den vollstaendigen Fix (@Async + gebundenes
max.block.ms/spring.kafka.admin.properties) inklusive einer dabei zusaetzlich real
gefundenen, analogen zweiten Blockierung (Db2LegacyBenchmarkPort via HikariCPs
30-Sekunden-connectionTimeout-Default).