【Seer】自動根本原因分析で N+1 クエリ問題を解消
Article by: Sergiy Dybskiy Shopify で働いていたとき、ブラックフライデーとサイバーマンデーはまさに私たちにとってのスーパーボウルでした。マーチャントの皆さんが1年の中で重要な時期に予期せぬトラブルに遭遇しないよう、数週間も前からコードフリーズに入っていました。それでも、ときには直前になってアップデートをリリースしなければならないこともあります。 たとえば、こんな場面です。 ブラックフライデー前夜の午後 11 時 47 分。50 点以上の商品を割引価格で掲載した新しい /sale ページをデプロイしたばかりです。マーケティングチームはこれから 50 万人の購読者にメールを送ろうとしています。サンプルデータでのテストはすべて問題ありませんでした。 そして午前 0 時 13 分、最初の Sentry アラートが届きます。 問題 /sale エンドポイントの平均レスポンスタイムが 1 リクエストあたり 4 秒以上かかっています。ユーザーはタイムアウトを経験しており、今すぐこの問題を修正する必要があります。 Sentry が問題を検知する Sentry を開いてみると、すでに原因が特定されています。N+1 クエリです。Sentry はトランザクションスパンを自動的に解析し、/api/sale エンドポイントがリクエストごとに 150 回以上の連続したデータベースクエリを発行していることを突き止めました。 Issue の詳細を見ると、典型的なパターンが現れています。 まず最初に全商品を取得するクエリが 1 回実行され、その後に各商品のセール価格、メタデータ、カテゴリ情報を取得するクエリが何度も繰り返し実行されています。典型的な N+1 です。 […]
【Sentry】デザインを一新しました！
Article by: Jesse Box お気づきかもしれませんが、Sentry の見た目が大きくアップデートされました。 これまで、プロダクトの見た目は「いかにもエンタープライズ向け」という無難なデザインだった一方で、ブランドはずっと大胆で型破りでした。そのちぐはぐさは、もう終わりです！今日からは、皆さんが Sentry に期待するあの「ノリ」とプロダクトのデザインがきちんと噛み合うようになりました。より鮮やかで、より手触り感があって、より一層「Sentry らしい」見た目になっています。 ようこそ、S.C.R.A.P.S. 時代へ。これは Sentry の新しいデザイン言語で、正式名称は 「Standardized Collection of Reusable Assets & Patterns for Sentry（Sentry のための再利用可能なアセット＆パターンの標準コレクション）」 です。Sentry ならではの、ちょっと風変わりでクセになる魅力を、そのままプロダクトの中に流し込むためのデザイン体系なのです。 はじまりはこんなところから Sentry のプロダクトは、この数年で機能面では大きく成長してきましたが、見た目のほうは小さな改善の積み重ねにとどまっていました。「壊れていないものは直すな（Don’t fix what isn’t broken）」という考え方も、いつまでも通用するわけではありません。デザインは静かに古びていき、いったん世の中の期待値が変わってしまうと、かつては新鮮だったものも途端に古くさく感じられてしまいます。 一方で、ブランドのほうはどんどん先へ進んでいました。イラストはいい意味でどんどん「ヘン」になり、トーンはますます大胆に。それに対してプロダクトは、ずっと控えめなまま。両者の距離は少しずつ開いていきました。アプリはブランドの「少しトーンを落とした反響」であることが多いとはいえ、私たちの場合、そのギャップはもはや見過ごせないほど大きくなっていたのです。プロダクトが、もはや「Sentry らしく」感じられなくなっていました。 直近のマーケティングキャンペーンは「Make it make sense.」でした。 Sentry が初期に成功できた理由は、ほんの少しだけ他と違うことをしていたからです。誰も気にしないような部分にまで手をかけ、誰とも同じような「しゃべり方」をしないと決めていました。その最初のタグラインである「Sh*t Happens. Be on top of it.（トラブルは起きるもの。主導権はこちらが握る。）」が、その姿勢を物語っています。正直で人間味があって、ソフトウェアのカオスを前にしてもユーモアを忘れないトーンです。 その声は今も私たちを形づくっていますが、状況は変わりました。いまや「磨き上げられていること」は前提条件で、どのアプリも見た目はちゃんとしている。だから Sentry のデザインを刷新しようと決めたとき、私たちが目指したのは、よりツヤツヤした UI ではなく、「もう一度、自分たちらしさを取り戻すこと」でした。 […]
うまく機能していたメトリクス製品をあえて終了させてゼロから作り直した理由
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 […]
Seer が Cursor Agents を起動してバグを自動修正できるようになりました！
Article by: Jenn Mueng 先日、Cursor Cloud Agent との連携機能をリリースしました。これにより、Seer がバグを見つけたときに、その問題に関して Sentry が持っているコンテキスト一式を添えて Cursor に渡し、修正コードを書いて PR を作成させることができるようになりました。 完全自動＆検証済みのコード修正 これからは、実際に稼働しているコードベース環境の中で、コーディングエージェントを自律的に動かすことができます。しかも、すべてバックグラウンドで実行されます。 Seer が問題を検知し、根本原因を分析すると、その結果と問題のコンテキストを Cursor Cloud Agent に送信できます。 エージェント側では次の情報を受け取ります。 Issue のコンテキスト一式：スタックトレース、ブレッドクラム、ユーザーインパクトなど Seer の Root Cause Analysis：実際に何が壊れているのかに関する詳細な分析結果 あなたの稼働中コードベース：Cursor Cloud Agent は実際のコードベース全体にアクセスでき、コードの実行も可能 あとは、あなたがコーヒーを取りに行っている間に、エージェントが自律的に作業を進めてくれます。戻ってくる頃には、あなたのリポジトリにはエージェントが作成した PR がすでに用意されています。 使い方は 2 通り 手動トリガー 任意の Issue の「Seer Root Cause Analysis」カードから、Find […]
【Sentry Logs】ダイナミックサンプリング問題をデバッグ
Article by: Simon Hellmayr この四半期、Sentry のチームの一部は不具合の修正に注力し、正確には 800 件を超える問題を解決しました。その中には、社内の Sentry プロジェクトでトランザクションのスパイク（急増）を引き起こしていた複雑な不具合も含まれていましたが、Sentry Logs を用いて調査し、根本原因を追跡して問題を解決しました。 問題：断続的なスパイクと 100% のサンプル率 最初の症状は明確でした。特定の時間帯の始まりに、社内のプロジェクトが大量のスパンであふれ、プロジェクトの「abuse layer（異常負荷防止層）」が Sentry プロジェクトから膨大なデータをランダムに破棄していました。ただし、すべての時間帯で発生するわけではなく、数日間連続で発生しないこともありました 調査の結果、ダイナミックサンプリング設定が「すべてをサンプリングする」ルールに上書きされていることがすぐに判明しました。つまり、{“type”: “sampleRate”, “value”: 1.0} という設定です。 この設定の目的は、どのプロジェクトやトランザクションをどの割合で保存するかを指定することです。そして、その値が 1.0 の場合、すべてをサンプリングすることを意味します。Sentry の目標サンプリング率は 2% であるため、突如として 50 倍のトラフィックを受け取る事態は冗談では済みません。 しかし、なぜこのようなことが起きていたのでしょうか？ 最初の仮説は、ルール生成ロジックがフォールバックケース（代替処理）に入ってしまっているというものでした。これを確認するためには、より多くの可視性が必要でした。まず最初のステップとして、問題の設定状況を把握するために、コードに詳細なログ出力を追加し、動作を記録するようにしました。 調査に Logs を活用する まずは設定の JSON をそのままログに出力しましたが、この設定は非常に大きくなることがあり、GCP Logs が受け付けるサイズを超える場合があると分かりました。一方で Sentry Logs は JSON を自動的に切り詰め、重要な情報を直接得られるようにしてくれました。 ログのペイロードを縮小し、意味の明確化も図って迅速に改善した結果、必要なデータを取得できるようになりました。次に問題が再発した際には、すぐにSentry […]
【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 […]
【Sentry Flutter SDK 9.0】Logs・Session Reply・Feature Flags などをご紹介
Article by: Gino Buenaflor, Steve Zegalia (本記事は2025/6/16に公開された記事です） 「Null check operator used on a null value（null 値に対して null チェック演算子が使われました）」とだけ書かれたエラーレポートを手がかりに Flutter アプリをデバッグしたことがあるなら、すでにご存じのとおり、コンテキストがすべてです。ですが、ネイティブコードや Dart、非同期スタックトレース、プラットフォームチャネルを同時に扱っていると、そのコンテキストを得るのは簡単ではありません。 そこで Flutter SDK v9 では、何が起きているのかをより可視化し、改善に役立つインサイトを得られる機能を導入しました。 新機能は次のとおりです。 モバイル向け Session Replay の一般提供（GA）対応：クラッシュ前にユーザーが何を見て（何を操作して）いたかを再現して確認できます。 Feature Flags（フィーチャーフラグ）対応：バグ発生時にどのフラグが有効だったかを把握できます。 Logs（現在 Open Beta）対応：ログをクラッシュやパフォーマンス問題と相関付けて確認できます。 ネイティブ JS エラー対応（Flutter Web）：JS 連携（interop）を利用する Flutter Web アプリの可視性が向上します。 Release Health（Flutter Web）対応：リリースの普及状況、安定性、クラッシュフリーセッションについてより深いインサイトを得られます。 Traces と Errors の連携強化：アプリケーションコード内の特定の span と問題を相関付けて分析できます。 […]
「ミニ」じゃなかったミニダンプ！SteamOSで見逃されていたクラッシュを発見
Article by: Amir Mujacic 私たちは Sentry のゲームエンジンとネイティブ SDK のアップデートをリリースしましたが、Windows でビルドしたゲームを Linux 上で Wine / Proton 互換レイヤーを使って意図的にテストしている場合を除いて、おそらくほとんどの開発者はこれまで気づいていなかったと思います。それこそが狙いです。 ゲームエンジン SDK の改善に取り組んでいる最中、謎の問題を調査する中で得た知見は、Wine やその他の互換レイヤーを介して Linux 上で動作するあらゆる Windows アプリケーションにも当てはまります。そしてそこに至るまでの経緯自体が語る価値のあるストーリーだったのです。 謎：なぜクラッシュレポートが届かないのか きっかけは、あるゲームスタジオからのサポートチケットでした。 「Sentry は Windows ではうまく動いているのですが、Steam Deck のクラッシュでは何も届きません。」 おかしい… 私たちはテスト用ゲームを SteamOS 上で動かしましたが、Linux ビルドをテストすれば、問題なく動作します。次のステップは、多くのゲームと同じように互換レイヤーを介して、SteamOS 上でテスト用ゲームを動かすことでした。非致命のエラーはきちんと拾える。ログも例外もパフォーマンスデータも一通り見えます。ところが実際のクラッシュだけは、反応ゼロ…。 最初の直感：アップロードパイプラインを確認しました。ネットワークの問題？認証？いいえ。非クラッシュイベントに関してはすべて正常に見えました。 そこで Steam Deck のテストデバイス上のローカルストレージを確認しました。 すると 15 個のクラッシュダンプがありました… それぞれが 500MB 超えで、デモゲームなのに、ヒープメモリがダンプされていない状態としては異常な大きさです。 参考までに言えば、同じゲームの通常の Windows クラッシュダンプは 50〜80KB 程度です。何かが壊滅的におかしかったのです。 […]
そのままで動くLaravel パフォーマンスモニタリングも同様
Article by: Will McMullen Laravel アプリを初めて立ち上げたときのことを覚えていますか？ルーティング、認証、ORM、キューがすべてスムーズにつながり、ほとんど手間がかからなくなったはずです。これこそ、Laravel が「最初から生産的に感じられる」理由のひとつです。 しかし、アプリの動作が遅くなり始めたとき、Eloquent クエリが重くなる、ジョブがいつまでも終わらない、キャッシュミスが増えていく。その原因を見つけるのは簡単ではありません。Laravel には多くのツールが備わっていますが、それらをつなぎ合わせて全体像を把握するのは、これまで開発者の手に委ねられていました。 Sentry の新機能「Laravel Insights」を使えば、アプリ内部で何が起きているのかを、より明確に把握できます。エラー、遅いジョブ、データベースクエリ、キャッシュの利用状況、ルートごとのパフォーマンスなどを可視化し、既に追跡している課題と関連づけて表示します。さらに、それらがユーザー体験に実際どのような影響を与えているのかも確認できます。 すべてがつながっています。特定のルートから発生した遅いジョブをたどり、その原因となったクエリを特定し、キャッシュが改善に寄与したのか、それとも逆効果だったのかまで把握できるのです。 Laravel を先回りして最適化 これは新しい製品でも、新しいタブでもありません。Laravel アプリで基本的な Sentry のインストルメンテーション（エラーおよびトレーシング）が設定されていれば、Insights → Backend の中で Laravel プロジェクトを開くだけで次の情報を確認できます。 Recommended Issues：本番環境で新たに発生した、または深刻化している課題を表示 Requests & Duration：リリースごとの負荷の変化やアプリのパフォーマンスを追跡し、リグレッションが発生していないか確認 Jobs：バックエンドジョブの実行時間や失敗率の傾向を監視し、SendWelcomeEmail::dispatch($user); が常に時間通りに動作しているか確認 Queries：コストの高いデータベース呼び出しを特定し、トランザクションを最適化 Caches：キャッシュミスが多発している箇所を特定し、無効化の問題を修正 Routes：リクエスト数、ユーザー数、総処理時間、pXX 指標ごとにソートし、早期にパフォーマンス低下を検知 一人で開発している場合でも、スタートアップのスケールアップ段階にあっても、これらのインサイトによりアプリの挙動を簡単に把握でき、ユーザーが気づく前に問題を修正できるようになります。 さらに深く掘り下げ、アラートを作成 たとえばキャッシュミスの急増、データベース時間を食い尽くす暴走クエリ、異常に滞留しているキューなど、もし何かおかしな兆候を見つけたら、クリックひとつで詳細を掘り下げることができます。 Laravel Insights の各ウィジェットには 「Open in Explore」（Exploreで開く）ボタンがあり、ドロップダウンをクリックすると Sentry のクエリビルダーに直接移動できます。そこで次のようなことが可能です。 特定のサービス、ルート、ユーザー、または環境に絞り込んでクエリをカスタマイズ ブラウザの種類、ユーザーアカウントの状態、リクエスト元など、Sentry に送信している任意のタグ（デフォルト・カスタム問わず）でグループ化 […]
【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 […]