tracing: add option to choice mutation policy for RequestID extension#16770
tracing: add option to choice mutation policy for RequestID extension#16770mattklein123 merged 11 commits intoenvoyproxy:mainfrom
Conversation
Signed-off-by: Shikugawa <rei@tetrate.io>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
…ate-sampling Signed-off-by: Shikugawa <rei@tetrate.io>
adisuissa
left a comment
There was a problem hiding this comment.
Can you please also update docs/root/intro/arch_overview/observability/tracing.rst?
| // Trace reason is decided by request_id by default. If true, these sampling strategy decisions | ||
| // will be decided by only tracing provider and :ref:`x-request-id<config_http_conn_man_headers_x-request-id>` | ||
| // never be modified. |
There was a problem hiding this comment.
Not sure if I understand this correctly, but please let me know if I'm wrong here:
| // Trace reason is decided by request_id by default. If true, these sampling strategy decisions | |
| // will be decided by only tracing provider and :ref:`x-request-id<config_http_conn_man_headers_x-request-id>` | |
| // never be modified. | |
| // By default, tracing requires the :ref:`x-request-id <config_http_conn_man_headers_x-request-id>` header to be set, and modifies its value. | |
| // If true, the request will be traced, and *x-request-id* will not be modified. |
There was a problem hiding this comment.
I think that we should add that the request will bypass x-request-id based tracing decision.
There was a problem hiding this comment.
Should this be an enum? Do we want to maybe support other modes of operation in the future?
There was a problem hiding this comment.
What operation will be expected in the future?
There was a problem hiding this comment.
I was interested in your perspective on this.
There was a problem hiding this comment.
Sure, with NONE, BYPASS. If you have high confidence we would never have some other trace sample strategy with request ID I'm fine with the current bool, just would like to make sure this is deliberative.
ea8eba5 to
adf26d7
Compare
|
@htuch @mattklein123 I'm considering that we might add a new tracing stat |
|
There are already a bunch of different forced |
|
Over to @mattklein123 for tracing implementation review. |
|
@mattklein123 is out for the week. I can do a pass while he's out but looking this over I agree with Adi this should include an update to docs/root/intro/arch_overview/observability/tracing.rst as I'm not quite sure from the API documentation what this option provides. Mind adding that for now and also seeing if the coverage failure is real? /wait |
Signed-off-by: Shikugawa <rei@tetrate.io>
mattklein123
left a comment
There was a problem hiding this comment.
Thanks for working on this. I fixed a similar issue recently with users requesting to not pack trace status into the UUID. See pack_trace_reason here: https://github.com/envoyproxy/envoy/blob/main/api/envoy/extensions/request_id/uuid/v3/uuid.proto
IMO it would be better to add a new configuration option for the default request ID provider to not use request ID for sampling. I think this would be a bit cleaner as it would be colocated with the other related option and also avoid adding new configuration to HCM. WDYT?
/wait
SGTM. Let me change. |
mattklein123
left a comment
There was a problem hiding this comment.
Thanks for iterating. Starting with an API comment.
/wait
mattklein123
left a comment
There was a problem hiding this comment.
Thanks LGTM with small comments.
/wait
Signed-off-by: Shikugawa <rei@tetrate.io>
| // Set whether to use :ref:`x-request-id<config_http_conn_man_headers_x-request-id>` or not. | ||
| // This defaults to true. | ||
| // Set whether to use :ref:`x-request-id<config_http_conn_man_headers_x-request-id>` for sampling or not. | ||
| // This defaults to true. See the :ref:`context propagation <arch_overview_tracing_context_propagation>` |
There was a problem hiding this comment.
| // This defaults to true. See the :ref:`context propagation <arch_overview_tracing_context_propagation>` | |
| // This defaults to true. See the :ref:`context propagation <arch_overview_tracing_context_propagation>` overview |
…envoyproxy#16770) Signed-off-by: Shikugawa <rei@tetrate.io>
Signed-off-by: Shikugawa rei@tetrate.io
Commit Message: Close #16530. In the previous implementation, the sampling decision was determined by the UUID and additional headers. In this state, without the additional headers, the sampling decision depends entirely on the UUID. In this case, in an environment where Envoy is mixed with other sidecars that have different request ID generation procedures, Envoy receiving requests from other sidecars will always send a span with invalid sampling. This behavior is considered to be unnatural as the default behavior. Therefore, in this PR, we provide the
mutation_policyoption for Request ID extension. When this option is configured asSKIP, it will always skip the request ID mutation and execute request ID (currently UUID) independent sampling decision algorithm and enable sampling of the span by default. With this flag in place, the sampling is completely determined by the additional header, which makes the behavior intuitive and independent of the sidecar type.Additional Description:
Risk Level: Low
Testing: Unit
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]
cc @basvanbeek