分布式追踪的常见问题

Istio 以两种不同的方式与分布式追踪系统集成: 基于 Envoy(#how-mixer-based-tracing-works) 的和基于 Mixer 的。这两种追踪集成方法，都由应用程序负责为后续传出请求转发追踪的 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

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

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

Envoy：

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

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

对于基于 Mixer 的跟踪集成，Mixer （通过 istio-telemetry 服务解决）提供了后端跟踪的集成。Mixer 集成允许操作员对分布式跟踪进行更高级别的控制，包括对跟踪范围中包含的数据进行细粒度选择。它还提供将跟踪发送给 Envoy 不直接支持的后端。

对于基于 Mixer 的集成，Envoy：

• 在请求流经代理时为请求生成 ID 和跟踪报头 （例如，X-B3-TraceId）
• 调用 Mixer 进行常规异步遥测报告
• 将跟踪报头转发到代理的应用程序

Mixer：

• 基于 operator-supplied 配置为每个请求生成跟踪的范围
• 将生成的跟踪范围发送到 operator-designated 跟踪后端

使用 Istio 的 Stackdriver 跟踪集成是通过 Mixer 进行跟踪集成的一个示例。

启用了追踪功能的 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>
# 从 Mixer Deployment 中移除对 zipkin url 的引用
$ kubectl -n istio-system edit deployment istio-telemetry
# 现在，手动从文件中移除 trace_zipkin_url 的实例，保存文件

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

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

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

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

默认情况下，Mixer 通过为 Envoy 代理已经选择的要跟踪请求生成自己的跨度来参与跟踪。这使操作员可以观察到网格中基于 Mixer 策略的执行机制的参与。如果在网格范围内禁用 istio-策略 配置，则 Mixer 不会以这种方式参与跟踪。

Mixer 作为 istio-telemetry 服务，也可用于生成数据平面流量的跟踪范围。Mixer 的 Stackdriver 适配器就是支持此功能的一个示例。

对于由 Mixer 生成的跟踪，Istio 仍然依靠 Envoy 生成跟踪上下文并将其转发到必须传播上下文的应用程序中。Envoy 它自己没有直接地发送追踪信息到追踪后端，而是 Mixer 根据操作员提供的配置从常规的 Envoy 报告中提取客户端和服务器范围。用这种方式，操作员可以精确地控制何时以及如何生成跟踪数据，并可以从跟踪中完全删除某些服务，或者为某些命名空间提供更详细的信息。

Mixer 为到达 Mixer 并且带有追踪头的请求生成了应用级别的追踪。Mixer 为它做的任何关键工作都生成 span 并且打上了 istio-mixer 标签，包括分发到各个适配器。

在数据路径上 Envoy 缓存了到 Mixer 的调用。因此，通过 istio-policy 服务向 Mixer 发起的调用只是在一些特定的请求中会有，例如：缓存过期或者不一样的请求特性。由于这个原因，你会看到 Mixer 只参与了 一些 追踪。

要关闭 Mixer 的应用级别追踪 span，你必须编辑 istio-policy 的 deployment 配置，并且在命令行参数中删除 --trace_zipkin_url 参数。