Sentry and OpenTelemetry: Complementary Tools, Not Rivals

Teams that already instrument their backend with OpenTelemetry often assume evaluating Sentry means ripping out that setup. In practice, the recommended pattern is to keep OpenTelemetry as-is on the backend, add the Sentry SDK on the frontend for browser tracing, error capture, Session Replay and logs, and forward OTLP (OpenTelemetry Protocol) events to Sentry. Sentry's OTLP ingest currently supports traces and logs, with metrics support still under consideration.

The key is separating two distinct decisions: how frontend and backend stay linked in the same distributed trace via W3C traceparent headers, and how backend OTLP events get exported to Sentry. For export, teams can send OTLP directly from a backend service to Sentry's endpoint, or route it through an OpenTelemetry Collector first. Direct export suits single-service setups with minimal moving parts, while Collector forwarding fits multi-service environments needing centralized batching, processing, sampling, or parallel routing to an existing vendor for comparison during evaluation.

One caveat for multi-project setups: a generic OTLP HTTP exporter is tied to a single Sentry project key, so every service would land in the same project. The dedicated Sentry exporter solves this by routing events to different projects based on resource attributes like service.name, and can even auto-create missing projects given the right API permissions.

A reference architecture demonstrates this: a React frontend using @sentry/react propagates traceparent headers over fetch calls to a FastAPI backend instrumented purely with OpenTelemetry, which then forwards OTLP data through a Collector to Sentry. Despite using different SDKs per layer, every component participates in the same distributed trace, with backend logs attached to that shared debugging context.