分布式追踪的常见问题

分布式追踪的常见问题

如何使用 Istio 实现分布式追踪？

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

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

使用 Istio 进行分布式追踪需要什么？

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 的跟踪集成，Envoy（Sidecar 代理）代表所代理的应用程序将跟踪信息直接发送到跟踪后端。

Envoy：

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

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

基于 Mixer 的跟踪是如何工作的？

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

对于基于 Mixer 的集成，Envoy：

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

Mixer：

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

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

分布式追踪所需的 Istio 最低配置是什么？

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

为什么要初始化生成 Zipkin (B3) HTTP header?

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

为什么 Istio 不能代替应用程序传播标头？

尽管 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 时禁用追踪。

Istio 是否能发送追踪信息到外部与 Zipkin 兼容的后端？

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

Istio 支持请求跟踪 vert.x 事件总线消息吗？

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

Mixer 在 Istio 跟踪踪故事中扮演的什么角色？

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

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

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

为什么在我的一些分布式追踪中会有 `istio-mixer` span？

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

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

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

分布式追踪