Set Up Profiling

Learn more about how to configure our Profiling integration and start profiling your code.

By default, Sentry error events will not get trace context unless you configure the scope with the transaction, as illustrated in the example below.

If you're adopting Profiling in a high-throughput environment, we recommend testing prior to deployment to ensure that your service's performance characteristics maintain expectations.

Node profiling is available starting in @sentry/profiling-node version 0.3.0. You have to have the @sentry/google-cloud-serverless (minimum version 8.0.0) package installed.

Copied
npm install --save @sentry/google-cloud-serverless @sentry/profiling-node

To enable profiling, import @sentry/profiling-node, add the nodeProfilingIntegration to your integrations, and set the profilesSampleRate.

Copied
const Sentry = require("@sentry/google-cloud-serverless");
const { nodeProfilingIntegration } = require("@sentry/profiling-node");

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  integrations: [
    // Add our Profiling integration
    nodeProfilingIntegration(),
  ],
  tracesSampleRate: 1.0,
  // Set sampling rate for profiling - this is relative to tracesSampleRate
  profilesSampleRate: 1.0,
});

// Profiling happens automatically after setting it up with `Sentry.init()`.
// All spans captured in your application will have profiling data attached to them.
// You can also manually capture spans with `startSpan`, as shown below:
Sentry.startSpan(
  {
    op: "rootSpan",
    name: "My root span",
  },
  () => {
    // Any code in this callback will be profiled.
  },
);

Under the hood, the Sentry profiler uses V8's CpuProfiler to collect stack samples. This means that sentry/profiling-node is written as a native add-on for Node and won't run in environments like Deno or Bun. Profiling enhances tracing by providing profiles for individual transactions. This allows you to look at higher level performance information like transaction and span durations before diving deeper and looking at profiles.

The default mode of the v8 CpuProfiler is kEagerLogging which enables the profiler even when no profiles are active—this is good because it makes calls to startProfiling fast with the tradeoff of constant CPU overhead. This behavior can be controlled via the SENTRY_PROFILER_LOGGING_MODE environment variable with values of eager|lazy. If you opt to use the lazy logging mode, calls to startProfiling may be slow. (Depending on environment and node version, it can be in the order of a few hundred ms.)

Here's an example of starting a server with lazy logging mode:

Copied
# Run profiler in lazy mode
SENTRY_PROFILER_LOGGING_MODE=lazy node server.js

We recommend you have your own CPU resource-monitoring in place, because the actual resource use could be environment-dependent.

Starting from version 0.1.0, the @sentry/profiling-node package precompiles binaries for a number of common architectures. This minimizes the tooling required to run the package and avoids compiling the package from source in most cases, which speeds up installation. Currently, we ship prebuilt binaries for the following architectures and Node versions:

  • macOS x64: Node v16, v18, v20
  • Linux ARM64 (musl): Node v16, v18, v20
  • Linux x64 (glibc): Node v16, v18, v20
  • Windows x64: Node v16, v18, v20

The set of common architectures should cover a wide variety of use cases, but if you have feedback or experience different behavior, please open an issue in the Sentry JavaScript SDK repository.

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").