Sentry + Tracing

[HazAT]

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
see: https://docs.sentry.io/platforms/javascript/?platform=browser#adding-integration-from-sentryintegrations

Sentry.init({
  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:

feat: Tracing setup

[buffcode]

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!
Laurens

[bruno-garcia]

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.

[HazAT]

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.

[buffcode]

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.

[cjerdonek]

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?

[HazAT]

Hey,

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.
http://getsentry.github.io/sentry-javascript/classes/hub.span.html

[cjerdonek]

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?

[HazAT]

The header might change very soon 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.

[bruno-garcia]

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?

[cjerdonek]

Sorry, I meant to reply to this earlier.

@bruno-garcia

Do you mean to set the trace id or the span id?

I guess just the trace id.

@bruno-garcia

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?

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 - https://www.youtube.com/watch?v=-6Hk9rcgM94&t=7m30s - 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).

[will-cap]

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

  <script src="https://browser.sentry-cdn.com/5.3.1/bundle.min.js" crossorigin="anonymous"></script>
  <script src="https://browser.sentry-cdn.com/5.3.1/tracing.min.js" crossorigin="anonymous"></script>

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

Tracing Demo - 5.3.1/tracing.min.js

@HazAT is awesome

[sacharya]

This is really amazing stuff and would love to use this with the Java SDK. What is the current status of the tracing capability, @HazAT? And/or is there a newer/better way to do cross-service request tracing?

[HazAT]

The plan is to gradually roll out support for other SDKs over time. We want to make sure the overall experience is good before we support all SDKs. But rest assured, once we are confident enough that the “APM” story in Sentry is good enough, Java is high on our list for SDKs to support this.

[jesper]

Would love to implement this, but it looks like the tracing integration has been moved to the APM package @HazAT? Is the automatic tracing still working? If so - are there any additional steps required to get the error tracing up and running for JS Browser and server running express after the move?

[HazAT]

Hey, yes it still works.
Please see this post for the latest info on how to use APM

Sentry's APM Docs [Alpha]

THIS POST IS OUTDATED, please visit https://docs.sentry.io/performance/distributed-tracing/

Outdated

Sentry’s APM (Application Performance Management) features provide users with a view of the general health of their system. The APM tools will give insight on an application’s performance bottleneck, even when there aren’t errors. Our initial rollout of APM includes our Python SDK. If you have version >= 0.14.2 the APM features are available to you. <a name="getting-started-python-1…

[pjmrrk]

@HazAT: I am using React js in frontend and Koa as backend. Using same dns for both of them… But I don’t see spans child created for spans and also db query detail??