Istio: Can I add randomly generated unique value as a header to every request before it reaches my application

There is important information that needs to be said in this subject. And it looks to me like You are trying to make a workaround tracing for an applications that does not forward/propagate headers in Your cluster. So I am going to mention few problems that can be encountered with this solution (just in case).

As mentioned in answer from Yuri G. You can configure unique x-request-id headers but they will not be very useful in terms of tracing if the requests are passing trough applications that do not propagate those x-request-id headers.

This is because tracing entire request paths needs to have unique x-request-id though out its entire trace. If the x-request-id value is different in various parts of the path the request takes, how are We going to put together the entire trace path?

In a scenario where two requests are received in application pod at the same time even if they had unique x-request-id headers, only application is able to tell which inbound request matches with which outbound connection. One of the requests could take longer to process and without forwarded trace header we can't tell which one is which.

Anyway for applications that do support forwarding/propagating x-request-id headers I suggest following guide from istio documentation.

Hope it helps.

apiVersion: networking.istio.io/v1alpha3kind: EnvoyFiltermetadata:  name: enable-envoy-xrequestid-in-response  namespace: istio-systemspec:  configPatches:  - applyTo: NETWORK_FILTER    match:      context: GATEWAY      listener:        filterChain:          filter:            name: "envoy.http_connection_manager"    patch:      operation: MERGE      value:        typed_config:          "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"          always_set_request_id_in_response: true

From reading the documentation of istio and envoy it seems like this is not supported by istio/envoy out of the box. As a workaround you have 2 options

Option 1: To set the x-envoy-force-trace header in virtual service

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: reviews-routespec:  hosts:  - reviews.prod.svc.cluster.local  http:  - headers:      request:        set:          x-envoy-force-trace: true

It will generate a header x-request-id if it is missing. But it seems like abuse of tracing mechanism.

Option 2: To use consistentHash balancing based on header, e.g:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata:   name: bookinfo-ratings spec:   host: ratings.prod.svc.cluster.local   trafficPolicy:     loadBalancer:       consistentHash:         httpHeaderName:           name: x-custom-request-id 

It will generate the header x-custom-request-id for any request that doesn't have this header. In this case the requests with same x-custom-request-id value will go always to the same pod that can cause uneven balancing.