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:Available Auto-Instrumentations
The SDK automatically includes OpenTelemetry instrumentations for:HTTP & Networking
httpIntegration- HTTP/HTTPS requestsnativeNodeFetchIntegration- Native fetch API
Frameworks
expressIntegration- Express.jsfastifyIntegration- FastifyhapiIntegration- HapinestIntegration- Nest.js
Databases
prismaIntegration- Prisma ORMmongoIntegration- MongoDBmongooseIntegration- MongoosemysqlIntegration- MySQLmysql2Integration- MySQL2postgresIntegration- PostgreSQLredisIntegration- 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: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
Use Sentry APIs when possible
Use Sentry APIs when possible
Sentry APIs (
startSpan, getActiveSpan) are easier and integrate better:Follow semantic conventions
Follow semantic conventions
Initialize Sentry first
Initialize Sentry first
Always initialize Sentry before other imports:
Don't mix setup approaches
Don't mix setup approaches
Either use Sentry’s auto-setup OR custom OpenTelemetry setup, not both:
Troubleshooting
Spans not appearing in Sentry
Spans not appearing in Sentry
Symptoms: No performance data in SentrySolutions:
- Ensure
tracesSampleRateis set - Initialize Sentry before all imports
- Check console for errors
- Verify instrumentations are loaded
Duplicate spans
Duplicate spans
Symptoms: Same operation shows multiple spansSolution: You may be using both Sentry and OTel APIs. Pick one:
Context not propagating
Context not propagating
Symptoms: Distributed traces disconnectedSolutions:
- Set
tracePropagationTargets - Ensure services use same trace headers
- Check CORS allows trace headers
High overhead from instrumentation
High overhead from instrumentation
Solutions:
- Lower
tracesSampleRate - Disable unused instrumentations
- Use
shouldCreateSpanForRequestto filter
Complete Example
Migration from OpenTelemetry
If you’re already using OpenTelemetry:Resources
- OpenTelemetry JavaScript SDK
- OpenTelemetry Semantic Conventions
- OpenTelemetry Registry
- Sentry OpenTelemetry Docs
Next Steps
Custom Integrations
Build custom integrations
Performance Monitoring
Best practices for performance