Meine Demo von OpenTelemetry Tracing umfasst zwei Spring Boot-Komponenten. Eine verwendet den Java-Agenten und mir ist ein anderes Verhalten aufgefallen, als ich ihn kürzlich von v1.x auf v2.x aktualisiert habe. In der anderen verwende ich Micrometer Tracing, weil ich in GraalVM nativ kompiliere und es keine Java-Agenten verarbeiten kann.   Meine OpenTelemetry-Demo  In diesem Beitrag möchte ich diese drei Ansätze vergleichen: Java-Agent v1, Java-Agent v2 und Micrometer Tracing.  Die Basisanwendung und ihre Infrastruktur  Ich verwende dieselbe Basisanwendung: eine einfache Spring Boot-Anwendung, die in Kotlin codiert ist. Sie bietet einen einzelnen Endpunkt.  Die Funktion hinter dem Endpunkt heißt  entry()  Es ruft eine andere Funktion namens   auf. intermediate()  Letzteres verwendet eine   Instanz, den Ersatz für   , um einen Aufruf des obigen Endpunkts zu tätigen WebClient RestTemplate  Um Endlosschleifen zu vermeiden, übergebe ich einen benutzerdefinierten Anforderungsheader: Wenn die Funktion   ihn findet, fährt sie nicht fort  entry()  Es wird in den folgenden Code übersetzt:   @SpringBootApplication class Agent1xApplication @RestController class MicrometerController { private val logger = LoggerFactory.getLogger(MicrometerController::class.java) @GetMapping("/{message}") fun entry(@PathVariable message: String, @RequestHeader("X-done") done: String?) { logger.info("entry: $message") if (done == null) intermediate() } fun intermediate() { logger.info("intermediate") RestClient.builder() .baseUrl("http://localhost:8080/done") .build() .get() .header("X-done", "true") .retrieve() .toBodilessEntity() } }  Bei jedem Setup überprüfe ich zwei Phasen: die primäre Phase mit aktivierter OpenTelemetry und eine Anpassungsphase zum Erstellen zusätzlicher interner Bereiche.  Mikrometer-Abtastung  Micrometer Tracing stammt von   , einer „herstellerneutralen Fassade zur Anwendungsbeobachtung“. Micrometer  Micrometer Tracing bietet eine einfache Fassade für die gängigsten Tracer-Bibliotheken, sodass Sie Ihren JVM-basierten Anwendungscode ohne Abhängigkeit von einem Anbieter instrumentieren können. Es ist so konzipiert, dass es Ihrer Tracing-Sammelaktivität wenig bis gar keinen Mehraufwand hinzufügt und gleichzeitig die Portabilität Ihrer Tracing-Bemühungen maximiert.  --  Mikrometer-Tracing-Site  Um mit Micrometer Tracing zu beginnen, müssen einige Abhängigkeiten hinzugefügt werden:  Spring Boot-Aktuator,  org.springframework.boot:spring-boot-starter-actuator  Mikrometer-Tracing selbst,  io.micrometer:micrometer-tracing  Eine „Brücke“ zur Ziel-Tracing-Backend-API. In meinem Fall ist es OpenTelemetry, daher  io.micrometer:micrometer-tracing-bridge-otel  Ein konkreter Exporter zum Backend,  io.opentelemetry:opentelemetry-exporter-otlp  Wir benötigen keine Stückliste, da im übergeordneten Spring Boot-Element bereits Versionen definiert sind.  Wir benötigen jedoch zwei Laufzeitkonfigurationsparameter: Wohin sollen die Traces gesendet werden und wie lautet der Name der Komponente? Sie werden durch die Variablen   und   gesteuert. MANAGEMENT_OTLP_TRACING_ENDPOINT SPRING_APPLICATION_NAME   services: jaeger: image: jaegertracing/all-in-one:1.55 environment: - COLLECTOR_OTLP_ENABLED=true #1 ports: - "16686:16686" micrometer-tracing: build: dockerfile: Dockerfile-micrometer environment: MANAGEMENT_OTLP_TRACING_ENDPOINT: http://jaeger:4318/v1/traces #2 SPRING_APPLICATION_NAME: micrometer-tracing #3  Aktivieren Sie den OpenTelemetry-Collector für Jaeger  Vollständige URL zum Jaeger OpenTelemetry gRPC-Endpunkt  Legen Sie den Dienstnamen von OpenTelemetry fest  Hier ist das Ergebnis:   Ohne jegliche Anpassung erstellt Micrometer Spans beim Empfangen und Senden von HTTP-Anfragen.  Das Framework muss Magie in den   einbringen, um ihn zu senden. Dazu müssen wir den RestClient vom RestClient instanziieren lassen: RestClient   @SpringBootApplication class MicrometerTracingApplication { @Bean fun restClient(builder: RestClient.Builder) = builder.baseUrl("http://localhost:8080/done").build() }  Wir können manuelle Spannen auf verschiedene Weise erstellen, eine davon über die OpenTelemetry-API selbst. Die Einrichtung erfordert jedoch viel Boilerplate-Code. Der einfachste Weg ist die   von Micrometer. Ihr Hauptvorteil besteht darin, dass sie eine einzige API verwendet, die sowohl   als auch   verwaltet.  Observation-API Metriken Traces  Hier ist der aktualisierte Code:   class MicrometerController( private val restClient: RestClient, private val registry: ObservationRegistry ) { @GetMapping("/{message}") fun entry(@PathVariable message: String, @RequestHeader("X-done") done: String?) { logger.info("entry: $message") val observation = Observation.start("entry", registry) if (done == null) intermediate(observation) observation.stop() } fun intermediate(parent: Observation) { logger.info("intermediate") val observation = Observation.createNotStarted("intermediate", registry) .parentObservation(parent) .start() restClient.get() .header("X-done", "true") .retrieve() .toBodilessEntity() observation.stop() } }  Die hinzugefügten Beobachtungsaufrufe spiegeln die generierten Spuren wider:   OpenTelemetry Agent v1  Eine Alternative zu Micrometer Tracing ist der generische   . Sein Hauptvorteil besteht darin, dass er weder den Code noch die Entwickler beeinflusst. Der Agent ist ein reines Laufzeitproblem. OpenTelemetry Java Agent   java -javaagent:opentelemetry-javaagent.jar agent-one-1.0-SNAPSHOT.jar  Der Agent hält sich an die Konfiguration von OpenTelemetry mit Umgebungsvariablen:   services: agent-1x: build: dockerfile: Dockerfile-agent1 environment: OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4317 #1 OTEL_RESOURCE_ATTRIBUTES: service.name=agent-1x #2 OTEL_METRICS_EXPORTER: none #3 OTEL_LOGS_EXPORTER: none #4 ports: - "8081:8080"  Legen Sie das Protokoll, die Domäne und den Port fest. Die Bibliothek hängt   an. /v1/traces  Legen Sie den Dienstnamen von OpenTelemetry fest  Exportieren Sie weder die Metriken noch die Protokolle  Ohne weitere Konfiguration erhalten wir die folgenden Spuren:   Der Agent verfolgt automatisch empfangene und gesendete Anfragen   . Traces sind entsprechend dem Aufrufstapel korrekt ineinander verschachtelt. Um zusätzliche Funktionen zu verfolgen, müssen wir unserer Codebasis eine Abhängigkeit hinzufügen:   . Wir können jetzt zuvor nicht verfolgte Funktionen mit der Annotation   annotieren.  sowie Funktionen, die mit Spring-bezogenen Annotationen markiert sind io.opentelemetry.instrumentation:opentelemetry-instrumentation-annotations @WithSpan  Der   Teil bestimmt die Bezeichnung der Ablaufverfolgung, während   als   -Attribut übersetzt wird. Wenn der Wert auf eine leere Zeichenfolge gesetzt ist, was der Standard ist, wird der Name der Funktion ausgegeben. Für meine Zwecke sind Standardwerte gut genug. value() kind span.kind   @WithSpan fun intermediate() { logger.info("intermediate") RestClient.builder() .baseUrl("http://localhost:8080/done") .build() .get() .header("X-done", "true") .retrieve() .toBodilessEntity() }  Es ergibt sich die erwartete neue   :  intermediate()  OpenTelemetry Agent v2  OpenTelemetry hat im Januar dieses Jahres eine neue Hauptversion des Agenten veröffentlicht. Ich habe meine Demo damit aktualisiert; Traces werden jetzt nur noch erstellt, wenn die App Anfragen empfängt und sendet.   Wie bei der vorherigen Version können wir Spuren mit der Annotation   hinzufügen. Der einzige Unterschied besteht darin, dass wir auch die Funktion   annotieren müssen. Sie wird standardmäßig nicht verfolgt.  @WithSpan entry()  Diskussion  Spring war aus zwei Gründen erfolgreich: Es vereinfachte komplexe Lösungen,   . B. EJBs 2, und bot eine Abstraktionsschicht gegenüber konkurrierenden Bibliotheken. Micrometer Tracing begann als Abstraktionsschicht über Zipkin und Jaeger und machte absolut Sinn. Dieses Argument ist hinfällig, da OpenTelemetry von den meisten Bibliotheken in Programmiersprachen und Trace-Sammlern unterstützt wird. Die Observation API ist immer noch ein erheblicher Vorteil von Micrometer Tracing, da es eine einzige API über Metrics und Traces verwendet. z  Auf der Java-Agent-Seite ist die OpenTelemetry-Konfiguration bei allen Tech-Stacks und Bibliotheken ähnlich – Umgebungsvariablen. Ich war etwas enttäuscht, als ich von v1 auf v2 aktualisierte, da der neue Agent nicht Spring-fähig ist: Mit Spring annotierte Funktionen werden standardmäßig nicht verfolgt.  Letztendlich ist es eine kluge Entscheidung. Es ist viel besser, die gewünschten Spannen explizit anzugeben, als einige zu entfernen, die Sie nicht sehen möchten.    . Danke an   für seine Hilfe und seine Rezension Jonatan Ivanov  Der vollständige Quellcode für diesen Beitrag ist auf GitHub zu finden:   https://github.com/ajavageek/boot-tracing?embedable=true   Um weiter zu gehen:   Demo von OpenTelemetry Tracing   Mikrometer-Abtastung   OpenTelemetry-Spuren   OpenTelemetry Java-Integration OpenTelemetry Java-Beispiele   Verteiltes Tracing mit Spring Boot 3 – Micrometer vs. OpenTelemetry   Beobachtbarkeit mit Spring Boot 3   Ursprünglich veröffentlicht bei   am 3. August 2024 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Dieses Audio ist in der Originalsprache der Geschichte produziert!

OpenTelemetry Tracing in Spring Boot: Auswahl zwischen Java Agent und Micrometer für

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Celebrating Our Management Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Celebrating Our Management Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps