HTTP request with special X-Request-Id can NOT be traced in Istio

Policies and Telemetry
1

curl a service with following two ways:

curl http://svc:20888/path  -H 'X-Request-Id: 8cda17a5-eb41-4ced-9843-acc826f95c8c'
curl http://svc:20888/path -H 'X-Request-Id: 27290d28d5c38da315a78399d71fc20b'

The former request with a valid uuid as x-request-id can be traced successfully,
while the latter with a invalid uuid does not be traced, thex-request-id is generated by some old app.

My question is why the formation of x-request-id affects the tracing.

The detail pls refer the issue https://github.com/istio/istio/issues/17437

2

Envoy conveys information about the sampling mode in the x-request-id, see https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#config-http-conn-man-headers-x-request-id.

The code is here.

3

Thanks for the code reference. Still not understand why user’s original x_request_id be checked and modified here.

4

Not sure of the history - probably best to raise the question on the envoy repo. In practice, once the sampling decision has been made, the decision is carried using the tracer specific context propagation format (e.g. b3) - so encoding it in the x-request-id shouldn’t be necessary.

5

Yes, x-b3-sampled is set in envoy and app propagate it across one request, which decide weather the trace should be collected.

6