Telemetry コストとボリュームの管理
Telemetry ボリュームには、イベント頻度、シリアル化されたペイロード サイズ、保持、クエリ スキャン パターン、エクスポート、個別のディメンション値の数など、いくつかの異なるドライバーがあります。単一バイトの合計が完全なベンダー請求書となるわけではありませんが、これらの入力値を測定することで、無駄や危険な収集の変更をレビューしやすくなります。
まずはイベント契約を測定する
取り込み時に、制御されたイベント名、制限されたプロデューサー ソース、シリアル化されたペイロード バイト、スキーマ バージョン、受け入れ結果、および環境を含むコンパクトな操作イベントを記録します。元のペイロードを測定イベントに複製しないでください。
の テレメトリ ボリューム SQL レシピ グループは、イベント コントラクトによってカウントおよびペイロード バイトをカウントします。また、平均イベント サイズと拒否率も計算します。これにより、高頻度の小規模イベントと低頻度の過大なイベントが区別され、コストの変更によってデータ品質がひそかに低下するのを防ぎます。
シリアル化されたバイトは、圧縮ストレージ、スキャンされたバイト、ネットワーク送信、または請求書のコストと同じではありません。金額を予測する前に、集計を実際のリテンションおよび価格モデルに関連付けます。
カーディナリティと有用性を確認する
未加工の URL、リクエスト ID、エラー メッセージ、ユーザー生成のラベルなどのフィールドがグループ化ディメンションになる場合、小規模なイベントでも使用できないダッシュボードが作成される可能性があります。フォローしてください 高カーディナリティ フィールドのガイド デフォルトのグラフではなく、ターゲットを絞ったドリルダウン用の識別子を保持します。
大規模な契約ごとに、次の文書を作成します。
- サポートされる意思決定、ダッシュボード、アラート、または調査。
- 必須フィールドと削除または分類できるフィールド。
- プロダクション サンプリング ルールと、サンプリングによって防止される質問。
- 保存と削除の要件。
- スキーマとボリュームの変更をレビューする所有者。
コレクションを安全に変更する
開発ノイズ、偶発的な重複、リーダーのないフィールドから始めます。実稼働データを削減する前に、スキーマの変更と拒否動作をテストします。ロールアウト後に完全な日次バケットを比較して、トラフィックの変化がインストルメンテーションの勝利と誤解されないようにします。
を使用します。 データ品質レシピ集 ボリュームを変更しながら、鮮度、重複、NULL フィールド、およびスキーマの採用を監視します。の データ保持ガイド クエリの最適化とは別にする必要があるポリシーと削除の決定について説明します。