速率限制和 API 錯誤

Telemetry 端點使用標準 HTTP 狀態程式碼。在重試之前，客戶端應將請求缺陷與臨時服務或容量狀況區分開來。

計劃特定的配額和當前限制可能會發生變化。將產品和計費設定中顯示的限制視為帳戶的真實來源；不要對未記錄的全域性請求率進行硬編碼。

反應等級

錯誤主體可能包括更具體的上下文。記錄狀態、端點名稱、請求 ID 和安全錯誤類別。不要僅僅因為請求失敗就記錄 API 金鑰或原始事件負載。

安全重試

對 429、502、503 和 504 回應使用帶抖動的指數退避。限制嘗試和總執行時間，以便遙測中斷不會耗盡應用程式工作人員的精力。

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

在不修改請求的情況下，請勿重試 400 回應。重複傳送無效架構或 SQL 查詢會建立負載，但不會建立成功路徑。

保留事件身分

重試攝取時，請為邏輯事件重新使用穩定的 event_id。這使得重複傳遞變得可測量，並允許冪等消費者識別重試。每次網路嘗試上的新識別符號都會將一個結果轉變為幾個無法區分的業務事件。

使用 重複的事件 ID 配方 審查重試行為。

約束失效影響

確定遙測是否位於關鍵路徑上。對於大多數產品儀器，應透過安全診斷通道報告臨時攝取失敗，而不更改已成功的客戶回應。對於合規性或計費工作流程，持久佇列可能比較合適。

對於大型結果集，請使用 非同步查詢API，而不是重複重試互動式請求。有關範圍規則，請參閱 API 金鑰與身分驗證。