大模型服务的流量特征很极端平时闲、峰值猛一次对话的链路又长网关、鉴权、提示词组装、向量检索、推理、后处理单个 Segment 的 Span 数量可能是普通接口的几十倍。如果 100% 全量采集SkyWalking 的探针 CPU、网络带宽、OAP 计算力和后端存储都会被迅速吃满账单也会非常可观。采样Sampling就是在这个矛盾里找平衡用最小的代价保留足够的排障信息。本文讲清楚 SkyWalking 的采样机制与在大模型场景的落地策略。为什么必须采样开销与成本的真实来源SkyWalking 的采样机制全景实战探针与 OAP 双层采样配置大模型场景的采样策略设计存储与 TTL 成本优化1. 为什么必须采样开销与成本的真实来源一条链路从产生到可查询要经历四道成本关**探针开销**每个 Span 的创建、上下文维护、序列化都需要 CPU大模型链路 Span 多单请求探针耗时可能从微秒级升到毫秒级会直接抬升接口 P99。**网络开销**探针把 Segment 批量上报给 OAP全量上报在高并发下会打满网卡。**OAP 开销**OAP 要做拓扑聚合、指标计算、Trace 解析数据量线性放大。**存储开销**Trace 原始数据落在 Elasticsearch / BanyanDB / TiDB按数据量计费且需要磁盘容量与索引。以一个日活推理峰值 5000 QPS、平均每个对话 60 个 Span 的服务估算全量采集每天产生约 260 亿个 Span 的写入压力。即便按 10% 采样也能砍掉 90% 的存储与计算成本而排障所需的「慢调用」「错误调用」样本依然充足。因此采样的目标不是「少采」而是「聪明地采」保住有排障价值的样本错误、慢调用、特定模型丢弃无差异的海量正常样本。2. SkyWalking 的采样机制全景SkyWalking 的采样分布在两层**第一层探针端采样agent.sample_rate**。探针在创建 Segment 的第一个 Span 时按概率决定这条链路是否采集。一旦决定采样整条链路包括后续异步、跨进程的所有 Span都会被采集决定不采则整条丢弃。这是成本最低的一层因为它在源头就拦掉了数据。**第二层OAP 端采样receiver-trace**。即使探针全量上报OAP 在接收端仍可按 sampleRate 二次丢弃。这一层通常用于「探针全采、服务端按策略收口」的集中管控场景。除此之外还有三个「强制采样」开关保证关键样本不被采样率误杀force_sample_error_segment错误链路强制采样默认 true。slow_trace_segment_threshold超过该耗时的慢链路强制采样毫秒。错误与慢调用是排障的核心务必保持强制采样开启。采样率单位的坑探针端 agent.sample_rate 是 0~1 的小数1 表示 100%而 OAP 端 sampleRate 是以「万分之一」为单位的整数10000 表示 100%。两者容易混淆配置时要特别注意。3. 实战探针与 OAP 双层采样配置探针端配置写在 agent.config推荐用环境变量注入便于按环境区分agent.service_name${SW_AGENT_NAME:llm-inference}collector.backend_service${SW_AGENT_BACKEND:oap:11800}agent.sample_rate${SW_AGENT_SAMPLE_RATE:0.1} # 采样率日常 10%压测/灰度可调高agent.force_sample_error_segment${SW_FORCE_SAMPLE_ERROR:true} # 错误链路强制采集永远不要关启动命令通过环境变量覆盖做到「测试环境全采、生产环境抽样」java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \-DSW_AGENT_NAMEllm-inference \-DSW_AGENT_SAMPLE_RATE0.1 \-DSW_FORCE_SAMPLE_ERRORtrue \-jar inference-service.jarOAP 端在 application.yml 的 receiver-trace 中配置服务端采样与慢调用强制采样receiver-trace:default:# 服务端采样率单位 1/1000010000 100%sampleRate: ${SW_TRACE_SAMPLE_RATE:10000}# 错误段强制采样forceSampleErrorSegment: ${SW_FORCE_SAMPLE_ERROR:true}# 慢调用阈值毫秒超过则强制采样slowTraceSegmentThreshold: ${SW_SLOW_TRACE_THRESHOLD:2000}把 slowTraceSegmentThreshold 设成略高于你的大模型推理 P99例如推理普遍 1.5s可设 2000ms这样凡是「比正常慢」的调用都会被保留正好命中性能排查需求。4. 大模型场景的采样策略设计大模型链路不能简单「全局 10% 了事」需要分层设计**错误全采**force_sample_error_segmenttrue推理失败、超时、降级都进链路便于复盘。**慢调用全采**slowTraceSegmentThreshold 对齐业务 SLA慢推理必留样。**按端点区分**健康检查、心跳类接口价值极低可以单独调低甚至不采核心对话接口保留更高比例。基础版的 agent.sample_rate 是全局的要做到「按端点不同采样率」需要自定义采样插件或借助 OAP 服务端按 endpoint 过滤例如上游只把核心接口打到全采的探针分组。**按模型区分**把 modelName 作为关联上下文见第 06 篇对昂贵的大模型如 72B 推理提高采样率对轻量模型降低。**压测期临时全采**大促或压测前通过环境变量把 SW_AGENT_SAMPLE_RATE 调到 1拿到完整链路做容量评估结束再调回。不同采样率下的成本与覆盖率直觉对比如下表采样率存储/计算成本错误捕获慢调用捕获适用阶段---------------100%最高全量全量测试、压测、灰度初期50%中高全量(强制)全量(强制)上线观察期10%低全量(强制)全量(强制)稳定生产环境1%极低全量(强制)全量(强制)超大流量常态注意表中「错误/慢调用」一列始终全量正是因为强制采样开关的存在——这正是采样策略能「又省钱又不漏问题」的关键。5. 存储与 TTL 成本优化采样解决的是「写入量」而 TTL数据保留时长解决的是「存量规模」。即便采了 10%Trace 原始数据长期堆积仍会撑爆存储。SkyWalking 的存储 TTL 在 application.yml 的 storage 段配置storage:banyandb:# Trace 原始记录保留天数recordDataTTL: ${SW_RECORD_DATA_TTL:3}# 指标数据保留天数拓扑/监控图表用metricsDataTTL: ${SW_METRICS_DATA_TTL:15}优化建议**Trace 原始数据 TTL 短3~7 天**排障通常在发生后几天内完成过长保留收益低。**指标数据 TTL 长15~30 天**趋势图、容量规划需要长期数据且指标体积小。**存储选型**Elasticsearch 功能全但成本高BanyanDB 是 SkyWalking 原生时序存储针对 Trace 做了压缩成本显著更低大模型高吞吐场景首选。**索引策略**ES 下合理设置分片数与副本数避免为历史索引长期占用资源。不同存储的取舍如下表存储成本查询能力适用------------Elasticsearch高强全文检索已具备 ES 集群、需复杂查询BanyanDB低中原生优化 Trace新部署、成本敏感、高吞吐TiDB / MySQL中弱适合小流量小规模验证6. OAP 采样内部原理与限流理解采样在 OAP 内部怎么生效有助于避免误配。OAP 的 receiver-trace 模块在收到 Segment 后先判断是否命中采样未命中的 Segment 直接丢弃根本不会进入后续的拓扑聚合、指标计算与 Trace 存储流程。这意味着服务端采样不仅省存储还省 OAP 的 CPU 与内存——这是它和「只删存储」最大的区别。需要厘清一个常见误解**错误强制采样发生在探针端而不是 OAP 端**。当探针发现当前 Segment 包含错误 Span 或耗时超过 slow_trace_segment_threshold 时会无视 sample_rate 强制标记为「采样」并连带整条链路上报。因此即使你把 SW_AGENT_SAMPLE_RATE 设成 0.01错误与慢调用依然 100% 进入 OAP。如果你发现错误链路也没了第一反应应是检查 force_sample_error_segment 是否被误关或探针与 OAP 版本不匹配导致字段解析失败。此外OAP 还有一层自我保护当接收流量超过处理能力时会通过内部缓冲与丢弃策略限流避免被冲垮。这正是为什么生产环境更该在探针端就把采样率降下来——把压力挡在源头比让 OAP 在入口限流更优雅。7. 采样率选择的决策流程与成本估算采样率不是拍脑袋定的要基于流量与成本倒推。下面以一个典型大模型对话服务做估算假设平均每次对话产生 60 个 SpanQPS 为对话请求数峰值 QPS全量(100%)每日 Span 数10% 采样每日 Span 数1% 采样每日 Span 数------------1000约 52 亿约 5.2 亿约 5200 万3000约 155 亿约 15.5 亿约 1.55 亿5000约 260 亿约 26 亿约 2.6 亿每个 Span 在 Elasticsearch 里索引后约占几百字节到 1KB取决于 tag 数量与长度26 亿 Span 就是 TB 级写入与存储。按 10% 采样写入量与存储直接降到约十分之一且错误与慢调用因为强制采样仍然 100% 保留——排障所需样本完全够用。推荐的决策流程**灰度/上线观察期**sample_rate1100%拿到完整链路做容量评估与基线建立。**稳定生产期**降到 0.110%配合 force_sample_errortrue 与 slow_trace_segment_threshold 对齐 SLA。**超大流量常态**可降到 0.011%但必须监控错误/慢调用样本量是否足够定位。**压测/大促前**临时调回 1结束后调回。核心原则**正常流量可以少采异常流量必须全采**。采样率只砍「无差异的正常样本」不砍「有排障价值的异常样本」。8. 监控采样效果与防错采样配置一旦生效要持续监控它「有没有在正常工作」否则可能悄悄漏掉关键链路**监控采样后 Trace 数量**若某服务的 Trace 列表突然为空要么是 sample_rate 过低且恰好没有错误/慢调用要么是探针没挂上。需结合指标拓扑图 CPM判断——拓扑有流量但 Trace 为空就是采样或插桩异常。**监控错误样本完整性**定期检查错误链路是否仍 100% 出现。可以在测试环境主动制造一次错误请求确认它一定出现在 Trace 列表里。**告警联动**把「错误 Span 数突增但 Trace 样本为 0」作为独立告警项这比「接口变慢」更早暴露采样配置问题。**版本一致性**探针 apm-toolkit-trace 与 OAP 大版本必须一致。跨大版本升级 OAP 时先升级 OAP 再升级探针避免快照字段不兼容导致强制采样失效。9. 多环境采样配置管理采样率绝不能硬编码在 agent.config 里否则测试环境全采、生产环境也全采成本失控。正确做法是用环境变量或配置中心按环境注入做到「一套探针包多环境不同策略」。在 Kubernetes 里常见做法是用 ConfigMap 环境变量env: # deployment.yaml 片段- name: SW_AGENT_SAMPLE_RATEvalue: 0.1 # 生产环境默认值- name: SW_FORCE_SAMPLE_ERRORvalue: true当需要临时调高如大促前全量观察只需改这个环境变量并滚动重启无需重新打镜像。更进一步的做法是接配置中心如 Nacos / Apollo运行中动态下发采样率探针支持部分配置热更新真正做到「不重启调采样」。推荐的环境策略环境sample_rate说明---------本地开发1全量方便调试测试 / 预发1全量建立基线灰度上线0.5观察真实流量稳定生产0.1成本与覆盖平衡超大流量0.01仅保留异常样本10. 采样与可观测性权衡速查把「采多少」和「能看见什么」直接对应起来避免拍脑袋你的诉求采样策略还能看见什么---------我要完整复现每一次请求100%全部 Trace成本最高我要抓性能瓶颈但不想太贵10% 强制错误/慢正常样本抽样异常全留我只关心报错和大模型慢推理1% 强制错误/慢仅异常样本成本极低我要长期趋势图任意采样 长 TTL 指标拓扑/指标不受影响记住一个核心不等式**采样率只影响「正常样本的留存比例」不影响「错误与慢调用的留存」**。只要 force_sample_error_segment 和 slow_trace_segment_threshold 开着你最该关心的异常链路永远不会丢。这是采样能「又省又准」的根本原因。总结采样是「前端节流」TTL 与存储选型是「后端瘦身」。两者结合才能在高并发大模型场景下既把成本压下来又保证错误与慢调用万无一失。下一篇我们进入拓扑图看看怎么用全局视角定位瓶颈节点。
大模型服务的流量特征很极端平时闲、峰值猛一次对话的链路又长网关、鉴权、提示词组装、向量检索、推理、后处理单个 Segment 的 Span 数量可能是普通接口的几十倍。如果 100% 全量采集SkyWalking 的探针 CPU、网络带宽、OAP 计算力和后端存储都会被迅速吃满账单也会非常可观。采样Sampling就是在这个矛盾里找平衡用最小的代价保留足够的排障信息。本文讲清楚 SkyWalking 的采样机制与在大模型场景的落地策略。为什么必须采样开销与成本的真实来源SkyWalking 的采样机制全景实战探针与 OAP 双层采样配置大模型场景的采样策略设计存储与 TTL 成本优化1. 为什么必须采样开销与成本的真实来源一条链路从产生到可查询要经历四道成本关**探针开销**每个 Span 的创建、上下文维护、序列化都需要 CPU大模型链路 Span 多单请求探针耗时可能从微秒级升到毫秒级会直接抬升接口 P99。**网络开销**探针把 Segment 批量上报给 OAP全量上报在高并发下会打满网卡。**OAP 开销**OAP 要做拓扑聚合、指标计算、Trace 解析数据量线性放大。**存储开销**Trace 原始数据落在 Elasticsearch / BanyanDB / TiDB按数据量计费且需要磁盘容量与索引。以一个日活推理峰值 5000 QPS、平均每个对话 60 个 Span 的服务估算全量采集每天产生约 260 亿个 Span 的写入压力。即便按 10% 采样也能砍掉 90% 的存储与计算成本而排障所需的「慢调用」「错误调用」样本依然充足。因此采样的目标不是「少采」而是「聪明地采」保住有排障价值的样本错误、慢调用、特定模型丢弃无差异的海量正常样本。2. SkyWalking 的采样机制全景SkyWalking 的采样分布在两层**第一层探针端采样agent.sample_rate**。探针在创建 Segment 的第一个 Span 时按概率决定这条链路是否采集。一旦决定采样整条链路包括后续异步、跨进程的所有 Span都会被采集决定不采则整条丢弃。这是成本最低的一层因为它在源头就拦掉了数据。**第二层OAP 端采样receiver-trace**。即使探针全量上报OAP 在接收端仍可按 sampleRate 二次丢弃。这一层通常用于「探针全采、服务端按策略收口」的集中管控场景。除此之外还有三个「强制采样」开关保证关键样本不被采样率误杀force_sample_error_segment错误链路强制采样默认 true。slow_trace_segment_threshold超过该耗时的慢链路强制采样毫秒。错误与慢调用是排障的核心务必保持强制采样开启。采样率单位的坑探针端 agent.sample_rate 是 0~1 的小数1 表示 100%而 OAP 端 sampleRate 是以「万分之一」为单位的整数10000 表示 100%。两者容易混淆配置时要特别注意。3. 实战探针与 OAP 双层采样配置探针端配置写在 agent.config推荐用环境变量注入便于按环境区分agent.service_name${SW_AGENT_NAME:llm-inference}collector.backend_service${SW_AGENT_BACKEND:oap:11800}agent.sample_rate${SW_AGENT_SAMPLE_RATE:0.1} # 采样率日常 10%压测/灰度可调高agent.force_sample_error_segment${SW_FORCE_SAMPLE_ERROR:true} # 错误链路强制采集永远不要关启动命令通过环境变量覆盖做到「测试环境全采、生产环境抽样」java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \-DSW_AGENT_NAMEllm-inference \-DSW_AGENT_SAMPLE_RATE0.1 \-DSW_FORCE_SAMPLE_ERRORtrue \-jar inference-service.jarOAP 端在 application.yml 的 receiver-trace 中配置服务端采样与慢调用强制采样receiver-trace:default:# 服务端采样率单位 1/1000010000 100%sampleRate: ${SW_TRACE_SAMPLE_RATE:10000}# 错误段强制采样forceSampleErrorSegment: ${SW_FORCE_SAMPLE_ERROR:true}# 慢调用阈值毫秒超过则强制采样slowTraceSegmentThreshold: ${SW_SLOW_TRACE_THRESHOLD:2000}把 slowTraceSegmentThreshold 设成略高于你的大模型推理 P99例如推理普遍 1.5s可设 2000ms这样凡是「比正常慢」的调用都会被保留正好命中性能排查需求。4. 大模型场景的采样策略设计大模型链路不能简单「全局 10% 了事」需要分层设计**错误全采**force_sample_error_segmenttrue推理失败、超时、降级都进链路便于复盘。**慢调用全采**slowTraceSegmentThreshold 对齐业务 SLA慢推理必留样。**按端点区分**健康检查、心跳类接口价值极低可以单独调低甚至不采核心对话接口保留更高比例。基础版的 agent.sample_rate 是全局的要做到「按端点不同采样率」需要自定义采样插件或借助 OAP 服务端按 endpoint 过滤例如上游只把核心接口打到全采的探针分组。**按模型区分**把 modelName 作为关联上下文见第 06 篇对昂贵的大模型如 72B 推理提高采样率对轻量模型降低。**压测期临时全采**大促或压测前通过环境变量把 SW_AGENT_SAMPLE_RATE 调到 1拿到完整链路做容量评估结束再调回。不同采样率下的成本与覆盖率直觉对比如下表采样率存储/计算成本错误捕获慢调用捕获适用阶段---------------100%最高全量全量测试、压测、灰度初期50%中高全量(强制)全量(强制)上线观察期10%低全量(强制)全量(强制)稳定生产环境1%极低全量(强制)全量(强制)超大流量常态注意表中「错误/慢调用」一列始终全量正是因为强制采样开关的存在——这正是采样策略能「又省钱又不漏问题」的关键。5. 存储与 TTL 成本优化采样解决的是「写入量」而 TTL数据保留时长解决的是「存量规模」。即便采了 10%Trace 原始数据长期堆积仍会撑爆存储。SkyWalking 的存储 TTL 在 application.yml 的 storage 段配置storage:banyandb:# Trace 原始记录保留天数recordDataTTL: ${SW_RECORD_DATA_TTL:3}# 指标数据保留天数拓扑/监控图表用metricsDataTTL: ${SW_METRICS_DATA_TTL:15}优化建议**Trace 原始数据 TTL 短3~7 天**排障通常在发生后几天内完成过长保留收益低。**指标数据 TTL 长15~30 天**趋势图、容量规划需要长期数据且指标体积小。**存储选型**Elasticsearch 功能全但成本高BanyanDB 是 SkyWalking 原生时序存储针对 Trace 做了压缩成本显著更低大模型高吞吐场景首选。**索引策略**ES 下合理设置分片数与副本数避免为历史索引长期占用资源。不同存储的取舍如下表存储成本查询能力适用------------Elasticsearch高强全文检索已具备 ES 集群、需复杂查询BanyanDB低中原生优化 Trace新部署、成本敏感、高吞吐TiDB / MySQL中弱适合小流量小规模验证6. OAP 采样内部原理与限流理解采样在 OAP 内部怎么生效有助于避免误配。OAP 的 receiver-trace 模块在收到 Segment 后先判断是否命中采样未命中的 Segment 直接丢弃根本不会进入后续的拓扑聚合、指标计算与 Trace 存储流程。这意味着服务端采样不仅省存储还省 OAP 的 CPU 与内存——这是它和「只删存储」最大的区别。需要厘清一个常见误解**错误强制采样发生在探针端而不是 OAP 端**。当探针发现当前 Segment 包含错误 Span 或耗时超过 slow_trace_segment_threshold 时会无视 sample_rate 强制标记为「采样」并连带整条链路上报。因此即使你把 SW_AGENT_SAMPLE_RATE 设成 0.01错误与慢调用依然 100% 进入 OAP。如果你发现错误链路也没了第一反应应是检查 force_sample_error_segment 是否被误关或探针与 OAP 版本不匹配导致字段解析失败。此外OAP 还有一层自我保护当接收流量超过处理能力时会通过内部缓冲与丢弃策略限流避免被冲垮。这正是为什么生产环境更该在探针端就把采样率降下来——把压力挡在源头比让 OAP 在入口限流更优雅。7. 采样率选择的决策流程与成本估算采样率不是拍脑袋定的要基于流量与成本倒推。下面以一个典型大模型对话服务做估算假设平均每次对话产生 60 个 SpanQPS 为对话请求数峰值 QPS全量(100%)每日 Span 数10% 采样每日 Span 数1% 采样每日 Span 数------------1000约 52 亿约 5.2 亿约 5200 万3000约 155 亿约 15.5 亿约 1.55 亿5000约 260 亿约 26 亿约 2.6 亿每个 Span 在 Elasticsearch 里索引后约占几百字节到 1KB取决于 tag 数量与长度26 亿 Span 就是 TB 级写入与存储。按 10% 采样写入量与存储直接降到约十分之一且错误与慢调用因为强制采样仍然 100% 保留——排障所需样本完全够用。推荐的决策流程**灰度/上线观察期**sample_rate1100%拿到完整链路做容量评估与基线建立。**稳定生产期**降到 0.110%配合 force_sample_errortrue 与 slow_trace_segment_threshold 对齐 SLA。**超大流量常态**可降到 0.011%但必须监控错误/慢调用样本量是否足够定位。**压测/大促前**临时调回 1结束后调回。核心原则**正常流量可以少采异常流量必须全采**。采样率只砍「无差异的正常样本」不砍「有排障价值的异常样本」。8. 监控采样效果与防错采样配置一旦生效要持续监控它「有没有在正常工作」否则可能悄悄漏掉关键链路**监控采样后 Trace 数量**若某服务的 Trace 列表突然为空要么是 sample_rate 过低且恰好没有错误/慢调用要么是探针没挂上。需结合指标拓扑图 CPM判断——拓扑有流量但 Trace 为空就是采样或插桩异常。**监控错误样本完整性**定期检查错误链路是否仍 100% 出现。可以在测试环境主动制造一次错误请求确认它一定出现在 Trace 列表里。**告警联动**把「错误 Span 数突增但 Trace 样本为 0」作为独立告警项这比「接口变慢」更早暴露采样配置问题。**版本一致性**探针 apm-toolkit-trace 与 OAP 大版本必须一致。跨大版本升级 OAP 时先升级 OAP 再升级探针避免快照字段不兼容导致强制采样失效。9. 多环境采样配置管理采样率绝不能硬编码在 agent.config 里否则测试环境全采、生产环境也全采成本失控。正确做法是用环境变量或配置中心按环境注入做到「一套探针包多环境不同策略」。在 Kubernetes 里常见做法是用 ConfigMap 环境变量env: # deployment.yaml 片段- name: SW_AGENT_SAMPLE_RATEvalue: 0.1 # 生产环境默认值- name: SW_FORCE_SAMPLE_ERRORvalue: true当需要临时调高如大促前全量观察只需改这个环境变量并滚动重启无需重新打镜像。更进一步的做法是接配置中心如 Nacos / Apollo运行中动态下发采样率探针支持部分配置热更新真正做到「不重启调采样」。推荐的环境策略环境sample_rate说明---------本地开发1全量方便调试测试 / 预发1全量建立基线灰度上线0.5观察真实流量稳定生产0.1成本与覆盖平衡超大流量0.01仅保留异常样本10. 采样与可观测性权衡速查把「采多少」和「能看见什么」直接对应起来避免拍脑袋你的诉求采样策略还能看见什么---------我要完整复现每一次请求100%全部 Trace成本最高我要抓性能瓶颈但不想太贵10% 强制错误/慢正常样本抽样异常全留我只关心报错和大模型慢推理1% 强制错误/慢仅异常样本成本极低我要长期趋势图任意采样 长 TTL 指标拓扑/指标不受影响记住一个核心不等式**采样率只影响「正常样本的留存比例」不影响「错误与慢调用的留存」**。只要 force_sample_error_segment 和 slow_trace_segment_threshold 开着你最该关心的异常链路永远不会丢。这是采样能「又省又准」的根本原因。总结采样是「前端节流」TTL 与存储选型是「后端瘦身」。两者结合才能在高并发大模型场景下既把成本压下来又保证错误与慢调用万无一失。下一篇我们进入拓扑图看看怎么用全局视角定位瓶颈节点。
