堅牢な時系列モニタリング Matrix Profile と Prophet を用いた異常検知
Article by: Ram Senthamarai, Aayush Seth 異常検知は鏡だらけの家で探偵をしているようなものです。何かがおかしいのは分かるけれど、見えているのが本当の問題なのか、それとも奇妙な反射にすぎないのか、いつも確信が持てません。 本番環境のシステムを監視するのは、絶えず形を変える干し草の山の中から動き回る針を探すように感じることがよくあります。Sentry では、お客様が従来のしきい値ベースや割合ベースのアラートを超えられるようにすることを目標にし、システム内の微妙で複雑な異常をほぼリアルタイムで検知できるよう支援することを目指しました。 本記事では、当社の AI/ML チームが Matrix Profile と Meta の Prophet を用いて、時系列の異常検知システムを開発した方法を詳しく説明します。直面した課題を取り上げ、このハイブリッドなアプローチによって、より信頼性が高く、よりインテリジェントなアラートを構築できた理由を解説します。 問題：ノイズの多いメトリクス、微妙な障害 システムメトリクスは本質的にノイズが多いものです。しかし、適切なタイミングで適切な異常を特定できるかどうかで、結果は大きく変わります。たとえば、素早い修正で済むのか、重大インシデントに発展するのか。とはいえ、自動の時系列異常検知（Time Series Anomaly Detection。以下 TSAD）は簡単な問題ではありません。 コンテクストがすべて：データのスパイクは異常かもしれませんし、週末セール、プロダクトローンチ、システムメンテナンスの影響にすぎない場合もあります。コンテクストがなければ、その違いは判別しにくくなります。 「正常」は常に変動する：パターンは時間とともに変化します。季節性、トレンド、そして突然のレジームシフト（状態の急変）によって、今日の「正常」が明日の「異常」になり得ます。 ノイズとシグナルのせめぎ合い：システムメトリクスのデータはノイズが多くなることがあります。特に大規模環境では、誤検知を連発せずに真の異常だけを検知するのは簡単ではありません。 万能解はない：各メトリクスの振る舞いは異なります。CPU 使用率、ユーザー登録数、取引量など、それぞれ特性が異なるため、状況に応じたアプローチが必要です。 ラベル付きデータがない：教師あり学習は、正解（グラウンドトゥルース）がない場合、難しくなります。多くの場合、何が異常だったのかは、実際に何かが壊れてから初めて分かります。 Sentry のスケール：何十万ものメトリクスを監視する Sentry のようなオブザーバビリティプラットフォームの規模で、この問題を解くことを想像してみてください。 要するに、自動 TSAD には、コンテクストを理解し、適応的で、精度が高く、しかもスケールすることが同時に求められます。 解決策：ハイブリッドアプローチ ARIMA、SARIMA、TimeGPT、Moirai、AutoFormer、ChatTS などさまざまなモデルで広範に実験した結果、私たちは Matrix Profile と Prophet を組み合わせたハイブリッド手法に落ち着きました。これらのモデルを組み合わせることで、時系列データにおける異常をより広い視野と、よりニュアンスのある形で理解できるようになります。 Matrix Profile：形状ベースの異常検知 […]
【Sentry Godot SDK】Logs・User Feedback など新機能追加
Article by: Serhii Snitsaruk 最初の安定版リリースを経て、Sentry Godot SDK が Windows / Linux / macOS / iOS / Android をサポートし、一般利用いただける状態になったことをお知らせし致します。1年前、いくつかのプロトタイプから本格開発をスタートし、ついにここまでたどり着きました。実績のある Sentry プラットフォーム SDK 群の上に構築されており、Godot プロジェクトに簡単に追加できる GDExtension アドオンとして提供されています。 はじめて Sentry を知る方のために説明すると、Sentry はゲームの開発中・QA 中・リリース後を通じて「健全性」を管理するためのアプリケーションモニタリングツールです。クラッシュや実行時エラー、ログ、さらにはプレイヤーからのフィードバックまで自動的に追跡できるため、バグ追いに費やす時間を減らし、そのぶん「おもしろい体験」を作ることに集中できます。 このあと、Godot SDK に含まれる主な機能をご紹介していきます。 クラッシュとエラー Sentry はエラーやクラッシュのレポートを収集し、それらを「Issue」としてダッシュボード上に自動でグルーピングします。これにより、どの問題から優先的に修正すべきかを判断しやすくなります。 Godot Engine のランタイムエラーやスクリプトエラーを自動で捕捉し、詳細なスタックトレースを表示します。必要に応じてローカル変数やメンバー変数の情報、さらに可能な場合はその前後のスクリプトソースコード行まで確認することができます。 C++ レイヤーで発生したクラッシュについては、Sentry が minidump を収集・送信できます。これにより、ゲームがいつ、Godot のソースコードのどこでクラッシュしたのかを把握できます。この情報をもとにクラッシュの原因を理解したり、スタックトレース（または minidump ファイル）を Godot の開発者と共有したり、自分たちで問題を修正したりすることが可能になります。 […]
【webvitals.com 登場】サイトを遅くしている原因を見つけよう！
Article by: Anton Bjorkman, Sergiy Dybskiy 開発者が求めているのは、「ツールを実行して、数字を見つめて、落ち込むだけ」のウェブサイトではありません。なので、私たちは、まったく違うものを作りました。 WebVitals は、サイトの分析・最適化・高速化を、ひとつの場所でまとめて行えるサービスです。スタックトレースや遅いクエリに日々向き合っているメンバーが作ったこのツールは、パフォーマンス指標と、実際にユーザー体験を遅くしている原因とのつながりを浮かび上がらせます。 この 1 つの場所で、次のことができます。 実際のユーザーがあなたのサイトをどう体験しているかを把握する 最大の遅延要因をすぐに見つけ出す 専門用語や勘に頼ることなく、「次に何をすべきか」がはっきり分かる webvitals.com の仕組み ドメインを入力して「Go」を押せば、あとは WebVitals にお任せです。 裏側では、WebVitals が Vercel AI SDK を使って、いくつかのツールコールを実行します。 1つは Google の PageSpeed API：過去28日間の実ユーザーのパフォーマンスデータ、いわゆる CrUX データを取得します。 もう1つは Cloudflare の URL Scanner：サイトで使われている技術スタックを検出します。 これらの結果を組み合わせて分析し、本当に重要なポイントだけが浮かび上がるようにしています。 何がうまくいっていて、どこに改善余地があるのかが一目でわかります。各レポートでは、CrUX データを踏まえながら、指標を改善するための具体的でコンテキストのある次のステップを提示します。 なお、CrUX データは「実ユーザーの実際の利用データに基づく各指標の 75 パーセンタイル値」です。 Core Web Vitals レポート […]
うまく機能していたメトリクス製品をあえて終了させてゼロから作り直した理由
Article by: David Rosenthal 2年前、Sentry は「紙の上では」完璧に見えるメトリクス製品を作りました。ところが、自分たちでドッグフーディングしてみると、それが本当にお客様の求めているものではないことに気づいたのです。ローンチ予定の 2 週間前、私たちはそのプロダクト全体をお蔵入りにしました。 ここでは、その過程で得た学び、なぜ従来型の時系列メトリクスがモダンなアプリケーションのデバッグでは破綻してしまうのか、そして私たちがそのシステムをどのようにゼロから作り直したのかをお話しします。 最初のメトリクス製品がイマイチだった理由 2年以上前、Sentry では開発者向けのメトリクス製品をつくろうと動き始めました（私が Sentry に入社する前のことです）。その結果、ほとんどのオブザーバビリティプラットフォームが通ってきた道、メトリクスを事前に集計し、時系列データとして保存するというアプローチを選ぶことになりました。この方法であれば、エンドポイントのレイテンシやリクエスト数といった指標を効率よく、かつ高速に追跡できるはずでした。 そして実際、私たちのチームは成功しました。個々のメトリクスを追うだけなら、高速で低コストに動いていたのです。 しかし Sentry には、社内で自分たちのプロダクトを徹底的に使い込む「ドッグフーディング」の文化があります。この仕組みを実際の現場で使い始めたとき、すぐに問題点が見えてきました。それは、同じ設計思想のメトリクス製品が必ずぶつかる古典的な課題、いわゆる Cartesian product problem（デカルト積問題） でした。 ご存じない方のために説明すると、従来型のメトリクスでは新しい属性を 1 つ足すたびに、その属性の値ごとに新しい時系列データを保存しなければなりません。たとえば “server” 属性にサーバー名を入れるなら、サーバー名ごとに別々の時系列が必要になります。さらに複数の属性で分解したければ、それらの値のすべての組み合わせに対して時系列を持たなければなりません。これはすべて「事前集計」をする以上、あらかじめ「どんな問いを立てるのか」を決めておく必要があるという根本的な制約から生じています。 もちろん、これは常に大問題になるわけではありません。30台のサーバーのメモリ使用量を追跡するとか、その 16 コアそれぞれの CPU 使用率を見る、といった用途だけなら、従来のやり方でも十分に機能します。 しかし Sentry のゴールは、「コードが壊れたときに、開発者がデバッグして修正するためのリッチなコンテキストを提供すること」です。そのために、開発者は状況を理解しやすくするための属性やコンテキストをできるだけたくさん付けたくなります。ところが、コンテキストを増やせば増やすほどコストが爆発していくとなると、開発者は「本当は取りたいコンテキスト」を諦めざるを得ません。 社内でこのプロダクトを使っていたエンジニアたちは、常に「欲しいコンテキスト」と「払えるコスト」のあいだで板挟みになっていました……。これは、明らかに良くない状態でした。 カーディナリティという女王様 例を見てみましょう。 仮に、個々のタイムシリーズを保存するコストが 1 本あたり月 $0.01 だとします（業界的にもだいたいこのオーダー感です）。そして、ある特定のエンドポイントのレイテンシを追跡していて、そのエンドポイントは 1 日あたり 10 万回呼ばれているとしましょう。ここまではよくある状況です。 ここに、開発者 A がやってきて、「どのサーバー（8 […]
【Size Analysis（Early Access）】モバイルアプリサイズを可視化・最適化
Article by: Max Topolsky, Nico Hinderling これは「man.jpg」です。 なぜか、トヨタの iOS アプリにはこのファイルが含まれており、そのサイズは無視できない 14.6MB でした。都合よく、発覚から数か月後に man.jpg は削除されましたが。 本記事は、man.jpg をアプリに含めるべきだったかどうか、あるいは man.jpg をどれだけ小さくできたか（MB）について論じるものではありません。本記事の主題は、今日から Sentry の Size Analysis を使えば、すべての開発者がアプリサイズの問題を簡単に検出し、修正できるということ（さらに、人気のオープンソースアプリのサイズを 30% 削減する方法 😉）です。 Size Analysis（現在 Early Access）紹介 Size Analysis は、モバイルアプリのサイズを監視し、削減するための機能です。 Sentry が Emerge Tools を買収したことを覚えている方もいるかもしれません。Size Analysis は Emerge の最初の製品であり、Spotify、Square、Tinder などのチームがアプリをできる限り軽量化してリリースするために活用していました。 そして今、Sentry アカウントを持っているすべての開発者が、同じツールを利用できるようになりました。 Size Analysis 使い方 Size Analysis […]
【Emerge Tools】Sentryの一部に
Article by: David Cramer 本日（2025/5/6）、Emerge Tools が Sentry に加わることを発表できることを大変嬉しく思います。 Emerge は、世界の主要ブランドから信頼される最高水準のモバイル向けツールを開発しています。同社チームのたゆまぬ 努力 によってモバイル ビルドを改善してきた取り組みを、皆さんもどこかで目にしたことがあるかもしれません。Sentry では以前からその姿勢を高く評価してきました。 そして実際に Emerge の共同創業者である Josh と Noah に初めて会ったとき、私たちは同じ世界観を共有していることを感じ、すぐに意気投合しました。 モバイル分野は、私たちの業界において常に複雑な存在でした。重要であることは誰もが認める一方で、しばしば軽視されてきた領域でもあります。これまでモバイル特化型のツールが数多く登場してきましたが、モバイルを二の次とする大手ベンダーに取って代わられることも少なくありませんでした。 Sentry では、モバイルアプリケーションをビジネスの重要な延長線上にあるものと捉えています。それは新しい顧客と最初に接する接点の一つであり、テクノロジースタックの他の要素と同等の注目と投資を受けるべき領域です。 市場のリーダーたちはこの重要性を理解していますが、多くの企業はいまだ追随段階にあります。OpenAI は、ChatGPT の体験が iPhone、Android、またはウェブ上のどこであっても快適な体験を提供することが、いかに重要かを深く理解しています。Spotify も同様に、顧客が持つあらゆるデバイス上で自社を存在させる必要があります。DoorDash や Tinder が今のクオリティを維持していなければ、Z 世代の生活はどうなっていたでしょうか。優れたモバイル体験は、私たちが毎日頼りにしているブランドにとって不可欠なものです。 現在の Sentry は、ユニバーサルかつ最高水準のクラッシュレポートおよびアプリケーションモニタリングで広く知られています。そこに Emerge Tools が加わることで、モバイルチームに次のような新たな機能を提供していきます。 アプリをより小さく軽くし、インストール率の向上とユーザー満足度の向上を実現 不要なコードを削除し、バグを減らすとともに、Sentry のコストについて CFO と議論する時間を削減 社内配布を効率的に管理し、残されたバグを顧客ではなく自社チームで発見 ビジュアルリグレッションテストを活用し、サインアップボタンが消えるような問題に再び悩まされることを防止 これはほんの始まりにすぎません。Emerge の専門知識と既存プロダクトが加わることで、皆さんがすでに愛用している機能をさらに強化し、本番監視の枠を超えたサポートを拡張していきます。 私たちはバグを捕まえることを仕事としていますが、本音を言えば、それを未然に防ぎたいのです。 今回の発表および今後の展開については、Emerge […]
段階的にブラウザのトレーシングを改善
Article by: Lukas Stracke ブラウザのトレーシングは、うまく機能しているあいだは「存在を感じさせないもの」です。しかし、一度それがうまく動かなくなると、たちまち強烈な存在感を放ちます。トレーシングが正しく機能していれば、実環境におけるアプリケーションの挙動を明確に把握でき、具体的で行動につながるインサイトが得られます。一方で、トレーシングがうまく機能していない場合、そこにあるのはノイズだらけのデータ、欠落したトレース、そして何も語ってくれないスパン。つまり、何の手がかりも得られない状況です。私たちはここ数か月、この問題に少しずつ取り組み、着実に改善を重ねてきました。 ここでは、Sentry の JavaScript SDK に施した改善を順に見ていき、ブラウザトレーシングを「より正確にする」だけでなく、「より有用にする」ための取り組みをご紹介します。ページロードスパンを明示的に制御できるようにすることから、リダイレクトのより賢い取り扱い、リソーススパンにおけるより深いタイミングデータの追加まで。これらの更新は、推測を減らし、本当に重要なものを前面に出すことに主眼を置いています。 ページロードスパンを明示的に終了する 提供開始：10.13.0 私たちの SDK では、規定でページロードやナビゲーションのスパンは「アイドルスパン」として開始されます。このアイドルスパンは、子スパン（例：fetch リクエストのスパン）が継続的に開始・終了されるかぎりアクティブな状態を維持し、一定時間アクティビティが途絶えると自動的に終了します。 なぜこの方式なのでしょうか。それは、「ページが完全に読み込まれた」と言える普遍的な指標が存在しないからです。 初回レスポンスの受信後でしょうか。すべてのスクリプトやリソースのロード完了後でしょうか。それともアプリケーションのハイドレーションやブートストラップ完了後でしょうか。 たしかに、ブラウザには domContentLoaded や readyStateChange のようなシグナルも存在しますが、初期の体感的なページロードに関わる処理がその後に続くケースも少なくありません。現実として、フレームワークや Web アプリの多様性、そして一般的な JavaScript のカオスを踏まえると、この問いに万能な答えはありません。 私たちのアイドル化とデバウンスの仕組みは、ユーザーの 95% にとって十分に機能しており、概ねページロードの所要時間に納得いただけています。しかし一部のユーザーからは、「ページの読み込み完了をアプリケーション側から Sentry に明示的に通知したい」という要望も寄せられていました。そこで用意したのが、Sentry.reportPageLoaded() です。 enableReportPageLoaded: true と Sentry.reportPageLoaded() を併用すると、アイドル機構の大部分が取り除かれ、代わりにユーザーが完全に制御できるようになります。 コールバック外でのアクティブなスパン 提供開始：10.15.0 バージョン 8 で NodeJS SDK に OpenTelemetry を導入した際、私たちは旧来のトランザクション中心の API を新しい […]
【Session Replay】自分自身がデジタル上のシークレット・ショッパーになる
Article by: Kyle Tryon 本ブログの内容 リアルな顧客インサイトのために Session Replay を有効化する チェックアウト離脱とカート放棄の原因を診断する Session Replay を使って放棄カートを Sentry で確認する 自分のショップを次のステップへ 小売店が長年にわたってショッピング体験の測定と改善のために頼ってきた秘密兵器… それが「シークレット・ショッパー」です。 彼らは一般の客を装い、顧客体験を評価します。たとえば見つけにくい商品の特定、接客品質の評価、チェックアウトプロセスのスムーズさなど、摩擦が生じる箇所を見つけ出します。彼らが収集するデータは、偏りのない実践的なフィードバックの代理として機能し、店舗運営者はそれを基に顧客体験を改善し、コンバージョン率を高め、平均注文額を増やします。 しかし、eコマースでは小規模なサンプルや代理顧客に頼る必要はありません。Session Replay （セッションリプレイ）のようなツールを使えば、実際の購買者の行動を大規模に分析できるのです。さらに、ユーザーのセッションを「再生」して、彼らが実際に見たものをクリックごとに正確に確認することもできます。 リアルな顧客インサイトのために Session Replay を有効化する Session Replay は、ユーザー体験をまるで動画のように再現し、その時に発生したログ、エラー、トレースなどの関連情報をすべて紐づけて記録します。これにより、ユーザーが実際にどのような体験をしているのかを、当時のコンソールログなどと突き合わせながら確認することができます。 これは、ユーザー自身に報告を依頼せずに問題を診断できる非常に優れた方法です。詳細な説明やスクリーンショット、動画を求める代わりに、実際に何が起きたのかをそのまま見ることができるのです。 しかも、これは単なるエラーデバッグツールにとどまりません。「どこで迷い、どこで操作フローが途切れ、デザイン上の選択が体験にどう影響しているか」といったユーザーの行動パターンを可視化することもできます。 導入をするには、まず自分のオンラインストアのフロントエンドフレームワークに対応する正しい SDK を選び、Replays 機能を有効化した状態で Sentry を追加します。もし Shopify の Hydrogen を使ってアプリを開発している場合は、React Router SDK を利用することができます。 以下は、ご自身のアプリに簡単に組み込めるシンプルな React のセットアップ例となります。 エラー発生時や通常のセッションなど、状況に応じて Session Replay のキャプチャ率（録画割合）を個別に設定 […]
ベータ期間中に Sentry のユーザーフィードバックウィジェットを使って Logs を形作った方法
Article by: Jasmin Kassas Sentry では、私たちは公開の場で開発を行い、迅速に対応しています。しかし、スピードを重視することで、最初の試みで全てがうまくいくとは限りません。そこで役立つのがフィードバックです。フィードバックはうまくいっている点を検証し、不足している部分を特定し、エラートラッキングだけでは把握できない問題を明らかにする助けになります。 数か月前に Logs のベータ版をリリースしたとき（ちなみに先週 GA になったのでぜひご覧ください）、私たちはエラーやパフォーマンス監視だけでは明らかにならないもの（壊れているのに気付かれないもの、静かに失敗しているもの、あるいは単にユーザーを混乱させているもの）を見つける方法が欲しいと考えていました。そこで、Sentry のユーザーフィードバックウィジェットをプロダクトにそのまま組み込みました。 つまり、開発者がつまずいたとき、そのフィードバックにはリリースバージョン、環境、URL、さらには実際に起こったことのセッションリプレイといった、私たちに必要なすべてのコンテキストが付随していました。 その結果、Logs はより速く進化し、信頼性が高まり、開発者（私たち自身を含む）が実際に使いたいと思えるものへと変わりました。 フィードバックを機能と修正に変える ユーザーフィードバックウィジェットは単なる意見収集の箱ではなく、Logs ベータ期間中に私たちが実際に出荷したものを形作りました。 明確な例のひとつが 自動リフレッシュ機能 です。開発者から「ログストリームを自動的に更新してほしい」という要望が繰り返し寄せられていました。私たちもそれが重要であることは認識していましたが、優先順位を上げるには至っていませんでした。しかし、タグ付きのフィードバック提出が積み重なっていくうちに（製品固有のフィードバックを素早く確認するには、URL タグでフィルタリングしています）、その継続的なシグナルが優先度を押し上げました。そして、4週間でフィードバックから機能へと進化し、現在では稼働中の自動リフレッシュ機能をリリースするに至りました。 また、アラート機能に対する強い要望も寄せられました。これを受けて、ログベースのアラートをサポートし、認証エラーや設定の欠落といった重要なログが現れたときにユーザーへ通知できるようにしました。 しかし、このウィジェットは製品リクエストのためだけのものではありません。最も重要なのは、エラートラッキングだけではすぐに明らかにならなかった重大な SDK の問題を表面化させてくれた点です。それによって、私たちは次のような問題を特定し、解決することができました。 Python SDK のバグ：ログ属性を正しく収集していなかった。Python 標準ライブラリのロガーとのログ統合を最初に実装したとき、生成されたログメッセージに名前付きパラメータを付与していませんでした。この API がそのようにも利用され得ることを、ユーザーから指摘を受けるまで気付いていませんでした。 JavaScript SDK の問題：特定のオブジェクトのシリアライズが原因で、ログメッセージが正しくレンダリングされないことがありました。これは、JavaScript SDK でコンソール計測を通じて生成されたログを作成する際に、文字列を連結する方法に起因していました。修正自体は単純でしたが、[Object Object] が紛れ込んでしまうのは簡単だということを思い出させるものでした。 JavaScript SDK のより深刻なバグ：環境とリリースの属性がログに正しく付与されない問題がありました。原因は単純で、これらの属性をログに付与する際に正しいフォーマットを使用していなかったことです。しかし、私たちのプロダクトはリリース値や環境値をトップレベルのフィルタやデータの関連付けに依存しているため、ユーザーにとって多くの問題を引き起こしました。 フィードバック提出には、環境、組織ID、プロジェクト名、URL といった技術的なコンテキストが含まれていたため、私たちはサポート対象プラットフォーム全体に修正を出荷し、Logs をより信頼性の高いものにすることができました。その結果、Logs はフロントエンドの体験においても、基盤となる SDK インフラにおいても、開発者が期待する通りに動作するようになりました。 […]
Sentry Logs 一般提供開始（ログはログ…でもついに実用化）
Article by: Dhrumil Parekh 本ブログの内容 何も壊れていないように見えても、裏で起きていることがわかる ジョブの実行（あるいは失敗）をリアルタイムで監視 UI のリグレッションが雪だるま式に膨らむ前に検知 これまでの反響は？ Logs の始め方 私たちが Sentry に Logs 機能を構築し始めたとき、目標は一つでした。それは、単なる大量のテキストストレージではなく、実際のデバッグに役立つものにすることです。そのために、初日から「トレースと接続」させることにしました。 これにより、アプリケーション内で発生するアクションやパフォーマンスとログを密接に結びつけ、開発者がエラーやパフォーマンス、レイテンシの問題を調査するまさにその場所で活用できるようにしたのです。 現在、Logs はベータ版を終了し、すべてのユーザーに一般公開されました。さらに嬉しいことに、ベータ期間中に皆さんから要望のあった数多くの機能を追加しています。 ライブテーリング（Live Tailing）：ログをリアルタイムにストリーミングし、修正の確認、長時間実行されるジョブの監視、または問題が発生した瞬間の特定に利用できます。 アラート（Alerts）：特定のログパターン（例: 繰り返される payment_status=declined）に基づいてトリガーし、ユーザーが報告する前に失敗を把握できます。 ダッシュボード（Dashboards）：ログの傾向を時系列で可視化します。たとえば Safari でのエラーレートの上昇や、新しい機能フラグに関連する突然のスパイクを確認できます。 チェックアウトの失敗、不安定なジョブ、ページロードの遅延。どんなデバッグであっても、Logs は重要なコンテキストを提供します。そして、それらの Logs が他のテレメトリー（トレース、エラー、リプレイ）と結びつけば、根本原因をより早く突き止めることができます。タブの切り替えも、タイムスタンプの計算も不要。ただ答えがあるだけです。 ここからは、Logs がどのようにして面倒な問題のデバッグを簡単にするのか、その実例をご紹介します。あるいは、今すぐドキュメントを参照してログ送信を始めて頂いても構いません。 何も壊れていないように見えても、裏で起きていることがわかる トレースと接続されたログは、見過ごされがちなサイレントな失敗を見つける フロントエンドは checkout.request を送信し、バックエンドは 200 を返し、問題は記録されません。例外も投げられません。 しかし、ユーザーは注文確認を受け取っていないと報告してきます。 Sentry でトレースを開くと、checkout.request のスパンは正常に見えますし、処理は成功しています。しかし、本来その後に続くはずの非同期処理 order.processed のスパンがありません。 checkout.request のスパンをクリックすると、そのスパンにスコープされたログが表示されます。 […]