采样
使用分布式跟踪，您可以观察请求在分布式系统中从一个服务到另一个服务的传递情况。出于多种原因，这对于理解服务连接和诊断延迟问题非常实用。
然而，如果您的大多数请求都是成功的200，并且没有不可接受的延迟或错误，您真的需要所有这些数据吗？事实是，您并不总是需要大量的数据来获得正确的洞察力。您只需要正确的数据样本。
采样的核心思想是控制您发送到可观察性后端的跨度，以降低摄取成本。不同的组织将有自己的采样原因，不仅如此，还有可能要采样什么。您可能希望自定义您的采样策略以实现以下目标：
- 管理成本：如果您有大量的遥测数据，那么从遥测后端供应商或云提供商那里导出和存储每个跨度可能会产生巨额费用。
- 关注有趣的跟踪：例如，您的前端团队可能只想查看具有特定用户属性的跟踪。
- 过滤噪音：例如，您可能希望过滤掉健康检查。
术语
在讨论采样时使用一致的术语非常重要。跟踪或跨度被认为是“已采样”或“未采样”：
- 已采样：已处理并导出的跟踪或跨度。由于采样器选择它作为人口的代表，因此它被认为是“已采样”。
- 未采样：未处理或未导出的跟踪或跨度。由于不是采样器选择的，因此被认为是“未采样”。
有时，这些术语的定义会混淆。您可能会发现有人说他们正在“采样数据”，或者未处理或未导出的数据被认为是“已采样”。这些都是不正确的说法。
首部采样
首部采样是一种尽早做出采样决策的采样技术。不会通过审查整个跟踪来做出采样或丢弃跨度或跟踪的决策。
例如，最常见的首部采样形式是一致概率采样。它也可以称为确定性采样。在这种情况下，采样决策是基于跟踪ID和要采样的跟踪的所需百分比。这确保了整个跟踪以一致的速率进行采样，例如所有跟踪的5%。
首部采样的优点包括：
- 易于理解
- 易于配置
- 高效率
- 可以在跟踪收集流程的任何阶段完成
首部采样的主要缺点是无法基于整个跟踪中的数据做出采样决策。这意味着首部采样在某种程度上会有效，但对于必须考虑整个系统信息的采样策略来说是完全不够的。例如，无法使用首部采样来确保采样所有包含错误的跟踪。对于这种情况，您需要使用尾部采样。
尾部采样
尾部采样是通过考虑跟踪中的所有或大多数跨度来决定是否采样一个跟踪的过程。尾部采样允许您根据跟踪的不同部分派生出的特定条件对跟踪进行采样，这是首部采样无法实现的。
您可以使用尾部采样的一些示例包括：
- 始终对包含错误的跟踪进行采样
- 根据总体延迟对跟踪进行采样
- 基于跟踪中一个或多个跨度上的特定属性的存在或值对跟踪进行采样；例如，对于一个新部署的服务，采样更多的跟踪
- 根据某些条件对跟踪应用不同的采样率
正如您所看到的，尾部采样允许更高级别的复杂性。对于需要采样遥测数据的较大系统，几乎总是需要使用尾部采样来平衡数据量与数据的有用性。
目前，尾部采样存在三个主要缺点：
- 尾部采样可能很难实现。根据您可以使用的采样技术类型，这可能并不总是一种“设置并忘记”的事情。随着系统的更改，您的采样策略也将改变。对于大型复杂的分布式系统而言，实施采样策略的规则可能也是相当大而复杂的。
- 运行尾部采样可能很困难。实现尾部采样的组件必须是能够接受和存储大量数据的有状态系统。根据流量模式，这可能需要几十甚至几百个以不同方式利用资源的节点。此外，如果尾部采样器无法跟上收到的数据量，可能需要将其“回退”到计算方面较不复杂的采样技术。由于这些因素，监视尾部采样组件以确保它们具有完成正确采样决策所需的资源非常重要。
- 如今，尾部采样往往成为特定供应商技术的领域。如果您使用付费供应商进行可观察性，那么对您来说最有效的尾部采样选项可能会受限于供应商所提供的范围。
最后，对于某些系统，尾部采样可能与首部采样一起使用。例如，产生大量跟踪数据的一组服务可能首先使用首部采样只对少量跟踪进行采样，然后在遥测流程的后续阶段使用尾部采样进行更复杂的采样决策，然后导出到后端。这通常是为了保护遥测流程免受过载的影响。
支持
收集器
OpenTelemetry收集器包括以下采样处理器：
语言SDK
对于OpenTelemetry API和SDK的各个语言特定实现，您可以在相应的文档页面上找到对采样的支持：