【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: Lukas Stracke ブラウザのトレーシングは、うまく機能しているあいだは「存在を感じさせないもの」です。しかし、一度それがうまく動かなくなると、たちまち強烈な存在感を放ちます。トレーシングが正しく機能していれば、実環境におけるアプリケーションの挙動を明確に把握でき、具体的で行動につながるインサイトが得られます。一方で、トレーシングがうまく機能していない場合、そこにあるのはノイズだらけのデータ、欠落したトレース、そして何も語ってくれないスパン。つまり、何の手がかりも得られない状況です。私たちはここ数か月、この問題に少しずつ取り組み、着実に改善を重ねてきました。 ここでは、Sentry の JavaScript SDK に施した改善を順に見ていき、ブラウザトレーシングを「より正確にする」だけでなく、「より有用にする」ための取り組みをご紹介します。ページロードスパンを明示的に制御できるようにすることから、リダイレクトのより賢い取り扱い、リソーススパンにおけるより深いタイミングデータの追加まで。これらの更新は、推測を減らし、本当に重要なものを前面に出すことに主眼を置いています。 ページロードスパンを明示的に終了する 提供開始：10.13.0 私たちの SDK では、規定でページロードやナビゲーションのスパンは「アイドルスパン」として開始されます。このアイドルスパンは、子スパン（例：fetch リクエストのスパン）が継続的に開始・終了されるかぎりアクティブな状態を維持し、一定時間アクティビティが途絶えると自動的に終了します。 なぜこの方式なのでしょうか。それは、「ページが完全に読み込まれた」と言える普遍的な指標が存在しないからです。 初回レスポンスの受信後でしょうか。すべてのスクリプトやリソースのロード完了後でしょうか。それともアプリケーションのハイドレーションやブートストラップ完了後でしょうか。 たしかに、ブラウザには domContentLoaded や readyStateChange のようなシグナルも存在しますが、初期の体感的なページロードに関わる処理がその後に続くケースも少なくありません。現実として、フレームワークや Web アプリの多様性、そして一般的な JavaScript のカオスを踏まえると、この問いに万能な答えはありません。 私たちのアイドル化とデバウンスの仕組みは、ユーザーの 95% にとって十分に機能しており、概ねページロードの所要時間に納得いただけています。しかし一部のユーザーからは、「ページの読み込み完了をアプリケーション側から Sentry に明示的に通知したい」という要望も寄せられていました。そこで用意したのが、Sentry.reportPageLoaded() です。 enableReportPageLoaded: true と Sentry.reportPageLoaded() を併用すると、アイドル機構の大部分が取り除かれ、代わりにユーザーが完全に制御できるようになります。 コールバック外でのアクティブなスパン 提供開始：10.15.0 バージョン 8 で NodeJS SDK に OpenTelemetry を導入した際、私たちは旧来のトランザクション中心の API を新しい […]
【Session Replay】自分自身がデジタル上のシークレット・ショッパーになる
Article by: Kyle Tryon 本ブログの内容 リアルな顧客インサイトのために Session Replay を有効化する チェックアウト離脱とカート放棄の原因を診断する Session Replay を使って放棄カートを Sentry で確認する 自分のショップを次のステップへ 小売店が長年にわたってショッピング体験の測定と改善のために頼ってきた秘密兵器… それが「シークレット・ショッパー」です。 彼らは一般の客を装い、顧客体験を評価します。たとえば見つけにくい商品の特定、接客品質の評価、チェックアウトプロセスのスムーズさなど、摩擦が生じる箇所を見つけ出します。彼らが収集するデータは、偏りのない実践的なフィードバックの代理として機能し、店舗運営者はそれを基に顧客体験を改善し、コンバージョン率を高め、平均注文額を増やします。 しかし、eコマースでは小規模なサンプルや代理顧客に頼る必要はありません。Session Replay （セッションリプレイ）のようなツールを使えば、実際の購買者の行動を大規模に分析できるのです。さらに、ユーザーのセッションを「再生」して、彼らが実際に見たものをクリックごとに正確に確認することもできます。 リアルな顧客インサイトのために Session Replay を有効化する Session Replay は、ユーザー体験をまるで動画のように再現し、その時に発生したログ、エラー、トレースなどの関連情報をすべて紐づけて記録します。これにより、ユーザーが実際にどのような体験をしているのかを、当時のコンソールログなどと突き合わせながら確認することができます。 これは、ユーザー自身に報告を依頼せずに問題を診断できる非常に優れた方法です。詳細な説明やスクリーンショット、動画を求める代わりに、実際に何が起きたのかをそのまま見ることができるのです。 しかも、これは単なるエラーデバッグツールにとどまりません。「どこで迷い、どこで操作フローが途切れ、デザイン上の選択が体験にどう影響しているか」といったユーザーの行動パターンを可視化することもできます。 導入をするには、まず自分のオンラインストアのフロントエンドフレームワークに対応する正しい SDK を選び、Replays 機能を有効化した状態で Sentry を追加します。もし Shopify の Hydrogen を使ってアプリを開発している場合は、React Router SDK を利用することができます。 以下は、ご自身のアプリに簡単に組み込めるシンプルな React のセットアップ例となります。 エラー発生時や通常のセッションなど、状況に応じて Session Replay のキャプチャ率（録画割合）を個別に設定 […]
ベータ期間中に Sentry のユーザーフィードバックウィジェットを使って Logs を形作った方法
Article by: Jasmin Kassas Sentry では、私たちは公開の場で開発を行い、迅速に対応しています。しかし、スピードを重視することで、最初の試みで全てがうまくいくとは限りません。そこで役立つのがフィードバックです。フィードバックはうまくいっている点を検証し、不足している部分を特定し、エラートラッキングだけでは把握できない問題を明らかにする助けになります。 数か月前に Logs のベータ版をリリースしたとき（ちなみに先週 GA になったのでぜひご覧ください）、私たちはエラーやパフォーマンス監視だけでは明らかにならないもの（壊れているのに気付かれないもの、静かに失敗しているもの、あるいは単にユーザーを混乱させているもの）を見つける方法が欲しいと考えていました。そこで、Sentry のユーザーフィードバックウィジェットをプロダクトにそのまま組み込みました。 つまり、開発者がつまずいたとき、そのフィードバックにはリリースバージョン、環境、URL、さらには実際に起こったことのセッションリプレイといった、私たちに必要なすべてのコンテキストが付随していました。 その結果、Logs はより速く進化し、信頼性が高まり、開発者（私たち自身を含む）が実際に使いたいと思えるものへと変わりました。 フィードバックを機能と修正に変える ユーザーフィードバックウィジェットは単なる意見収集の箱ではなく、Logs ベータ期間中に私たちが実際に出荷したものを形作りました。 明確な例のひとつが 自動リフレッシュ機能 です。開発者から「ログストリームを自動的に更新してほしい」という要望が繰り返し寄せられていました。私たちもそれが重要であることは認識していましたが、優先順位を上げるには至っていませんでした。しかし、タグ付きのフィードバック提出が積み重なっていくうちに（製品固有のフィードバックを素早く確認するには、URL タグでフィルタリングしています）、その継続的なシグナルが優先度を押し上げました。そして、4週間でフィードバックから機能へと進化し、現在では稼働中の自動リフレッシュ機能をリリースするに至りました。 また、アラート機能に対する強い要望も寄せられました。これを受けて、ログベースのアラートをサポートし、認証エラーや設定の欠落といった重要なログが現れたときにユーザーへ通知できるようにしました。 しかし、このウィジェットは製品リクエストのためだけのものではありません。最も重要なのは、エラートラッキングだけではすぐに明らかにならなかった重大な SDK の問題を表面化させてくれた点です。それによって、私たちは次のような問題を特定し、解決することができました。 Python SDK のバグ：ログ属性を正しく収集していなかった。Python 標準ライブラリのロガーとのログ統合を最初に実装したとき、生成されたログメッセージに名前付きパラメータを付与していませんでした。この API がそのようにも利用され得ることを、ユーザーから指摘を受けるまで気付いていませんでした。 JavaScript SDK の問題：特定のオブジェクトのシリアライズが原因で、ログメッセージが正しくレンダリングされないことがありました。これは、JavaScript SDK でコンソール計測を通じて生成されたログを作成する際に、文字列を連結する方法に起因していました。修正自体は単純でしたが、[Object Object] が紛れ込んでしまうのは簡単だということを思い出させるものでした。 JavaScript SDK のより深刻なバグ：環境とリリースの属性がログに正しく付与されない問題がありました。原因は単純で、これらの属性をログに付与する際に正しいフォーマットを使用していなかったことです。しかし、私たちのプロダクトはリリース値や環境値をトップレベルのフィルタやデータの関連付けに依存しているため、ユーザーにとって多くの問題を引き起こしました。 フィードバック提出には、環境、組織ID、プロジェクト名、URL といった技術的なコンテキストが含まれていたため、私たちはサポート対象プラットフォーム全体に修正を出荷し、Logs をより信頼性の高いものにすることができました。その結果、Logs はフロントエンドの体験においても、基盤となる SDK インフラにおいても、開発者が期待する通りに動作するようになりました。 […]
Sentry Logs 一般提供開始（ログはログ…でもついに実用化）
Article by: Dhrumil Parekh 本ブログの内容 何も壊れていないように見えても、裏で起きていることがわかる ジョブの実行（あるいは失敗）をリアルタイムで監視 UI のリグレッションが雪だるま式に膨らむ前に検知 これまでの反響は？ Logs の始め方 私たちが Sentry に Logs 機能を構築し始めたとき、目標は一つでした。それは、単なる大量のテキストストレージではなく、実際のデバッグに役立つものにすることです。そのために、初日から「トレースと接続」させることにしました。 これにより、アプリケーション内で発生するアクションやパフォーマンスとログを密接に結びつけ、開発者がエラーやパフォーマンス、レイテンシの問題を調査するまさにその場所で活用できるようにしたのです。 現在、Logs はベータ版を終了し、すべてのユーザーに一般公開されました。さらに嬉しいことに、ベータ期間中に皆さんから要望のあった数多くの機能を追加しています。 ライブテーリング（Live Tailing）：ログをリアルタイムにストリーミングし、修正の確認、長時間実行されるジョブの監視、または問題が発生した瞬間の特定に利用できます。 アラート（Alerts）：特定のログパターン（例: 繰り返される payment_status=declined）に基づいてトリガーし、ユーザーが報告する前に失敗を把握できます。 ダッシュボード（Dashboards）：ログの傾向を時系列で可視化します。たとえば Safari でのエラーレートの上昇や、新しい機能フラグに関連する突然のスパイクを確認できます。 チェックアウトの失敗、不安定なジョブ、ページロードの遅延。どんなデバッグであっても、Logs は重要なコンテキストを提供します。そして、それらの Logs が他のテレメトリー（トレース、エラー、リプレイ）と結びつけば、根本原因をより早く突き止めることができます。タブの切り替えも、タイムスタンプの計算も不要。ただ答えがあるだけです。 ここからは、Logs がどのようにして面倒な問題のデバッグを簡単にするのか、その実例をご紹介します。あるいは、今すぐドキュメントを参照してログ送信を始めて頂いても構いません。 何も壊れていないように見えても、裏で起きていることがわかる トレースと接続されたログは、見過ごされがちなサイレントな失敗を見つける フロントエンドは checkout.request を送信し、バックエンドは 200 を返し、問題は記録されません。例外も投げられません。 しかし、ユーザーは注文確認を受け取っていないと報告してきます。 Sentry でトレースを開くと、checkout.request のスパンは正常に見えますし、処理は成功しています。しかし、本来その後に続くはずの非同期処理 order.processed のスパンがありません。 checkout.request のスパンをクリックすると、そのスパンにスコープされたログが表示されます。 […]
【ダッシュボードのアップデート】クリック数削減、操作性向上、ウィジェット作成の高速化
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 […]