You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: develop-docs/application-architecture/dynamic-sampling/architecture.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -133,7 +133,7 @@ In this case, the matching will happen from **top to bottom** and the following
133
133
1. Rule `1` is matched against the event payload, since it is of type `transaction`. The `samplingValue` is a `factor`, thus the accumulated factors will now be `2.0 * 1.0`, where `1.0` is the identity for the multiplication.
134
134
2. Because rule `1` was a factor rule, the matching continues and rule `2` will be matched against the DSC, since it is of type `trace`. The `samplingValue` is a `sampleRate`, thus the matching will stop and the sample rate will be computed as `2.0 * 0.5 = 1.0`, where `2.0` is the factor accumulated from the previous rule and `0.5` is the sample rate of the current rule.
135
135
136
-
<Alerttitle="✨ Note"level="info">
136
+
<Alerttitle="✨ Note">
137
137
138
138
It is important to note that a `sampleRate` rule must match in order for a sampling decision to be made; in case this condition is not met, the event will be kept. In practice, each project will have a uniform trace rule which will always match and contain the base sample rate of the organization.
Copy file name to clipboardExpand all lines: develop-docs/application-architecture/dynamic-sampling/fidelity-and-biases.mdx
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ sidebar_order: 2
5
5
6
6
Dynamic Sampling allows Sentry to automatically adjust the amount of data retained based on how valuable the data is to the user. This is technically achieved by applying a **sample rate** to every event, which is determined by a **set of rules** that are evaluated for each event.
7
7
8
-
<Alerttitle="✨ Note"level="info">
8
+
<Alerttitle="✨ Note">
9
9
10
10
A sample rate is a number in the interval `[0.0, 1.0]` that will determine the likelihood of a transaction to be retained. For example, a sample rate of `0.5` means that the transaction will be retained on average 50% of the time.
11
11
@@ -21,15 +21,15 @@ There are two available modes to govern the target sample rates for Dynamic Samp
21
21
-**Automatic Mode** dynamically manages the target sample rate for each project based on the target sample rate for the organization, prioritizing lower volume projects to increase visibility. Automatic Mode is active if the organization option `sentry:sampling_mode` is set to `organization`. The target sample rate for the organization is stored in the **organization** option `sentry:target_sample_rate`, and project target sample rates are calculated based on the organization target sample rate.
22
22
-**Manual Mode** allows the user to set static target sample rates on a per-project basis that serve as the baseline sample rate before applying the dynamic biases outlined below. Target sample rates are not adjusted by the system. Manual Mode is active if the organization option `sentry:sampling_mode` is set to `project`. The target sample rates for projects are stored in the **project** option `sentry:target_sample_rate`.
23
23
24
-
All functionality defaults to Automatic Mode if the option `sentry:sampling_mode` is not set, and all target sample rates default to 1 if the option `sentry:target_sample_rate` is not set.
24
+
All functionality defaults to Automatic Mode if the option `sentry:sampling_mode` is not set, and all target sample rates default to 1 if the option `sentry:target_sample_rate` is not set.
25
25
26
26
When the user switches between modes, target sample rates are transferred unless changed explicitly. For example, if the user switches from Automatic Mode to Manual Mode, the sample rates calculated during Automatic Mode are persisted in the project option `sentry:target_sample_rate`. Conversely, if the user switches from Manual Mode to Automatic Mode, the project target sample rates are recalculated based on the overall organization target sample rate.
27
27
28
-
The [sample rates are periodically recalibrated](https://github.com/getsentry/sentry/blob/9b98be6b97323a78809a829e06dcbef26a16365c/src/sentry/dynamic_sampling/rules/biases/recalibration_bias.py#L11-L44) to ensure that the overall target sample rate is met. This recalibration is done on a project level or organization level, depending on the dynamic sampling mode. Within the target sample rate, Dynamic Sampling **biases towards more meaningful data**. This is achieved by constantly updating and communicating special rules to Relay, via a project configuration, which then applies targeted sampling to every event.
28
+
The [sample rates are periodically recalibrated](https://github.com/getsentry/sentry/blob/9b98be6b97323a78809a829e06dcbef26a16365c/src/sentry/dynamic_sampling/rules/biases/recalibration_bias.py#L11-L44) to ensure that the overall target sample rate is met. This recalibration is done on a project level or organization level, depending on the dynamic sampling mode. Within the target sample rate, Dynamic Sampling **biases towards more meaningful data**. This is achieved by constantly updating and communicating special rules to Relay, via a project configuration, which then applies targeted sampling to every event.
29
29
30
30
31
31
32
-
<Alerttitle="✨ Note"level="info">
32
+
<Alerttitle="✨ Note">
33
33
For orgs under AM2, Dynamic sampling uses a [sliding window function](https://github.com/getsentry/sentry/blob/cc8cc38c8a108719d068e5622b24a8d0c744e84c/src/sentry/dynamic_sampling/tasks/sliding_window_org.py#L37-L61) over the incoming volume to calculate the target sample rate.
34
34
</Alert>
35
35
@@ -39,7 +39,7 @@ It is important to note that fidelity only determines an **approximate target sa
39
39
40
40
Instead, the Sentry backend **computes a set of rules** whose goal is to cooperatively achieve the target sample rate. Determining when and how to set these rules is part of the Dynamic Sampling infrastructure.
41
41
42
-
<Alerttitle="✨ Note"level="info">
42
+
<Alerttitle="✨ Note">
43
43
44
44
The effectively applied sample rate, in the end, depends on how much data matches each of the bias overrides.
45
45
@@ -59,7 +59,7 @@ To achieve trace sampling, SDKs pass all fields that can be sampled by [Dynamic
59
59
60
60
61
61
62
-
<Alerttitle="✨ Note"level="info">
62
+
<Alerttitle="✨ Note">
63
63
64
64
In order to achieve full trace sampling, the random number generator used by Relay is seeded with the trace ID inside of the DSC sent by the SDK. This ensures that traces with the same trace ID will always yield the same sampling decision.
65
65
@@ -115,7 +115,7 @@ The list of development environments is available [here](https://github.com/gets
115
115
For prioritizing dev environments, we use a sample rate of `1.0` (100%), which results in all traces being sampled.
116
116
117
117
### Prioritize Low Volume Projects
118
-
<Alerttitle="✨ Note"level="info">
118
+
<Alerttitle="✨ Note">
119
119
This bias is only active in Automatic Mode (and not in Manual Mode). It applies to any incoming trace and is defined on a per-project basis.
120
120
</Alert>
121
121
@@ -126,13 +126,13 @@ The algorithm used in this bias computes a new sample rate with the goal of prio
126
126
### Prioritize Low Volume Transactions
127
127
This bias is used to prioritize low-volume transactions that can be drowned out by high-volume transactions. The goal is to rebalance sample rates of the individual transactions so that low-volume transactions are more likely to have representative samples. The bias is of type trace, which means that the transaction considered for rebalancing will be the root transaction of the trace.
128
128
129
-
Prioritization of low volume transactions works slightly differently depending on the dynamic sampling mode:
130
-
- In **Automatic Mode** (`sentry:sampling_mode` == `organization`), the output of the [boost_low_volume_projects](https://github.com/getsentry/sentry/blob/dee539472e999bf590cfc4e99b9b12981963defb/src/sentry/dynamic_sampling/tasks/boost_low_volume_transactions.py#L183) task is used as the base sample rate for the balancing algorithm.
129
+
Prioritization of low volume transactions works slightly differently depending on the dynamic sampling mode:
130
+
- In **Automatic Mode** (`sentry:sampling_mode` == `organization`), the output of the [boost_low_volume_projects](https://github.com/getsentry/sentry/blob/dee539472e999bf590cfc4e99b9b12981963defb/src/sentry/dynamic_sampling/tasks/boost_low_volume_transactions.py#L183) task is used as the base sample rate for the balancing algorithm.
131
131
- In **Manual Mode** (`sentry:sampling_mode` == `project`), the project target sample rate is used as the base sample rate for the balancing algorithm.
132
132
133
-
In order to rebalance transactions, the system retrieves the counts of the transactions for each project and calculates a new sample rate for each transaction.
133
+
In order to rebalance transactions, the system retrieves the counts of the transactions for each project and calculates a new sample rate for each transaction.
134
134
135
-
<Alerttitle="✨ Note"level="info">
135
+
<Alerttitle="✨ Note">
136
136
137
137
The algorithms for boosting low volume events are run periodically (with cron jobs) with a sliding window to account for changes in the incoming volume.
Copy file name to clipboardExpand all lines: develop-docs/application-architecture/dynamic-sampling/the-big-picture.mdx
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ sidebar_order: 1
7
7
8
8
9
9
10
-
<Alerttitle="💡 Note"level="info">
10
+
<Alerttitle="💡 Note">
11
11
12
12
Dynamic Sampling currently operates on either spans or transactions to measure data throughput. This is controlled by the feature flag `organizations:dynamic-sampling-spans` and usually set to what the organization's subscription is metered by. In development, this currently defaults to transactions.
13
13
The logic between the two data categories is identical, so most of this documentation is kept at a generic level and important differences are pointed out explicitly.
@@ -27,7 +27,7 @@ When events arrive, in a simplified model, they go through the following steps:
27
27
4.**Dynamic Sampling**: based on an internal set of rules, Relay determines a sample rate for every incoming event. A random number generator finally decides whether a payload should be kept or dropped.
28
28
5.**Rate limiting**: events that are sampled by Dynamic Sampling will be stored and indexed. To protect the infrastructure, internal rate limits apply at this point. Under normal operation, this **rate limit is never reached** since dynamic sampling already reduces the volume of events stored.
29
29
30
-
<Alerttitle="💡 Example"level="info">
30
+
<Alerttitle="💡 Example">
31
31
32
32
A client is sending 1000 events per second to Sentry:
33
33
1. 100 events per second are from old browsers and get dropped through an inbound data filter.
@@ -44,7 +44,7 @@ The ingestion pipeline has two kinds of rate limits that behave differently com
44
44
1.**High-level request limits on load balancers**: these limits do not differentiate which data is sent by clients and drop requests as soon as the throughput from clients reaches the limit.
45
45
2.**Specific limits per data category in Relay**: these limits apply once requests have been parsed and have gone through basic handling (see [Sequencing](#sequencing) above).
46
46
47
-
<Alerttitle="✨️ Note"level="info">
47
+
<Alerttitle="✨️ Note">
48
48
49
49
There is a dedicated rate limit for stored events after inbound filters and dynamic sampling. However, it does not affect total events since the fidelity decreases with higher total event volumes and this rate limit is not expected to trigger since Dynamic Sampling already reduces the stored event throughput.
50
50
@@ -56,7 +56,7 @@ Dynamic sampling ensures complete traces by retaining all events associated with
56
56
57
57
Despite dynamic sampling providing trace completeness, events or other items (errors, replays, ...) may still be missing from a trace when rate limiting drops one or more of them. Rate limiting drops items without regard for the trace, making each decision independently and potentially resulting in broken traces.
58
58
59
-
<Alerttitle="💡 Example"level="info">
59
+
<Alerttitle="💡 Example">
60
60
61
61
For example, if there is a trace from `Project A` to `Project B` and `Project B` is subject to rate limiting or quota enforcement, events of `Project B` from the trace initiated by `Project A` are lost.
62
62
@@ -84,7 +84,7 @@ Each of these metrics can be filtered and grouped by a number of predefined tags
84
84
85
85
For more granular queries, **stored events are needed**. _The purpose of dynamic sampling here is to ensure that there are always sufficient representative sample events._
86
86
87
-
<Alerttitle="💡 Example"level="info">
87
+
<Alerttitle="💡 Example">
88
88
89
89
If Sentry applies a 1% dynamic sample rate, you can still receive accurate events per minute (SPM or TPM, depending on event type) and web vital quantiles through total event data backed by metrics. There is also a listing of each of these numbers by the transaction.
Copy file name to clipboardExpand all lines: develop-docs/application-architecture/multi-region-deployment/control-silo.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ Prior to our multi-region offering, all API traffic from customers would be sent
15
15
- DSN host
16
16
- A static list of URL names (region pin list)
17
17
18
-
<Alertlevel="info">
18
+
<Alert>
19
19
💡 Requests going to sentry.io do not meet data residency requirements. Customers will need to use region domains in order to not have requests go to the US.
0 commit comments