Description
(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 forstart_transaction
/start_span
anymore start_span
instead gets an extraattributes
argument which, when provided, prepopulates the attributes- integrations that were providing a
custom_sampling_context
will instead provide a set of prepopulatedattributes
(that can't be objects) - the
sampling_context
accessible intraces_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 Use span attrs in GCP sampling context #3818
- 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:
orcapture_internal_exceptions
)
- see if there's any framework-specific stuff in e.g. the asgi scope (starlette/fastapi adds
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/ Update
custom_sampling_context
docs #3933