OpenTelemetry Support

You can configure your OpenTelemetry SDK to send traces to Sentry over OTLP.

Install

Install the otel and otel/otlp modules in addition to the main SDK:

go get github.com/getsentry/sentry-go \
       github.com/getsentry/sentry-go/otel \
       github.com/getsentry/sentry-go/otel/otlp

Usage

Create a trace exporter and register Sentry's OTel integration:

import (
	"context"
	"go.opentelemetry.io/otel"
	sdktrace "go.opentelemetry.io/otel/sdk/trace"

	"github.com/getsentry/sentry-go"
	sentryotel "github.com/getsentry/sentry-go/otel"
	sentryotlp "github.com/getsentry/sentry-go/otel/otlp"
	// ...
)

sentry.Init(sentry.ClientOptions{
	Dsn:              "___PUBLIC_DSN___",
	EnableTracing:    true,
	TracesSampleRate: 1.0,
	Debug:            true,
	Integrations: func(integrations []sentry.Integration) []sentry.Integration {
		return append(integrations, sentryotel.NewOtelIntegration())
	},
})

ctx := context.Background()
exporter, err := sentryotlp.NewTraceExporter(ctx, "___PUBLIC_DSN___")
if err != nil {
	panic(err)
}

tp := sdktrace.NewTracerProvider(
	sdktrace.WithBatcher(exporter),
)
otel.SetTracerProvider(tp)

Now, spans produced by OpenTelemetry will be exported to Sentry over OTLP.

Distributed Tracing

The OTLP integration does not set up a propagator for you. How you configure propagation depends on your setup:

• Sentry frontend → OTel backend: If a Sentry SDK on your frontend sends requests to this OTel-instrumented service, enable propagateTraceparent in your frontend SDK. This sends the W3C traceparent header, which your OTel-instrumented backend will pick up automatically.
• OTel ↔ OTel: If all your services use OpenTelemetry, configure propagators using the standard OpenTelemetry API (for example, propagation.TraceContext{}). See the OpenTelemetry propagation documentation for details.

If you're exporting through an OpenTelemetry Collector instead of sending traces directly to Sentry, you only need to keep the same sentry.Init(...) with sentryotel.NewOtelIntegration() in your Go app. Then configure the collector's otlphttp exporter to send traces to Sentry's OTLP endpoints. See the OpenTelemetry Collector guide.

Linking Errors to Transactions

To link errors and messages captured by the Sentry SDK to the active trace in the UI, pass the current OpenTelemetry-enhanced context in the EventHint:

hub := sentry.CurrentHub()
//// or:
// hub := sentry.GetHubFromContext(ctx)
client, scope := hub.Client(), hub.Scope()
client.CaptureException(
	errors.New("new error"),
	&sentry.EventHint{Context: ctx},
	scope,
)

Events captured with the high-level sentry.CaptureException or sentry.CaptureMessage functions are not linked unless the active context is included in the event hint.

OpenTelemetry and Sentry

With the OTLP-based setup, your OpenTelemetry spans are exported to Sentry using the standard OpenTelemetry trace pipeline instead of being converted locally by a Sentry span processor. Root spans show up in Sentry as transactions, child spans appear under those transactions, and the full trace remains connected across services.

If you also want captured Sentry errors to be linked to the active OpenTelemetry trace, register sentryotel.NewOtelIntegration() in sentry.Init and capture errors with an EventHint that includes the active context.Context.

If you're using an OpenTelemetry Collector, you don't need sentryotlp.NewTraceExporter(). Keep sentryotel.NewOtelIntegration() in your Sentry SDK setup, then configure the collector's otlphttp exporter to send traces to Sentry's OTLP endpoints. For the collector configuration, see the OpenTelemetry Collector guide.

Additional Configuration

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.