Zipkin / Brave Integration (Tracing)

[Tim Dörnemann]

Hi everyone,

I'm in the middle of implementing tracing for our vert.x 3.3.2 application and I'm currently stuck with passing along the traceId and parentSpanId to other verticles when using Java proxies.

What already works:

HTTPEndpoint verticle receives events via SockJS bridge and starts tracing (brave.serverTracer().setStateUnknown( .... )). The resulting parentSpanId is set as a header in DeliveryOptions:

DeliveryOptions deliveryOptions = new DeliveryOptions().addHeader("__spanId", ""+parentSpanId) .addHeader("__traceId", ""+parentSpanId);
eventBus.publish("testChannel", msg, deliveryOptions);

The receiving verticle then extracts the values and traces its own call:

Long parentSpanId = Long.valueOf(msg.headers().get("__spanId"));
Long traceId = Long.valueOf(msg.headers().get("__traceId"));

// ...

brave.serverTracer().setStateCurrentTrace(traceId, spanId, parentSpanId, methodName);

This works -- Zipkins shows the trace as a chain of calls from HTTPEndpoint to the receiving verticle.

My questions:

(1) Our application makes heavy use of the auto-generated Java proxies for inter-verticle communication. How would I transport the tracing information from verticle A to verticle B then (A calls B)?

(2) Is there a better way than setting deliveryOptions to transport header when using send / publish? Adding an interceptor to eventBus and then call event.message().headers.add("__spanId", ""+id); ? What makes more sense in terms of overhead?

Thanks, Tim

[Clement Escoffier]

Hello Tim,

I’ve added some comment inline.

On 13 sept. 2016, at 11:39, Tim Dörnemann <tim.doe...@gmail.com> wrote:

Hi everyone,

I'm in the middle of implementing tracing for our vert.x 3.3.2 application and I'm currently stuck with passing along the traceId and parentSpanId to other verticles when using Java proxies.

What already works:

HTTPEndpoint verticle receives events via SockJS bridge and starts tracing (brave.serverTracer().setStateUnknown( .... )). The resulting parentSpanId is set as a header in DeliveryOptions:

DeliveryOptions deliveryOptions = new DeliveryOptions().addHeader("__spanId", ""+parentSpanId) .addHeader("__traceId", ""+parentSpanId);
eventBus.publish("testChannel", msg, deliveryOptions);

The receiving verticle then extracts the values and traces its own call:

Long parentSpanId = Long.valueOf(msg.headers().get("__spanId"));
Long traceId = Long.valueOf(msg.headers().get("__traceId"));

// ...

brave.serverTracer().setStateCurrentTrace(traceId, spanId, parentSpanId, methodName);

This works -- Zipkins shows the trace as a chain of calls from HTTPEndpoint to the receiving verticle.

My questions:

(1) Our application makes heavy use of the auto-generated Java proxies for inter-verticle communication. How would I transport the tracing information from verticle A to verticle B then (A calls B)?

You would need to have access to the delivery options when calling the method. Unfortunately, there is no way to do this at the moment. You can add a JSON Object to your method to propagate the span metadata.

The fact is: most of the tracing API have been thought with thread local in mind. But thread locals do not work in Vert.x , so you need to pass the metadata explicitly. If you have an idea about how it can be done, all ideas are welcome.

(2) Is there a better way than setting deliveryOptions to transport header when using send / publish? Adding an interceptor to eventBus and then call event.message().headers.add("__spanId", ""+id); ? What makes more sense in terms of overhead?

The issue with the interceptor is the collection of the metadata to add. How does the interceptor knows the span id ? 

Clement

Thanks, Tim

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAA_cZHaCmJWScnR9tH9zcAA5ACg7-TEiz3WGZTg%3DyO%3DA97NFwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Dörnemann]

Hi Clement,

thanks for answering so quickly. You're right about the interceptor and metadata. I now wrapped EventBus into a utility class to add tracing information as DeliveryOptions before calling the actual send / publish operation.

If something comes to my mind concerning passing the metadata, I'll let you know ;)

Thanks, Tim

Hello Tim,

Thanks, Tim

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAA_cZHaCmJWScnR9tH9zcAA5ACg7-TEiz3WGZTg%3DyO%3DA97NFwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/082181C4-1384-4B5F-BE5E-B95381087393%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Dr. Tim Dörnemann <tim.doe...@gmail.com>

Herrmannstr. 12, 35037 Marburg

Tel: +49-173-3104281

GPG: 0797 2FF8 8142 53A6 C04D 1D61 2C1B 36EB 148A 6A51