Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,8 @@ muzzle {

dependencies {
compileOnly("io.vertx:vertx-web:3.0.0")
compileOnly("io.vertx:vertx-codegen:3.0.0")
compileOnly("io.vertx:vertx-docgen:3.0.0")

// We need both version as different versions of Vert.x use different versions of Netty
testInstrumentation(project(":instrumentation:netty:netty-4.0:javaagent"))
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -5,13 +5,16 @@

package io.opentelemetry.javaagent.instrumentation.vertx;

import io.opentelemetry.api.GlobalOpenTelemetry;
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.context.Context;
import io.opentelemetry.context.Scope;
import io.opentelemetry.context.propagation.TextMapSetter;
import io.opentelemetry.instrumentation.api.instrumenter.LocalRootSpan;
import io.opentelemetry.instrumentation.api.semconv.http.HttpServerRoute;
import io.opentelemetry.instrumentation.api.semconv.http.HttpServerRouteSource;
import io.vertx.core.Handler;
import io.vertx.core.http.HttpServerRequest;
import io.vertx.ext.web.RoutingContext;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.UndeclaredThrowableException;
Expand All @@ -37,6 +40,7 @@ public void handle(RoutingContext context) {
route = route.substring(0, route.length() - 1);
}
HttpServerRoute.update(otelContext, HttpServerRouteSource.NESTED_CONTROLLER, route);
injectContextToDownstream(otelContext, context.request());

try (Scope ignore = RouteHolder.init(otelContext, route).makeCurrent()) {
handler.handle(context);
Expand All @@ -49,6 +53,21 @@ public void handle(RoutingContext context) {
}
}

private static void injectContextToDownstream(
Context otelContext, HttpServerRequest serverRequest) {
TextMapSetter<HttpServerRequest> setter =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the typical pattern is injecting context using TextMapSetters is something that happens in a client as opposed to server instrumentation

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not an expert on Otel, but this is what I've seen as a way to propagate context [1]. It's also the way we're doing internally in our framework. If there is a better alternative to achieve the same goal, we can certainly go for it.

[1] https://opentelemetry.io/docs/languages/java/api/#contextpropagators

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually you'd just call Context.current(). Serializing the context to context propagation headers is used for propagating context to external systems.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with Context.current() is the thread consistency. We have a multithreading environment and we cannot be certain that the thread that was executing the Vertx process is the same later used in the downstream process. That is the reason why we do prefer to use the context propagation via header instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are using threads in a way where context isn't automatically propagated you could capture the value of Context.current() at a point where it is still available and pass it along manually.
Could you elaborate why you wish to add the header based propagation here instead of doing it inside your own application?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apache Camel is not a simple application. It's a large framework with the integration of many components. We don't know beforehand how the user configure their applications or if even the user is going to include telemetry or not. We found several problem due to the context propagation in async situations, reason why we are adopting the header propagation [1] which seems to fit perfectly into our design. You can consider Camel as a black box, so, we are expecting upstream traces to carry on a traceparent header when this is somehow instrumented or enabled. Camel expects any upstream to carry on that header. And same for the downstream, Camel will add always a traceparent header for any downstream process to be able to relate the trace. I understood that was the correct way to handle distributed tracing.

[1] https://github.com/apache/camel/blob/main/proposals/tracing.adoc#context-propagation

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@laurit FYI, I've created a reproducer in the issue linked for this PR [1] if you want to have a look.

[1] #15284 (comment)

(carrier, key, value) -> {
if (carrier != null) {
carrier.headers().set(key, value);
}
};

GlobalOpenTelemetry.get()
.getPropagators()
.getTextMapPropagator()
.inject(otelContext, serverRequest, setter);
}

private static String getRoute(Context otelContext, RoutingContext routingContext) {
String route = routingContext.currentRoute().getPath();
String existingRoute = RouteHolder.get(otelContext);
Expand Down
Loading