Skip to main content
Sentry’s JavaScript SDK v8+ is built on OpenTelemetry, the industry-standard observability framework. This enables seamless integration with OpenTelemetry tooling and standardized instrumentation.

Why OpenTelemetry?

OpenTelemetry (OTel) provides:
  • Standardized instrumentation across languages and frameworks
  • Vendor-neutral data collection
  • Automatic instrumentation for common libraries
  • Distributed tracing across services
  • Rich ecosystem of integrations

Automatic OpenTelemetry Integration

In SDK v8+, OpenTelemetry is used automatically:
In Node.js SDK v8+, you MUST initialize Sentry before any other imports for OpenTelemetry auto-instrumentation to work.

Available Auto-Instrumentations

The SDK automatically includes OpenTelemetry instrumentations for:

HTTP & Networking

  • httpIntegration - HTTP/HTTPS requests
  • nativeNodeFetchIntegration - Native fetch API

Frameworks

  • expressIntegration - Express.js
  • fastifyIntegration - Fastify
  • hapiIntegration - Hapi
  • nestIntegration - Nest.js

Databases

  • prismaIntegration - Prisma ORM
  • mongoIntegration - MongoDB
  • mongooseIntegration - Mongoose
  • mysqlIntegration - MySQL
  • mysql2Integration - MySQL2
  • postgresIntegration - PostgreSQL
  • redisIntegration - Redis (ioredis)

GraphQL

  • graphqlIntegration - GraphQL operations

Custom OpenTelemetry Instrumentations

Add custom OpenTelemetry instrumentations:

Common Third-Party Instrumentations

Working with OpenTelemetry API

Using OpenTelemetry Spans

You can use both Sentry and OpenTelemetry APIs:

Getting Active Span

Adding Span Attributes

Semantic Conventions

Use OpenTelemetry semantic conventions for consistency:

HTTP Spans

Database Spans

RPC/GraphQL Spans

Custom Context Propagation

Control how trace context is propagated:

W3C Trace Context

Sentry supports W3C Trace Context:

Distributed Tracing

Connect traces across services:

Service A (Node.js)

Service B (Node.js)

OpenTelemetry Exporters

Export to multiple backends:
When skipOpenTelemetrySetup: true, you must configure OpenTelemetry yourself. Automatic instrumentations won’t work.

Filtering OpenTelemetry Spans

Control which spans are created:

Performance Optimization

Disable Unnecessary Instrumentations

Sampling

Control sampling at the OpenTelemetry level:

Accessing OpenTelemetry Context

Best Practices

Sentry APIs (startSpan, getActiveSpan) are easier and integrate better:
Use OpenTelemetry semantic conventions for consistency:
See OpenTelemetry Semantic Conventions
Always initialize Sentry before other imports:
Either use Sentry’s auto-setup OR custom OpenTelemetry setup, not both:

Troubleshooting

Symptoms: No performance data in SentrySolutions:
  1. Ensure tracesSampleRate is set
  2. Initialize Sentry before all imports
  3. Check console for errors
  4. Verify instrumentations are loaded
Symptoms: Same operation shows multiple spansSolution: You may be using both Sentry and OTel APIs. Pick one:
Symptoms: Distributed traces disconnectedSolutions:
  1. Set tracePropagationTargets
  2. Ensure services use same trace headers
  3. Check CORS allows trace headers
Solutions:
  1. Lower tracesSampleRate
  2. Disable unused instrumentations
  3. Use shouldCreateSpanForRequest to filter

Complete Example

Migration from OpenTelemetry

If you’re already using OpenTelemetry:

Resources

Next Steps

Custom Integrations

Build custom integrations

Performance Monitoring

Best practices for performance