Skip to content

Simplifying Trace Propagation Examples; Adding origin callout. #13148

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
codyde merged 4 commits into from
Mar 31, 2025
Merged

Simplifying Trace Propagation Examples; Adding origin callout. #13148

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
ceaaf51
Removing propagation endpoint, clarifying text
codyde Mar 28, 2025
5a00274
Adding trace propagation callout for localhost
codyde Mar 28, 2025
cebdcfa
Correcting language for trace prop example
codyde Mar 28, 2025
5cc6ae2
Updating clarification on the tracePropagation configuration.
codyde Mar 31, 2025
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
16 changes: 11 additions & 5 deletions platform-includes/distributed-tracing/how-to-use/javascript.astro.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,14 @@ If you're using our Astro SDK, distributed tracing will work out of the box for

When you are interacting with other external API systems, you might have to define `tracePropagationTargets` to get around possible [Browser CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) issues.

<Alert>

Note: port numbers are relevant for trace propagation and the origin. You may need to configure the `tracePropagationTargets` to ensure that traces are propagated across your services if they run on different ports.

For example, if you have a Node.js backend running locally on port 3000, that destination (`http://localhost:3000`) should be added to the `tracePropagationTargets` array on your frontend to ensure that CORS doesn't restrict the propagation of traces.

</Alert>

```javascript
// sentry.client.config.js
Sentry.init({
Expand All @@ -26,19 +34,17 @@ Sentry.init({
tracesSampleRate: 1.0,
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
"https://auth.myecommerce.com"
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down
10 changes: 4 additions & 6 deletions platform-includes/distributed-tracing/how-to-use/javascript.cloudflare.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ The Sentry Cloudflare SDK has out of the box support for distributed tracing if

### Custom Instrumentation

If you don't want to use tracing, you can set up <PlatformLink to="/tracing/trace-propagation/custom-instrumentation/">Custom Instrumentation</PlatformLink> for distributed tracing.
If you don't want to use the default tracing setup, you can set up <PlatformLink to="/tracing/trace-propagation/custom-instrumentation/">Custom Instrumentation</PlatformLink> for distributed tracing.

### Disabling Distributed Tracing

Expand All @@ -29,19 +29,17 @@ Sentry.init({
tracesSampleRate: 1.0,
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
"https://auth.myecommerce.com"
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down
14 changes: 10 additions & 4 deletions platform-includes/distributed-tracing/how-to-use/javascript.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,14 @@ If you're using the current version of our JavaScript SDK and have enabled the `

To get around possible [Browser CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) issues, define your `tracePropagationTargets`.

<Alert>

Note: port numbers are relevant for trace propagation and the origin. You may need to configure the `tracePropagationTargets` to ensure that traces are propagated across your services if they run on different ports.

For example, if you have a Node.js backend running locally on port 3000, that destination (`http://localhost:3000`) should be added to the `tracePropagationTargets` array on your frontend to ensure that CORS doesn't restrict the propagation of traces.

</Alert>

```javascript
Sentry.init({
dsn: "___PUBLIC_DSN___",
Expand Down Expand Up @@ -46,18 +54,16 @@ Sentry.init({
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down
14 changes: 10 additions & 4 deletions platform-includes/distributed-tracing/how-to-use/javascript.nextjs.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,14 @@ If you're using the current version of our Next.js SDK, distributed tracing will

For client-side, when you are interacting with other external API systems, you might have to define `tracePropagationTargets` to get around possible [Browser CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) issues.

<Alert>

Note: port numbers are relevant for trace propagation and the origin. You may need to configure the `tracePropagationTargets` to ensure that traces are propagated across your services if they run on different ports.

For example, if you have a Node.js backend running locally on port 3000, that destination (`http://localhost:3000`) should be added to the `tracePropagationTargets` array on your frontend to ensure that CORS doesn't restrict the propagation of traces.

</Alert>

```javascript
// sentry.client.config.js
Sentry.init({
Expand All @@ -25,18 +33,16 @@ Sentry.init({
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down
16 changes: 11 additions & 5 deletions platform-includes/distributed-tracing/how-to-use/javascript.node.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,17 @@ Sentry.init({
});
```

<Alert>

Note: port numbers are relevant for trace propagation and the origin. You may need to configure the `tracePropagationTargets` to ensure that traces are propagated across your services if they run on different ports.

For example, if you have a Node.js backend running locally on port 3000, that destination (`http://localhost:3000`) should be added to the `tracePropagationTargets` array on your frontend to ensure that CORS doesn't restrict the propagation of traces.

</Alert>

### Custom Instrumentation

If you don't want to use tracing, you can set up <PlatformLink to="/tracing/trace-propagation/custom-instrumentation/">Custom Instrumentation</PlatformLink> for distributed tracing.
If you don't want to use the default tracing setup, you can set up <PlatformLink to="/tracing/trace-propagation/custom-instrumentation/">Custom Instrumentation</PlatformLink> for distributed tracing.

#### Example 1: Microservices E-commerce Platform

Expand All @@ -20,18 +28,16 @@ Sentry.init({
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down
14 changes: 10 additions & 4 deletions platform-includes/distributed-tracing/how-to-use/javascript.nuxt.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,14 @@ If you're using the current version of our Nuxt SDK, distributed tracing will wo

To get around possible [Browser CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) issues, you should define `tracePropagationTargets` for client-side.

<Alert>

Note: port numbers are relevant for trace propagation and the origin. You may need to configure the `tracePropagationTargets` to ensure that traces are propagated across your services if they run on different ports.

For example, if you have a Node.js backend running locally on port 3000, that destination (`http://localhost:3000`) should be added to the `tracePropagationTargets` array on your frontend to ensure that CORS doesn't restrict the propagation of traces.

</Alert>

```javascript {filename:sentry.client.config.(js|ts)}
Sentry.init({
dsn: "___PUBLIC_DSN___",
Expand All @@ -21,18 +29,16 @@ Sentry.init({
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down
14 changes: 10 additions & 4 deletions platform-includes/distributed-tracing/how-to-use/javascript.remix.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,14 @@ The `name` attributes must be the strings `"sentry-trace"` and `"baggage"` and t

To get around possible [Browser CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) issues, you should define `tracePropagationTargets` on the client side. See <PlatformLink to="/tracing/trace-propagation/dealing-with-cors-issues/">Dealing with CORS Issues</PlatformLink> for more information.

<Alert>

Note: port numbers are relevant for trace propagation and the origin. You may need to configure the `tracePropagationTargets` to ensure that traces are propagated across your services if they run on different ports.

For example, if you have a Node.js backend running locally on port 3000, that destination (`http://localhost:3000`) should be added to the `tracePropagationTargets` array on your frontend to ensure that CORS doesn't restrict the propagation of traces.

</Alert>

```javascript
// entry.client.tsx
Sentry.init({
Expand All @@ -58,18 +66,16 @@ Sentry.init({
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down
14 changes: 10 additions & 4 deletions platform-includes/distributed-tracing/how-to-use/javascript.solidstart.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,14 @@ export default defineConfig({

To get around possible [Browser CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) issues, you should define `tracePropagationTargets` for client-side.

<Alert>

Note: port numbers are relevant for trace propagation and the origin. You may need to configure the `tracePropagationTargets` to ensure that traces are propagated across your services if they run on different ports.

For example, if you have a Node.js backend running locally on port 3000, that destination (`http://localhost:3000`) should be added to the `tracePropagationTargets` array on your frontend to ensure that CORS doesn't restrict the propagation of traces.

</Alert>

```javascript
// hooks.client.js
Sentry.init({
Expand All @@ -52,18 +60,16 @@ Sentry.init({
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down
14 changes: 10 additions & 4 deletions platform-includes/distributed-tracing/how-to-use/javascript.sveltekit.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,14 @@ If you're using the current version of our SvelteKit SDK, distributed tracing wi

When you are interacting with other external API systems, you might have to define `tracePropagationTargets` to get around possible [Browser CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) issues.

<Alert>
Copy link
Contributor

@coolguyzone coolguyzone Mar 28, 2025

Choose a reason for hiding this comment

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

It seems like this 'Alert' block is being used in several places with identical content, it's probably worth creating an include to simplify the maintenance of this content. This can totally be done in a follow-up PR if you want to merge this first.

Copy link
Contributor Author

@codyde codyde Mar 29, 2025

Choose a reason for hiding this comment

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

Yeah, definitely. Ill refactor it to include it short term, just to keep things clean, before merging.


Note: port numbers are relevant for trace propagation and the origin. You may need to configure the `tracePropagationTargets` to ensure that traces are propagated across your services if they run on different ports.

For example, if you have a Node.js backend running locally on port 3000, that destination (`http://localhost:3000`) should be added to the `tracePropagationTargets` array on your frontend to ensure that CORS doesn't restrict the propagation of traces.

</Alert>

```javascript
// hooks.client.js
Sentry.init({
Expand Down Expand Up @@ -29,18 +37,16 @@ Sentry.init({
tracePropagationTargets: [
"https://api.myecommerce.com",
"https://auth.myecommerce.com",
/^\/internal-api\//
],
});
```

This tells Sentry to track user journeys across three places:
This tells Sentry to pass trace headers across the following paths:

* Your main API server (where product data comes from)
* Your authentication server (where logins happen)
* Any API calls that start with "/internal-api/" on your current domain

This way, if a customer experiences an error during checkout, you can see the complete path their request took across these different services.
This way, if a customer experiences an error during checkout, or you want to check the performance of a specific endpoint, you can see the complete path their request took across these different services.

#### Example 2: Mobile App with Backend Services

Expand Down