JinyuChen97 commented on PR #8879: URL: https://github.com/apache/camel-quarkus/pull/8879#issuecomment-5024049179
> The main concern I have is with how the `MicrometerObservabilityTracerProducer` wires up the Micrometer Tracer and Propagator. The current implementation optionally injects them as CDI beans: > > ```java > @Inject > Instance<Tracer> tracerInstance; > > @Inject > Instance<Propagator> propagatorInstance; > ``` > > The problem is that no Quarkus extension currently produces Micrometer Tracer or Propagator CDI beans. So in practice, `tracerInstance.isResolvable()` will always be false, and the producer falls through to letting Camel's `initTracer()` handle it — which defaults to `Tracer.NOOP` and `Propagator.NOOP` with warning logs. The extension would appear to work but silently produce no traces. > > I actually [experimented](https://github.com/jamesnetherton/camel-quarkus/tree/micrometer-observation) with this extension some time back. The approach I took is to explicitly bridge from the Quarkus-provided OpenTelemetry bean to Micrometer using `quarkus-micrometer-opentelemetry` (note this currently has [preview status](https://code.quarkus.io/?extension-search=opentelemetry%20bridge)) & `micrometer-tracing-bridge-otel`: > > ```java > @Inject > OpenTelemetry openTelemetry; > > // In the producer method: > Tracer otelTracer = openTelemetry.getTracer("camel"); > OtelCurrentTraceContext currentTraceContext = new OtelCurrentTraceContext(); > OtelTracer micrometerTracer = new OtelTracer(otelTracer, currentTraceContext, event -> {}, > new OtelBaggageManager(currentTraceContext, List.of(), List.of())); > OtelPropagator micrometerPropagator = new OtelPropagator(openTelemetry.getPropagators(), otelTracer); > > tracer.setTracer(micrometerTracer); > tracer.setPropagator(micrometerPropagator); > ``` > > This ensures Camel's Micrometer spans are correctly bridged into the same OTel trace context that Quarkus and Vert.x use, so parent-child span relationships work across the full stack. > > That way you don't burden the user with having to produce a bunch of CDI beans (which I think is what `MicrometerObservabilityConfiguration` is doing in the tests). > > A couple of other things worth considering: > > * SDK disable check: The opentelemetry2 extension checks `oTelRuntimeConfig.sdkDisabled()` and returns `null` when tracing is disabled. This extension should probably do the same for consistency. > * Test fidelity: Using opentelemetry-sdk-testing's `InMemorySpanExporter` instead of micrometer-tracing-test's `SimpleTracer` would validate the full pipeline (Camel → Micrometer bridge → OTel SDK → exporter), proving that spans actually reach OTel rather than only exercising the Micrometer layer. Thanks for your feedback! Considering quarkus-micrometer-opentelemetry is preview status and confirmed camel-micrometer-observability is tracing only(only register tracing observation handlers in camel)so this extension should be no metric export to otel. using quarkus-opentelemetry instead to bridge from the quarkus-opentelemetry bean to micrometer tracing with micrometer-tracing-bridge-otel will be enough. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
