[
https://issues.apache.org/jira/browse/CAMEL-23283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18072535#comment-18072535
]
Pasquale Congiusti commented on CAMEL-23283:
--------------------------------------------
> But if the route is triggered by a JMS message without a traceparent header
> (i.e. a new traceId is created by camel-micrometer-observability), the
> structure becomes incorrect: the first span for the message consumption has
> the newly created traceId, but the programmatically created second span gets
> yet another, newly created and unique traceId.
Does this only happen for JMS or is it a generic case? Is this also happening
when you enable processors? What the component does is to rely on a propagator
which has to be implemented so, it's the propagator that is in charge to make
sure to properly propagate context. Can you share your propagator configuration
to analyze the issue better?
> 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)
