一、项目背景

我们的 AI 网关一开始做全链路追踪，所有调用全量上报，想着看得全，排查啥都有据。结果调用量一大，存储和费用直接炸了，一个月的 trace 存储顶半个模型训练的预算，财务找上门问为什么可观测账单这么高。更糟的是关键错误被海量正常 trace 淹没，想查一次慢请求得翻半天，排查效率不升反降，研发抱怨"全量追踪反而更盲"。我们意识到全量追踪在网关这种高吞吐场景根本不划算，得换个思路，钱要花在刀刃上，不能为了可观测把利润吃光。我们做过一次成本拆解，正常请求 trace 占了九成以上的存储，却几乎从不被人查，纯粹是沉没成本，这让我们下定决心砍采样。

二、落地场景

我们把追踪改成按策略采样。按错误率和延迟分层，正常请求抽一部分，慢请求和错误请求全采。关键业务调用标记全采，确保不被抽样丢掉，这条业务的每一次调用都有完整 trace。低成本指标走旁路，不进重存储，只留关键维度。采样率可以动态调整，流量小的时候调高，大促时调低省钱，运营按预算调。费用进看板，哪条链路烧钱一眼看见，预算也不再失控，财务终于不找了，大家各司其职。研发侧体感是查问题更快了，因为要翻的 trace 少了，真正有价值的异常反而浮得上来，不再被正常的海洋淹没。关键业务的全采标记由调用方在请求头里带，网关按标记走全量 trace，业务侧完全自助，不用找我们开白名单。慢请求的阈值也做成可调，不同接口的慢标准不一样，查询类一百毫秒算慢，生成类五秒都正常，我们按接口维度配而不是全局一把尺。运营把采样率旋钮接到了值班面板上，大促前手动调低省钱，平时调高便于排查，一张表看各链路的采样分布和费用占比，财务要报表直接导，不用再找研发拉数。我们还把指标旁路接到了现有监控，告警规则和原来的基建打通，没另起一套，运维也不用学新系统。

三、关键技术挑战与解决思路

采样率平衡是最难的。抽太少关键错误抓不全，抽太多又烧钱，这个度要反复调。我们的策略是按错误和长尾采样，正常请求按比例抽，错误和慢请求全采，这样花钱最少还能保住该保的，钱都花在异常上。关键调用保全靠业务标记，标了全采的绝不抽样，这条线不能动。成本可控靠把指标和 trace 分开存，指标走便宜的时序库，重存储只放采样后的 trace。动态调采样靠实时流量，闲时多采便于排查，忙时少采省钱，一张旋钮给运营。这里踩过坑，第一版错误也按比例抽，结果一次故障的错 trace 被抽掉大半，定位花了三倍时间，后来错误改全采才稳，错误绝不能抽，抽错误等于自断线索，故障来了只能抓瞎，这个教训够记很久。

案例片段（已脱敏）： 调用链分层采样配置（示意）： sample.mode: stratified sample.error: full sample.slow.full: true sample.normal.rate: 0.1 metric.bypass_cheap_tsdb: true 某网关线追踪存储费用下降约 70%，关键错误捕获率保持 100%，trace 查询时效提升约 2 倍。

四、效果数据

我们盯存储费用、关键错误捕获率、trace 查询时效和采样覆盖率。存储费用下降约七成，财务的账单终于正常了；关键错误捕获率保持满格，该抓的错没漏，几次故障都靠它快速定位；trace 查询时效因为量小了反而更快，研发查问题不翻半天了；采样覆盖率对正常请求约一成，对错误和慢请求全采，该全的没少。我们把采样省下来的存储费用折算成可观测的投入产出，算下来每花一块钱采样能省七块存储，财务当场就批了把采样策略做成长期基线，不用每次大促临时申请。研发侧还意外发现，错误全采之后，几次故障的定位时间从小时级降到分钟级，他们愿意主动配合标记关键业务，因为尝到了排查快的甜头，协作顺了。

文中数据为项目复盘口径，实际值随流量波动，仅作趋势参考。研发那边反馈最实用的是，现在查问题不用再大海捞针了，几分钟能定位，也不再抱怨可观测反盲，排查效率高了一截，连带着对网关的信任也回来了，以前他们觉得网关是个黑盒。

五、可复用经验总结

高吞吐网关做全量追踪是浪费，采样才是正路，但采样得讲策略，不能为了省钱把错误也抽没了。错误和慢请求必须全采，这是底线，我们就是在这里栽过才记住的，错误抽样等于自断线索，故障来了抓瞎。指标和 trace 分开存，能把大头成本砍掉，时序库便宜够用，重存储留给真正要查的。我倾向闲时多采、忙时少采的动态思路，比写死一个固定率灵活，预算紧的时候调低也不慌。做可观测的人，先想清楚"到底要抓什么"，再去定采样，别一上来就全量，全量是最贵的偷懒，省下的钱够再买几张卡，性价比高得多。