バッチ処理、バックプレッシャー、正常なシャットダウン
バッチ処理はリクエストのオーバーヘッドを削減できますが、障害の影響や配信の遅延も変化します。制限なくイベントをキューに入れるプロセスは、停止中にメモリを消費する可能性があります。保留中の作業を考慮せずに終了したプロセスは、最新のイベントを通知なく失う可能性があります。
Telemetry のログ API は、1 つの JSON オブジェクトまたは JSON オブジェクトの配列を受け入れます。 API 機能では、すべてのプロデューサーがメモリ内のバックグラウンド キューを維持する必要はありません。
待望の直接配送からスタート
少量のワークフローの場合は、1 つのコンパクトな結果イベントを送信し、制限されたタイムアウトでリクエストを待ちます。これは、推論とテストを行うための最も簡単な配信パスです。
リクエストのオーバーヘッドが重大であることが測定で示された場合、または既存のワーカーがすでに永続的なコレクション バッファーを所有している場合にバッチを実行します。サイズのしきい値を無制限に待機する大きなキューよりも、時間制限のある小さなバッチを優先します。
await telemetry.log("api_request_completed", [
{
event_id: "evt_101",
route_template: "/api/projects/:id",
status: "success",
latency_ms: 84,
},
{
event_id: "evt_102",
route_template: "/api/projects/:id",
status: "failed",
latency_ms: 912,
error_type: "database_timeout",
},
]);
バッチ内のすべてのオブジェクトと同じテーブル スキーマとの互換性を維持します。 1 つの無効なアイテムまたは互換性のないアイテムにより、リクエスト全体の結果が複雑になる可能性があります。
すべてのキューをバインドする
アプリケーションがイベントをバッファーする場合は、以下を定義します。
- キューに入れられたイベントの最大数とシリアル化されたバイト数。
- 部分的なバッチが送信されるまでの最大経過時間。
- 最大バッチサイズ。
- リクエストのタイムアウトと再試行のバジェット。
- オーバーフロー動作。
- シャットダウン動作。
オーバーフロー動作は明示的である必要があります。最も古い優先度の低い診断イベントの削除、ノイズの多い成功パスのサンプリング、専用のテレメトリ ワーカーのブロック、耐久性のある送信ボックスへの永続化は、運用上のさまざまな影響を及ぼします。プロセス メモリを使い果たすことによって、無制限のキューに決定をさせないでください。
キューの深さ、最も古いイベントの経過時間、送信されたバッチ、受け入れられたイベント、ドロップされたイベント、および永続的な配信の失敗を安全な診断パスを通じて記録します。同じ失敗したキューを介してテレメトリ キュー自身の失敗イベントを再帰的に送信することは避けてください。
バックプレッシャーを顧客の作業から切り離す
ほとんどの製品分析では、テレメトリ配信で顧客リクエストのレイテンシ バジェット全体が消費されるべきではありません。短い境界付きハンドオフまたはアプリケーション所有のワーカーを使用します。キューがいっぱいの場合は、無期限に待機するのではなく、文書化されたオーバーフロー ポリシーを適用します。
請求または承認された監査イベントの場合は、ビジネス イベントを失うのではなく、耐久性のある送信ボックスを使用し、送信ボックス ワーカーにバックプレッシャーを与えます。の イベント配信と冪等性ガイド 複数の試行にわたる安定したイベント ID について説明します。
シャットダウンを意図的に処理する
正常なシャットダウン信号の場合:
- 新しい仕事の受け入れをやめてください。
- 実行中のアプリケーション作業が定義された境界に到達できるようにします。
- 残りのテレメトリ バッチを送信または永続化します。
- シャットダウン期限を強制します。
- 配信できなかった数を記録します。
特定の SDK が公開および文書化していない限り、クライアント フラッシュ保証を主張しないでください。クライアントが各呼び出しをすぐに送信する場合、追跡されているすべての呼び出しを待つことは、内部キューをフラッシュすることとは異なります。サーバーレスおよびエッジ ランタイムは応答後に実行をフリーズする場合があるため、ランタイムでサポートされているバックグラウンド作業メカニズムを使用するか、イベントが必要なときに返される前に配信します。
過負荷動作を検証する
完全なバッチ、部分的な時間トリガー バッチのテスト、 429, 503、接続タイムアウト、キューのオーバーフロー、保留中のイベントによるプロセスの終了。再試行によってイベント ID が保持され、失敗パスで認証情報や生のペイロードが出力されないことを確認します。
を使用します。 イベント取り込みのトラブルシューティング ガイド 応答を確認し、 テレメトリボリュームガイド バッチ処理またはサンプリングが実際に必要かどうかを測定します。