Telemetry コストとボリュームの管理
課金は経過時間ではなく、全ワーカーの実際の CPU 時間を測定します。8 個の CPU が 10 秒稼働すると 80 CPU 秒です。待機は含みません。完了した各フラグメントとコーディネーター自身の処理をそれぞれ一度だけ計上します。リクエスト全体が失敗しても完了済みフラグメントは課金対象になり、再試行で使用量が増える場合があります。新しいレコードには 300 ms の最低課金はありません。月額の CPU 時間枠は Free が 1 時間、Business が 10 時間、Enterprise が 100 時間で、有料プランの超過分は CPU 時間あたり $0.30 です。待機による遅さではなく実際の仕事量に課金するためです。並列実行で安くなる保証はありません。
CPU billing: full details (English)
テレメトリのコストを把握するには、イベントの頻度、ペイロードのサイズ、保持期間、クエリが読むデータ量、エクスポート、フィールドごとの値の種類数を測ります。合計バイト数だけでは請求額を説明できません。収集量を減らす前にこれらを確認し、どのデータを失うか、どのコストを減らせそうかを判断してください。
まずはイベント契約を測定する
取り込み時に、制御されたイベント名、制限されたプロデューサー ソース、シリアル化されたペイロード バイト、スキーマ バージョン、受け入れ結果、および環境を含むコンパクトな操作イベントを記録します。元のペイロードを測定イベントに複製しないでください。
の テレメトリ ボリューム SQL レシピ グループは、イベント コントラクトによってカウントおよびペイロード バイトをカウントします。また、平均イベント サイズと拒否率も計算します。これにより、高頻度の小規模イベントと低頻度の過大なイベントが区別され、コストの変更によってデータ品質がひそかに低下するのを防ぎます。
シリアル化されたバイトは、圧縮ストレージ、スキャンされたバイト、ネットワーク送信、または請求書のコストと同じではありません。金額を予測する前に、集計を実際のリテンションおよび価格モデルに関連付けます。
カーディナリティと有用性を確認する
未加工の URL、リクエスト ID、エラー メッセージ、ユーザー生成のラベルなどのフィールドがグループ化ディメンションになる場合、小規模なイベントでも使用できないダッシュボードが作成される可能性があります。フォローしてください 高カーディナリティ フィールドのガイド デフォルトのグラフではなく、ターゲットを絞ったドリルダウン用の識別子を保持します。
大規模な契約ごとに、次の文書を作成します。
- サポートされる意思決定、ダッシュボード、アラート、または調査。
- 必須フィールドと削除または分類できるフィールド。
- プロダクション サンプリング ルールと、サンプリングによって防止される質問。
- 保存と削除の要件。
- スキーマとボリュームの変更をレビューする所有者。
コレクションを安全に変更する
開発ノイズ、偶発的な重複、リーダーのないフィールドから始めます。実稼働データを削減する前に、スキーマの変更と拒否動作をテストします。ロールアウト後に完全な日次バケットを比較して、トラフィックの変化がインストルメンテーションの勝利と誤解されないようにします。
を使用します。 データ品質レシピ集 ボリュームを変更しながら、鮮度、重複、NULL フィールド、およびスキーマの採用を監視します。の データ保持ガイド クエリの最適化とは別にする必要があるポリシーと削除の決定について説明します。