[
https://issues.apache.org/jira/browse/CAMEL-23283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18073001#comment-18073001
]
Bjorn Beskow edited comment on CAMEL-23283 at 4/12/26 7:12 PM:
---------------------------------------------------------------
Thanks for the suggestion. Unfortunately, it makes no difference (to my
understanding,
{{{}Observation{}}}{{{}.createNotStarted(){}}}{{{}.observe({}){}}}is just
syntactic sugar for using the Tracer as you suggest).
Our observability requirements are to
* have identical structure for tracing and logs from both vanilla Spring Boot
and Spring Boot/Camel applications
* have trace_id, spanId and additional baggage as attributes on both spans and
logs
* be able to create custom spans (including giving the span a non-technical
name and be able to add custom attributes to the span) for significant
transformations
* use a common, standardised API when needed to interact programmatically with
the observability platform
If I interpret you correctly, this cannot be achieved with
camel-micrometer-observability.
So, we'll switch to using opentelemetry-api and the opentelemetry agent for
both our Spring Boot and Spring Boot/Camel applications (using
camel-opentelemetry2).
Thanks for looking into it, you may close this issue.
was (Author: beskow):
Thanks for the suggestion. Unfortunately, it makes no difference (to my
understanding,
{{{}Observation{}}}{{{}.createNotStarted(){}}}{{{}.observe({}){}}}is just
syntactic sugar for using the Tracer as you suggest).
Our observability requirements are to
* have identical structure for tracing and logs from both vanilla Spring Boot
and Spring Boot/Camel applications
* have trace_id, spanId and additional baggage as attributes on both spans and
logs
* be able to create custom spans (including giving the span a non-technical
name and be able to add custom attributes to the span) for significant
transformations
* use a common, standardised API when needed to interact programmatically with
the observability platform
If I interpret you correctly, this cannot be achieved with
camel-micrometer-observability.
So, we'll switch to using opentelemetry-api and the opentelemetry agent for
both our Spring Boot and Spring Boot/Camel applications (using
camel-opentelemetry2).
Thanks for looking into it.
> 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)
