コードと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でグループ化され、キャッシュバストやアセット分割のさまざまな方法に対応します。 […]
【モバイル開発】未来は宣言型にある
モバイル開発のエコシステムは常に非常に多様であると言えます。（デスクトップ）ウェブ開発のエコシステムよりも多様だと言えるでしょう。日々、ウェブ開発者向けのフレームワークやツールは増えているようですが、その多くはJavaScriptの上に構築されています。 その多くは、互いに似たようなパターンを実装しています。一方、モバイルのエコシステムには、コアとなる複数の言語セットがあり、そのためモバイル向けのツールやフレームワークの違いを識別するのは非常に簡単です。 モバイルのネイティブプラットフォームの代表格といえば、ネイティブのAndroidとiOSの2つがあります。 どちらも最近興味深いイノベーションがありました。近年Jetpack ComposeとSwiftUIの導入がありました。 ネイティブアプリの開発は、React NativeやFlutterアプリの開発と非常によく似ています。React NativeもFlutterも、最初から宣言型アプローチをとっています。 AndroidとiOSも現在、宣言型のアプローチを採用しています。 モバイル開発の未来は、宣言型であると言えるでしょう。 ちょっとした歴史 React NativeやFlutterは常に宣言型のアプローチをとってきましたが、AndroidとiOSは当初はそうではありませんでした AndroidはViewを活用していました（今もそうですが）。ViewはXMLファイルです。 Button、TextView、LinearLayoutなどのウィジェットを使ってユーザーインターフェイスを定義します。開発者はこれらのウィジェットにIDを割り当てます。これらのIDは、Javaファイルの中でウィジェットを参照するために使用されます。 ファイルでは、機能と動作を開発します。以下は、Viewファイルの例です： このようにウィジェットのリファレンスを作成することになります。 iOSには、Auto Layout、UIAppearance、Objective-Cの@property宣言、KVCコレクション演算子、Combineといった宣言型の機能がありました。 しかし、それでもある程度の命令型のコードを書く必要がありました。 例えば、iOSにはStoryboardsがありました（今もあります）。Storyboardsは、私たちがUIを構築するために使うグラフィカルなツールですが、実際にはXMLファイルです。しかし、開発者はXMLのコード自体にはほとんど触れません。ここでは、StoryboardsでUI要素を追加し、参照とアクションを作成する方法を紹介します。 宣言型に移行する 記憶を呼び覚ますと、命令型アプローチとは、目的のUIを実現するまでのステップバイステップの指示を出すことです。宣言的アプローチとは、最終的なUIがどのような状態になるかを記述することです。 Androidの新しいJetpack ComposeはKotlinで書かれています。 これはマークアップ言語であるXMLとは対照的なプログラミング言語です。 先ほどのXML Viewの例は、Jetpack Composeではこのようになります。 ご覧のように、このアプローチでUIを構築すると、必要なコードはかなり少なくなります。プログラミング言語を使えば、ウィジェットへの参照を作成し、そのウィジェットにロジックを取り付ける代わりに、変数とコールバックを直接使用することができます。値に変化があれば再構成（リレンダリング）が行われるため、UIは常に最新の状態に保たれます。 iOSのSwiftUIはほとんど同じで、Jetpack Composeの代わりにSwiftで構築されています。先ほどのStoryboardの例は、SwiftUIではこのようになります。 ここでもコード量がぐっと減ります。ここはプログラミング言語なので、Buttonのラベルを直接定義することができます。 参照を作成することなく、onClickコールバックを提供することができます。 命令型UIKitで作業しているときに、問題が見つかりました。ViewをView階層に追加する前に、Viewの制約を有効にする必要があります。 subview.leadingAnchor.constraint(…)の行とview.addSubview(view)の行を入れ替えるとエラーにならずに動作します。最初にこのエラーに遭遇したとき、何が起こっているのか理解するのに時間がかかりました。 理解しやすくなるまで、さらに何度かこのエラーを発生させてみました。しかし、新しい宣言的アプローチでは、この問題に遭遇することはないでしょう。 AndroidとiOSにおけるこの宣言型へのシフトは、より良い開発者体験とより速い開発への大きな一歩となります。プログラミング言語を使ってUIを宣言型で定義することで、AndroidやiOSの開発者が抱える多くの苦悩を解決することができます。 ここでは、宣言型アプローチの利点を紹介します。 テーマ設定が簡単になり、より動的になります。 ステートマネジメントは自然に感じられ、新しい宣言的アプローチにおいて重要な役割を果たします。 コンポジションアプローチでは、要素をネストすることでUIを構成することができます ダイナミックレイアウトや条件付きレンダリングが簡単にできるようになりました。 なぜでしょうか？それは制御構造や分岐ロジックを持つプログラミング言語を使ってUIを構築しているからです XMLを介するよりもSwift/Kotlinのコードを介した方がgrepがしやすくなります。 プログラミング言語の他の部分に適用されるのと同じツールを使って、より体系的にコードを再構築することができます。 PRのコード差の方がわかりやすくなります。 UI要素は、マークアップ言語とは対照的に、実際のデータ構造（関数、クラス、構造体）で構築されています。 そのため、Viewのユニットテストも行うことができます。 もちろん、気にかけるべき欠点は常にいくつか存在します。 SwiftUIとJetpack Composeはまだ生まれて数年しか経っていません。 ドキュメントの不足、コミュニティの小ささ、いくつかのパフォーマンスの問題（例えばAndroidの遅延カラム）などの欠点があり、また以前のフレームワークからのすべてのコンポーネントがサポートされているわけではありません。 より複雑なUIを構築しようとすると、制限があります。SwiftUIとJetpack Composeの両方は、まだ進化し、改善されています。 […]
【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 […]
OpenTelemetry対応開始のご案内： オブザーバビリティ（可観測性）データの有効利用
Sentryは、2008年にサイドプロジェクトから成長していたオープンソース企業です。 現在では、350万人以上の開発者たちに利用されるアプリケーションパフォーマンス監視（APM）プラットフォームへと拡大しています。Sentryは、オープンソースと開発者たちのコミュニティにコミットしています。 また私たちは、コミュニティに対してオープンで透明であることにコミットしています。 Sentryは、ソフトウェアを構築するために、パブリックアプローチをとっています。 OpenTelemetry（またはOTel）の対応とインテグレーションは、Sentryにとって非常に自然なパートナーシップです。 何千もの企業がOpenTelemetryを使用して、サービス全体のデータを取得しています。 生ログ、トレース、メトリクスをキャプチャすることで、ソフトウェアのパフォーマンスを改善するための最初のステップが始まります。 OpenTelemetryを使用している開発者は、Sentryの最新のAPMを使用できるようになりました。 SentryのAPMツールは、開発者たちを第一に考慮して作られています。 私たちは、すべてのオブザーバビリティ（可観測性）データを実用化します。SentryとOpenTelemetryを使用する開発者たちは、パフォーマンス問題の根本原因をより迅速に特定し、解決することができるようになります。 Sentryは、Golang、Node.js、Python、Ruby、Javaをサポートしており、近日中に.NETがそこに加わります。 これにより開発者たちは、SentryのパワーとOpenTelemetryが設定されたアプリケーションからのパフォーマンスデータを組み合わせることができます。また開発者たちは、問題の原因となっているコードや関数の行を突き止めることができるようにます。 多くの無駄なデータを分析したり、ツール間を行き来したりする必要はもうありません。 Sentryは、利用者がより速く修正にたどり着くために必要な答えを見つけることを可能にします。 OpenTelemetryとSentryの連携を開始する Sentryは開発者優先のツールであり、簡単な導入プロセスを提供することで、開発者が複雑な設定に時間を費やすことなくコード作成に集中できるよう設計されています。 OpenTelemetryのインテグレーションは、設定も簡単です。 ソフトウェアに数行のコードを追加するだけで、すぐにSentryでテレメトリーデータを見ることができるようになります。 一度設定すれば、自動的に読み込みの遅いページのトレースが開始されます。 問題の原因となっているAPIコールやKafkaキューまで、簡単に確認することができます。他にも関連するエラーがあれば、Sentryはそれらも表示し、発生している可能性のある他のエラーと結びつけます。 Sentryは、問題を迅速に解決するために必要なすべてのデータ背景情報を提供します。それはまるで、ソフトウェアにGPSを搭載しているようなものです。Sentryは問題の原因を直接指摘してくれます。 SentryとOpenTelemetryを使い始めるのは、早くて簡単でした。私たちがSentryを選んだ理由は、どこでなぜ遅延が発生しているのかを理解できるからです。 迅速に修正し、ユーザーからのクレームを防ぐことができます。 Dominik Sandjaja シニアソフトウェアエンジニア @bex technologies GmbH Open TelemetryとSentryを使用して、ソフトウェアをより速く修正 顧客が注文をするためにチェックアウトページにたどり着きました💰。すべてがうまくいったように見えます。でも、errors.errorString（別名：無効な製品ID）が原因でサイレントクラッシュが発生し、支払いのフローが壊れてしまいました。顧客は注文を完了できず、怒りのソーシャルメディア投稿💸を書き始めます。 Sentryは、これを解決するのに役立つことができます*。Sentryはそのエラーを捕捉し、OTelのトレースデータと組み合わせます。Sentryは警告を発し、コードのどこに問題があるのかを正確に示します。 自動グループ化を用い、Sentryのフィード画面に個々の課題が表示されます。Sentryは、すべてのユニークなインスタンスをグループ化します。また、OTelからのトレースとスパンを同様に使用することもできます。Sentryは、エラーと問題を引き起こした関連する分散サービスを結びつけます。 問題が特定されたら、SentryのGithubとの強固なインテグレーションを活用し、その分散システムのコードをどのチームやエンジニアが所有しているかを見つけることができます。そして、そのチームをSentryから直接担当に割り当てることができます。 担当者らは、誰とも会話する必要もなく、修正作業を開始し、本番環境にリリースすることができます🪄。 Sentryは、アプリケーションコードの健全性を監視するための不可欠なツールです。エラー追跡からパフォーマンス監視まで、開発者たちは、フロントエンドからバックエンドまで、アプリケーションをより明確に理解し、より迅速に問題を解決し、継続的に学習することができます。Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの監視機能を提供しています。 毎月Sentryは、インターネット上で最も人気のある製品から数十億の例外処理を行ってしています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。