OTel span、Sentry のエラー：ひとつのトレースが紡ぐラブストーリー
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 […]
Sentry + OTLP で .NET の MongoDB クエリをトレースする
Article by: James Crosswell（読了時間：6分） あなたの .NET アプリが MongoDB とやり取りしているなら、遭遇しうるパフォーマンスの問題を効果的にデバッグできるようDB のパフォーマンスを計測できるようにしたいと、まず間違いなく考えるはずです。 そのためには、どのデータベースコマンドが実行されていたのか、どれくらいの時間がかかったのか、そしてそれが一度きりの小さな異常なのか、それともより大きなパターンの一部なのかを知る必要があります。理想を言えば、そのトレースから、関連するエラーやリプレイへと、手作業でつなぎ合わせることなく移動できるようにもしたいところです。 この記事では、まさにそれを実現する方法を次のものを使って紹介します。 MongoDB に組み込まれた OpenTelemetry インストルメンテーション .NET SDK での Sentry の OTLP 取り込みサポート エンドツーエンドの流れを示す、小さなサンプルアプリ 一通り終える頃には MongoDB のスパンとクエリデータを Sentry 上で確認し、次のように掘り下げられるようになります。 なぜこのアプローチなのか Sentry ユーザーのために MongoDB のインストルメンテーションを実現する方法は基本的に2つ考えられます。 1つは、独自の ActivityListener とカスタムのマッピングロジックを備えた専用の Sentry.MongoDB インテグレーションを構築して保守する方法です。これでも機能はしますが、その一方で保守すべきカスタムコードが増え、テレメトリモデル間の変換が増え、説明すべき特殊なインテグレーションがもう1つ増える、ということでもあります。 私たちが選んだのはもう1つの方法である OpenTelemetry を活用し、OTLP 経由で Sentry にスパンを送る方法です。MongoDB はすでに OpenTelemetry 互換の Activity データを出力しており、Sentry も今では OTLP […]
Next.js は最初からリクエストをトレースしている ー OpenTelemetry でエクスポートする方法
Article by: Kyle Tryon （読了時間：7分） トレースは情報の宝庫であり、あなた自身、あるいは AI が遅いページを見つけて修正する助けになります。 Next.js は標準で トレーシング をサポートしています。受信リクエスト、fetch() 呼び出し、ミドルウェア、サーバーサイドレンダリングはすべて配線済みで、OpenTelemetry 互換のバックエンドにトレースを送信する準備が整っています。 ただし落とし穴があります。エクスポーターを設定しない限り、それらのトレースを目にすることはありません。 数行のコードと @vercel/otel ライブラリの助けを借りれば、アプリケーションは OpenTelemetry データを受け付けるあらゆるプラットフォーム（Sentry を含む）にトレースをエクスポートできます。（また OTLP と Sentry SDK のどちらを選ぶべきか迷っている方のために、その点についても解説します。） なぜ Next.js のトレースが重要なのか Next.js アプリのページが遅いとき、難しいのはリクエストのどの部分が原因なのかを突き止めることです。原因はミドルウェアかもしれませんし、サーバーサイドレンダリング、API ルート、データベースクエリ、上流への fetch() 呼び出し、あるいは自分で書いたカスタム関数かもしれません。 リクエストが実際にどう実行されたかのトレースがなければ、症状から逆算して作業を進めることになります。ローカルで再現し、ログを追加し、ボトルネックになりそうな箇所を推測し、本番環境が自分のマシンと同じ挙動をすることを願う、という具合です。 トレーシングを使えば、各 API 呼び出し、ページロード、データベースクエリなどが、実行タイムライン上の スパン として記録されます。トレースは 1 つのリクエストから生まれたすべてのスパンをウォーターフォールとしてまとめるため、どこで時間が費やされたかを正確に確認できます。 このトレースでは、最上位の GET /api/auth/[…nextauth] スパンが受信リクエストを表しています。その下に、Next.js がリクエストの各ステップごとに追加のスパンを作成します。ページコンポーネントの解決、API ルートの実行、レスポンスの開始といった具合です。この完全な階層構造があれば、そのリクエスト中にどこで時間が費やされたかを正確に把握できます。 Node ランタイム では、このタイムラインを独自のカスタムスパンで拡充し、各トレースにアプリ固有のコンテキストを追加していくことになります（具体例は後ほど紹介します）。 Edge ランタイム […]
【Sentry & OpenTelemetry】併用する方法
Article by: Lazar Nikolov 要約：バックエンドがすでにOpenTelemetryを使っているなら、環境変数をいくつか変更するだけでトレースとログをSentryへ送信できます。SDKの置き換えも、インストルメンテーションの書き直しも不要です。OTLPエクスポーターの送信先をSentryのエンドポイントに向け、フロントエンドにはブラウザコンテキスト用のSentry SDKを追加するだけで、クリックからバックエンドのスパンまで1本につながったトレースが手に入ります。 バックエンドはすでに OpenTelemetry でインストルメントしている。サービスはスパンを出力している。チームは OTel の API に慣れている。すでに Collector を運用しているかもしれない。そこで Sentry を評価し始めると、当然こんな疑問が生まれます。 OpenTelemetry の構成を Sentry SDK に置き換える必要があるのだろうか。 答えはノーです。 現実的な答えとしては、OpenTelemetry がすでに機能しているところはそのまま使い続け、より多くのアプリケーションコンテキストが得られる箇所に Sentry SDK を追加し、OpenTelemetry Protocol（OTLP）イベントを Sentry に送信する。Webアプリであれば、フロントエンドにはブラウザトレーシング、エラー、ログ、Session Replay、ソースマップのために Sentry SDK を使い、バックエンドの既存サービスインストルメンテーションには OpenTelemetry をそのまま使う、というケースが多いです。 スコープの補足：OTLPはトレース、ログ、メトリクスを扱えます。現時点では、SentryのOTLPインジェストはログとトレースをサポートしており、メトリクスはサポートしていません。将来的にサポートを追加することを検討しています。 重要なのは、よく混同されがちな2つの判断を分けて考えることです。 フロントエンドとバックエンドでトレースをどのようにつなげるか。 バックエンドのOTLPイベントをどのようにSentryへエクスポートするか。 この2つを分けて考えると、アーキテクチャがずっとシンプルに整理できます。 Sentry vs OpenTelemetry は問い方が間違っている 最初の判断はトレースの連結です。ユーザーがReactアプリのボタンをクリックし、そのクリックがバックエンドへのリクエストをトリガーする場合、フロントエンドとバックエンドは同じ分散トレースコンテキストで合意する必要があります。この例では、Sentry フロントエンド SDK […]
【Stripe Projects】2つのコマンドで Sentry が利用可能に
Article by: Burak Yiğit Kaya 2つのコマンドだけで、エラーモニタリング、パフォーマンストレーシング、セッションリプレイを備えた完全に構成済みの Sentry プロジェクトをゼロから立ち上げることができます。 サインアップフォームも、メール認証のステップも、ダッシュボードを行き来して DSN をコピーして .env に貼り付ける作業もありません。アカウントは作成され、プロジェクトはプロビジョニングされ、5つの環境変数が作業ディレクトリに生成されて、そのまま SDK が読み取れる状態になります。 そしてコーディングエージェントを使っている場合でも同じです。ただしその場合、コマンドを入力する必要すらありません。「エラーモニタリングを追加して」と伝えるだけです。 仕組み Sentry は Stripe Projects のプロバイダーとして追加されました。Stripe Projects は、開発者（および AI エージェント）がターミナルから直接インフラサービスを発見・プロビジョニング・管理できる CLI ワークフローです。アプリが実行時に依存するサービスのためのパッケージマネージャのようなものだと考えると分かりやすいかと思います。 全カタログはこちらです。 デプロイ可能なサービスは2つ（Sentry プロジェクトと Seer AI）、プランは3種類。すべて CLI から管理できます。課金は既存の Stripe の支払い方法を通じて行われるため、Sentry 側で別途請求設定を行う必要はありません。 「エージェントに指示するだけ」という部分 stripe projects init を実行すると、プロジェクト内にエージェントスキルのファイルがスキャフォールドされます。 これらは、Claude Code や Cursor などのコーディングエージェントに Stripe Projects […]
【Sentry】Perforce 連携 正式リリース
Article by: Amir Mujacic 要約 Sentry が Perforce P4 とネイティブ連携するようになりました。これにより、Perforce を利用するチームでも、スタックトレースのリンク、suspect commit の特定、オンデマンドのソースコンテキスト表示、P4 Code Review との連携を利用できます。integration の導入はこちらから始められます。 Perforce と Sentry の連携 ゲーム開発、VFX、あるいは大容量のバイナリアセットを扱う業界で働いているなら、あなたのコードベースは Perforce P4 上にある可能性が高いでしょう。Perforce P4 は、世界でも最大級のゲームやクリエイティブプロジェクトを支えるバージョン管理システムです。そして、これまで Sentry が正式サポートしていなかった最後の主要 SCM のひとつでもありました。 本日（2026年4月29日）、その状況が変わります。Sentry + Perforce P4 integration が、すべての Sentry organization 向けに正式リリースされました。 利用できる機能 この integration により、P4 サーバーを Sentry と直接接続できるようになり、Git ベースのチームが長年利用してきた、ソースコード連携型のデバッグワークフローを利用できます。 スタックトレースリンク […]
【OpenTelemetry】既存トレースをSentryに送信
Article by: James W. アプリにOpenTelemetryを組み込むのに何ヶ月も費やしてきたはずです。それを新しい可観測性バックエンドに移行するためにすべてやり直すという選択肢は現実的ではありません。 SentryのOTLPエンドポイントを使えば、その必要はありません。実際のところ、必要なのは環境変数を2つ設定するだけで、既存のトレースがSentryのトレースエクスプローラーに表示されるようになります。 SentryのOTLPサポートは現在オープンベータです。つまり、すぐに利用を開始できますが、いくつかの既知の制限があります（これについては後ほど説明します）。 なぜOTLPなのか：計測はそのままに、送信先だけを変更する OpenTelemetryを使用する最大の利点は、計測がベンダーに依存しないことです。計測コードはOpenTelemetryの標準APIを使用し、OTLP（プロトコル）はそのデータを対応する任意のバックエンドに送信します。つまり、いくつかの設定を変更するだけで、いつでも可観測性バックエンドを切り替えることができます。 次のような場合に特に有効です。 すでにOpenTelemetryエコシステムに大きく投資している場合 計測の柔軟性を維持したい、またはスタックの他の部分ですでにOpenTelemetryを使用している場合 一方で、ゼロから始めてSentryのみを使用する場合は、ネイティブのSentry SDKの方が、すべてのSentry機能（spanイベント、Session Replay、プロファイリングを含む）を完全にサポートしています。OTLPサポートはまだベータであり、いくつかの制限があります。本ガイドの後半で両者を比較します。 前提条件 開始する前に、以下が必要です。 Sentry アカウント（無料プランで問題ありません） Node.js 18以上がインストールされていること Express.jsの基本的な知識 まだSentryプロジェクトを作成していない場合は、ここで作成してください。作成時にはプラットフォームとしてExpressを選択します。DSNの設定手順はスキップして構いません。代わりにOTLPエンドポイントを使用します。 SentryのOTLP認証情報を取得する Sentryはプロジェクトごとに専用のOTLPエンドポイントを提供しています。 取得方法は以下の通りです。 左側のサイドバーでSettingsをクリックします。 SettingsサイドバーのOrganizationセクションでProjectsをクリックします。 一覧から対象のプロジェクトを見つけてクリックし、プロジェクト設定を開きます。 プロジェクト設定のサイドバーで、SDK Setupセクション内のClient Keys（DSN）をクリックします。 OpenTelemetryタブを選択し、ExpandボタンをクリックしてすべてのOTLPエンドポイントの値を表示します。 Sentry UIで「Settings > Client Keys（DSN）> OpenTelemetry」タブを開き、OTLPエンドポイントが表示されている画面 このタブは開いたままにしておいてください。次のステップで以下の値を使用します。 […]
【Sentry SDK】アップグレードが必要な状態かもしれません
Article by: Sergiy Dybskiy Session Replay、Structured Logs（構造化ログ）、AI Monitoring（AIモニタリング）、Automatic OpenTelemetry Tracing（自動 OpenTelemetry トレーシング）、Feature Flag Tracking（フィーチャーフラグトラッキング）。もしこれらをあなたの Sentry ダッシュボードで見かけていないなら、その理由はおそらく SDK のバージョンにあります。 @sentry/react、@sentry/nextjs、@sentry/vue、@sentry/angular、@sentry/sveltekit、あるいはその他の @sentry/* パッケージのいずれを使っていても、これらはすべて同じバージョンで管理されています。v10 はそれらすべてを指しています。 ここで重要なのは、npm のダウンロード数に基づくと、Sentry の JavaScript SDK のインストールの約半分が、いまだに v8 もしくはそれ以前にとどまっているという点です。 データ 主要な @sentry/* パッケージについて、npm のダウンロード統計を取得しました。2026年3月時点での週間インストール数は以下の通りです。 パッケージ 週間合計 v7のまま v7 + v8 合計 @sentry/node 14.9M 4.8M (32%) 7.3M (49%) @sentry/browser 14.5M 3.2M […]
OTLP を使って OpenTelemetry のログを Sentry に送る方法
Article by: James W. もしすでに OpenTelemetry でアプリを計装しているなら、Sentry を使うためにわざわざ外す必要はありません。環境変数を2つ設定するだけで、Logs を Sentry に送れるようになります。SDK の変更も再計装も不要です。この記事では、サンプルアプリでの設定方法とネイティブ Sentry SDK を使うべきケースについてご紹介します。 なぜネイティブ SDK ではなく OTLP を使うのか OTLP の主な利点は、ログ記録のコードを特定のオブザーバビリティ基盤から切り離したままにできることです。数行の設定を変更するだけで、ログの送信先を切り替えられます。 次のような場合に役立ちます。 すでに OpenTelemetry によるロギングを導入している ログを複数のバックエンドに送りたい ベンダー中立な計装が必要である OpenTelemetry をデフォルトで使用する AI や LLM のフレームワークを扱っている より広い OpenTelemetry のエコシステムを活用したい 一方、ゼロから導入するのであれば、必要なのが Sentry のみの場合は ネイティブの Sentry SDK のほうが適しています。ネイティブ SDK では、Logs からの Issue 作成、Session Replay […]
SentryがXcodeBuildMCPを買収
Article by: Cameron Cooke, Josh Cohenzadeh 本日（2026年2月11日）、Sentry が XcodeBuildMCP を買収したことを発表いたします。XcodeBuildMCP はオープンソースの MCP サーバーで、AI エージェントにネイティブのiOS／macOS アプリをビルド、テスト、デバッグする機能を提供します。 XcodeBuildMCP はエージェント型の Apple プラットフォーム開発における定番ツールとなっており、GitHub のスター数は4,000を超え、活発なコミュニティがあります。ビルド、実行、デバッグ、操作、検証という開発ループ全体を解放し、ユーザーが好みのエージェント型開発環境にとどまったまま作業できるようにします。 この買収の一環として、XcodeBuildMCP の作者兼メンテナーである Cameron Cooke も Sentry のチームに加わり、Sentry のモバイル向けツール群、そして新しいエージェント型開発の環境を継続的に改善していく取り組みを支えてくれます。 なぜ Sentry に適しているのか Sentry はソフトウェアの信頼性を高め、開発者がアイデアから本番環境へ最短で到達できるようにすることに注力しています。モバイルチームにとって、この道のりは依然として困難であり、そのため私たちは2025年に Emerge Tools を買収しました。 Apple プラットフォーム向けのツールはエージェント的なワークフローへの採用が再び遅れており、開発者たちはますます重厚な IDE よりも Cursor や Claude Code、Codex CLI のようなツールで作業を行うようになっています。 XcodeBuildMCP はそのギャップを埋めるのに役立ちます。開発者が持つ現実世界での能力をエージェントにも与えることで、自律的に反復し、人間に都度コントロールを戻すのではなく、変更を検証できるようになります。 XcodeBuildMCP で可能になること 主な機能は以下のとおりです。 […]