Skip to content

Commit 057ab7a

Browse files
authored
Merge branch 'master' into lcian/feat/rust-tracing-docs
2 parents ab9268f + 08b2627 commit 057ab7a

File tree

632 files changed

+15434
-5356
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

632 files changed

+15434
-5356
lines changed

.babelrc.js.bak

Lines changed: 0 additions & 16 deletions
This file was deleted.

.github/workflows/lint-404s.yml

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -32,8 +32,13 @@ jobs:
3232
- uses: actions/cache@v4
3333
id: cache
3434
with:
35-
path: ${{ github.workspace }}/node_modules
35+
path: |
36+
${{ github.workspace }}/node_modules
37+
${{ github.workspace }}/.next/cache
38+
${{ github.workspace }}/.eslintcache
3639
key: node-${{ runner.os }}-${{ hashFiles('**/yarn.lock') }}
40+
restore-keys: |
41+
node-${{ runner.os }}-
3742
3843
- run: yarn install --frozen-lockfile
3944
if: steps.cache.outputs.cache-hit != 'true'

.github/workflows/test.yml

Lines changed: 15 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -29,18 +29,23 @@ jobs:
2929
- uses: actions/cache@v4
3030
id: cache
3131
with:
32-
path: ${{ github.workspace }}/node_modules
32+
path: |
33+
${{ github.workspace }}/node_modules
34+
${{ github.workspace }}/.next/cache
35+
${{ github.workspace }}/.eslintcache
3336
key: node-${{ runner.os }}-${{ hashFiles('**/yarn.lock') }}
37+
restore-keys: |
38+
node-${{ runner.os }}-
39+
3440
- run: yarn install --frozen-lockfile
3541
if: steps.cache.outputs.cache-hit != 'true'
3642

3743
# Additional checks
3844
- run: yarn lint:ts
39-
- run: yarn lint:docs
4045

4146
# Run automatic fixes (run prettier apart from eslint to also fix mdx files)
4247
- run: yarn lint:prettier:fix
43-
- run: yarn lint:eslint:fix
48+
- run: yarn lint:eslint:fix --cache
4449

4550
# Check (and error) for dirty working tree for forks
4651
# Reason being we need a different token to auto commit changes and
@@ -69,8 +74,14 @@ jobs:
6974
- uses: actions/cache@v4
7075
id: cache
7176
with:
72-
path: ${{ github.workspace }}/node_modules
77+
path: |
78+
${{ github.workspace }}/node_modules
79+
${{ github.workspace }}/.next/cache
80+
${{ github.workspace }}/.eslintcache
7381
key: node-${{ runner.os }}-${{ hashFiles('**/yarn.lock') }}
82+
restore-keys: |
83+
node-${{ runner.os }}-
84+
7485
- run: yarn install --frozen-lockfile
7586
if: steps.cache.outputs.cache-hit != 'true'
7687
- name: Run Tests

.gitignore

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -4,9 +4,6 @@ npm-debug.log*
44
yarn-debug.log*
55
yarn-error.log*
66

7-
# Ignore generated export markdown files
8-
/public/md-exports/
9-
107
# Runtime data
118
pids
129
*.pid
@@ -96,6 +93,8 @@ public/page-data
9693
# tsbuildinfo file generated by CI
9794
tsconfig.tsbuildinfo
9895

96+
# Ignore generated files
97+
/public/md-exports/
9998
public/mdx-images/*
10099

101100
# yalc

app/[[...path]]/page.tsx

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -199,10 +199,10 @@ export async function generateMetadata(props: MetadataProps): Promise<Metadata>
199199
? `https://${process.env.VERCEL_URL}`
200200
: domain;
201201
let title =
202-
'Sentry Docs | Application Performance Monitoring &amp; Error Tracking Software';
202+
'Sentry Docs | Application Performance Monitoring & Error Tracking Software';
203203
let customCanonicalTag: string = '';
204204
let description =
205-
'Self-hosted and cloud-based application performance monitoring &amp; error tracking that helps software teams see clearer, solve quicker, &amp; learn continuously.';
205+
'Self-hosted and cloud-based application performance monitoring & error tracking that helps software teams see clearer, solve quicker, and learn continuously.';
206206
// show og image on the home page only
207207
const images =
208208
((await props.params).path ?? []).length === 0

app/globals.css

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -165,3 +165,18 @@ body {
165165
{
166166
color: rgb(134, 142, 150) !important;
167167
}
168+
169+
/* CSS Counters for Onboarding Steps */
170+
.onboarding-steps {
171+
counter-reset: onboarding-step;
172+
}
173+
174+
.onboarding-step {
175+
counter-increment: onboarding-step;
176+
}
177+
178+
.onboarding-step .step-heading::before,
179+
.onboarding-step h2::before {
180+
content: "Step " counter(onboarding-step) ": ";
181+
font-weight: inherit;
182+
}

app/sitemap.ts

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ import {getDevDocsFrontMatter, getDocsFrontMatter} from 'sentry-docs/mdx';
55

66
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
77
if (isDeveloperDocs) {
8-
const docs = getDevDocsFrontMatter();
8+
const docs = await getDevDocsFrontMatter();
99
const baseUrl = 'https://develop.sentry.dev';
1010
return docsToSitemap(docs, baseUrl);
1111
}

bin/lint-docs.ts

Lines changed: 0 additions & 6 deletions
This file was deleted.

develop-docs/application-architecture/dynamic-sampling/architecture.mdx

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -52,6 +52,18 @@ An example of rule encoded in JSON is the following:
5252
}
5353
```
5454

55+
<Alert title="✨ Note">
56+
Dynamic sampling rules must always include a `condition` field, otherwise the entire dynamic sampling ruleset will be ignored by Relay. If you want a rule to match every event, set the condition as follows:
57+
```json
58+
{
59+
"condition": {
60+
"inner": [],
61+
"op": "and"
62+
}
63+
}
64+
```
65+
</Alert>
66+
5567
#### Fetching the Sampling Configuration
5668

5769
The sampling configuration is fetched by Relay from Sentry in a pull fashion. This is done by sending a request to the `/api/0/relays/projectconfigs/` endpoint periodically (defined [here](https://github.com/getsentry/sentry/blob/master/src/sentry/api/endpoints/relay/project_configs.py#L34-L34)).

develop-docs/application-architecture/dynamic-sampling/fidelity-and-biases.mdx

Lines changed: 9 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -71,33 +71,28 @@ Transaction Sampling **does not guarantee complete traces** and instead **applie
7171

7272
## Biases for Sampling
7373

74-
A bias is a set of one or more rules that are evaluated for each event. More specifically, when we define a bias, we want to achieve a specific objective, which **can be expressed as a set of rules**. You learn more about rules on the architecture page [here](/dynamic-sampling/architecture/).
74+
Dynamic Sampling uses biases to adjust how many events matching certain conditions are sampled. These biases are defined as a set of rules that Relay checks for each event. Learn more about these rules [on the architecture page](/dynamic-sampling/architecture/).
7575

76-
Sentry has already defined a set of biases that are available to all customers. These biases have different goals, but they can be combined to express more complex semantics.
77-
78-
Some of the biases defined by Sentry can be enabled or disabled in the UI, more specifically under **Project Settings -> Performance**, while others are enabled by default and cannot be disabled.
79-
80-
An example of how the UI looks is shown in the following screenshot (the content of this screenshot is subject to change):
76+
Sentry defines a set of biases that are available to all customers. Some of the biases defined by Sentry can be enabled or disabled in the UI under **Project Settings -> Performance**, while others are enabled by default and cannot be disabled. See this example of the UI (the content of this screenshot is subject to change):
8177

8278
![Biases in the UI](./images/biasesUI.png)
8379

8480

8581

8682
### Prioritize New Releases
8783

88-
This bias is used to prioritize traces that are coming from a new release. The goal is to increase the sample rate in the time window that occurs between the creation of a release and its adoption by users. _The identification of a new release is done in the `event_manager` defined [here](https://github.com/getsentry/sentry/blob/43d7c41aee2b22ca9f51916afac40f6cbdcd2b15/src/sentry/event_manager.py#L739-L773)._
84+
This bias is used to prioritize traces that come from a new release. The goal is to increase the sample rate in the time window between the creation of a release and its adoption by users. _New releases are identified in the `event_manager` defined [here](https://github.com/getsentry/sentry/blob/43d7c41aee2b22ca9f51916afac40f6cbdcd2b15/src/sentry/event_manager.py#L739-L773)._
8985

90-
Since the adoption of a release is not constant, we created a system of _decaying_ rules which can interpolate between two sample rates in a given time window with a given function (e.g. `linear`). The idea being that we want to reduce the sample rate since the amount of samples will increase as the release gets adopted by users.
86+
Because release adoption varies over time, a system of _decaying_ rules interpolates between two sample rates within a specified time window and using a specified interpolation function (e.g. `linear`). The sample rate is gradually lowered as user adoption increases and the volume of samples grows.
9187

9288
![Sample Rate and Adoption](./images/sampleRateAndAdoption.png)
9389

94-
The latest release bias uses a decaying rule to interpolate between a starting sample rate and an ending sample rate over a time window that is statically defined for each platform (the list of time to adoptions is define [here](https://github.com/getsentry/sentry/blob/9b98be6b97323a78809a829e06dcbef26a16365c/src/sentry/dynamic_sampling/rules/helpers/time_to_adoptions.py#L25). For example, Android has a bigger time window than JavaScript because on average Android apps take more time to get adopted by users.
90+
The latest release bias uses a decaying rule to interpolate between a starting and ending sample rate over a time window that is statically defined for each platform. The list of adoption times is defined [here](https://github.com/getsentry/sentry/blob/9b98be6b97323a78809a829e06dcbef26a16365c/src/sentry/dynamic_sampling/rules/helpers/time_to_adoptions.py#L25). For example, Android has a longer time window than JavaScript because Android apps generally take more time to be adopted by users.
9591

9692
### Prioritize Dev Environments
9793

98-
This bias is used to prioritize traces coming from a development environment in order to increase the amount of data retained for such environments, since they are more likely to be useful for debugging.
94+
This bias increases the sampling rate for traces from development environments, since this data is often more valuable for debugging. Sentry identifies development environments using a regularly maintained and updated list of known environment patterns. For these environments, the sample rate is set to 100%, so all traces are sampled.
9995

100-
To mark a trace's root transaction as belonging to a development environment, we leverage a list of known development environments, which is maintained and updated regularly by Sentry.
10196

10297
```python
10398
ENVIRONMENT_GLOBS = [
@@ -112,19 +107,18 @@ ENVIRONMENT_GLOBS = [
112107

113108
The list of development environments is available [here](https://github.com/getsentry/sentry/blob/4cb0d863de1ef8e3440153cb440eaca8025dee0d/src/sentry/dynamic_sampling/rules/biases/boost_environments_bias.py#L7).
114109

115-
For prioritizing dev environments, we use a sample rate of `1.0` (100%), which results in all traces being sampled.
116110

117111
### Prioritize Low Volume Projects
118112
<Alert title="✨ Note">
119113
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.
120114
</Alert>
121115

122-
The algorithm used in this bias computes a new sample rate with the goal of prioritizing low-volume projects, which can be drowned out by high-volume projects. The mechanism used for prioritizing is similar to the low-volume transactions bias in which given the sample rate of the organization and the counts of each project, it computes a new sample rate for each project, assuming an ideal distribution of the counts. The sample rate of the boost low volume projects bias is computed using an algorithm that leverages a dynamic sample rate obtained by measuring the incoming volume of transactions in a sliding time window, known as the target fidelity rate. This rate is obtained by calling, at fixed intervals, the `get_sampling_tier_for_volume` function (defined [here](https://github.com/getsentry/sentry/blob/f3a2220ccd3a2118a1255a4c96a9ec2010dab0d8/src/sentry/quotas/base.py#L481)).
116+
This bias uses an algorithm to increase the sample rate for low-volume projects, which might otherwise be overshadowed by high-volume projects. It calculates a new sample rate for each project based on the organization’s overall sample rate and the number of transactions each project receives, aiming for a more balanced distribution. The algorithm dynamically adjusts these rates by measuring _the volume of incoming transactions over a sliding time window_ (also known as the target fidelity rate). At regular intervals, the system calls the `get_sampling_tier_for_volume` function (defined [here](https://github.com/getsentry/sentry/blob/f3a2220ccd3a2118a1255a4c96a9ec2010dab0d8/src/sentry/quotas/base.py#L481)) to determine the appropriate sample rate for each project.
123117

124118

125119

126120
### Prioritize Low Volume Transactions
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.
121+
Different transactions have different volumes, and 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 transaction considered for rebalancing will be the root transaction of the trace.
128122

129123
Prioritization of low volume transactions works slightly differently depending on the dynamic sampling mode:
130124
- 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.
@@ -140,9 +134,7 @@ The algorithms for boosting low volume events are run periodically (with cron jo
140134

141135
### Deprioritize Health Checks
142136

143-
This bias is used to de-prioritize transactions that are classified as health checks. The goal is to reduce the amount of data retained for health checks, since they are not very useful for debugging.
144-
145-
In order to mark a transaction as a health check, we leverage a list of known health check endpoints, which is maintained by Sentry and updated regularly.
137+
This bias reduces the sampling rate for transactions identified as health checks, since these transactions typically provide little value for debugging. Sentry maintains and regularly updates a list of known health check endpoints to identify such transactions and deprioritize them accordingly.
146138

147139
```python
148140
HEALTH_CHECK_GLOBS = [

0 commit comments

Comments
 (0)