針對 API 節流錯誤進行疑難解答

發行項
04/18/2024

Azure 計算要求可能會在訂用帳戶和每個區域進行節流，以協助服務的整體效能。我們確保所有對 Azure 計算資源提供者 (CRP) 的呼叫，在 Microsoft.Compute 命名空間下管理資源不會超過允許的 API 要求速率上限。本文件說明 API 節流、如何針對節流問題進行疑難解答的詳細數據，以及避免節流的最佳做法。

Azure Resource Manager 與資源提供者的節流

作為 Azure 的前門，Azure Resource Manager 會對所有傳入的 API 要求進行驗證和第一順序驗證和節流。這裡說明 Azure Resource Manager 呼叫速率限制和相關的診斷回應 HTTP 標頭。

當 Azure API 用戶端收到節流錯誤時，HTTP 狀態為 429 太多要求。若要瞭解要求節流是否由 Azure Resource Manager 或 CRP 之類的基礎資源提供者完成，請檢查 x-ms-ratelimit-remaining-subscription-reads 是否有非 GET 要求的 GET 要求和x-ms-ratelimit-remaining-subscription-writes回應標頭。如果剩餘的通話計數接近0，則已達到Azure Resource Manager定義的訂用帳戶一般通話限制。所有訂用帳戶客戶端的活動會一起計算。否則，節流會來自目標資源提供者， (要求URL) 區段所 /providers/<RP> 尋址的資源提供者。

通話費率信息回應標頭

頁首	值格式	範例	描述
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet;159	節流原則的剩餘 API 呼叫計數，涵蓋資源貯體或作業群組，包括此要求的目標
x-ms-request-charge	`<count>`	1	此 HTTP 要求的通話數目會「計費」，以達到適用原則的限制。這通常是 1。批次要求，例如調整虛擬機擴展集，可以收取多個計數。

請注意，API 要求可能會受限於多個節流原則。每個原則都會有個別 x-ms-ratelimit-remaining-resource 的標頭。

以下是刪除虛擬機擴展集要求的範例回應。

x-ms-ratelimit-remaining-resource: Microsoft.Compute/DeleteVMScaleSet;107 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/DeleteVMScaleSet;587 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/VMScaleSetBatchedVMRequests;3704 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/VmssQueuedVMOperations;4720

節流錯誤詳細數據

429 HTTP 狀態通常用來拒絕要求，因為已達到通話速率限制。從計算資源提供者的一般節流錯誤回應會如下列範例所示 (只會顯示相關的標頭) ：

HTTP/1.1 429 Too Many Requests
x-ms-ratelimit-remaining-resource: Microsoft.Compute/HighCostGet;0
Retry-After: 1200
Content-Type: application/json; charset=utf-8
{
  "code": "OperationNotAllowed",
  "message": "The server rejected the request because too many requests have been received for this subscription.",
  "details": [
    {
      "code": "TooManyRequests",
      "target": "HighCostGet",
      "message": "{\"operationGroup\":\"HighCostGet\",\"startTime\":\"2018-06-29T19:54:21.0914017+00:00\",\"endTime\":\"2018-06-29T20:14:21.0914017+00:00\",\"allowedRequestCount\":300,\"measuredRequestCount\":1238}"
    }
  ]
}

剩餘通話計數為0的原則是傳回節流錯誤所造成的原則。在這裡情況下為 HighCostGet。回應本文的整體格式是一般 Azure Resource Manager API 錯誤格式， (符合 OData) 。主要錯誤碼 OperationNotAllowed是計算資源提供者用來報告節流錯誤 (其他類型的用戶端錯誤) 。內部 message 錯誤 () 的屬性包含串行化的 JSON 結構，其中包含節流違規的詳細數據。

如上所示，每個節流錯誤都包含 Retry-After 標頭，這會提供用戶端在重試要求之前應該等候的最小秒數。

API 呼叫率和節流錯誤分析器

預覽版的疑難解答功能適用於計算資源提供者的 API。這些 PowerShell Cmdlet 會提供每個作業每個時間間隔的 API 要求速率統計數據，以及每個作業群組的節流違規 (原則) ：

API 呼叫統計數據可讓您深入瞭解訂用帳戶用戶端 () 的行為，並讓您輕鬆識別導致節流的呼叫模式。

分析器目前的限制是，它不會計算 (支援受控磁碟) 之磁碟和快照集資源類型的要求。因為它會從CRP的遙測收集數據，所以也無法協助識別ARM的節流錯誤。但您可以根據獨特的 ARM 回應標頭輕鬆識別這些專案，如先前所述。

PowerShell Cmdlet 使用 REST 服務 API，用戶端可以輕鬆地直接呼叫它 (但尚未) 正式支援。若要查看 HTTP 要求格式，請使用 Fiddler 在其執行時使用 -Debug 參數或 Snoop 執行 Cmdlet。

最佳做法

請勿無條件且/或立即重試 Azure 服務 API 錯誤。常見的情況是用戶端程式代碼在遇到無法重試的錯誤時進入快速重試迴圈。重試最終會耗盡目標作業群組的允許呼叫限制，並影響訂用帳戶的其他用戶端。
在大量 API 自動化案例中，當目標作業群組的可用呼叫計數低於一些低閾值時，請考慮實作主動式用戶端自我節流。
追蹤異步操作時，請遵守 Retry-After 標頭提示。
如果客戶端程式代碼需要特定虛擬機的相關信息，請直接查詢該 VM，而不是列出包含資源群組或整個訂用帳戶中的所有 VM，然後在客戶端挑選所需的 VM。
如果客戶端程式代碼需要來自特定 Azure 位置的 VM、磁碟和快照集，請使用以位置為基礎的查詢形式，而不是查詢所有訂用帳戶 VM，然後依用戶端上的位置進行篩選： GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30 查詢至計算資源提供者區域端點。
建立或更新 API 資源時，特別是 VM 和虛擬機擴展集時，追蹤傳回的異步操作完成比根據 provisioningState) 對資源 URL 本身進行輪詢 (更有效率。

後續步驟

如需 Azure 中其他服務的重試指引詳細資訊，請參閱特定服務的重試指引。

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。您也可以將產品意見反應提交給 Azure 意應見反社群。