ダッシュボードをエージェントで作成・編集する新しい方法
Article by: Ben Coe , Steve Zegalia AIエージェントが当たり前になった世界では、チームが重要な KPI を追跡するためにビジュアライゼーションを手作業でじっくり組み上げていく、従来型のダッシュボードワークフローは終わりを迎えつつあります。 数年前、エージェントがあらゆる場面で利用されるようになる前、私たちは開発者が重要なユーザー体験を監視しやすくしようと取り組んでいました。その成果として Insights ページを導入しました。これは事前に設定されたダッシュボードで、Web Vitals や Mobile Vitals といった一般的な健全性シグナルをあらゆる Sentry ユーザーがすぐに活用できるようにしたものです。 考え方は正しかったものの、問題がありました。多くの企業が共通のシグナルを持つ一方、各組織はそれぞれ固有の事情を抱えています。意味のあるカスタマイズができなければ、ほとんどのチームは結局、手作業でダッシュボードを構築する作業を延々とこなす羽目になっていました。そこで私たちは改善を続けました。 オンデマンドでカスタマイズ可能なダッシュボードをついに現実のものにしたのは、大規模言語モデルです。ビジュアライゼーションは、人間にとってもエージェントにとっても、最も情報密度の高いコミュニケーション手段のひとつであり続けていますが、変わったのはそのビューを作成するコストです。 ウィジェットをひとつひとつ組み合わせてダッシュボードを作る代わりに、エージェントに指示して Sentry 上で直接ダッシュボードを作成・編集したり、Sentry CLI で他のモデルと連携して目的に合わせたダッシュボードを生成したりできるようになりました。 Insights ページはSentry Built Dashboards になりました。クローンし、エージェントにプロジェクト向けのカスタマイズを依頼できます。ダッシュボードは数秒で作成でき、プロジェクトや調査の期間中使い続け、必要がなくなれば廃棄することができます。 新機能まとめ エージェントによるダッシュボード作成・編集（ベータ版）： AI 機能が有効化されているすべての組織で、エージェントを活用したチャット体験を通じて Sentry でダッシュボードを作成・編集できるようになりました。 Insights が Sentry Dashboards に： Insights ページをクローンし、編集可能な Sentry Dashboards に置き換えました。特定のユースケースに合わせてカスタマイズできます。 Sentry CLI によるダッシュボード作成・編集： 新しい Sentry CLI を使って、ターミナルから […]
Sentry にプロダクト分析はもう揃っている
Article by: Rahul Chhabria 必要なものは、すでに手元にそろっています。 Sentry を使っているなら、トレース、構造化ログ、そして新たにアプリケーションメトリクスもあるはずです。多くのチームはデバッグ目的にしか使っていませんが、実はそのデータで、別チームが管理し、別のデータモデルを持ち、別の費用がかかる専用アナリティクスツールに投げていたプロダクトの大半の問いに答えられます（すべてではありません。ギャップについては後ほど正直にお伝えします）。 この記事は、プロダクトアナリティクスツールの存在意義を問うものではありません。開発者がプロダクトインサイトの宝の山の上に座りながら、その問いを他の誰かに外注してきたという事実についての記事です。そうしなくていいのです。 これが今、5年前より重要な意味を持つ理由があります。「プロダクトマネージャー」と「ソフトウェアエンジニア」の境界が曖昧になりつつあるからです。アップタイムやレイテンシだけでなく、採用率・リテンション・ユーザー行動まで考えることが、エンジニアにも求められるようになっています。プロダクトエンジニア（最近はもはや「エンジニア」と同義になりつつありますが）であれば、デバッグに使っているツールで、プロダクトに関する問いの答えを得ることができます。そういう使い方をしてこなかっただけで。 プロダクトの問いはすべて、手元のテレメトリにマッピングできる 「今週、オンボーディングを完了したユーザーは何人いるか？」 これはカウンターメトリクスです：metrics.count(“onboarding.completed”, 1)。プランの種類、国、流入元など、すでに設定している属性でスライスできます。 「地域別のチェックアウトレイテンシの p95 はどれくらいか？」 これはスパンのディストリビューションです。トレースにはすでにタイミング情報があります。あとはクエリするだけです。 「火曜日にサインアップが落ちたのはなぜか？」 これは構造化ログです。サインアップサービスは signup.failed を reason: email_validation_error や deploy_sha: a3f9b2c といった情報と一緒にログに記録しています。そのログはすでに、リクエスト全体のライフサイクルを示すトレース、エラーが発生したスパン、それを引き起こしたリリースと紐づいています。トレースからワンクリックで Issue に移動でき、Issue からコミットと原因となったコードの行へたどり着けます。 PM がアナリティクスツールに投げているのと同じ質問です。違いは、自分のテレメトリから答えるとき、その答えにはコンテキストが伴う点です。アナリティクスツールは「何が起きているか」を教えてくれます。テレメトリは「何が起きているか」「なぜ起きているか」、そして「責任のあるコードへの直接の道筋」までセットで教えてくれます。 あるクライアントから最近、こんな話を伺いました。アナリティクスツールが問題を知らせてくれるのは被害が出た後ばかりで、先手を打ちたいと。そのクライアントが辿り着いた答えは、すでに収集しているテレメトリにアラートとモニターを設定することでした。ビジネス上重要なメトリクスが下降傾向を示し始めたとき、週次のダッシュボードレビューで気づくより前にアラートが発動します。そしてそのアラートは完全なトレースと繋がったスパンやメトリクスに紐づいているため、別ツールへのコンテキストスイッチなしに、最初からコンテキストを持った状態で調査を始められます。収集するデータを変えたわけではなく、それをどう監視するかを変えたのです。 実際どのようなものか 新しいエクスポート機能のユーザー採用状況を把握したい、パフォーマンスを確認したい、有料ユーザーと無料ユーザーの挙動の違いも見たい、というケースを考えてみましょう。 アナリティクスツールへのインストルメントチケットを作成する必要はありません。スパン、構造化ログ、アプリケーションメトリクスという3つの基本要素がすでに手元にあります。 リクエストレベルのコンテキストにはスパン。 スパンはリクエストがシステムをどう流れ、各処理にどれだけ時間がかかっているかを示します。エクスポート API ハンドラーにはすでにスパンがあります。そこにビジネスレベルの属性（プランでスライスできる export.user_tier など）を追加しましょう。 採用状況、パフォーマンス、エラーを一か所でクエリしてみましょう。 すでにストーリーが見えてきます。xlsx エクスポートは csv の 3〜4 倍遅く、無料プランの xlsx は […]
【View Renderer V2】iOS Session Replay パフォーマンスを向上
Article by: Phil Niedertscheider モバイル向け Session Replay を一般提供（GA）にした後、採用は急速に進み、より多くのフィードバックが私たちのもとに届くようになりました。 あまり良くない話ですが、Apple SDK のユーザーから、古い iOS デバイスでの Session Replay のパフォーマンスオーバーヘッドにより、アプリが使い物にならなくなったという報告がありました。 そこで私たちは原因を突き止めるための旅に出て、ベンチマークで 4〜5 倍良いパフォーマンスを得られる解決策を見つけました。モバイルの Session Replay の内部で何が起きているのかを理解するために、技術的な詳細に入る前に、まずモバイルの画面録画がどのように動作するのかを見ていきましょう。 フレームレートをひと言で言うと 画面録画とは、フレームと呼ばれる高速で表示される多数の画像から成る動画です。人間の目は 1 秒あたり約 60 フレーム（フレームレート）を処理でき、これはヘルツ（1 Hz = 1 秒あたり 1 単位）で測定され、動いている映像の錯覚を生み出します。フレームレートは用途によって異なり、映画では 24 Hz、ゲーミング向けの PC ディスプレイでは 144 Hz まであります。 より高いフレームレートはより滑らかな動画を生みますが、重大なトレードオフを伴います。 同じ動画の長さでも、ストレージとネットワーク帯域の消費が増える 1 秒あたりに処理すべきフレームが増え、性能を維持するにはより強力なハードウェアが必要になる フレームレートを最小まで下げると、録画はストップモーション動画のように見えます。このスタイルのとても良い例は、この YouTube 動画で見ることができます。フレームは単に連続した写真にすぎませんが、それでも動いている写真のように感じられる、つまり動画です。 これは本質的に、私たちがモバイルの Session […]
堅牢な時系列モニタリング Matrix Profile と Prophet を用いた異常検知
Article by: Ram Senthamarai, Aayush Seth 異常検知は鏡だらけの家で探偵をしているようなものです。何かがおかしいのは分かるけれど、見えているのが本当の問題なのか、それとも奇妙な反射にすぎないのか、いつも確信が持てません。 本番環境のシステムを監視するのは、絶えず形を変える干し草の山の中から動き回る針を探すように感じることがよくあります。Sentry では、お客様が従来のしきい値ベースや割合ベースのアラートを超えられるようにすることを目標にし、システム内の微妙で複雑な異常をほぼリアルタイムで検知できるよう支援することを目指しました。 本記事では、当社の AI/ML チームが Matrix Profile と Meta の Prophet を用いて、時系列の異常検知システムを開発した方法を詳しく説明します。直面した課題を取り上げ、このハイブリッドなアプローチによって、より信頼性が高く、よりインテリジェントなアラートを構築できた理由を解説します。 問題：ノイズの多いメトリクス、微妙な障害 システムメトリクスは本質的にノイズが多いものです。しかし、適切なタイミングで適切な異常を特定できるかどうかで、結果は大きく変わります。たとえば、素早い修正で済むのか、重大インシデントに発展するのか。とはいえ、自動の時系列異常検知（Time Series Anomaly Detection。以下 TSAD）は簡単な問題ではありません。 コンテクストがすべて：データのスパイクは異常かもしれませんし、週末セール、プロダクトローンチ、システムメンテナンスの影響にすぎない場合もあります。コンテクストがなければ、その違いは判別しにくくなります。 「正常」は常に変動する：パターンは時間とともに変化します。季節性、トレンド、そして突然のレジームシフト（状態の急変）によって、今日の「正常」が明日の「異常」になり得ます。 ノイズとシグナルのせめぎ合い：システムメトリクスのデータはノイズが多くなることがあります。特に大規模環境では、誤検知を連発せずに真の異常だけを検知するのは簡単ではありません。 万能解はない：各メトリクスの振る舞いは異なります。CPU 使用率、ユーザー登録数、取引量など、それぞれ特性が異なるため、状況に応じたアプローチが必要です。 ラベル付きデータがない：教師あり学習は、正解（グラウンドトゥルース）がない場合、難しくなります。多くの場合、何が異常だったのかは、実際に何かが壊れてから初めて分かります。 Sentry のスケール：何十万ものメトリクスを監視する Sentry のようなオブザーバビリティプラットフォームの規模で、この問題を解くことを想像してみてください。 要するに、自動 TSAD には、コンテクストを理解し、適応的で、精度が高く、しかもスケールすることが同時に求められます。 解決策：ハイブリッドアプローチ ARIMA、SARIMA、TimeGPT、Moirai、AutoFormer、ChatTS などさまざまなモデルで広範に実験した結果、私たちは Matrix Profile と Prophet を組み合わせたハイブリッド手法に落ち着きました。これらのモデルを組み合わせることで、時系列データにおける異常をより広い視野と、よりニュアンスのある形で理解できるようになります。 Matrix Profile：形状ベースの異常検知 […]
【Emerge Tools】Sentryの一部に
Article by: David Cramer 本日（2025/5/6）、Emerge Tools が Sentry に加わることを発表できることを大変嬉しく思います。 Emerge は、世界の主要ブランドから信頼される最高水準のモバイル向けツールを開発しています。同社チームのたゆまぬ 努力 によってモバイル ビルドを改善してきた取り組みを、皆さんもどこかで目にしたことがあるかもしれません。Sentry では以前からその姿勢を高く評価してきました。 そして実際に Emerge の共同創業者である Josh と Noah に初めて会ったとき、私たちは同じ世界観を共有していることを感じ、すぐに意気投合しました。 モバイル分野は、私たちの業界において常に複雑な存在でした。重要であることは誰もが認める一方で、しばしば軽視されてきた領域でもあります。これまでモバイル特化型のツールが数多く登場してきましたが、モバイルを二の次とする大手ベンダーに取って代わられることも少なくありませんでした。 Sentry では、モバイルアプリケーションをビジネスの重要な延長線上にあるものと捉えています。それは新しい顧客と最初に接する接点の一つであり、テクノロジースタックの他の要素と同等の注目と投資を受けるべき領域です。 市場のリーダーたちはこの重要性を理解していますが、多くの企業はいまだ追随段階にあります。OpenAI は、ChatGPT の体験が iPhone、Android、またはウェブ上のどこであっても快適な体験を提供することが、いかに重要かを深く理解しています。Spotify も同様に、顧客が持つあらゆるデバイス上で自社を存在させる必要があります。DoorDash や Tinder が今のクオリティを維持していなければ、Z 世代の生活はどうなっていたでしょうか。優れたモバイル体験は、私たちが毎日頼りにしているブランドにとって不可欠なものです。 現在の Sentry は、ユニバーサルかつ最高水準のクラッシュレポートおよびアプリケーションモニタリングで広く知られています。そこに Emerge Tools が加わることで、モバイルチームに次のような新たな機能を提供していきます。 アプリをより小さく軽くし、インストール率の向上とユーザー満足度の向上を実現 不要なコードを削除し、バグを減らすとともに、Sentry のコストについて CFO と議論する時間を削減 社内配布を効率的に管理し、残されたバグを顧客ではなく自社チームで発見 ビジュアルリグレッションテストを活用し、サインアップボタンが消えるような問題に再び悩まされることを防止 これはほんの始まりにすぎません。Emerge の専門知識と既存プロダクトが加わることで、皆さんがすでに愛用している機能をさらに強化し、本番監視の枠を超えたサポートを拡張していきます。 私たちはバグを捕まえることを仕事としていますが、本音を言えば、それを未然に防ぎたいのです。 今回の発表および今後の展開については、Emerge […]
【ダッシュボードのアップデート】クリック数削減、操作性向上、ウィジェット作成の高速化
Article by: Alexandra Cota 本番環境のメトリクスを確認していると、突然ダッシュボードにエラーのスパイクが表示されます。このとき最初に考えるのは「この状況を調べるために新しいビューをどのように作ろう」ではなく、「どうすればすぐに原因を突き止められるのか」でしょう。実際、先月私たちのエンジニアリングチームの一つがAPIのレスポンスタイムに異常なパターンを発見した際にも、まさに同じ状況が起こりました。彼らはゼロからアドホッククエリを実行するのではなく、以前のインシデント後に作成していたカスタムダッシュボードを活用しました。 エラーとトレースデータの傾向を関連付けることで、彼らはすぐに原因を特定しました。それはインデックスの欠落による非効率なクエリ実行でした。迅速に修正を加えた結果、レスポンスタイムはすぐに正常に戻り、何時間も手作業で調査する必要はありませんでした。 ダッシュボードは単なる静的なレポートではありません。チームが異常を素早く検知し、シグナル同士の関連性を見つけ、問題の根本原因に素早くたどり着くための動的なツールです。 過去数か月の間に、ダッシュボードの構築、管理、操作を改善するためのさまざまなアップデートを行いました。ウィジェットビルダーの刷新から、ダッシュボードの整理・保護方法の新機能まで、設定にかける時間を減らし、本当に重要なことに集中できるようになりました。 より直感的なウィジェット作成 ウィジェットはダッシュボードの基本要素であり、私たちはウィジェットビルダーを刷新し、ウィジェットの作成・編集をより簡単かつ直感的にし、ワークフローとの統合性も高めました。 サイドパネルデザイン：ページ遷移せずにウィジェットの作成・編集が可能です。 ライブプレビュー：設定を調整すると即座に反映され、余計なスクロールや固定ヘッダーの操作は不要です。 シンプルなレイアウト：視覚的な煩雑さを抑え、必要なステップが一目で分かり、クエリを素早く作成できます。 ウィジェットライブラリの改善：ビルダーのスペースを圧迫することなく、ゼロからウィジェットを作るか、プリセットから始めるかを選択可能です。 ダッシュボードを意図した通りに維持する リリース当日、チームはクリティカルリリースダッシュボードを注視し、問題が拡大する前に検知しようとしています。エラー、レイテンシ、スループット。必要な情報はすべてそろっているはずです。 しかし、状況が悪化し始めたとき、失敗率のチャートが消えていたり、フィルターが変更されていたり、レイテンシのウィジェットがp95ではなくp50を表示していることに気づきます。 実は、誰かがダッシュボードを編集していたのです。その結果、問題を素早く把握するどころか、表示を元に戻すために右往左往し、貴重なインシデント対応の時間を無駄にしてしまいます。 ダッシュボードは、他チームによる意図しない変更が加えられることなく、自分たちが最も重視するインサイトを正しく反映すべきです。今回の更新により、誰がダッシュボードを編集できるかを制御できるようになりました。 これにより、クリティカルリリース用のダッシュボードをロックしたり、自分のチームだけに編集権限を付与したりすることが可能です。新たに追加された「編集アクセス」セレクターにより、適切な制御が可能になり、明確な権限の線引きがチーム間の円滑なコラボレーションを実現します。 お気に入り登録とダッシュボード整理 チェックアウトフロー、認証フロー、主要APIエンドポイントなど、ダッシュボードの数が増えていくと、目的のダッシュボードを素早く見つけることが重要になります。そこで、ダッシュボードのお気に入り機能を導入しました。重要なダッシュボードをリストの上部にピン留めすることができます。 ダッシュボード詳細ページまたはダッシュボード一覧ページで⭐アイコンをクリックするだけで、よく使うダッシュボードがいつでもすぐアクセスできるようになります。 さらに、テーブルビューも追加し、ダッシュボードの整理・管理をよりコンパクトに行えるようにしました。以下の2つのビューを切り替えられます。 グリッドビュー：カード形式のビジュアルレイアウト テーブルビュー：コンパクトな表形式 始め方 Sentry のダッシュボードを使えば、単なる監視にとどまらず、すぐに問題解決へとつなげることができます。トランザクションの失敗が急増しているのを見つけた際、どのデータベースクエリが遅延を引き起こしているのか、どの例外がコード内で発生しているのかを即座に掘り下げることができます。ハイレベルなメトリクスと実装の詳細が直接つながっているため、頻繁に画面を切り替えることなく、問題の特定・診断・修正が可能になります。 これらの改善は、モニタリングとデバッグをよりシンプルにするという私たちの継続的な取り組みの一環です。そしてこれは始まりにすぎません。今後数か月間でさらに多くの改善が予定されています。 この機能は Business プランと Enterprise プランのすべてのユーザーが利用できます。ぜひダッシュボードで自分だけの画面を作ってみてください。 まだ Sentry のアカウントをお持ちでない方もご安心ください。無料トライアルやデモリクエストですぐに始められます。 Original Page: Dashboard updates: Fewer […]
異常検知アラートがオープンベータで利用可能に より賢いモニタリング・誤検知を削減
Article by: Rachel Wang, Aayush Seth 数週間前、私たちはアーリーアダプター向けに異常検知アラートを導入しました。そして本日（2025/3/25）、異常検知アラートが正式にオープンベータとなり、Trial、Business、Enterpriseプランの全Sentryユーザーが利用可能になったことをお知らせします。 異常検知アラートとは？ Sentryでは、特定のメトリクスが予想された閾値から逸脱した際に通知されるメトリクスベースのアラートを設定できます。例えば、エラー率が一定の閾値を超えたときや、主要なアプリケーションパフォーマンス指標が特定の範囲を外れたときにアラートを作成できます。 強力ではありますが、メトリクスのアラート閾値を手動で設定するのは複雑な作業になりがちで、しばしばノイズの多いアラートや、最悪の場合は問題の見逃しにつながることもあります。従来、Sentryでメトリクスアラートを設定するには、適切なバランスを見つけるためにかなりの推測と試行錯誤が必要であり、さらにデータについての深い理解も求められていました。 アラート詳細ページでユーザーのクエリによって定義されたカスタムメトリクスアラートで発生した異常アラートの例です。チャート上では赤色で表示され、アルゴリズムが異常な挙動を検知するとアラートが発報されます。 異常検知アラートは、予想されるパターンを自動的に学習することで、この複雑さを解消し、ユーザーは設定や推測なしでアラートを作成できます。静的な閾値を手動で定義する代わりに、異常検知アラートは過去のデータを利用して予測される傾向を判断します。これにより、誤検知が減り、アプリケーション監視時のシグナルとノイズの比率が改善されます。 さらに、静的な閾値は状況の変化によってすぐに古くなったり無意味になったりしますが、異常検知アラートは時間とともに動的に調整され、昼夜や平日・週末といった季節性や、持続的な成長といった長期トレンドも考慮します。これによりビジネスやアプリケーションが変化しても、アラートは常に適切な状態が保たれます。 仕組み 異常検知アラートは、Matrix Profiling と Prophet Forecasting という2つのアルゴリズムの組み合わせを活用しています。 Matrix Profiling：最新のデータポイントが過去のパターンと比べてどれほど「意外」かを検出します。現在と過去のデータ系列間のユークリッド距離に基づいて異常を評価します。 Prophet Forecasting：季節性や長期的なパターンを考慮しながら期待されるトレンドのモデルを構築し、データポイントが予測範囲から外れたときに逸脱として検出します。 ハイブリッド検知： 両方のアルゴリズムが異常を検知した場合、または片方が高い確信度で異常を検知した場合に、システムは異常アラートを発報します。この組み合わせたアプローチにより、誤検知（偽陽性）と見逃し（偽陰性）の両方を最小限に抑えます。 今すぐ試してみよう 異常検知アラートは現在、Trial、Business、Enterpriseプランのすべてのユーザーにオープンベータ版として提供されています。 始めるには、左側のナビゲーションバーの Alerts タブに移動し、Create Alert をクリックしてください。次にメトリクスを選択し、検知方法として Anomaly を選び、必要に応じて感度を調整すれば、あとは Sentry が処理してくれます。異常検知アラートの設定方法については、ドキュメントに詳しい情報があります。 異常検知アラートのパブリックベータ版公開は、私たちのチームにとって大きな節目であり、今後もこの機能の安定化に取り組んでいきます。皆さんのフィードバックもぜひお聞かせください。ぜひ試して、ご意見をお寄せください！ Original Page: Anomaly Alerts Now in Open Beta: Smarter […]
【Breakpoint まとめ】稼働監視・ロボット・豊富なフィーチャーフラグ
Article by: Sasha Blumenfeld バグは丁寧に現れることはなく、チェックアウト機能をクラッシュさせ、認証を破壊し、APIの応答速度を極端に低下させます。しかも多くの場合、CEOから進捗状況を尋ねられる直前に発生します…。さらに、エラー通知ボックスが「TypeError: cannot read property of undefined」の亜種で埋め尽くされると、真に重要な問題を見極めることが困難になります。 そのため、デバッグにおける推測作業を排除するためのアップデートを展開しました。調査に費やす時間を短縮し、開発に集中できるようにすることが目的です。ユーザーに影響が及ぶ前にダウンタイムの通知を受け取り、サイト上で関連する問題やユーザーからのフィードバックを直接確認できます。また、AIによるアラートのグルーピング機能により重複を整理し、AI支援による修正により、問題の迅速な解決が可能になります。 アプリ障害、上司より先に気づけていますか？ プロダクション障害はそれだけで問題ですが、それを CEO の Slack メッセージで知るのは最悪です。 現在一般提供中の Uptime Monitoring を使えば、SNS で炎上したり、全社ミーティングで取り上げられたりする前に、障害を検知することができます。 最短60秒間隔で実行されるグローバルチェックにより、障害発生の瞬間を即座に把握できます。 以下のことが可能です。 重要なフローの監視たとえば、購入処理が突然止まったかどうかを検出するためのチェックアウトページやユーザーがログインできなくなっているかを確認するログインエンドポイントなどです。 カスタム条件の設定たとえば、ダウンタイムが60秒を超えた場合にのみ通知を受け取るように設定可能です。 普段使用しているツールでの通知Slack、PagerDuty、Teams、または Webhook 経由です。 たとえば、チェックアウトページが突然タイムアウトし始めたとしましょう。顧客からの苦情を待つ代わりに、即座にアラートが届きます。障害ログを確認すると、サードパーティの決済サービスの応答が遅いことが分かります。Sentry のエラーやトレースと照合することで、その遅延がどこで発生しているのか（APIの障害か、ネットワークの問題か、自分たちのコード内の何かか）を正確に特定でき、売上の損失が積み重なる前に修正できます。 私たちはこれまでに 40,000件のダウンタイムを検知しており、それらが大量のサポートチケットに発展する前に、チームが問題を特定できるよう支援してきました。 モニターは1つ無料でご利用頂けます。追加はモニター1つあたり月額1ドルです。HTTPメソッド、ヘッダー、ボディパラメータなど、リクエストの詳細を完全にコントロールし、特定のURLに対するカスタムアラートを作成できます。ぜひ試してください。詳細はブログでもご覧頂けます。 重複したエラーを掘り返すのはやめましょう エラー受信箱が多数の通知で溢れていても、それが本当に10件の異なる問題なのでしょうか。それとも同じ問題の50通りのバリエーションでしょうか。現在受信しているアラートが、実は過去に対応済みのエラーの再通知である可能性もあります。 このように終わりのないアラートの中で混乱するのではなく、Issue Grouping を活用することで、関連するエラーを自動的にグループ化し、イズを削減できます。その結果、本当に修正すべき課題に集中することが可能になります。 例えばアプリケーションの複数箇所で API が、500 Internal Server Error を返している場合でも、Issue Grouping（AI Grouping）は、それらが単一の根本原因によるものなのか、複数の独立した問題なのかを判別します。また、ステージング環境と本番環境をまたいでエラーをグループ化できるため、同じ問題を重複して調査する無駄を防げます。 […]
アプリがダウン？今すぐ復旧！Sentry アップタイムモニタリングをご紹介
Article by: Sasha Blumenfeld, Gabriel Lopes Sentry もダウンタイムとは無縁ではありません。実は私たちはかつて、誤ったマイグレーションによって自社のアプリケーションを停止させてしまったことがあります。重要なデータベーステーブルにフィールドを追加しようとしたところ、そのマイグレーションがテーブル全体をロックしてしまったのです。このテーブルは Sentry の動作に不可欠だったため、アプリ全体が停止してしまいました。ウェブサイトは読み込めず、データの取り込みも止まり… すべてが完全に止まってしまいました… 私たちはすぐに問題のクエリを特定して停止させましたが、もし主要なページにアップタイムモニタリングを設定していれば、もっと早く異常に気づけたかもしれません。これこそが、Uptime Monitoring を開発した理由です。 開発者が障害の原因を突き止めようと右往左往しているその1秒ごとに、ユーザーはページをリロードし、苛立ち、あるいは離れていきます。にもかかわらず、通常の対応プロセス（あるツールでアラートを受け取り、別のツールでログを調べ、何が起きたかを手作業でつなぎ合わせる）は遅くて苦痛を伴います。 私たちはトラブルシューティングの断片化が復旧を遅らせることを身をもって体験しました。だからこそ、障害が発生した瞬間に検知し、その修正に必要なコンテキストまで一か所で得られる仕組みを作ったのです。 Sentry の Uptime Monitoring は、単に「何かが落ちた」と通知するだけではありません。バグのあるコード、失敗したAPI、またはまったく別の原因かどうかを特定し、根本原因へと導きます。 Sentry Uptime Monitoringは、すべてのユーザーにご利用いただけるようになりました。すべてのプランに1つの無料モニターが含まれています。ユーザーが気づく前に、あなた自身でダウンタイムを検知しましょう。 Sentry の Uptime Monitoring Sentryはサイトの稼働状況を監視し、ダウンタイムが検出された際に通知します。 設定されたURLに対して60秒ごとに HTTP リクエストでヘルスチェックを行い、Web サービスを能動的に監視します。タイムアウト、DNS 解決エラー、不正なレスポンスなど、問題が検出されれば即座に通知されます。 9月末のベータリリース以降、すでに約10万件のアクティブなアップタイムアラートが作成されました。さらに、皆さまからの要望が多かった機能も多数追加し、より使いやすくなっています。 チェック履歴「すべてが崩れる前にサイトが正常に動いていた証拠があれば…」と思ったことはありませんか？今ならあります。チェック履歴を使えば、過去のアップタイムチェックを確認したり、パフォーマンストレンドを追跡したり、ダウンタイムと他の問題との関連を見つけ出すことができます。詳しくはこちら アップタイム問題詳細画面のUXを改善インシデント調査時により多くの情報が得られるよう、問題詳細ページを全面的に刷新しました。これにより、チェック履歴のタイムライン表示、すべてのアップタイムチェックのクイックビュー、関連リクエストのトレースビューにアクセスできるようになっています。 分散トレーシング対応アップタイムチェックが失敗したとき、探偵のように手がかりを追いかけたくはありませんよね。バックエンドサービスがSentry SDK でインスツルメントされていれば、リクエストのトレースをアップタイムチェックに自動的に関連付けます。そのため、必要なスパンや問題にすぐにジャンプでき、手作業で情報をつなぎ合わせる必要はありません。 地理的に分散されたチェック午前3時の誤検知ほど、気分を台無しにするものはありません。ダウンタイムの見逃しと不要なアラートの両方を減らすため、現在は複数のロケーションからアップタイムチェックを実施しています。異なる地域で3回連続してチェックが失敗した場合にのみ、ダウンタイムとして認識される仕組みです。そのため、本当に対応が必要なときだけ、アラートが届きます。 モニター設定の追加オプションすべてのサービスが同じではないように、モニタリングのニーズも一様ではありません。今では、各スタックに最適な形で、チェック間隔やタイムアウトの設定をカスタマイズできるようになりました。 よくあるダウンタイムの原因 — Uptime Monitoring がどう役立つか 壊れたコードのプッシュ 一見無害に思えた変更をプッシュした結果、システム全体が危機的状況に陥ったという経験を、誰しも一度はお持ちではないでしょうか。あるチームでは、非同期ジョブ内の単純な型エラーが原因で、購入処理用の配信システムがクラッシュし、あわや大惨事という事態になりました。1つのジョブだけが失敗するはずが、クラッシュによってキュー全体がブロックされ、以降のすべてのジョブが実行されなくなったのです。 そしておなじみの JavaScript の典型的なミスといえば、1ページを更新したつもりが、サイト全体を壊してしまうことです。ある開発者はそれを痛い形で学びました。テストではすべて問題なく見えていたにもかかわらず、ほんの小さな見落としが大きな混乱を引き起こしたのです。そのコードは、特定の要素が常に存在すると仮定し、すべてのページで実行されていました。nullチェックがなかったため、該当の要素が存在しないページは即座にクラッシュが発生しました。 このコードは、なぜかPRレビューと社内テストを通過してしまいました。というのも、テスト対象となっていたのは、更新されたページのみだったからです。 […]
Trace Explorer でスパンからメトリクス、グループ、アラートを取得する方法
Article by: Will McMullen どこかで、わずかに引っかかるアプリを開発した経験は、誰しも一度はあるでしょう。あるいは、どうしてもうまく最適化できないクエリに悩まされたことがあるかもしれません。Chrome の DevTools にあるネットワークウォーターフォールでは、その裏側で実際に何が起きているのかを完全に把握することは困難ですし、OTelによるトレーシング（正直に言えば、Sentryでのトレーシングも）も、やはり難解でした。 しかし本日から状況が変わります。私たちはトレーシングデータのための全く新しい Explore ビューをリリースしました。これにより、スパンデータを分類、絞り込み、並べ替えることで、パターンや具体的なトレース事例をこれまで以上に容易に見つけ出すことができます。 また、デフォルトまたはカスタムのスパン属性を使って、pXX（パーセンタイル）などのスパンベースのメトリクスを作成し、それをもとにアラートやカスタムダッシュボードウィジェットを構成することも可能となりました。 さらに、スパンをタイムスタンプ順に並べ替えることが、ついに可能になりました。ただし、これだけではありません。さっそく詳細を見ていきましょう。 ※この機能は Sentry のアーリーアダブタープログラムに参加しているすべてのセルフサーブ（自己登録）ユーザーに提供されています。まだ参加していない場合は、Sentry の設定画面から有効にしてください！ Sentry の Trace Explorer における新機能 アプリケーションがますます複雑化する中で、わずかなパフォーマンスの低下でも深刻なユーザー影響を引き起こす可能性が高まっています（最終的にユーザーの離脱という深刻な事態につながることもあります）。遅延の原因を簡単に特定できず、それを特定のサービス、エンドポイント、API、あるいはデータベース呼び出しに関連付ける手段がなければ、生のトレースデータを注意深く確認する（最悪の場合はログを手作業で確認する）必要があり、複数のツールに分断された断片的なデータを手動で追いかけることになります。 このような課題を解決するのが、新しい Trace Explorer です。スパンデータの活用方法が大幅に刷新され、以下の機能が追加されました。 スパンベースのメトリクススパン属性を集計し、p95(measurements.lcp) のようなメトリクスとして扱うことができます。これにより、パフォーマンスにおける境界ケースの検出や、大量の API ペイロードの追跡、さらにはアラートやダッシュボードの設定が可能となり、アプリケーションのシグナルを常に把握できるようになります。 クエリ可能なカスタム属性token_usage、region、cart_value など、アプリケーションに関連するカスタム属性をクエリおよび測定することが可能です。これにより、共通パターンを特定し、ユーザーにとって最も重要な体験に焦点を当てたアラートやダッシュボードを設計できます。 アクションにつながる Trace Explorerスタック全体にわたるトレースデータを迅速にフィルタリングおよびグループ化し、クエリを保存・共有することができます。「なぜチェックアウトページの読み込みが遅いのか？」といった問いに即座に対応できるだけでなく、どのユーザーが影響を受けているかもすばやく把握できます。 これらの機能は、パフォーマンスモニタリング・アラート・ダッシュボードの高度なセットアップを素早く構築できるように設計されており、トレースデータの価値を最大限に引き出すことができます。しかも、最小限のコストと構成で実現可能です。 技術的に見ても非常にスマートな仕組みですが、実用面においてはさらに高い効果を発揮します。ベータ版で多数の企業と連携を行う中で、以下のような代表的なユースケースが明らかになりました。 CDN画像のパフォーマンス分析image_url や cdn_provider のような属性を付加し、プロバイダー別に画像の遅延を並べ替えて分析できます。事前のメトリクス変換や処理は不要であり、クエリ実行時に動的に処理できます。 AI消費量の追跡APIコール数、トークン使用量、モデル名などを測定可能です。スパイクが発生した際には、対象のトランザクション、ユーザー、環境、リポジトリを正確に特定できます。 ECサイトにおけるチェックアウト追跡cart_value や payment_method といった属性を用いてチェックアウトフロー全体を追跡できます。これにより、高額な取引でパフォーマンスが遅延しているケースを特定し、即座にトリアージすることが可能です。 新しい Trace Explorer でスパンメトリクスを設定・活用する 1：重要な箇所にコードを計測挿入する（インストゥルメントする） Sentry […]