fix(sampling): ensure agent based sampling is not reset after forking and on tracer.configure

[mabdinur]

Builds on 7fbdc9f

• Fix: Avoids reinitializing the SpanAggregator on tracer.configure(...) and when an application forks. Instead SpanAggregator.reset() is called. This operation ensures global configurations are re-applied, trace buffer can be reset, and trace writer is recreated. This ensures agent based sampling rules are not reset.

• Clean up

  • Removes writer parameter from SpanAggregator.__init__(...) with this change the intialization of the global writer is an implementation detail of the SpanAggregator. There is no longer a need to supply the SpanAggregator with a writer on the initialization of the global tracer.
  • Moves all implementation details of resetting the SpanAggregator from Tracer.configure(...) and Tracer._recreate(...) to SpanAggregator.reset(...).
  • Removes the initialization of the SpanAggregator from _default_span_processors_factory. With this change the global tracer's SpanAggregator is never re-created. It's only modified when tracer.configure(..) is used.
  • Rename DatadogSampler._service_based_samplers property to DatadogSampler._agent_based_sampler to improve clarity. These sampling rules are no longer supplied via environment variables or a programatic api, they can only be set by the Datadog Agent.
  • Splits SpanAggregator.trace_proccessors into two properties SpanAggregator.dd_proccessors and SpanAggregator.user_processors. SpanAggregator.users_proccessors is set after application startup via Tracer.configure(..) while SpanAggregator.dd_proccessors is internal to the ddtrace library and should only be set by ddtrace components. This separation allows us to avoid recreating all trace processors when tracer.configure() is called.

• Adds a more descriptive release note to an unreleased fix.

Checklist

• PR author has checked that all the criteria below are met
• The PR description includes an overview of the change
• The PR description articulates the motivation for the change
• The change includes tests OR the PR description describes a testing strategy
• The PR description notes risks associated with the change, if any
• Newly-added code is easy to change
• The change follows the library release note guidelines
• The change includes or references documentation updates if necessary
• Backport labels are set (if applicable)

Reviewer Checklist

• Reviewer has checked that all the criteria below are met
• Title is accurate
• All changes are related to the pull request's stated goal
• Avoids breaking API changes
• Testing strategy adequately addresses listed risks
• Newly-added code is easy to change
• Release note makes sense to a user of the library
• If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
• Backport labels are set in a manner that is consistent with the release branch maintenance policy

[github-actions]

CODEOWNERS have been resolved as:

releasenotes/notes/fix-agent-based-sampling-8877694a37053e51.yaml       @DataDog/apm-python
ddtrace/_trace/processor/__init__.py                                    @DataDog/apm-sdk-api-python
ddtrace/_trace/sampler.py                                               @DataDog/apm-sdk-api-python
ddtrace/_trace/tracer.py                                                @DataDog/apm-sdk-api-python
ddtrace/internal/ci_visibility/recorder.py                              @DataDog/ci-app-libraries
ddtrace/internal/writer/writer.py                                       @DataDog/apm-core-python
ddtrace/opentracer/tracer.py                                            @DataDog/apm-sdk-api-python
tests/ci_visibility/test_ci_visibility.py                               @DataDog/ci-app-libraries
tests/integration/test_priority_sampling.py                             @DataDog/apm-sdk-api-python
tests/tracer/test_processors.py                                         @DataDog/apm-sdk-api-python
tests/tracer/test_sampler.py                                            @DataDog/apm-sdk-api-python
tests/tracer/test_writer.py                                             @DataDog/apm-sdk-api-python
tests/utils.py                                                          @DataDog/python-guild

[github-actions]

Bootstrap import analysis

Comparison of import times between this PR and base.

Summary

The average import time from this PR is: 279 ± 3 ms.

The average import time from base is: 283 ± 3 ms.

The import time difference between this PR and base is: -3.6 ± 0.1 ms.

Import time breakdown

The following import paths have grown:

ddtrace.auto 0.224 ms (0.08%)

ddtrace 0.162 ms (0.06%)

ddtrace.trace 0.162 ms (0.06%)

ddtrace._trace.tracer 0.104 ms (0.04%)

ddtrace.internal.schema.processor 0.104 ms (0.04%)

ddtrace._trace.filters 0.059 ms (0.02%)

ddtrace._trace.processor 0.059 ms (0.02%)

ddtrace._trace.sampler 0.023 ms (0.01%)

ddtrace.bootstrap.sitecustomize 0.062 ms (0.02%)

ddtrace.bootstrap.preload 0.062 ms (0.02%)

ddtrace.internal.products 0.062 ms (0.02%)

importlib.metadata 0.062 ms (0.02%)

importlib.metadata._collections 0.062 ms (0.02%)

The following import paths have shrunk:

ddtrace.auto 2.296 ms (0.82%)

ddtrace.bootstrap.sitecustomize 1.476 ms (0.53%)

ddtrace.bootstrap.preload 1.476 ms (0.53%)

ddtrace.internal.remoteconfig.client 0.692 ms (0.25%)

ddtrace.internal.products 0.062 ms (0.02%)

importlib.metadata 0.062 ms (0.02%)

importlib.metadata._itertools 0.062 ms (0.02%)

ddtrace 0.820 ms (0.29%)

ddtrace.trace 0.140 ms (0.05%)

ddtrace._trace.tracer 0.140 ms (0.05%)

ddtrace.settings.peer_service 0.106 ms (0.04%)

ddtrace.internal._unpatched 0.032 ms (0.01%)

json 0.032 ms (0.01%)

json.decoder 0.032 ms (0.01%)

re 0.032 ms (0.01%)

enum 0.032 ms (0.01%)

types 0.032 ms (0.01%)

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-06-23 19:30:16

Comparing candidate commit 7f6185d in PR branch munir/cleanup-agent-based-sampling-fix with baseline commit d49390c in branch main.

Found 0 performance improvements and 1 performance regressions! Performance is the same for 560 metrics, 3 unstable metrics.

scenario:iastaspectsospath-ospathsplit_aspect

• 🟥 execution_time [+827.082ns; +899.715ns] or [+17.114%; +18.617%]

[brettlangdon]

would be nice to have a regression test for this, otherwise lgtm

[emmettbutler]

Nice work. Is there a test for how this works in subprocesses that I'm missing?