【Sentry Snapshots ベータ公開】スナップショットテストでビジュアルリグレッションを検出
Article by: Max Topolsky（読了時間：6分） 要約 — Sentry Snapshots がベータ公開されました。（英語記事公開日2026/6/11）CI でスクリーンショットの差分を検出し、意図しないビジュアルの変更を検知、フロントエンドを持つあらゆるプラットフォームに対応。まずはSnapshots のドキュメントから始めてください。 Sentry Snapshotsは、コミットのたびにスクリーンショットを比較し、表示内容に変更があった場合はPRをブロックして、その変更が意図したものかどうかを確認できます。ユーザーが実際に目にし、操作するのはコードではなくアプリケーションです。Snapshotsは、そのユーザー体験を手軽に検証するための仕組みです。 コードの変更はかつてないほど簡単になりましたが、同時に、スピードのために品質を犠牲にする可能性も高くなっています。現代のコードベースには、正しさを担保するためのガードレールが必要です。Snapshots でめざしているのは、コードへのチェック機能と、ワークフローを改善するためのリソースを提供することです。 スナップショットテストとは スナップショットテストの基本的な流れはシンプルです。 コードを変更する アプリケーションのスクリーンショットを生成する そのスクリーンショットをベースラインと比較する 変更箇所を表示する Sentry Snapshots では、スクリーンショットをアップロードすると差分を比較し、差分があれば PR にコメントします。 その後 UI に移動して、具体的にどのような変更があるかを確認できます。 このシンプルなワークフローにより、ビジュアルのカバレッジという新しい軸が加わり、異なるテーマ・言語・ビューポートでアプリケーションが期待通りに表示されているかをテストできます。スナップショットテストは、意図した以上の変更が行われていないかを検証します。 Sentry Snapshots とエージェントの連携 従来からビジュアル変更に対するガードレールとして利用されてきたスナップショットテストは、AIエージェントによる開発でも特に有効です。たとえ雑なプロンプトでエージェントが変更を加えたとしても、スナップショットテストを実行し、変更が検出されればPRをブロックできます。 しかし Snapshots はエージェントが「活用する」アーティファクトにもなり得ます。最近、Snapshots 自体のビジュアル変更を行う際に Snapshots を活用した流れをご紹介します。 課題 複数のユーザーから「Snapshot Toolbar」に関して似たようなフィードバックが寄せられていました。 最初に表示される赤い「差分マスク」の意味が分からない マスクを非表示にしたいが方法が分からない（実際には可能） 差分ビューを切り替えたいが、操作方法が見つからない 要するに、既存機能の見つけにくさが課題でした。 […]
ダッシュボードをエージェントで作成・編集する新しい方法
Article by: Ben Coe , Steve Zegalia AIエージェントが当たり前になった世界では、チームが重要な KPI を追跡するためにビジュアライゼーションを手作業でじっくり組み上げていく、従来型のダッシュボードワークフローは終わりを迎えつつあります。 数年前、エージェントがあらゆる場面で利用されるようになる前、私たちは開発者が重要なユーザー体験を監視しやすくしようと取り組んでいました。その成果として Insights ページを導入しました。これは事前に設定されたダッシュボードで、Web Vitals や Mobile Vitals といった一般的な健全性シグナルをあらゆる Sentry ユーザーがすぐに活用できるようにしたものです。 考え方は正しかったものの、問題がありました。多くの企業が共通のシグナルを持つ一方、各組織はそれぞれ固有の事情を抱えています。意味のあるカスタマイズができなければ、ほとんどのチームは結局、手作業でダッシュボードを構築する作業を延々とこなす羽目になっていました。そこで私たちは改善を続けました。 オンデマンドでカスタマイズ可能なダッシュボードをついに現実のものにしたのは、大規模言語モデルです。ビジュアライゼーションは、人間にとってもエージェントにとっても、最も情報密度の高いコミュニケーション手段のひとつであり続けていますが、変わったのはそのビューを作成するコストです。 ウィジェットをひとつひとつ組み合わせてダッシュボードを作る代わりに、エージェントに指示して Sentry 上で直接ダッシュボードを作成・編集したり、Sentry CLI で他のモデルと連携して目的に合わせたダッシュボードを生成したりできるようになりました。 Insights ページはSentry Built Dashboards になりました。クローンし、エージェントにプロジェクト向けのカスタマイズを依頼できます。ダッシュボードは数秒で作成でき、プロジェクトや調査の期間中使い続け、必要がなくなれば廃棄することができます。 新機能まとめ エージェントによるダッシュボード作成・編集（ベータ版）： AI 機能が有効化されているすべての組織で、エージェントを活用したチャット体験を通じて Sentry でダッシュボードを作成・編集できるようになりました。 Insights が Sentry Dashboards に： Insights ページをクローンし、編集可能な Sentry Dashboards に置き換えました。特定のユースケースに合わせてカスタマイズできます。 Sentry CLI によるダッシュボード作成・編集： 新しい Sentry CLI を使って、ターミナルから […]
Sentry にプロダクト分析はもう揃っている
Article by: Rahul Chhabria 必要なものは、すでに手元にそろっています。 Sentry を使っているなら、トレース、構造化ログ、そして新たにアプリケーションメトリクスもあるはずです。多くのチームはデバッグ目的にしか使っていませんが、実はそのデータで、別チームが管理し、別のデータモデルを持ち、別の費用がかかる専用アナリティクスツールに投げていたプロダクトの大半の問いに答えられます（すべてではありません。ギャップについては後ほど正直にお伝えします）。 この記事は、プロダクトアナリティクスツールの存在意義を問うものではありません。開発者がプロダクトインサイトの宝の山の上に座りながら、その問いを他の誰かに外注してきたという事実についての記事です。そうしなくていいのです。 これが今、5年前より重要な意味を持つ理由があります。「プロダクトマネージャー」と「ソフトウェアエンジニア」の境界が曖昧になりつつあるからです。アップタイムやレイテンシだけでなく、採用率・リテンション・ユーザー行動まで考えることが、エンジニアにも求められるようになっています。プロダクトエンジニア（最近はもはや「エンジニア」と同義になりつつありますが）であれば、デバッグに使っているツールで、プロダクトに関する問いの答えを得ることができます。そういう使い方をしてこなかっただけで。 プロダクトの問いはすべて、手元のテレメトリにマッピングできる 「今週、オンボーディングを完了したユーザーは何人いるか？」 これはカウンターメトリクスです：metrics.count(“onboarding.completed”, 1)。プランの種類、国、流入元など、すでに設定している属性でスライスできます。 「地域別のチェックアウトレイテンシの p95 はどれくらいか？」 これはスパンのディストリビューションです。トレースにはすでにタイミング情報があります。あとはクエリするだけです。 「火曜日にサインアップが落ちたのはなぜか？」 これは構造化ログです。サインアップサービスは signup.failed を reason: email_validation_error や deploy_sha: a3f9b2c といった情報と一緒にログに記録しています。そのログはすでに、リクエスト全体のライフサイクルを示すトレース、エラーが発生したスパン、それを引き起こしたリリースと紐づいています。トレースからワンクリックで Issue に移動でき、Issue からコミットと原因となったコードの行へたどり着けます。 PM がアナリティクスツールに投げているのと同じ質問です。違いは、自分のテレメトリから答えるとき、その答えにはコンテキストが伴う点です。アナリティクスツールは「何が起きているか」を教えてくれます。テレメトリは「何が起きているか」「なぜ起きているか」、そして「責任のあるコードへの直接の道筋」までセットで教えてくれます。 あるクライアントから最近、こんな話を伺いました。アナリティクスツールが問題を知らせてくれるのは被害が出た後ばかりで、先手を打ちたいと。そのクライアントが辿り着いた答えは、すでに収集しているテレメトリにアラートとモニターを設定することでした。ビジネス上重要なメトリクスが下降傾向を示し始めたとき、週次のダッシュボードレビューで気づくより前にアラートが発動します。そしてそのアラートは完全なトレースと繋がったスパンやメトリクスに紐づいているため、別ツールへのコンテキストスイッチなしに、最初からコンテキストを持った状態で調査を始められます。収集するデータを変えたわけではなく、それをどう監視するかを変えたのです。 実際どのようなものか 新しいエクスポート機能のユーザー採用状況を把握したい、パフォーマンスを確認したい、有料ユーザーと無料ユーザーの挙動の違いも見たい、というケースを考えてみましょう。 アナリティクスツールへのインストルメントチケットを作成する必要はありません。スパン、構造化ログ、アプリケーションメトリクスという3つの基本要素がすでに手元にあります。 リクエストレベルのコンテキストにはスパン。 スパンはリクエストがシステムをどう流れ、各処理にどれだけ時間がかかっているかを示します。エクスポート API ハンドラーにはすでにスパンがあります。そこにビジネスレベルの属性（プランでスライスできる export.user_tier など）を追加しましょう。 採用状況、パフォーマンス、エラーを一か所でクエリしてみましょう。 すでにストーリーが見えてきます。xlsx エクスポートは csv の 3〜4 倍遅く、無料プランの xlsx は […]
正常に見えるダッシュボードに潜む危険信号
Article by: Milin Desai 最近、ある企業の開発責任者（会社名は出せないのですが）からこんなふうに言われました。 「あなたのおかげで、本当にユーザーに影響を与える問題を見つけて解決できました。次は、それが標準的な SLO やシステム指標よりも重要だということを CTO に納得してもらう必要があります。」 CTOがシステムと基本的な稼働時間を測定するのは間違いではありません。ただ、それは基準線にすぎません。だれもがあらゆるものを監視しようとしていますが、ユーザーに関係することについては何も見えていないのです。 従来型モニタリングの罠 稼働率は素晴らしい。レイテンシはSLOの範囲内。エラーバジェットも問題ない。ダッシュボードは緑一色。 それでも、ユーザーはまだ失敗しています。システムが落ちているからではありません。システム自体は問題ないのです。けれども「ユーザーがボタンをクリックする」から「ユーザーが欲しかった結果を得る」までのどこかで、何かが壊れました。静かに。 アラートは出ない。しきい値も超えない。ただ、ユーザーが諦めて離脱しただけです。 コードは壊れます。そこが問題の核心ではありません。問題は、それが3週間後に発覚することです。大口の顧客が苛立って離脱しそうになり、営業チームがエスカレーションして初めて分かるのです。 マネーモーメント どのプロダクトにも「マネーモーメント」がいくつかあります。ユーザーが成功できるか、あるいは収益を失うかを左右する、プロダクト内の特に重要なポイントです。「APIは落ちていないか」でも「ページは読み込めたか」でもありません。ユーザーが本当にやりに来た「その行為」のことです。 最近聞いた例をいくつか挙げます。 ある小売企業はブラックフライデーを完璧な稼働時間で乗り切りましたが…コンバージョン率が12%も下がってしまいました。マネーモーメントである「購入手続きの完了」が、特定のブラウザ拡張機能を使っているユーザーで機能していませんでした。サーバーエラーはなし、アラートもなし。3週間分の売上を失いました。修正にかかったのは1時間ですが、問題に気づくまでには非常に長い時間がかかりました。 ある決済企業はすべてのSLOを満たしていましたが…顧客から「ランダムに失敗する」という苦情がありました。マネーモーメントである「送金が実際に完了し、確認まで終わること」が、国際送金では断続的に失敗していたのです。原因はタイムアウトのエッジケースで、ダッシュボードには平均値しか表示されていませんでした。影響を受けていたのはユーザーでした。修正は6行のコードで済む内容でしたが、何か月分ものノイズの下に埋もれていました。 あるB2Bプラットフォームはどの指標でも健全に見えていましたが…ところが、マネーモーメントである「新規顧客が“なるほど”と実感する瞬間」が、特定の設定を持つエンタープライズアカウントで壊れていました。監視より先に営業がそれを見つけました。ダッシュボードはどれもシステムが「稼働中」だと言っていましたが、プロダクトは壊れていたのです。 毎回、同じパターンです。 測っている対象が間違っています 違いはこうです。 多くのチームが測っていること すべてのサービスは動いているか 指標はしきい値の範囲内か システムは健全か 本当に重要なこと ユーザーは目的を達成できたか できていないなら、どのコードが壊れたのか どれだけ早く直せるか 前者は横方向です。あらゆるものを監視して、何かを拾えることに期待する。 後者は縦方向です。マネーモーメントをエンドツーエンドで追う。壊れたらすぐに分かる。リリースまでたどる。修正する。 両方を行うこともできます。もしダッシュボードが緑でもユーザーが失敗しているのであれば、何が欠けているかがわかります。 実践するべきこと 複雑ではありません。 マネーモーメントに名前を付けましょう50もの異なるフローではなく、プロダクトが機能するかどうかを左右する3〜5つのポイントを特定してください。ユーザーにとって重要で、彼らが目的を達成できるかどうかを左右する瞬間です。ユーザーが成功する瞬間、離脱する瞬間はどこでしょうか。 セグメント別に監視しましょう平均ではなく、顧客ティア別、地域別、デバイス別、リリース別です。最大の顧客を混乱させるバグは、集約されたメトリクスには現れません。 リリースと結びつけましょうマネーモーメントが失敗した場合、最初にすべき質問は「何が変わったか」です。数分で答えられないようであれば、目を閉じたまま飛んでいるようなものです。 アラートまでの時間ではなく、修正までの時間を測りましょう誰もダッシュボードがどれだけ早く真っ赤になったかには関心がありません。壊れたコードをどれだけ早く発見し、修正をリリースできたかが重要です。 […]
【LogTape & Sentry】トレースに紐づく構造化ログ
Article by: Kyle Tryon アプリケーションがちょっとした個人開発から、多くのユーザーに使われる複雑な分散システムへと成長していくにつれて、従来の console.log に頼ったデバッグ手法では通用しなくなります。本当に観測可能なシステムを構築するには単なるテキストログから、構造化されクエリ可能で、トレースに紐づくイベントへと移行していく必要があります。 要点：ログ戦略の転換 多くの人はログをパンくずのように扱い、各行が実行されたことを確認したり、デバッグのために出力結果を記録したりします。ところが本番環境では、そのパンくずはすぐにノイズの山になります。必要なのは処理の過程を逐一ログに残すやり方から、マイルストーンをログに残すやり方へ切り替えることです。 ノイズを取り除く：ノイズを生み、クエリや相関が難しい「薄い」ログから離れましょう。 高カーディナリティを受け入れる： タスクの進行に伴って積み上がる「厚い」コンテキストをログに詰め込みましょう。ユーザーID、注文ID、カート情報などを含め、任意のイベントについて必要なデータをクエリできるようにします。 点をつなぐ： Sentry を使ってログをトレースに紐づけたままにし、各ログをそれを引き起こした特定のリクエストへ紐づけます。 ログの洪水：なぜ本番環境では console.log が通用しないのか ログが集中管理されなくなり、時系列で追えなくなった瞬間に console.log は破綻します。複数のユーザーとサービスが同時に動く本番環境では、ログはすぐにさまざまなイベントが入り混じったストリームになってしまい、特定の1リクエストについて何が起きたのかを復元する明確な手がかりがなくなります。 関連するログ同士をつなぐ共通のトレースと、フィルタ可能で有用なデータがなければ、こうしたログは本番環境では実質的に役に立たなくなります。 LogTape と Sentry で本番品質のロギングを実装 Sentry はトレースに紐づくロギングを提供します。トレースを使えば、1つのリクエストに関する全体のコンテキスト（そのリクエストに紐づくログも含む）を確認できます。これにより特定の issue やリクエストに関連するトレースとログを簡単にクエリできるようになります。 さらに Sentry Logs には、属性や構造化データをもとにログを検索できる強力なクエリエンジンがあります。そこから検索結果に基づいてアラートやダッシュボードを作成することも可能です。 LogTape はあらゆる JavaScript ランタイム向けの軽量なロギングライブラリです。LogTape のようなロギングライブラリを使うと、コードに計測を組み込み、自動でリッチな構造化ログを出力できるようになります。また「log sink」を使って、それらのログを Sentry に送信できます。 構造化ログとは、単なる文字列ではなく、定義されたプロパティを持つ構造化オブジェクトとしてログを扱う形式です。 これにより本番環境でのデバッグにおいて、ログから必要なデータを見つけて可視化するための強力なクエリやフィルターを作成できます。 LogTape の構造化ログマニュアルからの例 クイックスタート：Next.js […]
【View Renderer V2】iOS Session Replay パフォーマンスを向上
Article by: Phil Niedertscheider モバイル向け Session Replay を一般提供（GA）にした後、採用は急速に進み、より多くのフィードバックが私たちのもとに届くようになりました。 あまり良くない話ですが、Apple SDK のユーザーから、古い iOS デバイスでの Session Replay のパフォーマンスオーバーヘッドにより、アプリが使い物にならなくなったという報告がありました。 そこで私たちは原因を突き止めるための旅に出て、ベンチマークで 4〜5 倍良いパフォーマンスを得られる解決策を見つけました。モバイルの Session Replay の内部で何が起きているのかを理解するために、技術的な詳細に入る前に、まずモバイルの画面録画がどのように動作するのかを見ていきましょう。 フレームレートをひと言で言うと 画面録画とは、フレームと呼ばれる高速で表示される多数の画像から成る動画です。人間の目は 1 秒あたり約 60 フレーム（フレームレート）を処理でき、これはヘルツ（1 Hz = 1 秒あたり 1 単位）で測定され、動いている映像の錯覚を生み出します。フレームレートは用途によって異なり、映画では 24 Hz、ゲーミング向けの PC ディスプレイでは 144 Hz まであります。 より高いフレームレートはより滑らかな動画を生みますが、重大なトレードオフを伴います。 同じ動画の長さでも、ストレージとネットワーク帯域の消費が増える 1 秒あたりに処理すべきフレームが増え、性能を維持するにはより強力なハードウェアが必要になる フレームレートを最小まで下げると、録画はストップモーション動画のように見えます。このスタイルのとても良い例は、この YouTube 動画で見ることができます。フレームは単に連続した写真にすぎませんが、それでも動いている写真のように感じられる、つまり動画です。 これは本質的に、私たちがモバイルの Session […]
堅牢な時系列モニタリング 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 […]