事务采样
编辑事务采样编辑
分布式追踪可能会生成大量数据。数据越多,意味着成本越高,噪音也越大。采样的目标是减少摄取的数据量和分析这些数据所需的工作量,同时仍然可以轻松地在应用程序中发现异常模式、检测中断、跟踪错误并缩短平均修复时间 (MTTR)。
Elastic APM 支持两种类型的采样
头部采样编辑
在头部采样中,每个追踪的采样决定是在追踪启动时做出的。每个追踪都有一个定义好的、相等的采样概率。
例如,采样值为 .2
表示事务采样率为 20%
。这意味着只有 20%
的追踪会发送并保留其所有相关信息。其余的追踪将丢弃上下文信息,以减少追踪的传输和存储大小。
头部采样设置起来快速简便。它的缺点是它是完全随机的,有趣的数据可能会因为纯粹的偶然性而被丢弃。
请参阅配置头部采样以开始使用。
使用头部采样进行分布式追踪
在分布式追踪中,采样决定仍然是在追踪启动时做出的。每个后续服务都会遵循初始服务的采样决定,而不管其配置的采样率如何;结果是采样百分比与初始服务相匹配。
在这个例子中,服务 A
启动了四个事务,采样率为 .5
(50%
)。服务 B
和 服务 C
的采样率将被忽略。
在这个例子中,服务 A
启动了四个事务,采样率为 1
(100%
)。同样,服务 B
和 服务 C
的采样率将被忽略。
使用头部采样的 OpenTelemetry
头部采样直接在 APM 代理和 SDK 中实现。采样率必须在服务和托管接收服务之间传播,以便生成准确的指标。
OpenTelemetry 提供了多个采样器。然而,大多数采样器不传播采样率。这会导致基于 Span 的指标不准确,例如 APM 吞吐量、延迟和错误指标。
为了在将头部采样与 OpenTelemetry 一起使用时获得准确的基于 Span 的指标,您必须使用[一致概率采样器](https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/)。这些采样器在服务和托管接收服务之间传播采样率,从而产生准确的指标。
OpenTelemetry 并非在所有语言中都提供一致概率采样器。OpenTelemetry 用户应考虑改用尾部采样。
+ 有关一致概率采样器可用性的更多信息,请参阅您最喜欢的 OpenTelemetry 代理或 SDK 的文档。
尾部采样编辑
在尾部采样中,每个追踪的采样决定是在追踪完成后做出的。这意味着所有追踪都将根据一组规则或策略进行分析,这些规则或策略将决定它们的采样率。
与头部采样不同,每个追踪的采样概率并不相等。因为较慢的追踪比较快的追踪更有趣,所以尾部采样使用加权随机采样,因此根事务持续时间较长的追踪比根事务持续时间较短的追踪更有可能被采样。
尾部采样的一个缺点是,它会导致从 APM 代理发送到 APM 服务器的数据更多。因此,与头部采样相比,APM 服务器将使用更多的 CPU、内存和磁盘。然而,由于尾部采样决定发生在 APM 服务器中,因此从 APM 服务器传输到 Elasticsearch 的数据更少。因此,在仪表化服务附近运行 APM 服务器可以减少尾部采样带来的任何传输成本增加。
请参阅配置尾部采样以开始使用。
使用尾部采样进行分布式追踪
使用尾部采样,所有追踪都会被观察,并且只有在追踪完成后才会做出采样决定。
在这个例子中,服务 A
启动了四个事务。如果我们对结果为 成功
的追踪的采样率为 .5
(50%
),对结果为 失败
的追踪的采样率为 1
(100%
),则采样的追踪将如下所示
使用尾部采样的 OpenTelemetry
尾部采样完全在 APM 服务器中实现,并且可以使用 Elastic APM 代理或 OpenTelemetry SDK 发送的追踪。
由于在使用 tailsamplingprocessor 时存在OpenTelemetry 尾部采样限制,我们建议改用 APM 服务器尾部采样。
采样数据和可视化编辑
采样的追踪会保留与其关联的所有数据。未采样的追踪会丢弃所有 Span 和 事务 数据1。无论采样决定如何,所有追踪都会保留 错误 数据。
APM 应用程序中的某些可视化(例如延迟)由聚合的事务和 Span 指标提供支持。指标基于采样的追踪,并按采样率的倒数加权。例如,如果您以 5% 的比例进行采样,则每个追踪都计为 20。因此,随着延迟方差的增加或采样率的降低,您的错误级别将会增加。
1 真实用户监控 (RUM) 追踪是此规则的例外。使用 RUM 数据的 Kibana 应用程序依赖于事务事件,因此未采样的 RUM 追踪会保留事务数据,只会丢弃 Span 数据。
采样率编辑
最佳采样率是多少?遗憾的是,没有一个最佳采样率。采样取决于您的数据、应用程序的吞吐量、数据保留策略和其他因素。从 .1%
到 100%
的采样率都被认为是正常的。您可能会针对不同的场景决定唯一的采样率。以下是一些示例
- 流量明显高于其他服务的,可以安全地以较低比率进行采样
- 比其他路由更重要的路由可以以更高的比率进行采样
- 生产服务环境可能需要比开发环境更高的采样率
- 失败的追踪结果可能比成功的追踪更有趣,因此需要更高的采样率
无论上述情况如何,注重成本的客户可能会对较低的采样率感到满意。