[
https://issues.apache.org/jira/browse/CAMEL-23283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18073086#comment-18073086
]
Pasquale Congiusti commented on CAMEL-23283:
--------------------------------------------
Hello. My above comment was more a kind of design suggestion. I am working to
reproduce the issue and if there is any inconsistency in the component as
you're experimenting, then it has to be fixed. If at "process" level, the
component is not handle to properly figure it out the correct span hierarchy,
then, we need to fix it. I am going to try to reproduce the error and find a
solution compliant with the design.
For sure the camel-opentelemetry2 is easier to configure, but, I'll keep you
posted on the progress for this task.
> 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)
