In Explore, count(span.duration) aggregated per trace shows extreme spikes with extrapolation enabled — single traces reporting tens to hundreds of thousands of spans — that don't match real traffic. Disabling extrapolation for the same query and time window returns normal-looking counts.
The magnitude doesn't reconcile with the standard 1 / (client_sample_rate × server_sample_rate) extrapolation weighting. Sampled spans pulled from the affected traces/window had client_sample_rate: 0.85 with server_sample_rate values of 0.17393316971887673 and 0.19332399029978814, giving combined effective rates of ~0.148 and ~0.164 (extrapolation weights of only ~6–7x). That multiplier cannot explain aggregate jumps from a small number of real spans to counts like 250,694 or 85,461 for a single trace — no sampled span with a rate anywhere near the ~0.0001–0.001 range needed to produce that magnitude of extrapolation was found.
- Example outlier traces (from
count(span.duration) aggregated by trace, extrapolation on): 4ab991e4d77c40fca64b84f68e18a443 (250,694), b1df1b3f0e7d44ae81f7bccf467ea380 (85,461), 2e4e6869916c4073988ccb31245c1907 (250,000), 7624a7e22e474c0caa6db4face514baf (238,194) — all far above typical per-trace counts (single/low-hundreds) in the same window.
- Toggling extrapolation off for the same query/window returns counts consistent with real traffic.
Possibly related: #117021 (extrapolation/accuracy-mode toggle parity for dashboards), #89266 (usage mode for span consumption tracking) — neither covers this specific reliability/calculation gap.
via Daniel Shec.
--
View Junior Session in Sentry
In Explore,
count(span.duration)aggregated per trace shows extreme spikes with extrapolation enabled — single traces reporting tens to hundreds of thousands of spans — that don't match real traffic. Disabling extrapolation for the same query and time window returns normal-looking counts.The magnitude doesn't reconcile with the standard
1 / (client_sample_rate × server_sample_rate)extrapolation weighting. Sampled spans pulled from the affected traces/window hadclient_sample_rate: 0.85withserver_sample_ratevalues of0.17393316971887673and0.19332399029978814, giving combined effective rates of ~0.148 and ~0.164 (extrapolation weights of only ~6–7x). That multiplier cannot explain aggregate jumps from a small number of real spans to counts like 250,694 or 85,461 for a single trace — no sampled span with a rate anywhere near the ~0.0001–0.001 range needed to produce that magnitude of extrapolation was found.count(span.duration)aggregated by trace, extrapolation on):4ab991e4d77c40fca64b84f68e18a443(250,694),b1df1b3f0e7d44ae81f7bccf467ea380(85,461),2e4e6869916c4073988ccb31245c1907(250,000),7624a7e22e474c0caa6db4face514baf(238,194) — all far above typical per-trace counts (single/low-hundreds) in the same window.Possibly related: #117021 (extrapolation/accuracy-mode toggle parity for dashboards), #89266 (usage mode for span consumption tracking) — neither covers this specific reliability/calculation gap.
via Daniel Shec.
--
View Junior Session in Sentry