Sentry - Ichizoku

『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の日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

Laravelとの提携に興奮する理由

Laravelの友人がSentryとの新しいパートナーシップを発表しました。簡単に説明すると、新規または既存の Forge/Vapor サイトに数クリックでエラー監視とトレース機能を追加できるということです。この新しい統合は、PHP 開発者が可能な限り簡単にプロジェクトの実際の遠隔測定を収集できるように設計されています。 PHPアプリケーションのビルド、デプロイ、管理、デバッグ ForgeとVaporのUIを通して、Sentryを初めて使う開発者は、組織やSentryプロジェクトを作成することができます。 ForgeはLaravelのサーバー管理とデプロイサービスであり、Vaporは60万以上のPHPアプリケーションを提供するサーバーレスデプロイプラットフォームです。 Laravelのビデオで、実際の動作をご覧ください。この統合により、PHP 開発者はアプリケーションのビルド、デプロイ、管理、デバッグをより効率的かつ確実に行えるようになります。この統合を通じてPHPのエコシステムをサポートし続けるため、今後も多くの改善が行われることを期待しています。拡大するLaravelユーザーをサポート Laravelは、10年以上にわたってアプリケーション開発の中核を担ってきました。 PHPフレームワークの中で最も人気があり、急成長しているフレームワークの1つで、そのクリーンで表現力豊かな構文とモダンなコーディング原則により、書きやすく読みやすくなっています。大企業や新興企業の開発者は、Laravelを使用してアプリケーションを迅速に構築し、デプロイしています。少なくとも毎年1つのメジャーリリースと、数週間ごとの反復リリースがあり、Laravelのイノベーションは衰えていません。例えば、Laravel 11では以下のようなリリースが行われています。 Reverb (ファーストパーティのWebSocketサーバー) グレースフル暗号化キー・ローテーション秒単位のレート制限合理化されたアプリケーション構造 Sentryには、100以上のSDK、フレームワーク、ライブラリがあり、開発者が使用するツールに精通しています。 Sentryの中で、Laravelは3番目に人気のあるバックエンドSDKで、毎年増え続けています。まだ始まったばかり PHP開発者の間でのLaravelの持続的な人気は、驚異的としか言いようがありません。 Laravelが長年愛されているのは、その技術のパワーとPHPコミュニティ内で築かれた信頼があってこそだと物語っています。 Sentryは、LaravelとPHPコミュニティにコミットし、皆様を念頭に置いて構築し続けています。新しいForgeとVaporの統合により、私たちはLaravelアプリの管理、デプロイ、デバッグのための新しいスタンダードを築き上げます。詳しい使い方はドキュメントをご覧ください。 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の日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

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 […]

【Sentry】TTFB(Time to First Byte)を減らし、ユーザ体験を改善する手法について

最近、私はただひとつの指標、TTFB（Time to First Byte）を改善することに集中することで、すべてのホームページのCore Web Vitalsを改善しました。データを取得する方法に2つの小さな変更を加えるだけで、p75のTTFBを3.46秒から704msに短縮することができました！（「p75」と「TTFB」については後述します）この記事では、私がどのように問題を発見し、それを解決するために何をしたのか。そして、その過程で下した重要な決断について説明します。 Sentryパフォーマンス・モニタリングの使用新しいサイトを立ち上げるとき、新機能を開発するとき、サイトが本当に遅いと気づいたときがありました。 2021年から22年にかけて、私はパフォーマンスを改善するためにWebサイトを一から作り直しました。しかし時間が経つにつれ、私はサイトのさまざまな部分に実験的な技術をたくさん追加し、パフォーマンスが再び、恥ずかしくなるほど悪くなってしまいました。ここ数ヶ月の間、Webサイトをロードしているときに私自身がこのことに気づいていましたが、Sentryパフォーマンス・モニタリングをサイトに追加したときに初めて全体像を見ることができました。 Sentryのようなパフォーマンス監視ツールを使用することの素晴らしい点は、OS、ブラウザ、モバイルデバイス、インターネット接続、その他ユーザーエクスペリエンスに影響を与える多くの要因すべてにわたって、Webサイトの実際のユーザーデータを表示してくれることです。以前は、Google Lighthouseのようなツールを開発中やWebサイト構築中に使用して、新しいビルドごとにパフォーマンスを分析していました。実際のユーザーデータの方がはるかに価値があります。 Here’s what the performance looked like on my homepage before any modifications from February 14-21 2024. 2024年2月14日から21日まで、修正前の私のホームページのパフォーマンスはこんな感じでした。最も緊急に改善すべきと目立ったのは、TTFB（Time to First Byte）でした。 TTFBとは、ブラウザがサーバーにリクエストをしてから、最初の1バイトのレスポンスを受け取るまでの時間を指します。理論的には、TTFBが低ければ低いほど、ブラウザはより早くページの描画を開始することができ、ユーザーはより早くブラウザで何かを見ることができます。結果的に、離脱する可能性が低くなります！ここに表示されているTTFBの値は、75パーセンタイル（p75）のもので、3.46秒が全ホームページビューの75%に見られた最悪のスコアであることを意味します。これはまた、25％のユーザーがページの読み込みに3.46秒以上待たされたことを意味します。この悪いスコアは、レスポンスが送り返される前にサーバーで行われている処理が多すぎることを示していました。ひとつはニュースレター・プロバイダからデータを取得して最新の購読者数を取得するもので、もうひとつはTwitch APIからデータを取得して最新のストリーム動画や現在進行中のライブ・ストリームの最新のサムネイルを表示するものです。どちらの関数も、最初のHTTPレスポンスをメモリに取り込み、サードパーティのAPIからデータを取得し、それに応じてHTMLを書き換えます。このアーキテクチャの目的は、静的に生成されたホームページに動的なデータを表示するために、メインのJavaScriptスレッドをブロックする可能性のあるクライアント側のデータ・フェッチを最小限に抑えることでした（スケルトン・ローダーは嫌いです）。これは「ユーザーに最新のものを見せる」という観点では素晴らしいものでした。しかし、HTTPリクエストが事実上重複してしまうため、ブラウザに何かを表示するのにかかる時間が2倍になってしまうことが問題でした。そして静的な地域にある2つの別々のサードパーティ・サービスが、世界のどこからでも（エッジから）呼び出されることによるAPIの待ち時間の変化も加わり、ちょっとした混乱に陥り始めます。正確なニュースレター購読者数は、私以外の誰が求めているのでしょうか？ […]

Supabase データベースとエッジ機能の監視

クラウドサービスが登場し始めた頃、多くの開発者は、オンデマンドでWebアプリケーションをデプロイするために、あらゆる種類のインフラをスピンアップして拡張できることに驚嘆しました。しかし、大手のクラウドサービスプロバイダーは利用が複雑で、スケールアウトには費用がかかり、デフォルトのモニタリングソリューションはあまり洞察に富んでいないのが実情です。その上、我々開発者は、物事が簡潔であることを望んでいます。 SupabaseとSentryはデプロイとモニタリングを簡素化します。 SupabaseはデータベースとEdge Functionのデプロイを容易にし、Sentryとの新しい統合はローカルと外部でのコードの監視を簡単にします。新しいSupabaseとSentryの統合により、Supabaseを通してデプロイしたコードを数行のコードで簡単に監視できるようになりました。そのため、新しいWebサービスが爆発的に普及した場合、Sentryは認証されたEdge FunctionsとDBの呼び出しが監視されていることを確認し、手に負えない問題が発生した場合に警告を発します。機器データベースの統合 SupabaseはJavaScriptクライアント @supabase/supabase-js を提供し、アプリケーションがプラットフォーム上で動作する Postgres データベースとやり取りできるようにします。 Supabaseチームのサポートにより、Sentryとの統合が可能になり、SupabaseのJavaScript SDKを利用してSentryでパフォーマンスモニタリング、ブレッドクラム、エラーのトレースを収集できるようになりました。セットアップコピーして、貼り付けて、さあ始めましょう。以下のスニペットは、Sentry SDKとSupabaseクライアントをインストールして初期化し、前述のすべての洞察を収集するために必要なすべてを記しています。エラーとトレースがSentryに確実に取り込まれるようにアプリケーションをセットアップするための詳細については、@supabase/sentry-js-integration documentationとrepoを参照してください。 Supabaseクライアントでは、ログインやユーザー管理機能の構築、大容量ファイルの管理、Deno Edgeファンクションの呼び出しも可能です。 Sentryは、あなたのコードがエッジ上で実行されているときでも、同様に監視されていることを確認するのに役立ちます。エッジ機能サポート 2023年11月のローンチ・ウィークでは、できるだけ多くのプラットフォームで、できるだけ多くのデベロッパーにサポートを提供するために、私たちがどのように取り組んでいるかについてお話ししました。特筆すべきは、これにはDenoも含まれているということだ。 Denoは、流行に敏感な開発者の間だけでなく、Supabaseのようなプラットフォームの成長によっても人気が高まっています。 Supabaseは、エッジ機能のランタイムとしてDenoを使用しています。Sentryは、当社のDeno SDKを通じてこれをサポートしています。 Denoは、Edgeランタイム上でコードを実行する機能を提供しますが、Sentryは、コードを確実に監視し、エラーやパフォーマンス課題が発生した場合にアラートを出すことができます。設定の詳細はこちらをご覧ください。ピースをつなぐ Supabaseは、週末の片手間で構築でき、世界中に拡張できることを約束します。 Sentryとの統合により、エラーや遅いDBクエリがいつ、どのような理由で発生したかを確実に知ることができます。Sentryを初めて使う方はアカウントを作成することができます。また、この統合に追加してほしい機能などがあれば、GitHubでもお問い合わせを受け付けています。ぜひご連絡ください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

SentryとOpenTelemetryによるAspire Insightsの本番稼動対応

Aspire 101 .NET8のリリースに伴い、Microsoftは分散アプリケーションの作り方を大きく変える.NET Aspireと呼ばれる新しいフレームワークをリリースしました。 Aspireは、.NETでの分散アプリケーションの構成とデプロイを簡単にします。詳細については、Aspireのドキュメントを参照してください。 Aspireを使用してアプリケーションをビルドすると、以下のような利点があります。 OpenTelemetryのログ、メトリクス、トレースヘルスチェックサービスディスカバリー .NETでのオーケストレーション（KubernetesやDockerの設定ファイルに潜る必要なし）その他多数 Aspireには、”リソース”（Aspireでは分散システムの様々なコンポーネントを “リソース “と呼ぶ）から生成されるテレメトリを簡単にナビゲートできるダッシュボードが付属しています。これらすべてが、かなりクールな開発者体験をもたらします。そして、我々は、OpenTelemetry データを Sentry と簡単に共有することができます。Sentry は、テレメトリーデータから得られる全ての洞察に加えて、Sentry が提供する全てのクールなもの（クラッシュレポート、ソースマップ、.NET でビルドされていない分散アプリケーションコンポーネントを計測する機能など）を提供してくれます。また、Sentryを使えば、開発現場でも生産現場でも、このインストルメンテーションを利用することができます（現在、Aspireのダッシュボードは開発者のみの体験となっています）。では、どのように配線するのか見てみましょう！注：以下のすべてのソースコードはGitHubで入手可能です。基本的なAspireソリューションの作成 Aspire を使い始めるための良いチュートリアルがいくつかあるので、ここでは詳しく説明しません。まず、ツールのセットアップが完了したら、コマンドラインから新しい aspire ソリューションを作成します。これは、最小 API (ApiService)、Blazor フロントエンド (Web)、Aspire ソリューションのバックボーンとなる 2 つのプロジェクト (AppHost と ServiceDefaults) から構成される aspire-starter テンプレートを使用して、新しい Aspire ソリューションを作成します。 ServiceDefaults には、ソリューション内のすべてのプロジェクトに共通する設定を配線するためのさまざまな拡張メソッドが含まれています。 AppHostはすべてのオーケストレーションに使用され、開発マシン上ですべてをパワーアップしたいときに実行するアプリケーションです。便利なダッシュボードも含まれています。ダッシュボードには、分散アプリケーションの各「リソース」に対応するURLへの便利なリンクに加え、それぞれのログ、トレース、メトリクスが表示されます。 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でもお問い合わせいただけます。 […]

【Break Production Less】Codecovのプレリリース・フォーカスの紹介

テストプラクティスとツールの改善を支援しようとするソリューションは、世の中にたくさんあります。しかし私たちは、高品質なソフトウェアは、テストがいかにうまく行われているかに限らないと考えています。そのため、私たちはコードカバレッジの枠を超え、バンドル分析、テスト分析、AIを活用したコードレビューを備えた初のプレリリースプラットフォームの基盤を構築しています。 JavaScriptバンドル分析バンドルサイズが重要なのは、アプリケーションのパフォーマンス、帯域幅の使用量、ロード時間に直接影響するからです。バンドルが大きいとロード時間が長くなり、パフォーマンスが低下し、ユーザーエクスペリエンスが低下します。私たちは、開発者がこのような課題に立ち向かえるよう、JavaScript バンドル解析を展開しています。私たちのBundle Analysisは、Rollup、Vite、Webpackと連携し、エンドユーザーに影響を与える前に問題を診断するのに役立ちます。今すぐ Bundle Analysis を試して、GitHub issue で感想を聞かせてください。バンドル解析はすべてのCodecovユーザーが無料で利用でき、ほとんど設定なしで動作します。テスト分析欠陥のあるテストや、CIの実行に時間がかかるテストは、デプロイ失敗のリスクを高め、新機能を迅速にデリバリー（リリース）することを難しくします。そこで、テストの実行時間や失敗率のデータを提供し、不安定なテストを特定する Test Analytics を紹介します。テストの失敗に関する洞察を GitHub 内で直接提供することで、コードの行をスクロールすることなく、テストに欠陥がある箇所や失敗している箇所を確認することができます。これによって、問題の発見と対処がより速くできるようになります。😏 Codecov PR Commentでテストの失敗情報を取得するには、テスト結果をJUnit XMLファイルとして生成し、そのファイルをCodecovにアップロードするだけです。 Test Analyticsを使い始めるには、こちらのドキュメントをご覧ください。テスト失敗レポートは現在稼働中ですが、私たちはテスト管理プロセスを改善し、コードレビューのサイクルをスピードアップするために、Flaky Test Detectionを積極的に開発しています。テストの失敗や欠陥のあるテストについてどう思いますか？ GitHub issue でご意見をお聞かせください。 AIによるコードレビュー機能コードレビューで最悪なのは、自分のPRを誰かにレビューしてもらうことです。ああ、他のチームの誰かにあなたの変更をレビューしてもらう必要があるなら、幸運を祈ります。もしあなたがPRを開いた瞬間に、誰かもしくは何かがレビューしてくれたらいいと思いませんか？ Codecovの新しいAIコードレビュー機能は、まさにそれを可能にします。明らかなミスを特定し、開発者がコード変更のより複雑で重要な側面にコードレビューを集中できるようにする、物知りな友人のようなものだと考えてください。これは、レビューの迅速化、承認の迅速化、顧客への機能提供の迅速化、そして「最新の変更をレビューしてもらえますか」というメッセージの減少を意味します。まとめ Sentryはおそらく本番環境であなたのコードを監視していると思いますが、デプロイする前にはギャップがあります。そこで、SentryのCodecovチームは、コードカバレッジだけでなく、リリース前のすべてにフォーカスを移すことで、そのギャップを埋めようとしています。これはほんの始まりに過ぎません。私たちが境界を押し広げ、一度に1行のコードでソフトウェア開発の未来を形作り続けるように、私たちに加わってください。いつものように、あなたのご意見をお聞かせください。また、Codecovを初めてお使いになる方は、今すぐ無料でお試しいただくか、デモ利用のお申し込みをください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

Archives: Sentry