istio 过滤跟踪 headers 在哪里，比如 x-b3-*
where is istio filtering trace headers like x-b3-*
我看到 istio 在启用跟踪时向传入请求添加 x-b3-traceid、x-b3-spanid 和其他 header。但是其中 none 被返回给调用者。
我能够在日志中捕获 x-b3-traceid，并且可以在 Tempo/Grafana 中找到它。
我可以在 istio envoy 代理（边车）上看到 traceid，我可以使用 EnvoyFilter.
访问 header
有人可以告诉我它是在哪里过滤的吗？
TL;DR
这些是 header，因此 jaeger 或 zipkin 可以跟踪单个请求。此应用程序负责它们的正确传播。此外，它们是 请求 headers 和 不响应 header，所以一切正常。
解释：
看起来不错。首先，让我们从 what these requests are:
开始
Field Name Request/ Response Type Description
x-request-id request The x-request-idheader is used by Envoy to uniquely identify a request as well as perform stable access logging and tracing
x-b3-traceid request The x-b3-traceidHTTP header is used by the Zipkin tracer in Envoy. The TraceId is 64-bit in length and indicates the overall ID of the trace. Every span in a trace shares this ID
x-b3-spanid request The x-b3-spanidHTTP header is used by the Zipkin tracer in Envoy. The SpanId is 64-bit in length and indicates the position of the current operation in the trace tree
x-b3-sampled request The x-b3-sampledHTTP header is used by the Zipkin tracer in Envoy. When the Sampled flag is either not specified or set to 1, the span will be reported to the tracing system
在github你可以找到问题：What is the usage of X-B3-TraceId, traceId, parentSpanId and spanId ?:
http headers contain only a small amount of data: IDs and sampling flags these go synchronously with your application requests, and allow the other side to continue the trace. https://github.com/openzipkin/b3-propagation#overall-process If zipkin is enabled, details including these IDs and other data like duration send asynchronously to zipkin after a request completes. you can see a diagram about that here under "Example Flow" http://zipkin.io/pages/architecture.html
X-B3-TraceId is same or different from every call of the same client? different per overall request. each top-level request into your system has
不同的跟踪 ID。该请求中的每个步骤都有不同的 span id
X-B3-SpanId is not send back to the caller, then how could i set the parent(which show be the X-B3-SpanId of the the present call) of the next call? Here is a response shows the absent of X-B3-SpanId in the header： I don't quite understand. The parent is only used when creating a span.
跨度是在发送请求之前创建的。因此，在跨度创建中与响应 headers 无关。
在 this doc 中，您可以从 istio 站点找到有关 headers 的信息：
Distributed tracing enables users to track a request through mesh that is distributed across multiple services. This allows a deeper understanding about request latency, serialization and parallelism via visualization.
Istio leverages Envoy’s distributed tracing feature to provide tracing integration out of the box. Specifically, Istio provides options to install various tracing backend and configure proxies to send trace spans to them automatically. See Zipkin, Jaeger and Lightstep task docs about how Istio works with those tracing systems.
如果你想完全理解它是如何工作的，你应该阅读 this envoyproxy documentation:
Distributed tracing allows developers to obtain visualizations of call flows in large service oriented architectures. It can be invaluable in understanding serialization, parallelism, and sources of latency. Envoy supports three features related to system wide tracing:
Request ID generation: Envoy will generate UUIDs when needed and populate the x-request-id HTTP header. Applications can forward the x-request-id header for unified logging as well as tracing.
Client trace ID joining: The x-client-trace-id header can be used to join untrusted request IDs to the trusted internal x-request-id.
External trace service integration: Envoy supports pluggable external trace visualization providers, that are divided into two subgroups:
External tracers which are part of the Envoy code base, like LightStep, Zipkin or any Zipkin compatible backends (e.g. Jaeger), and Datadog.
External tracers which come as a third party plugin, like Instana.
回答您的问题：
Can someone let me know where it is filtered?
他们默认这样做。负责对这些 header 执行操作的是应用程序（zipkin、jaeger）。此外，它们是 请求 headers 和 不响应 header，所以一切正常。
我看到 istio 在启用跟踪时向传入请求添加 x-b3-traceid、x-b3-spanid 和其他 header。但是其中 none 被返回给调用者。
我能够在日志中捕获 x-b3-traceid，并且可以在 Tempo/Grafana 中找到它。
我可以在 istio envoy 代理（边车）上看到 traceid，我可以使用 EnvoyFilter.
有人可以告诉我它是在哪里过滤的吗？
TL;DR
这些是 header，因此 jaeger 或 zipkin 可以跟踪单个请求。此应用程序负责它们的正确传播。此外，它们是 请求 headers 和 不响应 header，所以一切正常。
解释：
看起来不错。首先，让我们从 what these requests are:
开始
Field Name Request/ Response Type Description
x-request-id request The x-request-idheader is used by Envoy to uniquely identify a request as well as perform stable access logging and tracing
x-b3-traceid request The x-b3-traceidHTTP header is used by the Zipkin tracer in Envoy. The TraceId is 64-bit in length and indicates the overall ID of the trace. Every span in a trace shares this ID
x-b3-spanid request The x-b3-spanidHTTP header is used by the Zipkin tracer in Envoy. The SpanId is 64-bit in length and indicates the position of the current operation in the trace tree
x-b3-sampled request The x-b3-sampledHTTP header is used by the Zipkin tracer in Envoy. When the Sampled flag is either not specified or set to 1, the span will be reported to the tracing system
在github你可以找到问题：What is the usage of X-B3-TraceId, traceId, parentSpanId and spanId ?:
http headers contain only a small amount of data: IDs and sampling flags these go synchronously with your application requests, and allow the other side to continue the trace. https://github.com/openzipkin/b3-propagation#overall-process If zipkin is enabled, details including these IDs and other data like duration send asynchronously to zipkin after a request completes. you can see a diagram about that here under "Example Flow" http://zipkin.io/pages/architecture.html
X-B3-TraceId is same or different from every call of the same client? different per overall request. each top-level request into your system has
不同的跟踪 ID。该请求中的每个步骤都有不同的 span id
X-B3-SpanId is not send back to the caller, then how could i set the parent(which show be the X-B3-SpanId of the the present call) of the next call? Here is a response shows the absent of X-B3-SpanId in the header： I don't quite understand. The parent is only used when creating a span.
跨度是在发送请求之前创建的。因此，在跨度创建中与响应 headers 无关。
在 this doc 中，您可以从 istio 站点找到有关 headers 的信息：
Distributed tracing enables users to track a request through mesh that is distributed across multiple services. This allows a deeper understanding about request latency, serialization and parallelism via visualization.
Istio leverages Envoy’s distributed tracing feature to provide tracing integration out of the box. Specifically, Istio provides options to install various tracing backend and configure proxies to send trace spans to them automatically. See Zipkin, Jaeger and Lightstep task docs about how Istio works with those tracing systems.
如果你想完全理解它是如何工作的，你应该阅读 this envoyproxy documentation:
Distributed tracing allows developers to obtain visualizations of call flows in large service oriented architectures. It can be invaluable in understanding serialization, parallelism, and sources of latency. Envoy supports three features related to system wide tracing:
Request ID generation: Envoy will generate UUIDs when needed and populate the x-request-id HTTP header. Applications can forward the x-request-id header for unified logging as well as tracing.
Client trace ID joining: The x-client-trace-id header can be used to join untrusted request IDs to the trusted internal x-request-id.
External trace service integration: Envoy supports pluggable external trace visualization providers, that are divided into two subgroups:
External tracers which are part of the Envoy code base, like LightStep, Zipkin or any Zipkin compatible backends (e.g. Jaeger), and Datadog.
External tracers which come as a third party plugin, like Instana.
回答您的问题：
Can someone let me know where it is filtered?
他们默认这样做。负责对这些 header 执行操作的是应用程序（zipkin、jaeger）。此外，它们是 请求 headers 和 不响应 header，所以一切正常。