Article by: Johannes Daxböck , Neel Shah（読了時間：5分）
OTel のトレースはすでに Sentry へ送信できますが、OTLP exporter を Sentry のエンドポイントに向け、環境変数を設定すれば、スパンがトレースエクスプローラーに表示されるようになります。
（手順については、OTLP セットアップガイド と【Sentry & OpenTelemetry】併用する方法で解説しています。）
ただ、これらのスパンは孤立した島のような状態です。たしかに Sentry 上でトレースのウォーターフォール表示は得られますが、そこには Sentry を本当に価値あるものにしている要素が欠けています。
- エラーをクリックすれば、その原因となった OTel トレースを確認できる
- スパンをクリックすれば、その内部で発生した Sentry のエラーを確認できる
OTel のパフォーマンスデータと Sentry のエラーデータをつなぐこの連携は、SDK 側で両者を能動的に結びつける仕組みがなければ実現しません。
それを担うのが、Python、Ruby、Node.js、Go、PHP、.NET、Java に対応した OtlpIntegration です。
トレースのつながり：素の OTLP エンドポイントだけでは解決できない問題
スタンドアロンの OTel SDK を Sentry の OTLP エンドポイントと組み合わせて使うと、プロセス内で2つの独立したシステムが動くことになります。
- OTel 側はトレースとスパンを管理
- Sentry SDK はエラー、ログ、application metrics、Session Replay、Profiling を管理
両者は同じプロセスを共有していますが、コンテキストは共有していません。Sentry SDK がエラーをキャプチャするとき、どの OTel トレースがアクティブなのかを把握できません。OTel SDK がスパンをエクスポートするときも、そのスパンの最中に Sentry のエラーが発生したことを知る術がありません。
OtlpIntegration はこのギャップを橋渡しします。アクティブな OTel トレースのコンテキストを読み取り、すべての Sentry イベントに trace_id と span_id を付与します。これによって、エラーが対応する OTel トレースのウォーターフォール内に表示され、逆にウォーターフォール側でもどのスパンでエラーが起きたのかがわかるようになります。
OtlpIntegration が内部で行っていること
行っているのは、次の3つです。
- OTLP exporter を構成する — DSN から導出した Sentry の取り込みエンドポイントに向けて設定します。OTel のスパンは、標準的な OTLP 経由で Sentry に流れ込みます。
- アクティブな OTel トレースのコンテキストを読み取る — すべての Sentry イベント（エラー、ログ、application metrics など）に付与し、トレースのウォーターフォール上で互いにつながって見えるようにします。
- 必要に応じて SentryPropagator を登録する — Sentry ネイティブのトレーシングを使うサービスとの互換性のためです。（この自動セットアップは全 SDK の次のメジャーバージョンで廃止され、propagation はドキュメント化されたオプトイン方式に切り替わります。）
なぜ従来のアプローチを置き換えたのか
以前の戦略は POTel と呼んでおり、Sentry SDK を OpenTelemetry と深く統合するもので、このアプローチにも利点はありました。Sentry と OpenTelemetry のスパンを同じトレース内で交互に並べられること、コンテキストの propagation が一元化されること、そして OpenTelemetry のインストルメンテーションエコシステムを最小限の手間で活用できることです。
新しいアプローチは異なるトレードオフを選んでいます。すべての Sentry SDK に OpenTelemetry との深い統合を求めるのではなく、バックエンドの各 SDK が単独で動作するようにしました。OpenTelemetry への必須の依存も、リリースサイクルへの結合もありません。その代わりにプロセス内でのスパンの交互配置は諦めていますが、対応するすべてのバックエンド SDK にわたって一貫性があり、移植しやすく、実用的な解決策が手に入ります。
より緊密な統合が必要なユーザー向けには、Java が引き続き従来の POTel アプローチをサポートします。Java では成熟した OpenTelemetry エコシステムがあり、このモデルがうまく適合します。
この integration は OTEL_EXPORTER_OTLP_TRACES_ENDPOINT と OTEL_EXPORTER_OTLP_TRACES_HEADERS から OTLP exporter の設定を読み取り、BatchSpanProcessor を備えた TracerProvider をセットアップして、トレースのコンテキストを Sentry イベントに結びつけます。すでに独自の TracerProvider を用意している場合は、integration がそれを検知して自動セットアップをスキップします。他の SDK も、それぞれの言語らしい書き方で同じパターンに従います。OTLP integration のドキュメントもあわせてご覧ください。
そして、Sentry では次のように表示されます。
POTel が生き続ける場所（と、そうでない場所）
Java は POTel が現時点で長期的な標準ルートである唯一の SDK です。Java の OTel エコシステムは成熟していて安定していて、深い統合がここでは実際の価値を生みます。Sentry のスコープの propagation、ブレッドクラムの自動キャプチャなど、ひととおり揃っています。またOTLP integration は置き換えではなく、追加の選択肢として存在します。
JavaScript (Node.js) は移行期にあります。現在、フル機能の Node.js SDK は、自動インストルメンテーション付きの OpenTelemetry を同梱しています（POTel）。あわせて、OpenTelemetry の依存を完全に取り除いた軽量モード（@sentry/node-core/light からインポート）も提供しています。こちらでもエラー、ログ、メトリクス、手動のスパンは使えますが、自動インストルメンテーションは付きません。v11 でも同様の軽量アプローチを採用しています。OTel の TracerProvider はセットアップされませんが、Sentry ネイティブの自動インストルメンテーションは利用できます。
これはどんな人に向いているのか
次のようなチームに最適です。
- すでにバックエンドのトレーシングで OTel を活用している —
TracerProviderを設定し、自動インストルメンテーションを動かし、場合によっては OTel Collector まで運用しています。それを取り払ってまで Sentry のトレーシングに移行したくはない。 - エラー管理に Sentry を使っている（または検討している） — 提供価値は「OTel のトレースはそのままに、エラー用に Sentry を加えれば、integration が両者をつなぐ。エラーをクリックすればトレースが見え、スパンをクリックすればエラーが見える」です。
- 複数言語のバックエンドを運用している — この integration は複数の Sentry SDK を横断して機能します。「Python のマイクロサービスが Go のサービスと通信し、.NET のモノリスと通信」このような組織でも、各サービスを OTel で計測し、Sentry で統合されたトレースを確認できます。
トレースとログは対応、エラーとメトリクスは非対応
得られるもの
- Sentry のトレースウォーターフォールに表示される OTel スパン。同じトレース上で Sentry のエラー、ログ、その他のイベントとひとつにつながって表示される。
- サービス間の分散トレーシング。Sentry ネイティブのトレーシングでも OTel でも対応。
- OTLP のログ取り込み（ただし後述の注意点あり）
得られないもの
- OTLP 経由のエラー — もっともよくある誤解です。エラーには依然として Sentry SDK が必要です。OTLP が扱うのはトレースとログであって、例外ではありません。OTLP exporter を Sentry に向けるだけで SDK を省こうとすると、トレースは得られてもエラー追跡は得られません。
- 同一プロセス内での Sentry と OTel のスパンの交互配置 — トレーシングシステムはサービスごとに1つを選びます。OTel のトレーシングを使うなら、Sentry SDK 側で
traces_sample_rateを設定しないでください。スパンが二重に生成されてしまいます。 - OTLP トレースなしで、エラーと結びついた OTLP ログ — ログとエラーのリンクは、共有されたトレースのコンテキストに依存します。トレーシングなしでログだけが必要なら、Sentry ネイティブのログ機能のほうが適しています。
propagation はオプトインへ
SentryPropagator の自動セットアップは、全 SDK（Python、Ruby、.NET、Java）で廃止されます。OTel はグローバルな propagator を一度に1つしか許可しないため、黙って登録してしまうと、ユーザーがすでに設定しているものと競合しかねません。混在環境で sentry-trace ヘッダーの注入が必要なユーザーは、自分でコンポジットの propagator をセットアップすることになります。
セットアップの詳細は、Sentry for OpenTelemetry または OTLP integration のドキュメント をご覧ください。
知っておくべきことは以上です。OTel はそのままに、Sentry を加えて、1つのトレースにすべての物語を語らせましょう。
Original Page: Your OTel spans, our errors: A Sentry love story in one trace
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。
