Sentry 機能 / Sentry Features - Ichizoku

【ダッシュボードのアップデート】クリック数削減、操作性向上、ウィジェット作成の高速化

Article by: Alexandra Cota 本番環境のメトリクスを確認していると、突然ダッシュボードにエラーのスパイクが表示されます。このとき最初に考えるのは「この状況を調べるために新しいビューをどのように作ろう」ではなく、「どうすればすぐに原因を突き止められるのか」でしょう。実際、先月私たちのエンジニアリングチームの一つがAPIのレスポンスタイムに異常なパターンを発見した際にも、まさに同じ状況が起こりました。彼らはゼロからアドホッククエリを実行するのではなく、以前のインシデント後に作成していたカスタムダッシュボードを活用しました。エラーとトレースデータの傾向を関連付けることで、彼らはすぐに原因を特定しました。それはインデックスの欠落による非効率なクエリ実行でした。迅速に修正を加えた結果、レスポンスタイムはすぐに正常に戻り、何時間も手作業で調査する必要はありませんでした。ダッシュボードは単なる静的なレポートではありません。チームが異常を素早く検知し、シグナル同士の関連性を見つけ、問題の根本原因に素早くたどり着くための動的なツールです。過去数か月の間に、ダッシュボードの構築、管理、操作を改善するためのさまざまなアップデートを行いました。ウィジェットビルダーの刷新から、ダッシュボードの整理・保護方法の新機能まで、設定にかける時間を減らし、本当に重要なことに集中できるようになりました。より直感的なウィジェット作成ウィジェットはダッシュボードの基本要素であり、私たちはウィジェットビルダーを刷新し、ウィジェットの作成・編集をより簡単かつ直感的にし、ワークフローとの統合性も高めました。サイドパネルデザイン：ページ遷移せずにウィジェットの作成・編集が可能です。ライブプレビュー：設定を調整すると即座に反映され、余計なスクロールや固定ヘッダーの操作は不要です。シンプルなレイアウト：視覚的な煩雑さを抑え、必要なステップが一目で分かり、クエリを素早く作成できます。ウィジェットライブラリの改善：ビルダーのスペースを圧迫することなく、ゼロからウィジェットを作るか、プリセットから始めるかを選択可能です。ダッシュボードを意図した通りに維持するリリース当日、チームはクリティカルリリースダッシュボードを注視し、問題が拡大する前に検知しようとしています。エラー、レイテンシ、スループット。必要な情報はすべてそろっているはずです。しかし、状況が悪化し始めたとき、失敗率のチャートが消えていたり、フィルターが変更されていたり、レイテンシのウィジェットがp95ではなくp50を表示していることに気づきます。実は、誰かがダッシュボードを編集していたのです。その結果、問題を素早く把握するどころか、表示を元に戻すために右往左往し、貴重なインシデント対応の時間を無駄にしてしまいます。ダッシュボードは、他チームによる意図しない変更が加えられることなく、自分たちが最も重視するインサイトを正しく反映すべきです。今回の更新により、誰がダッシュボードを編集できるかを制御できるようになりました。これにより、クリティカルリリース用のダッシュボードをロックしたり、自分のチームだけに編集権限を付与したりすることが可能です。新たに追加された「編集アクセス」セレクターにより、適切な制御が可能になり、明確な権限の線引きがチーム間の円滑なコラボレーションを実現します。お気に入り登録とダッシュボード整理チェックアウトフロー、認証フロー、主要APIエンドポイントなど、ダッシュボードの数が増えていくと、目的のダッシュボードを素早く見つけることが重要になります。そこで、ダッシュボードのお気に入り機能を導入しました。重要なダッシュボードをリストの上部にピン留めすることができます。ダッシュボード詳細ページまたはダッシュボード一覧ページで⭐アイコンをクリックするだけで、よく使うダッシュボードがいつでもすぐアクセスできるようになります。さらに、テーブルビューも追加し、ダッシュボードの整理・管理をよりコンパクトに行えるようにしました。以下の2つのビューを切り替えられます。グリッドビュー：カード形式のビジュアルレイアウトテーブルビュー：コンパクトな表形式始め方 Sentry のダッシュボードを使えば、単なる監視にとどまらず、すぐに問題解決へとつなげることができます。トランザクションの失敗が急増しているのを見つけた際、どのデータベースクエリが遅延を引き起こしているのか、どの例外がコード内で発生しているのかを即座に掘り下げることができます。ハイレベルなメトリクスと実装の詳細が直接つながっているため、頻繁に画面を切り替えることなく、問題の特定・診断・修正が可能になります。これらの改善は、モニタリングとデバッグをよりシンプルにするという私たちの継続的な取り組みの一環です。そしてこれは始まりにすぎません。今後数か月間でさらに多くの改善が予定されています。この機能は Business プランと Enterprise プランのすべてのユーザーが利用できます。ぜひダッシュボードで自分だけの画面を作ってみてください。まだ Sentry のアカウントをお持ちでない方もご安心ください。無料トライアルやデモリクエストですぐに始められます。 Original Page: Dashboard updates: Fewer […]

異常検知アラートがオープンベータで利用可能に　より賢いモニタリング・誤検知を削減

Article by: Rachel Wang, Aayush Seth 数週間前、私たちはアーリーアダプター向けに異常検知アラートを導入しました。そして本日（2025/3/25）、異常検知アラートが正式にオープンベータとなり、Trial、Business、Enterpriseプランの全Sentryユーザーが利用可能になったことをお知らせします。異常検知アラートとは？ Sentryでは、特定のメトリクスが予想された閾値から逸脱した際に通知されるメトリクスベースのアラートを設定できます。例えば、エラー率が一定の閾値を超えたときや、主要なアプリケーションパフォーマンス指標が特定の範囲を外れたときにアラートを作成できます。強力ではありますが、メトリクスのアラート閾値を手動で設定するのは複雑な作業になりがちで、しばしばノイズの多いアラートや、最悪の場合は問題の見逃しにつながることもあります。従来、Sentryでメトリクスアラートを設定するには、適切なバランスを見つけるためにかなりの推測と試行錯誤が必要であり、さらにデータについての深い理解も求められていました。アラート詳細ページでユーザーのクエリによって定義されたカスタムメトリクスアラートで発生した異常アラートの例です。チャート上では赤色で表示され、アルゴリズムが異常な挙動を検知するとアラートが発報されます。異常検知アラートは、予想されるパターンを自動的に学習することで、この複雑さを解消し、ユーザーは設定や推測なしでアラートを作成できます。静的な閾値を手動で定義する代わりに、異常検知アラートは過去のデータを利用して予測される傾向を判断します。これにより、誤検知が減り、アプリケーション監視時のシグナルとノイズの比率が改善されます。さらに、静的な閾値は状況の変化によってすぐに古くなったり無意味になったりしますが、異常検知アラートは時間とともに動的に調整され、昼夜や平日・週末といった季節性や、持続的な成長といった長期トレンドも考慮します。これによりビジネスやアプリケーションが変化しても、アラートは常に適切な状態が保たれます。仕組み異常検知アラートは、Matrix Profiling と Prophet Forecasting という2つのアルゴリズムの組み合わせを活用しています。 Matrix Profiling：最新のデータポイントが過去のパターンと比べてどれほど「意外」かを検出します。現在と過去のデータ系列間のユークリッド距離に基づいて異常を評価します。 Prophet Forecasting：季節性や長期的なパターンを考慮しながら期待されるトレンドのモデルを構築し、データポイントが予測範囲から外れたときに逸脱として検出します。ハイブリッド検知：両方のアルゴリズムが異常を検知した場合、または片方が高い確信度で異常を検知した場合に、システムは異常アラートを発報します。この組み合わせたアプローチにより、誤検知（偽陽性）と見逃し（偽陰性）の両方を最小限に抑えます。今すぐ試してみよう異常検知アラートは現在、Trial、Business、Enterpriseプランのすべてのユーザーにオープンベータ版として提供されています。始めるには、左側のナビゲーションバーの Alerts タブに移動し、Create Alert をクリックしてください。次にメトリクスを選択し、検知方法として Anomaly を選び、必要に応じて感度を調整すれば、あとは Sentry が処理してくれます。異常検知アラートの設定方法については、ドキュメントに詳しい情報があります。異常検知アラートのパブリックベータ版公開は、私たちのチームにとって大きな節目であり、今後もこの機能の安定化に取り組んでいきます。皆さんのフィードバックもぜひお聞かせください。ぜひ試して、ご意見をお寄せください！ Original Page: Anomaly Alerts Now in Open Beta: Smarter […]

【Breakpoint まとめ】稼働監視・ロボット・豊富なフィーチャーフラグ

Article by: Sasha Blumenfeld バグは丁寧に現れることはなく、チェックアウト機能をクラッシュさせ、認証を破壊し、APIの応答速度を極端に低下させます。しかも多くの場合、CEOから進捗状況を尋ねられる直前に発生します…。さらに、エラー通知ボックスが「TypeError: cannot read property of undefined」の亜種で埋め尽くされると、真に重要な問題を見極めることが困難になります。そのため、デバッグにおける推測作業を排除するためのアップデートを展開しました。調査に費やす時間を短縮し、開発に集中できるようにすることが目的です。ユーザーに影響が及ぶ前にダウンタイムの通知を受け取り、サイト上で関連する問題やユーザーからのフィードバックを直接確認できます。また、AIによるアラートのグルーピング機能により重複を整理し、AI支援による修正により、問題の迅速な解決が可能になります。アプリ障害、上司より先に気づけていますか？プロダクション障害はそれだけで問題ですが、それを CEO の Slack メッセージで知るのは最悪です。現在一般提供中の Uptime Monitoring を使えば、SNS で炎上したり、全社ミーティングで取り上げられたりする前に、障害を検知することができます。最短60秒間隔で実行されるグローバルチェックにより、障害発生の瞬間を即座に把握できます。以下のことが可能です。重要なフローの監視たとえば、購入処理が突然止まったかどうかを検出するためのチェックアウトページやユーザーがログインできなくなっているかを確認するログインエンドポイントなどです。カスタム条件の設定たとえば、ダウンタイムが60秒を超えた場合にのみ通知を受け取るように設定可能です。普段使用しているツールでの通知Slack、PagerDuty、Teams、または Webhook 経由です。たとえば、チェックアウトページが突然タイムアウトし始めたとしましょう。顧客からの苦情を待つ代わりに、即座にアラートが届きます。障害ログを確認すると、サードパーティの決済サービスの応答が遅いことが分かります。Sentry のエラーやトレースと照合することで、その遅延がどこで発生しているのか（APIの障害か、ネットワークの問題か、自分たちのコード内の何かか）を正確に特定でき、売上の損失が積み重なる前に修正できます。私たちはこれまでに 40,000件のダウンタイムを検知しており、それらが大量のサポートチケットに発展する前に、チームが問題を特定できるよう支援してきました。モニターは1つ無料でご利用頂けます。追加はモニター1つあたり月額1ドルです。HTTPメソッド、ヘッダー、ボディパラメータなど、リクエストの詳細を完全にコントロールし、特定のURLに対するカスタムアラートを作成できます。ぜひ試してください。詳細はブログでもご覧頂けます。重複したエラーを掘り返すのはやめましょうエラー受信箱が多数の通知で溢れていても、それが本当に10件の異なる問題なのでしょうか。それとも同じ問題の50通りのバリエーションでしょうか。現在受信しているアラートが、実は過去に対応済みのエラーの再通知である可能性もあります。このように終わりのないアラートの中で混乱するのではなく、Issue Grouping を活用することで、関連するエラーを自動的にグループ化し、イズを削減できます。その結果、本当に修正すべき課題に集中することが可能になります。例えばアプリケーションの複数箇所で API が、500 Internal Server Error を返している場合でも、Issue Grouping（AI Grouping）は、それらが単一の根本原因によるものなのか、複数の独立した問題なのかを判別します。また、ステージング環境と本番環境をまたいでエラーをグループ化できるため、同じ問題を重複して調査する無駄を防げます。 […]

アプリがダウン？今すぐ復旧！Sentry アップタイムモニタリングをご紹介

Article by: Sasha Blumenfeld, Gabriel Lopes Sentry もダウンタイムとは無縁ではありません。実は私たちはかつて、誤ったマイグレーションによって自社のアプリケーションを停止させてしまったことがあります。重要なデータベーステーブルにフィールドを追加しようとしたところ、そのマイグレーションがテーブル全体をロックしてしまったのです。このテーブルは Sentry の動作に不可欠だったため、アプリ全体が停止してしまいました。ウェブサイトは読み込めず、データの取り込みも止まり… すべてが完全に止まってしまいました… 私たちはすぐに問題のクエリを特定して停止させましたが、もし主要なページにアップタイムモニタリングを設定していれば、もっと早く異常に気づけたかもしれません。これこそが、Uptime Monitoring を開発した理由です。開発者が障害の原因を突き止めようと右往左往しているその1秒ごとに、ユーザーはページをリロードし、苛立ち、あるいは離れていきます。にもかかわらず、通常の対応プロセス（あるツールでアラートを受け取り、別のツールでログを調べ、何が起きたかを手作業でつなぎ合わせる）は遅くて苦痛を伴います。私たちはトラブルシューティングの断片化が復旧を遅らせることを身をもって体験しました。だからこそ、障害が発生した瞬間に検知し、その修正に必要なコンテキストまで一か所で得られる仕組みを作ったのです。 Sentry の Uptime Monitoring は、単に「何かが落ちた」と通知するだけではありません。バグのあるコード、失敗したAPI、またはまったく別の原因かどうかを特定し、根本原因へと導きます。 Sentry Uptime Monitoringは、すべてのユーザーにご利用いただけるようになりました。すべてのプランに1つの無料モニターが含まれています。ユーザーが気づく前に、あなた自身でダウンタイムを検知しましょう。 Sentry の Uptime Monitoring Sentryはサイトの稼働状況を監視し、ダウンタイムが検出された際に通知します。設定されたURLに対して60秒ごとに HTTP リクエストでヘルスチェックを行い、Web サービスを能動的に監視します。タイムアウト、DNS 解決エラー、不正なレスポンスなど、問題が検出されれば即座に通知されます。 9月末のベータリリース以降、すでに約10万件のアクティブなアップタイムアラートが作成されました。さらに、皆さまからの要望が多かった機能も多数追加し、より使いやすくなっています。チェック履歴「すべてが崩れる前にサイトが正常に動いていた証拠があれば…」と思ったことはありませんか？今ならあります。チェック履歴を使えば、過去のアップタイムチェックを確認したり、パフォーマンストレンドを追跡したり、ダウンタイムと他の問題との関連を見つけ出すことができます。詳しくはこちらアップタイム問題詳細画面のUXを改善インシデント調査時により多くの情報が得られるよう、問題詳細ページを全面的に刷新しました。これにより、チェック履歴のタイムライン表示、すべてのアップタイムチェックのクイックビュー、関連リクエストのトレースビューにアクセスできるようになっています。分散トレーシング対応アップタイムチェックが失敗したとき、探偵のように手がかりを追いかけたくはありませんよね。バックエンドサービスがSentry SDK でインスツルメントされていれば、リクエストのトレースをアップタイムチェックに自動的に関連付けます。そのため、必要なスパンや問題にすぐにジャンプでき、手作業で情報をつなぎ合わせる必要はありません。地理的に分散されたチェック午前3時の誤検知ほど、気分を台無しにするものはありません。ダウンタイムの見逃しと不要なアラートの両方を減らすため、現在は複数のロケーションからアップタイムチェックを実施しています。異なる地域で3回連続してチェックが失敗した場合にのみ、ダウンタイムとして認識される仕組みです。そのため、本当に対応が必要なときだけ、アラートが届きます。モニター設定の追加オプションすべてのサービスが同じではないように、モニタリングのニーズも一様ではありません。今では、各スタックに最適な形で、チェック間隔やタイムアウトの設定をカスタマイズできるようになりました。よくあるダウンタイムの原因 — Uptime Monitoring がどう役立つか壊れたコードのプッシュ一見無害に思えた変更をプッシュした結果、システム全体が危機的状況に陥ったという経験を、誰しも一度はお持ちではないでしょうか。あるチームでは、非同期ジョブ内の単純な型エラーが原因で、購入処理用の配信システムがクラッシュし、あわや大惨事という事態になりました。1つのジョブだけが失敗するはずが、クラッシュによってキュー全体がブロックされ、以降のすべてのジョブが実行されなくなったのです。そしておなじみの JavaScript の典型的なミスといえば、1ページを更新したつもりが、サイト全体を壊してしまうことです。ある開発者はそれを痛い形で学びました。テストではすべて問題なく見えていたにもかかわらず、ほんの小さな見落としが大きな混乱を引き起こしたのです。そのコードは、特定の要素が常に存在すると仮定し、すべてのページで実行されていました。nullチェックがなかったため、該当の要素が存在しないページは即座にクラッシュが発生しました。このコードは、なぜかPRレビューと社内テストを通過してしまいました。というのも、テスト対象となっていたのは、更新されたページのみだったからです。 […]

Trace Explorer でスパンからメトリクス、グループ、アラートを取得する方法

Article by: Will McMullen どこかで、わずかに引っかかるアプリを開発した経験は、誰しも一度はあるでしょう。あるいは、どうしてもうまく最適化できないクエリに悩まされたことがあるかもしれません。Chrome の DevTools にあるネットワークウォーターフォールでは、その裏側で実際に何が起きているのかを完全に把握することは困難ですし、OTelによるトレーシング（正直に言えば、Sentryでのトレーシングも）も、やはり難解でした。しかし本日から状況が変わります。私たちはトレーシングデータのための全く新しい Explore ビューをリリースしました。これにより、スパンデータを分類、絞り込み、並べ替えることで、パターンや具体的なトレース事例をこれまで以上に容易に見つけ出すことができます。また、デフォルトまたはカスタムのスパン属性を使って、pXX（パーセンタイル）などのスパンベースのメトリクスを作成し、それをもとにアラートやカスタムダッシュボードウィジェットを構成することも可能となりました。さらに、スパンをタイムスタンプ順に並べ替えることが、ついに可能になりました。ただし、これだけではありません。さっそく詳細を見ていきましょう。 ※この機能は Sentry のアーリーアダブタープログラムに参加しているすべてのセルフサーブ（自己登録）ユーザーに提供されています。まだ参加していない場合は、Sentry の設定画面から有効にしてください！ Sentry の Trace Explorer における新機能アプリケーションがますます複雑化する中で、わずかなパフォーマンスの低下でも深刻なユーザー影響を引き起こす可能性が高まっています（最終的にユーザーの離脱という深刻な事態につながることもあります）。遅延の原因を簡単に特定できず、それを特定のサービス、エンドポイント、API、あるいはデータベース呼び出しに関連付ける手段がなければ、生のトレースデータを注意深く確認する（最悪の場合はログを手作業で確認する）必要があり、複数のツールに分断された断片的なデータを手動で追いかけることになります。このような課題を解決するのが、新しい Trace Explorer です。スパンデータの活用方法が大幅に刷新され、以下の機能が追加されました。スパンベースのメトリクススパン属性を集計し、p95(measurements.lcp) のようなメトリクスとして扱うことができます。これにより、パフォーマンスにおける境界ケースの検出や、大量の API ペイロードの追跡、さらにはアラートやダッシュボードの設定が可能となり、アプリケーションのシグナルを常に把握できるようになります。クエリ可能なカスタム属性token_usage、region、cart_value など、アプリケーションに関連するカスタム属性をクエリおよび測定することが可能です。これにより、共通パターンを特定し、ユーザーにとって最も重要な体験に焦点を当てたアラートやダッシュボードを設計できます。アクションにつながる Trace Explorerスタック全体にわたるトレースデータを迅速にフィルタリングおよびグループ化し、クエリを保存・共有することができます。「なぜチェックアウトページの読み込みが遅いのか？」といった問いに即座に対応できるだけでなく、どのユーザーが影響を受けているかもすばやく把握できます。これらの機能は、パフォーマンスモニタリング・アラート・ダッシュボードの高度なセットアップを素早く構築できるように設計されており、トレースデータの価値を最大限に引き出すことができます。しかも、最小限のコストと構成で実現可能です。技術的に見ても非常にスマートな仕組みですが、実用面においてはさらに高い効果を発揮します。ベータ版で多数の企業と連携を行う中で、以下のような代表的なユースケースが明らかになりました。 CDN画像のパフォーマンス分析image_url や cdn_provider のような属性を付加し、プロバイダー別に画像の遅延を並べ替えて分析できます。事前のメトリクス変換や処理は不要であり、クエリ実行時に動的に処理できます。 AI消費量の追跡APIコール数、トークン使用量、モデル名などを測定可能です。スパイクが発生した際には、対象のトランザクション、ユーザー、環境、リポジトリを正確に特定できます。 ECサイトにおけるチェックアウト追跡cart_value や payment_method といった属性を用いてチェックアウトフロー全体を追跡できます。これにより、高額な取引でパフォーマンスが遅延しているケースを特定し、即座にトリアージすることが可能です。新しい Trace Explorer でスパンメトリクスを設定・活用する 1：重要な箇所にコードを計測挿入する（インストゥルメントする） Sentry […]

モバイル向けセッションリプレイが一般公開！ユーザー体験を簡単に改善する方法を徹底解説

Article by: Jasmin Kassas, Sarah Guthals モバイル向けセッションリプレイがついに一般公開されました。セッションリプレイの偉大さについて大袈裟に語ることもできますが、今回は趣向を変えて、A…I…があなたのために一句詠みます。画面が固まる　開発者はため息リプレイ明かす犯人は…… .addListener　忘れていた俳句になっているかどうかはさておき、要するに Sentry はユーザーの操作を動画のように再現できるため、どのデバイスで問題が発生しているのか、他の端末を使って再現確認しなくても、不具合の箇所や体験が途切れているポイントをすぐに確認できます。今どき iPhone 12 Mini が家に転がっている人なんてそうそういませんよね？少なくとも、私たちの手元にはありません。あなたのところはいかがですか？さて、本題に移ります。もし実際の問題をセッションリプレイでどのようにデバッグできるのか知りたい方は、この先をご覧ください。そうでない場合は、iOS、Android、Flutter、React Nativeのセットアップ方法をまとめたドキュメントをぜひご覧ください。セッションリプレイでどう解決するのか奇妙なバグの通知を受け取り、クラッシュダンプを見てもなぜユーザーがその状態に至ったのかわからなかった… 開発者であればそんな経験はよくあるでしょう。その度に状態を把握するためランダムなログを無闇に差し込み、それを再リリースしてユーザーにアップデートを強制するも的が外れてまたやり直し… そんなことを繰り返していませんか？しかしセッションリプレイならそんな手間を省くことができます。エラーや操作の流れも含めて確認することができるため、ユーザーがエラーに至るまでに何をしていたのかが正確に確認できます。ここからは、過去6ヶ月間のベータ期間に Sentry のお客様が実際に体験された事例をご紹介していきます。モバイルアプリの状態を正確に把握するモバイルアプリは実にさまざまな形式があり、その多くは複雑なUIフローや状態を保持しています。セッションリプレイを使用することで、アプリがどのような状態なのかを正確に把握することができ、問題の原因になっているUIフローを見つけることができます。以下の画像のように、バックエンドのエラーも含めて全体像を掴むのにとても役立ちました。セッションリプレイがなければ、問題が起きた時の再現手順を特定するのに不要な手間がかかります。これは複雑な条件（手順や状態）をデバッグする際に特に役立ちます。バックエンドのエンドポイントエラーにも対応ユーザーがどのような操作をしていたか分からない状態で、サーバーのエラーをデバッグするのは本当に骨が折れます。しかしセッションリプレイを使えば、エンドポイントに到達するまでのユーザー操作をそのまま見ることができます。またタイムラインビューを使うことでサーバーエラーが発生した正確なタイミングに一瞬でジャンプすることもできます。とあるお客様の事例を挙げると、アプリがフォアグラウンドに戻った際にプロフィールを更新しようとして、400エラーが発生していたことがありました。原因はその時点でユーザーがログアウトしていたからでした。修正はシンプルで、今では AppState イベントを監視しユーザーがログアウト状態ならすぐにログイン画面へリダイレクトするように修正しています。モバイル特有の問題も見逃さないセッションリプレイのパンくずリストを使えば、ユーザーの操作履歴とともにデバイスに関する重要な情報も取得できます。どの瞬間に、どのような操作や理由によって問題が起きたのかを正確に特定します。例えば「コードに問題はなかったのに、ネットワークが突然切れてオフラインになったこと」が原因だった（調査する開発者にとっては、これほど最悪なケースはありません）としても、セッションリプレイを見れば一目瞭然です。このパンくずリストは、従来のログでは見えない部分に光を当ててくれる貴重な手掛かりになります。モバイル向けセッションリプレイ導入手順セッションリプレイをアプリに組み込むためのステップは以下の通りです。 […]

モバイル向けセッションリプレイを発表 – オープンβ開始

iOS、Android、React Native用のSession Replayがオープンβになりました。もしあなたがSession Replayをすでに知っているなら、素晴らしいことです。リンクをクリックし、あなたのSDKをアップデートすれば、あなたのユーザーが怒りを引き起こすような問題を経験している場所をビデオのように再現してくれるようになります。もし私が何を言っているのか分からないなら、なおさらです。お話をしましょう。クラッシュ、悪ふざけ、一般的な無反応は、⭐1つのレビューにつながり、人々はアンインストールし、成長ハックを売り込むPMにつながり、誰もそれを望んでいません。このような悪ふざけを先回りするにはどうすればいいのでしょうか？昨年、私たちは、Webアプリのユーザーセッションの完全匿名化されたビデオのような複製をキャプチャする機能 – Webベースのアプリケーションのためのセッションリプレイ – を発表しました。現在、40,000を超えるチームが、チェックアウトの不具合、ページの読み込みの遅さ、予期せぬクラッシュなど、あらゆるデバッグにこの機能を使用しています。何が問題なのかを実際に見ることで、デバッグがより簡単になるとは誰が考えたでしょうか???? モバイル開発者（GitHubで400以上のアップヴォートを提供し、500以上のアーリーアダプターのサインアップに貢献した）もこの機能を望んでいます。だから、私たちはここにいます。モバイル向けセッション・リプレイは現在オープンベータ版で、アーリーアダプターは無料で使用できます。コードとUXのギャップを埋めるモバイル向けセッションリプレイは、アプリ上のユーザーセッションを視覚的に再現することで、モバイルアプリケーションの可視性を拡大します。これにより、いつ、どこで、どのようにエラーがアプリに影響を及ぼしているかを、自分で再現したり顧客と会話したりすることなく理解することができます。リプレイを使用すると、タップやピンチによるズームなどのジェスチャーがリプレイビューに含まれるため、ユーザーとのインタラクションをより深く理解し、アプリのどこで問題が発生しているかを特定することができます。リプレイには、デバイスタグ、ネットワークリクエストの詳細、スローされた例外などのデバッグコンテキストも含まれています。当社の全製品と同様に、セッションリプレイはSentryワークフローに統合されています。Issue Detailsでスタックトレースを検査しながら関連するリプレイを見たり、User Feedbackでバグレポートを提出したユーザからのリプレイを見たりすることができます。また、サンプリング設定を構成して、エラーが発生したときのみリプレイをキャプチャし、データのインジェストを減らすことができます。また、UIへの影響やユーザーの反応（アプリを閉じたかどうかなど）によって、問題の深刻度を評価することもできます。モバイルエラーの根本原因を確認するモバイル用のSentryのセッションリプレイを使用すると、ユーザーがエラーに遭遇したときにサンプリングセッションを優先するオプションがあります。これは、クラッシュが発生したときに、その特定のエラーに遭遇した実際のユーザーからの関連するリプレイが、問題の詳細ページで関連するSentryの問題に便利にリンクされていることを意味します。エラーの発生前、発生中、発生後に、OSのバージョンや名前などの有用なコンテキストとともに何が起こったかを見ることで、エラーがどのように発生し、ユーザーにどれほどの影響を与えたかを素早く特定することができます。さらに、エラー時のサンプリングにより、必要なデータを待つ時間や、イベントクォータを監視する不安も軽減されます。ゲーミフィケーションを使用し、UXに重点を置き、素晴らしいイラストやアニメーションがある、派手なライフスタイル・アプリを開発しているとしましょう。アプリケーション・パフォーマンス・モニタリング（APM）製品は、サードパーティのライブラリでクラッシュが発生していることを警告します。この問題を調査し解決するためにセッションリプレイを使用する方法を説明します。エラーを特定する：エラー追跡システムで、あなたはエラーメッセージ “NullPointerException in run_animation() “で繰り返し起こるクラッシュを分析します。スタック・トレースは、あなたが使っているサードパーティのアニメーション・ライブラリを指していますが、あなたはその意味を理解していません。関連するセッションのリプレイを探す：リプレイをフィルタリングして、この特定のクラッシュに関連するものだけを表示します。リプレイを見る：リプレイの1つを選択すると、達成を祝う画面から始まり、達成ポイントが与えられます。かなり長いです）リワードアニメーションが再生される間に、ユーザーは「次へ」ボタンをタップし、アプリがクラッシュします。コンソールログを調べる：コンソールログの中で、アニメーションライブラリから「onAnimationCancelled」コールバックが呼び出されていることに気づきます。このコールバックを実装しそこねていたことに気づきます。対策として、アニメーションの時間も短くします。アップデートをデプロイした後、アプリをアップデートするにつれてクラッシュの数が減少していることを監視します。この例では、Session Replayにより、クラッシュに至ったユーザーアクションを正確に可視化し、エラーの根本原因としてアニメーションライブラリのコールバックの欠落を特定し、この問題を解決するために的を絞った修正を実装することができます。セッションリプレイがなければ、イベントの正確なシーケンスを理解し、このクラッシュの原因を特定することははるかに困難であったでしょう。アプリのペインポイントの特定誤解を招くラベル、リンク切れ、パーミッションの問題 – ユーザーが例外を発生させない問題にぶつかることがありますが、それでもユーザー体験に影響を与えます。セッションリプレイは、ユーザーがどこで立ち往生したり、アプリから脱落したりするかを確認することで、アプリ内でこれらのペインポイントが発生する場所を特定するのに役立ちます。例えば、モバイル e コマースアプリを開発していて、チェックアウト中にアプリが反応しなくなるという悪いレビューが増えているとします。この問題を調査し解決するためにセッションリプレイをどのように利用できるかを説明しましょう。アプリのパフォーマンスに問題があると思われます。しかし、パフォーマンスKPIはまだ良好で、APM製品はチェックアウト画面で問題を示しません。関連するセッション・リプレイを見つける：リプレイをフィルタリングして、チェックアウト画面に関連するリプレイのみを表示し、継続時間の長いリプレイにも注目します。リプレイを見る：リプレイの1つを選択し、ユーザーのアクションを観察します。ユーザーがチェックアウトページの「次へ」ボタンをタップし、サーバーへのAPIコールが開始されるのを確認します。ネットワークリクエストを確認する：ネットワーク・タブを調べると、APIコールが正常かつ適切な時間で終了していることがわかります。これで、これが根本的な原因ではないことがわかりました。パンくずを調べる：アプリのUI状態管理でごく最近の状態変更があり、APIコールが返された後に状態が衝突してUIが更新されないことに気づきます。この時点で、ユーザーは激怒してクリックし、最終的にアプリを終了します。修正と検証：UI状態管理のバグを処理するための修正を実装します。アップデートをデプロイした後、後続のセッションリプレイを監視して、ユーザーがチェックアウトプロセス中に進めるようになったことを確認します。 […]

Trace Viewを使用してAPIコールを22.3秒短縮した方法

Dan Mindruはフロントエンド開発者兼デザイナーで、モーニング・メーカー・ショーの共同司会者でもあります。現在、PageUI、Clobbr、CronToolなどのアプリケーションを開発しています。開発者として、遅いAPIほどイライラさせられるものはありません。コードが動くことは分かっていても、それがもう良いユーザー体験にならないことは分かっているはずです。私にもそのようなことがあり、2週間ほど見て見ぬふりをしていました。しかししばらくすると、いくつかの問題は個人的なものになります。問題は、どこから手をつければいいのか見当もつかなかったことです。 Sentryの新しいトレース・ビューを発見するまでは。もちろん、トレースこそ、パフォーマンス低下の根本原因を突き止めるために必要なものです。では、このトレース・ビューのトリックひとつで、APIコールのロード時間を22.3秒短縮した方法をお教えしましょう。この投稿で詳細を説明し、トレースを使って自分のAPIコールのボトルネックを見つける方法を紹介します。うまくいけば、あなた自身のレスポンスタイムを数秒短縮できるかもしれません。さあ、始めましょう！トレースビューとは？ほとんどの人は、Sentryのエラー監視機能を知っています。しかし、それだけではありません。実際、Sentryはパフォーマンスのボトルネックを見つけるのにも役立ちます！ Sentryのセットアップがいかに簡単かは前にも述べました。その後、Sentryはパフォーマンス・メトリクスも収集してくれます。トレース・ビューはその重要な一部で、トランザクションとスパンを滝のように可視化します。ご想像の通り、これはアプリケーションのパフォーマンスに影響を与える遅延、関連するエラー、ボトルネックの特定に役立ちます。次に、私のユースケースでこれをどのようにセットアップしたかをお見せしましょう。面白いことに、Sentryは自社のパフォーマンス測定機能を活用したことで、年間16万ドルを節約しました！ファイルI/Oのトレースビューの設定私がデバッグしているエンドポイントは、普通のボトルネックではありません。長いHTTPコール、ファイルI/O、サードパーティ・コール（AI生成）、そして最後にDBクエリーがいくつかあります。問題のエンドポイントはShipixenというアプリのもので、コードベース全体、リポジトリ、コンテンツを生成し、Vercelにデプロイまでしてくれます。見ての通り、通常のCRUDエンドポイントではありません。このような状況は、影響を測定することなく毎月毎月機能を増やし続けるエンドポイントによく見られます。最終的なエンドポイントのボスと呼んでもいいでしょう。目の前の問題を理解するただひとつわかっていたのは、このリクエストのすべてのステップが必要だということでした。バックグラウンド処理にしたり、キューに分けたり、他のアーキテクチャを応用することも考えたが、実際のところは以下の通りです。ユーザーが利益を得るのは、すべてのタスクが完了してから。ユーザーは王様／女王様であり、私のアーキテクチャなど気にも留めない。私は行動を共にし、リクエストを完了するのにかかる時間を半分にするよう努力する必要がある。これが、44.94秒という短い処理時間の理由です。あるいは、平均的なシナリオでこのリクエストを完了するのにかかった時間です。さっそくデバッグシューズを履いて、トレースビューを開いてみました。驚いた！ SentryはネットワークI/Oの検出はうまくやりましたが、それ以外はすべてブラックボックスでした。そしてそれは理にかなっています。実行中の様々なファイルI/Oをすべてトレースする必要があることを、どうやって知ることができるでしょうか？ 54秒かかったという事実は無視して、目の前の問題に集中しましょう。どのタスクに一番時間がかかるのか、さらに重要なのは、どの順番でタスクが完了するのかがわからなかったのです。カスタム計装の設定幸運なことにSentryはカスタムインスツルメンテーションを行うメソッドを公開しているので、ファイルシステム上であれ、https上であれ、その中間であれ、あらゆる操作を追跡することができます。スパンを作成する関数呼び出しで、問題の操作をラップする必要があります。スパンとは、基本的に時間の計測値であり、「起こること」です。”thing “と呼ぶのは少し抽象的なので、スパンと呼ぶことにしました。お使いの言語やフレームワークにもよりますが、以下のようになります。そして、メソッドをスパンで囲み始めると、いつの間にかトレース・ビューワーはこのようになっていました。ボトルネックを特定する方法を探ってみましょう。ボトルネックの特定この見方をよく見てみましょう。一般的に、これらは最も注意すべき問題です。ロング・ラン・スパンペイロードを減らすことができるか？複数の並列タスクに分割できるか？バックグラウンドで実行できるか？より高速で効率的な新しいAPIはないか？互いに待機するウォーターフォール型スパン（並列化可能）互いに待機しなければならない非効率的なスパンオーダースパン間の依存関係最初のバイトまでの時間が遅い / ネットワーク依存のコールドスタート […]

Sentryのメトリクスで、16万ドル節約した方法

私をご存知の方は知っているでしょうが、私はいつも高速に動作するコードかどうか気にしています。最近、簡単なクエリーを実行したところ、1つのタスクに年間16万ドル近く費やしていることが判明しました。幸運なことに、私たちは3月にメトリクス・ベータを立ち上げました。ここ1ヶ月ほど10人のSentryエンジニアは、カスタム・データ・ポイントを追跡するためにMetricsを活用し、この無駄なインジェスト・コストにつながる問題を突き止めるために、多くの機能にわたって協力しました。解決すべき重要な問題の特定 save_event_transaction 私はSentryのSearch and Ingestチームにいます。同僚のJernej Strasnerと私は、Sentryのインジェストパイプラインを最適化できるかどうかを調べたいと思いました。最近のクエリで、save_event_transaction タスクに週に6,000ドル近く費やしていることがわかりました。パフォーマンスとメトリクスが、どのように問題特定に役立ったかこれはMetricsの完璧なユースケースだと思いました。このタスクの計算時間を可視化するためにMetricsをセットアップしたところ、save_event_transaction タスクに過去7日間で1.37週間の計算を費やしたことがわかりました。 save_event_transationタスクから始めるべきだということがわかったので、このオーバーヘッドを減らす方法を特定するために、発見の旅に出ました。トレース・ビューは、どの関数が最大の違反者であるかのヒントを与えてくれました。下のスクリーンショットでわかるように、この特定のトレースでは 8.00s秒のうち7.37s秒がset_subkeysに費やされていることが分かります。 set_subkeys 関数はmemcachedを通してキャッシュを設定し、私たちのインフラストラクチャで重要な役割を果たしている。この時点で、 set_subkeysの実際の影響を突き止めたいと思いました。そこで、Metricsを使用して、抽出されたトランザクションとスパンのメトリクスをプロットし、save_event_transaction. に関連してset_subkeysが費やす時間の割合を得ました。実際には、インジェストされたトランザクションごとに、最小で27％、最大で81％をキャッシュの設定に費やしていることになります。要約すると、トランザクションの処理時間の平均51％をキャッシュの設定に費やしているということです。財務用語で言えば、私たちはキャッシュの設定に1週間あたりおよそ3060ドル（年間16万ドル）を費やしていることになります。セーブイベントからSentryを保存する save_event_transaction:によって引き起こされる時間（とお金）のコストを削減するのに役立つ、Metricsの助けを借りて特定した主な方法は4つありました。キャッシュを設定するタイミングを慎重にする。 memcacheサーバー間のトラフィックのバランス配分を改善する。サードパーティツールのバックグラウンドスレッドを有効にする。 Twemproxyから代替へ移行する。これらの変更により、Sentryのコードベース全体のパフォーマンスが向上し、全体的なコスト削減につながりました。インパクトのある変更は一行で可能慎重に検討した結果、トランザクションごとにキャッシュを設定し、別の書き込み操作を必要とする代わりに、最初の読み取り操作の際にキャッシュを設定すればよいことにしました。この変更はGitHubでご覧いただけます。このマイナーチェンジを行った直後から、平均で300msから100ms以下に短縮されたのがお分かりいただけると思います。そしてこの変更は、他のceleryタスクにも大きな影響を与えました。トラフィック配分を改善するためにオペレーション・チームを巻き込むオペレーションの2人の同僚、Anton OvchinnikovとAlex TarasovもSentryのmemcachedサーバーの前にあるロードバランサー、twemproxyのKubernetes設定に問題があることを発見しました。彼らはtwemproxy-saveサービスをclusterIP Noneから通常のclusterIPに切り替えて、memcacheサーバ間のトラフィックを適切にバランスよく分散させる実験を行いました。その結果、ユーザースペースに費やされるCPU時間の割合が大幅に減少し、接続がより均等に分散されたため、CPU使用率が安定しました。実験の結果、sentry.tasks.store.save_eventのp95が大幅に減少しました。 C また、sentry.tasks.store.save_eventの時間が10ms（～13%）短縮しました。さらに、sentry.tasks.store.save_event_transaction p95も減少しました。サードパーティツールからのブロック解除メトリクスを詳細に分析した結果、インフラ監視ツールのSDKがstatsdプロキシに逐次的なリクエストを送信し、ブロックしていたため、Sentryのホットパスで高い実行回数が発生していることがわかりました。私たちはクライアントを更新し、メインのスレッドをブロックしないように別のスレッドでメトリクスを送信するバックグラウンドスレッド機能を有効にしました。一部のプロファイルでは、インフラ・モニタリング・ツールがプロキシにイベントを送信するのに非常に時間がかかり、トランザクション全体の30%を占めていました。この変更により、sentry.tasks.store.save_event_transaction.が11ms改善されました。 Twemproxy […]

【Beta版公開中】Metricsで重要指標を測定し、問題を迅速に解決する方法

4年前、私たちは開発者を第一優先したパフォーマンス監視で大きな一歩を踏み出しました。それ以来、数千ものソフトウェアチームが当社の最新APMソリューションを採用しています。しかし、パフォーマンスについてチェックすべき項目が多くある一方で、開発チーム内で別々のツールで管理しているところもあり、監視が分断されてしまっているケースもあります。エラーの根本原因や、パフォーマンスの問題を結びつけるのは、不必要に難しくさせます。SentryのMetricsは現在ベータ版で公開されています。最初の立ち上げの週に予告したように、Metricsはまだ開発途中でした。今回、ベータ版がリリースされ、無料で使用できるようになりました（ローンチウィークのアナウンスはこちら）。これは単なるツールではなく、あなたにとって最も重要なデータポイントを長期にわたって追跡するための新しいパートナーとなるでしょう。 Metricsを使えば、製品・サービス・コードが常に意図したとおりに動作していることを確認しながら、相関するトレースで問題を特定し、解決することができます。チームは、処理時間・チェックアウトのコンバージョン率・ユーザーのサインアップなどのカスタムメトリクスを監視して視覚化したり、トランザクションの継続時間などの既成のメトリクスを探索したりすることが可能になります。また、問題を発見した場合、問題の原因を解決するために相関トレースを使用することができます（もちろん、このような機能はありません）。メトリクスでクリティカルパスを監視あなたがショッピングカートとチェックアウトの機能を持つ製品やサービスに取り組んでいるとします。その処理フローは、あなたの会社の収益に直結しています。ですから、巨大なeコマースチェーンや、ユーザーがクレジットカード情報を入力しなければ続行できないSentry’sのようなSaaSビジネスを思い浮かべてください。ユーザーがハッピーパスを通して成功できるようにすることは、貴社の成功にとって非常に重要です。このパスに遅延が生じると、収益が失われ、おそらく（間違いなく）多くの顧客が離脱することになります。以下の例では、チェックアウトのレートを注視し、ユーザーがホームページから配送先住所の追加、チェックアウトへとスムーズに移動できるようにします。仮想のチェックアウトフローのGIFをご覧いただくとわかるように、訪問者は3つのステップを完了する必要があります。ホームページでスワッグをリクエストし、住所を入力し、注文を送信します。 Sentryの新しいメトリクスを使用すると、カスタムメトリクスを作成して、チェックアウトプロセスを完了したユーザー数をカウントし、視覚化することができます。チェックアウトフローの3つのステップを追跡するためにカスタムメトリクスを作成し、何人のユーザーがホームページでスワッグをリクエストし、住所を入力、そして注文を送信したかどうかを可視化できるようになりました。 Metricsのおかげで、チェックアウトのコンバージョン率が安定していることが可視化することが出来るようになりました。メトリクスが合わないとアラートを受け取るまた、アラートを作成して、重大な変更があった場合にSlack、Discord、Teams、Emailで通知を受け取ることもできます。チェックアウトフローですべてがうまくいっていることを確認するために、チェックアウト率が20%下がったら発動する閾値アラートを設定しました。アラートが表示される場合は、以下の画像のように表示されます。コンバージョン率が下がったのでしょう。結果をチェックすると、それを確認することができます。訪問者が購入者に転換していないようです。カスタムメトリクスによると、注文を正常に送信するユーザーが明らかに減少している。一般的な製品の旅はここで終わりです。しかし、Sentryの場合はまだ始まりに過ぎません。【メトリクスとトレース】デバッグの強化問題を特定できたので、当然の次のステップは解決策を見つけ出すことです。問題がどこにあるのか直感的に分かるかもしれませんし、特定のAPIに問題があるかどうかを確認するために、レスポンスタイムのような他のメトリクスを引き出すかもしれません。それで十分な場合もありますが、それ以上に厄介な場合もあります。そんな時こそ、1つのツールでアプリケーションに関する様々な種類のデータにアクセスできるのが本当に便利です。 Metricsは、アプリケーションの幅広いデータを見るのに適しています。一方、トレースは、フロントエンドからバックエンドまで、アプリケーションの深部を見るのに役立ち、根本原因を見つけるための豊富なトラブルシューティングデータを提供します。あなたが注目しているメトリクスと相関のあるトレースイベントを表示することで、2つのシグナルを簡単に結びつけることができます。イベント・サンプル・テーブルから、特定のトレース・ビューにドリルダウンすることができます。ウォーターフォールを見ると、このトレースに非常に時間がかかっていることがわかります。サードパーティのフルフィルメントAPIが原因です。これで、問題を解決し、ショップを復旧させるために何をすべきかがはっきりしました。数えるだけじゃない『分布・ゲージ・セット』上記の例では、カウント（”インクリメント “できるものをトラッキング）の例を示していますが、以下のようなさまざまなメトリックタイプを作成することができます。分布：最大値、最小値、平均値のように、時間にわたって集計できる値のリストを追跡します（たとえば、ページのロード時間）。プロセスの開始時間やキューの健全性やターンアラウンドタイムのように、アプリケーションの健全性を明らかにするようなことをレポートするために分布を使用することができます。例えば、Sentryでは、イベントマネージャがイベントを保存するのにかかる時間の分布を測定するために、Dogfood Metricsを使用しています。そして、通常95パーセンタイルを監視し、イベント・インジェスト・パイプラインに影響を与える可能性のあるリグレッションをチェックします。以下のように、青い点はこのメトリクスで収集されたサンプルです。サンプルテーブルを使用して単一のサンプルを選択するか、直接ドットをクリックしてトレースの詳細を表示することができます。ゲージ：増減する値を追跡します（例えば、使用可能なディスク容量や使用メモリなど）。セット： count_unique（ユニーク・ユーザー数など）のように、時間の経過とともに集計される値のセットを追跡します。さあ、始めましょう！ Metricsを追加する以前の場合は、SentryのPerformance機能を使えば、すべての典型的なパフォーマンス・メトリクスを測定することは可能でした。 […]

Sentry Category: Sentry 機能 / Sentry Features