Sentry OpenTelemetry連携の3経路｜OTLP直送とSDK併用の判断

OpenTelemetryで計装済みのアプリケーションからSentryへテレメトリを渡す経路は、2026年8月時点の公式ドキュメントで3通りに整理されています。Sentry SDKにOTLP Integrationを足す構成、OTLPエンドポイントへ直送する構成、そしてOpenTelemetry CollectorにSentry Exporterを挟む構成です。この記事では3経路のエンドポイント設定値と認証ヘッダ、オープンベータゆえに欠ける取り込み仕様、エラーイベントとトレースを同一trace_idで結ぶ実装、スパンが二重に登録される条件、そして既存のOTelパイプラインへSentryを足すか置き換えるかの判断までを、実装する側の材料として整理します。

まとめ：3経路の選び分けとエラー相関を落とさない条件

結論を先に置きます。Sentryをエラー監視として使い続けながらOTelのトレースも見たいなら、Sentry SDKにOTLP Integrationを足す構成が第一候補です。トレースとログの保管先としてだけSentryを使うならOTLPエンドポイントへの直送、複数サービスを1つのCollectorから別々のSentryプロジェクトへ振り分けたいならSentry Exporterという順で候補を絞ると迷いません。

経路選択より先に確認すべきなのは、OTLP経由の取り込みが2026年8月時点でオープンベータであるという前提です。受け取れるシグナルはトレースとログの2つで、メトリクスの取り込みには対応していません。スパンイベントは取り込み時に破棄され、スパンリンクと配列属性は表示はされるものの検索・フィルタ・集計の対象外です。「OTelで計装すればSentryの機能が全部そのまま使える」という前提で提案すると、実装フェーズで崩れます。

SentryがOpenTelemetryを受け取る3経路と適用範囲の切り分け

3経路は優劣ではなく、テレメトリの正規化とプロジェクトへの振り分けをどこで行うかの違いです。OTLPやCollectorという語が何を指すかについてはOpenTelemetry（OTel）の3つのシグナルとOTLP・Collectorの役割を先に押さえておくと、以降の設定項目が読み解けます。

OTLP IntegrationでSDKのエラーとOTel計装を束ねる構成

Sentry SDKを従来どおり初期化したうえで、OTLP Integrationを有効にする構成です。公式は「同じバックエンドサービス内でSentry SDKとOTel計装の両方を動かしているなら、OTLP Integrationを使う」と位置づけています。この統合が行うのは3つで、稼働中のOTelトレース文脈を読み取ってSentryイベントへtrace_idとspan_idを刻むこと、Sentryの取り込みエンドポイントを向いたOTLPエクスポータを設定すること、そしてPropagatorの登録です。

エラー監視という本来の使い方を維持したまま、トレースの計装はOTel側の資産に寄せられます。Pythonでの記述はsentry_sdk.integrations.otlpのOtlpIntegrationを初期化時のintegrationsへ渡すだけで、エンドポイントはDSNから自動的に導出されます。

OTLP直送でSentryをトレースとログの保存先に限定する構成

計装コードには一切手を入れず、既存のOTLPエクスポータの向き先をSentryのエンドポイントへ変えるだけの構成です。公式ブログもこの経路を「計装はそのまま、送信先だけ変える」と説明しています。Sentry SDKを入れないため、エラーイベント・Session Replay・自動ブレッドクラムといったSentry固有の機能は載りません。

トレース保管先の乗り換え検証や、既にエラー監視を別系統で持っている案件に向いた経路です。逆に言えば、Sentryを選ぶ最大の理由であるエラー起点の調査は、この構成では手に入りません。他社バックエンドと横並びで評価しているなら、Datadog OpenTelemetry連携の4方式と機能差と比較しておくと、保管先としての条件の違いが見えます。

Sentry ExporterをCollectorに挟む複数プロジェクト振り分け

OpenTelemetry Collectorにsentryという名前のエクスポータを設定し、1つのCollectorインスタンスから複数のSentryプロジェクトへテレメトリを振り分ける構成です。サービスごとにDSNを配って回る必要がなくなります。既定ではservice.nameリソース属性の値と同じスラッグのプロジェクトへ送られ、service.nameがpayments-apiのサービスはpayments-apiプロジェクトに入ります。

ただし安定度はトレース・ログともにアルファ段階と明記されています。振り分け属性が欠けたテレメトリは失われ、自動作成されたプロジェクトでは最初のバッチが落ちることがあり、削除済みプロジェクト宛ての送信はキャッシュが退避するまで403を返し続けます。マイクロサービスが数十本ある組織向けの経路であって、サービス2〜3本の構成で持ち出す道具ではありません。

OTLP直送エンドポイントの設定値とベータ段階で欠ける機能の内訳

直送経路は設定項目が2つだけと軽い一方、取り込み側の仕様に明示された欠落があります。数値と対象を押さえておくと採否を即断できます。

トレースとログのエンドポイントURLと認証ヘッダの具体的な指定手順

送信先はシグナルごとに分かれています。トレースは https://o〈組織ID〉.ingest.sentry.io/api/〈プロジェクトID〉/integration/otlp/v1/traces 、ログは末尾が v1/logs になったURLです。認証はAPIトークンではなくDSNの公開鍵を使い、ヘッダ値は x-sentry-auth に「sentry sentry_key=公開鍵」の形で渡します。

1. Sentryの Settings から Projects を開き、対象プロジェクトを選ぶ
2. SDK Setup 配下の Client Keys（DSN）で OpenTelemetry のタブを開く
3. 表示されたエンドポイントURLと公開鍵を OTEL_EXPORTER_OTLP_TRACES_ENDPOINT と OTEL_EXPORTER_OTLP_TRACES_HEADERS に設定する
4. ログも送るなら OTEL_EXPORTER_OTLP_LOGS_ENDPOINT と OTEL_EXPORTER_OTLP_LOGS_HEADERS を同様に設定する
5. OTEL_SERVICE_NAME を明示し、Sentry側でサービス単位に絞り込めるようにする

公式ドキュメントが示す設定例はHTTPのエクスポータにurlとheadersを渡す形で、gRPCでの送信手順は記載されていません。既存のCollectorがgRPCでバックエンドへ送っている構成なら、Sentry向けのパイプラインだけHTTPに分ける必要があります。ログ側のパイプライン設計はOpenTelemetryのログを直接送信とfilelog receiverで選び分ける手順と併せて詰めてください。

スパンイベント破棄とスパンリンク部分対応という取り込み時の欠落

取り込み仕様には明示された欠落が3つあります。最も影響が大きいのはスパンイベントで、公式は「スパンイベントは非対応。取り込み時にすべて破棄される」と記載しています。例外情報をスパンイベントとして載せている計装は、Sentry側でその情報が消えます。

スパンリンクと配列属性は取り込みも表示もされますが、検索・フィルタ・集計はできません。「画面に出ているのにダッシュボードで集計できない」という形で表面化するため、非同期処理のリンク関係をアラート条件に使う設計は、この段階では成立しないと見ておくべきです。

OTLPメトリクス非対応がバックエンド統合に与える制約と回避策

SentryはOTLP経由のメトリクスを受け取りません。3シグナルすべてを1つのバックエンドへ集約する構想でSentryを選ぶと、メトリクスだけ行き場を失います。実務上の回避策は2つです。メトリクスをPrometheusなど別系統に残して二系統で運用するか、Collectorのパイプラインをシグナル別に分けて宛先を変えるか。

後者はCollectorの設定ファイル内でtracesとlogsのパイプラインだけSentryへ向け、metricsは既存の送信先を維持する形になります。3シグナル統合を優先要件に置くなら、そもそも受け口の広いバックエンドを見るほうが早いです。

エラーイベントとOTelトレースを同一trace_idで相関させる実装

SentryをOTelと組み合わせる価値は、ほぼこの一点に集約されます。エラーをクリックすれば原因のOTelトレースに飛べる、逆にトレースの遅いスパンからそこで起きたエラーへ辿れる、という導線です。

OTLP Integrationがイベントへtrace_idを刻む仕組みと対応言語

相関の実体は、OTLP Integrationが稼働中のOTelトレース文脈を読み、すべてのSentryイベントにtrace_idとspan_idを付与する処理です。これによりエラーがトレースのウォーターフォール上の正しいスパンに現れます。SentryとOTelのSDKが同一サービス内で動く場合、trace_idは自動的に共有されます。

この統合が使える言語は、公式ブログの記載でPython・Ruby・Node.js・Go・PHP・.NET・Javaです。Javaはsentry-opentelemetry-agentをjavaagent引数で読み込む従来のディープ統合も主軸として維持されている状況です。なおPython側の要件はPython 3.7以上、opentelemetry-distroは0.35b0以上とされ、Propagatorの自動設定は次のメジャーバージョンで削除予定と告知されています。Sentry製品そのものの機能範囲はSentryのエラー監視・APM機能と料金体系で確認できます。

traces_sample_rate併用でスパンが二重化する条件と回避手順

連携で最も多い事故がこれです。OTel側でトレースを取りながらSentry SDK側でもtraces_sample_rateやtraces_samplerを設定すると、同じ処理に対して両方がスパンを作り、Sentryに重複したスパンが登録されます。公式は「OTelのトレースを使うならSentry SDKにtraces_sample_rateを設定しないこと。重複スパンが生まれる」と明記しています。

回避策は単純で、1サービスにつきトレースの発生元を1つに固定することです。OTLP Integrationを使うならSentry SDKの追跡設定は書かない。逆にSentry SDKのトレースを使うなら、OTelのエクスポータをSentryへ向けない。Node.jsで既存のOTelセットアップをそのまま使いたい場合は、Sentry.initにskipOpenTelemetrySetupを立てたうえで、SentrySpanProcessor・SentryPropagator・SentrySamplerとSentryContextManagerを自分で組み込み、最後にvalidateOpenTelemetrySetupで配線を検証します。この検証関数を呼ばずに本番へ出すと、文脈の分離だけが静かに壊れた状態に気づけません。

propagateTraceparentとサンプラー設定が招く判断の食い違い

フロントエンドからバックエンドまで1本のトレースにする場合、propagateTraceparentを有効にするとフロント側SDKがサンプリング判断をW3Cのtraceparentヘッダに載せ、バックエンドがそれを引き継ぎます。ここで公式が注意しているのが、OTel側のサンプラーをalways_onにしておくという点です。

親のサンプリング判断に従うサンプラーのままだと、Collector側でテールベースのサンプリングを組んでいても、フロントの判断が先に効いて素通りしてしまいます。エラー時だけ全スパンを残す設計を組んでいる案件では、この一行の違いで「落ちたリクエストのトレースだけ欠けている」という最悪の欠落が起きます。フロントを含む分散トレースを組むなら、サンプリング判断をどの層で下すかを先に決めてください。

既存のOTelパイプラインにSentryを足すか置き換えるかの判断基準

ここは判断を言い切ります。既にOTelでトレースを取っている環境にSentryを持ち込む価値があるのは、エラー監視をSentryに寄せる場合に限られます。トレース保管先としての置き換えを検討しているなら、現時点では見送りが妥当です。

エラー監視を主目的にSentryを足す構成の採用条件と運用前提

足す構成を採用してよいのは、次の2つを同時に満たすときです。第一に、エラーの調査導線をSentryに集約したい、あるいは既にSentryでエラー監視をしていること。第二に、対象言語がOTLP Integrationの対応言語（Python・Ruby・Node.js・Go・PHP・.NET・Java）に含まれていること。

この条件下なら、既存のOTel計装をそのままトレースの供給源にしつつ、エラーとトレースが同一trace_idで結ばれます。運用面の前提は1つだけ、サービスごとにトレースの発生元がSentry SDKかOTelかのどちらに寄っているかを台帳で管理することです。ここが曖昧なまま担当者が入れ替わると、重複スパンが再発します。

OTLP直送だけで組んだ場合に落ちるSentry固有機能と見送り判断

Sentry SDKを入れずOTLP直送だけで組む構成は、新規にSentryを導入する案件では見送るべきです。ログからのIssue生成、Session Replayとの連携、自動ブレッドクラム、そしてエラー相関は、いずれもネイティブSDK側に組み込まれた機能で、ベータ段階のOTLP経由の取り込みには載っていません。Sentryを選ぶ理由の大半がこれらであるため、機能を捨てた状態で比較すると、そもそも他のバックエンドのほうが条件が良くなります。

ベンダー中立性を最優先し、トレースとログの保管先を将来差し替える前提なら、判断は逆です。その場合はSentryに限定せず、Grafanaの構成でOTLPを受けて3シグナルを統合する手順のようなメトリクスまで受けられる選択肢を含めて評価してください。メトリクス非対応という制約が、Sentryを汎用バックエンドとして選びにくくしています。

小規模構成でSentry Exporterを立てる運用コストの損益分岐

サービス数が2〜3、送信先プロジェクトも1つという規模でCollectorにSentry Exporterを組むのは過剰です。Collector本体の可用性・バージョン追従・設定管理という運用対象が増えるうえ、エクスポータ自体がアルファ段階で、振り分け属性の欠落がそのままデータ損失になります。この規模なら各サービスにDSNを配ってOTLP Integrationで直接送るほうが、管理点も障害点も少なく済みます。

損益分岐は、プロジェクト数が2桁に届き、DSNの配布と更新が手作業で回らなくなったあたりにあります。監視基盤の経路設計から運用体制まで含めて相談したい場合は、システムの保守運用・内製化支援で構成レビューから引き受けています。

よくある質問

SentryとOpenTelemetryの連携について、実装前に確認されることの多い5問に答えます。

SentryはOpenTelemetryのメトリクスを取り込めますか？

取り込めません。2026年8月時点の公式ドキュメントは、OTLP経由で受け取れるシグナルをトレースとログの2つとし、メトリクスについては現時点で非対応と明記しています。3シグナルすべてを1つのバックエンドに集約したい要件がある場合、メトリクスはPrometheusなど別系統に残すか、Collectorのパイプラインをシグナル別に分けて宛先を変える設計になります。

OTelで計装すればSentryの機能はすべて使えますか？

使えません。OTLP経由の取り込みはオープンベータで、ログからのIssue生成、Session Replayとの連携、自動ブレッドクラムといったネイティブSDK側の機能は載っていません。取り込み仕様にも欠落があり、スパンイベントは破棄され、スパンリンクと配列属性は表示のみで検索・フィルタ・集計の対象外です。エラー起点の調査導線が要件なら、Sentry SDKにOTLP Integrationを足す構成を選んでください。

Sentry SDKとOTelを併用するとスパンが重複しませんか？

設定次第で重複が生じる構成です。OTel側でトレースを取りながらSentry SDKにもtraces_sample_rateやtraces_samplerを設定すると、同じ処理に対して両方がスパンを生成します。公式もこの点を明示して警告しています。回避策は、1サービスにつきトレースの発生元を1つに固定することです。OTLP Integrationを使う場合はSentry SDK側の追跡設定を書かないでください。

OTLPエンドポイントへgRPCで送ることはできますか？

公式ドキュメントが示す設定例はHTTPのエクスポータにurlとheadersを渡す形式のみで、gRPCでの送信手順は記載されていません。既存のCollectorがgRPCでバックエンドへ送っている構成では、Sentry向けのパイプラインだけHTTPに分ける必要があります。エンドポイントはトレースとログでURLが分かれており、認証はDSNの公開鍵をx-sentry-authヘッダに載せて渡します。

複数サービスを別々のSentryプロジェクトへ振り分けられますか？

CollectorにSentry Exporterを設定すれば可能です。既定ではservice.nameリソース属性の値と同じスラッグのプロジェクトへ送られ、project_from_attributeで振り分けの基準属性を変更したり、明示的な対応表を持たせたりもできます。ただし安定度はトレース・ログともアルファ段階で、振り分け属性が欠けたテレメトリは失われます。プロジェクト数が2桁に届かない規模では、各サービスにDSNを配る運用のほうが堅実です。

関連記事

• OpenTelemetry（OTel）とは：3つのシグナル・OTLP・Collectorという、この記事の前提になる規格側の解説です。
• Sentryとは：バックエンド側の機能構成と料金体系を、製品概要の粒度で確認できます。
• Datadog OpenTelemetry連携の4方式：同じOTel計装を別のバックエンドへ送る場合の方式差と機能制限の比較材料になります。
• Grafana OpenTelemetry連携の構成：メトリクスまで含めた3シグナル統合が要件のとき、Sentryの代替として評価できます。
• APM（アプリケーション性能監視）とは：トレースを何に使うのかという監視カテゴリ側の前提を整理できます。