Automatic Instrumentation

The Sentry SDK provides a BrowserTracing integration to add automatic instrumentation for monitoring the performance of browser applications.

What Our Instrumentation Provides

The BrowserTracing integration creates a new transaction for each page load and navigation event, and creates a child span for every XMLHttpRequest or fetch request that occurs while those transactions are open. Learn more about traces, transactions, and spans.

Enable Instrumentation

The Ember add-on automatically adds the

tracingThe process of logging the events that took place during a request, often across multiple services.
integration for you with additional routing details by hooking into your application's router. If you are not seeing transactions appear, you may need change the configuration passed to Ember's default tracing integration. The options for the default integration can be passed by using browserTracingOptions.

After configuration, you will see both pageload and navigation transactions in sentry.io.

Copied
import * as Sentry from "@sentry/ember";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",

  // We recommend adjusting this value in production, or using tracesSampler
  // for finer control
  tracesSampleRate: 1.0,

  // Configuration for Ember's default tracing integration.
  browserTracingOptions: {
    tracePropagationTargets: ["localhost", "my-site-url.com", /^\//],
  },
});

Configuration Options

Supported options:

tracePropagationTargets

A list of strings and regular expressions. The JavaScript SDK will attach the sentry-trace and baggage headers to all outgoing XHR/fetch requests whose destination contains a string in the list or matches a regex in the list. If your frontend is making requests to a different domain, you'll need to add it there to propagate the sentry-trace and baggage headers to the backend services, which is required to link transactions together as part of a single trace.

The tracePropagationTargets option matches the entire request URL, not just the domain. Using stricter regex to match certain parts of the URL ensures that requests don't unnecessarily have additional headers attached.

The default value of tracePropagationTargets is ['localhost', /^\//]. This means that by default,

tracingThe process of logging the events that took place during a request, often across multiple services.
headers are only attached to requests that contain localhost in their URL or requests whose URL starts with a '/' (for example GET /api/v1/users).

For example:

  • A frontend application is served from example.com
  • A backend service is served from api.example.com
  • The frontend application makes API calls to the backend
  • The option can be configured for the built-in ember browser
    tracingThe process of logging the events that took place during a request, often across multiple services.
    : browserTracingOptions: { tracePropagationTargets: ['api.example.com'] }}
  • Now outgoing XHR/fetch requests to api.example.com will get the sentry-trace header attached.
Copied
import * as Sentry from "@sentry/ember";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",

  // We recommend adjusting this value in production, or using tracesSampler
  // for finer control
  tracesSampleRate: 1.0,

  browserTracingOptions: {
    tracePropagationTargets: [
      "localhost",
      "my-site-url.com",
      "api.example.com",
    ],
  },
});

You will need to configure your web server CORS to allow the sentry-trace and baggage headers. The configuration might look like "Access-Control-Allow-Headers: sentry-trace" and "Access-Control-Allow-Headers: baggage", but it depends on your set up. If you do not allow the two headers, the request might be blocked.

beforeNavigate

beforeNavigate is called at the start of every pageload or navigation transaction, and is passed an object containing the data with the transaction will be started. Using beforeNavigate gives you the option to modify that data, or drop the transaction entirely by returning undefined.

One common use case is parameterizing transaction names. For both pageload and navigation transactions, the BrowserTracing integration uses the browser's window.location value to generate a transaction name. Using beforeNavigate you can modify the transaction name to make it more generic, so that, for example, transactions named GET /users/12312012 and GET /users/11212012 can both be renamed GET /users/:userid, so that they'll group together.

Copied
Sentry.init({
  // ...
  browserTracingOptions: {
    beforeNavigate: (context) => {
      return {
        ...context,
        // You could use your UI's routing library to find the matching
        // route template here. We don't have one right now, so do some basic
        // parameter replacements.
        name: location.pathname
          .replace(/\/[a-f0-9]{32}/g, "/<hash>")
          .replace(/\/\d+/g, "/<digits>"),
      };
    },
  },
});

shouldCreateSpanForRequest

This function can be used to filter out unwanted spans such as XHRs running health checks or something similar. If this function isn't specified, spans will be created for all requests.

Copied
Sentry.init({
  // ...
  browserTracingOptions: {
    shouldCreateSpanForRequest: (url) => {
      // Do not create spans for outgoing requests to a `/health/` endpoint
      return !url.match(/\/health\/?$/);
    },
  },
});

idleTimeout

The idle time, measured in ms, to wait until the transaction will be finished, if there are no unfinished spans. The transaction will use the end timestamp of the last finished span as the endtime for the transaction.

The default is 1000.

finalTimeout

The maximum duration of the transaction, measured in ms. If the transaction duration hits the finalTimeout value, it will be finished.

The default is 30000.

heartbeatInterval

The time, measured in ms, one heartbeat takes. If no new spans were started or no open spans finished within three heartbeats, the transaction will be finished. The heartbeat count restarts whenever a new span is created or an open span is finished.

The default is 5000.

startTransactionOnLocationChange

This flag enables or disables creation of navigation transaction on history changes.

The default is true.

startTransactionOnPageLoad

This flag enables or disables creation of pageload transaction on first pageload.

The default is true.

markBackgroundTransactions

This option flags transactions when tabs are moved to the background with "cancelled". Because browser background tab timing is not suited for precise measurements of operations and can affect your statistics in nondeterministic ways, we recommend that this option be enabled.

The default is true.

enableLongTask

This option determines whether spans for long tasks automatically get created.

The default is true.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").