OpenTelemetry gives you a standard way to instrument your code. Sentry gives that telemetry data meaning: errors connected to traces, logs tied to issues, and debugging tools that point to the root cause in your code.
Send traces and logs directly via OTLP, forward them through the OTel Collector, or run Sentry SDKs alongside your existing OpenTelemetry setup.
Tolerated by 4 million developers
Configure your OpenTelemetry SDK to export traces and logs to Sentry's OTLP endpoint. Set the OTEL_EXPORTER_OTLP_ENDPOINT environment variable, add your auth header, and you're done. No Collector, no sidecar agents, no extra infrastructure to manage.
Most OpenTelemetry backends show you traces and logs. Sentry connects those to the errors, stack traces, and breadcrumbs that explain what actually went wrong. When a Sentry SDK and OTel instrumentation run in the same service, they share the same trace ID automatically, so errors link to the exact span where they happened.
Your frontend uses a Sentry SDK. Your backend uses OpenTelemetry. Sentry propagates W3C Trace Context headers so both sides of the request show up in a single distributed trace, with timing for every span. You can follow a slow page load from the browser through your API, into the database query that caused it.
Use the OpenTelemetry Collector, Vector, or Fluent Bit to forward logs and traces from infrastructure sources into Sentry. The Sentry Exporter for the OTel Collector handles multi-project routing and automatic project creation, so each service's telemetry lands in the right place.
We support every technology (except the ones we don't).
Get started with just a few lines of code.
Point any OpenTelemetry SDK directly at Sentry's OTLP endpoint. No Sentry SDK or Collector needed.
Set these environment variables (works with any OTel SDK):
# Traces
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="{OTLP_TRACES_URL}"
export OTEL_EXPORTER_OTLP_TRACES_HEADERS="x-sentry-auth=sentry sentry_key={PUBLIC_KEY}"
# Logs
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="{OTLP_LOGS_URL}"
export OTEL_EXPORTER_OTLP_LOGS_HEADERS="x-sentry-auth=sentry sentry_key={PUBLIC_KEY}"Find your endpoint URLs and public key in Project Settings > Client Keys (DSN) in Sentry.
Recommended if you're already running an OpenTelemetry Collector. No Sentry SDK needed.
Download the pre-built otelcol-contrib distribution and add the Sentry exporter to your collector config:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
exporters:
sentry:
url: https://sentry.io
org_slug: ${env:SENTRY_ORG_SLUG}
auth_token: ${env:SENTRY_AUTH_TOKEN}
processors:
batch:
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [sentry]
logs:
receivers: [otlp]
processors: [batch]
exporters: [sentry]Set your environment variables:
export SENTRY_ORG_SLUG="your-org-slug"
export SENTRY_AUTH_TOKEN="your-auth-token"Create an auth token via Settings > Developer Settings > Internal Integrations in Sentry.
Install the Sentry SDK alongside your OpenTelemetry SDK for the tightest integration. Adds Sentry features like release tracking and session replay.
Example (Python):
pip install --upgrade 'sentry-sdk[opentelemetry-otlp]'import sentry_sdk
from sentry_sdk.integrations.otlp import OTLPIntegration
sentry_sdk.init(
dsn="__DSN__",
send_default_pii=True,
integrations=[
OTLPIntegration(),
],
)Dominik Sandjaja
Senior Software Engineer
bex technologies GmbH
SDKs with built-in OpenTelemetry support
organizations use Sentry in production
supported pipeline tools: OTel Collector, Vector, Fluent Bit
How to route your existing OTel traces into Sentry with direct OTLP ingestion or the OpenTelemetry Collector.
Step-by-step recipe for routing OTel traces from your services into Sentry using the Collector or direct export.
Send structured logs from OTel-instrumented services into Sentry for correlated debugging.
Send OTel traces and logs to Sentry for error context, distributed tracing, and code-level debugging. Direct OTLP ingestion, no Collector required.