【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 — 何かが発生するたびに値を記録し、その分布を分析します。そのジョブはどれくらい時間がかかったか？ キュー内には何件アイテムがあったか？ 平均値だけでは実態が分からない場合に使います。
  
  
• Gauge — 現在値を継続的に追跡します。queue.depth、cache.size、active.connections のようなものです。ダッシュボードに表示したい種類の数値です。

これらすべてに属性を付与できます。ここが、多くのインフラ監視ツールとの違いです。そうしたツールは事前集計を行い、コンテキストを削ぎ落とします。一方で Application Metrics では、user.id、region、projectId などを付与すると、そのコンテキストを保持したままイベントが保存されます。そのため、distribution がスパイクした際にも、単なる数値を見るのではなく、「特定ユーザーが、特定リージョンで、特定プロジェクト上で発生させた数値」として確認できます。

スパイクをクリックして、トレースへ移動

完全なメトリクスイベントを trace ID とともに保存することで、メトリクスはより広いトレースベースのデバッグワークフローの一部になります。

メトリクスが予期しない閾値へ達した場合（たとえば未送信メールによってバックグラウンドジョブが滞留している、あるいは UI コンポーネントの読み込みに異常な時間がかかっている場合）、そのメトリクスからトレース、ログ、エラーへジャンプし、Pager が鳴ったタイミングで実際に何が起きていたのかを全体像として把握できます。

• React コンポーネントの読み込み時間を測定する distribution がスパイクしているタイミングで、429 エラーがループ発生していないか？
• キュー深度を測定する gauge が増加しているタイミングで、上流のメールサービスが遅延していないか？

Session Replay のバグ調査で実際にどう使ったか

Session Replay の問題を調査するため、私たちはまず、読み込まれた動画セグメント数を追跡する distribution を追加しました。そこには、高カーディナリティ属性である projectId も含めました。

以下が、Replay 内の動画セグメント追跡を開始するために追加したコードです。

詳細については、getsentry/sentry#114001 を参照してください。

私たちは replayId と projectId を scope 上の属性として付与し、イベント数の多いケースを特定のプロジェクトや Replay に絞り込めるようにしました。問題の再現が難しい状況だったため、この情報によって問題発生の瞬間を直接捉え、特定の組織まで遡って追跡できるようにしたのです。

これによって、私たちはすぐに2つのことを把握できました。

• 問題の発生は稀で、過去1週間でわずか7件だったこと
• 影響を受けたユーザーを正確に特定できたこと

そこから、それらのセッションを追跡し、問題を再現し、修正できました。

さらに、各メトリクスイベントには trace ID が含まれているため、私たちはより深く調査できました。ユーザーが 1,000 を超えるフレームを読み込んだ際に、具体的に何をしていたのかを確認するため、ターゲットを絞ったログを追加しました。たとえば、動画をシークしていたのか、短時間で多数の動画を連続読み込みしていたのか、といった情報です。

次に replay.videoEventCount が 1,000 を超えた際には、関連付けられたトレースへジャンプし、ログ行を確認することで、バグ修正に必要なコンテキストを把握できました。

メトリクスとその他の機能の違い

メトリクスは、エラー、トレース、ログを置き換えるものではありません。メトリクスは、「アプリケーション内の重要で、意味が明確なイベントを、高い精度で継続追跡する」という特定の役割を担います。

すべてのイベントをメトリクス化する必要はありません。調査段階ではログが非常に有効です。しかし、長期的に追跡したいシグナル、つまりアプリケーションの健全性を示すものを見つけたなら、それをメトリクスに変えるべきです。

適した例としては、コード実行に紐づくビジネス KPI（payment.declined、search.zero_results）、アプリケーション健全性指標（job.retried、email.failed）、リソース利用状況（queue.depth、cache.hit_rate）、そしてアラート対象にしたい成功率・失敗率などがあります。

一方で、CPU やメモリのようなインフラメトリクスには適していません（インフラ監視ツールを使うべきです）。また、フォレンジック目的のデバッグには Sentry Logs、リクエスト単位のパフォーマンスや接続状況には Sentry Tracing が適しています。

まずはチームが最初に確認するメトリクスから始める

すべての Sentry プランには、5GB の Application Metrics が含まれています。最近の SDK バージョンを利用していれば、すでに使用可能です。

何か問題が起きたときに、チームが最初に確認するシグナルを1つ選んでください。checkout.failed かもしれませんし、queue.depth や deployment.duration かもしれません。

そのメトリクスをインストルメントし、必要な属性を付与します。user、project、region など、そのメトリクスを分析する際に必要なものです。そしてアラート閾値を設定してください。

アラートが発火したら、トレースへ移動し、スパイク周辺のコンテキストを確認して、問題を修正できます。

Application Metrics の無料トライアルは Explore > Metrics から開始できます。または、Application Metrics ドキュメントを参照してください。