ラーニングセンターで RUM 保持フィルターを試す
RUM 保持フィルターを使用して、保存するセッションデータを制御し、オブザーバビリティの予算を最適化する方法を学びます。
概要
RUM without Limits を使用すると、すべてのセッションデータをキャプチャしながら、組織にとって価値のあるセッションのみを保持できます。このツールは、セッションデータの取り込みとインデックス作成を分離することで、データ管理を強化します。
主な機能
- 動的保持フィルター: コードを変更することなく、保持するデータを調整します。
- 包括的なメトリクス: メトリクスはセッションの 100% を反映し、完全な可視性を確保します。
- ターゲットを絞ったセッション保持: 重要なセッションデータを優先してコストを最適化します。
本ガイドでは、オブザーバビリティ予算内で RUM セッションボリュームを効果的に管理するための戦略を説明します。
保持フィルターのシーケンスを理解する
RUM 保持フィルターを使用すると、保持するユーザーセッションを選択できます。仕組みは以下のとおりです。
各セッションには複数のイベント (ナビゲーションを表すビュー、ユーザーアクション、エラー、ネットワークリクエストを表すリソースなど) が含まれており、それぞれに属性 (期間、コンテキストなど) が豊富に含まれています。システムは、各イベントを個別に評価して保持フィルターと照合します。
- セッションを保持: セッション内の少なくとも 1 つのイベントが保持フィルターに一致し、かつ保持対象としてサンプリングされた場合、セッション全体が保存されます。
- セッションを破棄: セッション終了までにどのイベントも保持フィルターに一致しない場合、セッション全体が削除されます。
イベントタイプごとの仕組み
一部のイベント (エラーやアクションなど) は、発生後に変更できません。Datadog では、これらをイミュータブルイベントと呼びます。その他のイベント (セッションやビューなど) は、ユーザーがアプリを使用し続けるにつれて変化する可能性があります。Datadog では、これらをミュータブルイベントと呼びます。
ベストプラクティス
保持フィルターの順序
保持フィルターの順序は重要です。Datadog では、最も具体的でサンプリングレートが高いフィルターをリストの上部に、最も一般的でサンプリングレートが低いフィルターを下部に配置することを推奨しています。
たとえば、クラッシュイベント (@error.is_crash:true 属性を持つエラーイベント) があるとします。このイベントは複数のフィルターに一致する可能性がありますが、リスト内の最初に一致したフィルターに対してのみ評価されます。
以下の例では、“Crashes”保持フィルターが、より一般的な“All errors”保持フィルターの上に配置されています。これにより、すべてのクラッシュセッションが保持されます。それらのセッションは、“Crashes”保持フィルターに最初に一致するためです。
以下の例では、より一般的な“All errors”保持フィルターが“Crashes”保持フィルターの前に配置されています。そのため、クラッシュセッションは、“All errors”保持フィルターによって選択された場合にのみ保持されます (たとえば、サンプリングレートが 50% の場合など)。選択されなかった場合は、“Crashes”保持フィルターによって評価されないため、それらのセッションは失われます。
残りのセッションをキャプチャするためのフォールバックフィルター
リストの最後にあるフォールバックフィルターは、他のフィルターで一致しなかった少数のセッションをキャプチャします。フォールバックフィルターのクエリには、常に @session.is_active:false を含める必要があります。
セッションの除外
単一のフィルターがイベントのサブセットに一致しないようにするには、そのフィルターのクエリ内に除外条件を追加します。保持フィルターを使用したセッションの除外を参照してください。
すべてのカスタム保持フィルターでイベントを除外するには、各クエリで同じ除外条件を繰り返す代わりに除外フィルターを使用してください。
推奨される保持フィルターとユースケース
以下に、デフォルトのフィルター、推奨されるフィルター、およびそれらの一般的なユースケースを示します。
| フィルタータイプ | クエリの例 | 使用する状況 | 保持率 |
|---|
| リプレイ付きセッション | @session.has_replay:true | セッションリプレイが利用可能なセッションをシステムが破棄しないように、リプレイ付きセッションを保持します。 | 100% |
| エラーのあるセッション | @type:error | 少なくとも 1 つのエラーを含むすべてのセッションを保持するために適用できるデフォルトのフィルターです。 | 100% |
| クラッシュしたセッション | @type:error @error.is_crash:true | クラッシュで終了したすべてのセッションを保持するために適用できるフィルターです。 | 100% |
| セッション | @type:session | リストの最後に配置されるデフォルトのフィルターで、すべてのセッションに適用され、その一部を保持または破棄できます。 | 可変 |
| アプリのバージョン | @type:session version:v1.1.0-beta | アプリのバージョン (ベータ版、アルファ版、または特定のバージョン) でフィルタリングすることで、特定のビルドからのすべてのセッションを詳細な分析やトラブルシューティングのために保存できます。 | 100% |
| 環境 | @type:session environment:stage | さまざまなビルドタイプや環境のセッションを収集する際に、少なくともステージング環境のセッションは 100% キャプチャし、開発/テスト環境のセッションを収集する割合を減らすことができます。 | 100% |
| フィーチャーフラグ | @type:session feature_flags.checkout_type:treatment_v1 | すでにフィーチャーフラグを使用している場合は、特定のフィーチャーフラグ処理が行われたセッションを 100% 保持するように選択できます。 | 100% |
| カスタム属性 | @type:session @context.cartValue:>=500 | セッションのカスタム属性を含むほぼすべてのクエリを使用してフィルターを作成し、保持基準を指定できます。たとえば、Datadog のデモアプリ“Shopist”では、カートの金額がカスタムセッション属性になっています。これにより、カートの金額が高いセッションを保持できるため、収益に影響を与える問題のトラブルシューティングを効率的に行うことができます。 | 可変 |
| ユーザー属性を持つセッション | @type:session user.tier:paid | セッションのユーザー情報を使用してフィルターを作成します。たとえば、有料ティアの全ユーザーのセッションを保持することができます。 | 100% |
| 特定のユーザーのセッション | @type:session user.id:XXXXX | このフィルターは、本番環境のテストアカウントや、定期的にアプリケーションをテストするエグゼクティブなど、特定のユーザーのセッションを対象にできます。 | 100% |
| 特定のアクションを含むセッション | @type:action @action.name:XXXXX | SDK が自動的に追跡する標準的なアクションや、コード内でインスツルメントしたカスタムアクションを含むすべてのセッションを保持できます。 | 100% |
| 特定の期間のセッション | @session.view.count :> 3 OR @session.time_spent :> 15000000000 | 短いセッションが多く見られる場合 (ユーザーが 10 秒間ページを閲覧しただけで、その後のアクションやエラーが発生しないセッションなど)、それらは通常役に立ちません。期間の保持フィルターを使用すると、これらのセッションを減らすことができます。注: 期間の値はナノ秒単位の数値で入力し、単位は含めないでください (例: 15 秒の場合は 15000000000 と入力します)。 | 可変 |
| ネットワークエラー 4XX および 5XX が発生したセッション | @type:resource @resource.status_code:>=400 | フロントエンドアプリケーションでは、ダウンストリームサービスが 4XX または 5XX のステータスコードを返す問題が頻繁に発生します。このフィルターを使用すると、エラーコードが発生したリソース呼び出しを含むすべてのセッションをキャプチャできます。 | 100% |
参考資料
