Felsökning av fel med API-begränsningar

Artikel
07/30/2024

Gäller för: ✔️ Virtuella Linux-datorer ✔️, virtuella Windows-datorer

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 resursprovider (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 regelverk för att undvika begränsning.

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

Som klientdörr till Azure utför Azure Resource Manager autentisering och första ordningens validering och begränsning av alla inkommande API-begäranden. Azure Resource Manager-anropsfrekvensgränser 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. Om du vill veta 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).

Informationssvarshuvuden för samtalsfrekvens

Header	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 resurs bucketen eller åtgärdsgruppen, inklusive målet för den här begäran
x-ms-request-charge	`<count>`	1	Antalet anrop "debiteras" för den här 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 kommer att finnas ett separat x-ms-ratelimit-remaining-resource huvud för varje princip.

Här är ett exempelsvar 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 samtalsfrekvens nås. Ett typiskt svar på begränsningsfel från beräkningsresursprovidern ser ut som 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 beror på vilket begränsningsfelet returneras. I det här fallet är HighCostGetdet . Det övergripande formatet för svarstexten är det allmänna Azure Resource Manager API-felformatet (överensstämmer med OData). Huvudfelkoden, 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 antal sekunder som klienten bör vänta innan begäran försök igen.

API-anropsfrekvens och begränsningsfelanalys

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

API-anropsstatistiken kan ge stor insikt 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 resurstyper för diskar och ögonblicksbilder (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.

Bästa praxis

Försök inte utföra api-fel för Azure-tjänsten på nytt villkorslöst och/eller omedelbart. En vanlig förekomst är att klientkoden hamnar i en snabb återförsöksloop när ett fel uppstår som inte kan försöka igen. Återförsök kommer så småningom att uttömma den tillåtna samtalsgrä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ålgrupp sjunker under något lågt tröskelvärde.
När du spårar asynkrona åtgärder respekterar du huvudtipsen Försök efter igen.
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 resursgruppen som innehåller 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 köra frågor mot 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 efter 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 effektivare 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 vägledning för återförsök 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.

Dela via