Sentryでデバッグするヒント / Sentry Debugging Tips - Ichizoku

【Sentry】Reactのデバッグを簡単にする方法

初期UIがサーバーでレンダリングされたものと一致しないため、ハイドレーションに失敗したら、とても陰鬱な気持ちになると思います。 Next.jsやReactベースのメタフレームワークを使ってサーバーレンダリングされたページを構築しているなら、ハイドレーションエラーが起きると最悪な気持ちになり、デバッグが困難であることはご存じでしょう。 Reactにおけるハイドレーションとは、サーバー上でHTMLとしてレンダリングされたReactアプリケーションが、ブラウザ上でインタラクティブになるときに発生するプロセスのことです。ハイドレーションエラーは、クライアント上でReactによってレンダリングされたマークアップが、最初にサーバーからレンダリングされたHTMLと一致しない場合や、サーバーから無効なHTMLが送信され、Reactがそれを修正できなかった場合に発生します。日付やローカライズなどであれば、避けられないケースとなることも有り得ます。Reactのコードでは、このような不可避な差異に対するエラーを抑制することができますが、ほとんどのハイドレーションエラーは、アプリに何らかのバグがあることを示しています。この記事では、ハイドレーションエラーの修正方法ではなく、Sentryを使用したハイドレーションエラーをデバッグする方法について説明します。開発中にハイドレーションエラーが発生すると、選択したJavaScriptフレームワークは通常、エラーを引き起こしたコードに関するいくつかの詳細とともに、大きなエラーメッセージを表示します。しかし、ハイドレーションエラーは通常、本番環境では表示されませんし、原因も曖昧な状態になりがちです。一般的なユーザーは、おそらくエラーレポートとともに有用なスクリーンショットを提供することはできないでしょう。また、ブラウザの開発者ツールなどでエラーを探そうと思うことは皆無に近いでしょう。さらに言えば、Sentryが自動的に作成するエラー問題も、解決にはあまり役に立たないでしょう。『セッションリプレイ』を使って原因追及！もしあなたがSentryのセッションリプレイ機能を用いることで、ユーザーがハイドレーションエラーを起こしたときにユーザーセッションの再現を取得する設定なら、Sentryは特定のハイドレーションエラーのイシューを自動的に作成します（しかも無料です！） Sentryが自動的に特定のハイドレーションエラー問題を作成します。すべての同じエラーをグループ化します。エラー発生時に存在したサーバーレンダリングと、クライアントレンダリングの両方のマークアップをキャプチャします。ビジュアルモードと、プレーンHTMLモードの両方で差分を表示します。注意点として、SentryのJavaScript SDK、バージョン7.87.0以上を使用していることと、セッションリプレイを有効にしていることを確認してください。グループ化されたハイドレーションエラーが、Sentryでどのように見えるかご紹介します。 Hydration Error（ハイドレーションエラー）という名前なので、課題リストビューで簡単に見つけることができます。表示するイベント（推奨、最新、最古）を選択し、イベント間を移動してコンテキスト情報を比較できます。サーバーとクライアントの間でスライドする差分を表示します（差分ビューアを開くと、ビジュアル差分とHTML差分を並べて表示することもできます）。『ハイドレーションエラーの解決』をクリックすると、ハイドレーションエラーの解決に関するヘルプが表示されます。ハイドレーションエラーのデバッグ標準的なハイドレーションエラーの内容は、サーバーでレンダリングされたHTMLがクライアントでレンダリングされたHTMLと一致しなかったと述べていることが多いです。そのため、差分ビューアーはこれらの違いを見つけるのにとても役立ちます。 Before「ビューはサーバーでレンダリングされたもの」で、 After「ビューはReactがクライアントでレンダリングしたもの」です。もしかすると、こちらの例でお気づきかもしれません。それは「変更前」と「変更後」が見た目がほとんど同じに見えるということです。 HTMLの差分を調べると、サーバーでは空白のページがレンダリングされ、クライアントではHTMLがレンダリングされている、というケースがあります。しかしこれは正しくない状態です。ブラウザのネットワークタブで確認したところ、HTMLは間違いなくサーバーでレンダリングされています。ハイドレーションエラーの原因となっているコードの本当の問題は、サーバー側でレンダリングされたHTMLと、クライアント・レンダリングされたHTMLが一致していないことではなく、自身が作成したHTMLが無効で（<p>が<p>の中に含まれている）、Reactがエラーを投げたことです。これが『ハイドレーションエラーが最悪な理由』です。ではなぜdiff（ファイル差分）によると、サーバー上にHTMLがレンダリングされていないように見えるのでしょうか？ Reactが無効なHTMLのために無意味なハイドレーションエラーを投げたことを考えると、Sentryは問題が何であるかについて最善の努力を尽くして推測するしかありません。通常、あるイベントに意味のないdiffがある場合、別のイベントの方が役に立つかもしれません。要するに、Reactがハイドレーションエラーを投げたときは、修正が必要な問題があるということです。そして、Reactは本番環境で問題を修正するために必要な詳細を教えてくれないので、Sentryはハイドレーションエラーの差分ツールの空白を可能な限り埋めることで、問題をよりよくデバッグできるようにしてくれます。ハイドレーションエラーの問題や差分を作成すると、Sentryの利用金額は増える…? すでにセッションリプレイを使用している場合、自動的にグループ化されたハイドレーションエラー課題を『無料』でご利用いただけます。 Sentryのハイドレーションエラー問題は、リプレイとその関連データから生成されるため、エラークォーターにも影響しません。さらに、ハイドレーションエラーのアラートもデフォルトで表示されます。セッションリプレイを使っているなら、Sentry に送信される前に、デフォルトですべてのテキストコンテンツを「 * 」でマスクし、クライアント上のすべてのメディア要素をブロックすることに気づいたかもしれません。この記事では、Session Replay SDK がどのように設定されているかによって、ハイドレーションエラーの画像に示されている例は、「 * 」ではなくテキストを表示しています。 […]

【Sentry】Android開発のデバッグを効率化する方法

Androidアプリのデバッグには、クラッシュ、ANR、一貫性のないログなど、独特な課題が豊富にあります。しかし、問題を素早く特定して解決し、より良いパフォーマンスとユーザー体験を実現する簡単な方法がいくつかあります。今回は、Android のデバッグを効率化する基本的なツールとテクニックを紹介し、ANR について説明します！ Androidデバッグにおける「3つ」の基本 Android StudioのLogcat Logcatはリアルタイムにログを出力し、手動でエラーを見つけるのに役立ちます。このツールでは、以下のようなカスタムタグを使用することで特定の問題を切り分けることが簡単にできます。 Logcatで「MyAppTag 」でフィルタリングすると、無関係なログを選別することなく、NullPointerExceptionのような特定の問題に焦点を当てることができます。 Android Studioのブレークポイントブレークポイントは、実行時の動作を検査するために不可欠です。コードの重要な行にブレークポイントを設定します。ブレークポイントがトリガーされると、Android Studioは実行を一時停止し、変数（結果）を検査したり、コードの実行をステップ実行してロジックの展開を確認したりすることができます。この方法は、フロー制御や計算の微妙なバグをキャッチするために非常に有効です！ブレークポイントがトリガーされると、Android Studioは実行を一時停止し、変数（結果）を検査したり、コードの実行をステップ実行してロジックの展開を確認したりすることができます。この方法は、フロー制御や計算の微妙なバグをキャッチするために非常に有効です！ Sentry によるリアルタイムのエラー追跡　ローカルでの開発デバッグや手動ログだけに頼るのではなく、Sentry は本番環境でのエラー追跡を自動化します。例えば、APIリクエストが失敗した場合を追跡する場合、以下のように記述します。 Sentryはエラーをキャプチャし、スタックトレース、ブレッドクラム（エラーに至るまでのイベント）、環境の詳細を含む詳細なレポートを生成します。このコンテキストは、アプリが稼動した後に問題を診断し解決するために非常に貴重です。Sentryはまた、スタックトレースやパンくずのような追加コンテキストでLogcatログからエラーレポートをキャプチャし、強化することによって、Logcatと統合することができます。さて、基本をカバーしたところで、Androidアプリケーションで非常に頻繁かつ一般的な問題であるANRに取り組む方法など、Androidをデバッグするための他の戦略について、さらに深く掘り下げてみましょう。 AndroidでANRを検出する ANR（Application Not Responding）は、アプリのメインスレッドが長時間ブロックされ、システムがエラーダイアログを表示することで発生します。最も一般的なものは、Input Dispatching Timeoutで、ユーザーが操作した後アプリのメインスレッドが5秒以上応答しない場合に発生します。これはユーザー体験に大きく悪影響を与え、Google Playストアでアプリのダウングレードにつながる可能性があります。 AndroidでANRを検出する方法はいくつかあり、それぞれに長所と短所があります。トレードオフの関係性にあります。以下で確認していきましょう。ウォッチドッグスレッド：メインスレッドに定期的にタスクを送信します。スレッドが設定した時間（通常は5秒）以内に応答しなかった場合、ANRが発生したと見なされます。この方法はリアルタイムで検出できますが、ユーザーとの対話がない場合は誤検出してしまうリスクがあります。ネイティブシグナルハンドラ：ネイティブレベルでシグナルハンドラをインストールすることで、システムによって発生したANRをリッスンすることができます。この方法はネイティブのシグナルを捕捉できますが、バックグラウンドのANRをカバーできず、提供されるスレッド情報も限られてしまいます。アプリケーション終了情報API（Android 11以上）：この新しいAndroid APIは、完全なスタックトレース、スレッド情報、デッドロック検出など、ANRの最も正確な検出を提供します。フォアグラウンドANRとバックグラウンドANRを区別しますが、Android 11以上でのみ利用可能です。 ANRの検出方法はまだ半分に過ぎません。 AndroidのANRのデバッグについて、Sentryを使用して説明しましょう。 SentryによるANRのデバッグ ANR が発生すると、Sentry は自動的に発生時のアプリの状態、デバイスのパフォーマンス（メモリやバッテリー容量など）、および完全なスレッドダンプを含む重要な詳細を瞬時にキャプチャします。実際のシナリオを挙げて、確認していきましょう。スレッドロッキングの問題でアプリが「Input Dispatching Timeout」を出力したとします。Sentryを使えば、ブロックを引き起こしている正確なスレッドを示す詳細なレポートを受け取ることができます。同期化の問題なのか、何か他のものがメインスレッドをロックしているのかを突き止めることができます。パフォーマンスプロファイリングを使ってANRを解決する […]

Sentryを使って React のデバッグを改善する方法

このガイドは、一般的なバグやパフォーマンスの問題を特定し、解決する方法を解説していきます。クライアントサイドのReactのデバッグを扱いますが、サーバーサイドレンダリングを使用するReactアプリを持っている場合は、Node.jsのデバッグガイドやオンデマンドのワークショップの記事でその方法がわかります。ぜひそちらもご覧ください。以下のセクションでは、次のことを解説していきます。 Chrome DevTools、VS Code、およびReact Developer Toolsを使用したReactデバッグの基礎最小限のバグと最大限のパフォーマンスを実現するReactアプリを作成する方法一般的なReactのエラーやパフォーマンス課題を特定する方法、それらの課題を改善する方法 SentryがどのようにしてReactのバグやパフォーマンス課題を本番環境で記録しているか、その問題が発生した際に自ら察知するための方法 Reactデバッグの基礎 Chrome 開発者ツールを使用した React のデバッグすべての主要なブラウザ開発ツールには、JavaScriptデバッガが含まれています。ブラウザからF12キーを押すことで、Chrome 開発者ツールのコンソールにアクセスできます。開発者ツールの「Sources」パネルが開き、3つのセクションが表示されます。次の通りです。ページコードエディタデバッガ「ページ」セクションでは、ページが要求したすべてのファイルのファイルツリーが表示されます。React コンポーネントのファイルを選択すると、そのコードが「コードエディタ」に表示されます。「デバッガ」には、JavaScript コードを精査するためのツールが表示されます。「コードエディタ」で行番号をクリックするとブレークポイントを設置することができます。行番号を右クリックし、ポップアップメニューから適切な項目を選択することで、条件付きブレークポイントやログポイントを追加することができます。イベントリスナーブレークポイントは、「デバッガ」セクションで追加できます。イベントリスナーブレークポイントとは、さまざまな状況でアプリをデバッグするためにDevToolsで利用可能な多くのブレークポイントの中の一つです。ちなみに、Chrome for Developersの「Pause your code with breakpoints」で、さまざまなタイプのブレークポイントについて学ぶことができるので、こちらの記事も読んでいただくと、理解をさらに深めることができます。さて、コード実行がブレークポイントで一時停止すると、「デバッガ」セクションの「スコープ」タブで、一時停止時点でのローカル変数とグローバル変数の値を確認することができます。スコープ内にある値は、DevToolsウィンドウの左下にある「コンソール」パネルで参照することができます。コンソールパネルが表示されない場合は、Escキーを押してみることを試してください。また、「デバッガ」の上部にあるボタンを使用して、コードを一つずつステップ実行し、変数の値がどのように変化するかを確認することができます。これは問題のデバッグに役立ちます。「BasicCounter」コンポーネントの「Increment」ボタンをクリックした時の状態を下の画像で示します。 stateValue変数が増加しない場合がありますが、これはインクリメント関数内でcount状態の値に設定されているにもかかわらず、予期しない動作かもしれません。コードをステップ実行することで、「Increment」ボタンがクリックされたときにstateValue変数がゼロのままである理由がわかります。 stateValueは、コンポーネントが再レンダリングされるたびに「0」に設定されます。count状態が増加するため「Increment」ボタンがクリックされるとコンポーネントが再レンダリングされるという仕組みです。ブで、Chrome 開発者ツールを使用したJavaScriptのデバッグについてさらに学ぶことができます。ただ、Reactのデバッグ作業をブラウザの開発者ツールだけで補おうとしても限界があります。開発者ツールのデバッガを使用してReactコンポーネントの状態値を更新することは可能ですが、推奨されません。 Reactのpropsとstateは不変であり、直接変更すべきではありません。代わりに、React Developer Toolsを使用して状態値やpropsを変更してください。それでは、次にReact Developer Toolsの使用方法について説明します。 React […]

【必読】Webページを読み込む前に高速化する方法

私たちは通常、ブラウザ上に表示されるものを見始めた時や、コンテンツを消費したりページと対話したりできるようになった時に、何が起こるかを測定するという文脈で、Webパフォーマンスについて話します。開発者として、フロントエンド開発者として、Webパフォーマンスは大変重要だからです。例えば、以下のCore Web Vitalsは『私たちが見ることができるもの』、『使用することができるもの』、『経験することができるもの』についての議論を導くものです。 First Contentful Paint（FCP）：ユーザーが最初にページを開いてから、コンテンツの一部がレンダリングされるまでの時間のこと Largest Contentful Paint（LCP）：ページのロードタイムラインにおいて、ページのメインコンテンツがロードされるまでの時間のこと Interaction to Next Paint（INP）：Webページがユーザーの入力にどれだけ速く反応するかを測定するしかし、Webページの最初のバイト(Byte: データのごく小さい単位)がブラウザに受信される前に起こるイベントについてはどうでしょうか？そのようなイベントを測定し、最適化することで、Webページやアプリケーションの読み込みをさらに速くすることは可能でしょうか？ Sentryトレースビューを使い、TTFB前のイベントがどのように可視化されるのか Sentryのトレースビューを確認すると、browserウィンドウで何かがレンダリングされる前に起こるイベントがキャプチャされ、[browser]のスパンとしてラベル付けされていることがわかります。キャッシュ、DNS、接続、TLS/SSL、リクエスト、レスポンスの6つのスパンが時系列で登録されています。レスポンス以前のすべてのイベントは、Webページ/リソースへのリクエストからレスポンスの最初のバイトが到着し始めるまでの時間を計測するTTFB（Time to First Byte）に先行します。 Sentryがブラウザで初期化されていないにも関わらず、これらのイベントがどのようにしてSentryが捕らえているのか不思議に思うかもしれません。その答えは、Performance API（Webアプリケーションのパフォーマンスを測定するために使用されるウェブ標準のグループ）にあります。より具体的にいうと、Navigation Timing APIにあります。本当に素晴らしい点は、ブラウザでパフォーマンス API に直接アクセスできることです。パフォーマンス・エントリーのほとんどは、どのWebページに対しても記録されており、それらを取得するためのセットアップや余分なコードは必要ありません。開発ツールのコンソールを開き、window.performanceと入力して試してみてください。以下のようなものが表示されます。 ※解析しやすいように、関連するタイムスタンプを手作業でグループ化し、順番に並べています。それでは、Sentryはどのようにしてブラウザのスパンを読み取っているのでしょうか？パフォーマンスAPIが、URLがブラウザでリクエストされた瞬間からタイムスタンプでこれらのメトリクスを記録する結果、Sentry JavaScript SDKは、初期化後にこれらにアクセスし、Webページがロードされる前に、時系列的に起こったイベントの完全なリストを埋め戻し、トレースビューで可視化できるように、関連する完全なトレースにスパンとして送信することができます。 Webページが読み込まれる前に起きていること window.performanceは、Webページのコンテンツがブラウザに表示されるまでに起こるさまざまなイベントへのウィンドウを提供します。これはPerformanceオブジェクトを返し、そのオブジェクトは上記のコード例にあるtimingpropertyを含んでいます。これはコードを書かずにページ読み込み時にブラウザによって記録されたイベントを検査する素早い方法ですが、Performance.timingプロパティは現在では非推奨となっており、PerformanceNavigationTiming APIに取って代わりました（これまでのところ、わずかな変更のみです）。 Navigation Timing Level 2仕様のこの図は、ブラウザでナビゲーション要求が行われた瞬間から、現在のドキュメントのロードイベントが完了するまでPerformanceNavigationTimingイベントが記録される順序を示しています。すべてのイベントが各ページのロードで利用できるわけではありませんが、順序は上記のwindow.performanceを使用して観察したものと一致しています！それでは次に、関連する各イベントメトリックを調べてみましょう。一体、ボンネットの下で何が起こっているのか、そして、トレースビューのブラウザスパンを入力するために、特定のタイムスタンプから Sentry によってどのように計算されるのかを見てみます。そして、この新しい知識を得ることで、TTFBの前にWebパフォーマンスを最適化できるかもしれません。ブラウザキャッシュリソースがHTTP GETを使用してフェッチされる場合（例えば、Webページへの標準的なリクエスト）、ブラウザは最初にHTTPキャッシュをチェックします。fetchStartは、ブラウザがキャッシュのチェックを開始する直前の時刻を返します。Sentry Trace Viewのキャッシュスパンは、fetchStartタイムスタンプとdomainLookupStartタイムスタンプの間の時間として計算されます。トレースビューのキャッシュスパンのゼロでない値は、ブラウザがブラウザキャッシュからリソースを取得するのにかかった時間を表します。キャッシュスパンが長い場合、遅いブラウザや古いブラウザを使用しているか、ブラウザのキャッシュを頻繁にクリアしないユーザである可能性が高いといえます。ブラウザDNS 次のスパンは、DNS（ドメインネームシステム）のルックアップ時間（ドメイン名をIPアドレスに変換したり、IPアドレスをドメイン名に変換すること）を報告しています。ユーザーがURLをリクエストすると、DNSはデータベース内のドメインを「検索」し、IPアドレスに変換するために問い合わせを行います。これを完了するのにかかった合計時間は、domainLookupEndタイムスタンプ値からdomainLookupStartタイムスタンプ値を引くことで計算されます。ブラウザ接続次に、ブラウザがWebサーバに接続するまでの時間を測定します。これは「コネクション・ネゴシエーション」と呼ばれ、connectStart（ブラウザがWebサーバーへの接続を開始するとき）とconnectEnd（Webサーバーへの接続が確立されたとき）の2つのイベント間の時間として測定されます。 […]

2024年にGoogle Lighthouseのスコアをハックする方法

Google Lighthouseは、開発者の間でWebページのパフォーマンスをゲーム化し、促進する最も効果的な方法の1つです。Lighthouseを使えば、全体的なパフォーマンス、アクセシビリティ、SEO、Googleが考える「ベストプラクティス」に基づいてWebページを評価することができます。これらのテストは、フロントエンドフレームワークのすぐに使えるパフォーマンスを評価したり、熱心なリファクタリングによってパフォーマンスが改善されたことを喜んだりするのに使うかもしれません。そして、Lighthouseの満点のスクリーンショットをソーシャルメディアで共有するのが好きなのはご存じでしょう。紙吹雪のお祝いにふさわしい栄誉です。 Lighthouseが私たちのような開発者にパフォーマンスについて語らせるという事実だけでも勝利です。しかし、パーティーの片棒を担ぐようなことはしたくないですが、実際のところ、Webパフォーマンスはこれよりもはるかに微妙なものです。この記事では、Google Lighthouseがどのようにパフォーマンス・スコアを算出しているかを検証し、この情報を使って、私たちに有利になるようにスコアを「ハック」してみます。Lighthouseをどこまで「騙す」ことができるか、そして自分たちにふさわしいスコアよりも良いスコアを出すことができるか、楽しみながらやってみましょう。その前に、データについて話しましょう。現場データは重要であるローカル・パフォーマンス・テストは、Webサイトのパフォーマンスが正しい方向に傾いているかどうかを理解するための素晴らしい方法ですが、現実の全体像を描くことはできません。WWW（ワールドワイドウェブ）は西部の荒野であり、人々がWebサイトにアクセスするために使用しているさまざまなデバイスの種類、インターネット接続速度、画面サイズ、ブラウザ、およびブラウザのバージョン（これらすべてがページパフォーマンスとユーザー体験に影響を与える可能性があります）を、私たちはほぼ確実に見失っています。 Sentryのようなアプリケーションパフォーマンス監視ツールによって、実際にWebサイトを使用している人々のデバイスから収集されたフィールドデータ（しかも大量に）は、制御された条件下でハイスペックなスーパーパワー開発マシンを使用して、1サンプルサイズから収集されたラボデータよりもはるかに正確なWebサイトパフォーマンスのレポートを提供します。フィリップ・ウォルトンは2021年、HTTPアーカイブのデータに基づき、「Lighthouseで100点を獲得したページのほぼ半数が、推奨されるCore Web Vitalsのしきい値を満たしていなかった」と報告しています。パフォーマンスとは、単一のCore Web Vitals指標やLighthouseのパフォーマンススコア以上のものです。私たちが話しているのは、扱う生データの種類をはるかに超えるものです。 Webパフォーマンスは数字以上のもの Webパフォーマンスについて話すとき、スピードが最初に話題に上ることがよくあります。これは測定する上で最悪なことではありませんが、スピードはおそらくビジネスのKPIや売上目標に大きく影響されることを念頭に置かなければなりません。 Googleが2018年に発表したレポートによると、ページの読み込み時間が3秒以上になると、直帰する確率が32％増加し、10秒になると123％に跳ね上がるといいます。つまり、より多くの売上につなげるには、直帰率を減らす必要があるという結論になります。そして、直帰率を減らすには、ページの読み込みを速くしなければなりません。しかし、「読み込みを速くする」とはどういうことなのでしょうか？ある時点で、Webページの読み込みをこれ以上速くすることは物理的に不可能になります。人間やそれをつなぐサーバーは世界中に散らばっており、現代のインターネット・インフラは一度に多くのバイト数しか配信できないのです。要するに、ページの読み込みは一瞬ではないということです。スピードとは何か？Googleのいう、ページ読み込みイベントとは。単一の指標では完全には捉えられない体験のことです。ユーザーが「速い」と感じるかどうかには、読み込み体験の間に複数の瞬間があり、1つの瞬間だけに注目すると、残りの時間に起こる悪い体験を見逃してしまうかもしれません。ここでのキーワードは『体験』です。本当のWebパフォーマンスとは、数字やスピードよりも、ユーザーとしてページロードやページの使いやすさをどのように体験するかということなのです。そしてこれは、Google Lighthouseがどのようにパフォーマンススコアを計算するかという議論にうまくつながっていく。(あなたが思っているよりも、純粋なスピードは重要ではありません）。 Google Lighthouseのパフォーマンススコアはどのように計算されますか？ (CLS)）と、ページ読み込みのタイムライン全体を通して観察可能なその他のスピード関連メトリクス（Speed Index (SI)、Total Blocking Time (TBT)）に基づくスコアを加重平均して算出されます。このように、メトリクスは総合スコアで重み付けされます。各スコアに割り当てられた重み付けは、Googleが優れたユーザー体験のさまざまな構成要素にどのような優先順位をつけているかを教えてくれます。 1. Webページはユーザーの入力に反応しなければならないこの指標は、FCP（First Contentful Paint）後の合計時間を調べ、メインスレッドがユーザー入力への迅速な応答を妨げるほど長くブロックされている可能性がある場所を示すのに役立ちます。メインスレッドで JavaScript タスクが 50 ミリ秒以上実行されると、メインスレッドは「ブロックされた」と見なされます。TBTを最小化することで、Webページが物理的なユーザー入力（例：キーの押下、マウスのクリックなど）に確実に反応するようになります。 2.Webページは、予期せぬ視覚的な変化を伴うことなく、有用なコンテンツを読み込むべきである Lighthouseのメトリクスで次に重みがあるのは、Largest Contentful Paint（LCP）とCumulative Layout Shift（CLS）です。LCPは、ページのロードタイムラインの中で、ページのメインコンテンツがロードされた可能性が高い時点を示すもので、そのため有用です。メインコンテンツがロードされた可能性が高い時点で、ユーザーがページを使用でき、予期しないビジュアルシフト（CLS）の影響を受けないように、ビジュアルの安定性も維持したいものです。良いLCPスコアは2.5秒未満です（私たちはWebサイトを可能な限り高速化しようとしていることが多いので、これは想像以上に高いスコアです）。 […]

バックエンドが原因で遅くなったWebページのデバッグ手法について

開発者として、誰かがあなたのWebサイトの読み込みが遅いと言ったとき、あなたはどんな反応をすべきでしょうか？「ユーザーに任せている」と言わない限り、あなたはすでに正しい道を歩んでいます。ユーザーの苦痛を和らげることを選択したのですから、読み込みの遅さやパフォーマンスの問題を特定し、修正するプロセスをご案内します。実際、パフォーマンスの問題をどのように解決するかはさまざまですが、開発者としては、解決への最短経路を常に求めています。小規模から中規模の静的サイトであれば、ブラウザの開発ツールに組み込まれているLighthouseスコアで十分でしょう。個々のページのCore Web Vitalsが表示され、通常、Webサイトのパフォーマンスを改善するために必要な変更を行うのに十分な情報が得られます。とはいえ、Lighthouseのスコアだけを目標にすべきではありません。 Webサイトが成長したり、静的でなくなったりすると、パフォーマンスの問題をデバッグするために、より詳細な洞察が必要になります。この投稿では、私が開発したサイトを紹介します。このサイトは静的Webサイトとは程遠く、各ルートは人気リズムゲームのゲーム内スコアに基づいて、ユーザーにカスタムされたポケモンのようなカードを動的にレンダリングします。そのような動的な性質をもつため、すべてのブラウザとユーザーが使用する可能性のある・すべてのネットワークで・すべてのルートをテストすることは不可能です。その代わりに、実際のユーザーによる実際のセッションのパフォーマンスをモニターして、いつ問題が発生し、どのように解決できるかを知る必要があります。問題の発見モニタリングツールがなければ、ドッグフーディング（アプリを自分で使用すること）、またはユーザーレポートという2つの方法のいずれかでパフォーマンスの問題に遭遇する可能性が高いです。ドッグフーディングは重要ですが、インターネット接続が良好なハイエンドのデバイス1台でしかアプリを使用していない可能性が高く、それがユーザーの間で一般的かどうかを検討する必要があります。ユーザーレポートは非常に有用ですが、正直なところ、明らかなレポートチャネルを持っていない場合、それらはほとんどありません（そして、その場合でも、役に立たないか、または再現するのが難しい場合があります）。常にログを読み、リクエストのタイミングを計っていない限り、どこで間違ったのか、なぜ間違ったのかを正確に突き止めることは難しいのです。 Sentryのユーザーフィードバックとセッションリプレイ Sentryでは、あなたのサイトに常に存在するユーザーフィードバックウィジェットにオプトインすることができます。このウィジェットは、ユーザーが見つけたバグを直接Sentryのダッシュボードに報告することができ、スクリーンショットを追加するオプションもあるので、即座に実用的な洞察を得ることができます。さらに、Sentryは、このフィードバックを「セッションリプレイイベント」と連動させ、ユーザーがボタンをクリックしたり、サイト内を移動するたびに、追加の有用な詳細を含むパンくずなど、ユーザーのWebサイトとのインタラクションの完全な再現を見ることができます。最近、Sentryのウィジェットを介してユーザーがフィードバックを送信し、ロードに時間がかかる理由を尋ねたとき、私はWebサイトのページロードが遅いことに気づきました。セッションのリプレイをチェックすると、明らかに読み込みが非常に遅かったのですが、フィードバックとセッションのリプレイで提供された情報でも、大きな画像や過剰なJavaScriptのような明らかな問題や迅速な解決策を見つけることができませんでした。この問題については、Sentryのトレースビューをもう少し深く掘り下げる必要がありました。トレースの使用 Sentryのトレース機能は、フロントエンドからバックエンド、そしてサービス間のトランザクションをリンクし、ソフトウェアの接続されたビューを提供することで、コードのパフォーマンスを追跡するために使用されるツールです。トレースビューは、各トランザクションにかかる時間から、より具体的な問題のデバッグを助けるためにユーザが使用したデバイスやブラウザまで、あらゆる情報を提供します。トレースビューは、ユーザーフィードバックや問題によってトリガーされたリプレイにも添付され、ユーザーがページをロードしたとき、ボタンをクリックしたとき、サイト内を移動したときなど、舞台裏で起こったすべてのことを簡単に調べることができます。セッションリプレイイベントのトレースを参照した後（パフォーマンスタブを少し調べると同時に）、私のサイトの（かなりひどい）スローダウンはナビゲーション中のロード関数にあることがわかりました。それはいいことですが、私は15分以上前にコードを書いたのです。幸運なことに、Sentryはリクエストまでの詳細をすぐに提供してくれました。修正リピート・リクエスト私が犯した最初のミスは、それを書くときに明らかであったはずなのですが、不必要に同じリクエストを何度も繰り返し、一度に一つのものだけを取り出すことでした。ユーザー」オブジェクトを構築する際に、大きなJSONデータの塊から特定のプロパティを取り出す必要があったのですが、1回の関数呼び出しで必要なプロパティを返すのではなく、同じ関数を8回繰り返し呼び出して配列を作成し、その都度1つのプロパティしか取得しませんでした。 Sentryのトレースビューで、私はすぐに問題を特定することができました。青い「自動グループ化された」スパン（2秒近くかかりました🤮）が最初に目に留まり、それを拡大して各スパンが同じリクエストエンドポイントを持っているのを見ると、私のコードで何が修正されるべきかは明白でした。リクエストウォーターフォールさてさて、滑稽なほど酷いコードはこのくらいにして、解決策があまり明確でない問題に移りましょう。上の画像では、「自動グループ化された」リクエストの先にも、ページロードの終わりまで小さな階段があるのがお分かりいただけるでしょう。これはリクエストウォーターフォールと呼ばれるもので、リクエスト（この場合は外部APIへのリクエスト）を直列に行い、前のリクエストを終えてから次のリクエストを開始することで発生するものです。このウォーターフォールはできるだけ避けたいものですが、リクエストを連続して行う必要がある状況もあります（一般的には、ある呼び出しのリクエストが前の呼び出しの結果に依存している場合）。 1回の呼び出しで楽曲IDのリストを取得しているのですが、より具体的な情報を取得するには、特定のIDごとに個別のリクエストを行う必要があります。私が最初に考えたのは、1回のリクエストですべての情報を集めることはできないので、1つずつ呼び出す必要があり、現在持っているパフォーマンスはそのままになってしまうということでした。幸いなことに、この問題を抱えたのは私が初めてではなく、リクエストのウォーターフォールを回避する2つの解決策を見つけました。直列運転と並列運転ロード時間のパフォーマンスを最適化する場合、リクエストを直列に実行しないことが最も重要ですが、常に可能というわけではありません。直列に実行する必要があるときと、そうでないときを見分けることが重要です。なぜなら、可能な限りリクエストを並行して実行する必要があるからです。直列実行の反対は並列実行で、その名の通り、すべてのリクエストが同時に実行され、最も遅いリクエストが終了するたびにグループとして解決されます。JavaScriptでは、コード上の違いはごくわずかですが、実行時に実際に起こることは大きく異なります。上記のように、リクエストを直列に呼び出すコードから並列に呼び出すコードに変更した後、最終的に恐ろしいウォーターフォールを取り除くことができ、Sentryでこれを確認することができます。両方のロード関数のトレースを比較すると、かつては階段状だったものが、今では崖のようになっており、最も遅いリクエストが終了するとすぐにページがロードされることがわかります。リクエストの処理方法を変更した後、P75（75％のユーザーにとっての平均ページ読み込み速度）を6.5秒からわずか2.3秒まで下げることができました。一歩前進 SvelteKit（またはReactではこのようなもの）のpromiseストリーミングを使えば、このパフォーマンスの大幅な向上をさらに一歩進めることが可能になります。サーバーのロード関数からクライアントにpromiseをストリーミングすることで、すべてのリクエストが終了する前にページをレンダリングできるようになります。これには累積レイアウトシフト（Cumulative Layout Shift）の可能性に対処する複雑さが加わりますが、ページのロード速度を劇的に改善する機会があり、ユーザーにとって最も重要なデータをより迅速に利用できるようになります。パフォーマンスには価値があるこの記事の冒頭で、最も早く解決する道は常に取るべき道であると述べました。パフォーマンスの問題は、「バグ」ではないという点でユニークであり、Webサイトのエラーやクラッシュを引き起こしていないため、多くの開発者が見過ごしてしまうことがあります。しかし、一貫して速い読み込み速度は、10,000セッションに1回起こるエッジケースエラーよりも、ユーザーにとって同じように、いやそれ以上に重要です。Sentryを使用することで、このような抽象的な問題の発見と解決が非常に簡単になります。パフォーマンス問題のデバッグの詳細 Sentryのトレースがパフォーマンス問題のデバッグにどのように役立つのか、もっと知りたいですか？悪いLCPスコアをバックエンドの問題にトレースするSalmaのブログ記事をチェックするか、以下のワークショップの全容をぜひご覧ください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

『Requests』機能によるサードパーティAPIのデバッグ手法

インターネットは基本的に、たくさんのWebサイトが互いに通信し合っているだけの仕組みです。あなたがあるサービスに対して呼びかけ（リクエスト）をかけると、そのサービスからあなたに返答（レスポンス）が返ってきて、そのサービスがダウンしてあなたの午後が台無しになる、というものです。 Insightsの最新機能である『Requests』は、発信されたHTTPリクエストの動作を確認、理解、追跡、改善するための機能です。一般的なサードパーティのAPIや自社サービスの呼び出しであろうと、Requestsビューはすべての情報を一箇所に集めるのに役立ち、問題が発生したときにトラブルシューティングするための接続されたデバッグワークフローを提供します。お客様の問題、私たちの解決策 InsightsのRequestsは、他のサービスを呼び出す頻度や、それらのリクエストにかかる時間、3xx、4xx、5xxエラーコードの急増など、その他の興味深い情報を確認するのに最適です。学術的な興味はそれで十分ですが、ここではRequests機能が解決に役立つ現実の一般的な問題をいくつか紹介していきます。皆のためか、私だけのためか？サードパーティのサービスが停止しているのか、それとも自分のサービスが停止しているのか、それをすぐに知るにはどうすればいいのでしょうか？ Requestsを使えば、非常に簡単にできます。人気のあるサードパーティサービスでは、「Status 」リンクからサービスの稼働時間ページにアクセスできます。エラーの応答率を公式の稼働時間と照らし合わせ、エラーが発生しているのがあなただけかどうかを確認してください。 P.S. 人気のあるステータスページのリストはオープンソースです。助けて！レート制限されています！リクエストが殺到して、サービスが処理を止めることがあります。 409が多発し、サービスの利用を減らす方法を考えなければなりません。 Requestsを使えば、これはかつてないほど簡単になります！ドメインをクリックし、トランザクションあたりのスループットをチェックして、コードのどこでそのサービスを最も頻繁に呼び出しているかを確認します。機能は壊れているが、私の機能ではないアプリケーションがサードパーティのAPIを呼び出している場合、統合がうまくいっていないというバグ報告を受けることがあります。Requestsを使えば、これを追跡するのは簡単です。統合のドメインをクリックし、エラーレスポンスのサンプルを見つけ、関連するトレースを見て問題を見つけることができます。リクエストを始める Requestsはビジネスプランとエンタープライズプランに含まれています。始めるには、ドキュメントをチェックするか、今すぐSentryアカウントでお試しください。また、Sentryを初めてご利用になる場合は、今すぐ無料でお試しいただくか、デモをリクエストしてください。ぜひGitHub、Twitter、Discordでご意見をお聞かせください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

観察せず、デバッグしよう。

「観測可能性」という言葉は奇妙なものです。複雑な分散システムやマイクロサービスを監視するための洗練されたアプローチを説明する方法として、私たちはその価値を理解しています。しかし、この用語は本質的に受動的なものです（正直に言いましょう、ちょっと負荷の高いマーケティング用語です）。単に「観察」するだけでは、問題解決にはつながりません。特に、アクションにつながらないデータが大量にある場合はなおさらです。私たちは、開発者が行動を起こし、バグやエラー、その他の問題を解決するのを助けるためにSentryを構築しました。そして、この哲学は、新しいスパン・ファーストのトレースとメトリクス・エクスペリエンスという、観測可能性ツールの構築のアプローチにも受け継がれています。両者とも現在オープン・ベータ版となっており、皆様からのフィードバックをお待ちしています。新しいスパン・ファーストのトレース体験分散システム（マイクロサービスを含む）のデバッグは、複雑で相互接続された環境全体の問題を診断する必要があるため、大変困難です。例えば、eコマースアプリでユーザーが注文時に遅延が発生した場合、根本的な原因を突き止めるために複数のサービス（潜在的にはユーザーサービス、注文サービス、決済サービス、在庫サービス）をチェックする必要があり、デバッグプロセスが複雑で時間がかかります。フルスタックアプリケーションのデバッグは、問題がアプリケーションのフロントエンドまたはバックエンドのいずれかに起因する可能性がある場合、同様の課題を提示する可能性があります。トレーシングは、問題を引き起こしている特定のオペレーションを特定するために、システムやサービスを横断して、ユーザーとの対話からリクエストの完全なエンドツーエンドのパスを追跡するので強力です。トレースは、すべての開発者のデバッグツールキットの一部であるべきです。トレースをよりアクセスしやすく、効果的にするために、私たちは新しい、スパンベースのトレースモデルを構築しました。以前は単純化するために、トランザクションベースのモデルでトレースを構築していました。（ちなみに、トランザクションは複数のスパンで構成されます。例えば、HTTPリクエストに応答するウェブサーバーや、関数の単一の呼び出しがスパンになります。トレースについて詳しくはこちらをご覧ください）しかし、トランザクションベースのモデルでは、データベースクエリやネットワークリクエストのような重要な情報を照会することは困難でした。スパンが主要なトレース単位である新しいモデルでは、クリティカルなデータを照会し、根本原因を簡単に掘り下げることができます。トレースエクスプローラを使用した、既知の問題調査特定のスパン属性を使用して特定のトレースを検索することで、問題をプロアクティブに特定できるようになりました。例えば、ユーザーがページの読み込みが遅いと訴えたり、パートナーAPIが停止を報告した場合、ユーザーEメール、APIエンドポイント、またはルートでクエリし、適切なコンテキストでトレースを見つけ、問題を迅速に解決することができます。ユーザーからチェックアウト・エクスペリエンスが遅いと報告されたとします。ユーザー ID やスパンの説明のようなカスタムタグや既定のタグを含む、カーディナリティの高いデータを使用してスパンを検索することで、特定のトレースを見つけることができます。フルコンテキストでより速くデバッグするトレースエクスプローラーから、クエリされたトレースまたは特定のスパンをクリックして、再設計されたトレースビューに直接移動することができます。ウォーターフォール・ビューは、フロントエンドからバックエンドまで、またサービス全体にわたるアプリケーション・リクエストの完全な可視性を提供します。特定のスパンにドリルインすると、カスタムタグ、プロファイル、リプレイなど、効率的なデバッグのための適切なコンテキストと詳細なデータが得られます。メトリクスはトレースビューでも利用でき、デバッグに役立つコンテキスト情報の追加ソースを提供します。さぁ、はじめてみましょう！ Sentryアカウントをお持ちであれば、トレースを始めるのは簡単です。私たちのドキュメントの指示に従ってスパンの送信を開始するだけです。ぜひご利用ください！ IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

Fortune 500,000社のための今後の展望。あと80％です…

デイビッド・クレイマーがサイドプロジェクトに最初のコミットを行ったのは16年前のことでした。彼とクリス・ジェニングスがこのサイドプロジェクトを単純な問題を解決するために存在する会社に変えたのは12年前のことです。それ以来、我々は多くの人が考える「観測可能性」とは少し異なる道を歩んできました。Sentryは、ログを収集して監視ボックスをチェックすることを望むプラットフォームでも会社でもありません。 12年経った今でも私たちは、開発者のためのデバッグの簡素化という1つの重要な問題に注力しています。しかし、より重要なことは、開発者コミュニティからのサポートなしにはできないことです。私たちは現在10万以上の組織をサポートしており、昨年のARRは1億ドルを突破しました。素晴らしいことですが、なぜ気にする必要があるのでしょうか？どちらも恣意的な数字に過ぎません。しかし、これらのマイルストーンは、単に自分たちを褒め称えるための口実ではないのです。さてこの話は一旦横に置いておき、代わりに皆さんとSentryの次の展開に焦点を当ててまいります。（それでも足りない場合は、私たちのコミュニティでお祝いする楽しい方法がありますが、その前にどうかお付き合いください） Sentryのチーム 2019年、デイビッド・クレイマーはCEOからCTOに移行する際、Sentryを率いるために私を雇いました。ここまでは順調でした。本日、クレイマーと私は、次期CTOとしてセントリーに入社するデイヴ・ローゼンタールを迎え入れます。クレイマーは、新設された最高製品責任者の役割に移行します。デイヴは、世界で最も革新的な企業のいくつかで、新興企業の創業者と技術リーダーの経験があります。彼は今月初旬に入社し、私たちは彼をチームに迎えることに興奮しています。一方、CPOへの正式な肩書き変更については、クレーマーからのコメントをお読みください。(私が「公式」と言ったのは、多くの点で、彼は常にSentryのCPOだったからです）。 Sentryのプロダクトそして、クレイマーのオープンソースのサイドプロジェクトとして始まったSentryは、10万以上の組織と数百万人の開発者が自信を持って出荷できる会社に成長しました。当初から、そして現在もSentryは「発見」と「解決」という2つの成果を重視しています。私たちは、開発者が問題を知るだけでなく、ワークフローの中で問題を解決する方法をリアルタイムで示すことを可能にします。これが、Sentryが100,000以上の組織で信頼されている理由であり、この哲学を倍加することが、次の100,000以上の組織にサービスを提供するために成長する方法なのです。 Sentryバージョンの理想的な開発者アシスタントは、あなたの指先で利用可能なすべての関連するコンテキストであなたの問題をデバッグするのに役立ちます。私たちは、あなたのワークフローで最も重要な問題、あなたが働く場所（PRコメントを考えてください）、そしてソフトウェアの問題を素早く修正するのに役立つ信号の最も鋭い接続されたビューを提供することに対応し続けます。ですから、問題に行き着いたものの、ビデオのような問題の再現が必要な場合、あるいはスパンウォーターフォールを調査する必要がある場合、Sentryのデータストリームを使えば、どんな種類の問題でも簡単にデバッグすることができます。多くの企業は、ボトムアップ戦略（製品主導の成長、あるいはPLGと呼ばれることもある）で成功を収め、規模が大きくなると、スイッチを入れて企業バイヤーに売り込み（そして企業バイヤーのために構築し）始めるのが一般的です。しかし、Sentryは違います。PLGはとにかく、ソート・リーダーシップの訓練なのです。もしあなたが、販売戦略に関係なく、市場に出せる最高の製品を作っていないのであれば、なぜビジネスをしているのでしょうか？私たちは、想像上の「ペルソナ」を満たすために製品に機能を追加したりはしません。Sentryは開発者用ツールなのです。Sentryは、Fortune 500社だけでなく、Fortune 500,000社向けにも開発しています。そして私たちは、オープンソースにおける持続可能性の危機を解決するために私たちの役割を果たしながら、オープンに構築し続けます。ワークフローが変わっても問題は解決しない Gitが登場するずっと前の話です。当時のエンジニアは、パンチカードを使ってソフトウェアをリリースしていました。バグを修正するために「パッチ」（文字通りのパッチ。開発者がソフトウェアを構築する方法は今も変わり続けています。私たちが（購入者ではなく）実践者に焦点を当て続けるということは、Sentryが彼らが自信を持って出荷できるように支援するということです。あなたのペアプログラミングのパートナーがCopilotであろうと、Codyであろうと、Devinであろうと、Augmentであろうと）バグを軽減する必要があることに変わりはありません。簡単に言えば、私たちはまだ作り終えていません。どのように進化しようとも、現代の開発者のワークフローにマッチする革新的なソリューションを出荷し続けます。ささやかな感謝のしるし当社のクラウド・サービスで10万を超える組織をサポートしていることは光栄なことであり、当然のことではありません。私たちは、ユーザーの一人ひとりにコミットしています。私たちが、これまで歩んできた道のりの一部であったすべてのユーザーに感謝する最善の方法は、彼らのために構築し続け、彼らの進化するワークフローのありふれた細部にまでこだわり続けることです。そして2番目に良い方法は？無料のお菓子です！今年の残りの期間中、私たちはコミュニティに10万ドルのSentryグッズをプレゼントします。詳細はこちらをご覧ください。未来の詳細がどのようなものになるかはまだわかりませんが、私たちはこれまで以上に、道を切り開く開発者の役割に自信を持っています。私たちの周りの世界を定義するソフトウェアを出荷する彼らのために、彼らとともに構築することは、私たちの特権です。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

デバッグの問題を軽減する5つの改善点

昨年Sentryでは、セッションリプレイやクーロンモニタリングのような新しい製品をリリースしました。しかし、新しい製品を作るだけでなく、ソフトウェアの問題をより速くデバッグするために、コアプラットフォームを改善する方法を常に探しています。 Sentryのローンチウィーク中にご覧いただけたと思いますが、私たちは以下の問題に対処する5つのQoL改善をリリースしました。修正ファイルに未解決の問題がないことを確認するには？コードが本番環境で動作しない場合、どうすればよいか？コンテキストの切り替えを減らすには？フロントエンドの問題をサーバーサイドのエラーにすばやく突き止めるには？これが最新情報です。修正ファイルに未解決の問題がないことを確認するには？ GitHubでレビューコメントを発行する GitHub でプルリクエストを開くと、Sentry はあなたが変更しようとしているコードに起因する既存の未処理の問題をコメントするようになりました。つまり、PR の一部として変更されたファイルに未解決のエラーやパフォーマンスの問題がある場合、提案した変更のリスクをよりよく理解したり、少し修正する時間を取ることができるようになるということです。詳しくはドキュメントやGitHubのディスカッションをご覧ください。コードが本番環境で動作しない場合、どうすればよいのか？ CI/CDツールやプラクティスがこれだけ進歩しているにもかかわらず、CD Foundationが調査した企業のうち、デプロイを毎日行っているのはわずか30%に過ぎないというのは唖然とします。開発者がより頻繁に本番環境にプッシュしない最大の理由の1つは、自分たちのソフトウェアが本番環境で実際に動作するかどうかわからないということのようです。 Release Healthの最新アップデートにより、デプロイメントが本番稼動した瞬間に、ソフトウェアが本番稼動しているかどうか、リリースの健全性を文字通りお伝えすることができます。不良リリース検出リリースが健全でない場合は、リリースページとリリースの詳細ページに表示されるため、リリースに関わったすべてのチームメンバーが何が問題だったのかを確認し、調査することができます。リリースの健全性を判断するために、エラーやクラッシュ率などに基づいて、独自のしきい値を設定することもできます。また、CI/CDパイプラインで私たちの新しいAPIをポーリングすることで、リリースの閾値のステータスを取得することができます(Sentry が不正なリリースを検出したときに、すぐに通知と Webhook を起動する機能を公開予定です)。コンテキストの切り替えを減らすには？ Slackとの統合強化私たちがより早く重要なリリースにたどり着こうとしているのは、不良リリースの検出だけではありません。 Slackとの統合により、コードベース内の新しい重要な問題に対してアラートを受け取ることができます。このアラートにはより多くのコンテキストが追加され、バグに関する適切な情報を適切なタイミングで、適切な場所で取得できるようになりました。更新されたSlack通知では、問題の詳細が表示され、Slackクライアント内で一般的なアクションにアクセスできます。以下のこれらでわかります。イベント数とユーザー数推奨される担当者そして、以下で出来るようになります。ノートとルールブックのURLを追加する issueのアーカイブ方法の設定課題セレクタで検索（課題を割り当てるチームメンバーを検索できます） Slackから直接、課題の割り当て、解決、アーカイブを行うことができ、より多くのデータを得ることができます。問題の詳細にリプレイを埋め込む問題の詳細をスクロールすると、ページにリプレイが埋め込まれるようになりました。セッションリプレイ機能は、映像でユーザーセッションの再現を提供します。これによって不具合の再現を支援し、ユーザーが問題を経験する前後に何が起こったかを確認することができます。問題の詳細ページを離れることなく、より迅速にデバッグすることが可能になります。フロントエンドの問題をサーバーサイドのエラーに素早く突き止めるには？問題の詳細におけるトレースナビゲータの改善各問題詳細ページのトレースナビゲータを更新し、トレースで特定のエラーが検出された場所や、このエラーに関連する可能性のある他の問題を簡単に視覚化できるようにしました。これにより、キーボードの上で顔を丸めることなく、「バックエンドのエラーがフロントエンドに問題を引き起こしているのか」という漠然とした質問に明確に答えることができます。トレースの改善やパフォーマンス監視の主なアップデートの詳細については、ローンチウィーク2日目に発表した内容をご覧ください。まとめ私たちは、あなたが本番を壊すことが少なくなるよう、最善を尽くしています。新しいパフォーマンス機能から、AI対応のコードレビューやAutofixの導入、そして上記のプラットフォームのアップデートまで、デバッグの酷さを軽減するために前進し続けています。 Sentryの最新情報を入手するには、Change logをチェックしてください。また、GitHub、Twitter、Discordでもお問い合わせいただけます。 […]

Sentry Category: Sentryでデバッグするヒント / Sentry Debugging Tips