【Log Drains 提供開始】プラットフォームログを直接Sentryへ
Article by: Allison Rogers, Paul Jaffre Sentry は Log Drains に対応しました。これにより、アプリケーションコードの変更や手動でのプロジェクトキー検索をすることなく、簡単にログを Sentry へ転送できます。すでに別の場所にログがある場合でも、コード変更なしで、Sentry上でエラーやトレースと並べて確認できるようになりました。 すぐに試したい方は、クイックスタートガイド をご確認ください。 ログを1か所に集約し、Issue のコンテキストと関連付ける 2025年9月に Sentry で Logs を一般提供した際の目的は、ログ、トレース、エラー、リプレイを単一のプラットフォームで確認できるようにすることでした。そしてフィードバックで特に多かったのは、「適切なログが適切な Issue にデフォルトで紐づいていてほしい」という点でした。 「Sentry をアプリに統合したところ、急に「もうひとつ目が増えた」ように感じています。私たちは Logs にも活用していて、デバッグが大幅に楽になりました。Sentry がエラーを報告すると、関連するログがその場ですぐに確認できます。もうひとつ大きな利点は、各ログエントリにユーザー情報が自動でタグ付けされることです。そのため手作業で付ける必要がありません。」 Log Drains を使用することで、プラットフォームのログ（およびトレース）が自動的に Sentry に流れ込み、アプリケーションコード外のプラットフォームレベルのイベントにも「もうひとつの目」が届くようになります。 「例を見せてほしい」と思った方は DevEx チームが Sentry で Vercel ログについて説明する動画をご覧ください。 アプリケーションのエラーやトレースと一緒にプラットフォームのログを一箇所に集約することで、チームはビルド、デプロイ、エッジランタイム、データベース、認証レイヤーにわたるシステムの動作を全体的に把握できます。追加のエージェントを実行したり、アプリケーションコードに触れたりする必要はありません。 ダッシュボードを行き来したり、ログの保持期限が短いせいで大切な情報を失ったりすることなく、エンジニアは Sentry上でエンドツーエンドに問題を調査できます。 今すぐ始める：すべてのプランで5GBのログが含まれています（追加分は1GB$0.50）。 チームはどのように Log […]
2025年もオープンソースのメンテナーに75万ドルを支援
Article by: Chad Whitacre 2025年も Sentry は日頃から頼りにしているオープンソースのメンテナーに、まとまった金額を拠出しました。これで5年連続（2024、2023、2022、2021）になりました。 これは私たちが Open Source Pledge を立ち上げて以来、最初のレポートです。 この Pledge は、コミュニティの独立したメンテナーに対する敬意を共有する企業を集めるものです。Pledge メンバーは立ち上げ以来、合計で 450 万ドルをオープンソースのメンテナーおよび財団に支払ってきました。もう言い訳はできません。企業がメンテナーに支払う時代は現実です。あなたもこの流れに参加してください。:-) いつもどおり、私たちの主要な配分（37.5 万ドル）の詳細は thanks.dev（TD）で確認できます。 これが一番簡単な方法です。thanks.dev にあなたの会社を登録して、依存しているプロジェクトのメンテナーに支払いましょう。Pledge の最低基準（開発者 1 人あたり年間 2,000 ドル）を満たし、さらにブログで発信してくれれば、私たちはあなたの会社をそのリストに追加します。参加する企業が増えるほど、参加する企業はさらに増え、オープンソースのエコシステムはより強く、よりレジリエントになります。 私たちは引き続き Open Source Collective / Ecosyste.ms Funds（7.5 万ドル）や GitHub Sponsors（5 万ドル）とも取り組んでいます。 thanks.dev と同様に、Ecosyste.ms Funds も複数のプロジェクトをまとめて支援しやすくしてくれますが、特定のエコシステムで私たちが実際に使っている依存関係を見て、どのプロジェクトを使っているかを判定する仕組みはありません。ただし、彼らの全体データは非常に優れているため、私たちは依存しているエコシステム全体に広く支援が行き渡るよう、10% を彼ら経由で拠出しています。 残念ながら、Microsoft はこの 1 年で Sponsors を事実上停止しました。Universe でも Sponsors 関連の発表はなく、AI […]
100ms未満のEC体験 Speculation Rules APIによる瞬時ロード
Article by: Lazar Nikolov Eコマースでは、スピードが収益に直結することは、皆さんご存じだと思います。私も知っていますし、皆さんも知っているでしょう。Amazonも、eBayも、Shopifyも、誰もが認識している事実です。この記事では、製品詳細ページやカートページ、チェックアウトページといった重要なページのパフォーマンスをどのように向上させることができるかをご紹介します。Speculation Rules API（SRA）を活用して、これらのページをプリレンダリング/プリフェッチし、さらにNext.jsのような特定のフレームワークが提供する独自のプリフェッチ機構についても説明します。 Speculation Rules API SRAは、現在 Chromiumブラウザでのみ利用可能な実験的な機能で、ウェブサイト側から「ユーザーが次にどのページを訪れる可能性があるか」をブラウザにヒントとして伝えることができます。ブラウザはそのヒントをもとに、あらかじめページをプリロードまたはプリレンダリングし始めます。これにより、そのページへの遷移がほぼ瞬時に感じられるようになります。 プリレンダリングルール（prerender rules）は、ブラウザに対して対象ページを「見えないタブ」の中で完全にダウンロードし、レンダリングし、読み込むよう指示します。これにはすべてのサブリソースの読み込み、すべての JavaScript の実行、さらに JavaScript から開始されるデータフェッチも含まれます。プリレンダリング済みページへの遷移は即座に完了します。文字通り、ブラウザが「すでに完全に読み込み済みのタブに切り替える」だけの動きになります。 プリフェッチルール（prefetch rules）は、ブラウザに対してページのドキュメント本体だけをダウンロードさせます。バックグラウンドでページをレンダリングしたり、JavaScript を実行したり、サブリソースを読み込んだりはしません。ナビゲーション時のメインドキュメントの HTTP リクエストをスキップするだけで、その後のレンダリングやリソースの読み込みは通常どおり必要になります。それでもパフォーマンスは大きく改善されますが、プリレンダリングルールに比べると処理はかなり軽量です。 これらのルールは、ページ内に <script type=”speculationrules”> 要素を追加し、その中で JSON 形式で定義します。 上記の speculation rules によって、そのページ内に存在する /products/* にマッチするすべての URL が積極的にプリフェッチされ、さらに /cart ページも 同様に処理されます。これらのルールをどのように追加するかは問いません。<head> の末尾にハードコードしてもよいですし、JavaScript でランタイムに動的生成してもかまいません。これらのルールには「締め切り」はなく、ブラウザは DOM 内でルールを見つけた瞬間にプリフェッチやプリレンダリングを開始します。 どれだけ積極的に先読みするかや、さまざまな種類のマッチャーやセレクタ、その他の注意点についてもオプションが用意されていますが、この記事では取り上げませんので、詳しくは必ずMDN の Speculation rules APIのドキュメントを確認してください。 […]
ゲームコンソール向けクラッシュレポートが正式リリース
Article by: Bruno Garcia TL;DR：主要なゲームコンソール向けのエラーモニタリングとクラッシュレポートが、正式に利用可能になりました（加えて、Unreal Engine SDK v1.1 もリリース）。これ以上の説明が不要でしたら、以下はスキップして、『リリースに含まれるものは？』のセクションにジャンプしてください。 10年以上前、ある顧客が自分のPlayStation 3のゲームに Sentry をハックして組み込みました。そこから時を経て、Sentry はいまでは Web、モバイル、デスクトップを横断して数千ものゲーム開発者をサポートしています。 欠けていたピースはなんでしょうか。 それはコンソールです。開発者からの要望を受けて、私たちはそれを実現しました。今年初めにベータとして提供を開始した後、主要なすべてのプラットフォームでコンソールサポートが正式リリースとなり、開発者が優れたゲーム体験を構築・提供するための新たな道を切り拓きました。これでスタジオは、クラッシュダンプに溺れることなく、構築・ローンチ・成長に必要なツールを手に入れることができます。 さらに、Unreal SDK、Unity SDK、カスタムエンジン向けの Sentry Native SDK とも緊密に統合され、すでに大規模な本番環境で稼働しています。 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 「Sentry のクラッシュレポート機能は、私たちが VALORANT を Xbox Series や PS5 コンソールでローンチするうえで不可欠でした。Riot 規模で対象とするすべてのプラットフォームをサポートするカスタムクラッシュ収集ソリューションを構築するのは、非常に複雑になっていたでしょう。Sentry はその問題を解決してくれたため、私たちはプレイヤーにより良いゲームを届けることに専念できるのです。」— Daniele Giannetti, Riot Games Inc. リリースに含まれるものは？ このリリースにより、開発機や市販デバイスを問わず、致命的・非致命的イベント（完全なネイティブクラッシュ対応を含む）の全コンテキストを一元的に取得できるようになります。 もはやクラッシュダンプを手動で取得したり、リキャップサーバーを立てたり、プラットフォームごとに複数のクラッシュレポートツールを使い分けたりする必要はありません。 リリースに含まれるもの 可読性の高いスタックトレース：問題が何で、どこで発生したのかをすぐに特定できる 組み込みのシンボルサーバー：デバッグファイルを直接 Sentry にアップロード可能 カスタムシンボルサーバー対応：単一かつ統一されたフォーマットを含む、多様なシンボルサーバーレイアウトをサポート タグとデバイスコンテキスト：コンソールモデル、ビルド番号、リージョン、デバイスの状態などを取得し、特定の地域、リリース、ハードウェアで問題が発生しているかどうかを把握可能 クラッシュ時のスクリーンショット：問題が起きる直前にプレイヤーが何を見ていたかを正確に確認できる […]
PlayStation・Xbox・Switch・PC・モバイル どのプラットフォームでもSentry がバグの修正をサポート
Article by: Sasha Blumenfeld ボス戦でのフリーズでも、マルチプレイ中の突然の切断でも、クラッシュは没入感を壊し、プレイヤーを怒らせてしまいます。しかも各プラットフォームごとに異なるエラー報告システムがある中で、これらの問題をデバッグするのは非常に困難です。 Riot Games、Epic Games、Unity を含む 1,500 社以上のゲーム企業が Sentry を使用して自社プロダクトを監視しており、当社はゲームエンジンおよびコンソールとの統合サポートを継続的に拡充しています。Unreal Engine、Unity、Godot、社内エンジンのいずれで開発していたとしても、PlayStation、Xbox、Nintendo Switch 向けに出荷していても、Sentry は本番環境におけるクラッシュ、エラー、パフォーマンス問題を分散したログを探し回ったり、プラットフォーム固有のツールを切り替えたりすることなく追跡できます。 Sentry を使えば、すべてのプラットフォームで発生したネイティブクラッシュや例外を一箇所に集約できるため、こうした問題を簡素化できます。読みにくいメモリアドレス（長い 16 進数の数字列）と格闘する代わりに、Sentry はシンボル化されたスタックトレースを提供し、どの関数のどのコード行がクラッシュを引き起こしたのかを正確に示してくれます。 以下のような充実したコンテクスト情報を得ることができます。 読みやすいスタックトレースやパンくずリストにより、クラッシュ直前のプレイヤーの操作、エンジンイベント、システム動作を記録。何が壊れたかだけでなく「何が起きたのか」を把握できます。 ビルド番号やOSバージョンの追跡により、クラッシュが特定のアップデートに関連しているのか、古いシステムを使用しているプレイヤーのみに影響しているのかを判断できます。 クラッシュ時のスクリーンショットを記録し、ゲームが停止する直前のプレイヤーの視点を把握できます。 クロスプラットフォームでの可視化により、コンソールの問題を認証の障害となる前に解決できます（パブリッシャーに「なぜリリースできなかったのか」と説明することは、誰にとっても望ましくありません）。 開発用キットでは正常に動作していたにも関わらず、市販のハードウェア上で突然クラッシュが起き始めた… という場合でも、Sentry なら、原因（たとえば物理エンジン内のヌルポインタ例外）を正確に突き止め、プレイヤーの怒りが爆発する前に修正することができます。 Nintendo Switch 向けゲームで Sentry を使用するには、Nintendo のサーバーを設定してクラッシュ情報を Sentry に自動で転送するようにします。まずは Nintendo の CRPORTAL から始めてください。 Xbox 向けには、Microsoft の GDKX Middleware 認証ページで Sentry を見つけて、そこから導入を開始できます。 そして最後に、PlayStation 向けには Tools & […]
Sentry と Pinia との組み合わせで、Vue と Nuxt のエラートラッキングを強化する方法
Article by: Steven Eubank 本番環境で問題をデバッグする際に大切なのは、その瞬間のコンテキストです。 Sentry はすでにスタックトレースやパンくずリスト、ユーザー情報などの豊富なエラーデータを提供していますが、エラーが発生した時点でアプリケーションがどんな状態だったのかまでが分かれば、再現手順や修正方法が迅速に得られ、リリースに大きく役立ちます。 Sentry の Pinia 統合は、まさにそれを実現してくれる機能です。エラーが発生した時点で Pinia の状態を自動的にキャプチャするため、Vue または Nuxt アプリケーションでどんな問題が発生したのか詳細まで把握できます。 それでは、Vue および Nuxt アプリケーションで実際に導入する手順を確認していきましょう。 Sentryでショッピングカートの不具合も素早くデバッグ Pinia のパイナップルロゴ🍍にインスパイアされた「Pineapple Paradise」というオンラインストアを例に挙げてご紹介します。 この Vue アプリでは、Pinia を使ってショッピングカートの状態を管理しています。 オンラインストアが期待通りに動作する方法を模倣していて、ユーザーは商品を閲覧し、ショッピングカートに追加します。アプリの状態管理は全て Pinia が担っています。 以下はショッピングカートの状態を管理するコードのシンプルな例です。 Vue アプリに Sentry と Pinia の統合を追加する Sentry のPinia統合をセットアップするのは、他のフレームワークと同様にとても簡単です。 main.js ファイルで、Sentry Vue SDK をインポートし、必要なオプションで init メソッドを呼び出し、次に pinia.use(createSentryPiniaPlugin()) を呼び出すように追加すれば完了です。 以下はその例です。 アプリの状態から不具合のコンテキストを見つける 例えば今、ユーザーが好きなパイナップル関連の商品でチェックアウトしようとした瞬間、サイトがクラッシュして購入を諦めてしまったとします。 このとき関連するすべてのコンテキストと共にエラーイベントが Sentry に自動送信され、次のような情報が記録されます。 […]
アプリを高速化し、インフラコストを削減！サーバーサイドキャッシュの活用術
Article by: Will McMullen もし100ミリ秒未満の応答時間に驚いたことがあるなら、その背後には「キャッシュ」がある可能性が高いでしょう。 キャッシュは、システムのパフォーマンスを支える縁の下の力持ちです。よく使用されるデータを保存しておくことで、データベースやAPIへのアクセスを減らし、アプリの応答速度をミリ秒単位で短縮します。 今回はキャッシュがどのように機能するのか分解し、代表的な活用事例をご紹介していきます。 キャッシュとは？ キャッシュは、データの通り道に置かれる短期的な記憶装置のようなものです。よくアクセスされる情報を、時間のかかるデータベースや外部APIから毎回取り出すのではなく、すぐ使えるように一時的に保存しておきます。 動作の流れはとてもシンプルです。 最初のアクセス（キャッシュミス） まずアプリは指定されたキーに対応するデータがキャッシュにあるかをチェックします。なければ、アプリは時間やコストのかかる処理（たとえばデータベースクエリ）を実行し、その結果をキャッシュに保存してからユーザーに返します。 2回目以降のアクセス（キャッシュヒット） 次回、同じデータが必要になった場合は、データベースを介さずキャッシュから直接取得します。このルートは非常に高速で、ユーザー体験が一気に向上します。 キャッシュはスピード感のあるUXを実現したり、インフラの負荷を軽減したりするうえでとても頼れる存在です。理論上、どのようなデータもキャッシュできますが、特によく使われるのは以下のようなものが挙げられます。 コストの高いクエリの結果 「ユーザーXのカート情報」や「特集商品」のように、何度も同じ結果が返されるデータ 計算されたメトリクスや分析結果 毎回計算し直す必要がなく、元データが更新された時だけ再計算すれば良いデータ 静的アセット 画像やフォント、CSSなど、普段は変更されないものの頻繁に使用されるデータ それではキャッシュを設定して、実際にパフォーマンスのメリットを確認してみましょう。 PythonでシンプルなRedisキャッシュを設定する 「キャッシュと言えば Redis」と呼ばれるほど、世界中の開発者に使われている信頼性の高いオープンソースのツールです。 私が気に入っている説明は Simon Willison のワークショップで耳にした『Redis は素晴らしい小さなサーバー』というひと言です。Redis はインメモリで動く Key-Value 形式でデータを保持します。 またデータベースやキャッシュ、メッセージブローカーとしても使用されています。とにかく高速で効率的なことが特徴で、リアルタイムに動作することが求められるアプリケーションにピッタリです。 今回はこの Redis を使って、データベース呼び出しをキャッシュかすることに焦点を絞ります。Redis の導入で、たとえ開発用のノートPCでも 1秒あたり数十万件の処理をミリ秒単位で処理できるようになります。 メモリ上に保存するため高速ですし、キャッシュだけでなく永続性や原子性のあるストレージとしても活用できます。主要な SQL や NoSQL の負荷を軽くし、全体のパフォーマンス改善にもつながるというわけです。 Redis を導入するためにデータベースを移行したり設定を大きく変えたりする必要はありません。Pythonを使って PostgreSQL のキャッシュ層として […]
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の日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。