Code-level application monitoring for OpenTelemetry

Take action on your telemetry data to resolve code issues faster - without multiple tools or complex instrumentation. Join the discussion here.

AMA: Getting Started with OpenTelemetry and Sentry

Getting Started is Simple

Grab the Open Telemetry SDK:

Click to Copy
go get \

Configure your properties file:

Click to Copy
import ( "" sdktrace "" "" "" // ... ) sentry.Init(sentry.ClientOptions{ Dsn: "__DSN__", EnableTracing: true, TracesSampleRate: 1.0, Debug: true, }) tp := sdktrace.NewTracerProvider( sdktrace.WithSpanProcessor(sentryotel.NewSentrySpanProcessor()), ) otel.SetTracerProvider(tp) otel.SetTextMapPropagator(sentryotel.NewSentryPropagator())

Check our documentation for the latest instructions.

See all platforms

More than 100K Organizations Trust Sentry with Their Application Monitoring

Performance Monitoring that’s actionable, not academic

Focused on actionable feedback, not dashboards. Automatically detect issues for performance and errors and get to the fix faster with deep context - down to the line of code.

Learn more about Performance Issues

Fill in the blanks about your errors

Expose the important events that led to each exception: SQL queries, debug logs, network requests, past errors. Improve debugging workflow with a full view of releases so you can mark errors as resolved and prioritize live issues.

Check out breadcrumbs

Combine performance and error monitoring to trace across services

See a unified view of your frontend to backend flow. Trace slow-loading pages all the way back to poor-performing API calls — and surface any related errors — to get to root cause faster.

Explore an example Trace View

"Getting started with Sentry and OpenTelemetry was fast and easy. We chose Sentry because we can understand why and where something is slow, fix it quickly, and get ahead of user complaints."

Dominik Sandjaja
Senior Software Engineer at bex technologies GmbH


The collector approach ultimately removes the Sentry SDKs from the equation, which means you will not get the benefits of advanced error tracking, or any other features Sentry SDKs provide. That includes new product features like profiling and crons. So the approach we decided upon was to treat OTel the same way we treat any other framework. The SDKs can plugin and capture all the relevant data to send to Sentry where we can couple it with all the other features, while getting all insights from your OTel data.

The parent-most OTel span on the OTel span tree that’s created becomes the transaction, and the rest of the spans on the OTel span tree (descendants, branches/leaves) are the spans inside of it.

Yes. Our goal is a flawless conversion of OTel data into Sentry. We do not do some things like automatically set tags. But if you see something amiss, reach out to support, or create an issue for SDK team on one of our repos, we will make sure it is routed to the right place.

A trace represents the record of the entire operation you want to measure or track - like page load, an instance of a user completing some action in your application, or a cron job in your backend. When a trace includes work in multiple services, such as those listed above, it's called a distributed trace, because the trace is distributed across those services.
Each trace consists of one or more tree-like structures called transactions, the nodes of which are called spans. In most cases, each transaction represents a single instance of a service being called, and each span within that transaction represents that service performing a single unit of work, whether calling a function within that service or making a call to a different service. Learn more about distributed tracing.

Looking for an example suite of microservices already instrumented with Sentry and OTel SDKs? We got you covered. Check out our demo repo in Github here. This is a fork of the official example provided by OpenTelemetry we use for our own testing purposed.

© 2024 • Sentry is a registered Trademark
of Functional Software, Inc.