【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 — 何かが発生するたびに値を記録し、その分布を分析します。そのジョブはどれくらい時間がかかったか？ […]