前言：本文直击传统采样方案的痛点，着重介绍腾讯云 APM 新推出的采样策略优势：既能降低 APM 使用成本，又不会对用户的使用体验带来明显影响。

概述

应用性能管理（Application Performance Management），简称 APM，是一种监控和管理软件应用程序性能及其用户体验的技术。

APM 不仅能够帮助 IT 团队实时监控和优化应用程序性能，而且能够快速定位和解决性能问题，提升用户体验。同时又能优化资源利用与容量规划，促进团队协作，并支持数据驱动的决策。因此，APM 工具在现代 IT 运维和开发领域扮演着至关重要的角色，是实现应用可观测性的核心。

分布式链路追踪能力是 APM 工具最重要的能力之一，能够帮助用户自动构建每次请求的完整路径，实现一站式全链路问题分析，提高定位问题的效率。

应用接入 APM 以后，会根据用户请求向 APM 系统上报链路信息，链路信息以 Trace 和 Span 的形式承载。其中，Trace 代表一条完整的链路，描述一次用户请求在多个分布式应用中经过的路径；Span 代表链路中的一个环节，可以是一次 RPC 调用、一次 HTTP 调用、一次消息发送，也可以是应用内部的一次本地函数调用。

在实际使用场景中，随着业务规模的增长，向 APM 上报的链路数据会增多，与此同时，APM 使用成本也会随之增加，然而并不是每一条 Trace 都值得被 APM 系统记录，因为分布式系统之间的相互调用会产生大量重复的链路信息。

特别是在系统健康运行的时候，重复而冗余的链路信息对于用户分析性能问题并没有太大的价值。采样（Sampling）的引入，可以减少重复的链路信息，帮助用户将关注重点放在更有价值的数据上，同时降低 APM 的使用成本。

采样方案的选择

采样的本质，就是从大量数据中选择一部分数据进行观察和分析，以理解系统整体的行为或特性。体现在 APM 系统中，采样针对的是链路数据，这代表没有被选择到的链路数据可以不被采集，或者采集后直接被丢弃。具体哪一些链路数据被选择，在不同的采样方案中，会存在比较大的差异。

根据 APM 系统的特点，采样策略的引入，需要考虑到如下几个重要的需求：

链路完整性：一条完整的链路（Trace）包含多个跟踪单元（Span），如果采样导致一条链路中的部分 Span 被丢弃，链路的完整性就会被打破，整条链路数据都会失去价值。

指标正确性：各种统计指标不要因为采样策略的引入而出现偏差，包括吞吐量、响应时间、错误率、应用健康状态等等。

保留高价值数据：在真实的分布式系统中，存在一些关注度非常高的链路，需要采样策略能够选择性的保留这些数据。

其中最典型的例子就是错误调用和慢调用，当一条链路中存在错慢调用的时候，不能被采样策略丢弃。

结合这几项重要的需求，再基于数据的选择和采样时机，APM 领域诞生了 2 种典型的采样方案：头部采样和尾部采样。

头部采样(Head Based Sampling)

顾名思义，头部采样在请求进入分布式系统的入口处进行采样决策，随着请求在不同应用之间的流转，采样决策会一直保持传播，从而保证每一个环节都遵循相同的行为。在入口处，一旦决定对某个请求进行采样，整条链路都可以完整的保留下来。

头部采样的实现比较简单，通用的链路传播协议，例如在 OpenTelemetry 生态中广泛使用的 W3C 链路上下文标准，都对头部采样方案提供了支持。

只需要基于链路传播协议，在 APM 提供给应用接入的探针或 SDK 中进行简单的处理，就能实现头部采样。但头部采样可能会导致某些重要事件或异常的遗漏，因为采样决策是在入口时就已经确定的，无法根据请求在后续环节中的实际情况进行调整。

例如，当用户请求进入分布式系统后，基于预设的采样规则，做出的决策是丢弃此条链路，但在接下来的环节中，此链路上出现了一个数据库慢调用，SQL 执行的时长超过了 3 秒。这本应该是一个值得重点分析的重要事件，却因为采样策略的引入，导致关键数据都被丢弃了。

此外，在 APM 系统中，链路数据和统计指标之间是存在相互关系的，例如统计某一个接口的响应耗时 99 分位数，往往依赖于 APM 服务端基于收到的 Span 信息进行计算分析。头部采样会导致指标数据跟真实情况发生非常大的偏离。

尾部采样(Tail Based Sampling)

尾部采样是指在请求完成后再进行采样决策。一般由 APM 的服务端来实现。APM 服务端会先临时收集所有链路数据，然后在请求完成后根据实际情况（如请求的响应时间、错误状态等）决定保留哪一些链路。

尾部采样能够更好地捕获重要事件和异常，确保错慢调用所在的链路都可以完整保留，同时也能够确保统计指标的准确性。

但尾部采样需要 APM 系统在服务端引入额外的存储和计算资源，来临时保存每个环节的链路数据，实现比较复杂。在常见的开源 APM 项目中，对于尾部采样的实现，都没有提供完整的完整的方案。

方案对比

站在 APM 使用者的角度，尾部采样无疑是更好的方案，对于分析应用性能和排查问题能够提供更好的帮助。错慢请求是 APM 使用者需要特别关注的对象，当错慢请求不是频繁大量产生的时候，头部采样方案会有很大概率导致关键信息的丢失。

尾部采样的技术复杂度

虽然尾部采样是对于 APM 使用者是更好的方案，但在众多开源以及商业化 APM 工具中，被广泛使用的却是头部采样方案。

造成这个现象的关键原因是尾部采样引入了更高的技术复杂度，也对 APM 服务端带来了更大的稳定性挑战。

回顾采样的基本原理，头部采样在链路入口做出采样决策的时候，并不需要考虑该链路后续可能发生的情况，因此可以非常简单的引入一套采样算法，任何满足统计学要求的算法都是可行的，比如基于百分比的随机算法，或者参考请求特征的哈希算法。

而尾部采样在 APM 服务端做决策的时候，需要整体考虑一条链路中每个环节的特点，因此需要预先将整条链路的数据都缓存起来，以保证决策的正确性。

以下面这条典型的链路为例，其中存在一个响应时间达到 8 秒的慢调用，基于尾部采样的目标，这一条链路需要被完整保存。但在链路的其它环节，调用的响应时间都是非常快的，其中有一部分的 Span 信息会在 8 秒的慢调用完成前就上报到 APM 服务端，当 APM 服务端收到这部分数据的时候，并不能立即做出决策，而是需要将数据整体缓存一段时间，直到这条链路的所有参与者都成功上报了 Span 信息，才能进行判断。

实际上，链路的所有参与者都只会基于自身的数据完整性上报 Span 数据，并不会考虑其他环节的发生的事情，这导致 APM 服务端在任何时间点都无法 100% 确认一条链路已经结束了。

换种角度来理解：因为慢调用的存在，APM 服务端永远都无法预知一条链路上是否还存在未上报的 Span。理论上，APM 服务缓存数据的时间越长，判断就更加精准，但同样也加剧了 APM 服务端的资源开销，需要结合实际业务场景权衡考虑。

关于尾部采样算法的实现方式，我们可以参考 OpenTelemetry 社区 Collector 组件的代码，Collector 引入了 Tail Sampling Processor 来实现尾部采样。

首先，系统会根据 Trace ID 对 Span 数据进行哈希路由，确保同一条链路的 Span 数据都能被路由到同一个 Collector 实例中。每个 Collector 实例维护一个固定大小的滑动时间窗口，根据 Trace ID 聚合 Span 数据，等滑动时间窗口结束之后，再去匹配采样算法，决定整条链路的保存或丢弃。

但这套机制的实现明显是不完整的，滑动窗口越大，对于链路完整性的处理会更精准，但同时也会导致更大的数据查询延迟。在 APM 工具的实际使用过程中，有一个很明显的体现：一条链路明明已经结束很久了，但使用者就是迟迟查不到数据，这在生产级 APM 工具中是无法被接受的。

此外，为了缓解 APM 服务端的性能压力，部分商业化 APM 系统将尾部采样的实现机制交给了更靠近端侧（也就是接入 APM 的应用）的采集器。

在实际应用场景中，往往是每个 Kubernetes 集群中，或者每个 VPC 中部署一个 Agent 或采集器。这种做法本质是将尾部采样的性能开销从 APM 提供商转嫁到了用户侧，对于采集器的资源要求很高。

而且，随着云计算的发展，跨 Kubernetes 集群，跨 VPC，甚至跨云的分布式调用，都是极为普遍的。只要一条链路跨越了多个采集器，这样的尾部采样方案就会导致断链。

从技术复杂度来分析，也就明白为什么 APM 领域被广泛使用的依然是不那么优秀的头部采样方案了。

腾讯云 APM 的尾部采样实现

腾讯云应用性能监控（Application Performance Management ，APM）属于腾讯云可观测平台（Tencent Cloud Observability Platform，TCOP）的子产品，支持多种主流编程语言以及开源框架，为用户提供业界领先的全栈式应用可观测解决方案。

使用方式

采样策略是腾讯云 APM 在 2024 年 9 月推出的全新功能，目前还没有全面开放，您可以通过提交工单进行申请。申请完成后，就能在 APM 控制台的应用性能监控 > 系统配置中找到采样配置页面。

接下来，可以针对特定的业务系统调整全局采样配置。全局采样配置对一个业务系统内的所有应用生效，包括如下几项配置：

1. 采样率：采样率代表需要保留的链路百分比，通过随机算法实现，默认是 100%(也就是全部保留)。采样率越低，使用成本越低。

   
   

2. 保存错误链路：如果链路上存在错误的 Span，整条链路都会被完整保存。这是尾部采样的关键能力之一，建议打开，避免对错误链路的遗漏。

   
   

3. 慢调用保存阈值：如果链路上存在慢调用，整条链路都会被完整保存。对于大多数分布式系统，可以将此阈值设置到 500 毫秒到 2 秒之间。

完成全局采样配置后，您还可以根据实际业务需求配置需要全部采样的接口。如果一条链路中，存在被匹配到的接口，将绕过全局采样配置，完整保留整条链路。在每一条全采样策略中，您可以指定特定的应用，也可以通过精确匹配、前缀匹配、后缀匹配的方式指定具体的接口。

采样配置提交后会立即生效，您可以前往 APM 控制台的链路追踪页面体验采样配置对于链路数据的影响，或前往 APM 控制台的资源管理 - 用量分析页面评估采样配置对于降低 APM 使用成本起到的效果。

值得注意的是，在按量付费模式下，应用性能监控（APM）的计费项包括上报费用和链路存储费用。采样配置可以降低链路存储费用，最高达到 90%，但并不能降低上报费用。这也是符合尾部采样基本原则的：通过全量上报数据，确保指标的正确性以及错慢链路完整保存。

合理的配置采样策略

采样配置旨在确保在有效管理应用性能的基本上，优化使用成本，所以我们不能够本末倒置，为了优化使用成本而降低对应用性能管理的要求。

需要特别注意的是，尽管尾部采样能够尽可能的保留重要的链路数据，但并不是 100% 无损的，在特定的场景下可能导致关键信息的丢失。

同样的采样率设置下，数据样本越少，关键信息丢失的概念就越高。

举一个例子，某个接口只会在整点的时候收到 10 次 调用，在采样率为 20% 的情况下，存在 10 次 调用都不被命中的可能性，这样就无法得知接口所在的链路经过了哪一些服务。

基于应用性能管理的基本原则 ，以及腾讯云 APM 采样方案的特点，遵循常用的采样配置最佳实践，可以帮助我们在节省 APM 使用成本的同时，更好的挖掘 APM 的价值。

采样配置最佳实践

1. 合理的规划业务系统。腾讯云 APM 通过业务系统分类管理您的应用，每个业务系统之间的数据都是隔离的，可以拥有完全独立的采样率配置。如果两组应用之间没有相互调用的可能性，建议将它们分别接入不同的业务系统。一个典型的例子是，将测试环境和生产环境分别使用独立的业务系统进行管理。

   
   

2. 100% 的全局采样率是一个比较好的开端。在接入应用后，100% 采样率有助于我们更全面的了解分布式系统的整体情况，同时也有助于更好地掌握 APM 工具的使用。

   
   

3. 渐进式的降低全局采样率。结合对于费用成本上以及数据完整度的要求，逐步降低全局采样率，每次调整都投入充足的时间进行验证，不要一步到位。

   
   

4. 合理设置全采样接口。对于关键的应用和关键的接口，往往需要保留所有链路数据，可以将它们纳入到全采样策略中。

   
   

5. 必要时候临时提升全局采样率。在排查线上问题的时候，可以根据实际需要将全局采样率临时提升到 100%，以提升解决问题的效率，问题解决后再恢复之前设置全局采样率。用户在 APM 控制台修改采样配置后，可以立即生效，因此可以根据实际业务需求进行灵活调整。

   
   

可以同时使用尾部采样和头部采样吗？

理论上是可以的，但如果您使用腾讯云 APM，强烈不建议这样做。

同时使用尾部采样和头部采样，不但会对最终的采样率产生叠加效果，还会严重影响指标数据的准确度。当接口吞吐量、错误数、应用健康状态等统计数据完全不具备可参考性的时候，APM 工具对于应用性能管理的指导性将大打折扣。为了更好的发挥 APM 的重要价值，请确保不要在应用中引入头部采样设置。

降低采样率能降低探针的性能开销吗？

对于尾部采样方案而言，答案是否定的，因为采样的决策是发生在 APM 服务端，对探针的性能开销没有任何影响。实际上，即便是在开源领域广泛使用的头部采样方案，降低采样率对于探针性能开销的影响也是很微弱的，完全可以忽略。

总结与展望

采样技术是降低 APM 使用成本的终极武器。腾讯云 APM 提供的尾部采样方案不仅能有效帮助用户降低 APM 使用成本，还能最大限度地减少了传统采样方案造成的负面影响。

持续帮助用户降低成本，是腾讯云可观测平台的重要课题。接下来，腾讯云可观测平台将继续优化尾部采样方案，提供更精细化的配置选项。除此之外，下个月腾讯可观测平台还将重磅推出永久免费的轻量级 APM 产品形态，敬请期待。

联系我们

如有任何疑问，欢迎加入官方技术交流群

关于腾讯云可观测平台

腾讯云可观测平台（Tencent Cloud Observability Platform，TCOP）基于指标、链路、日志、事件的全类型监控数据，结合强大的可视化和告警能力，为您提供一体化监控解决方案。满足您全链路、端到端的统一监控诉求，提高运维排障效率，为业务的健康和稳定保驾护航。功能模块有：

• Prometheus 监控：开箱即用的 Prometheus 托管服务；

• 应用性能监控 APM：支持无侵入式探针，零配置获得开箱即用的应用观测能力；

• 云拨测 CAT：利用分布于全球的监测网络，提供模拟终端用户体验的拨测服务；

• 前端性能监控 RUM：Web、小程序等大前端领域的页面质量和性能监测；

• Grafana 可视化服务：提供免运维、免搭建的 Grafana 托管服务；

• 云压测 PTS：模拟海量用户的真实业务场景，全方位验证系统可用性和稳定性；

• ......等等