Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Pass parentSampleRate to tracesSampler #15024

Merged
merged 53 commits into from
Jan 22, 2025

Conversation

lforst
Copy link
Member

@lforst lforst commented Jan 15, 2025

Ref: #14932
Ref: getsentry/team-sdks#117

This PR mainly does 2 things:

  • Pick up the sample_rate from the DSC and pass it to the tracesSampler as parentSampleRate
  • "Unfreeze" or rather set the sample_rate for a DSC of a given span whenever we applied a sample rate to the span's root span. The sample_rate is equivalent to the sample rate the root span has been sampled with. This is to ensure that downstream services can reliably use the sample_rate in the DSC to pass it to the tracesSampler - like we do in this PR (kinda closing the loop).

Copy link
Contributor

github-actions bot commented Jan 15, 2025

size-limit report 📦

Path Size % Change Change
@sentry/browser 23.01 KB +0.14% +31 B 🔺
@sentry/browser - with treeshaking flags 22.9 KB +0.13% +30 B 🔺
@sentry/browser (incl. Tracing) 35.74 KB +0.17% +61 B 🔺
@sentry/browser (incl. Tracing, Replay) 72.53 KB +0.09% +61 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags 66.09 KB +0.1% +64 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas) 76.78 KB +0.09% +64 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback) 88.8 KB +0.08% +70 B 🔺
@sentry/browser (incl. Feedback) 39.22 KB +0.08% +32 B 🔺
@sentry/browser (incl. sendFeedback) 27.64 KB +0.1% +27 B 🔺
@sentry/browser (incl. FeedbackAsync) 32.4 KB +0.1% +33 B 🔺
@sentry/react 25.69 KB +0.12% +31 B 🔺
@sentry/react (incl. Tracing) 38.52 KB +0.16% +61 B 🔺
@sentry/vue 27.1 KB +0.22% +60 B 🔺
@sentry/vue (incl. Tracing) 37.49 KB +0.15% +56 B 🔺
@sentry/svelte 23.14 KB +0.14% +32 B 🔺
CDN Bundle 24.4 KB +0.15% +35 B 🔺
CDN Bundle (incl. Tracing) 36.04 KB +0.14% +49 B 🔺
CDN Bundle (incl. Tracing, Replay) 70.66 KB +0.03% +18 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) 75.82 KB +0.04% +29 B 🔺
CDN Bundle - uncompressed 71.25 KB +0.13% +94 B 🔺
CDN Bundle (incl. Tracing) - uncompressed 106.95 KB +0.13% +137 B 🔺
CDN Bundle (incl. Tracing, Replay) - uncompressed 217.8 KB +0.07% +137 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed 230.33 KB +0.06% +137 B 🔺
@sentry/nextjs (client) 38.63 KB +0.16% +60 B 🔺
@sentry/sveltekit (client) 36.27 KB +0.17% +62 B 🔺
@sentry/node 156.28 KB +0.07% +111 B 🔺
@sentry/node - without tracing 97.37 KB +0.06% +53 B 🔺
@sentry/aws-serverless 106.83 KB +0.09% +97 B 🔺

View base workflow run

Copy link

codecov bot commented Jan 15, 2025

❌ 2 Tests Failed:

Tests completed Failed Passed Skipped
691 2 689 297
View the top 2 failed tests by shortest run time
propagation.test.ts Propagates trace for outgoing http requests
Stack Traces | 0.089s run time
propagation.test.ts:6:5 Propagates trace for outgoing http requests
events.test.ts Event emitter
Stack Traces | 0.175s run time
events.test.ts:4:5 Event emitter

To view more test analytics, go to the Test Analytics Dashboard
📢 Thoughts on this report? Let us know!

spans.forEach(span => {
delete span.data[SEMANTIC_ATTRIBUTE_SENTRY_CUSTOM_SPAN_NAME];
delete span.data[SEMANTIC_ATTRIBUTE_SENTRY_OVERRIDE_TRACE_SAMPLE_RATE];
span.data && delete span.data[SEMANTIC_ATTRIBUTE_SENTRY_CUSTOM_SPAN_NAME];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can drop this check (span.data &&), as span data is not optional anymore? 🤔


// This attribute is important for internal logic but should not leak into actual data
// eslint-disable-next-line @typescript-eslint/no-dynamic-delete
delete spanJson.data[SEMANTIC_ATTRIBUTE_SENTRY_OVERRIDE_TRACE_SAMPLE_RATE];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm no strong feelings, but can we move this somewhere else than here? E.g. into sentrySpan (where we already delete the name attribute) and/or the span exporter (where we already clear some data that we do not want to send)? These feel like more correct places for this than the envelope, which should rather just send what it gets, IMHO.

Copy link
Member Author

@lforst lforst Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put this here because there is no other really generic flow that runs for standalone spans. This is basically one-of logic. We already delete it in sentrySpan, but sentrySpan doesn't run for standalones, neither does the span exporter in browser. Do you have any other concrete ideas?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could also just delete the line. We also seem to be sending other garbage attributes through standalones.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, I see 🤔 you decide, it feels a bit "weird" to do this in envelope serialization step, but also OK to me!

Copy link
Member Author

@lforst lforst Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know. For the lack of better placement I'll leave it. Removing it wouldn't be great since we'd just end up forgetting to do so. It's super easy to refactor once we flesh out standalone spans.


// For core implementation, we freeze the DSC onto the span as a non-enumerable property
const frozenDsc = (rootSpan as SpanWithMaybeDsc)[FROZEN_DSC_FIELD];
if (frozenDsc) {
return frozenDsc;
return applyTraceSampleRateOverrideToDsc(frozenDsc);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this not be on the frozen DSC already in this scenario?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is effectively what this change is about. The sample_rate becomes "unfrozen" in certain situations so no matter what the dsc may be, the sample rate that was applied to the root span wins.

const traceStateDsc = traceState?.get('sentry.dsc');

// If the span has a DSC, we want it to take precedence
const dscOnTraceState = traceStateDsc && baggageHeaderToDynamicSamplingContext(traceStateDsc);

if (dscOnTraceState) {
return dscOnTraceState;
return applyTraceSampleRateOverrideToDsc(dscOnTraceState);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this not already on the frozen dsc from the trace state here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because for example when the sample rate returned from a tracesSampler is different than on the incoming DSC. The sample rate returned from the tracesSampler wins.

}: {
decision: SamplingDecision | undefined;
context: Context;
spanAttributes: SpanAttributes;
sampleRand?: number;
sampleRateOverride?: number;
Copy link
Member

@mydea mydea Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is just the naming, but I am confused. This sounds to me as if we are overriding the used sample rate for this sampling decision? But if I read the comment below, I guess it means "propagate this sample rate to downstream spans"? Is this a correct interpretation? 😅

Copy link
Member Author

@lforst lforst Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well here we are in wrapSamplingDecision, meaning that the sampling decision was already made. In this context, it kinda means what you wrote: Override the sampling decision on the DSC for everything downstream with this value, no matter what the DSC had as a sample_rate before. Do you have any suggestions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed it to shouldUpdateSampleRateOnDownstreamTrace for now.

@lforst lforst requested a review from mydea January 20, 2025 13:18
@lforst
Copy link
Member Author

lforst commented Jan 21, 2025

image

@lforst lforst merged commit 5021a58 into develop Jan 22, 2025
149 checks passed
@lforst lforst deleted the lforst-parent-sampling-decision branch January 22, 2025 08:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants