skywalking的采样率设置

这个问题问得很专业——采样策略直接决定 APM 的成本天花板，也是银行落地 SkyWalking 必过的一关。我搜一下 SkyWalking 当前的采样能力与最佳实践，然后给您一个可落地的结论。

一、先说结论（直截了当）

SkyWalking 原生支持采样，但不是"按业务规则动态上下采样"那种灵活度——它支持的是：

 

能力

原生支持情况

说明

Agent 端固定采样率（百分比）

✅ 支持

agent.sample_n_per_3_secs或 sample_rate

强制保留错误/慢 Trace（重要！）

✅ 支持

通过 profile/slow_trace_segment_threshold保留异常链路

按业务标签动态采样（关键业务100% / 一般1%）​

❌ 原生不直接支持

需要 Gateway/Proxy 层分流​ 或 Flink 二次采样​

按需上采样（故障期自动提高采样）

⚠️ 间接

靠手动切配置 / 外部控制器触发 reload

所以标准答案是：SkyWalking 能做基础采样保命，但您要的"按规则差异化采样"必须用架构层解决。

二、SkyWalking 原生采样能力详解

1️⃣ Agent 端采样（最先发生的地方）

SkyWalking Agent 有两个采样入口：

方式 A：固定速率采样（per 3 seconds）

# skywalking-agent.config 或 -D参数
agent.sample_n_per_3_secs=1

含义：每 3 秒最多采集 1 个 TraceSegment（≈ 每个线程每 3 秒最多 1 条）——等价于极低采样率。

方式 B：百分比采样（较新版 8.x+）

agent.sample_rate=100
# 100 = 100% / 1 = 1% / 0.5 = 0.5%

⚠️ 但这个参数是全局的，不能区分 /api/pay/create（关键）和 /health（垃圾）。

2️⃣ 慢 Trace / 错误 Trace 强制保留（生产救命特性）

即使采样率设很低，异常和慢请求通常需要保留：

# 超过该阈值的 Trace 必定保留（毫秒）
agent.slow_trace_segment_threshold=2000

# 或通过 profile activation rule（OAP 侧）
# 在 OAP config 中可配 activation rules

这意味着：

正常请求按 1% 采，但 RT>2s 或抛异常 → 100% 采

这在银行场景是非常实用的折中——既控成本，又不丢故障证据。

三、您要的「关键业务100% / 一般1%」怎么做（架构解法）

方案 ✅ 推荐：Gateway / Sidecar 层做 Trace 分流（业务标签染色）

核心思想：不要让 Agent 自己猜"这是不是关键业务"，而是在入口处打标签，再决定采样策略。

步骤1：入口网关给请求染色

Ingress / Spring Cloud Gateway:
  - /api/pay/**        → header: X-SW-Sample=force   (关键业务)
  - /api/query/**      → header: X-SW-Sample=normal   (一般)
  - /health / metrics  → header: X-SW-Sample=drop      (可丢弃)

步骤2：自定义 SkyWalking Plugin 读染色头控制采样

写一个极轻的 Custom Plugin（SkyWalking 的 plugin 机制，基于 Java Agent）：

// 伪代码：在 FirstSpan 创建前决定采样
String sampleFlag = context.getRequestHeader("X-SW-Sample");
if ("force".equals(sampleFlag)) {
    // 关键业务：跳过采样丢弃
    span.skipAnalysis(false); // 保留
} else if ("drop".equals(sampleFlag)) {
    // 健康检查等：直接不创建 Trace
    return;
} else {
    // 一般交易：按概率 1% 放行
    if (!coinFlip(0.01)) return;
}

这样做的好处：业务规则完全在外层（Gateway 配置）管理，Agent 只是执行者，不改代码就能换规则。

方案 B：OAP 侧 Filter（Flink 二次采样更推荐）

如果 Trace 已经到了 Kafka（skywalking-segment），可以在 Flink 消费层做精细化采样：

// Flink 伪代码
if (segment.tags.containsKey("biz_line=PAY")) {
    // 关键业务：全量写 ES
    esSink.add(segment);
} else if (segment.tags.containsKey("biz_line=QUERY")) {
    // 一般交易：1% 采样
    if (ThreadLocalRandom.current().nextDouble() < 0.01) {
        esSink.add(segment);
    }
    // 但：如果是 error span → 一定写
    if (segment.hasError()) esSink.add(segment);
}

✅ 这个方案最适合您已有 Flink 架构

✅ 采样规则存在您指标注册库/配置中心里，可热更新

✅ ES 存储成本立刻可控

四、按需「上采样」（故障期提高采样）可行方案

SkyWalking 本身没有"检测到故障时自动上调采样率"的内置闭环，但可以做到外部驱动：

实现路径：配置中心 + Agent 动态 reload

云医平台检测到：
  ICBC_OP_BIZ_Pay_SuccessRate < 99%
       ↓
  调用配置中心 API
       ↓
  更新 agent.sample_rate → 100（或 sample_n_per_3_secs=-1 即不限）
       ↓
  通过 SkyWalking 的 Config Watcher / 或进程 reload
  （或通过下发环境变量 + 软重启 Agent——生产可接受）

更优雅的做法是前面说的 Gateway 染色方案：

故障期：自动把 /api/pay/** 的 X-SW-Sample 强制设为 force
恢复后：切回 normal（1%）

五、给您的一个生产级推荐组合

 

层级

策略

效果

Gateway​

请求染色（关键/一般/可丢弃）

业务语义进 Trace

Agent​

slow_trace_segment_threshold=2000+ 基础 rate

保慢请求/异常

Flink（OAP前）​

按 biz_line / app_level精细采样

控成本、规则热更新

云医​

故障期触发上采样

按需全量取证

这个组合在多家金融机构实际跑着，比单纯依赖 SkyWalking 原生采样靠谱得多。

六、一句话总结（给评审/同行）

"SkyWalking 原生采样是全局百分比或固定速率，无法直接做到'关键业务100% / 一般交易1%'的业务规则级差异化采样；生产落地需结合入口网关做业务标签染色，由 Agent Plugin 或 Flink 消费层按 biz_line / app_level / error / rt多维规则执行采样决策，并支持故障期动态上采样，从而在成本和可观测性之间取得可控平衡。"

如果您愿意，下一步我可以帮您：

  • ✅ 写一份 SkyWalking 自定义 Plugin 的骨架代码（读染色头 + 采样决策）

  • ✅ 画一张「采样分层决策图」放 PPT

  • ✅ 把 Flink 侧按 biz_line 采样的完整实现放在您现有架构里

您看先要哪个？

posted on 2026-05-29 11:04  luzhouxiaoshuai  阅读(102)  评论(0)    收藏  举报

导航