Sentry + Tracing


Our latest version of our JS SDKs
(@sentry/browser >= 5.2, @sentry/node >= 5.2) and sentry-python >= 0.7.13 now come with a Tracing integration.

What is tracing?
Our first version of tracing is there to correlate errors between different platforms. So for example you are using our JS SDK in the frontend and the Python SDK in the backend. With that we are able to tell that the frontend error was caused by a specific error on the backend.

We already use it ourself and in the following screenshot you are able to see that a query was causing and 500 internal server error that was calso causing and frontend error. This information can be really valuable.

What do I need to do to get this?
So this is on purpose not fully documented yet since we will ship more features + depending on the feedback we get things might change. Also the story/UX in Sentry itself is nearly not finished we are working on that. Right now only tags will be emitted to match these issues.

As mentioned before, you need to have SDKs up and running that support tracing. Then in JS you need to use the Tracing integration which is contained in @sentry/integrations

  dsn: "YOUR DSN",
  integrations: [
    new Tracing(),

With that we instrument all outgoing XHR / fetch requests.

Make sure to have the counterpart on the server setup, if you have a node server running our express handlers it should already work.

Using Python? If you’re using one of our web framework integrations it will automatically work with no additional configuration.

If you read this far it’s already amazing and we would like to get your opinion about this. Support for the other SDKs will come once things stabilize.

Here are the corresponding PRs integrating this into Sentry:

pinned globally #2

I don’t quite get the Tracing feature. From your screenshot it just looks like two integrations using the same DSN.

At least from your screenshot I can‘t see an automatic correlation between the frontend/backend errors.

Could you please give some in depth details on the Tracing feature?

Thanks in advance!


You are right they use the same DSN but note the filter on the right hand side. The issues also have the same trace ID. The sdks automatically correlate the events.


Sorry if this wasn’t clear enough.

So on the screenshot you can see multiple issues that all have the same trace (see content of the search field).
When using the tracing integration we emit a “trace” tag which can be used to search for issues that belong to the same trace (across different projects / platforms). That way you are able to tell for example if your backend caused a frontend error.


Thanks for the clarification @HazAT @bruno-garcia!
I was so focused on the highlighted area that I missed the search filter.

Looks promising and with some UI iterations this could give significant insight into errors trails.


Does / will this feature support–

  1. Accessing the tracing id used by Sentry for inclusion in one’s own (non-Sentry) logs, and
  2. Setting your own tracing id instead of using one generated by Sentry?


So regarding 1.
This depends on your setup, if you log all incoming headers you will see the trace_id but we are not logging anything anywhere by default.

Regarding 2.
Yes, you can do it now like (this may change in the future, that’s why it’s not documented yet):

import * as Sentry from '@sentry/browser';
import { Span } from '@sentry/hub';

Sentry.configureScope(scope => {
  scope.setSpan(new Span('YOUR TRACE ID'));

Be aware that the trace_id needs to be a a uuid4 lowercase without dashes.


Okay, thanks! So we can grab the trace information from the headers (assuming those header names remain the same). Also, what is the difference between the span_id and the trace_id? How should they each be thought of / which should be of interest to users?


The header might change very soon :expressionless: to it’s final form. So please be aware of that.

trace_id can be seen as something similar to a session_id, all spans that are in a trace have the same trace_id. A span_id uniquely identifies a span which can be seen as an action during a trace.


Do you mean to set the trace id or the span id?
The trace id could have been defined already by the caller in which case you can’t control.

Could you please describe a bit your scenario, besides logging Sentry’s trace/span ids? And what format would you be expecting to have for your ids?


Sorry, I meant to reply to this earlier.

I guess just the trace id.

The use case is simply to include the trace id in log messages, e.g. as discussed in this recent talk at PyCon 2019 (US) (Alex Landau - Building a Culture of Observability - - direct link to portion of talk mentioning trace id’s), and have it match what Sentry uses.

Two cases that can come up that are related to this are: (1) maybe you want to start logging before Sentry has chosen a trace id, which is the case where you might yourself want to set the trace id that Sentry should use, and (2) if you cross a service boundary where you’re not using Sentry, and come back, you’d want to be able to link that back to Sentry and have Sentry resume picking that up. Hence it would be good to know what headers, etc. one should use to let Sentry know.

Any easily generated format should be fine (e.g. UUID).


If you need the Tracing integration through a CDN delivery, you can do:

  <script src="" crossorigin="anonymous"></script>
  <script src="" crossorigin="anonymous"></script>

      integrations: [
        new Sentry.Integrations.Tracing({ tracingOrigins: ['localhost', /^\//] } )

@HazAT is awesome