0

Based on the Documentation envoy is capable of generating and propagating the traces to the Jaeger service cluster.

It also states that

in order to fully take advantage of tracing, the application has to propagate trace headers that Envoy generates while making calls to other services.

So assuming if a client calls -> service A -> calls Service B, service A being proxied behind envoy. If service A calls service B, this call from A to B would also have to go through envoy right. So the traced Id that was originally generated by envoy when the client called Service A, wouldn't this be propagated to Service B.

Why does the application (Service A) need to forward these headers?

Community
  • 1
  • 1
Vipin Menon
  • 2,892
  • 4
  • 20
  • 35
  • Only the application can know if a client call from A to B is the result of a preceding call, or something different / unrelated. Envoy cannot make this guess. That's why you need to propagate headers. – Joel Jan 21 '20 at 13:11

2 Answers2

3

When doing tracing in a service mesh, behind proxies, the traceID generated upon the initial client call is propagated automatically only so long as the call goes from proxy->proxy.

So:

  1. Client sends request
  2. Request hits some ingress proxy. A trace ID is generated
  3. Request is routed to proxy A in front of Service A. The trace ID is propagated from the ingress proxy to proxy A
  4. Request hits microservice A. The trace ID is propagated to here in the headers.
  5. Microservice A now has full control over the request. If the service discards all the HTTP headers when making it's outgoing request to Service B, then the traceID will also be discarded.

To get around this, Microservice A just needs to know which headers represent the traceIDs, how to append into it, and some state to make sure it makes it to outgoing requests. Then you'll get a full transaction chain.

Without the service propagating the headers, tracing basically gives you each path that ends in a microservice. Still useful, but not as complete of a picture.

justincely
  • 955
  • 7
  • 12
0

My interpretation of this is that We need to keep in mind that communication between services needs to support forwarding/"passing along" the trace ID's so that the tracing works correctly.

So it warns us against situations where:

Client calls -> Service A #using http request with trace ID in header.

Service A -> Service B #using tcp request that does not support headers and the trace ID header is lost.

This situation could break or limit tracing functionality.

On the other hand If we have situation where:

Client calls -> Service A #using http request with trace ID in header.

Service A -> Service B #using http request the trace ID is forwarded to service B.

This situation allows for the trace ID header to be present in both connections so the tracing can be logged and then viewed in tracing service dashboard. Then We can explore the path taken by the request and view the latency incurred at each hop.

Hope it helps.

Community
  • 1
  • 1
Piotr Malec
  • 3,429
  • 11
  • 16