【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 ベースのチームが長年利用してきた、ソースコード連携型のデバッグワークフローを利用できます。 スタックトレースリンク […]
【Application Metrics】シグナルを追跡し、スパイクを把握し、トレースへジャンプする
Article by: Ben Coe 要約：Application Metrics をリリースしました。これは、アプリケーション内の重要なシグナルを追跡するための新しい仕組みです。コンテキスト付きでユーザーの状況を把握し、問題がエラー化する前に検知できるようになります。 数週間前、私たちは Session Replay に関するバグに遭遇しました。1,000 を超える動画セグメントが読み込まれると、一部ブラウザで Replay が失敗していたのです。しかし、それがどの程度発生しているのか、誰に影響しているのかが分かりませんでした。さらに、この障害は必ずしもエラーを生成するわけではなかったため、影響を受けたユーザーを特定して再現する手段もありませんでした。 以前であれば、span やログを使って調査していたでしょう。しかしそれでは扱いづらい面があります。span はサンプリングされることが多く、外れ値を見逃す可能性があります。ログは構造化が弱く、時間とともに内容が変化しやすいものです。どちらも調査用途には向いていますが、既知の振る舞いを継続的に追跡するには、メトリクスのほうが適しています。 そこで私たちは、Sentry SDK 内で user 属性と provider 属性付きのメトリクスを設定し、1,000 セグメントを超えるセッションをフィルタリングしました。その結果、数分で再現ケースを特定できました。 これこそが、Application Metrics の役割です。追跡したいシグナルを記録し、あとで必要になるかもしれないコンテキストを紐付けておくこと。何か問題が起きたときには、必要なデータがすでにそこに揃っています。 事前集計されたカウンターではなく、完全なイベント インフラストラクチャテレメトリの追跡向けに設計されたメトリクスツールは、多くの場合、データを集計します。その過程で、ユーザー、IP アドレス、リージョンといった情報は削ぎ落とされます。残るのは単なるカウンターです。 Sentry の Application Metrics は、user のような高カーディナリティ属性を含む完全なイベントを保存します。そのため、「アプリケーション全体でチェックアウト体験が遅かったか」だけではなく、「東海岸のユーザーに対してチェックアウト体験が遅かったか」や、「特定ユーザーのスケジュールジョブがキューの滞留を引き起こしていたか」といった問いにも答えられます。 同じ SDK、コード1行で利用可能 最近の Sentry SDK を使っていれば、メトリクス機能はすでに有効化されています。新しい依存関係やサイドカーは不要です。必要なのはコードを1行追加するだけです。 主に使うことになるメトリクス型は、次の3つです。 Counter — 何かが発生するたびに数値を加算します。payment.declined、search.zero_results、email.failed のようなものです。アラート対象にしたい発生率や合計値の追跡に向いています。 Distribution — 何かが発生するたびに値を記録し、その分布を分析します。そのジョブはどれくらい時間がかかったか？ […]
SentryとOpenTelemetryによるAspire Insightsの本番稼動対応
Aspire 101 .NET8のリリースに伴い、Microsoftは分散アプリケーションの作り方を大きく変える.NET Aspireと呼ばれる新しいフレームワークをリリースしました。 Aspireは、.NETでの分散アプリケーションの構成とデプロイを簡単にします。 詳細については、Aspireのドキュメントを参照してください。 Aspireを使用してアプリケーションをビルドすると、以下のような利点があります。 OpenTelemetryのログ、メトリクス、トレース ヘルスチェック サービスディスカバリー .NETでのオーケストレーション（KubernetesやDockerの設定ファイルに潜る必要なし） その他多数 Aspireには、”リソース”（Aspireでは分散システムの様々なコンポーネントを “リソース “と呼ぶ）から生成されるテレメトリを簡単にナビゲートできるダッシュボードが付属しています。 これらすべてが、かなりクールな開発者体験をもたらします。 そして、我々は、OpenTelemetry データを Sentry と簡単に共有することができます。Sentry は、テレメトリーデータから得られる全ての洞察に加えて、Sentry が提供する全てのクールなもの（クラッシュレポート、ソースマップ、.NET でビルドされていない分散アプリケーションコンポーネントを計測する機能など）を提供してくれます。 また、Sentryを使えば、開発現場でも生産現場でも、このインストルメンテーションを利用することができます（現在、Aspireのダッシュボードは開発者のみの体験となっています）。 では、どのように配線するのか見てみましょう！ 注：以下のすべてのソースコードはGitHubで入手可能です。 基本的なAspireソリューションの作成 Aspire を使い始めるための良いチュートリアルがいくつかあるので、ここでは詳しく説明しません。 まず、ツールのセットアップが完了したら、コマンドラインから新しい aspire ソリューションを作成します。 これは、最小 API (ApiService)、Blazor フロントエンド (Web)、Aspire ソリューションのバックボーンとなる 2 つのプロジェクト (AppHost と ServiceDefaults) から構成される aspire-starter テンプレートを使用して、新しい Aspire ソリューションを作成します。 ServiceDefaults には、ソリューション内のすべてのプロジェクトに共通する設定を配線するためのさまざまな拡張メソッドが含まれています。 AppHostはすべてのオーケストレーションに使用され、開発マシン上ですべてをパワーアップしたいときに実行するアプリケーションです。 便利なダッシュボードも含まれています。 ダッシュボードには、分散アプリケーションの各「リソース」に対応するURLへの便利なリンクに加え、それぞれのログ、トレース、メトリクスが表示されます。 Sentry でそれを見ることができたら、素晴らしいと思いませんか？ […]
ソースマップのアップロードエラーを修正する方法
すべての変数と関数名を含むソースコードが含まれていないスタック・トレースは、開発者が問題の根本原因を分析することを困難にさせます。 Sentry には、根本原因分析において開発者を支援する重要な機能があります。 Sentry では、ソースマップをアップロードすることができます。 これにより、元のソースコードにマップバックすることができ、コード内の問題の原因をより簡単に理解することができます。しかし、Sentyにソースマップをアップロードすることは困難です。 このガイドでは、ソースマップのアップロードを試みたもののエラーが表示されてしまう場合の対処方法をご説明します。 最も一般的なアップロードの問題を解決するために、再確認すべき事項やベストプラクティスについて詳しくご紹介します。 まだソースマップをアップロードしていない場合は、以下の1行のコードからプロセスを開始しましょう。 npx @sentry/wizard@latest -i sourcemaps Sentryのソースマップの使い方 スタックトレースにオリジナルのソースコードを表示するには、Sentry はイベントペイロード内のスタックトレースを、そのリリースまたはビルド用にアップロードされたソースマップと照合する必要があります。 そのために、Sentry は「Debug IDs」と「release + abs_path」に基づく2つの照合方法を提供します。上記のコマンドでウィザードを実行すると、どの方法があなたのアプリに有効かを判断するのに役立ちます。 ウィザードを実行してアップロードした後、どの方法を使用しているかを確認することができます。 設定 > プロジェクト > [プロジェクト名] > ソースマップページから、アップロードしたファイルにアクセスすることで確認できます。バンドルを開き、ファイル名の下に Debug ID があるか確認します。 デバッグIDが表示されていれば、現在デバッグIDが設定されているということになります。 デバッグIDが表示されない場合は、リリース+abs_pathマッチングに設定されているということになります。 Sentryでは、より簡単にセットアップするために、Debug IDの使用を推奨しています。 release + abs_pathマッチングを使用している場合でも心配ありません。このアップロードプロセスのデバッグ方法についてもご説明します。 デバッグIDアップロードエラーの修正 デバッグIDは、ソースマップをアップロードするための推奨される方法です。これは release + abs_path アプローチの欠点を無くしたものです。Debug IDのサポートを追加することで、リリースを作成する必要がなくなります。Sentry はパス（信頼性に欠ける可能性がある）に依存するのではなく、Debug ID で圧縮されたソースとソースマップのペアを一意に識別しバインドします。これにより、Sentry はパスを確認することなく、最小化されたソースと対応するソース マップを識別することができます。 以下は、デバッグIDを使用したソースマップ・アップロード・エラーをデバッグするためのトラブルシューティング・チェックリストです。 1. SDKバージョンをアップグレードする： SDKがデバッグIDを使用できることを確認してください。issueの詳細ページの下部に、イベントが送信されたSDKが表示されます。 […]
OpenTelemetry対応開始のご案内： オブザーバビリティ（可観測性）データの有効利用
Sentryは、2008年にサイドプロジェクトから成長していたオープンソース企業です。 現在では、350万人以上の開発者たちに利用されるアプリケーションパフォーマンス監視（APM）プラットフォームへと拡大しています。Sentryは、オープンソースと開発者たちのコミュニティにコミットしています。 また私たちは、コミュニティに対してオープンで透明であることにコミットしています。 Sentryは、ソフトウェアを構築するために、パブリックアプローチをとっています。 OpenTelemetry（またはOTel）の対応とインテグレーションは、Sentryにとって非常に自然なパートナーシップです。 何千もの企業がOpenTelemetryを使用して、サービス全体のデータを取得しています。 生ログ、トレース、メトリクスをキャプチャすることで、ソフトウェアのパフォーマンスを改善するための最初のステップが始まります。 OpenTelemetryを使用している開発者は、Sentryの最新のAPMを使用できるようになりました。 SentryのAPMツールは、開発者たちを第一に考慮して作られています。 私たちは、すべてのオブザーバビリティ（可観測性）データを実用化します。SentryとOpenTelemetryを使用する開発者たちは、パフォーマンス問題の根本原因をより迅速に特定し、解決することができるようになります。 Sentryは、Golang、Node.js、Python、Ruby、Javaをサポートしており、近日中に.NETがそこに加わります。 これにより開発者たちは、SentryのパワーとOpenTelemetryが設定されたアプリケーションからのパフォーマンスデータを組み合わせることができます。また開発者たちは、問題の原因となっているコードや関数の行を突き止めることができるようにます。 多くの無駄なデータを分析したり、ツール間を行き来したりする必要はもうありません。 Sentryは、利用者がより速く修正にたどり着くために必要な答えを見つけることを可能にします。 OpenTelemetryとSentryの連携を開始する Sentryは開発者優先のツールであり、簡単な導入プロセスを提供することで、開発者が複雑な設定に時間を費やすことなくコード作成に集中できるよう設計されています。 OpenTelemetryのインテグレーションは、設定も簡単です。 ソフトウェアに数行のコードを追加するだけで、すぐにSentryでテレメトリーデータを見ることができるようになります。 一度設定すれば、自動的に読み込みの遅いページのトレースが開始されます。 問題の原因となっているAPIコールやKafkaキューまで、簡単に確認することができます。他にも関連するエラーがあれば、Sentryはそれらも表示し、発生している可能性のある他のエラーと結びつけます。 Sentryは、問題を迅速に解決するために必要なすべてのデータ背景情報を提供します。それはまるで、ソフトウェアにGPSを搭載しているようなものです。Sentryは問題の原因を直接指摘してくれます。 SentryとOpenTelemetryを使い始めるのは、早くて簡単でした。私たちがSentryを選んだ理由は、どこでなぜ遅延が発生しているのかを理解できるからです。 迅速に修正し、ユーザーからのクレームを防ぐことができます。 Dominik Sandjaja シニアソフトウェアエンジニア @bex technologies GmbH Open TelemetryとSentryを使用して、ソフトウェアをより速く修正 顧客が注文をするためにチェックアウトページにたどり着きました💰。すべてがうまくいったように見えます。でも、errors.errorString（別名：無効な製品ID）が原因でサイレントクラッシュが発生し、支払いのフローが壊れてしまいました。顧客は注文を完了できず、怒りのソーシャルメディア投稿💸を書き始めます。 Sentryは、これを解決するのに役立つことができます*。Sentryはそのエラーを捕捉し、OTelのトレースデータと組み合わせます。Sentryは警告を発し、コードのどこに問題があるのかを正確に示します。 自動グループ化を用い、Sentryのフィード画面に個々の課題が表示されます。Sentryは、すべてのユニークなインスタンスをグループ化します。また、OTelからのトレースとスパンを同様に使用することもできます。Sentryは、エラーと問題を引き起こした関連する分散サービスを結びつけます。 問題が特定されたら、SentryのGithubとの強固なインテグレーションを活用し、その分散システムのコードをどのチームやエンジニアが所有しているかを見つけることができます。そして、そのチームをSentryから直接担当に割り当てることができます。 担当者らは、誰とも会話する必要もなく、修正作業を開始し、本番環境にリリースすることができます🪄。 Sentryは、アプリケーションコードの健全性を監視するための不可欠なツールです。エラー追跡からパフォーマンス監視まで、開発者たちは、フロントエンドからバックエンドまで、アプリケーションをより明確に理解し、より迅速に問題を解決し、継続的に学習することができます。Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの監視機能を提供しています。 毎月Sentryは、インターネット上で最も人気のある製品から数十億の例外処理を行ってしています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。