レート制限と API エラー

Telemetry エンドポイントは、標準の HTTP ステータス コードを使用します。クライアントは、再試行する前に、リクエストの欠陥と一時的なサービスまたは容量の状態を区別する必要があります。

プラン固有の割り当てと現在の制限は変更される場合があります。製品および請求設定に表示される制限を、アカウントの信頼できる情報源として扱います。文書化されていないグローバルリクエストレートをハードコーディングしないでください。

応答クラス

エラー本文には、より具体的なコンテキストが含まれる場合があります。ステータス、エンドポイント名、リクエスト ID、および安全なエラー カテゴリをログに記録します。リクエストが失敗したからといって、API キーや元のイベント ペイロードをログに記録しないでください。

安全に再試行してください

ジッターを伴う指数バックオフを使用する 429, 502, 503、そして 504 応答。テレメトリの停止によってアプリケーション ワーカーが疲弊することがないように、試行時間と合計経過時間の両方に制限を設けます。

delay = min(max_delay, base_delay * 2^attempt) + random_jitter

再試行しないでください 400 リクエストを変更せずに応答します。無効なスキーマまたは SQL クエリを繰り返し送信すると、成功へのパスが作成されずに負荷が発生します。

イベントのアイデンティティを保持する

取り込みを再試行するときは、安定した event_id 論理イベントの場合。これにより、重複配信が測定可能になり、冪等のコンシューマが再試行を認識できるようになります。ネットワークを試行するたびに新しい識別子が発生し、1 つの結果がいくつかの区別できないビジネス イベントに変わります。

を使用します。 重複したイベント ID レシピ 再試行動作を監査します。

バウンド障害の影響

テレメトリがクリティカル パス上にあるかどうかを決定します。ほとんどの製品インストルメンテーションでは、一時的な取り込みの失敗は、既に成功した顧客の応答を変更することなく、安全な診断チャネルを通じて報告される必要があります。コンプライアンスまたは請求のワークフローには、永続的なキューが適切な場合があります。

大規模な結果セットの場合は、 非同期クエリ API 対話型リクエストを繰り返し再試行するのではなく、参照 API キーと認証 スコープルールの場合。