跟踪记录采样

本文档介绍了抽样的概念，即“抽样” span 的数据发送到 Cloud Trace。当一个 span 上 发送到 Cloud Trace，然后对该 span 进行采样。当每个 跟踪记录中的 span，则跟踪记录完整。但经常跟踪 缺少 span，因为分布式跟踪中的每个插桩组件 系统会自动决定是否记录 处理对象。

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

  • 根 span 决定对跟踪记录中的所有 span 是否进行采样。
  • 采样根 span 时，系统会采样轨迹中的所有 span。因此， 即表明跟踪记录已完成

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

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

抽样策略

采样决策可以基于头部或尾部。 在“头部抽样”中，抽样决定是在收到请求后给出的 发送到处理 span 的组件接收的数据。 在“基于尾部的采样”中，采样决策会延迟 直到整个跟踪记录可用为止。

您可能会遇到“100% 抽样”这样的短语文档 分布式跟踪系统这个短语可能适用于跟踪记录或 组件。如果应用于跟踪记录，则意味着已对所有 span 采样， （等同于跟踪完成）应用到组件时 这意味着组件会对处理的每个 span 进行采样。

头部采样

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

  • 采用始终采样配置时，所有组件 该服务 span 可以写入跟踪记录数据， 过程。理想情况下，所有轨迹都已完成，因此您拥有排查失败问题所需的信息。这种类型的配置可能会导致您超出配额， 或存储空间费用上限

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

轨迹可能不包含每个跨度。这是意料之中的， 概率抽样，也可能是因为配额或部分 处理请求，但不对 span 进行采样。

尾部抽样

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

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

如果您打算使用尾采样，请考虑以下几点：

  • 在做出采样决策之前，您必须将所有 span 存储在跟踪记录中。 因此，您可能需要大量的临时存储空间，或者会产生其他开销。
  • 一般来说，所有可以为轨迹生成 span 的组件都需要协调。通常，使用 OpenTelemetry 的开发者会路由所有 span 同一个跟踪记录 ID 与同一收集器相关联。

抽样和 Google Cloud 服务

每项 Google Cloud 服务都会做出自己的抽样决策， 而不是所有 Google Cloud 服务示例也就是说，服务可能永远不会 Cloud Trace

如果某项 Google Cloud 服务支持采样，则该服务通常 实现以下各项：

  • 默认采样率。
  • 一种机制，使用父实体的抽样决策作为提示，确定是否 对 span 采样。
  • 最大采样率。

如需请求 Google Cloud 服务添加对抽样的支持，请执行以下操作： 使用 Google 问题跟踪器。

后续步骤