Skip to content

Conversation

solnic
Copy link
Collaborator

@solnic solnic commented Jun 4, 2025

This updates OpenTelemetry.Sampler so that it uses traces_sample_rate for sampling spans before they get sent to the span processor.

This way we're not processing spans when they are
dropped during sampling, which was previously the
case as the Client was responsible for sampling
just before attempting to send a transaction.

This is based on:

#skip-changelog

@solnic solnic force-pushed the new-span-sampler branch 4 times, most recently from 5a841bb to 01a7066 Compare June 4, 2025 12:43
@solnic solnic force-pushed the new-span-sampler branch from 8538c0b to af64d0f Compare June 5, 2025 10:43
This updates OpenTelemetry.Sampler so that it uses
`traces_sample_rate` for sampling spans before they
get sent to the span processor.

This way we're not processing spans when they are
dropped during sampling, which was previously the
case as the Client was responsible for sampling
just before attemping to send a transaction.
@solnic solnic force-pushed the new-span-sampler branch from af64d0f to 7e7718f Compare June 5, 2025 10:55
solnic added 3 commits June 5, 2025 12:09
Previously it incorrectly referred to "parent" where
in reality we're dealing with spans from the same
trace and respect sampling decisions that were
already made for a given trace.

This is not the same thing as parent/child spans
that we're handling in the SpanProcessor as this
type of relationship is established post-sampling.
@solnic solnic marked this pull request as ready for review June 5, 2025 13:23
@sl0thentr0py
Copy link
Member

just noting the first change that is necessary, but we can defer this to the future because we don't have trace propagation implemented right now:

  • traces_sample_rate needs to default to nil, because when we do have distributed tracing:
    • traces_sample_rate=0 implies the elixir service will not start new traces but honor incoming sentry-trace headers and will still sample a transaction based on incoming headers
    • traces_sample_rate=nil means there will be no transactions ever, and even incoming headers will be ignored

Copy link
Member

@sl0thentr0py sl0thentr0py left a comment

Choose a reason for hiding this comment

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

just one comment about the client report, rest we can postpone when we implement propagation.

If you want, you can already set the default traces_sample_rate to nil and tweak the logic a bit to account for that

@solnic solnic force-pushed the new-span-sampler branch from 9078ba6 to 3fd1304 Compare June 9, 2025 13:05
@solnic
Copy link
Collaborator Author

solnic commented Jun 9, 2025

If you want, you can already set the default traces_sample_rate to nil and tweak the logic a bit to account for that

I did that here via 3fd1304

@solnic solnic requested a review from sl0thentr0py June 9, 2025 13:05
@solnic solnic requested a review from sl0thentr0py June 10, 2025 12:48
@solnic solnic merged commit d6af772 into span-processor-with-new-sampler Jun 10, 2025
8 checks passed
@solnic solnic deleted the new-span-sampler branch June 10, 2025 13:26
solnic added a commit that referenced this pull request Jun 10, 2025
* Better span sampler

This updates OpenTelemetry.Sampler so that it uses
`traces_sample_rate` for sampling spans before they
get sent to the span processor.

This way we're not processing spans when they are
dropped during sampling, which was previously the
case as the Client was responsible for sampling
just before attemping to send a transaction.

* Enhance sampling logic to record discarded transactions

* Clarify trace-level sampling decision-making

Previously it incorrectly referred to "parent" where
in reality we're dealing with spans from the same
trace and respect sampling decisions that were
already made for a given trace.

This is not the same thing as parent/child spans
that we're handling in the SpanProcessor as this
type of relationship is established post-sampling.

* Remove unnecessary sleep calls in sampler tests

* Fix flaky test

* Clean up make_sampling_decision

* Simplify client reports for dropped transactions

* Update traces_sample_rate default value to be nil

* Account for `nil` sample_rate when sampling

* Use put_test_config

* Update traces_sample_rate spec to allow nil value
solnic added a commit that referenced this pull request Jun 17, 2025
* Revert "Revert "Add SpanProcessor for OpenTelemetry (#875)""

This reverts commit 2ced90e.

* Better span sampler (#903)

* Better span sampler

This updates OpenTelemetry.Sampler so that it uses
`traces_sample_rate` for sampling spans before they
get sent to the span processor.

This way we're not processing spans when they are
dropped during sampling, which was previously the
case as the Client was responsible for sampling
just before attemping to send a transaction.

* Enhance sampling logic to record discarded transactions

* Clarify trace-level sampling decision-making

Previously it incorrectly referred to "parent" where
in reality we're dealing with spans from the same
trace and respect sampling decisions that were
already made for a given trace.

This is not the same thing as parent/child spans
that we're handling in the SpanProcessor as this
type of relationship is established post-sampling.

* Remove unnecessary sleep calls in sampler tests

* Fix flaky test

* Clean up make_sampling_decision

* Simplify client reports for dropped transactions

* Update traces_sample_rate default value to be nil

* Account for `nil` sample_rate when sampling

* Use put_test_config

* Update traces_sample_rate spec to allow nil value

* Support for traces_sampler option (#910)

* Add support for `traces_sampler` config option

* Update docs

* Remove unnecessary attribute merging

* Call traces_sampler only for root spans

* Reuse sampling decision logic

* Add test for handling invalid traces_sampler return values

* Add tests for SamplingContext access functions

* Add basic integration tests for OpenTelemetry (#912)

* Update CHANGELOG
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.

3 participants