【Sentry Snapshots ベータ公開】スナップショットテストでビジュアルリグレッションを検出
Article by: Max Topolsky（読了時間：6分） 要約 — Sentry Snapshots がベータ公開されました。（英語記事公開日2026/6/11）CI でスクリーンショットの差分を検出し、意図しないビジュアルの変更を検知、フロントエンドを持つあらゆるプラットフォームに対応。まずはSnapshots のドキュメントから始めてください。 Sentry Snapshotsは、コミットのたびにスクリーンショットを比較し、表示内容に変更があった場合はPRをブロックして、その変更が意図したものかどうかを確認できます。ユーザーが実際に目にし、操作するのはコードではなくアプリケーションです。Snapshotsは、そのユーザー体験を手軽に検証するための仕組みです。 コードの変更はかつてないほど簡単になりましたが、同時に、スピードのために品質を犠牲にする可能性も高くなっています。現代のコードベースには、正しさを担保するためのガードレールが必要です。Snapshots でめざしているのは、コードへのチェック機能と、ワークフローを改善するためのリソースを提供することです。 スナップショットテストとは スナップショットテストの基本的な流れはシンプルです。 コードを変更する アプリケーションのスクリーンショットを生成する そのスクリーンショットをベースラインと比較する 変更箇所を表示する Sentry Snapshots では、スクリーンショットをアップロードすると差分を比較し、差分があれば PR にコメントします。 その後 UI に移動して、具体的にどのような変更があるかを確認できます。 このシンプルなワークフローにより、ビジュアルのカバレッジという新しい軸が加わり、異なるテーマ・言語・ビューポートでアプリケーションが期待通りに表示されているかをテストできます。スナップショットテストは、意図した以上の変更が行われていないかを検証します。 Sentry Snapshots とエージェントの連携 従来からビジュアル変更に対するガードレールとして利用されてきたスナップショットテストは、AIエージェントによる開発でも特に有効です。たとえ雑なプロンプトでエージェントが変更を加えたとしても、スナップショットテストを実行し、変更が検出されればPRをブロックできます。 しかし Snapshots はエージェントが「活用する」アーティファクトにもなり得ます。最近、Snapshots 自体のビジュアル変更を行う際に Snapshots を活用した流れをご紹介します。 課題 複数のユーザーから「Snapshot Toolbar」に関して似たようなフィードバックが寄せられていました。 最初に表示される赤い「差分マスク」の意味が分からない マスクを非表示にしたいが方法が分からない（実際には可能） 差分ビューを切り替えたいが、操作方法が見つからない 要するに、既存機能の見つけにくさが課題でした。 […]
ダッシュボードをエージェントで作成・編集する新しい方法
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 は […]
【モンキーパッチはもう不要】Tracing Channels による、より優れたオブザーバビリティ
Article by: Sigrid Huemer ほとんどすべての本番アプリケーションは、さまざまなツールやライブラリを利用しています。たとえば、データベースやキャッシュと通信するためのライブラリ、あるいは Nest.js や Nitro のようなフレームワークです。本番環境で何が起きているのかを把握するために、アプリケーション開発者は Sentry のような APM（Application Performance Monitoring）ツールを利用します。 しかし、そこには本質的な問題があります。APM ツールが必要とするパフォーマンスデータは、多くの場合、ライブラリ自身からネイティブに提供されていません。そのデータ取得は、Sentry や OpenTelemetry のような APM ツール側へ委ねられており、それらが代わりにライブラリの重要な機能へインストルメンテーションを行っています。 インストルメンテーションとは？ アプリケーションを観測可能にするための最も基本的な要件は、その各コンポーネントや利用ライブラリをインストルメントできることです。インストルメンテーションとは、プログラム内部の動作を監視・分析し、診断データを生成するためのコードを追加するプロセスを指します。Sentry SDK や OpenTelemetry のインストルメンテーションは、まさにこの処理を内部で行っています。 たとえば、一般的な HTTP クライアントライブラリを考えてみましょう。アプリケーション開発者は、リクエストの開始と完了のタイミング、さらに URL、ステータスコード、ヘッダーといったメタデータを知りたいと考えます。 現在、ライブラリごとにこの対応方法は統一されていません。emitter.on(‘request’, …) のような独自フックを提供するものもあれば、リクエストを横取りするためのベンダー固有ミドルウェアを提供するものもあります。こうした場合、Sentry や OpenTelemetry は、オブザーバビリティデータを送信するプラグインを実装できます。 これは機能しますが、その負担はライブラリやフレームワーク側（たとえば Nuxt）にかかります。つまり、インストルメンテーション用 API を意識的に設計し、どこでそれを公開するべきかを判断しなければなりません。フックやインターセプタによって、適切な場所へオブザーバビリティコードを差し込める一方で、APM のメンテナーは、その API が将来にわたって安定して維持されることをライブラリ作者に依存しています。 さらに、共通規約も存在しません。ライブラリごとにフックの形もメタデータも異なるため、APM メンテナーはライブラリごとに大きく異なるプラグインを実装・保守し続ける必要があります。 サーバーサイド JavaScript はどのようにインストルメントされているのか JavaScript における従来のインストルメンテーション手法は「モンキーパッチ」です。これは、ライブラリのコードを実行時に書き換え、本来の処理に加えてオブザーバビリティデータも送信するようにする方法です。この手法が可能なのは、モジュールが変更可能で同期ロードされる CommonJS（CJS）環境に限られます。 […]
【Application Metrics】シグナルを追跡し、スパイクを把握し、トレースへジャンプする
Article by: Ben Coe 要約：Application Metrics をリリースしました。これは、アプリケーション内の重要なシグナルを追跡するための新しい仕組みです。コンテキスト付きでユーザーの状況を把握し、問題がエラー化する前に検知できるようになります。 数週間前、私たちは Session Replay に関するバグに遭遇しました。1,000 を超える動画セグメントが読み込まれると、一部ブラウザで Replay が失敗していたのです。しかし、それがどの程度発生しているのか、誰に影響しているのかが分かりませんでした。さらに、この障害は必ずしもエラーを生成するわけではなかったため、影響を受けたユーザーを特定して再現する手段もありませんでした。 以前であれば、span やログを使って調査していたでしょう。しかしそれでは扱いづらい面があります。span はサンプリングされることが多く、外れ値を見逃す可能性があります。ログは構造化が弱く、時間とともに内容が変化しやすいものです。どちらも調査用途には向いていますが、既知の振る舞いを継続的に追跡するには、メトリクスのほうが適しています。 そこで私たちは、Sentry SDK 内で user 属性と provider 属性付きのメトリクスを設定し、1,000 セグメントを超えるセッションをフィルタリングしました。その結果、数分で再現ケースを特定できました。 これこそが、Application Metrics の役割です。追跡したいシグナルを記録し、あとで必要になるかもしれないコンテキストを紐付けておくこと。何か問題が起きたときには、必要なデータがすでにそこに揃っています。 事前集計されたカウンターではなく、完全なイベント インフラストラクチャテレメトリの追跡向けに設計されたメトリクスツールは、多くの場合、データを集計します。その過程で、ユーザー、IP アドレス、リージョンといった情報は削ぎ落とされます。残るのは単なるカウンターです。 Sentry の Application Metrics は、user のような高カーディナリティ属性を含む完全なイベントを保存します。そのため、「アプリケーション全体でチェックアウト体験が遅かったか」だけではなく、「東海岸のユーザーに対してチェックアウト体験が遅かったか」や、「特定ユーザーのスケジュールジョブがキューの滞留を引き起こしていたか」といった問いにも答えられます。 同じ SDK、コード1行で利用可能 最近の Sentry SDK を使っていれば、メトリクス機能はすでに有効化されています。新しい依存関係やサイドカーは不要です。必要なのはコードを1行追加するだけです。 主に使うことになるメトリクス型は、次の3つです。 Counter — 何かが発生するたびに数値を加算します。payment.declined、search.zero_results、email.failed のようなものです。アラート対象にしたい発生率や合計値の追跡に向いています。 Distribution — 何かが発生するたびに値を記録し、その分布を分析します。そのジョブはどれくらい時間がかかったか？ […]
【Size Analysis】Sentryで提供開始
Article by: Max Topolsky, Steve Zegalia Sentry は 2025年5月に Emerge Tools を買収しました。これにより開発チームに最適なモバイルツールを提供する準備が整いました。そして主力製品の1つである Size Analysis を正式にすべての Sentry ユーザーに提供を開始しました。これで、アプリサイズをもう心配する必要はありません。 CI パイプラインでの自動監視 アプリサイズが増えていく最も一般的なパターンは、少しずつ積み重なっていくことです。小さな変更が時間とともに蓄積し、気づけばモバイル通信でのダウンロード上限を超えているという警告が出るようになります。そうした小さな変更は、加えた時点であれば簡単に最適化できますが、1年後に対処しようとすると、途端に難しい作業になります。 Size Analysis は CI ワークフローに統合できるため、アプリサイズの状態を継続的に把握できます。すべてのビルドをアップロードして差分比較できます。サイズに変化があったときは、単に変わったことがわかるだけでなく、なぜ変わったのか、さらにサイズを小さくするために実施できる推奨修正があるかどうかまで確認できます。 よくあるシナリオを見てみましょう。SDK を追加する場合です。 ここに、Kingfisher を追加した際のステータスチェックがあります。Size Analysis を使うと、すぐに次のことがわかります。 この PR により、ダウンロードサイズは約500 kB、インストールサイズは約1.5 MB増加しています。 この PR が失敗したのは、「Install Size の差分が 1 MB を超える場合はチェックを失敗させる」という事前設定済みのしきい値があったためです。 「Comparison Page」を確認すれば、差分が想定どおりであることを確かめたうえで、PR を承認できます。このページでは全体のサイズ変化だけでなく、サイズが変化したすべてのファイルを表形式とビジュアルの両方で確認できます。 この場合、これは意図した差分であることが明らかなので、ステータスチェックを承認し、PRをマージできます 🎉。 次のシナリオを見てみましょう。新しいヒーローイメージを追加する場合です。 全体のサイズ差分は今回も確認できますが、今回は2つの Insights […]
【Sentry サンプリング戦略】すべてを見ようとすると結局なにも見えなくなる
Article by: Kyle Tryon 要約：一律のサンプリングレートは無駄や非効率につながることがあります。独自のサンプリングロジックを用いて、ノイズを減らしつつ100%のシグナルをキャプチャし、アプリケーションの監視方法を細かく調整しましょう。 高トラフィックの本番環境では、テレメトリはユーザー体験への最も直接的なリンクです。Sentry に送られるすべての Span、Trace、Log、Replay は、本番環境で実際に何が起きているのかを高い精度で可視化してくれます。 しかしその可視性から最大限の価値を引き出すには、シグナルとノイズをどう切り分けるかを理解しておく必要があります。安定したレガシールートにおける通常の「ページ読み込み」を、チェックアウトフローや新機能リリースのような重要な体験と同じ強度で扱っていては、収集するデータを最適化できているとは言えません。 スケールしても持ちこたえ、クォータも圧迫しないオブザーバビリティ戦略を構築するには「一律サンプリング」を超えていく必要があります。重要な箇所や変化の速い箇所では高解像度のデータを優先し、安定しているシステムでは設定を最適化する必要があります。 すべてを100%サンプリングすればいいのでは？ 可能です！ アプリが小規模だったり、まだ新しかったりするなら、それが実際に正しい方針である場合もあります。しかしスケールしていくにつれ、「すべてを100%」はたいてい現実的な選択肢ではなくなります。 理由はいくつかあります。 シグナル対ノイズ（Signal-to-Noise）: テレメトリデータはひと目で何が起きたかわかるときに、より役立ちます。チェックアウト中にユーザーが問題を経験した100件を見つけるために、100万件の「ユーザーがボタンをクリックした」span を解析しなければならないのは、あなたにとっても、クエリにとっても、そして私たちと同じ情報を利用する可能性のあるLLMにとっても、効率的ではありません。 ネットワーク負荷（The Network Footprint）: SDKは高度に最適化されていますが、あらゆる操作、あらゆる関数呼び出しは、積み重なると負荷になります。必要なものだけをサンプリングすることで、価値ある情報を収集しながら、高いパフォーマンスを維持できます。 基本の調整項目：静的サンプルレート Sentry を初期化する際には、送信するデータ量を調整するための主要なオプションが4つあります。まず最初のステップはそれぞれがどう連動するのかを理解することです。 sampleRate：エラー向けです。何かが壊れたら、毎回必ず把握したいので、私たちはほぼ常にこれを 1.0 のままにしています。 tracesSampleRate：トラフィックの一断面を取得します。パフォーマンスデータの量を管理するための主要な調整レバーです。 replaysSessionSampleRate：セッション開始時点から、セッション全体を記録します。高精細（high-fidelity）なので、通常は「平均的な」ユーザーがどうナビゲートしているかを見るには、ごく小さい割合で十分です。 replaysOnErrorSampleRate：バッファです。エラーが発生した場合にのみリプレイを送信し、エラーに至るまでの 60秒間 のアクティビティを記録します。 精密な制御：tracesSampler Trace は私たちが持つ指標の中でも特に重要である可能性が高く、パフォーマンス監視、エラー監視、そしてすべてのデータを相互に結びつける役割を担っています。本番環境では、トレースの100％をサンプルすることがほとんどの場合推奨されます。しかし、特にトラフィックが非常に多いアプリケーションでは、戦略的にトレースするのであれば、すべての Trace を収集する必要はありません。 一律の割合を指定する代わりに、Sentry では tracesSampleRate に tracesSampler 関数を渡せます。これにより、リクエストのコンテキストに基づいて、リアルタイムに判断を下せるようになります。 […]
正常に見えるダッシュボードに潜む危険信号
Article by: Milin Desai 最近、ある企業の開発責任者（会社名は出せないのですが）からこんなふうに言われました。 「あなたのおかげで、本当にユーザーに影響を与える問題を見つけて解決できました。次は、それが標準的な SLO やシステム指標よりも重要だということを CTO に納得してもらう必要があります。」 CTOがシステムと基本的な稼働時間を測定するのは間違いではありません。ただ、それは基準線にすぎません。だれもがあらゆるものを監視しようとしていますが、ユーザーに関係することについては何も見えていないのです。 従来型モニタリングの罠 稼働率は素晴らしい。レイテンシはSLOの範囲内。エラーバジェットも問題ない。ダッシュボードは緑一色。 それでも、ユーザーはまだ失敗しています。システムが落ちているからではありません。システム自体は問題ないのです。けれども「ユーザーがボタンをクリックする」から「ユーザーが欲しかった結果を得る」までのどこかで、何かが壊れました。静かに。 アラートは出ない。しきい値も超えない。ただ、ユーザーが諦めて離脱しただけです。 コードは壊れます。そこが問題の核心ではありません。問題は、それが3週間後に発覚することです。大口の顧客が苛立って離脱しそうになり、営業チームがエスカレーションして初めて分かるのです。 マネーモーメント どのプロダクトにも「マネーモーメント」がいくつかあります。ユーザーが成功できるか、あるいは収益を失うかを左右する、プロダクト内の特に重要なポイントです。「APIは落ちていないか」でも「ページは読み込めたか」でもありません。ユーザーが本当にやりに来た「その行為」のことです。 最近聞いた例をいくつか挙げます。 ある小売企業はブラックフライデーを完璧な稼働時間で乗り切りましたが…コンバージョン率が12%も下がってしまいました。マネーモーメントである「購入手続きの完了」が、特定のブラウザ拡張機能を使っているユーザーで機能していませんでした。サーバーエラーはなし、アラートもなし。3週間分の売上を失いました。修正にかかったのは1時間ですが、問題に気づくまでには非常に長い時間がかかりました。 ある決済企業はすべてのSLOを満たしていましたが…顧客から「ランダムに失敗する」という苦情がありました。マネーモーメントである「送金が実際に完了し、確認まで終わること」が、国際送金では断続的に失敗していたのです。原因はタイムアウトのエッジケースで、ダッシュボードには平均値しか表示されていませんでした。影響を受けていたのはユーザーでした。修正は6行のコードで済む内容でしたが、何か月分ものノイズの下に埋もれていました。 あるB2Bプラットフォームはどの指標でも健全に見えていましたが…ところが、マネーモーメントである「新規顧客が“なるほど”と実感する瞬間」が、特定の設定を持つエンタープライズアカウントで壊れていました。監視より先に営業がそれを見つけました。ダッシュボードはどれもシステムが「稼働中」だと言っていましたが、プロダクトは壊れていたのです。 毎回、同じパターンです。 測っている対象が間違っています 違いはこうです。 多くのチームが測っていること すべてのサービスは動いているか 指標はしきい値の範囲内か システムは健全か 本当に重要なこと ユーザーは目的を達成できたか できていないなら、どのコードが壊れたのか どれだけ早く直せるか 前者は横方向です。あらゆるものを監視して、何かを拾えることに期待する。 後者は縦方向です。マネーモーメントをエンドツーエンドで追う。壊れたらすぐに分かる。リリースまでたどる。修正する。 両方を行うこともできます。もしダッシュボードが緑でもユーザーが失敗しているのであれば、何が欠けているかがわかります。 実践するべきこと 複雑ではありません。 マネーモーメントに名前を付けましょう50もの異なるフローではなく、プロダクトが機能するかどうかを左右する3〜5つのポイントを特定してください。ユーザーにとって重要で、彼らが目的を達成できるかどうかを左右する瞬間です。ユーザーが成功する瞬間、離脱する瞬間はどこでしょうか。 セグメント別に監視しましょう平均ではなく、顧客ティア別、地域別、デバイス別、リリース別です。最大の顧客を混乱させるバグは、集約されたメトリクスには現れません。 リリースと結びつけましょうマネーモーメントが失敗した場合、最初にすべき質問は「何が変わったか」です。数分で答えられないようであれば、目を閉じたまま飛んでいるようなものです。 アラートまでの時間ではなく、修正までの時間を測りましょう誰もダッシュボードがどれだけ早く真っ赤になったかには関心がありません。壊れたコードをどれだけ早く発見し、修正をリリースできたかが重要です。 […]
【LogTape & Sentry】トレースに紐づく構造化ログ
Article by: Kyle Tryon アプリケーションがちょっとした個人開発から、多くのユーザーに使われる複雑な分散システムへと成長していくにつれて、従来の console.log に頼ったデバッグ手法では通用しなくなります。本当に観測可能なシステムを構築するには単なるテキストログから、構造化されクエリ可能で、トレースに紐づくイベントへと移行していく必要があります。 要点：ログ戦略の転換 多くの人はログをパンくずのように扱い、各行が実行されたことを確認したり、デバッグのために出力結果を記録したりします。ところが本番環境では、そのパンくずはすぐにノイズの山になります。必要なのは処理の過程を逐一ログに残すやり方から、マイルストーンをログに残すやり方へ切り替えることです。 ノイズを取り除く：ノイズを生み、クエリや相関が難しい「薄い」ログから離れましょう。 高カーディナリティを受け入れる： タスクの進行に伴って積み上がる「厚い」コンテキストをログに詰め込みましょう。ユーザーID、注文ID、カート情報などを含め、任意のイベントについて必要なデータをクエリできるようにします。 点をつなぐ： Sentry を使ってログをトレースに紐づけたままにし、各ログをそれを引き起こした特定のリクエストへ紐づけます。 ログの洪水：なぜ本番環境では console.log が通用しないのか ログが集中管理されなくなり、時系列で追えなくなった瞬間に console.log は破綻します。複数のユーザーとサービスが同時に動く本番環境では、ログはすぐにさまざまなイベントが入り混じったストリームになってしまい、特定の1リクエストについて何が起きたのかを復元する明確な手がかりがなくなります。 関連するログ同士をつなぐ共通のトレースと、フィルタ可能で有用なデータがなければ、こうしたログは本番環境では実質的に役に立たなくなります。 LogTape と Sentry で本番品質のロギングを実装 Sentry はトレースに紐づくロギングを提供します。トレースを使えば、1つのリクエストに関する全体のコンテキスト（そのリクエストに紐づくログも含む）を確認できます。これにより特定の issue やリクエストに関連するトレースとログを簡単にクエリできるようになります。 さらに Sentry Logs には、属性や構造化データをもとにログを検索できる強力なクエリエンジンがあります。そこから検索結果に基づいてアラートやダッシュボードを作成することも可能です。 LogTape はあらゆる JavaScript ランタイム向けの軽量なロギングライブラリです。LogTape のようなロギングライブラリを使うと、コードに計測を組み込み、自動でリッチな構造化ログを出力できるようになります。また「log sink」を使って、それらのログを Sentry に送信できます。 構造化ログとは、単なる文字列ではなく、定義されたプロパティを持つ構造化オブジェクトとしてログを扱う形式です。 これにより本番環境でのデバッグにおいて、ログから必要なデータを見つけて可視化するための強力なクエリやフィルターを作成できます。 LogTape の構造化ログマニュアルからの例 クイックスタート：Next.js […]
【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 […]