getsentry
feat(tracing) [DSC] Dynamic Sampling Context continuation
Describe the idea
As a server side platform PHP applications instrumented with the Sentry SDK should continue to propagate dynamic sampling context data to all outgoing requests.
The SDK should extract Dynamic Sampling Context from incoming requests, and propagating DSC to downstream SDKs.
Requirement:
When a PHP application receives a request which has baggage attached with sentry values, It shall propagate those same value in further outgoing requests so that contextual data is preserved across the continuation of trace
what should be sent?
- [ ] sentry-trace_id
- [ ] sentry-public_key
- [ ] sentry-sample_rate
- [ ] sentry-release
- [ ] sentry-environment
- [ ] sentry-user_id
- [ ] sentry-user_segment
- [ ] sentry-transaction
- [ ] trace_id (string)
- [ ] public_key (string)
- [ ] sample_rate (string)
- [ ] release (string)
- [ ] environment (string)
- [ ] user_id (string)
- [ ] user_segment (string)
- [ ] transaction (string)
where should it be sent?
- in dynamic sample context (by baggage header)
- in the envelope header
- meta data (was/is being done in JS to be check if still necessary)
Example:
Here is an example from the Sentry UI, where the implementation has already begun on the latest versions of the JS SDK. A request from the front end to a down stream applications includes in the request header baggage
Why do you think it's beneficial to most of the users
This ensures that further downstream applications connected in a distributed trace will contain all contextual data required for dynamically sampling based on upon the contextual data from the head of the trace.
Possible implementation
Implementation has already begun (at the time of this creation) on JS and Android. Refer to the SDK Developer documentation for further information
For full up to date requirements according to SDK Developer specifications please see the associated documentation.
Original PR for full context Add spec for Dynamic Sampling Context #613
baggage is standardized from the W3C spec, and then we further defined it based on our interpretation and usage of the spec
Hi @stayallive ,
any chance you could take a look at this one? it's been done on JS, and in progress on Python and mobile SDKs, then ruby and PHP are the next we'd like to cover.
We can have a sync with @Lms24 and @sl0thentr0py about the implementation on JS and Python respectively
@smeubank yes I will take a look at this, let me read in on it a bit and get back to you if I have any questions!
within this issue we will handle adding source to transaction names: in dev docs: Transaction Payloads - Transaction Annotations