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

發行項
07/30/2024

適用於：✔️ Linux VM ✔️ Windows VM

Azure 計算要求可能會在訂用帳戶和各區域時受到節流，以有助於服務的整體效能。我們會確保所有對 Azure 計算資源提供者 (CRP) 的呼叫，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 要求和 x-ms-ratelimit-remaining-subscription-writes 回應標頭是否有非 GET 要求。如果剩餘的通話計數接近 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 要求格式，請使用 -Debug 參數執行 Cmdlet，或使用 Fiddler 窺探其執行。

最佳做法

請勿無條件重試 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 和虛擬機擴展集比對資源 URL 本身進行 provisioningState輪詢更有效率地追蹤傳迴的異步作業完成。

下一步

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

與我們連絡，以取得說明

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

共用方式為