尧图网页设计 
Jaeger 自适应采样Adaptive Sampling深度解析从吞吐量观测到动态采样概率的计算链路【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger自适应采样是 Jaeger 分布式追踪平台中用于动态控制采集成本的核心机制它不再依赖人工为每个服务设定固定的采样率而是由 Collector 持续观测各服务的真实流量按「服务 端点」维度周期性地重新计算采样概率使最终采集到的 trace 数量始终贴近预设的目标值每秒采样条数。阅读本文后你将掌握自适应采样的整体架构Aggregator / Post-aggregator / Provider 三大组件、概率计算的底层算法、全部配置项及默认值并能结合仓库源码定位到每个环节的具体实现。为什么需要自适应采样传统的固定采样率例如统一 10%存在两个痛点低流量端点可能完全采不到样本一个每秒仅发生 0.1 次调用的接口即使以 10% 的概率采样也需要数分钟甚至更久才能等到一条 trace排障时往往无据可查高流量端点会造成存储浪费对于每秒数千次调用的热点接口10% 的概率可能带来巨大的存储与检索成本而其中绝大多数 trace 价值有限。自适应采样给出的答案是以「目标每秒采样条数」为控制目标而不是以固定的概率为目标。系统通过观测真实流量动态调整每个端点service operation 组合的采样概率让高流量端点降低概率、低流量端点提高概率最终使各端点采集到的 trace 量都收敛到目标值附近。一个重要前提自适应采样本身不采样仓库文档internal/sampling/samplingstrategy/adaptive/README.md特别强调了一个关键设计边界adaptive sampling in Jaeger backenddoes not actually do the sampling. The sampling is performed by OTEL SDKs, and sampling decisions are propagated through trace context.也就是说Jaeger 后端中的自适应采样并不实际决定某个 span 是否被采样。真正的采样动作由应用侧接入的 OTEL SDK 完成采样决策通过 trace contextsampler.type、sampler.param等标签在调用链中传播。Jaeger Collector 端自适应采样的职责是观测流量计算每个服务/端点的真实吞吐量基于吞吐量与目标值动态计算采样概率通过 Jaeger Remote Sampling 协议把概率下发给 SDK由 SDK 按照该概率执行实际的概率采样。三大核心组件与整体工作流从源码结构看自适应采样模块位于 internal/sampling/samplingstrategy/adaptive/由三个相互协作的组件构成组件源码文件运行位置核心职责Aggregatoraggregator.go每个 Collector 实例作为 OTEL Collector 的 trace processor 运行在采集管道中观察经过本实例的所有 span识别 root span 并按 service/operation 聚合计数周期性地把吞吐量throughput写入存储Post-aggregatorpost_aggregator.go每个 Collector 实例但只有 leader 执行完整计算从存储加载所有实例写入的吞吐量并聚合计算出各端点的采样概率与 QPS写回存储Providerprovider.goCollector 的采样策略服务端定期从存储读取最新概率翻译成 Remote Sampling 协议响应供 SDK 轮询/sampling端点获取三者串成一条完整的闭环链路SDK 上报 span → Aggregator 聚合吞吐量 → 写入存储 → Post-aggregatorleader汇总计算概率 → 写回存储 → Provider 读取概率 → SDK 轮询获取新概率 → 按新概率采样 → 产生新的 span。Aggregator吞吐量观测与持久化Aggregator 是采集管道中的一个处理器。在 aggregator.go 的HandleRootSpan中可以看到它的核心逻辑只处理root spanParentSpanID 0。实现注释特别说明仅检查 parentId 判断根 span 并不充分但可以确定只有 root span 会携带采样器标签因此采样器标签成为判断依据读取 span 的sampler.type与sampler.param标签见getSamplerParamsaggregator.gosampler.param支持 float、int 与字符串三种表示统一转换为 float64调用RecordThroughput在内存中按service - operation - Throughput的嵌套 map 累计计数。RecordThroughputaggregator.go有两个值得注意的细节只对概率采样probabilistic的 root span 计数递增对于 lowerbound 采样的 span 不递增但仍然以计数 0 写入吞吐量目的是让后端的自适应采样处理器感知到该端点的存在以便开始为它计算概率同一端点记录的采样概率会去重后最多保留 10 个maxProbabilities 10用于后续判断该端点是否真的在使用自适应采样。聚合后的吞吐量通过runAggregationLoopaggregator.go按CalculationInterval周期性地把当前内存计数批量写入存储storage.InsertThroughput清空内存计数开始下一个周期触发postAggregator.runCalculation()进入概率计算阶段。Post-aggregator真正的“自适应”逻辑Post-aggregator 是负责“自适应”部分的核心它的主要工作分为两个阶段阶段一读取与聚合吞吐量。由于生产环境通常部署多个 Collector 实例每个实例的 Aggregator 都会向共享存储写入各自的吞吐量。Post-aggregator 通过GetThroughput(startTime, endTime)拉取一段时间窗口内所有实例写入的吞吐量由aggregateThroughputpost_aggregator.go按 service/operation 汇总计数并合并概率集合。合并后的结果以「吞吐量桶throughputBucket」的形式放入内存桶的数量上限为AggregationBuckets。阶段二leader 计算概率。为避免多个 Collector 同时计算并写回互相覆盖Post-aggregator 借助存储后端的简单 leader-follower 选举机制Leader执行完整计算——把各桶吞吐量换算成 QPS、加权平均、计算新概率并把概率与 QPS 写回存储InsertProbabilitiesAndQPSFollower同样加载吞吐量并在内存中聚合为随时接替 leader 做好准备但不计算概率、也不写回存储。一旦 leader 实例宕机follower 已持有最新吞吐量数据可以快速接管计算。选举租约的刷新由两个配置控制leader 每LeaderLeaseRefreshInterval默认 5s续租一次follower 每FollowerLeaseRefreshInterval默认 60s尝试竞争一次leader 的续租频率高于 follower 以降低锁竞争避免锁抖动。从吞吐量到概率的四步算法在calculateProbabilitiesAndQPSpost_aggregator.go与calculateProbabilitypost_aggregator.go中概率计算的完整流程如下吞吐量 → QPSthroughputToQPS把每个桶内各端点的计数除以桶的时间间隔count / interval得到每秒请求数参与计算的桶数不超过BucketsForCalculation。加权平均 QPScalculateWeightedQPS对多个桶的 QPS 做加权平均权重向量由 weightvectorcache.go 生成权重公式为w(i) i⁴并归一化越新的桶权重越大最新数据位于切片头部。计算新概率由可插拔的概率计算器完成当前默认实现是PercentageIncreaseCappedCalculator见 calculationstrategy/percentage_increase_capped_calculator.go基础思路是newProbability prevProbability × (targetQPS / curQPS)当curQPS targetQPS需要提高概率时限制单次增幅不超过上一概率的 50%默认 cap 0.5例如概率从 0.1 提升 400% 的请求只能提到 0.15从而防止过采样震荡当curQPS targetQPS需要降低概率时直接跳到目标值快速抑制过采样。边界保护与容差最终概率被夹在[MinSamplingProbability, 1.0]之间math.Min(max, math.Max(min, newProbability))若 QPS 为 0端点突然无流量概率翻倍强制至少采样一个 span 以便感知端点状态withinTolerance使用DeltaTolerance判断实际 QPS 与目标值的偏差是否已“足够接近”abs(actual-expected)/expected DeltaTolerance若是则沿用旧概率、不发送新的控制信号避免概率频繁抖动。此外Post-aggregator 使用一个SamplingCachecache.go记录最近 25 轮serviceCacheSize内每个端点使用的概率与是否启用了自适应采样。isUsingAdaptiveSamplingpost_aggregator.go据此判断一个端点是否真的在用自适应采样若端点当前概率等于InitialSamplingProbability则视为首次出现、默认采用自适应否则检查本轮吞吐量记录的概率集合或上一轮缓存只有确实观察到了匹配的概率值才继续对其实施自适应控制。这样可以把那些使用固定概率采样的端点排除在动态调整之外。新端点如何启动当检测到一个新的服务或端点时README 明确说明它最初以InitialSamplingProbability默认 0.001被采样直到收集到足够的数据来计算与该端点实际流量相匹配的采样率。这个过程由DefaultSamplingProbability与MinSamplesPerSecond共同保证即使端点在初始概率下采不到样本MinSamplesPerSecond默认每分钟 1 条也会兜底确保低流量端点至少能被采集到。Provider把概率翻译成 Remote Sampling 策略Provider 是面向 SDK 的出口。SDK 按固定周期默认每分钟轮询 Jaeger 的/sampling端点Provider 的GetSamplingStrategyprovider.go返回对应服务的采样策略若该服务已有计算好的概率则返回按 operation 区分的概率列表否则返回默认策略概率 InitialSamplingProbability下限 MinSamplesPerSecond。generateStrategyResponsesprovider.go把存储中的ServiceOperationProbabilities翻译为 Jaeger Remote Sampling 协议中的PerOperationSamplingStrategies每条包含 operation 名与对应的ProbabilisticSamplingStrategy.SamplingRate。值得注意的同步机制由于只有 leader 会把概率写回存储follower 上的 Provider 必须周期性地从存储拉取最新概率到本地缓存。runUpdateProbabilitiesLoopprovider.go以followerRefreshInterval默认 20 秒为周期刷新并叠加了一个随机抖动addJitter其作用是当 leader 宕机时所有 follower 不会在同一时刻同时去抢锁而是错开时间尝试竞争既缩短了新 leader 的平均选举时间也分散了对存储的读取压力。配置参数详解所有配置项定义在 options.go 中mapstructure标签即为配置键名DefaultOptions()提供了默认值。下表汇总了完整参数配置键类型默认值含义target_samples_per_secondfloat1全局目标采样率每个操作每秒采集的 trace 条数目标delta_tolerancefloat0.3实际吞吐量与目标值的允许偏差比例30%。偏差在容差内就不下发新概率增大该值可降低概率波动calculation_intervalduration1m概率重算周期。例如 1 分钟表示每分钟计算一次每个桶包含 1 分钟的聚合吞吐量aggregation_bucketsint10内存中保留的吞吐量桶总数如计算周期 1 分钟、桶数 3则最多保留 3 个桶calculation_bucketsint1计算加权 QPS 时使用多少个最近的历史桶calculation_delayduration2m概率生成的延迟时间。假设计算周期 1 分钟、桶数 10、延迟 2 分钟则计算基于[now-12m, now-2m]区间的数据。该延迟用于抵消客户端轮询分布客户端在 1 分钟窗口内均匀分布地拉取新概率2 分钟延迟可保证所有客户端都能至少使用 1 分钟的最新概率initial_sampling_probabilityfloat0.001所有新操作的初始采样概率min_sampling_probabilityfloat1e-5所有操作的最小采样概率计算结果被限制在[min_sampling_probability, 1.0]min_samples_per_secondfloat1/60每秒最少采样条数保证低 QPS 操作如每分钟 1 次调用也能被采到至少一条 traceleader_lease_refresh_intervalduration5sleader 持有锁时的租约续期间隔应小于 follower 的间隔以减少锁竞争follower_lease_refresh_intervalduration60sfollower 竞争 leader 锁的间隔存储后端与生产部署形态自适应采样必须依赖一个存储后端来保存观测到的吞吐量数据和计算出的概率。README 明确列出了当前支持的采样存储后端memory用于 all-in-one 单机部署、cassandra、badger、elasticsearch、opensearch。在典型的生产环境中Jaeger 由多个 Collector 组成集群每个 Collector 运行独立的 Aggregator——它们彼此不需要协调只要共享同一存储即可各自聚合自己看到的流量每个 Collector 也运行 Post-aggregator但**只有一个leader**负责合并所有 Aggregator 的输出并生成最终概率其余 follower 仅预加载吞吐量以备接任所有 Collector 上的 Provider 都能向 SDK 提供策略follower 通过周期拉取保证缓存不落后。这种设计让自适应采样具备了水平扩展能力聚合工作天然可分摊到每个 Collector而概率计算则由存储上的分布式锁通过 internal/leaderelection 引入的选举参与者实现保证单点执行、写回不冲突。如何观测运行状态Post-aggregator 会通过 metrics factory 以adaptive_sampling_processor命名空间暴露两类指标见 post_aggregator.goadaptive_sampling_processor.operations_calculatedgauge当前参与概率计算的操作总数adaptive_sampling_processor.calculate_probabilitiestimer单轮概率计算的耗时。Aggregator 侧则暴露sampling_operations与sampling_services两个计数器aggregator.go分别统计刷新到存储的操作总数与涉及的服务数可用于观察流量观测的覆盖面与写入频率。相关源码导航如果你想深入研读实现细节可以按以下路径继续组件实现internal/sampling/samplingstrategy/adaptive/aggregator.go、post_aggregator.go、provider.go配置定义与默认值options.go概率计算器可插拔策略calculationstrategy/percentage_increase_capped_calculator.go 与 calculationstrategy/interface.go辅助设施加权向量缓存 weightvectorcache.go、采样状态缓存 cache.go、浮点工具 floatutils.go测试用例各组件均有同名_test.go测试文件如 aggregator_test.go、post_aggregator_test.go、provider_test.go覆盖了概率计算、leader/follower 行为、新端点启动等关键路径是理解边界行为的绝佳素材小结自适应采样把「按概率采样」升级为「按目标吞吐量采样」通过 Aggregator 观测、Post-aggregator 计算、Provider 下发三阶段闭环加上 leader 选举、加权 QPS、增幅封顶与容差机制实现了对每个服务端点采样率的自动、平滑、可收敛的调节。其核心工程取舍在于用存储换取协调成本、用延迟换取客户端一致性、用概率上下限与增幅封顶换取系统稳定性——理解这三组权衡也就理解了自适应采样设计的精髓。【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jaeger 自适应采样（Adaptive Sampling）深度解析：从吞吐量观测到动态采样概率的计算链路
Jaeger 自适应采样Adaptive Sampling深度解析从吞吐量观测到动态采样概率的计算链路【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger自适应采样是 Jaeger 分布式追踪平台中用于动态控制采集成本的核心机制它不再依赖人工为每个服务设定固定的采样率而是由 Collector 持续观测各服务的真实流量按「服务 端点」维度周期性地重新计算采样概率使最终采集到的 trace 数量始终贴近预设的目标值每秒采样条数。阅读本文后你将掌握自适应采样的整体架构Aggregator / Post-aggregator / Provider 三大组件、概率计算的底层算法、全部配置项及默认值并能结合仓库源码定位到每个环节的具体实现。为什么需要自适应采样传统的固定采样率例如统一 10%存在两个痛点低流量端点可能完全采不到样本一个每秒仅发生 0.1 次调用的接口即使以 10% 的概率采样也需要数分钟甚至更久才能等到一条 trace排障时往往无据可查高流量端点会造成存储浪费对于每秒数千次调用的热点接口10% 的概率可能带来巨大的存储与检索成本而其中绝大多数 trace 价值有限。自适应采样给出的答案是以「目标每秒采样条数」为控制目标而不是以固定的概率为目标。系统通过观测真实流量动态调整每个端点service operation 组合的采样概率让高流量端点降低概率、低流量端点提高概率最终使各端点采集到的 trace 量都收敛到目标值附近。一个重要前提自适应采样本身不采样仓库文档internal/sampling/samplingstrategy/adaptive/README.md特别强调了一个关键设计边界adaptive sampling in Jaeger backenddoes not actually do the sampling. The sampling is performed by OTEL SDKs, and sampling decisions are propagated through trace context.也就是说Jaeger 后端中的自适应采样并不实际决定某个 span 是否被采样。真正的采样动作由应用侧接入的 OTEL SDK 完成采样决策通过 trace contextsampler.type、sampler.param等标签在调用链中传播。Jaeger Collector 端自适应采样的职责是观测流量计算每个服务/端点的真实吞吐量基于吞吐量与目标值动态计算采样概率通过 Jaeger Remote Sampling 协议把概率下发给 SDK由 SDK 按照该概率执行实际的概率采样。三大核心组件与整体工作流从源码结构看自适应采样模块位于 internal/sampling/samplingstrategy/adaptive/由三个相互协作的组件构成组件源码文件运行位置核心职责Aggregatoraggregator.go每个 Collector 实例作为 OTEL Collector 的 trace processor 运行在采集管道中观察经过本实例的所有 span识别 root span 并按 service/operation 聚合计数周期性地把吞吐量throughput写入存储Post-aggregatorpost_aggregator.go每个 Collector 实例但只有 leader 执行完整计算从存储加载所有实例写入的吞吐量并聚合计算出各端点的采样概率与 QPS写回存储Providerprovider.goCollector 的采样策略服务端定期从存储读取最新概率翻译成 Remote Sampling 协议响应供 SDK 轮询/sampling端点获取三者串成一条完整的闭环链路SDK 上报 span → Aggregator 聚合吞吐量 → 写入存储 → Post-aggregatorleader汇总计算概率 → 写回存储 → Provider 读取概率 → SDK 轮询获取新概率 → 按新概率采样 → 产生新的 span。Aggregator吞吐量观测与持久化Aggregator 是采集管道中的一个处理器。在 aggregator.go 的HandleRootSpan中可以看到它的核心逻辑只处理root spanParentSpanID 0。实现注释特别说明仅检查 parentId 判断根 span 并不充分但可以确定只有 root span 会携带采样器标签因此采样器标签成为判断依据读取 span 的sampler.type与sampler.param标签见getSamplerParamsaggregator.gosampler.param支持 float、int 与字符串三种表示统一转换为 float64调用RecordThroughput在内存中按service - operation - Throughput的嵌套 map 累计计数。RecordThroughputaggregator.go有两个值得注意的细节只对概率采样probabilistic的 root span 计数递增对于 lowerbound 采样的 span 不递增但仍然以计数 0 写入吞吐量目的是让后端的自适应采样处理器感知到该端点的存在以便开始为它计算概率同一端点记录的采样概率会去重后最多保留 10 个maxProbabilities 10用于后续判断该端点是否真的在使用自适应采样。聚合后的吞吐量通过runAggregationLoopaggregator.go按CalculationInterval周期性地把当前内存计数批量写入存储storage.InsertThroughput清空内存计数开始下一个周期触发postAggregator.runCalculation()进入概率计算阶段。Post-aggregator真正的“自适应”逻辑Post-aggregator 是负责“自适应”部分的核心它的主要工作分为两个阶段阶段一读取与聚合吞吐量。由于生产环境通常部署多个 Collector 实例每个实例的 Aggregator 都会向共享存储写入各自的吞吐量。Post-aggregator 通过GetThroughput(startTime, endTime)拉取一段时间窗口内所有实例写入的吞吐量由aggregateThroughputpost_aggregator.go按 service/operation 汇总计数并合并概率集合。合并后的结果以「吞吐量桶throughputBucket」的形式放入内存桶的数量上限为AggregationBuckets。阶段二leader 计算概率。为避免多个 Collector 同时计算并写回互相覆盖Post-aggregator 借助存储后端的简单 leader-follower 选举机制Leader执行完整计算——把各桶吞吐量换算成 QPS、加权平均、计算新概率并把概率与 QPS 写回存储InsertProbabilitiesAndQPSFollower同样加载吞吐量并在内存中聚合为随时接替 leader 做好准备但不计算概率、也不写回存储。一旦 leader 实例宕机follower 已持有最新吞吐量数据可以快速接管计算。选举租约的刷新由两个配置控制leader 每LeaderLeaseRefreshInterval默认 5s续租一次follower 每FollowerLeaseRefreshInterval默认 60s尝试竞争一次leader 的续租频率高于 follower 以降低锁竞争避免锁抖动。从吞吐量到概率的四步算法在calculateProbabilitiesAndQPSpost_aggregator.go与calculateProbabilitypost_aggregator.go中概率计算的完整流程如下吞吐量 → QPSthroughputToQPS把每个桶内各端点的计数除以桶的时间间隔count / interval得到每秒请求数参与计算的桶数不超过BucketsForCalculation。加权平均 QPScalculateWeightedQPS对多个桶的 QPS 做加权平均权重向量由 weightvectorcache.go 生成权重公式为w(i) i⁴并归一化越新的桶权重越大最新数据位于切片头部。计算新概率由可插拔的概率计算器完成当前默认实现是PercentageIncreaseCappedCalculator见 calculationstrategy/percentage_increase_capped_calculator.go基础思路是newProbability prevProbability × (targetQPS / curQPS)当curQPS targetQPS需要提高概率时限制单次增幅不超过上一概率的 50%默认 cap 0.5例如概率从 0.1 提升 400% 的请求只能提到 0.15从而防止过采样震荡当curQPS targetQPS需要降低概率时直接跳到目标值快速抑制过采样。边界保护与容差最终概率被夹在[MinSamplingProbability, 1.0]之间math.Min(max, math.Max(min, newProbability))若 QPS 为 0端点突然无流量概率翻倍强制至少采样一个 span 以便感知端点状态withinTolerance使用DeltaTolerance判断实际 QPS 与目标值的偏差是否已“足够接近”abs(actual-expected)/expected DeltaTolerance若是则沿用旧概率、不发送新的控制信号避免概率频繁抖动。此外Post-aggregator 使用一个SamplingCachecache.go记录最近 25 轮serviceCacheSize内每个端点使用的概率与是否启用了自适应采样。isUsingAdaptiveSamplingpost_aggregator.go据此判断一个端点是否真的在用自适应采样若端点当前概率等于InitialSamplingProbability则视为首次出现、默认采用自适应否则检查本轮吞吐量记录的概率集合或上一轮缓存只有确实观察到了匹配的概率值才继续对其实施自适应控制。这样可以把那些使用固定概率采样的端点排除在动态调整之外。新端点如何启动当检测到一个新的服务或端点时README 明确说明它最初以InitialSamplingProbability默认 0.001被采样直到收集到足够的数据来计算与该端点实际流量相匹配的采样率。这个过程由DefaultSamplingProbability与MinSamplesPerSecond共同保证即使端点在初始概率下采不到样本MinSamplesPerSecond默认每分钟 1 条也会兜底确保低流量端点至少能被采集到。Provider把概率翻译成 Remote Sampling 策略Provider 是面向 SDK 的出口。SDK 按固定周期默认每分钟轮询 Jaeger 的/sampling端点Provider 的GetSamplingStrategyprovider.go返回对应服务的采样策略若该服务已有计算好的概率则返回按 operation 区分的概率列表否则返回默认策略概率 InitialSamplingProbability下限 MinSamplesPerSecond。generateStrategyResponsesprovider.go把存储中的ServiceOperationProbabilities翻译为 Jaeger Remote Sampling 协议中的PerOperationSamplingStrategies每条包含 operation 名与对应的ProbabilisticSamplingStrategy.SamplingRate。值得注意的同步机制由于只有 leader 会把概率写回存储follower 上的 Provider 必须周期性地从存储拉取最新概率到本地缓存。runUpdateProbabilitiesLoopprovider.go以followerRefreshInterval默认 20 秒为周期刷新并叠加了一个随机抖动addJitter其作用是当 leader 宕机时所有 follower 不会在同一时刻同时去抢锁而是错开时间尝试竞争既缩短了新 leader 的平均选举时间也分散了对存储的读取压力。配置参数详解所有配置项定义在 options.go 中mapstructure标签即为配置键名DefaultOptions()提供了默认值。下表汇总了完整参数配置键类型默认值含义target_samples_per_secondfloat1全局目标采样率每个操作每秒采集的 trace 条数目标delta_tolerancefloat0.3实际吞吐量与目标值的允许偏差比例30%。偏差在容差内就不下发新概率增大该值可降低概率波动calculation_intervalduration1m概率重算周期。例如 1 分钟表示每分钟计算一次每个桶包含 1 分钟的聚合吞吐量aggregation_bucketsint10内存中保留的吞吐量桶总数如计算周期 1 分钟、桶数 3则最多保留 3 个桶calculation_bucketsint1计算加权 QPS 时使用多少个最近的历史桶calculation_delayduration2m概率生成的延迟时间。假设计算周期 1 分钟、桶数 10、延迟 2 分钟则计算基于[now-12m, now-2m]区间的数据。该延迟用于抵消客户端轮询分布客户端在 1 分钟窗口内均匀分布地拉取新概率2 分钟延迟可保证所有客户端都能至少使用 1 分钟的最新概率initial_sampling_probabilityfloat0.001所有新操作的初始采样概率min_sampling_probabilityfloat1e-5所有操作的最小采样概率计算结果被限制在[min_sampling_probability, 1.0]min_samples_per_secondfloat1/60每秒最少采样条数保证低 QPS 操作如每分钟 1 次调用也能被采到至少一条 traceleader_lease_refresh_intervalduration5sleader 持有锁时的租约续期间隔应小于 follower 的间隔以减少锁竞争follower_lease_refresh_intervalduration60sfollower 竞争 leader 锁的间隔存储后端与生产部署形态自适应采样必须依赖一个存储后端来保存观测到的吞吐量数据和计算出的概率。README 明确列出了当前支持的采样存储后端memory用于 all-in-one 单机部署、cassandra、badger、elasticsearch、opensearch。在典型的生产环境中Jaeger 由多个 Collector 组成集群每个 Collector 运行独立的 Aggregator——它们彼此不需要协调只要共享同一存储即可各自聚合自己看到的流量每个 Collector 也运行 Post-aggregator但**只有一个leader**负责合并所有 Aggregator 的输出并生成最终概率其余 follower 仅预加载吞吐量以备接任所有 Collector 上的 Provider 都能向 SDK 提供策略follower 通过周期拉取保证缓存不落后。这种设计让自适应采样具备了水平扩展能力聚合工作天然可分摊到每个 Collector而概率计算则由存储上的分布式锁通过 internal/leaderelection 引入的选举参与者实现保证单点执行、写回不冲突。如何观测运行状态Post-aggregator 会通过 metrics factory 以adaptive_sampling_processor命名空间暴露两类指标见 post_aggregator.goadaptive_sampling_processor.operations_calculatedgauge当前参与概率计算的操作总数adaptive_sampling_processor.calculate_probabilitiestimer单轮概率计算的耗时。Aggregator 侧则暴露sampling_operations与sampling_services两个计数器aggregator.go分别统计刷新到存储的操作总数与涉及的服务数可用于观察流量观测的覆盖面与写入频率。相关源码导航如果你想深入研读实现细节可以按以下路径继续组件实现internal/sampling/samplingstrategy/adaptive/aggregator.go、post_aggregator.go、provider.go配置定义与默认值options.go概率计算器可插拔策略calculationstrategy/percentage_increase_capped_calculator.go 与 calculationstrategy/interface.go辅助设施加权向量缓存 weightvectorcache.go、采样状态缓存 cache.go、浮点工具 floatutils.go测试用例各组件均有同名_test.go测试文件如 aggregator_test.go、post_aggregator_test.go、provider_test.go覆盖了概率计算、leader/follower 行为、新端点启动等关键路径是理解边界行为的绝佳素材小结自适应采样把「按概率采样」升级为「按目标吞吐量采样」通过 Aggregator 观测、Post-aggregator 计算、Provider 下发三阶段闭环加上 leader 选举、加权 QPS、增幅封顶与容差机制实现了对每个服务端点采样率的自动、平滑、可收敛的调节。其核心工程取舍在于用存储换取协调成本、用延迟换取客户端一致性、用概率上下限与增幅封顶换取系统稳定性——理解这三组权衡也就理解了自适应采样设计的精髓。【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考