[
https://issues.apache.org/jira/browse/CAMEL-23283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18072532#comment-18072532
]
Pasquale Congiusti commented on CAMEL-23283:
--------------------------------------------
> Isn't that part of the documentation related to the "Using with standalone
> Camel" section? I interpreted that as not applicable when using with Spring
> Boot?
Sorry, there was some indentation problem. I'm fixing this right away.
> With Spring Boot Micrometer, to my understanding traceId and spanId are
> automatically set in the MDC (see e.g.
> https://docs.spring.io/spring-boot/3.5/reference/actuator/tracing.html#actuator.micrometer-tracing.logging).
> And that is indeed also the case if a traceparent header is provided when
> initiating a Camel route, but not if a new trace is created by
> camel-micrometer-observability. I cannot understand why
> camel-micrometer-observability should behave differently w.r.t. MDC in those
> two cases?
That's because Camel is agnostic to any specific tracing or mdc technology. We
can't support all the possible implementations around as there is no standard
for it. If you've noticed, our MDC solution is using a specific format for the
mdc variables, they are not "traceId" or "spanId" on purpose. If you want to
use any external MDC tooling you certainly can, but it must be properly
configured via a bridge as explained in the documentation, for example
https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/logger-mdc-instrumentation.md
> OpenTelemetry/Micrometer traces are not correctly structured for
> JMS-initiated routes
> -------------------------------------------------------------------------------------
>
> Key: CAMEL-23283
> URL: https://issues.apache.org/jira/browse/CAMEL-23283
> Project: Camel
> Issue Type: Task
> Components: camel-tracing
> Affects Versions: 4.15.0, 4.16.0, 4.17.0, 4.18.0, 4.18.1
> Reporter: Bjorn Beskow
> Priority: Minor
> Attachments: jms-micrometer-observability.zip
>
>
> When using camel-micrometer-observability, traces and spans are not correctly
> structured if a traceId and root span is not already present (as a result of
> OTEL context propagation from the caller, or by a Spring Boot framework
> component in front of the camel component).
> The effect is twofold:
> * traceId and spanId is not put in the MDC context, and hence not present in
> any logs created.
> * Nested spans created programmatically using the Micrometer Observation API
> are not properly nested (they get their own, unique traceId's).
> The attached sample project pinpoints the problem: For an exchange with a
> "traceparent" propagated from the caller, everything works as expected. For
> an exchange without a propagated existing trace, the tests show that the MDC
> is not properly populated and any nested spans have the wrong structure.
> This seems to be caused by missing scope management:
> MicrometerObservabilitySpanAdapter::activate() only calls span.start() but
> doesn't put the
> span into the tracer's thread-local scope. This means tracer.currentSpan()
> returns null during route execution, hence the span is invisible to e.g.
> programmatic child span creation that relies on tracer.currentSpan() to find
> a parent span (for example via the ObservationRegistry). It also becomes
> invisible for the MDC context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
