Distributed Tracing FAQ
** Is tracing only for request-response pair? How tracing happens for
indication where response is not expected.
Zipkin
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
Jaeger
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?
No.
** How to use Baggage in Jaeger headers?
Key: uberctx-{baggage-key}
Value: url-encoded string
** How to use Baggage in Zipkin B3 header?
baggage-:
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.
0 comments:
Post a Comment