[
https://issues.apache.org/jira/browse/CAMEL-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004419#comment-17004419
]
Dietrich Schulten edited comment on CAMEL-14322 at 12/28/19 7:59 AM:
---------------------------------------------------------------------
SpanDecorators are not a good fit, they are component-specific and they run for
every span, not just for the beginning of an exchange.
There are two issues to solve:
# Allow to observe spans and put traceId, spanId and baggage items into the MDC
# Allow to add an observer on all exchanges which allows you to write an
observer to add information from the exchange to the current span, so you do
not have to add interceptors on routes.
The first is already possible. I was able to implement an {{MdcTracerObserver}}
experimentally, based {{on the
io.opentracing.contrib:opentracing-api-extensions-tracer}}. Basically, you wrap
the {{io.opentracing.Tracer}} into an {{APIExtensionsTracer}} where you can
register a {{TraceObserver}}. However I would suggest to make this similar to
camel-zipkin and integrate with the {{useMDCLogging}} flag on CamelContext. If
that flag is true, we could wrap the tracer and add a default
{{MdcTracerObserver}} similar to my experiment. In addition, we could consider
to let {{OpenTracingTracer}} implement the {{APIExtensionsManager}} interface
directly so people could add their own tracerObservers, as suggested in the
readme of opentracing-api-extensions.
What do you think? Should I create a PR along these lines?
The second issue would require to introduce something like a
{{TracingExchangeObserver}} with a method that receives the current exchange
and the active span and call that in {{OpenTracingEventNotifier.notify}} and
{{OpenTracingRoutePolicy.onExchangeBegin}}.
I have made sure that the solution works with Karaf in a forked branch of the
karaf-camel-example-java:
[https://github.com/dschulten/karaf/tree/opentracing-mdc]
was (Author: dschulten):
SpanDecorators are not a good fit, they are component-specific and they run for
every span, not just for the beginning of an exchange.
There are two issues to solve:
# Allow to observe spans and put traceId, spanId and baggage items into the MDC
# Allow to add an observer on all exchanges which allows you to write an
observer to add information from the exchange to the current span, so you do
not have to add interceptors on routes.
The first is already possible. I was able to implement an {{MdcTracerObserver}}
experimentally, based {{on the
io.opentracing.contrib:opentracing-api-extensions-tracer}}. Basically, you wrap
the {{io.opentracing.Tracer}} into an {{APIExtensionsTracer}} where you can
register a {{TraceObserver}}. However I would suggest to make this similar to
camel-zipkin and integrate with the {{useMDCLogging}} flag on CamelContext. If
that flag is true, we could wrap the tracer and add a default
{{MdcTracerObserver}} similar to my experiment. In addition, we could consider
to let {{OpenTracingTracer}} implement the {{APIExtensionsManager}} interface
directly so people could add their own tracerObservers, as suggested in the
readme of opentracing-api-extensions.
The second issue would require to introduce something like a
{{TracingExchangeObserver}} with a method that receives the current exchange
and the active span and call that in {{OpenTracingEventNotifier.notify}} and
{{OpenTracingRoutePolicy.onExchangeBegin}}.
I have made sure that the solution works with Karaf in a forked branch of the
karaf-camel-example-java:
[https://github.com/dschulten/karaf/tree/opentracing-mdc]
> Allow to customize opentracing information
> ------------------------------------------
>
> Key: CAMEL-14322
> URL: https://issues.apache.org/jira/browse/CAMEL-14322
> Project: Camel
> Issue Type: Improvement
> Reporter: Dietrich Schulten
> Priority: Major
>
> Allow to hook in a custom enricher where you can add custom data from the
> current exchange to opentracing traces.
> E.g. put a process instance id from some process manager into opentracing
> baggages for correlation purposes.
> Also see CAMEL-12879 and [https://stackoverflow.com/q/59428904/743507]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
