分布式追踪的常见问题

Istio 以两种不同的方式与分布式追踪系统集成: 基于 Envoy 的和基于 Mixer 的。 这两种追踪集成方法，都由应用程序负责为后续传出请求转发追踪的 header 信息。

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

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

特别是，Istio 依赖于应用程序传播 B3 追踪 header 以及由 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 和 追踪 header（例如，X-B3-TraceId）
• 基于请求和响应元数据信息（例如，响应时间）为每个请求生成追踪 span
• 发送生成的追踪 span 到追踪后端
• 将追踪 header 转发给被代理的应用程序

Istio 支持与基于 Envoy 的LightStep、Zipkin 进行追踪集成，也支持与所有 Zipkin API 兼容后端集成，包括 Jaeger。

对于基于 Mixer 的追踪，由 Mixer (通过 istio-telemetry 服务)提供与追踪后端的集成支持。 Mixer 追踪允许对分布式追踪进行额外级别的操作控制，包括对追踪 span 中包含数据的细粒度选择。 它还提供了将追踪数据发送到不被 Envoy 直接支持的后端的能力。

对于基于 Mixer 的追踪集成，Envoy：

• 当请求通过代理时生成请求 ID 和 追踪 header（例如，X-B3-TraceId）
• 调用 Mixer 异步进行遥测数据汇报
• 将追踪 header 转发给被代理的应用程序

Mixer：

• 基于 operator-supplied 配置为每个请求生成追踪 span
• 发送生成的追踪 span 到 operator-designated 追踪后端

Stackdriver 与 Istio 的追踪集成是通过 Mixer 进行追踪集成的一个例子。

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

如果请求没有提供 header，Istio sidecar 代理（Envoy）将为其生成初始 header。

尽管 Istio sidecar 将处理与之关联的应用程序实例的入站和出站请求，但它并不能隐式地将出站请求和与该出站请求对应的入站请求建立联系。 实现这种相关性的唯一方法是应用程序传递从入站请求到出站请求的关联信息（比如，header）。 header 的传播可以通过客户端库或手动完成。 使用 Istio 进行分布式追踪需要什么？提供了进一步的讨论。

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

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

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），并且可能遭到破坏。

缺省情况下，Envoy 代理会选择一部分需要进行跟踪的请求，由 Mixer 生成 Span。这样一来，在网格中基于 Mixer 策略实施机制就可以为运维人员所观察了。如果 istio-policy 在网格范围内被禁用，Mixer 就无法用这种方式参与跟踪了。

istio-telemetry 服务中的 Mixer 也可以用于从数据平面流量中生成跟踪数据。Mixer 的 Stackdriver 适配器就是一个例子，展示了支持这种方式的适配方式。

Mixer 生成的跟踪数据，Istio 还需依赖 Envoy 来生成跟踪上下文，并传递给需要传播上下文数据的应用之中。Envoy 不会直接把跟踪信息发送给跟踪后端，Mixer 会从 Envoy 上报数据中，根据运维策略提取请求中的客户端和服务端跟踪信息。这种情况下，运维人员可以精确的控制如何以及何时生成数据，还可以完全的把某些服务从跟踪信息中移除，或要求某些命名空间中的服务提供更多跟踪信息。

Mixer 为携带追踪 header 并到达 Mixer 的请求生成应用程序级追踪信息。 Mixer 会生成 span，并将其标记为 istio-mixer 以便用于它所做的任何关键工作，包括分发到各个适配器。

Envoy 缓存在数据路径上对 Mixer 的调用。 因此，通过 istio-policy 服务对 Mixer 发出的调用只会在特定的请求中发生，例如：缓存过期或者请求具有不同特征。 正是由于这个原因，您只看到了 Mixer 参与了您的 一些 追踪（而非全部）。

要关闭 Mixer 的应用程序级追踪，您必须编辑 istio-policy 的部署配置，删除命令行参数 --trace_zipkin_url。