全量采链路还是抽样：追踪数据量存储开销和排查成功率怎么平衡

一天 2000 万次请求，一次请求在微服务之间展开平均 30 个 span，每个 span 序列化后约 600 字节——三个数乘下来，是 360GB 原始追踪数据/天。这还只是 payload 本身，没算索引、副本和元数据。全量采还是抽样，这个纠结的根子就在这笔账上：它不是"硬盘贵不贵"的问题，而是当 QPS 上去之后，追踪数据的上报、落盘、检索会反过来吃掉业务资源，而故障发生时你恰恰最需要它可用。

先说结论，后面慢慢拆：全量采集的真正风险不是存储成本，是"写入链路本身成为新的故障源"；合理做法不是二选一，而是分层——常态低比例采样保证趋势与拓扑，对慢请求、错误请求、关键接口做条件全采，保证排查时拿得到那条链路。

一条链路到底有多大：把 span 拆开称一称

讨论采样率之前，得先知道被采的东西有多重。一个 span 记录的是一次调用单元：trace_id（16 字节）、span_id（8 字节）、parent_span_id、操作名、调用类型（入口/客户端/内部）、开始时间戳、耗时、状态码，再加上若干属性（HTTP 方法、URL 模板、数据库语句、缓存键、实例 IP）和错误信息。

按典型架构推算（仅为量级示例，非实测）：操作名和属性用字符串存储、未做字典压缩时，一个中等复杂度的 span 序列化后落在 400–800 字节区间，取 600 字节做基准。如果往属性里塞 SQL 全文、请求体片段，单个 span 可以轻松涨到 3–5KB，这是很多人踩的第一个坑——不是 span 数量太多，是每个 span 太胖。

再看一条链路有多少 span。一次下单请求通常穿过网关、鉴权、订单服务、库存服务、支付服务、消息投递，每个服务内部又有数据库调用、缓存调用、RPC 调用各一个 span。按典型架构推算，一次中等复杂度请求展开 20–40 个 span，取 30 个。于是单条链路的 payload 体量约为 30 × 600B ≈ 18KB。这个数字是所有后续推导的起点，换成你自己的系统时，只需替换 span 平均大小和平均 span 数两个参数。

值得单独提一句的是"断链"对体量的影响。如果每个服务各自独立决定是否采样，一条 30 个 span 的链路可能只留下分散在 5 个服务里的 7 个 span，剩下 23 个是孤儿。数据没少存多少，可用信息却塌了大半。所以采样决策必须在链路入口做一次，然后随调用上下文一路传播下去，这是后面所有策略的前提。

从 QPS 到 GB：把放大过程摊开算

有了单条链路 18KB 这个基准，就可以把 QPS 换算成存储量。假设一个中等规模的交易系统：日均 2000 万次请求，峰值 QPS 3000，均值 QPS 约 230（以下均为按典型架构推算的量级示例，实际请按自身流量参数代入）。

全量采集下：2000 万 × 18KB ≈ 360GB/天的原始 payload。这笔数据进入后端存储后还要膨胀——倒排索引、列存副本、trace_id 与 service 名的二级索引、时间戳分区元数据，加起来普遍按 1.5–3 倍估算，取 2 倍，实际落盘约 720GB/天。保留 7 天约 5TB，保留 30 天约 21TB，一年滚动下来接近 260TB。

真正要命的不是总量，是峰值写入速率。峰值 3000 QPS × 30 span = 9 万 span/秒，乘以 600 字节，光 payload 就是 54MB/s 的持续写入。经过后端的写入放大（序列化格式转换、索引构建、副本同步），磁盘侧的持续写压力按 3–5 倍估算会到 150–270MB/s，而且这是 7×24 不间断的。这个量级不是加一块硬盘能解决的，它决定了你需要几条采集管道、几台后端节点、内网要留多少带宽。

这里给出通用公式，方便你代入自己的数字：日均存储量 ≈ 日请求数 × 平均 span 数 × 单 span 平均字节数 × 膨胀系数；峰值 span 速率 ≈ 峰值 QPS × 平均 span 数。采样率 p 直接乘在日请求数上，其余参数不变。也就是说，采样率从 100% 降到 1%，上面那 720GB/天就变成 7.2GB/天——这就是抽样最直观的收益，也是大多数人只看到收益就停在这里的原因。

全量采集的第一个代价：上报链路在抢业务的资源

追踪 SDK 是跑在业务进程里的。它要做的事很琐碎：为每个调用创建 span 对象、记录时间戳、在调用结束时补全属性、序列化、塞进内存队列、攒批后通过网络发给采集器。这些动作单看都很轻，但乘上峰值 QPS 之后就不是了。

按典型架构推算的量级参考：Java 系应用开启全量追踪后，SDK 常驻 CPU 占用通常在几个百分点的量级（不同框架插桩方式差异很大，字节码增强比手动埋点更重），堆内存里还要常驻一个发送队列和一批待序列化的 span 对象。对 GC 敏感的应用，这批短生命周期对象会明显抬高 young GC 频率——平时看不出来，在流量高峰和 Full GC 边缘时就会被放大。

更危险的是队列打满之后的行为。采集 SDK 的内存队列通常有上限，满了之后只有两种策略：丢弃新 span，或者阻塞业务线程。前者只是丢数据，后者会直接把延迟传导到用户请求上。很多 SDK 默认是丢弃，但一旦你配了"不允许丢"或者用了阻塞式导出，追踪系统就从观察者变成了参与者。我见过最难受的一种情况：后端存储抖动，采集器收不动，SDK 队列堆积，业务进程内存一路涨到被 OOM 杀掉——追踪系统把被观测对象干掉了。

还有一层是网络。9 万 span/秒的上报流量如果跨可用区甚至走公网，会占用本该给业务调用用的带宽。把采集器部署在同机柜或同可用区内网、用 gRPC 长连接批量上报、把采样决策前移到 SDK 侧（被丢弃的 span 根本不序列化、不上报），这三件事能把上报开销压掉一大截。注意最后一条：尾部采样做不到"不序列化就不上报"，因为它在决策前必须拿到完整链路，这是后文策略对比的关键分水岭。

第二个代价：存储不是线性变贵，是索引在膨胀

很多人算存储账的时候只算 payload，忽略了索引才是大头。后端存储要为 trace 建立可检索的维度：服务名、操作名、状态码、耗时区间、标签键值对。每多索引一个字段，写入时多一份构建开销，磁盘上多一份数据。

最典型的失控来源是高基数标签。把 user_id、order_id、session_id 这种枚举不完的值当成标签写进 span，等于在倒排索引里塞进几千万个唯一词条。按典型架构推算，索引体积可以在这种情况下翻好几倍，查询反而更慢——因为检索要先在庞大的词典里定位。正确的做法是：这类高基数值放到 span 属性里存但不建索引，或者干脆只写进日志，靠 trace_id 关联。

另一个被低估的是副本与保留策略。为了高可用，追踪数据通常至少两份副本；为了省钱，又想长期保留。这两件事方向相反，所以冷热分层几乎是必然选择：热层放最近 3–7 天，用 SSD 保证查询秒级响应；温层放 30 天，可以接受十几秒的查询延迟；再久的数据转冷存（对象存储），只归档不检索。绝大多数排查发生在故障后的头几个小时，把预算压在热层才是划算的，把三个月前的数据留在 SSD 上等着被查询一次，是纯粹的浪费。

第三个代价：查询变慢，而排查最怕慢

按 trace_id 精确查一条链路，在任何后端上都是毫秒到亚秒级，因为那是点查。真正吃力的是另一类查询："给我过去一小时里下单接口耗时超过 2 秒的所有请求"。这是范围扫描加过滤加排序，代价与库里的数据量成正比。

全量库上跑这类查询，几十秒到几分钟是常态，赶上故障期间写入还在打满，查询排队会更久。而一次线上故障的黄金处置窗口通常只有十几到几十分钟——如果你的追踪系统每次聚合查询要等两分钟，工程师会本能地放弃它，转回看日志和猜。这套系统就白建了。

采样后的库完全是另一个体验。同样条件下数据少两个数量级，聚合查询压到 1–3 秒，工程师愿意反复试、愿意换维度再看一遍。排查成功率不只取决于"有没有那条数据"，同样取决于"能不能在压力下快速拿到"。这一点在讨论采样率时经常被漏掉：全量采集牺牲的恰恰是故障时刻的可用性，而你建这套系统就是为了那一刻。

追踪后端跑在什么机器上：从热窗口反推资源

如果打算自建追踪后端（无论是搜索引擎类还是列式数据库类），资源估算的逻辑和 Web 服务器完全不同。它吃的是三样东西：内存（热数据的索引和缓存常驻）、磁盘随机写 I/O（索引构建）、内网带宽（span 上报与副本同步），CPU 主频反而不是第一位。

估算方法很直接：先按前面的公式算出热窗口数据量，比如 7 天热层 5TB，副本两份就是 10TB 可用容量需求；再按经验值给索引留出与数据量同量级的内存，让热查询命中缓存；最后按峰值 span 速率估算采集器节点数——按典型架构推算，单个采集器节点的稳定吞吐在每秒几千到上万 span这个量级（取决于是否做尾部采样缓冲、是否有复杂处理管道），9 万 span/秒的峰值大致需要十几个节点的采集层。

这类后端通常跑在物理机或大内存裸金属上，虚拟机的 I/O 抖动和内存开销在这种持续高写入场景下会被放大。像一万网络这样深耕 IDC 19 年（成立于 2007 年）的服务商，华南、华东、华北多节点可选，部署追踪后端时可以按上面这套热窗口反推法先定内存与磁盘规格，再跟服务商确认具体机型与实时报价。有一点值得强调：采集层节点要跨机架甚至跨可用区分布，别让追踪后端的单点故障和业务故障同时发生——这也是为什么我倾向于把后端放在有冗余托管条件的服务商那里，而不是随便找一台闲置机器。

三种采样策略各自丢掉了什么

采样的核心矛盾可以量化。假设某类严重故障一天只发生 3 次，随机采样率 1%，那么"至少采到其中一条"的概率是 1-(1-0.01)³ ≈ 3%。也就是说，97% 的情况下你打开追踪系统，那条最该看的链路不在里面。反过来，如果这类故障一天发生 20 万次（比如某个高频接口的普遍报错），1% 采样也能捞到 2000 条，绰绰有余。随机采样丢的不是"错误"，是"低频但严重的错误"——而后者才是真正让人半夜爬起来处理的那部分。

表格里最容易被忽略的是最后一列——策略没有好坏，只有和规模、团队运维能力是否匹配。尾部采样听起来最优雅，但它要求你有一层能扛住全量缓冲的采集层和把同一 trace 路由到同一节点的负载均衡。团队如果连采集层都没有，直接上尾部采样，等于把全量采集的代价原封不动搬到了采集器上，只是延后了几秒钟发生。

条件采样怎么设计：把"值得看"的请求挑出来

我倾向的设计是三层叠加，从下往上分别是基底、兜底和例外。

基底是全局低比例随机采样，比例通常落在 1%–5%。它的作用不是排查单次故障，而是维持依赖拓扑、慢调用分布、服务间耗时占比这类趋势视图。这个比例唯一的判断标准是"每个核心接口每分钟能不能采到足够多的样本"，后面会讲怎么算。

兜底是对异常无条件全采，这是整套设计里最不能省的一层。触发条件至少包含三类：状态码异常（HTTP 5xx、4xx，或 RPC 层报错）、耗时超过该接口的 P99 阈值（动态阈值比固定阈值好用，固定阈值在业务变化后会失效）、链路中出现 error 事件。兜底的触发判断必须在链路结束时做，所以要么走尾部采样，要么在 SDK 侧做一个折中——SDK 在内存里保留最近若干条链路的完整数据，一旦本次请求出错就立刻提交，正常结束则丢弃。这个折中方案的资源消耗是固定的（只和并发数有关，和 QPS 无关），不需要全量缓冲，是我个人更推荐的落地方式。

例外层是按路由和标记开的口子。核心交易接口（下单、支付、对账）给高比例甚至全采；健康检查、心跳、静态资源、前端埋点上报直接置 0%，这类请求常常占据请求总数的一半以上却毫无排查价值，把它们挡在门外比调任何比例都有效。另外一定要留一个人工通道：允许在请求头里带一个调试标记，被标记的请求无条件全采并且全链路传播。当客服转来"某个商户说下单失败"时，你能让对方复现一次并拿到完整链路，这比事后在海量数据里翻找高效得多。

还有一个必须提前定死的规矩：不要用追踪数据算 SLI。尾部采样会系统性放大错误和慢请求的比例，从追踪库里统计出来的错误率、P99 会被严重高估。可用性指标走独立的指标通道（计数器、直方图），追踪只负责"解释为什么会这样"。两者通过 trace_id 关联，各司其职，别混着用。

采样率定多少：判断依据不是百分比，是三个反推

拍脑袋定 10% 是最常见的做法，也是最没依据的做法。采样率应该由三个方向反推出来，取其中的约束交集。

第一个反推来自预算。先定"我愿意为追踪付出的每日存储增量"，比如 20GB/天，再除以单条链路落盘量（前面算的 36KB），得到每天可采约 55 万条链路；若日请求 2000 万，采样率上限就是 2.7%。这个方向的优点是确定，缺点是它只约束成本，不保证可用性。

第二个反推来自统计可信度。趋势视图需要的是"每个统计窗口内样本足够多"。按典型架构推算的经验参考：单个核心接口每分钟被采到的链路数在百条量级时，P99 的分钟级曲线才基本稳定，低于几十条时曲线会剧烈抖动到没法看。用这个标准反推——某接口峰值 500 QPS，每分钟 3 万请求，1% 采样就是 300 条/分钟，够用；另一个接口峰值只有 20 QPS，每分钟 1200 请求，1% 采样只有 12 条，必须单独给它提到 10% 以上。这就是为什么采样率必须按接口差异化，全局一个数必然两头不讨好。

第三个反推来自容错。回到那个公式：某类事件一天发生 k 次，采样率 p，至少采到一条的概率是 1-(1-p)^k。你先回答"这类故障我能不能接受查不到链路"，能接受就维持随机采样，不能接受就必须给它上兜底全采——注意这时候提高 p 是没用的，把 p 从 1% 提到 10%，k=3 时的命中率也只从 3% 升到 27%，仍然不够。低频高危事件的唯一解法是条件全采，不是提高采样率。

最后一个反直觉的建议：大促和故障期间应该降采样，而不是升采样。流量洪峰时后端本来就吃紧，此时把采样率调高只会加速后端崩溃；正确的做法是让自适应策略把写入量压到恒定水位，同时保留兜底层不动——反正兜底层保证的是"异常请求一定在"，常态样本少一些不影响定位问题。

上线之后怎么验证采样没把关键链路漏掉

采样策略配完就不管，是这套系统失效最常见的原因。配置会过期、新接口会漏配、SDK 会静默丢数据，而这些问题在你真正需要排查之前毫无症状。所以必须建立几条持续运行的验证。

第一条是合成探针。用一个定时任务，每隔一两分钟发起一次构造好的请求（带上调试标记），然后校验这条链路是否真的出现在后端里，从发起到可查询的延迟是多少。这个探针同时监控了三件事：采样规则是否生效、采集链路是否通畅、入库延迟是否异常。它坏了，就当作追踪系统不可用来告警，不要等到故障时才发现在裸奔。

第二条是错误对账。把业务侧错误日志的条数和追踪库里标记为错误的链路数做每日比对。如果某接口日志里报了 1000 条错，追踪里只有 5 条 error trace，兜底规则一定出了问题——可能是阈值配错，可能是错误没被正确标记为 span 状态。这个对账能抓住绝大多数兜底失效。

第三条是延迟对账。拿网关侧的 P99 延迟和追踪库里该接口的 P99 对比。如果网关看到 3 秒，追踪库里最高只有 800 毫秒，说明最慢的那批请求根本没进来——慢请求兜底形同虚设。这个偏差是最容易被忽略的，因为采样后算出来的 P99 天然会偏低，很多人误以为"系统比想象的健康"。

第四条是断链率和丢弃率的监控。断链率指"父 span 缺失"的链路占比，正常应该接近零，明显升高说明采样决策没有正确传播，或者某个服务的 SDK 版本不一致。丢弃率要看两个计数：SDK 侧发送队列的丢弃数和采集器侧的处理丢弃数，两者都必须有告警，静默丢弃等于数据凭空消失。

第五条是上线初期的双写对照。新策略上线的前两周，可以在采样写入主库的同时，把原始 span 以文件形式廉价地落到对象存储（只写不索引，成本很低）。这期间遇到任何排查，都能回捞全量数据做对照，验证新策略到底漏掉了什么。两周后确认没问题再关掉双写。这办法笨，但它是唯一能真正回答"我的采样策略靠不靠谱"的手段。

关于采样率与追踪落地的几个高频疑问

Q1：采样会不会导致排查时找不到那条请求？

会，而且这是随机采样最典型的失败场景。概率可以算：某类异常一天发生 k 次，采样率 p，至少采到一条的概率是 1-(1-p)^k。p=1%、k=3 时命中率只有约 3%。高频错误不受影响——一天 20 万次错误在 1% 采样下仍有约 2000 条；真正危险的是"某个商户的支付回调一天只失败两三次"这类低频严重问题。解法不是把采样率调高（提到 10% 命中率也才 27%），而是给错误和慢请求加兜底全采，把 p 对这部分请求直接拉到 100%。

Q2：头部采样和尾部采样怎么选？

看两件事：有没有独立的采集层，以及能不能接受入库延迟。头部采样在请求入口就决策，被丢弃的 span 不序列化、不上报，SDK 开销最小、实现最简单，缺点是决策时不知道请求后续会不会出错。尾部采样在链路结束后按结果决策，能精准留住异常，但它必须在采集器侧缓冲全量数据，内存和磁盘压力回到全量级别，还要解决同一 trace 的 span 汇聚问题，并且数据入库有数十秒到数分钟的延迟。没有独立采集层的团队，我建议用 SDK 侧兜底（内存保留最近若干条链路，出错才提交）替代尾部采样，效果接近而代价固定。

Q3：错误请求怎么保证一定被采到？

两条路。走尾部采样的话，在采集器侧配规则：状态码异常、span 状态为 error、耗时超阈值，命中任一条件即保留整条链路。不想上尾部采样的话，在 SDK 侧做本地缓冲——每个请求处理期间把 span 暂存在内存（通常还要限制并发数和单条 span 数防止内存失控），请求结束时若判定异常就提交，正常则直接丢弃。无论哪条路，都要在上线后用"错误日志条数 vs 追踪 error 链路数"做每日对账，否则规则配错你不会有任何感知。另外，兜底规则要配上写入上限，避免雪崩时兜底数据量暴涨把后端压垮。

Q4：span 打太多有没有代价？

有，而且是三重代价。第一重是运行时开销：每个 span 都要创建对象、记录时间戳、序列化、入队上报，按典型架构推算，Span 数量翻倍对 SDK 侧 CPU 和 GC 的影响大致也是翻倍量级。第二重是存储：span 数直接线性放大日均数据量。第三重最容易被忽略——往 span 属性里塞高基数字段（user_id、order_id、请求体全文）会让索引体积急剧膨胀，单个 span 从 600 字节涨到几 KB，同时查询变慢。实践上建议：数据库语句只保留模板不绑参数，业务标识类字段写进属性但不建索引，单个请求的 span 数控制在几十个量级，超过就说明插桩粒度过细。

Q5：追踪数据保留多久合适？

按查询概率分层，别用一个保留期。绝大多数排查发生在故障后的头几个小时，所以热层（SSD、秒级查询）保留 3–7 天就够覆盖几乎全部场景；温层保留 30 天，用于复盘和周期性对比，可以接受十几秒的查询延迟；再久的数据转冷存归档（对象存储），只保留不检索，成本极低。需要长期趋势的话，正确的做法不是延长追踪数据保留期，而是把聚合结果（按接口、按服务、按小时的耗时分布和错误率）落到指标系统里长期保存。另外要注意容量规划：前面推算的全量场景 7 天约 5TB，保留期每翻一倍，存储预算同比例翻倍。

Q6：采样率改了要不要重启服务？

取决于采样配置的下发方式，没有统一答案。如果采样率是写死在启动参数或环境变量里的，改完必须重启进程，这在核心服务上代价很高。如果 SDK 支持从采集器或配置中心远程拉取采样配置（多数主流实现都有这类扩展机制），改完通常在秒级到分钟级内自动生效，不需要重启。所以选型时要把"采样配置能否热更新"当成一项硬指标来评估——它决定了你在故障期间能不能快速调整策略。改完之后记得同步记录采样率变化，否则历史数据对比时口径不一致会得出错误结论。

Q7：链路追踪和日志、指标怎么配合？

三者职责要分清：指标负责"有没有问题"，追踪负责"问题出在哪一段"，日志负责"具体是什么"。指标是全量、低成本、长期保留的，用来发现异常和定义告警；追踪是采样、高成本、短保留的，用来还原单次请求的完整路径和耗时分布；日志是明细，用来给出具体错误上下文。串联三者的关键是 trace_id——日志里必须打印 trace_id，指标告警触发后能用 trace_id 直接跳到链路详情，链路里发现问题服务后再用 trace_id 反查该服务的日志。反过来，不要用追踪数据去算 SLI（尾部采样会让错误率被系统性高估），也不要指望指标能告诉你慢在哪个下游。

我的立场：把配额花在刀刃上，别为"全都有"付账

回到标题那个问题——全量还是抽样。我的答案是明确的：常态抽样，异常全采，接口差异化，并且用探针和对账持续验证。全量采集看起来是最省心的选择，实际上它用确定性的资源开销换来了不确定性的收益，还额外附赠了一个在故障时刻最脆弱的写入链路。一个 1% 基底采样加上无条件错误/慢请求兜底、再加上核心接口高比例的方案，按典型架构推算能覆盖绝大多数排查场景，而数据量通常是全量的 3%–8%。

剩下那 90% 被丢掉的链路，绝大多数是正常请求——它们对趋势统计有贡献，对排查没有。真正需要担心的只有低频高危那一类，而那一类的解法是条件全采，不是提高采样率。想清楚这一点，采样率就不用再纠结了。

最后落到承载层面：追踪后端是持续高写入、吃内存和磁盘 I/O 的负载，通常跑在物理机或大内存裸金属上比跑在虚拟机上更稳。如果团队没有自建机房的运维能力，把后端放在租用的物理资源上是更省心的选择——像一万网络这类深耕 IDC 19 年（成立于 2007 年）、有自营机柜与多节点可选、提供 7×24 中文工单（平均 5 分钟响应）与硬件故障自动迁移的服务商，至少能保证后端节点出问题时有人接手。具体机型、规格与费用请以官网实时报价和签约合同为准。

本文涉及的数据量、资源占用与命中率均为按典型架构推算的量级示例，用于说明估算方法与取舍逻辑，非任何实测数据或性能承诺。实际数值请按自身服务拓扑、span 平均大小、平均 span 数与流量参数重新代入计算。相关硬件与托管资源信息可参考一万网络官网（https://www.idc10000.net/），具体以签约时最新报价与合同为准。