Elastic APM：在全量和采样中寻找平衡

前言：Skywalking与Elasticsearch

最近在研究APM，在国内用户中，我们很欣喜的看到有Skywalking这样的Apache顶级项目被广泛的使用。并且，Elasticsearch作为一个兼具高吞吐，海量数据存储，高效多维过滤，快速搜索的搜索引擎，也是最常被用作为Skywalking的底层存储引擎的。Elastic APM作为一个后起之秀，有这样的一个榜样珠玉在前，并且双方在开源生态上互相支持，也是我们非常乐于看到的。

SkyWalking诞生于2015年，当时的设计思路就已经是为超大规模而生，在生产环境下，SkyWalking能够为大型分布式系统提供100%采样率的跟踪能力。

但随着我们的用户越来越多，系统的吞吐越来越庞大，很多时候，吞吐会成为我们瓶颈。而使用Elasticsearch作为Skywalking的同学，可以考虑以下的优化：

调优索引速度：

• 刷新间隔
• 禁用交换
• 优化文件系统缓存
• 关于更快硬件的注意事项
• 设置索引缓冲区大小

调整磁盘使用情况：

• 禁用不需要的功能
• 分片大小
• 收缩指数

当然，本文不是为了讨论如何为Skywalking下的Elasticsearch进行调优。而是讨论Elastic APM，是如何在全量采样和按需采样下寻找平衡的。

交易采样

分布式追踪可以产生大量的数据。更多的数据可能意味着更高的成本和更多的噪音。采样的目的是降低摄取的数据量和分析这些数据所需的努力--同时仍然可以很容易地发现你的应用程序中的异常模式，检测故障，跟踪错误，并降低MTTR。

Elastic APM 支持两种类型的采样：

• 基于头部的采样
• 基于尾部的抽样

基于头部的取样

在基于头部的取样中，每条追踪的取样决定是在追踪开始时做出的。每一个追踪都有一个确定的、平等的被抽样的概率。

例如，采样值为0.2表示交易采样率为20%。这意味着只有20%的追踪会发送并保留其所有相关信息。剩下的痕迹将放弃上下文信息，以减少痕迹的传输和存储大小。

基于头部的采样是快速和容易设置的。它的缺点是它是完全随机的--有趣的数据可能纯粹是由于机会而被丢弃。

使用基于头部的采样进行分布式跟踪

在分布式跟踪中，采样决定仍然是在跟踪开始时做出的。每个后续服务都尊重初始服务的采样决定，无论其配置的采样率如何；其结果是采样百分比与起始服务相匹配。

在此示例中，Service A（作为起始服务）启动了四个事务，并且采样率为.5( 50%)。Service B和的采样率Service C被忽略。

分布式跟踪和基于头部的采样示例一

在此示例中，Service A启动了四个事务，并且采样率为1( 100%)。Service B同样，和的采样率Service C被忽略。

分布式跟踪和基于头部的采样示例二

基于尾部的采样

在基于尾部的采样中，每个跟踪的采样决定是在跟踪完成后做出的。这意味着将根据一组规则或策略对所有跟踪进行分析，这些规则或策略将确定它们的采样率。

与基于头部的采样不同，每个跟踪（trace）被采样的概率不相等。因为较慢的跟踪比较快的跟踪更有趣，基于尾部的采样使用加权随机抽样——所以根事务持续时间较长的跟踪比根事务持续时间较短的跟踪更有可能被抽样。

基于尾部的采样的一个缺点是它会导致更多数据从 APM 代理发送到 APM 服务器。因此，与基于头部的采样相比，APM 服务器将使用更多的 CPU、内存和磁盘。但是，由于基于尾部的采样决策发生在 APM 服务器中，因此从 APM 服务器传输到 Elasticsearch 的数据较少。因此，在靠近你需要检测的服务的地方部署并运行 APM Server 可以减少基于尾部的采样带来的传输成本增加。

基于尾部采样的分布式跟踪

使用基于尾部的采样，所有跟踪都被观察到，并且只有在跟踪完成后才会做出采样决定。

在此示例中，Service A启动四个事务。如果我们将包含success结果的跟踪的采样率设为.5( 50%) ，而将包含failure结果的跟踪的采样率设为1( 100%) ，那么采样将如下所示：

分布式跟踪和基于尾部的采样示例一

采样数据和可视化

在Elastic APM中，被采样trace会保留与其关联的所有数据。而非采样trace则删除所有跨度和事务数据。无论采样决定如何，所有跟踪都会保留错误数据。

APM 应用程序中的一些可视化，如延迟，由聚合事务和跨度指标提供支持。指标基于采样的trace数据并按逆采样率加权。例如，如果您以 5% 进行采样，则每个trace都计为 20。因此，随着延迟方差的增加或采样率的降低，您的错误级别将会增加。

1真实用户监控 (RUM) 的trace是此规则的一个例外。利用 RUM 数据的 Kibana 应用程序依赖于事务事件，因此非抽样 RUM trace会保留事务数据——仅删除跨度数据。

采样率

最佳采样率是多少？这个问题没有唯一标准答案。抽样取决于您的数据、应用程序的吞吐量、数据保留策略和其他因素。从.1%到的采样率100%都被认为是正常的。您可能会为不同的场景决定一个独特的采样率。但需要注意：链路数据的价值分布是不均匀的。 据不完全统计，调用链的实际查询率小于百万分之一。全量存储数据不仅会造成巨大的成本浪费，也会显著影响整条数据链路的性能及稳定性。

这里有些例子，可以用于参考：

• 流量比其他服务多得多的服务可能可以安全地以较低的速率进行采样
• 比其他服务更重要的路由可能会以更高的速率进行采样
• 生产服务环境可能需要比开发环境更高的采样率
• 失败或者异常的trace可能比成功的trace更有趣——因此需要更高的采样率，甚至是全量采集

不管上述情况如何，注重成本的客户可能会接受较低的采样率。

冷热数据分离，低成本满足个性化的后聚合分析需求

冷热数据分离的价值基础在于用户的查询行为满足时间上的局部性原理。 简单理解就是，最近的数据最常被查询，冷数据查询概率较小。例如，由于问题诊断的时效性，50% 以上的链路查询分析发生在 30分钟内，7天之后的链路查询通常集中在错慢调用链。理论基础成立，接下来讨论如何实现冷热数据分离。

首先，热数据存在时效性，如果只需记录最近一段时间内的热数据，对于存储空间的要求就会下降很多。另外，在公有云环境下，不同用户的数据天然具备隔离性。因此，在用户 VPC 内部的热数据计算和存储方案就具备更优的性价比。

其次，冷数据的查询具备指向性，可以通过不同的采样策略筛选出满足诊断需求的冷数据进行持久化存储。例如错慢采样，特定业务场景采样等。由于冷数据存储周期较长，对稳定性要求较高，可以考虑在 Region 内统一管理。

综上所述，热数据存储周期短，成本低，但可以满足实时全量后聚合分析需求；而冷数据经过精准采样后数据总量大幅下降，通常只有原始数据量的 1% ~10%，并可以满足大多数场景的诊断诉求。两相结合，实现了成本与体验的平衡最优解。国内外领先的 APM 产品，如 ARMS、Datadog、Lightstep 均采用了冷热数据分离的存储方案。

结语

随着分布式应用系统所处理的业务流量越来越大，“成本”将是企业在使用APM进行性能监控时的关键衡量因素。而在云原生时代，充分利用边缘节点的计算和存储能力（基于尾部采样），结合冷热数据分离实现高性价比的数据价值探索已经逐渐成为 APM 领域的主流。全量数据上报、存储、再分析这种传统方案将面临越来越大的挑战。提供多种选择，能够让客户自己确定合适解决方案的需求，会越来越成为硬性的指标。