Hi James You need to use the camel-opentracing component to propagate the active span via the camel context. Information on configuring for spring-boot can be found here[1], as well as an example[2] - see service1.
As the trace context is being provided as B3 format, you will need to provide a tracer (bean) that is capable of understanding this format - either zipkin or jaeger (with specific config or env var). If you can wait for the soon to be released camel 2.21, you will only need to include the jaeger-tracerresolver (version 0.25) dependency in your pom (along with camel-opentracing-starter) without having to explicitly create the Tracer bean. [3] provides an example config for using in Istio - note the propagation format env var. Regards Gary [1] https://github.com/apache/camel/blob/master/components/camel-opentracing/src/main/docs/opentracing.adoc#spring-boot [2] https://github.com/apache/camel/tree/master/examples/camel-example-opentracing [3] https://github.com/objectiser/opentracing-prometheus-example/blob/master/simple/services-istio-kubernetes.yml#L24-L38 On Thu, Mar 15, 2018 at 4:24 PM, James Falkner <[email protected]> wrote: > Hey all, > > I've been doing some experimenting with tracing Camel apps (that happen to > be running in an Istio-ified OpenShift but that's not important). > > My app consists of some camel routes exposed with REST that call out to > other RESTful services to form an aggregate response to send back to the > caller, using the splitter and enricher patterns (and AggregationStrategy > POJOs) to do so. > > What I found was that the OpenTracing X-b3-* HTTP headers[1] aren't > preserved across these calls, so the tracing gets screwed up and spans > aren't associated with the proper traces. They are somehow being stripped, > somewhere. > > For example, here[2] are the two uses of split/enrich from my app. Using > the logger I determined that headers weren't being preserved. The > workaround I found was that, > in the AggregationStrategy POJOs[3] if I do this: > > original.getOut().setHeaders(original.getIn().getHeaders()); > > Before returning the original exchange, then things work. Basically I am > manually ensuring that the headers, if stripped, are added back. Is this a > bug in camel? Is this workaround good? > > -James > > [1] https://github.com/openzipkin/b3-propagation > [2] https://github.com/jbossdemocentral/coolstore-microservice/ > blob/1.2.x/coolstore-gw/src/main/java/com/redhat/coolstore/api_gateway/ > ProductGateway.java#L100-L101 > [3] https://github.com/jbossdemocentral/coolstore-microservice/ > blob/1.2.x/coolstore-gw/src/main/java/com/redhat/coolstore/api_gateway/ > ProductGateway.java#L169-L196 > > >
