Rework sampling_context

[sentrivana]

(custom_)sampling_context is a Sentry-specific concept that doesn't fit with how OTel works.

The purpose of a sampling_context is to provide extra external data to use for decision making in the traces_sampler. Right now, we're using it to make things like the transaction name, parent sampled decision, request object or queue name accessible in the sampler.

The goal is to store everything necessary on the span as attributes instead and expose those. However, since attribute types are very limited, we can't just save a custom object like e.g. the request as an attribute. Instead, we need to preprocess it into serializable attributes. For each integration, we need to see what important data we can extract and save on the span.

The idea:

• no custom_sampling_context argument for start_transaction/start_span anymore
• start_span instead gets an extra attributes argument which, when provided, prepopulates the attributes
• integrations that were providing a custom_sampling_context will instead provide a set of prepopulated attributes (that can't be objects)
• the sampling_context accessible in traces_sampler will change:
  • it'll contain all span attributes by default
  • it'll also contain the current data (transaction_context.name, transaction_context.op, parent_sampled) in some slightly modified form

Integrations that are currently setting a custom_sampling_context that will now have to set specific attributes:

• aiohttp Extract span attrs from AIOHTTP request #3782
• asgi Unpack custom_sampling_context into attributes in ASGI #3764 & Use semantic attributes in traces sampler for ASGI spans #3774
• aws_lambda Span attrs instead of AWS custom sampling context #3814
• celery Turn custom_sampling_context into span attrs in Celery integration #3813
• gcp
• rq Extract span attrs from RQ job object & fix tests #3786
• tornado Extract span attrs from Tornado request #3784
• wsgi Unpack WSGI environ into span attrs accessible in traces sampler #3775
• extra
  • see if there's any framework-specific stuff in e.g. the asgi scope (starlette/fastapi adds endpoint, for instance), and add if possible
  • seen in the wild: wsgi_environ.REQUEST_URI, wsgi_environ.HTTP_ headers stuff
  • consider serializing args and kwargs (mostly celery, rq) always in the same way (i.e., not via _serialize_span_attributes) so that the type doesn't randomly change on users
  • error handling (except: or capture_internal_exceptions)

Related:

• Allow to pass attributes to POTelSpan Remove custom_sampling_context #3747
• Document this properly in the migration guide for each integration
• Change documentation https://docs.sentry.io/platforms/python/configuration/sampling/

[antonpirker]

This is a user facing feature: https://docs.sentry.io/platforms/python/configuration/sampling/

So we need to update the docs too if we remove it and also have it in the migration guide