Sentry 機能 / Sentry Features - Ichizoku

Sentryのプロファイリング：コードレベルでパフォーマンスのボトルネックを特定し排除する

ユーザーからロードが遅いと言われたため、ログやトレース、メトリクスを通して分析をしました。さらに、アプリケーションのパフォーマンスの原因を特定するために、利用可能なデータはすべて分析しました。しかし、それでもボトルネックの原因を突き止めることはできませんでした。もしかしたら、監視が十分じゃなかったのかもしれません。あるいは、本番環境と大きく異なる環境でテストしているだけかもしれません。いずれにせよ、根本的な原因を突き止めるのに、精神的負荷と時間がかかります。このようなパフォーマンスの悩みを解決するために、プロファイリング機能を構築しました。現在、Python、Node.js、iOS、Android、PHPでは、最新の料金プランで利用可能です。プロファイリングは、パフォーマンスの問題を引き起こしているプログラムの行番号までピンポイントで特定するため、Sentryのパフォーマンスを向上させます。プロファイリングは、関数の実行時にその実行時間に関する本番環境のデータを収集します。そして、その結果を集計して、あらゆる環境におけるアプリケーションのパフォーマンスを把握することが可能になります。実行時間を推測したり、パフォーマンステストを書いたりする代わりに、アプリケーション内で非常に多く実行されるコードを確認し、パフォーマンスのボトルネックを素早く特定することができます。さらに、プロファイリングは手作業による計測にかかる時間を短縮するため、導入後すぐにパフォーマンスを計測することができます。プロファイリングによってパフォーマンスチューニング作業がどれくらい楽になり、ボトルネックをどのように修正するのかをご紹介します。また、SDKのサポートに関する最新情報についてもご紹介します。こちらは、動作の遅い関数からアプリケーションフレームやコールツリーまで掘り下げて、問題の原因となっているプログラムの行番号を特定するデモ画面です。プロファイリングを始める準備はできていますか？詳しくは価格ページをご覧ください。トランザクションからプロファイルまで掘り下げる Sentryパフォーマンスでは、トランザクションと期間ごとに、個々のサービスとそのサービスのパフォーマンスを表すトレースを収集することができます。トランザクションを監視して、速度低下の原因となっている期間を特定するのに役立ちますが、多くのタスクで長時間実行される箇所の原因を特定するのは難しい場合があります。長期間を小さく分割して計測するのではなく、プロファイリングを使用することで必要なコンテキストを提供することができます。プロファイリングデータがあると、最も頻繁に発生するコールスタックが表示され、最適化すべきコードを教えてくれます。以下の例では、特定のコールスタックが収集したサンプルの84.3%に、アプリ内関数の最上位がBigTableKVStorage.get_manyで、GCPのビッグテーブルクエリを実行していることがわかります。詳細を見ると、その関数が定義されている正確なファイルと行番号がわかります。さらにデバッグが難しいシナリオとして『一部のデータが抜けているケース』が挙げられます。観測できていない箇所を推測する代わりに、プロファイリングはその時間帯に実行されるコードを教えてくれます。これによって、コードのどこを修正する必要があるかがわかるだけでなく、このプレビューによって、新しく監視する箇所を追加しなくても根本的な原因を見つけることができます。この例では、観測できていなかった474msまでの間が、Redisクラスタへの接続をしていたことがわかります。さらに、フレームチャートビューアでは、すべてのスレッドのデータを含むプロファイル全体を表示します。トランザクションデータはプロファイリングデータとインラインで表示されるため、その時間に関連する機能をシームレスに関連付けることができます。フレームチャートの操作方法と解釈方法についての案内を作成しました。開発者のヴィトール・カリクストはプロファイルを利用して、Azos Segurosの顧客保険金の分割払いサービスのパフォーマンスを向上させています。ヴィトールは、フレームチャートを使用して、パフォーマンスの問題に関連するプロファイルを掘り下げ、リクエストが遅くなっている原因の関数コールを特定し、迅速に対応しました。これにより、リクエストの実行時間が大幅に改善されました。フレームチャートを使って、顧客決済サービス内で最も遅いデータベースリクエストを見つけることができました。プロファイリングを使用することで、リクエストの実行時間を1000msから300msに短縮することができました。– アゾス・セグロス社 Vytor Calixto氏プロファイリングで改善されるパフォーマンス問題プロファイリングは、トランザクションデータをグループ化して、共通のパフォーマンス問題を検出するなど、パフォーマンス機能を補うものです。プロファイリングデータが問題をコードレベルで可視化することによって、検出できることが増えます。プロファイリング・データを活用する最初の新しい課題タイプは、iOSとAndroidでサポートされるJSON Decoding on Main ThreadとImage Decoding on Main Threadの2つです。例えば、画像のデコード処理（ファイルの解凍などのこと）をメインスレッドから別スレッドに移動させることで、メインスレッド時間を150ミリ秒程度短縮できたことがわかります。さらに、UIジャンクの発生やスクロール性能の低下を防ぐこともできます。 […]

Sentryの新しい予算配分とスパイク保護で安心して複数のプロジェクトを管理

本日、新しいSpend Allocation（予算配分）機能とSpike Protection（スパイク保護）のアップデートを発表します。これにより、Sentryユーザーは、プロジェクトがどのようにイベントを消費するかをよりコントロールできるようになります。私たちは、お客様がプロジェクトにSentryを簡単に追加できるように製品を開発してきました。しかし、コミュニティからは、ノイズの多いイベントデータを扱うプロジェクトで、イベント枠を消費しすぎないようにするための方法がもっと欲しいという声を聞き続けていました。そこで私たちは、Spend Allocation（予算配分）を構築し、Spike Protection（スパイク保護）を更新しました。これにより、Sentryを大規模に利用する皆様は、イベント消費のレベルが異なる複数のプロジェクトやチームを簡単に管理できるようになりました。なぜかプランによっては、毎月Sentryに送信できるイベント数に上限が設定されています。その数を超えると、Sentryはあなたのイベントを削除し始めます。この場合、アプリケーションの状態を把握することができなくなります。インバウンドフィルタ、メトリックアラート、レートリミットなど、イベント消費を管理するためのツールを用意していますが、さらにコントロールを容易にしたいと考えました。これにより、プロジェクトでイベントが大量に発生するような予期せぬ事態が発生しても、ペナルティを受けることがないようにできます。 Spend Allocation（予算配分）とSpike Protection（スパイク保護）の向上予算配分は、予約エラー、トランザクション、添付ファイルに対して、プロジェクトごとに最小限のイベントの閾値を設定することができます。この設定はリアルタイムで行うことができ、すべてのプロジェクトに公平な割り当てを行うことができます。また、スパイク保護のアップデートは、その名の通り、イベント量の予期せぬ異常な急増からお客様を保護します。 Spike Protection（スパイク保護） – 何が変わったか予約した容量を使いながら、月内に十分な視認性を確保できるようにしたい。しかし、インシデントは起こります。 Sentryに送信されるイベントが急増することがあります。このような場合、数時間または数分で月間クォータを使用することができます。ユーザーからのフィードバックに基づき、イベントスパイクからお客様を保護するための従来のアプローチには、主に2つの問題があることが判明しました。「調整」が早すぎる。数時間以上続く正しく認識されたスパイクを「非スパイク」と誤判定することがあった。スパイクの閾値が単純に高すぎる場合がある。その結果、スパイクが捕捉されないことがある。これらの要因により、スパイク保護機能の有効性が損なわれていました。そこで、スパイク保護の機能を以下のように改善し、ユーザーの保護を強化することにしました。スパイクはプロジェクトごとに検出されるため、よりきめ細かい制御と可視化が可能です。スパイクがトランザクションと添付ファイルを検出するようになりました。アルゴリズムが更新され、イベントスパイクの検出がより正確になりました。 Stats（統計）ページで、プロジェクトごとのスパイク防止閾値を確認できるようになりました。また、「スパイク保護のアップデートにより、イベント数上限を超えずに管理することができた」というお客様からの声もいただいています。「スパイク保護は、データ移行の失敗から私たちを救ってくれました。一晩中、そして朝のピーク時まで、1つのスパイクが原因で、1日のイベント量が6000%増加しました。Sentryは、数時間以内にすべてのクォータを使い果たすことから私たちを救ってくれました。」-Vectare社テクノロジーディレクター、Alex Nathanail氏フィードバックを共有し、改善の詳細を得るには、GitHubのディスカッションに参加してください。 3つのステップで、アカウントのスパイク保護をオンにします。 Organization（組織）の設定に移動する左のナビバーにある「Spike Protection」をクリックプロジェクトのすべて（または一部）に対してSpike Protectionを有効にするかどうかを選択します。なぜ、プロジェクトでスパイク保護を有効にしなければならないのか、という疑問があるかもしれません。スパイクに関係なく、すべてのデータを確認したいお客様もいらっしゃいます。例えば、開発・テスト段階であれば、すべてのイベントを見ることができれば便利です。 Spend […]

アプリケーションのパフォーマンスを機能的に操作する方法

私は開発者として、そのアプリケーションがどのように動作すべきか、非常に強い関心を抱いています。高速に動いた結果、何かを壊すことには興味がありません。正直、世界を変えることにも興味はありません。快適で人間工学に基づいたソフトウェアを作ることに興味があります。そして、その対価としてお金を貰いたいという思いが強くあります。私の会社「Buttondown」は、そんな思いから生まれました。Buttondownは、メールやニュースレターを送信するためのツールです。市場にはこの手のツールはたくさんあります。しかし、Buttondownの強みは「ミニマリスト」であるということです。開発者にとって快適な体験を提供しています。それはプログラムへのアクセス、アクセシビリティ、そしてパフォーマンスを優先しているためです。しかし、アプリケーションの性能は時間とともに劣化する開発者たちはみんな「高パフォーマンスを意識して開発しなければならない！」と考えています。その意志は常に正しいです。一方で、簡単なことではないことも知っています。新機能の立ち上げ時には、可能な限り慎重にリリースします。 APIルートごとのデータベース呼び出し回数や負荷テストなど、厳しいテストを実施しています。誰かが非常に遅いエンドポイントについてバグレポートを提出した場合（あるいは、タイムアウトに関する例外が発生した場合）、私はできるだけ早く対応します。これは簡単で、テストも可能です。しかし、性能は時間の経過とともに、ゆっくりと、静かに低下していきます。余分なループが一つ、最適化されていないデータベースを一回呼び出す……。それが積み重なっていくように、目に見える小さな問題が積み重なっていくのです。解約した顧客からメールを受け取って初めて、そのことに気づきます。彼らは口を揃えて「UX（ユーザ体験）がよくない」と言います。クラッシュしないので「問題ない」ように思っていましたが、アプリは知らぬ間に悪化していました。パフォーマンスを抽象的なものから実用的なものへと変化させる私は長い間Sentryを、他のユーザーの皆さんと同様エラー処理と問題報告のために使っていました。軽量なインターフェースと迅速なインストールプロセスにより、私は簡単に問題を処理し、優先順位をつけ、解決することができました。私は、電子メールの受信箱と同じように、ソフトウェアの問題をクリーンな状態に保っています。正直、パフォーマンス・モニタリングに注力しているときの私は、半信半疑でした。たくさんのデータやダッシュボードが送られてきて、それを毎朝監視して見なければいけないからです。非常に時間がかかる作業な上、結局人が見て判断しなければならないため、億劫に感じました。しかしその疑念は、Sentryの提供する「パフォーマンスのためのクリアで簡素なアクション層」を理解した途端に消え去りました。 Sentryは、パフォーマンスに関する情報を分かりやすい内容で通知してくれます。これまでは、分かりにくい折れ線グラフではないにしろ、答えを与える代わりに疑問を増やすだけのものが多かったのです。代わりに、Sentryは明確で解決可能な問題を提示してくれました。例えば、SentryはN+1エラー通知をしてくれるので、オンボーディングが重要なルートを高速化することができました。このようなことをPythonの2行で表現しました。そして、Sentryはこの遅いDB操作にアラートしてくれました。 Sentryは、送信メールのレンダリングと送信を倍の速度で行う方法を教えてくれました。 Sentryは、プログラムのどこでどのトランザクションがパフォーマンスの問題を引き起こしているのかを正確に教えてくれました。そのため、問題の根本原因を見つけるために、多くのダッシュボードやレポートの分析に時間を費やす必要はありませんでした。 Sentryを使ったおかげで、無駄な作業が減り、アプリのパフォーマンスに注力することができるようになります。 Sentryでは、コードエラーを処理するのと同じように、パフォーマンスの問題を処理することができるので大変便利でした。開発者にとってパフォーマンスが重要な理由多くの開発者たちは、アプリケーションのパフォーマンスを「あったらいいな」程度の機能として扱っています。開発計画や製品ロードマップを作成しているとき、アプリのパフォーマンスについて十分に考えていない開発者がいるのです。これはよくわかります。お客様の多くは、ページの読み込み時間の遅さやその他のパフォーマンスの問題を受け入れてくれると考えていることが多いからです。一方で、新機能を搭載しなければ、お客様は不満を募らせるだろうと考えています。ですから、パフォーマンスよりも新機能を優先することはよくあることです。しかし、ユーザーや顧客は性能を気にしており、意外とすぐその変化に気がつきます。しかし、実際にどう説明したらいいのかわからないこともあります。 Buttondownを使い始めてから数カ月後のあるお客様と電話をしたことがあります。お客様：よく分からないんだけど、[加入者向け管理画面] が操作しやすくなったんですよね。いずれにせよ、UX（ユーザー体験）を向上させたのは素晴らしいです！とはいえ、UXは1ピクセルも変わっていませんでした。変わったのは、スピードとパフォーマンスです。Sentryのおかげで、5秒のフィードバックループを1秒に短縮することができました。Sentryを使えば、それは本当に簡単なことでした。一部製品、一部プロセス：アプリケーションのパフォーマンスに関する考え方のオススメパフォーマンス問題の優先順位付けと、改善を厳密に行うことに関心のあるエンジニアにお勧めのプロセスがあります。これは、私がAmazonやStripeでエンジニアをしていたときに実際に効果が合った方法です。 […]

プロファイリング入門101：なぜプロファイリングなのか？

プロファイリングについて、3回に分けてご紹介する「プロファイリング入門」。今回は第2回目です！第1回目「プロファイリングとは何か？」はこちらからご覧ください。第1部：プロファイリングとは何か？第2部：なぜプロファイリングを使うのか？（当記事）第3部：プロファイリングツールとその使い方（近日公開予定）アプリ開発の成功には、素晴らしいパフォーマンスが重要であることはご存じかと思います。パフォーマンスを改善するためのツールはたくさんあります。最新のプロファイリングツールを使ってプロファイリングを行うことは、アプリのパフォーマンスを理解するために最も簡単で効果的な方法の一つといえます。プロファイリングツールは、1970年代から開発者が遅いコードを修正するのに役立ってきました。最近のプロファイリングツールは、より洗練され、より使いやすくなっています。そして、サービス終了までのあいだ継続的に稼働させることができます。例えば、遅いコードの経路を示す有用な可視化データを自動的に作成する機能があります。また、他のパフォーマンスツールとの統合や連携も可能です。シリーズの第1回目と同様に、この記事のほとんどの例は、フロントエンドとバックエンドの開発に関するものです。しかし実際には、プロファイリングツールはほとんどのコードに適応し、パフォーマンス向上に役立てることができます。なぜプロダクションでプロファイルするのか？ PythonのcProfileやGoのpprofのように、多くの言語にはプロファイリングツールが組み込まれています。これらのツールはとても便利で、何十年も前から使われています。しかし、使い続けていると次第に使いにくい場面も出てくるのは事実です。そんな時は、追加の可視化ツールを必要とします。これらのツールは、あなたのローカル環境上で動作することだけを想定しています。ローカルプロファイリングは限定的内蔵のプロファイラを使えば、コードの特定の部分について詳細なベンチマークを取得することができます。それにより課題のある箇所を見つけるのに役立ちます。しかし、大規模なシステムでパフォーマンスの問題を発見するためには、最適の策ではありません。ローカルプロファイラを使用すると、多くのオーバーヘッドがコードに追加されます。（一般的には200%以上追加されます）プロファイリングを使うということは、コードの性能を気にしているはずです。それにも関わらず、コードを2倍以上遅くしているのは矛盾します。そして、すべてのプロファイラで、追加されるパフォーマンスオーバーヘッドの量は、関数呼び出しの間で一定ではありません。つまり、プロファイリングで得られるCPU処理時間は、正確ではない結果となります。これでは正確に解析できないため、プロファイリングを実行する意味がありません。一般的に、ローカルでのプロファイリングだけでは、ユーザー体験を明確に把握することはできません。本番環境での速度低下の原因を、ローカル環境で再現するのは非常に困難であるためです。ご存知のように、開発マシンでのパフォーマンスは、コードが本番稼働しているときと常に同じとは限りません。したがって、開発環境のローカルプロファイリングで問題を発見し、実際に修正するのは非常に困難であるということがわかります。プロダクションにおける最新のプロファイリング最終的には、本番環境でパフォーマンスを測定することが、システムのパフォーマンスを正確に把握する唯一の方法となります。幸いなことに、ローカルのプロファイリングツールが作られて以来、プロファイリング技術は大きく進化してきました。最新のサンプリングプロファイラは、現在、本番環境で実行できるほど進化しています。（決定論的プロファイラとサンプリングプロファイラの比較は第1回目で詳しく説明しています）それは、パフォーマンスのオーバーヘッドを抑えて実行できるようになったためです。また、コードのパフォーマンスの詳細な情報を可視化して提供してくれます。それはローカル環境上のプロファイリングと遜色ない、有用で十分な解析結果を出力してくれます。例えば、Sentryのプロファイリングツールは、10%以下のオーバーヘッドを目標として実行しています。さらに、最新のプロファイリングツールは、すべてのユーザーセッションのデータを取得するように設計されています。つまり、コードが本番環境でどのように動作しているかを包括的に把握することができるのです。プロファイリングは<metrics/logging/tracing>と比較してどうなのでしょうか？他のツールを使って、本番環境からパフォーマンスデータを取得している方もいらっしゃると思います。『なぜプロファイリングをセットアップする必要があるのか』という疑問もあるでしょう。パフォーマンスを監視する方法を変更するのは、決して簡単な作業ではありません。しかし幸いなことに、プロファイリングはパフォーマンスを測定するための他の戦略とともに機能します。また、設定もそれほど難しくなく、得られるメリットも大きいです。最も大きなメリットは、プロファイリングデータが関数またはコードレベルの粒度を提供することです。これにより、開発者はパフォーマンスの問題を発見し、修正することが非常に簡単になります。システムメトリクスページロード時間、CPU使用率など、その他の事前設定されたメトリクスは、本番環境で稼働しているアプリのパフォーマンスを把握するために使用されます。また、効果的でオーバーヘッドの少ない方法を提供し続けます。メトリクスは、パフォーマンスの問題があることを知らせるには最適ですが、その原因まで突き止めることはできません。メトリクスは非常に低いオーバーヘッドで動作するので、使わない理由はありません。しかし、最近のツールと比較すると、その有用性は限定的となります。ロギングロギングは、パフォーマンスを含め、さまざまな方法でシステムの健全性を把握するのに便利です。しかし、ロギングからパフォーマンスデータを取得するには、多くの手間がかかります。 […]

PythonとNode.jsのプロファイリングβ版

数ヶ月前、PythonとNode.js SDKのユーザー向けにプロファイリングのアルファ版がリリースされましたが、本日、PythonとNode.js向けのプロファイリングをベータ版に移行しました。プロファイリングはベータ版の間、無料で使用できます。正式リリースが近づいたら、また更新情報をお届けします。プロファイリングは、コードのパフォーマンスボトルネックを発見するのに役立つ重要なツールです。 Sentryのプロファイラでは、実行速度の遅いクエリのコードのファイル/行番号まで正確に把握することができます。特定の関数の実行に時間がかかっている理由を即座に把握し、コード内の関数を最適化することでアプリケーションのパフォーマンスを向上させることができます。最新のリリースでは、プロファイリング製品にいくつかの改良を加えています。 Pythonのアップデート Geventのサポート：SentryプロファイリングがPythonのgeventをサポートするようになりました。geventライブラリ（Gunicorn WSGI HTTPサーバとよくペアになっている）を使用しているすべてのユーザーに影響があり、以前はデータを取得できなかったgeventコルーチン（リクエスト処理コード）内で実行されているコードを確認できるようになりました。 WSGIリクエストだけでなく、すべてのトランザクションのプロファイリングをサポート：以前は、SentryはWSGIリクエストのみをプロファイルすることができました。現在では、すべてのトランザクション（手動で開始したものも含む）がプロファイルされ、この動作はプロファイルをサポートする他のSDKとの一貫性を担保します。これらの機能アップデートはいずれも追加設定を必要とせず、SDKをアップデートすればすぐに動作し、プロファイリングのインサイトを確認することができます。 Node.jsのアップデート Node.js 18および19のサポート：SentryプロファイリングがNode.jsの最新バージョン（v18とv19）に対応しました。 Google Cloud Runに対応：Google Cloud Run環境にデプロイした際に、Node.jsプロファイラがセグメンテーションしてしまうバグを修正しました。これで、Google Cloud Runにデプロイした際に、本番環境で正常にプロファイリングできるようになります。このパッケージは、コンパイル済みのバイナリとともに提供されるため、ソースからのビルドはあまり必要ありません。製品の機能改善 SDKのサポート強化に加え、いくつかの新しいプロファイリング機能のアップデートにより、ユーザー体験（UX）を向上させました。Sentryプロファイリングでは、ユーザーは以下のことができるようになりました。フレイムチャートの関数からGitHubのコードへのリンクソースマッピングが設定されている場合、フレイムチャートの関数フレームを右クリックすると、GitHubのその関数のコードに遷移します。これにより、長時間実行される関数のソースコードに直接移動できるため、パフォーマンス問題の修正プログラムを素早く書くことができ、トラブルシューティングの時間を短縮することができます。これは、ソースコード管理が設定されているNode.jsとPythonのプロジェクトで機能します。トランザクションの処理時間をフレイムチャート上で可視化するトランザクションが関連付けられたすべてのプロファイルは、トランザクションからの期間をフレームチャート上に直接出力します。これにより、トランザクションとプロファイルを行き来することなく、特定の処理で実行されたコードを1つの統一された画面で簡単に把握することができます。期間から対応するプロファイルに移動する Sentryのトレースを有効にしている場合、トランザクションイベントの詳細ページに移動し、ウォーターフォールビューから期間を選択し、「View Profile」ボタンをクリックすると、その期間に発生するプロファイルの部分に移動することができます。これにより、パフォーマンス問題を抽象的な上層〜詳細な下層にまで目的に合った粒度で分析することができます。結論 Sentryのプロファイリング機能を繰り返し強化する中で、初期の多くのお客様から、Sentryパフォーマンスとプロファイリングは、パフォーマンスワークフローにおいて、しばしばうまく組み合わせて利用できるという話を聞きます。 Sentryパフォーマンスは、お客様がサービス全体をトレースし、動作の遅いデータベースクエリや外部呼び出しを特定することを可能にします。例えば、プロファイリングのお客様の一人は次のように述べています。 Sentryパフォーマンスで最も遅いAPIコールを確認することは非常に有用です。私たちはパフォーマンスの最適化を行い、p50とp95の劇的な改善を確認しました。” – Aunty Grace（オーストラリアのヘルスケア企業）の開発者、シェーン・ホルコム氏プロファイリングはトレースを補完するもので、CPU消費を抑えるためにコードのどの部分を最適化する必要があるかについて、ファイルや行レベルで詳細に知らせてくれます。パフォーマンスとプロファイリングを併用することで、プロファイルとトランザクションを関連付け、遅いリクエストの根本的原因を特定し、迅速に修正することができます。数回のクリックでプロファイリングを始められます。まず、パフォーマンスの計測が完了していることを確認してください（わずか5行のコードで完了します）。 P.S. プロファイラを聞いたことがない、プロファイリングとロギングやトレースとの比較を知りたい、あるいは単に興味があるという方は、プロファイリングとは何か、なぜ運用中のアプリケーションをプロファイリングする必要があるのかを説明するブログシリーズ「Profiling 101」をご覧ください。 Pythonのプロファイリングの例やNodeのプロファイリングの例については、こちらをご覧ください。また、GitHub、Discord、またはメール（profiling@sentry.io）にて、ご意見・ご感想をお待ちしています。 Sentryは、アプリケーションコードの健全性を監視するために不可欠です。エラートラッキングからパフォーマンスモニタリングまで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの観測機能を提供しています。毎月、世界中で人気のサービスやアプリケーションから、数十億件の例外を処理し続けています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

コードマッピングとその重要性とは？

コードマッピングは、エラーとリポジトリ内のソースコードを結びつけるものです。エラーは、リポジトリのツリー構造とは異なる経路を持つことがあります。エラーまでの正確なパスを決定するためには、コードマッピングが必要不可欠です。このコードマッピングは、エラーまでのパスとリポジトリURLとの組み合わせによって成立します。 Sentryは、コードマッピングを使用して、課題の詳細ページでコンテキストと役立つデータを発行します。例えば、以下のようなものです。スタックトレース連動 Issue Detailsページから直接リポジトリ内のソースコードに移動することができます課題所有権とコード所有者パスルールを定義するか、リポジトリにあるコードの所有者ファイルを使用することで、課題（Issue）をチームに割り当てることができます。疑わしいコミットエラーが発生した際、どのプログラムのどの行で起きたのか、また誰が触ったかを分析することができます。変更を加えた人を担当者としてアサインし、問題を解決することができます。これらの機能によって、実装中に起きたエラーなどの解決にかかる時間を短縮することができます。また、エラー原因のコードの所有者（修正者）を迅速に特定することができます。これまでは、コードマッピングを設定するためのプロセスが複雑であることが課題視されてきました。そして、使いこなすことが難しいという課題を多くの開発者は以前から抱えてきました。そんな課題を解消するため、私たちは、そのプロセスを簡略化しました。また、コードマッピングを自動化する機能も新たに追加しました。コードマッピングの自動化に成功したプロセスについては、これからご説明します。また、どのように役立つのか、そして今後のリリース計画についてもぜひご覧ください。現在、自動コードマッピングは、GitHubインテグレーションをインストールしているお客様（Teamプラン以上）にのみ提供されています。また、限られた言語でのみ利用可能です。技術的な課題スタックトレースに対してコードマッピングを自動生成する機能を、私たちは数日で開発しました。しかし、『大規模プロジェクトで実行させる』という機能が最も大きな課題として私たちを悩ませました。 Sentryは、数万を超える組織やプロジェクトにご利用いただいています。そして、彼らが書いた多くのコードが格納される数多くのリポジトリを保有しています。私たちは、1時間に何十万通りにも及ぶさまざまなイシュー（フィードバックやバグ）を受け取ります。受け取ったイシューごとに処理を実行しなければなりませんが、この実行にかかるコストは高くつきます。ですので、より経済的でスケーラブル（拡張性がある）設計が必要になりました。 GitHubが設定した利用制限を守らなければならないため、GitHubのAPIをどのように使うかについて検討を積み重ねました。コードマッピングの導出は、GitHubのAPIを使用する唯一の機能ではありません。そのため、キャッシュを効率的かつ適切に使う必要がありました。これは、他のSentryの機能（GitHubからコミットを取得するなど）の動作に影響を与えるため、とても重要な検討事項です。 GitHubのAPIを利用したコードマッピングの導出スタックトレースに記載されているファイルを検索するためには、以下の2つの情報が必要です。ソースコードが存在するリポジトリファイルパスと一致させるために必要な変換工程例えば、このスタックトレースフレーム sentry/shared_integrations/client/base.pyは、Github の以下のソースファイルに接続しているとします。src/sentry/shared_integrations/client/base.py ソースコードがどこにあるのかを判断するためには、顧客の組織内のすべてのファイルとすべてのリポジトリのリストが必要です。リポジトリごとにファイルのツリーを作成するには、GitHub のふたつの API を使います。それは『組織リポジトリの一覧取得』APIと『ツリーの取得』API です。 1つ目の『組織リポジトリの一覧取得』APIは、その組織に関連するすべてのリポジトリをフェッチします。次にこれを使用して、各リポジトリのツリーをフェッチします。 2つ目の『ツリーの取得』API は、与えられたリポジトリのすべてのディレクトリとファイルを表すリポジトリツリーを返します。このAPIは 1回の呼び出しで、あるリポジトリのすべてのファイルにアクセスできるため、非常に便利です。レスポンスからツリー情報を抜き出し、ソースコードファイルでないものはすべて破棄します。エラーを発生させる可能性のあるファイルのみに絞り込むためです。すべてのリポジトリのツリーを入手したら、スタックトレースがあるプロジェクトの課題を選んで処理します。すべてのリポジトリの中で一致するファイルを見つけるために、すべてのフレームファイルのパスを探します。その際、リポジトリ内の任意の深さで正確なパスを検索します（例えば、src/foo/bar.py と project/src/foo/bar.py は sentry/foo/bar.py にマッチする、など）。ここで、Githubの検索APIを使うこともできたのですが『1時間に25リクエストまで』というAPI利用制限がありました。 […]

SentryファミリーにCodecovが参画：コードカバレッジとアプリケーション監視の融合

本日、CodecovはSentryファミリーに加わりました。Codecovは、2014年にコードカバレッジレポートツールとして始まり、それ以来Codecovはテスト分析分野のマーケットリーダーとして成長してきました。Codecovは、20以上のテストフレームワークでカバレッジを実用的なものにします。これまで100万人以上のソフトウェア開発者たちのテスト、カバレッジ、コードの信頼性に対するアプローチを改善するのに役立っています。テスト分析がアプリケーションの監視とどう関係するのでしょうか。それを理解するためには、まず、コードが適切にテストされないとどうなるかに着目する必要があります。コードを正しくテストせず（あるいは全くテストせず）、モニタリングに失敗したときに何が起こるのかに注目しなければなりません。ソフトウェアの停止が起こり、アプリケーションのパフォーマンスの問題が発生します。そしてそれは、顧客にとって劣悪な体験を生み出すことになるのです。ソフトウェアの停止は、問題の分析から始まります。実際に何が問題を引き起こしているのでしょうか？パフォーマンスの問題やその他のシグナルをつなぎ合わせて、根本原因を診断します。これがSentryの存在理由です。Sentryは、開発者の生産性を向上させるために存在します。私たちは、問題をできるだけ早く特定することに注力します。そして、開発者たちがその問題を素早く解決するための正しい情報とツールを手に入れることができるようにします。多くの開発者はこれをMTTR（平均復旧時間）と呼んでいます。Sentryは、問題が発生したときに開発者がそれを認識するのを助け、根本原因を示し、開発者らが臨めば問題をすぐに解決できるようにします。ソフトウェアチームがインシデント管理ではなく、本来の研究開発に割く時間を最大化できるよう、私たちは支援します。ソフトウェア開発ライフサイクルにおけるリリース前の段階において、ソフトウェアテストは高品質のコードを確実に開発するために最も重要です。Codecovは、より健全で高品質なコードを出荷することが、リスクの低減、より良いユーザー体験、そして開発者の生産性の向上につながると考えています。開発者の生産性を向上させるためのCodecovのアプローチは、コードが出荷される前のコードカバレッジと自動テストに重点を置いています。Sentryと同様、Codecovは常に開発者がコードの問題を認識するのを助け、望めばそれを解決できるように選択肢を与えることに重点を置いてきました。Codecovがソフトウェア開発ライフサイクルのプリリリース側に焦点を当てているとしても、SentryとCodecovの使命は同じです。両社とも、世界最高の開発者ツールを作り、開発者ファーストの考え方にこだわり続けたいと考えています。 SentryがCodecovと話を始めたとき、何万もの組織と協力してきたその道程について聞きました。つまり、それまでのコードカバレッジの概念は多くの開発者が使う便利な指標でありながらその指標の本来の意味については、ほとんど合意が得られていませんでした。 100％のカバレッジが目標なのでしょうか？完全にカバーされたコードベースが、なぜまだ壊れることがあるのでしょうか？100%がゴールでない場合、どの程度のテストが必要でしょうか？「ハッカーニュースコードカバレッジ」で検索して議論を読んでみてください。これらの議論は、答えが必要な質問が何かを明らかにしています。開発者はどのようにコードをテストするでしょうか？そのテストはどの程度弾力性がありますか？なぜコードベースの特定の部分をテストするのでしょうか？顧客やユーザーに対するリスクは？コードのコミットごとにすべてのテストを実行する必要があるのでしょうか？これらの質問は、Codecovが豊富な機能と今後のロードマップを確立するためのインスピレーションとなり、そして今後はSentryに統合されます。 Sentryのミッションは常に、ダッシュボードやツールの提供だけでなく、背景情報や洞察を通じて、開発者が高品質のコードを出荷できるようにすることです。Codecovチームは、この私たちのただ一つの焦点を共有しています。Codecovは、開発サイクルの早い段階で、アプリケーションのコード品質について、より包括的な洞察を開発者に提供します。 Codecovは、Sentryと同様に、開発者の既存のソフトウェア開発のワークフロー内で動作します。Codecovは、プラットフォーム、言語、CI/CDツールに関係なく、コードの品質に関するフィードバック、洞察、およびオーナーシップを提供します。今回の買収により、Sentryの顧客は、デプロイ前とデプロイ後の両方で、コード品質に関する洞察と保護から利益を得ることができます。 Sentryは、アプリケーションコードの健全性を監視するために不可欠なツールです。エラー追跡からパフォーマンス監視まで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。 Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの観察機能を提供しています。毎月、インターネット上で最も人気のある製品から数十億の例外処理を実行しています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

プロファイリング入門101：プロファイリングとは何か？

アプリケーションの性能は重要です。パフォーマンスの高いアプリケーションは、優れたユーザーエクスペリエンスを保証し、大切な顧客を維持します。開発者は、パフォーマンス目標を達成するための適切なツールを使う必要があります。顧客から不満が出る前に、適切なツールを用意していなければならないのです。良好なパフォーマンスを確保するための開発者のツールボックスの中で最も優れたツールの一つがプロファイリングです。本番のコードがどこで遅くなるかを正確に予測するのは非常に困難です。プロファイリングツールを使えば、コードの中で遅くなっている行を正確に示すことができます。また、特定の最適化を行い、テストすることも可能です。この三回シリーズでは、プロファイリングとは何か、なぜ本番環境でコードをプロファイリングする必要があるのか、プロファイリングのための人気のツールを紹介します。第1部プロファイリングとは？プロファイリングとは何か？（この記事です！）第2部：なぜプロファイリングなのか？第3部：プロファイリングツールとその使い方（近日公開予定）プロファイリングとは何か？プロファイリングツールは何十年も前からありますす。新しいものではありません。プロファイリングとは、プログラムのリソース使用状況のスナップショットを取得する方法です。これをプロファイルと呼びます。そして、そのスナップショットをコードベースに結びつけます。これで、コードの各行ごとのリソースの使用状況を把握することができます。プロファイリングは動的解析の一種です。コードを実行しながら測定します。プロファイリングによって、ローカルでも本番でも、コードがどのように実行されているかを正確に把握することができます。コードがデータベースや他のサービスとどのように相互作用しているかを確認することができます。プロファイリングは分散トレーシングとどう違うのか？まず、プロファイリングとトレーシングの違いについて説明します。トレーシングは、パフォーマンスを監視するために一般的に使用されるまた別のツールです。トレーシングは、リクエストの流れやタイミングを、システムを通過する際に追跡します。これは、そのシステムのパフォーマンスを理解し、ボトルネックを特定するのに役立ちます。トレースは、プログラムの実行中に発生したイベントのログです。分散型トレーシングでは、バックエンドとフロントエンドを横断して追跡するなど、分散型システムでトレースを作成します。フロントエンドからバックエンドへのリクエストをトレーシングすることで、どのサービスが関与し、どれくらいの時間がかかっているかを把握することができます。多くの場合、外部サービスやデータベースがアプリケーションの遅延を引き起こす最大の原因となっています。トレーシングは、これらの遅延を特定し測定するのに適しています。しかし、外部からの呼び出しではなく、内部的な問題でアプリケーションが遅くなっている場合、トレーシングは問題がどこにあるのかを正確には示せないことがあります。トレースから得られる情報は、コードに手動で実装したスパンと同程度の粒度しかないのです。一方、CPUプロファイラでは、関数や行レベルの詳細な情報を得ることができます。すべての関数を計測しなくても、コードのどこが遅いかを知ることができるのです。プロファイラの種類プロファイリングは非常に幅広い意味で用いられる言葉です。プロファイラは様々な方法で実装することができます。例えば、プロファイラが収集するデータには、CPU、GPU、メモリ、I/O、ネットワーキングなどの使用状況が含まれます。最近のプロファイリングツールのほとんどはCPUプロファイラで、CPU上で実行されるコードの性能を測定します。この連載では、CPUプロファイラに焦点を当てます。注意する点として、この記事で使用する例のほとんどは、フロントエンドとバックエンドの開発に関するものです。しかしながら、プロファイリングはあらゆるタイプのコードのパフォーマンスを理解するのに役立てられます。継続的プロファイリング、アドホックプロファイリング、およびトランザクションベースのプロファイリングプロファイリングには、継続的に行う方法（常に行う方法）、アドホックに行う方法（Chrome DevToolsなどのツールを使ってサイトのプロファイルを手動で収集する方法）、またはその中間があります。アドホックプロファイリングアドホックプロファイリングは、ウェブアプリケーションのプロファイルを取得する最も簡単な方法です。でも、ほとんどのアドホックプロファイリングツールは、機能が制限されています。非常に人気のあるアドホックプロファイリングツールの一つは、Chrome DevToolsのパフォーマンスパネルです。これは、ボタンを押すことで、あらゆるウェブサイトの基本的なCPUプロファイルを記録することができます。アドホックプロファイリングツールは、ウェブサイトのパフォーマンスを素早く把握するのに便利ですが、プロファイルに収集されるデータは完全ではありません。 Chrome DevToolsのプロファイルは、主にウェブサイトのフロントエンドのパフォーマンスを素早く把握するのに便利です。しかし、バックエンドのデータを正確に把握することはできません。さらに、プロファイルはあなたのマシンに固有のものであり、他のユーザーたちが体験している挙動を正確に反映しているとは限りません。最後に、これらのプロファイルの収集を自動化する簡単な方法もありません。パフォーマンスデータを見るには、毎回手動でプロファイルを作成する必要があります。各プロファイルがユーザーエクスペリエンスを正確に表しているかどうかは定かではないのです。継続的プロファイリング継続的プロファイリングは、包括的なプロファイルデータの定石です。継続的プロファイリングは、長時間実行されるプロファイルです。このプロファイルは、アプリケーションの実行時間全体、またはユーザーセッション全体にわたって自動的に収集されます。アドホックプロファイリングとは対照的に、連続的プロファイリングは、すべてのユーザーセッションで自動的に実行されます。これにより、いつでも実際のユーザーエクスペリエンスを明確に把握することができます。これを実現するために、ウォールタイム（通話が完了するまでにかかる現実世界の時間）のような計算されたメトリクスを使用することができます。継続的プロファイリングには、デメリットもあります。継続的プロファイリングは時間を長く擁することもあり、そのため必要な情報を見つけるのが難しくなることがあります。大量のデータ処理を要する場合もあります。トランザクションベースのプロファイリングトランザクションベースのプロファイリングは、アプリ内でトランザクションが発生している間にプロファイルを自動的に収集するプロファイリング手法です。トランザクションはトレーシングから生じた概念です。トランザクションとは、アプリケーション内部で呼び出されるサービスの単一インスタンスのことです。例えば、ページロード、ナビゲーション、非同期タスクなどです。これらのトランザクションの集合が1つのトレースを構成します。トランザクションベースのプロファイリングでは、自動プロファイリングの利点を享受でき、複数のユーザーのマシンで実際に起きていることを把握することが可能となります。しかし、継続的プロファイリングほど多くのデータを収集することはできません。トランザクションベースのプロファイリングでは、プロファイルが自動的に収集されるのは、トランザクションが発生している間だけです。これにより、トランザクションと一対一でプロファイルを収集することが可能になります（例えば、トランザクションをキャプチャする毎にプロファイルもキャプチャされます）。また、トランザクションに対してプロファイルの収集をアンダーサンプリングすることも可能です。つまり、各プロファイルはトランザクションに関連付けられますが、すべてのトランザクションがプロファイルを持つわけではありません。プロファイルの収集はトランザクションよりも多くのリソースを使用するため、アンダーサンプリングによってプロファイリングツールが引き起こすアプリケーションのパフォーマンス悪化を防止できます。さらに、プロファイルをトランザクションにリンクさせることで、トランザクションとプロファイルからパフォーマンスデータを探索し理解するためのわかりやすいメンタルモデルを得られます。アドホックプロファイリング、継続的プロファイリング、トランザクションベースプロファイリングの違いをまとめた表がこちらです。アドホックプロファイリング継続的プロファイリングトランザクションベースのプロファイリングプロファイルの作られ方手動自動 […]

コードとUXの間のギャップを埋める、SentryのSession Replayとは？

あの厄介なバグがありますよね？ローカルでは再現できないアレです。何度環境を再現しようとしても、再現できません。パンくずリストを調べ、スタックトレースを読み、サポートチケットをつなぎ合わせて、バグが本物であることを確認しなければなりません。しかし、もう原因をより迅速に突き止めるためにキーボードを走らせ頭を悩ませる必要はありません。SentryはSession Replayをリリースしました。この機能は現在すべてのウェブベースのプラットフォームでご利用いただけます。 Session Replayは、ウェブアプリケーション上のユーザーセッションを動画のように再現します。エラーやパフォーマンスの問題に至るまでユーザーが経験したことを正確に確認でき、再現が困難な問題をより迅速にトリアージして解決するのに役立ちます。 Session Replayを始める準備はできましたか? リプレイの基本割り当てはすべての Sentryプランに含まれておりすぐにご利用可能です。追加のリプレイは10,000リプレイにつき月額29ドルからご購入いただけます。詳細については、料金ページをご覧ください。パンくずリストとスタックトレースの先へ Sentryのエラー追跡では、例外データを記録し、パンくずリスト、スタックトレース、コードの改行など、開発者たちが問題をトラブルシューティングできるように背景情報を表示しますが、それでも理解や再現が困難なタイプの問題もあります。 Session Replayでユーザーが辿った行程を視覚化できるため、コードと実際のユーザーエクスペリエンスの間のギャップを埋めて、問題がUIでどのように現れるかを理解できます。また、DOM イベント、ネットワークデータ、コンソールログ、パンくずリストなどの追加のデバッグ用背景情報を Replay機能に追加したため、最も苛立たしいバグやパフォーマンスの問題のトラブルシューティングに必要なものがすべて揃っています。意味のあるデータを記録世の中にあるほとんどのセッションリプレイ製品は、製品を使うユーザーセッションの何%かをランダムを記録します。これは、ユーザー分析や製品ファネルの理解が目的の場合は理にかなっていますが、主にソフトウェアの問題のデバッグを行う場合にはあまり意味がありません。この方法では、再現したい複雑な問題に対応するリプレイに到達するまでに、1,000回のランダムなセッションを記録する必要が生じる場合があります。これは時間と費用の両方がかかります。 SentryのSession Replayは仕組みが異なります。一般的な方法でサンプリングをするオプションも提供していますが、ユーザーがエラーに遭遇したときのセッションを優先的にサンプリングするオプションも提供しています。これにより、トリッキーなバグが発生した場合に、そのバグに対応するリプレイが手配でき、この方法では、再現したい複雑な問題に対応するリプレイに到達するまでに、1,000回のランダムなセッションを記録する必要が生じる場合があります。問題に便利に紐付けられています。必要なデータの取得に必要なつ時間が減り、イベントクォータを監視する不安が軽減されます。サンプリングとカスタマイズの詳細については、ドキュメントをご覧ください。 SentryのSession Replayを使用すると、エラーに対応するリプレイに集中でき、問題を迅速に確認し、リプレイを閲覧して15分で解決できます。以前は、同じ問題を解決するのに一日はかかっていたかも知れません。- Resistbot社ソフトウェアエンジニアプライバシーを第一に考えたアプローチセッションリプレイ系の製品には難しい問題があります。記録された HTML内のユーザーの秘密情報を誤って明らかにすることなく、貴重なデバッグコンテキストを提供するというバランスを取らなければなりません。情報を隠しすぎると、ユーザーがそのトリッキーなバグを引き起こした正確な方法を解読するのが難しくなります。情報を隠さなすぎると、機密データがユーザーのブラウザから流出する危険があります。 SentryのSession Replayは、コンテンツをデフォルトで安全でないものとして扱うことで、ユーザのプライバシーに有利になるような調整を行っています。すぐに使用できるすべてのHTML テキスト、画像コンテンツ、およびユーザーによる入力内容がユーザーのブラウザからサーバへ送信される前にマスクし、代わりに、リプレイに必要な既知の安全な HTMLコンテンツ (静的ナビゲーションやヘッダーリンクなど) をオプトインするように開発者に依頼します）。この方法ではより多くのコンテンツがマスクされることにより、記録内容の忠実度がわずかに低下します。しかし、ほぼ確実に、既知の安全なコンテンツのみがユーザーのブラウザから送信されます。追加の防御策としてSession Replayは、個人情報スクラビングやIPリダクションなど、Sentryの他の製品と同じプロジェクトレベルのプライバシー設定を適用します。これにより、データが保存される前にエッジ取り込みサービスで機密コンテンツが削除されます。デフォルトで強力なプライバシー保護を導入することで、ユーザーの信頼を維持しながらデバッグエクスペリエンスを向上させることができます。ヘルスケア企業として、個人情報や個人健康情報/PHIを適切に扱うことは、私たちや従業員にとって非常に重要です。Sentryは、この機密データがSession Replayで簡単に秘匿できるように調整してくれました。- Peppy、スタッフエンジニアデイブ・クリッドランド氏問題の再現と解決をより迅速に。Replayがいかにエラーのトラブルシューティングに役立つか実際に、Session Replayが開発者たちをどう支援するかを詳しく見るために、トラブルシューティングが困難なエラークラスの一つであるハイドレーションエラーを見てみましょう。このクラスの問題は、Next.jsなどのハイブリッドレンダリングフレームワークに共通に見られ、サーバーが生成した HTMLがクライアント側のJavaScript が期待するものと一致しない場合に発生します。これにより、UIでコンテンツの不一致が発生し、本来不要なコンテンツの再フェッチと再レンダリングを引き起こします。 lablab.ai のLaszloがNext.jsプロジェクトでハイドレーションエラーに遭遇したとき、サーバーが生成したHTMLとクライアントのHTMLとが一致しない要素がページに何百もあったため、最初はデバッグが困難でした。またこの問題がユーザーにどう影響するかを理解するのは困難でした。そこでSession Replay の出番です。Laszloは、Replayを一回見ただけで、コンソールログとリプレイのパンくずリストにハイドレーションエラーが表示され、ユーザーに対し誤って重複した画像が表示されていることに気付きました。 Session […]

Sentryでパフォーマンス監視をより実用的にする方法とは？

コードがどのように機能するかは、主観的な議題ではありません。少なくとも、これからは違います。過去数か月で、Sentryは何が遅いのか、どこを修正すればいいのかを正確に教えてくれるようになりました。具体的には、コード内のN+1データベースクエリです。 N+1の問題解決は皆経験がありますが、パフォーマンスの問題には様々な種類があります。今や、課題フィード、Slackのアラート、電子メール通知で、より多くのPerformance Issuesに気づくでしょう。ダッシュボードや指標に目を通す時間を節約するために、Sentry はエラーと例外のワークフローをパフォーマンス監視にもたらします。Sentryは、コード内で一般的なパフォーマンス問題を自動的に検出してグループ化し、アプリケーションの速度低下やレイテンシー問題の原因となる具体的な問題点に対処できるようにします。フロントエンド、バックエンド、モバイルのパフォーマンスに関する新たな問題の通知を受け取り、対策を講じることができるようになりました。フロントエンド N+1 APIコール非圧縮アセット大きなレンダリングブロックアセットバックエンド連続データベースクエリ N+1 データベースクエリ遅いデータベースクエリモバイルメインスレッドでのファイル入出力 Performance Issuesを始める。issue.category:performanceでフィルターをかけるだけで、すべてのパフォーマンスの問題が表示されます。また、パフォーマンス問題の各タイプの詳細については、こちらをご覧ください。フロントエンドのパフォーマンスに関する問題フロントエンドデベロッパーとして、ウェブの健全性に目を配り、顧客からのフィードバックに耳を傾けることは、ユーザーにとって高品質な体験を維持するために不可欠です。パフォーマンスの問題を放置しておくと、ページの読み込みが遅くなったり、スクロールが乱れたり、その他のUXの問題を引き起こし、ユーザーが失望してウェブサイトからの離脱に繋がります。他のAPMツールでは、通常開発者達は、問題があまりにも深刻でサイトがダウンする場合を別とすれば、ダッシュボードを閲覧してログ、トレース、および指標の間を行き来しながらこれらの問題を手動で探し当てる必要があります。 Tilled のようなSentryの顧客にとって、Sentryのパフォーマンス監視サービスが提供する実用的な背景情報は、開発者チームの時間を節約するための鍵となっています。Sentry Performanceをセットアップしてトランザクションの送信を開始するや否や、TillのSRE リードであるブッチ・メイヒューにとって、パフォーマンスの問題が自動的に認識され、遅いページの読み込みや、遅いAPIエンドポイント応答の原因を特定するのに必要な、さまざまなデータソースを掘り下げる労力が軽減されました。 Sentryを専任とするエンジニアは週に1人です。パフォーマンスの問題に直面する中でも私たちのユーザーが慣れ親しんでいる高レベルのアプリケーションパフォーマンスを維持するには、背景情報がなければ、より多くのエンジニアリングリソースを割く必要があったでしょう。— ブッチ・メイヒュー（Tilled） Sentryは、すべてのフロントエンドWeb SDKについて、以下のフロントエンドのパフォーマンス問題を自動検出するようになったので、それらをあなたが手動で探す必要はありません。 N+1 APIコールバッチ処理される可能性のある、よく似た繰り返しAPIコールを検出します。 N+1 APIコールは、UIコードが同じ種類のリソースに対して多くの同時リクエストを行う場合によく起こります。例えば、アイテム内のすべてのリストが自身をレンダリングするためにAPIコールを行う場合などです。クライアントとサーバーの両方にとって余分なリクエスト各々が負荷となるため、これらのリクエストをバッチ処理して一括APIコールを行うことは、アプリのパフォーマンスを向上させるために重要です。N+1APIコール問題はよく起こります。特に、コンポーネントが隔離された状況で作業が行われ、インテグレーションテストが行われていない場合、リストでレンダリングされていることに気づかずに、データ読み込みロジックをコンポーネントに追加してしまいがちです。非圧縮アセット CSSやJavascript ファイルなどのフロントエンドテキストアセットの圧縮漏れに繋がるサーバーまたはインフラストラクチャ構成の問題を検出します。ブラウザページをロードするためにダウンロードする必要がある大きなファイル (500キロバイト以上) の転送にかなりの時間がかかる場合 (500ミリ秒以上)、または転送中に圧縮されない場合、それは素材ファイルを提供しているサーバーまたはCDN（コンテンツデリバリーネットワーク）の設定ミスを示していることがあります。圧縮されていない素材を最適化することで、特に接続速度の遅いユーザー（モバイルなど）に対して、ページの読み込み速度を向上させることができます。大型レンダリングブロックアセットダウンロードに時間がかかり、最初のページレンダリングを阻む大きなリソーススパン、および巨大なネットワークペイロードを検出します。大きなレンダリングブロックアセットは、ウェブページのレンダリングを続行する前に完全にダウンロードして処理する必要があるJavaScriptファイルまたはCSSです。サイズが大きいため、ページのレンダリングとパフォーマンスがブロックされます。これにより、コンテンツがすべて適切に読み込まれる前に、ユーザーに対して空白または不完全な画面が表示されます。Javascript に新しい依存関係を追加したり、webpackの設定を変更したりすると、誤ってレンダリングブロックアセットが大きくなる可能性があります。 Sentryは、リクエストのFirst Contentful Paint（FCP）とFirst Input Delay（FID）によって測定される、ページのレンダリングとインタラクティブ性に影響を与える長いリソーススパンを警告するようになりました。これらのサイトの健全性は、ページロードがうまくいっているかどうかを示し、ウェブページのユーザー保持率を追跡するのに役立ちます。大規模なレンダリングブロックのアセット問題は、アセットURLでグループ化され、キャッシュバストやアセット分割のさまざまな方法に対応します。 […]

Sentry Category: Sentry 機能 / Sentry Features