feat(tracing) [DSC] Dynamic Sampling Context continuation

[smeubank]

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?

baggage header

• sentry-trace_id
• sentry-public_key
• sentry-sample_rate
• sentry-release
• sentry-environment
• sentry-user_id
• sentry-user_segment
• sentry-transaction

Traces Envelope Header

• 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.

Dynamic Sampling Context

Original PR for full context
Add spec for Dynamic Sampling Context #613

[Jean85]

Is baggage a somehow standardized header? Or are we risking name collision?

[smeubank]

baggage is standardized from the W3C spec, and then we further defined it based on our interpretation and usage of the spec

[smeubank]

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

[stayallive]

@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!

[smeubank]

within this issue we will handle adding source to transaction names: in dev docs: Transaction Payloads - Transaction Annotations