Skip to content
This repository was archived by the owner on Aug 14, 2024. It is now read-only.
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 24 additions & 2 deletions src/docs/sdk/performance/dynamic-sampling-context.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -106,6 +106,28 @@ After the DSC of a particular trace has been frozen, API calls like `set_user` o
Dynamic Sampling Context is sent to Sentry via the `trace` envelope header and is propagated to downstream SDKs via a baggage header.

All of the values in the payloads below are required (non-optional) in a sense, that when they are known to an SDK at the time a transaction envelope is sent to Sentry, or at the time a baggage header is propagated, they must also be included in said envelope or baggage.

### Handling Sensitive Data and PII

<Alert level="info">

The currently specified solution is subject to change and will be revisited, once all SDKs implemented a mechanism of controlling where DSC and tracing data should be propagated to.
This mechanism is still up for discussion and implementation but it will be similar to the `tracingOrigins` property that is already used in some SDKs right now.
In the meantime, the solution below should be adopted from all SDKs to handle PII concerns.

</Alert>

It should be noted that DSC holds potentially sensitive data, such as PII, which needs to be handled carefully.

Therefore, the **only exception** to the rule that all available DSC values must be collected at DSC
population time, is the `user_id` field.
To avoid this sensitive information being leaked to third parties, `user_id` should only be added to the DSC, if the <Link to="/sdk/data-handling/#sensitive-data">`send_default_pii`</Link> option was enabled in the SDK's init options.
Note that this only applies for the head-of-trace SDK that populates the DSC content.
In case downstream SDKs receive a `user_id` in incoming DSC, they should continue to propagate it.
The rationale behind this is that incoming DSC [must be frozen](#freezing-dynamic-sampling-context) and users must make DS rules based on the head SDK's DSC data anyway.

#### Strictly required values

In any case, `trace_id`, `public_key`, and `sample_rate` should always be known to an SDK, so these values are strictly required.

### Envelope Header
Expand All @@ -118,7 +140,7 @@ The value of this envelope header is a JSON object with the following fields:
- `sample_rate` (string) - The sample rate as defined by the user on the SDK. This string should always be a number between (and including) 0 and 1 in basic float notation (`0.04242`) - no funky business like exponents or anything similar. If a `tracesSampler` callback was used for the sampling decision, its result should be used for `sample_rate` instead of the `tracesSampleRate` from `SentryOptions`. In case `tracesSampler` returns `True` it should be sent as `1.0`, `False` should be sent as `0.0`.
- `release` (string) - The release name as specified in client options`.
- `environment` (string) - The environment name as specified in client options.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So only sending this in the envelope header if tracingOrigins allows would mean we have to check tracingOrigins against the DSN or proxy to see if we're allowed to send it, correct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you referring to user_id? Could you elaborate what you mean here? Generally, in the context of this PR we're not including tracingOrigins in any way or condition. Just wanted to mention in the description that discussions around it are in the works.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this referred to user_id. Once discussed we could add something to clarify whether we need to check tracingOrigins against DSN / proxy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So currently, the JS SDK's BrowserTracing integration does not check for the DSN (or a proxy) but it only determines if the URL of the outgoing request matches a string or regex specified in tracingOrigins. So far, we haven't considered changing this but sincetracingOrigins is gonna be standardized, we can certainly discuss this. I would suggest though, discussing this in a separate issue about the tracingOrigins spec/changes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For Java we have our own transport(s) for communication with Sentry so we'd have to separately add the check there if we so choose.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tracingOrigins doesn't really matter when determining what is sent to Sentry. tracingOrigins should simply control which targets should receive a) a sentry-trace header b) DSC in a baggage header.

This shouldn't concern transports but rather request instrumentation. I might be wrong though since I don't know specifics on the Java SDK.

- `user_id` (string) - User ID as set by the user with <Link to="/sdk/unified-api/#scope">`scope.set_user`</Link>.
- `user_id` (string) - User ID as set by the user with <Link to="/sdk/unified-api/#scope">`scope.set_user`</Link>. **Only included, if [`send_default_pii`](#handling-sensitive-data-and-pii) is enabled.**
- `user_segment` (string) - User segment as set by the user with <Link to="/sdk/unified-api/#scope">`scope.set_user`</Link>.
- `transaction` (string) - The transaction name set on the scope.

Expand All @@ -133,7 +155,7 @@ SDKs may use the following keys to set entries on `baggage` HTTP headers:
- `sentry-sample_rate`
- `sentry-release`
- `sentry-environment`
- `sentry-user_id`
- `sentry-user_id` - **Only included, if [`send_default_pii`](#handling-sensitive-data-and-pii) is enabled.**
- `sentry-user_segment`
- `sentry-transaction`

Expand Down