分布式追踪的常见问题

Istio 使用 Envoy的分布式追踪系统集成。 由应用程序负责为后续传出请求转发追踪的 header 信息。

您可以在 Istio 分布式追踪（Jaeger， LightStep， Zipkin） 任务以及 Envoy 追踪文档中找到更多信息。

Istio 允许报告服务网格中工作负载到工作负载间通信的追踪 Span。 然而，为了将各种追踪 Span 整合在一起以获得完整的流量图，应用程序必须在传入和传出请求之间传播追踪上下文信息。

特别是，Istio 依赖于应用程序传播 B3 追踪 Headers 以及由 Envoy 生成的请求 ID。这些 Header 包括:

• x-request-id
• x-b3-traceid
• x-b3-spanId
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• b3

如果使用 LightStep，您还需要转发以下 Header：

• x-ot-span-context

如果使用 OpenTelemetry 或者 Stackdriver，您还需要转发以下 Header：

• traceparent
• tracestate

Header 传播可以通过客户端库完成，例如 Zipkin 或 Jaeger。 当然，这也可以手动完成，正如分布式追踪任务中所描述的那样。

对于基于 Envoy 的跟踪集成，Envoy（Sidecar 代理）代表所代理的应用程序将跟踪信息直接发送到跟踪后端。

Envoy：

• 在请求代理时为请求生成请求 ID 和跟踪标头（例如 X-B3-TraceId）
• 根据请求和响应元数据（即响应时间）为每个请求生成跟踪范围
• 将生成的跟踪范围发送到跟踪后端
• 将跟踪头转发到代理的应用程序

Istio 支持基于 Envoy 的 LightStep 和 Zipkin 的集成，以及所有与 Zipkin API 兼容的后端，包括 Jaeger。

启用了追踪功能的 Istio 最低配置文件是 Istio 与 Zipkin 兼容后端集成所需的全部内容。

如果请求中没有 Zipkin (B3) HTTP header，Istio sidecar 代理(Envoy) 会自动生成初始化的 headers。

尽管 Istio Sidecar 将处理关联应用程序实例的入站和出站请求， 它没有将出站请求与导致它们的入站请求相关联的隐式方法。可以实现这种关联的唯一方法是通过应用程序传播相关信息 （例如标头）从入站请求到出站请求。头传播可以通过客户端库或手动完成。 提供了进一步的讨论使用 Istio 进行分布式跟踪需要什么？。

从 Istio 1.0.3 开始，其 default 追踪采样率已经降低到 1%。 配置文件。 这意味着 Istio 捕获的 100 个追踪实例中只有 1 个将被报告给追踪后端。 demo 文件中的采样率仍设为 100%。 有关如何设置采样率的更多信息，可参见本节。

如果您仍然没有看到任何追踪数据，请确认您的端口是否符合 Istio 端口命名规范， 并公开适当的容器端口（例如，通过 pod spec）来启用 sidecar 代理（Envoy）能够对流量进行捕获。

如果您仅看到与出口代理相关联的跟踪数据，但没有看到与入口代理相关联的，那么它可能仍与 Istio 端口命名规范相关。 请先了解 Istio 1.3 中自动检测出口流量的协议相关部分。

Istio 通过 Envoy，目前支持基于百分比的采样策略来生成追踪信息。 有关如何设置此采样率的更多信息，请参阅本节。

如果您已经安装了启用追踪功能的 Istio，可以通过执行如下步骤禁用它：

# 用您的 Istio mesh 命名空间名填充下述命令中的 <istio namespace>。例如：istio-system
TRACING_POD=`kubectl get po -n <istio namespace> | grep istio-tracing | awk '{print $1}'`
$ kubectl delete pod $TRACING_POD -n <istio namespace>
$ kubectl delete services tracing zipkin   -n <istio namespace>
# 现在，手动从文件中移除 trace_zipkin_url 的实例，保存文件

然后遵循分布式追踪任务的清理部分的步骤进行后续操作。

如果您不想要追踪功能，那么就在安装 Istio 时禁用追踪。

可以这么做，但是必须用 Zipkin 兼容实例的完全合格的域名。比如：zipkin.mynamespace.svc.cluster.local。

目前 Istio 不提供对发布/订阅和事件总线协议的支持。这些技术都遵循 best-effort 网络模型，网络传输容易遭到破坏。