📢 Expanding OpenTelemetry Support: OTLP Endpoint in Sentry

[Dhrumil-Sentry]

As part of our ongoing commitment to supporting developers using OpenTelemetry to instrument their apps, we’re excited to announce that Sentry is working on native OTLP ("OpenTelemetry Protocol") support for tracing. Soon, you'll be able to send traces directly to Sentry from your applications or via an OpenTelemetry Collector—no extra setup needed.

Why Are We Doing This?

Sentry’s SDKs already capture errors, spans, replays, profiles, and everything else you need to keep your applications running smoothly. That’s not changing. But we also know that many developers have already invested in OpenTelemetry’s tracing ecosystem, and asking them to reimplement their custom instrumentation to use Sentry is a friction point—time spent moving over is time not spent shipping code.

Some of our SDKs offer a bridge between OpenTelemetry and Sentry, but for users working with our other SDKs—or those managing a complex OpenTelemetry pipeline—the experience hasn’t been seamless. We’re fixing that.

What’s Coming?

OTLP is the standard protocol for sending telemetry data in OpenTelemetry. With Sentry’s upcoming OTLP endpoint for traces, developers who have already instrumented their apps with OpenTelemetry will have a frictionless way to send that data to Sentry—whether directly from an application or via an OpenTelemetry Collector.

What this means for you:

✅ If you’re using OpenTelemetry today, you’ll be able to send traces to Sentry with minimal effort.

✅ Everything will be stitched together inside Sentry—no extra work required.

And if OpenTelemetry isn’t on your radar yet? No problem—Sentry’s SDKs will continue to provide the same tracing and insights you use today.

What’s Next?

To ensure a smooth experience for OpenTelemetry users, we’re making some tweaks to our span model to better align with OpenTelemetry’s structure. We’ll share more details in the coming weeks as we refine the implementation.

🚀 If you're using OpenTelemetry today (or thinking about it), we’d love to hear from you! What’s working? What’s not? How can we make integrating OpenTelemetry with Sentry easier? Drop your thoughts below! 👇

[usesi-jlambert]

This is great news! We are currently implementing a SaaS product into our environment and they support OpenTelemetry out of the box, but we would have to setup our own collector and maintain it in our own environment to be able to send spans to Sentry, so being able to have our SaaS product send spans directly would Sentry would be a life-saver!

[Dhrumil-Sentry]

@usesi-jlambert Would love to understand if you've used tracing in Sentry already and what are all the Must have's you'd absolutely want to see supported for your OTEL traces from the start? Querying for traces? Aggregating and Dashboards on your spans data?

[usesi-jlambert]

We are trying to utilize Sentry as our single pane of glass for several different systems. Since many of those systems are either open source or coded internally we have been able to use the existing Sentry SDKs to implement tracing. The instance we were not able to utilize is with our API gateway, which supports OpenTelemetry but would required an OTel collector to be setup to act as the middleman. Ideally in this scenario we would have as many features of Sentry as possible, but even basic support would be a great start. We want to have better visibility in Sentry for where errors are occurring inside as well as between our different systems, and what is breaking down in the chain of communication between them, so querying would be helpful in that regard!

[rodolfoBee]

@Dhrumil-Sentry is there an update or an ETA for when the endpoint will be available?
There is another use case for an OTLP endpoint in this ticket: a platform that is currently not supported by Sentry.

[Dhrumil-Sentry]

Hi - We don't have a concrete timeline yet, but we're still at least 4-6 weeks away from onboarding few Beta volunteers

[fnberta]

Thanks for the update @Dhrumil-Sentry. If you need someone external to test, happy to help!

[ronan-fitzgerald-zoe]

@Dhrumil-Sentry I'd also be keen to beta test this. We currently have a lot of our backend telemetry going through a self-managed otel collector and exporting using the sentry exporter - we'd love to replace our otel collector with Grafana Alloy which doesn't currently support the sentry exporter.

[Dhrumil-Sentry]

@ronan-fitzgerald-zoe Will definitely update here once we're ready to start onboarding users. Would love to understand your primary use cases for seeing OTEL data in Sentry - Is to to see Distributed traces and have span based alerting?

[ronan-fitzgerald-zoe]

@Dhrumil-Sentry yes exactly, we are working to better instrument our front-end with spans, but when the front-end makes network calls to our backend services we have to go into another tool to see the rest of the trace - this is even more annoying if a transaction makes multiple calls to our backend services.

We have a bunch of backend services that are already instrumented with otel libraries, which we enrich in a fairly basic otel pipeline in Grafana Alloy and send to a different vendor. For our testing, we then have another otel collector that we send the telemetry to, from Grafana Alloy, just so we can export it to Sentry.

What we'd like to do is simplify it like:

From this:
Service (otlp) -> Alloy (otlp) -> Otel Collector (proprietary sentry) -> Sentry

To this:
Service (otlp) -> Alloy (otlp) -> Sentry