轨迹采样

本文档介绍了抽样的概念，该概念是指是否将 span 的数据发送到 Cloud Trace。当 span 的数据发送到 Cloud Trace 时，系统会对该 span 进行抽样。记录轨迹中每个跨度的相关数据后，轨迹便会完成。但是，轨迹中经常会缺少一些跨度，因为分布式跟踪系统中的每个插桩组件都会独立决定是否记录其正在处理的跨度。

虽然每个组件都会自行决定要处理的跨度是否要进行抽样，但该决定可能会受到父级的抽样决定的影响。例如，假设每个组件都有一条规则，内容为“如果父级跨度被抽样，则抽样当前跨度；否则，抽样 50% 的跨度”。在这种情况下，以下为真：

  • 根 span 决定是否对轨迹中的所有 span 进行抽样。
  • 采样根 span 时，系统会采样轨迹中的所有 span。因此，轨迹已完成。

组件可以使用上下文将其抽样决策传递给子项。例如，在万维网联盟 (W3C) traceparent 标头中，sampled 标志会存储父级的抽样决策。

请勿将抽样与上下文传播混淆。抽样是指组件是否记录有关跨度的相关数据。上下文传播是指是否将有关 span 的信息（例如 span ID）传递给子组件。

抽样策略

采样决策可以基于头部或基于尾部。在基于头的采样中，当处理该跨度的组件收到请求时，系统会做出采样决策。在基于尾部的采样中，采样决策会延迟到整个轨迹可用之后。

在分布式跟踪系统的文档中，您可能会遇到“100% 抽样”一词。此字词可能适用于轨迹或组件。应用于轨迹时，表示所有 span 均已采样，或等同于轨迹已完成。应用于组件时，表示该组件会对其处理的每个跨度进行采样。

基于标头的采样

基于头的采样器通常配置为始终采样跨度或使用概率采样策略：

  • 使用始终采样配置时，所有服务跨度且可以写入轨迹数据的组件都会对其处理的跨度进行采样。理想情况下，所有轨迹都已完成，因此您拥有排查失败问题所需的信息。此类配置可能会导致您超出配额或存储空间费用限制。

  • 使用概率抽样时，并非所有跨度都会被抽样。 此方法的实际行为取决于组件的实现方式。在某些实现中，所有跨度都有相同的抽样概率。在某些情况下，父级的采样决策会影响是否对某个 span 进行采样。

轨迹可能不包含每个跨度。这可能是由于使用了概率抽样，也可能是由于配额或处理请求但不对跨度进行抽样的组件所致。

基于尾部的采样

Cloud Trace 不支持基于尾部的抽样；必须在向 Cloud Trace 发送数据的组件中做出抽样决策。

如果您想使用基于尾部的抽样，则可以使用中间服务器，该服务器会接收跟踪信息，并在做出抽样决策后将数据转发到 Cloud Trace。例如，您可以将 OpenTelemetry Collector 与尾随抽样处理器搭配使用，以做出延迟抽样决策。

如果您打算使用尾部抽样，请考虑以下事项：

  • 您必须先将所有跨度存储在轨迹中，然后才能做出抽样决策。 因此，您可能需要大量的临时存储空间，或者会产生其他开销。
  • 通常，所有可以为轨迹生成 span 的组件都需要协调。通常，使用 OpenTelemetry 的开发者会将具有相同轨迹 ID 的所有跨度路由到同一采集器。

抽样和 Google Cloud 服务

每项 Google Cloud 服务都会自行做出抽样决定，并且并非所有 Google Cloud 服务都会进行抽样。也就是说，服务可能永远不会向 Cloud Trace 发送数据。

当 Google Cloud 服务支持抽样时，该服务通常会实现以下内容：

  • 默认采样率。
  • 一种机制，用于将父级的抽样决策用作是否要对跨度进行抽样的提示。
  • 最大采样率。

如需请求 Google Cloud 服务添加对抽样的支持，请使用 Google 问题跟踪器。

后续步骤