正在加载

基于尾部的采样

Elastic Stack

注意

supported deployment methods

当写入 Elasticsearch 时，此页面上的大多数选项都受所有 APM Server 部署方法支持。如果您使用不同的输出，则不支持基于尾部的采样。

注意

使用基于尾部的采样需要更高的权限。 有关更多信息，请参阅创建基于尾部采样的角色。

基于尾部的采样配置选项。

示例配置文件

apm-server:
  host: "localhost:8200"
  rum:
    enabled: true

output:
  elasticsearch:
    hosts: ElasticsearchAddress:9200

max_procs: 4

直接在 Kibana 中配置和自定义 Fleet 管理的 APM 设置

  1. 在 Kibana 中，在主菜单中找到 Fleet，或使用全局搜索字段。
  2. 在 Agent policies 选项卡下，选择您想要配置的策略。
  3. 找到 Elastic APM 集成，然后选择 Actions > Edit integration。
  4. 在 Tail-based sampling 下查找这些选项。

请参阅基于尾部的采样以了解更多信息。

设置为 true 以启用基于尾部的采样。 默认情况下禁用。 (bool)
APM Server 二进制文件 sampling.tail.enabled
Fleet 管理 启用基于尾部的采样

多个 APM Server 的同步间隔。 应为数十秒或数分钟。 默认值：1m（1 分钟）。 (duration)
APM Server 二进制文件 sampling.tail.interval
Fleet 管理 间隔

用于将根交易匹配到采样率的标准。

策略将跟踪事件映射到采样率。 每个策略必须指定一个采样率。 跟踪事件按指定的顺序与策略匹配。 所有策略条件必须为真，跟踪事件才能匹配。 每个策略列表应以仅指定采样率的策略结束。 此最终策略用于捕获不匹配更严格策略的剩余跟踪事件。 ([]policy)
APM Server 二进制文件 sampling.tail.policies
Fleet 管理 策略

为匹配尾部采样策略的跟踪事件分配的存储空间量。 注意：将此限制设置得高于允许的空间可能会导致 APM Server 变得不健康。

值 0GB（或等效值）不设置具体限制，而是允许 APM Server 将其磁盘使用量与磁盘大小对齐。 APM Server 使用本地基于尾部的采样数据库所在的磁盘上高达 80% 的磁盘大小限制。 磁盘的最后 20% 将不会被 APM Server 使用。 建议使用该值，因为它会自动随磁盘大小缩放。

如果不需要这样，则可以为基于尾部的采样设置具体的 GB 值作为最大磁盘使用量。

如果配置的存储限制不足，它会记录“已达到配置的限制”。 当达到存储限制时，事件将绕过采样，并且始终会被索引。

默认值：0GB。 (text)
APM Server 二进制文件 sampling.tail.storage_limit
Fleet 管理 存储限制

请参阅基于尾部的采样以了解更多信息。

应用于匹配此策略的跟踪事件的采样率。 每个策略中都需要。

采样率必须大于或等于 0 且小于或等于 1。 例如，sample_rate 为 0.01 意味着将对匹配该策略的 1% 的跟踪事件进行采样。 sample_rate 为 1 意味着将对匹配该策略的 100% 的跟踪事件进行采样。 (int)

事件的跟踪名称，用于匹配策略。 当配置的 trace.name 与跟踪的根交易的 transaction.name 匹配时，会发生匹配。 根交易是任何没有 parent.id 的交易。 (string)

事件的跟踪结果，用于匹配策略。 当配置的 trace.outcome 与跟踪的 event.outcome 字段匹配时，会发生匹配。 跟踪结果可以是 success、failure 或 unknown。 (string)

事件的服务名称，用于匹配策略。 (string)

事件的服务环境，用于匹配策略。 (string)

APM Server 生成指标来监控性能并估计基于尾部的采样正在处理的工作负载。 为了使用这些指标，您需要启用 APM Server 的监控。 以下指标由基于尾部的采样器生成（请注意，这些指标可能具有不同的前缀，例如 ECH 部署的 beat.stats，具体取决于 APM Server 的运行方式）

此指标跟踪基于尾部的采样器正在跟踪的每个策略的动态服务数量。 为没有定义 service.name 的基于尾部的采样策略创建动态服务。

这是一个计数器指标，因此应使用 counter_rate 可视化。

此指标跟踪基于尾部的采样器处理的事件总数（包括事务和 span）。

这是一个计数器指标，因此应使用 counter_rate 可视化。

此指标跟踪基于尾部的采样器在数据库中存储的事件总数。 当完整跟踪尚未可用于做出采样决策时，将存储事件。 此值与基于尾部的采样器运行所需的存储空间成正比。

这是一个计数器指标，因此应使用 counter_rate 可视化。

此指标跟踪基于尾部的采样器丢弃的事件总数。 只有实际被基于尾部的采样器丢弃的事件才会被报告为已丢弃。 此外，处理器存储但从未索引的任何事件都不会被此指标计算在内。

这是一个计数器指标，因此应使用 counter_rate 可视化。

此指标跟踪基于尾部的采样数据库使用的日志结构合并树的存储大小（以字节为单位）。 从版本 9.0.0 开始，此指标实际上等于数据库使用的总存储大小。 这是跟踪基于尾部的采样器的存储要求的最关键指标，尤其是在具有大型分布式跟踪的大型部署中。 广泛使用基于尾部的采样的部署应在此指标上设置警报和监控。

此指标还可用于在增加负载之前通过根据当前使用情况推断指标来估计基于尾部的采样器的存储需求。 重要的是要注意，在进行任何估计之前，应允许基于尾部的采样器至少运行几个 TTL 周期，并且该估计仅对相似的负载模式有用。

此指标跟踪基于尾部的采样器的先前实现使用的值日志文件的存储大小。 此指标已在 9.0.0 中弃用，并且应始终报告 0。

© . All rights reserved.