構造化 Telemetry のイベント サンプリング戦略
サンプリングでは、対象となるイベントのサブセットが保持されます。配信とストレージの量を減らすことができますが、データセットが応答できる内容も変わります。サンプリングは、スキーマのレビュー、重複の削除、保持ポリシーに代わるものではなく、測定されたコストまたはスケールの問題に従う必要があります。
サンプリングの前に、未使用フィールドの削除、意図しない高カーディナリティ値の正規化、重複生成元の停止を行い、次のレシピでイベント数とペイロードバイト数を測定します: テレメトリボリュームのレシピ.
まれで重要な結果を保存する
承認されたコントロールに別の指示がない限り、端末の障害、セキュリティ関連のイベント、請求記録、インシデントのマイルストーン、まれなワークフローの結果を完全に忠実に保ちます。均一な 1% のサンプルで、インシデント中にオペレーターが必要とするイベントを正確に消去できます。
一般的な開始ポリシーは次のとおりです。
- すべての失敗、タイムアウト、再試行の枯渇、および明示的な顧客影響イベントを保持します。
- 限定されたインシデントウィンドウの間、小さな診断ホワイトリストのすべてのイベントを保持します。
- 大量の成功した結果のみをサンプリングします。
- 少量のビジネスマイルストーンをサンプリングせずに維持します。
決定論的にサンプリングする
決定論的なサンプリングにより、関連する決定が再現可能になります。次のような安定した識別子をハッシュします。 request_id, trace_id、または account_id バージョン管理されたポリシーを使用して、それを目標レートと比較します。ポリシーのバージョンは変更されないまま、同じ識別子は同じ決定を下す必要があります。
記録:
sampledまたは同等の収集結果。sample_rate、など0.1;sampling_policy、などapi_success_v2;- 決定に使用される安定した次元。
機密性の高い未加工のハッシュ入力を保存しないでください。分析でステップが結合可能なままであると予想される場合は、ワークフローのステップごとに新しいランダム決定を独立して生成しないでください。
重み付け分析を明示的にする
成功したイベントが 10% でサンプリングされた場合、保持される各成功は、ポリシーの仮定の下で約 10 件の適格な成功を表します。含まれる確率を保存し、数を推定するときに明示的な重みを使用します。
SELECT
route_template,
SUM(1.0 / sample_rate) AS estimated_requests
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY route_template
ORDER BY estimated_requests DESC;
加重カウントでは、すべての統計が自動的に修復されるわけではありません。テール パーセンタイル、個別ユーザー数、ファネル、コホート保持率、および小規模な顧客セグメントは、不安定になったり、偏ったりする可能性があります。分母や配列関係が正確である必要がある分析のために、非サンプリング データを保持します。
ポリシーのバージョンを作成して評価する
レートを変更するとデータセットが変更されます。ポリシーのバージョンと有効時間を記録すると、コレクションが一定であるかのように、クエリで互換性のない期間の比較を回避できます。
評価:
- 保持されたイベントの数とバイト数。
- 失敗とまれな結果をカバーします。
- サンプリングされていないフィクスチャまたは一時的なホールドアウトに対する推定メトリック エラー。
- 少量のルート、プラン、地域をセグメントでカバーします。
- サンプリングされたデータセットでは答えられなくなった質問。
収集ポリシーの変更による販売量の減少から製品の改善を推測しないでください。
履歴に問題がある場合は、保持期間の変更を優先する
サンプリングにより、将来の行カバレッジが減少します。保持では、ポリシーで定義された期間が経過すると古いデータが削除されます。現在のインシデントの詳細を完全にしておく必要があるが、長期的な履歴にコストがかかる場合は、より短い保持ポリシーの方が適している可能性があります。レビュー データの保持と削除 サンプリングとは別に。
続けて 高カーディナリティフィールド, テレメトリのコスト管理、そして データ品質の SQL レシピ.