Felsöka API-begränsningsfel

Artikel
04/18/2024

Azure Compute-begäranden kan begränsas i en prenumeration och per region för att hjälpa till med tjänstens övergripande prestanda. Vi ser till att alla anrop till Azure Compute Resource Provider (CRP), som hanterar resurser under Microsoft.Compute-namnområdet, inte överskrider den högsta tillåtna API-begärandefrekvensen. Det här dokumentet beskriver API-begränsning, information om hur du felsöker begränsningsproblem och metodtips för att undvika begränsning.

Begränsning av Azure Resource Manager jämfört med resursproviders

Som klientdörr till Azure utför Azure Resource Manager verifiering och begränsning av autentisering och första ordningen för alla inkommande API-begäranden. Azure Resource Manager anropsfrekvensbegränsningar och relaterade HTTP-huvuden för diagnostiksvar beskrivs här.

När en Azure API-klient får ett begränsningsfel är HTTP-statusen 429 För många begäranden. För att förstå om begränsningen av begäran görs av Azure Resource Manager eller en underliggande resursprovider som CRP kontrollerar du get-begäranden och x-ms-ratelimit-remaining-subscription-writes svarshuvuden x-ms-ratelimit-remaining-subscription-reads för icke-GET-begäranden. Om det återstående antalet samtal närmar sig 0 har prenumerationens allmänna samtalsgräns som definierats av Azure Resource Manager nåtts. Aktiviteter efter alla prenumerationsklienter räknas tillsammans. Annars kommer begränsningen från målresursprovidern (den som hanteras av /providers/<RP> segmentet för begärande-URL:en).

Svarshuvuden för samtalsfrekvensinformation

Rubrik	Värdeformat	Exempel	Beskrivning
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet; 159	Återstående API-anropsantal för begränsningsprincipen som täcker resursbucketen eller åtgärdsgruppen, inklusive målet för den här begäran
x-ms-request-charge	`<count>`	1	Antalet anrop räknas som "debiterade" för denna HTTP-begäran mot den tillämpliga principens gräns. Detta är oftast 1. Batch-begäranden, till exempel för skalning av en VM-skalningsuppsättning, kan debitera flera antal.

Observera att en API-begäran kan utsättas för flera begränsningsprinciper. Det finns en separat x-ms-ratelimit-remaining-resource rubrik för varje princip.

Här är ett exempel på ett svar för att ta bort begäran om VM-skalningsuppsättningar.

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

Information om begränsningsfel

HTTP-statusen 429 används ofta för att avvisa en begäran eftersom en gräns för anropsfrekvens nås. Ett typiskt svar på begränsningsfel från beräkningsresursprovidern ser ut som i exemplet nedan (endast relevanta rubriker visas):

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}"
    }
  ]
}

Principen med återstående anropsantal på 0 är den som begränsningsfelet returneras till. I det här fallet är HighCostGetdet . Svarstextens övergripande format är det allmänna Azure Resource Manager API-felformatet (överensstämmer med OData). Den huvudsakliga felkoden, OperationNotAllowed, är den som beräkningsresursprovidern använder för att rapportera begränsningsfel (bland andra typer av klientfel). Egenskapen message för de inre felen innehåller en serialiserad JSON-struktur med information om begränsningsöverträdelsen.

Som du ser ovan innehåller Retry-After varje begränsningsfel huvudet, vilket ger det minsta antalet sekunder som klienten ska vänta innan begäran försöker igen.

API-anropsfrekvens och begränsningsfelanalys

En förhandsversion av en felsökningsfunktion är tillgänglig för beräkningsresursproviderns API. Dessa PowerShell-cmdletar innehåller statistik om API-begärandefrekvens per tidsintervall per åtgärd och begränsningsöverträdelser per åtgärdsgrupp (princip):

API-anropsstatistiken kan ge bra inblick i beteendet hos en prenumerations klienter och möjliggöra enkel identifiering av anropsmönster som orsakar begränsning.

En begränsning för analysatorn för tillfället är att den inte räknar begäranden för disk- och ögonblicksbildresurstyper (till stöd för hanterade diskar). Eftersom den samlar in data från CRP:s telemetri kan den inte heller hjälpa till att identifiera begränsningsfel från ARM. Men de kan identifieras enkelt baserat på de distinkta ARM-svarshuvudena, som vi diskuterade tidigare.

PowerShell-cmdletarna använder ett REST-tjänst-API, som enkelt kan anropas direkt av klienter (men utan formellt stöd ännu). Om du vill se HTTP-begärandeformatet kör du cmdletarna med växeln -Debug eller snoop på deras körning med Fiddler.

Metodtips

Försök inte utföra api-fel för Azure-tjänsten på nytt villkorslöst och/eller omedelbart. En vanlig händelse är att klientkoden hamnar i en snabb återförsöksloop när det uppstår ett fel som inte kan försöka igen. Återförsök kommer så småningom att uttömma den tillåtna anropsgränsen för målåtgärdens grupp och påverka andra klienter i prenumerationen.
I högvolyms-API-automatiseringsfall bör du överväga att implementera proaktiv självbegränsning på klientsidan när det tillgängliga antalet anrop för en målåtgärdsgrupp sjunker under ett lågt tröskelvärde.
När du spårar asynkrona åtgärder bör du respektera Retry-After huvudtips.
Om klientkoden behöver information om en viss virtuell dator frågar du den virtuella datorn direkt i stället för att lista alla virtuella datorer i den innehållande resursgruppen eller hela prenumerationen och väljer sedan den virtuella dator som behövs på klientsidan.
Om klientkoden behöver virtuella datorer, diskar och ögonblicksbilder från en specifik Azure-plats använder du platsbaserad form av frågan i stället för att fråga alla virtuella prenumerationsdatorer och sedan filtrera efter plats på klientsidan: GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30 fråga till regionala slutpunkter för Beräkningsresursprovider.
När du skapar eller uppdaterar API-resurser i synnerhet, virtuella datorer och VM-skalningsuppsättningar, är det mycket mer effektivt att spåra den returnerade asynkrona åtgärden till slutförande än att avsöka själva resurs-URL:en (baserat på provisioningState).

Nästa steg

Mer information om återförsöksvägledning för andra tjänster i Azure finns i Återförsöksvägledning för specifika tjänster.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.