[
https://issues.apache.org/jira/browse/CAMEL-23283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18072541#comment-18072541
]
Pasquale Congiusti edited comment on CAMEL-23283 at 4/10/26 9:00 AM:
---------------------------------------------------------------------
I had a look and I'm not sure Observation is the proper way to handle. I think
you can get instead the tracer that is used by the telemetry component instead
and try to build the span from there. Something like:
{code}
import io.micrometer.tracing.Span;
import io.micrometer.tracing.Tracer;
...
Tracer t = CamelContextHelper.findSingleByType(getCamelContext(),
Tracer.class);
from("jms:queue:test")
.log("Received message from jms queue")
.process(exchange -> {
Span span = t.nextSpan()
.name("jms-transformer")
.start();
try (Tracer.SpanInScope scope = t.withSpan(span)) {
log.info("Transformed message from jms queue");
span.tag("camel.routeId", exchange.getFromRouteId());
span.tag("camel.exchangeId", exchange.getExchangeId());
} catch (Exception e) {
span.error(e);
throw e;
} finally {
span.end();
}
});
{code}
In any case as I said in your PR, I don't think it's a good design to add any
further custom span as it should be transparent for the route developer. The
span should be already created for the process and IMO, this one should be
enough from a telemetry POV. The developer should know nothing about any
telemetry instrumentation.
was (Author: squakez):
I had a look and I'm not sure Observation is the proper way to handle. I think
you can get instead the tracer that is used by the telemetry component instead
and try to build the span from there. Something like:
{code}
import io.micrometer.tracing.Span;
import io.micrometer.tracing.Tracer;
...
Tracer t = CamelContextHelper.findSingleByType(getCamelContext(),
Tracer.class);
from("jms:queue:test")
.log("Received message from jms queue")
.process(exchange -> {
Span span = t.nextSpan()
.name("jms-transformer")
.start();
try (Tracer.SpanInScope scope = t.withSpan(span)) {
log.info("Transformed message from jms queue");
span.tag("camel.routeId", exchange.getFromRouteId());
span.tag("camel.exchangeId", exchange.getExchangeId());
} catch (Exception e) {
span.error(e);
throw e;
} finally {
span.end();
}
});
{code}
> 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)
