istio 过滤跟踪标头（如 x-b3-*）在哪里

Question

我看到 istio 在启用跟踪时将x-b3-traceid、x-b3-spanid 和其他标头添加到传入请求中。但是它们都没有返回给调用者。

我能够在日志中捕获x-b3-traceid，并可以在 Tempo/Grafana 中找到它。 我可以在 istio 特使代理（sidecar）上看到traceid，我可以使用EnvoyFilter 访问标头。

谁能告诉我它是在哪里过滤的？

Answer 1

TL;DR 这些是标头，以便jaeger 或zipkin 可以跟踪单个请求。此应用程序负责它们的正确传播。此外，它们是请求标头而不是响应标头，所以一切正常。

---

解释：

看起来不错。首先，让我们从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 标头仅包含少量数据：ID 和采样标志与您的应用程序请求同步，并允许对方继续跟踪。 https://github.com/openzipkin/b3-propagation#overall-process 如果启用了 zipkin，包括这些 ID 和其他数据（如持续时间）在内的详细信息会在请求完成后异步发送到 zipkin。您可以在“示例流程”http://zipkin.io/pages/architecture.html

下查看相关图表

X-B3-TraceId 与同一客户端的每次调用相同还是不同？每个整体要求不同。进入系统的每个顶级请求都有

不同的跟踪 ID。该请求中的每个步骤都有不同的 span id

X-B3-SpanId 没有发回给调用者，那么我如何设置下一个调用的父级（显示当前调用的 X-B3-SpanId）？这是一个响应，显示标题中没有 X-B3-SpanId： 我不太明白。父级仅在创建跨度时使用。

跨度是在发送请求之前创建的。因此，在 span 创建中与响应标头无关。

在this doc，您可以从 istio 站点找到有关标头的信息：

分布式跟踪使用户能够通过分布在多个服务中的网格跟踪请求。这有助于通过可视化更深入地了解请求延迟、序列化和并行性。

Istio 利用 Envoy 的分布式跟踪功能提供开箱即用的跟踪集成。具体来说，Istio 提供了安装各种跟踪后端和配置代理以自动向它们发送跟踪跨度的选项。请参阅 Zipkin、Jaeger 和 Lightstep 任务文档，了解 Istio 如何与这些跟踪系统协同工作。

如果你想完全了解它是如何工作的，你应该阅读this envoyproxy documentation：

分布式跟踪允许开发人员在大型面向服务的架构中获得调用流的可视化。它对于理解序列化、并行性和延迟来源非常重要。 Envoy 支持与系统范围跟踪相关的三个功能：

• 请求 ID 生成：Envoy 将在需要时生成 UUID 并填充 x-request-id HTTP 标头。应用程序可以转发 x-request-id 标头以进行统一的日志记录和跟踪。

• 客户端跟踪 ID 加入：x-client-trace-id 标头可用于将不受信任的请求 ID 加入受信任的内部 x-request-id。

• 外部跟踪服务集成：Envoy 支持可插拔的外部跟踪可视化提供程序，分为两个子组：

• 作为 Envoy 代码库一部分的外部跟踪器，例如 LightStep、Zipkin 或任何 Zipkin 兼容的后端（例如 Jaeger）和 Datadog。

• 作为第三方插件提供的外部跟踪器，例如 Instana。

回答您的问题：

谁能告诉我它是在哪里过滤的？

他们默认这样做。负责对这些标头进行操作的是应用程序（zipkin、jaeger）。此外，它们是请求标头而不是响应标头，所以一切正常。