Distributed Tracing FAQ

** Is tracing only for request-response pair? How tracing happens for indication where response is not expected.

This is: One-way RPC Tracing. One-way is the same as normal RPC tracing, except there is no response anticipated.
In normal RPC tracing 4 annotations are used: “cs” “sr” (request) then “ss” “cr” (response). In one-way tracing, the first two are used “cs” “sr” as there is no response returned to the caller.
So, the client adds “cs” to a span and reports it to zipkin. Then, the server adds “sr” to the same span and reports it. Neither side add Span.timestamp or duration because neither side know both when the span started and finished.
CS = Client Send
SR = Server Receive
SS = Server Sent
CR = Client Receive
They are annotations for spans in Zipkin format


For asynchronous messaging communications: “span.kind” tag values are: Producer and Consumer
For synchronous RPC communications: “span.kind” tag values are: Client and Server
The span.kind=server tag denotes an entry span, e.g. a span created in the local code in response to an external request. Likewise, span.kind=client denotes an exit span, e.g. a call made from the local code to another server.

** At ‘Istio service mesh’, does ‘Envoy sidecar proxy’ add ‘B3 headers’ for incoming message or outgoing message,
For incoming message.

** What if some of the microservices use Zipkin format and new microservices use Jaeger format at K8s cluster?
Jaeger provides backward compatibility. So, just need to route ‘Zipkin format data’ from ‘legacy services’ to ‘Jaeger backend’ using ‘zipkin collector’

Backwards compatibility with Zipkin
Although we recommend instrumenting applications with OpenTracing API and binding to Jaeger client libraries to benefit from advanced features not available elsewhere, if your organization has already invested in the instrumentation using Zipkin libraries, you do not have to rewrite all that code. Jaeger provides backwards compatibility with Zipkin by accepting spans in Zipkin formats (Thrift or JSON v1/v2) over HTTP. Switching from Zipkin backend is just a matter of routing the traffic from Zipkin libraries to the Jaeger backend.

** The ‘Envoy sidecar proxy’ at ‘Istio Service Mesh’ sends collected span data (JSON format) to Jaeger Collector. It it for incoming message or outgoing message?
The ‘Envoy sidecar proxy’ sends a single span (JSON format), asynchronously, anytime, after receiving response for the request which was originated by application.

** Can we bypass Jaeger Agent?
Yes for C++ Jaeger ClientLib.

** Can Jaeger Collector work on UDP?

** How to use Baggage in Jaeger headers?
Key: uberctx-{baggage-key}
Value: url-encoded string

** How to use Baggage in Zipkin B3 header?
The support is only for Java and Go languages

** What is thrift
https://en.wikipedia.org/wiki/Apache_Thrift. It is for RPC with format like: JSON, Binary etc.

** what is TChannel?
It is a protocol over TCP for RPC

** Does Zipkin supports binary/compress format?
Zipkin can work on TChannel. It also supports compact Thrift format. However, Jaeger is better as being CNCF project.

** TChannel, Thrift, or its combination, which one is better?
Now, Jaeger collector supports gRPC as well. gRPC can be even better choice.

** Wild card query is supported at Jaeger UI?
No, due to limitations of other storage implementations. However, one can use Kibana + Elastic Search for the same.


Post a Comment