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: docs/organization/dynamic-sampling/index.mdx
+137Lines changed: 137 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,3 +37,140 @@ Please note that these Dynamic Sampling modes are only available for customers o
37
37
Dynamic Sampling is different from the sampling that you can configure in the Sentry SDKs. The SDK sampling rate is applied before events are sent to Sentry, while Dynamic Sampling is applied after events are received by Sentry. This means that Dynamic Sampling can be used to adjust the sample rate for events that have already been sent to Sentry and only take into account the volume of events that have been received by Sentry.
38
38
39
39
Also in contrast to the Dynamic Sampling, the SDK sample rate is never dynamically adjusted.
40
+
41
+
## Retention Priorities
42
+
43
+
44
+
45
+
<Note>
46
+
47
+
Retention priorities are only available on the latest version of our plans, starting from 1M reserved transactions. Anyone in your org with owner or billing-level permissions can update your plan by going to Settings > Subscription, and clicking the "Manage Subscription" button.
48
+
49
+
</Note>
50
+
51
+
While storing all your data makes sense at relatively low volumes, as your application scales, storing a raw copy of all your data has diminishing returns. When data reaches high volumes, Sentry begins to automatically prioritize retaining certain transactions over others with server-side data retention strategies called retention priorities.
52
+
53
+
It's important to note that even when we begin to only store the most valuable data based on retention priorities, the [performance metrics](/product/performance/metrics/) you see are still based on **all** the events you send to Sentry. This ensures that you get a full and complete view of your application's health.
Below is a list of the transactions we prioritize and deprioritize. They are enabled by default, but can be updated on a per-project basis to better fit your organization's needs.
76
+
77
+
### Prioritized Transactions
78
+
79
+
Sentry automatically prioritizes and retains the following types of transactions:
80
+
81
+
#### Latest Release
82
+
83
+
Latest releases are a retention priority because when you create a new release, we assume you'll want to have more visibility during the early adoption phase, which improves your ability to catch new issues as your release is gaining traction.
84
+
Because you may want to deploy the same release in different environments, we'll also take your environment into account and prioritize those transactions.
85
+
86
+
#### Dev Environments
87
+
88
+
Since dev environments usually generate a small number of transactions as compared to prod environments, we prioritize them during your testing phase so you can get meaningful insights. We consider an environment to be a dev environment if its name matches one of the following glob pattterns:
89
+
90
+
-`*debug*`
91
+
-`*dev*`
92
+
-`*local*`
93
+
-`*qa*`
94
+
-`*test*`
95
+
96
+
#### Low Volume Projects
97
+
98
+
<Note>
99
+
100
+
You won't be able to disable the Low Volume Projects retention priority because it's set on an organization-wide level, not on a per-project basis.
101
+
102
+
</Note>
103
+
104
+
Some projects within your organization are very high volume compared to others. This means that low-volume projects might get drowned out if we treat all projects equally. To ensure that you have enough samples regardless of project scale, we prioritize low-volume projects.
105
+
106
+
#### Low Volume Transactions
107
+
108
+
Transactions can be logically grouped by their name within a project. This means that transactions with the same name most likely indicate the same operation or code path, while transactions with different names usually indicate different operations.
109
+
We prioritize low-volume transactions for the same reason we prioritize low-volume projects – so they don't get drowned out by high-volume transactions. We want to make sure that transactions representing low-volume code paths are sampled in enough quantities to generate a complete view of your application.
110
+
111
+
### Investigation Mode
112
+
113
+
Our automated retention priorities work well in a generic manner to collect a baseline of samples because they prioritize retaining data that is valuable for any customer at any given time. However, there are certain scenarios, such as investigating a particular issue, when very specific data becomes temporarily more important. In such cases, sometimes the automated sampling priorities do not provide enough samples, so you may want to create investigation rules.
114
+
115
+
Investigation rules are sampling rules that can be created through the Sentry UI to temporarily boost the number of transactions collected for a particular scenario (for example, transactions with specific tag values). These rules can be created to retain more samples when too few (less than 5) are available. Once created, a rule will be active for up to 48 hours or until 100 samples are collected. You'll be notified via email when enough transactions have been collected.
116
+
117
+
Investigation sampling rules only apply to transactions and don't guarantee that full traces will be sampled. The maximum number of sampling rules that can exist at the same time is 50.
118
+
119
+
#### Creating a New Investigation Rule
120
+
121
+
When you perform a query on transactions either in [Discover](/product/explore/discover-queries/) or in [Transaction Summary](/product/performance/transaction-summary/) and receive fewer than 5 samples, you can click "Get Samples" to create a new investigation rule to retain more samples of transactions for the respective query.
122
+
123
+
124
+
125
+
<Note>
126
+
127
+
Please note that this feature only applies to transactions. Therefore, in Discover, you have to specify `event.type:transaction` in the query to access the feature, whereas in Performance the event type is implicit.
128
+
129
+
</Note>
130
+
131
+
Clicking this button triggers the creation of an investigation rule for the respective query. After the successful creation of the rule, a notification will appear and the button for creating the investigation rule will be replaced by a message specifying that the investigation is in progress and the amount of time since it has been active.
If a user performs the same search later and the investigation is still active, the notification will indicate that there is an active rule collecting data for the query.
136
+
137
+
Creating a rule is also possible from the Transaction Summary page in Performance.
138
+
139
+
140
+
141
+
142
+
### Deprioritized Transactions
143
+
144
+
Sentry automatically deprioritizes the following transactions:
145
+
146
+
#### Health Checks
147
+
148
+
We deprioritize health check type transactions because while they're important for checking the stability of your application, they don't have any value beyond the task associated with them. We consider a transaction to be a health check if its name matches one of the following glob patterns:
149
+
150
+
-`*healthcheck*`
151
+
-`*heartbeat*`
152
+
-`*/health`
153
+
-`*/healthy`
154
+
-`*/healthz`
155
+
-`*/live`
156
+
-`*/livez`
157
+
-`*/ready`
158
+
-`*/readyz`
159
+
-`*/ping`
160
+
161
+
### How to Change Retention Priorities
162
+
163
+
To make changes to a project's retention priorities in Sentry, go to **Settings > Projects**, select the project you're interested in, then scroll down to "Performance" in the "PROCESSING" section and make any updates under "RETENTION PRIORITIES" using the toggles. Each of your projects can have an individual set of retention priorities.
To give Sentry the fullest, most accurate picture of your application’s health, we recommend that you send us 100% of your transactions. You can do this by setting your [tracesSampleRate](/platform-redirect/?next=/performance/) to 1.0. If this isn't feasible for your organization, set a lower value, or switch to sampling selectively by using the [tracesSampler](/platform-redirect/?next=/performance/) to filter your transactions based on contextual data. Note that when calculating throughput, transaction metering is based on received transactions not stored transactions.
170
+
171
+
<Note>
172
+
Please note that changes to your SDK sampling configuration may affect your
173
+
quota. If you increase your SDK sampling rate, you'll also be increasing the
174
+
volume of transactions you send to Sentry. This may require that you adjust
0 commit comments