You can configure your OpenTelemetry SDK to send traces and spans to Sentry.
sentry-opentelemetry gem requires
1.0.0 or higher.
gem "sentry-ruby" gem "sentry-rails" gem "sentry-opentelemetry" gem "opentelemetry-sdk" gem "opentelemetry-instrumentation-all"
Initialize Sentry for
Sentry.init do |config| config.dsn = "__DSN__" config.traces_sample_rate = 1.0 # set the instrumenter to use OpenTelemetry instead of Sentry config.instrumenter = :otel end
This disables all Sentry instrumentation and relies on the chosen OpenTelemetry tracers for creating spans.
Next, configure OpenTelemetry as you need and hook in the Sentry span processor and propagator:
OpenTelemetry::SDK.configure do |c| c.use_all c.add_span_processor(Sentry::OpenTelemetry::SpanProcessor.instance) end OpenTelemetry.propagation = Sentry::OpenTelemetry::Propagator.new
OpenTelemetry and Sentry
With Sentry’s OpenTelemetry SDK, an OpenTelemetry
Span becomes a Sentry
Span. The first
Span sent through the Sentry
SpanProcessor is a
Transaction, and any child
Span gets attached to the first
Transaction upon checking the parent
Span context. This is true for the OpenTelemetry root
Span and any top level
Span in the system. For example, a request sent from frontend to backend will create an OpenTelemetry root
Span with a corresponding Sentry
Transaction. The backend request will create a new Sentry
Transaction for the OpenTelemetry
Span. The Sentry
Span are linked as a trace for navigation and error tracking purposes.
If you need more fine grained control over Sentry, take a look at the Configuration page. In case you'd like to filter out transactions before sending them to Sentry (to get rid of health checks, for example), you may find the Filtering page helpful.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").