观测云链路数据分流与尾部采样最佳实践

文章介绍通过观测云 DataWay 分流网关 + DataKit 尾部采样，精准保留错误、慢请求等关键链路，并对正常链路按比例采样，在保障问题定位完整性的同时，有效降低 Trace 数据传输、带宽与存储成本。

产品技术专家翁一磊 2026-08-31 7 分钟阅读更新于 2026-08-31

在微服务架构日益复杂的今天，分布式链路追踪（APM）已成为保障系统稳定性不可或缺的利器。然而，随着业务规模的爆发式增长，海量的 Trace 数据给系统的存储成本和带宽带来了极大的挑战。如何在不丢失异常/高延迟链路的前提下，最大化降低全量链路的存储开销？

本文将为您带来观测云的破局之道——分流网关+ 尾部采样的最佳实践。

1. 观测云：全栈可观测性与核心 APM 能力

观测云是一个统一实时监测平台，它提供全面的系统可观测性解决方案，帮助用户快速实现对云平台、云原生、应用及业务的监控需求。观测云的核心功能包括：基础设施监测，日志采集和分析，用户访问监测（RUM），应用性能监测（APM），服务可用性监测（拨测），安全检测（SIEM）等等，帮助工程师全面了解端到端的用户体验追踪，了解应用服务的每一次调用，以及全面监控云时代的基础设施。

在 APM（应用性能监测）领域，观测云展现出了强大的技术生态与监测能力：

多协议兼容：原生支持 DDTrace、OpenTelemetry、SkyWalking、Jaeger 和 Zipkin 等主流开源 APM 追踪框架，企业无需修改现有业务代码，即可无缝接入。
全链路拓扑：自动生成清晰的微服务依赖拓扑图，精准计算服务的请求数、错误率以及平均响应时间（RED 指标）。
上下游联动：无缝打通 Trace 与其关联的日志以及用户访问监测（RUM），实现从一次前端点击、到后端代码报错、再到底层数据库慢查询的一键全链路下钻分析。

2. 尾部采样的必要性

在链路采集场景中，采样策略通常分为头部采样（Head-based Sampling）和尾部采样（Tail-based Sampling）。两者的核心区别主要在于：

特性	头部采样 (Head-based)	尾部采样 (Tail-based)
采样决定时机	在链路发起端（如 Gateway 或首个服务）刚启动、Span 未完全生成时，直接通过算法（如随机、固定比例）做出采样决定。	在整条 Trace 的所有相关 Span 全部执行完毕、链路完整拼接之后，再根据策略做出过滤决定。
优缺点	优点：计算和内存开销极低。缺点：由于决策发生在链路执行前，算法无法预知请求的最终状态，因此可能导致正常状态的高频链路占据了绝大部分的存储配额。	优点：精准过滤。能做到“只为有价值的数据买单”，100% 保留异常、错误及慢响应，大幅过滤无意义的正常链路。缺点：需要消耗一定的计算和内存资源。

随着生产环境流量达到万级、甚至十万级 QPS，采用 100% 全量采集会导致高昂的流量和存储成本，而单纯依赖头部随机采样又无异于“盲人摸象”，导致需要分析的错误、慢响应等数据采集不全。因此，尾部采样能够在保证核心价值数据完整性的同时，大幅度减少数据传输流量、以及存储成本，是高并发架构下的一种优化选择。

3. 观测云尾部采样 + 分流最佳实践

3.1 部署架构

在观测云的大规模落地场景中，我们推荐采用“DataKit（本地收集/预处理） + DataWay（分流与聚合网关）”的联合部署架构。

该方案在保证尾部采样准确性的同时，具备以下优势：

本地聚合与流量节省：DataWay 具备强大的本地数据聚合能力，可在边缘侧完成链路清洗与压缩，大幅降低跨公网的数据传输（即将本地链路数据上报到观测云的 SaaS 平台）流量与带宽成本。
灵活的多业务场景分流：支持基于业务线、集群环境（如开发/生产）或多租户进行流量精细化路由，完美满足企业对数据隔离与费用分摊的管理需求。
后续弹性扩展：由于尾部采样需要占用 DataWay 一定的计算和内存资源，该方案支持 DataWay 计算节点随后期数据量增长进行无缝的弹性扩容。

架构示意图：

3.2 主要部署和配置步骤

3.2.1 部署独立数据网关 DataWay

如上述架构所示，对于观测云 SaaS 用户而言，可以在自己本地（例如 Kubernetes 集群中）部署一个 DataWay，专用于分流+尾部采样数据的聚合，然后再将数据转发给 SaaS 平台的 DataWay。

主要安装和部署步骤：

1、在 Kubernetes 集群中部署 etcd，主要用于存储分流规则

2、部署 DataWay，具体可以参考观测云在线文档：https://docs.guance.com/deployment/dataway/#__tabbed_1_2

【注意】：DataWay 需要使用 1.17.0 版本或以上：https://docs.guance.com/deployment/dataway-changelog/#cl-1.17.0

其中，需要调整的主要配置如下：

- name: DW_REMOTE_HOST # 需要连接的观测云 SaaS 平台网关地址，不同站点的具体地址可以访问观测云控制台的【集成】->【DataKit】菜单
  value: "https://openway.guance.com"
- name: DW_CASCADED # 开启网关级联模式，即数据上报到观测云的 SaaS 平台 DataWay
  value: "true"
- name: DW_AGGREGATOR_MODE # 开启尾部采样数据聚合模式，由该 DataWay 完成数据聚合
  value: "standalone"
- name: DW_BIND
  value: "0.0.0.0:9528"
- name: DW_UUID
  value: "agnt_sinker00000000000000000001"
- name: DW_TOKEN # 注意 tkn_ 后面需添加32位字符串
  value: "tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 
- name: DW_SECRET_TOKEN # 注意 tkn_ 后面需添加32位字符串；可以留空，datakit.conf 配置真实 token；若不留空，datakit.conf 中需要配置对应一致的 token
  value: "tkn_sinker1234567891234567891234demo"
- name: DW_SINKER_ETCD_URLS # 修改为实际的 etcd 访问地址
  value: "<your_etcd_url>"
- name: DW_SINKER_ETCD_KEY_SPACE
  value: "/dw_sinker"
- name: DW_SINKER_ETCD_USERNAME
  value: "dataway"                    
- name: DW_SINKER_ETCD_PASSWORD
  value: $your_etcd_passwd
- name: DW_PROM_LISTEN
  value: "0.0.0.0:9090"
- name: DW_LOG
  value: stdout
- name: DW_LOG_LEVEL
  value: info
- name: DW_GIN_LOG
  value: stdout
- name: DW_DISKCACHE_DIR # 设置缓存目录，该目录一般外挂存储
  value: /dataway-cache
- name: DW_DISKCACHE_CAPACITY_MB # 设置可用的磁盘空间大小，单位 MB，默认 20GB
  value: "10240"
- name: DW_HTTP_TIMEOUT
  value: "3s"
- name: DW_HTTP_CLIENT_TRACE
  value: "true"
- name: DW_MAX_HTTP_BODY_BYTES
  value: "67108864"

相关的环境变量配置，具体可以参考观测云在线文档：

3、配置分流规则，可以参考以下示例，以 namespace 做为分流标签，将不同 project 的数据发送到不同的工作空间。

【注意】将空间的 token 修改为实际真实的空间 token，以及 SaaS OpenWay 的具体地址需要根据实际接入的站点信息进行调整。详细信息，可以访问观测云控制台的【集成】->【DataKit】菜单

{
  "strict": true,
  "rules": [
    {
      "rules": [
        "{ namespace = 'projectA' }"
      ],
      "info": "projectA 的相关数据 -> 空间A",
      "url": "https://openway.guance.com?token=tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    },
    {
      "rules": [
        "{ namespace = 'projectB' }"
      ],
      "info": "tprojectB 的相关数据 -> 空间B",
      "url": "https://openway.guance.com?token=tkn_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
    },
    {
      "as_default": true,
      "info": "其他数据 -> 空间A",
      "url": "https://openway.guance.com?token=tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  ]
}

3.2.2 DataKit 分流+尾部采样配置

DataKit 侧配置，主要需要配置尾部采样，以及相关的分流标签配置。

【注意】：DataKit 需要使用 2.6.0 版本或以上：

https://docs.guance.com/datakit/changelog-2026/#cl-2.6.0

1、分流相关的配置，示例如下：

- name: ENV_DATAWAY # 根据实际情况调整；如果 DataWay 的 secret token 设置为空，此处可以配置真实 token
  value: "<your_dataway_url>?token=<your_dataway_secret_token>"
- name: ENV_DATAWAY_ENABLE_SINKER
  value: "true"
- name: ENV_SINKER_GLOBAL_CUSTOMER_KEYS # 指定 Sinker 分流的自定义字段列表，此处需要与 DataWay etcd 规则中使用的标签一致；各个 Key 之间以英文逗号分割
  value: "namespace,category"
- name: ENV_INPUT_CONTAINER_EXTRACT_K8S_LABEL_AS_TAGS_V2 # 追加资源的 labels 到数据（不包括指标数据）的 tag 中
  value: '["namespace"]'   
- name: ENV_INPUT_CONTAINER_EXTRACT_K8S_LABEL_AS_TAGS_V2_FOR_METRIC # 追加资源的 labels 到指标数据的 tag 中
  value: '["namespace"]'

2、尾部采样相关配置

环境变量配置：

- name: ENV_AGGREGATOR_USE_LOCAL_CONFIG
  value: "true"
- name: ENV_AGGREGATOR_LOCAL_CONFIG_DIR
  value: /usr/local/datakit/conf.d/aggr
- name: ENV_AGGREGATOR_LOCAL_TAIL_SAMPLING_CONFIG_FILE
  value: tail-sampling.toml

ConfigMap 配置：

apiVersion: v1
kind: ConfigMap
metadata:
  name: datakit-aggr-conf
  namespace: datakit
data:
  tail-sampling.toml: |
    version = 2

    [trace]
      data_ttl = "30s" # 网关在本地内存中缓存并等待同一个 trace_id 的所有相关链路数据的时长，时间越长所需内存越大，请根据实际情况调整
      group_key = "trace_id"

    [[trace.sampling_pipeline]]  # 错误链路全采
      name = "keep-error-trace"
      type = "condition"
      condition = '{ status = "error" }'
      action = "keep"

    [[trace.sampling_pipeline]]
      name = "keep-slow-trace"
      type = "condition"
      condition = '{ duration > 1000000 }' #超过 1s 的全采
      action = "keep"

    [[trace.sampling_pipeline]]
      name = "sample-rest"
      type = "probabilistic"
      condition = '{ 1 = 1 }'
      rate = 0.1 # 其他正常链路采样率 10%

3.3 注意事项

1、有关分流规则中，特殊 API 请求的配置说明：DataKit v2.0.0 及以后，只会在 point 写入类请求（/v1/write/*）上添加 Dataway Sinker header；其它从中心拉取资源、做身份识别或配置同步的 DataWay API 不再携带 X-Global-Tags/X-Global-Tags-V2，因此不需要再为这些 API 添加特殊分流规则。因此，在分流场景下，如果需要使用黑名单、端上 Pipeline 等功能，可以进行如下配置：

DataWay：DW_SECRET_TOKEN 环境变量留空
DataKit：token 配置真实的空间 token

具体信息可以参考观测云在线文档：https://docs.guance.com/deployment/dataway-sink/#special-sink-rule

2、由于尾部采样“先全量缓存、后状态判定”的运行机制，将整个链路的决策周期整体后置，因此会在一定程度上提升分流网关 DataWay 的 CPU 与内存资源开销。因此，需要根据相关的链路数据量，关注独立部署的 DataWay CPU 和内存使用情况。可在观测云的基础设施中进行查看，也可以配置监控告警。

3.4 实际效果

经过测试的流量数据可以看到，namespace 为 demoapp 的链路数据接入到了 A 空间，即图中的 Guance Demo，而另一个 namespace 的链路数据接入到了 B 空间。同时对于错误、耗时超过 1s 的链路进行了完整保留，而其他正常链路按照采样率进行了采样。

4. 总结

通过采用观测云分流网关 + DataKit 尾部采样的组合拳方案，企业能够在大规模分布式架构中建立起一套“高智能、低成本”的监测防线：

精准掌控：彻底告别随机采样的不确定性，确保 100% 捕获系统内的每一次黄金报错与性能瓶颈。
卓越降本：过滤掉冗余的正常高频链路，最大化压榨存储空间的性价比。
高可扩展：本地部署 Dataway 支持随着业务增长进行无缝的横向弹性扩容。

将对的资源用在最有价值的数据上，这就是观测云为您带来的最佳技术实践。

获取专属方案

联系我们

加入社区

微信扫码
加入官方交流群

立即体验

在线开通，按量计费，真正的云服务！

立即开始

选择观测云版本

免费版商业版企业版

代码托管平台

GitHub Gitee