Sentry 機能 / Sentry Features - Ichizoku

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

コードマッピングは、エラーとリポジトリ内のソースコードを結びつけるものです。エラーは、リポジトリのツリー構造とは異なる経路を持つことがあります。エラーまでの正確なパスを決定するためには、コードマッピングが必要不可欠です。このコードマッピングは、エラーまでのパスとリポジトリ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でグループ化され、キャッシュバストやアセット分割のさまざまな方法に対応します。 […]

【APM】実用的、手頃、そして実際の開発者のために作られた新しいアプリケーションパフォーマンス管理ツール

今ある可観測性の製品群 – 特に従来のアプリケーションパフォーマンス管理（APM）製品は、現代的な開発者たちの期待に応えられていません。これらのレガシーなツールは、運用チームとインフラチームがインフラストラクチャとサービスを稼働させ続けるために作られたものです。しかし、実際にコードを書く人々を助け、レイテンシーの問題を見つけて修正する段になると、これらのツールにはしばしば莫大な価格がかかるため、開発者たちは問題を探し回り続ける必要があり、開発の遅延を招きます。問題を見つけたら、ログ、各種指標およびトレースの間を行ったり来たりして、コードのどこに問題があるのかを突き止める必要があります。自社アプリケーションのパフォーマンスを理解するために、APMツールが博士号を備えている必要はありません。 Sentryのアプリケーションモニタリングへの新しいアプローチは、実用的で手頃な価格であることに重点を置いており、実際の開発者向けに構築されています。動作の遅いクエリであれ、タイムアウトして売上下落を招くリスクのある潜在的な支払いエンドポイントであれ、Sentry は複雑さを取り除き、分析を行い、すぐに対処できる最も重要なパフォーマンスの問題を明らかにします。あらゆる規模で手頃な価格を実現従来の APM ツールのほとんどは「すべてを取り込む」アプローチに重点を置いているため、ストレージコストが高騰、環境にノイズが増加し、ほとんどの開発者たちが分析する必要のない膨大な量のテレメトリデータを発生させます。一つのツールに数千万円（またはそれ以上）を投資する場合、面倒な作業はすべてツールが行うべきです。御社が自らデータを詳細に調べて潜在的な問題やその根本原因を見つける必要はありません。私たちは異なるアプローチを取り、市場で最も手頃なAPMソリューションを構築しました。私たちは、ノイズを取り除き、パフォーマンスデータから最大限の価値を引き出すと同時に、その節約分を直接お客様に還元しています。その結果、現在Sentryの大容量ユーザーの月次トランザクションコストは20％以上減少しています。まとめると、大量のデータがある場合、すべてを保存する意味はありません。全てを保存してしまうと、重複やノイズが発生し、コストがかかります。しかし、全てのデータがあることで、アプリケーションパフォーマンスの最も正確な視点を提供できることも私たちは知っています。プラットフォームを手頃な価格に提供するための新しいアプローチにより、御社が送信するデータが増えるほど、アプリケーションパフォーマンスのサンプルにおいて代表性を確保するために必要なデータ保存量が減少し、イベント毎のお支払い金額は少なくなります。裏側では、長期保存や検索に必要なイベントがどれかを最適化しており、御社が利用規模を拡大すればするほど、その節約の効果が表れます。さらに重要な点として、Sentryは異常値についてはデータを捨てることなく捕捉し続け、最新リリース、重要なトランザクション、開発環境など、お客様が設定した優先順位に基づいて最も気になる問題を特定し、さらなる分析やトラブルシューティングに必要なデータにいつでもアクセスできるようにします。この技術がSentryの現在および将来の製品にどのような影響を与えるか、まだ表面しか触れていませんので、詳しく確認したい方はこちらでディスカッション頂けます。これらの新しい価格テーブルを利用するには、サブスクリプション設定ページに移動してプランを更新するか、sales@sentry.ioに連絡してください。パフォーマンス監視をより使いやすくご利用の技術スタックに関係なくパフォーマンスデータに基づいた行動が取れるようにするために、よくあるパフォーマンスの問題を自動検出して通知する唯一のソリューションである Sentry が、より多くのフロントエンド、バックエンド、およびモバイルパフォーマンスの問題を検出できるようになりました。おなじみのエラーワークフローと同じように、ダッシュボードの情報を解読したりスパンツリーを調べたりする必要なく、画面上のフィードで実際に直接アラートを受けて問題を修正することが可能です。おそらく、素材の圧縮が漏れたためかページの読み込み速度が低下、または、持続時間が 1000 ミリ秒を超えるSQLクエリを記述したために、ユーザーがロード中の回転アニメーションを延々と見続ける – このような新しいパフォーマンスの問題、レンダリングをブロックする大きな素材、遅いデータベースクエリ、およびメインスレッドのファイル I/O – これらの問題はイシューフィードに自動的に表示されるようになり、トリアージ、割り当て、そして問題を解決することで、顧客に影響を与えたり、アプリケーションをダウンさせるのを防ぐことが可能となりました。今、私たちはSentryなしでは生きられません。パフォーマンストランザクション内でイベントの詳細を確かめ、HTTPリクエストでデータベースで実際に何が起こったかを確認できます。これまでのようにパフォーマンスの問題に関するアラートを受け取り、そこからさまざまなログをつなぎ合わせて解決を試みるために時間を費やす必要はもうなく、このお陰で開発者の生産性が約 50% 向上し、開発者の時間を節約できます。ブッチ・メイヒュー – Tilled社SREリード Sentryの新しいPerformance Issues機能について、詳しくはこちらのブログ投稿をご覧ください。または既に Sentry Performance をご利用の場合は、ログインして issue.category:performanceでフィルター処理し、パフォーマンスの問題をすべて確認してください。 Performance Issuesでは、折りたたまれたスパンツリーを提供して、問題がコード内のどこにあるかを特定するのに役立ちますが、問題を修正するためにさらに背景情報が必要な場合もあります。SentryのSession Replayを使用すると、ユーザーセッションをビデオのように再現し、ユーザーがパフォーマンスの問題に遭遇するまでに何を経験したかを正確に確認できるため、通常は再現が困難なレイテンシーの問題をトリアージして解決し、数日から数分に短縮できます。例えば、リプレイのパンくずリスト内で、特定のページナビゲーション、ページの読み込み、およびユーザーが経験したLargest Contentful Paint (LCP) を把握できるため、例えば、チェックアウトフローで読み込みが遅い画像があり、その読み込みを待つためにユーザーがどれだけ苦痛だったかをすぐに確認することができます。 Session Replayを使えば、ページの乱れを視覚的に確認でき、どのコンポーネントが影響を受けたかをピンポイントで特定できるので、手作業でのデバッグにかかる時間を短縮することができます。 -Laszlo […]