Mingration from OpenTracing: the baggageItem/context propagation. #5651
Replies: 2 comments 10 replies
-
In OTel Baggage baggage = Baggage.current().toBuilder()
.put(MY_KEY, value)
.build();
try (Scope ignored = baggage.makeCurrent()) {
// code that uses the modified baggage
} The way it's propagated is very similar to |
Beta Was this translation helpful? Give feedback.
-
Hello @jkwatson @mateuszrzeszutek In the end I had to change a bit the code but the baggage is propagated. So basically in service 1, as suggest by @mateuszrzeszutek, I have these two static utility methods: public static <T> T addCallerToCurrentBaggage(String caller, Supplier<T> supplier) {
Baggage baggage = Baggage.current().toBuilder()
.put(ROOT_CALLER, caller)
.build();
try (Scope ignored = baggage.makeCurrent()) {
return supplier.get();
}
}
public static String getRootCaller() {
return getBaggageItem(ROOT_CALLER).orElse(NONE);
} If for example the supplier make an http call to service 2 the baggage will be (magically) propagated. In Service 2 I have to call I have still one problem though. I'm using also reactive (Reactor project). When a use So if a set the baggage in thread 1, in thread 2 I do not have it. How can I propagate the baggage in this case? |
Beta Was this translation helpful? Give feedback.
-
With OpenTracing, for context propagation, I have this very simple utility class:
what is the simplest way to translate this with OpenTelemetry? I had a look at this doc and I'm a bit surprise how is this more difficult with OpenTelemetry. Moreover there is the concept of "carrier". It means that probably I would have to pass the httpExchange on both methods in the context propagation if propagation is done with HttpHeaders. I'm missing something or context propagation is became far more complex compare to
OpenTracing
?Beta Was this translation helpful? Give feedback.
All reactions