跟踪记录采样

跟踪记录抽样可确定 Cloud Trace 接收哪些请求和 span，从而帮助您控制存储费用并保持在配额范围内，同时捕获足够的数据来排查性能问题。为了管理大量请求，分布式跟踪系统中的组件通常仅对部分轨迹进行抽样，或者遵循父 span 的抽样决策。

抽样与上下文传播不同：抽样控制组件是否记录 span 数据，而上下文传播在组件之间传递轨迹标识符，以便关联抽样的 span。

抽样策略

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

您可能会在分布式跟踪系统的文档中看到“100% 抽样”一词。此短语可能适用于轨迹或组件。如果应用于轨迹，则表示所有 span 都已采样，或者等效地表示轨迹是完整的。如果应用于组件，则表示该组件会对处理的每个 span 进行采样。

基于标头的抽样

基于头部的采样器通常配置为始终对 span 进行采样，或使用概率性采样策略：

  • 对于始终采样配置，处理和写入轨迹数据的组件会对每个 span 进行采样。理想情况下，所有轨迹都是完整的，因此您拥有排查故障所需的信息。 不过，始终抽样配置可能会导致您超出配额或存储费用限额。

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

轨迹可能不包含所有 span。如果您使用概率性抽样、超出配额或使用处理但不抽样 span 的组件，则预期会出现不完整的轨迹。

基于尾部的抽样

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

如果您使用基于尾部的抽样，还可以使用中间服务器来接收跟踪记录数据、评估抽样决策，并将抽样的 span 中继到 Trace。例如，您可以将 OpenTelemetry 收集器与 Tail Sampling Processor 搭配使用，以做出延迟抽样决策。

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

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

组件做出抽样决策

每个组件都会自行决定是否对正在处理的 span 进行抽样。不过，父级的采样决策（可能通过跟踪记录上下文提供给组件）可能会影响组件的决策。使用 traceparent 标头的应用可以使用 sampled 标志传递父级的抽样决策。

例如，假设每个组件都有一条规则，规定“如果父 span 被抽样，则对当前 span 进行抽样；否则，对 50% 的 span 进行抽样”。在此场景中，以下情况属实：

  • 根 span 决定了是否对轨迹中的所有 span 进行采样。
  • 如果对根 span 进行抽样，则会对轨迹中的所有 span 进行抽样。因此，轨迹已完成。

抽样和 Google Cloud 服务

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

如果 Google Cloud 服务支持抽样，该服务通常会实现以下功能：

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

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

后续步骤