Api-beperkingsfouten oplossen

Artikel
04/18/2024

Azure Compute-aanvragen kunnen worden beperkt bij een abonnement en per regio om te helpen bij de algehele prestaties van de service. We zorgen ervoor dat alle aanroepen naar de Azure Compute Resource Provider (CRP), die resources beheert onder Microsoft.Compute-naamruimte, niet hoger zijn dan de maximaal toegestane API-aanvraagsnelheid. In dit document worden API-beperkingen beschreven, details over het oplossen van beperkingsproblemen en best practices om te voorkomen dat u wordt beperkt.

Beperking door Azure Resource Manager versus resourceproviders

Als front door naar Azure voert Azure Resource Manager de verificatie en validatie en beperking van alle inkomende API-aanvragen uit. Azure Resource Manager oproepsnelheidslimieten en gerelateerde HTTP-headers voor diagnostische reacties worden hier beschreven.

Wanneer een Azure API-client een beperkingsfout krijgt, is de HTTP-status 429 Te veel aanvragen. Als u wilt weten of de aanvraagbeperking wordt uitgevoerd door Azure Resource Manager of een onderliggende resourceprovider zoals CRP, controleert u de x-ms-ratelimit-remaining-subscription-reads op GET-aanvragen en x-ms-ratelimit-remaining-subscription-writes antwoordheaders voor niet-GET-aanvragen. Als het resterende aantal oproepen 0 nadert, is de algemene oproeplimiet van het abonnement die is gedefinieerd door Azure Resource Manager bereikt. Activiteiten van alle abonnementsclients worden samen geteld. Anders is de beperking afkomstig van de doelresourceprovider (de provider die wordt aangepakt door het /providers/<RP> segment van de aanvraag-URL).

Headers voor informatie over oproepsnelheid

Header	Waardenotatie	Voorbeeld	Omschrijving
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet; 159	Het resterende aantal API-aanroepen voor het beperkingsbeleid voor de resource-bucket of bewerkingsgroep, inclusief het doel van deze aanvraag
x-ms-request-charge	`<count>`	1	Het aantal oproepen telt 'in rekening gebracht' voor deze HTTP-aanvraag voor de limiet van het toepasselijke beleid. Dit is meestal 1. Batchaanvragen, zoals voor het schalen van een virtuele-machineschaalset, kunnen meerdere aantallen in rekening brengen.

Houd er rekening mee dat een API-aanvraag kan worden onderworpen aan meerdere beperkingsbeleidsregels. Er is een afzonderlijke x-ms-ratelimit-remaining-resource header voor elk beleid.

Hier volgt een voorbeeld van een antwoord om de aanvraag voor virtuele-machineschaalsets te verwijderen.

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

Details van beperkingsfout

De HTTP-status 429 wordt vaak gebruikt om een aanvraag te weigeren omdat een limiet voor aanroepsnelheid is bereikt. Een typische beperkingsfout van compute resourceprovider ziet er uit zoals in het onderstaande voorbeeld (alleen relevante headers worden weergegeven):

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

Het beleid met het resterende aantal aanroepen van 0 is het beleid waardoor de beperkingsfout wordt geretourneerd. In dit geval is HighCostGetdat . De algemene indeling van de antwoordtekst is de algemene Azure Resource Manager API-foutindeling (conform OData). De belangrijkste foutcode, OperationNotAllowed, is de rekenresourceprovider die wordt gebruikt om beperkingsfouten te melden (onder andere typen clientfouten). De message eigenschap van de interne fout(en) bevat een geserialiseerde JSON-structuur met de details van de beperkingsschending.

Zoals hierboven is geïllustreerd, bevat elke beperkingsfout de Retry-After header, die het minimale aantal seconden biedt dat de client moet wachten voordat de aanvraag opnieuw wordt geprobeerd.

API-aanroepsnelheid en beperkingsfoutanalyse

Er is een preview-versie van een probleemoplossingsfunctie beschikbaar voor de API van de rekenresourceprovider. Deze PowerShell-cmdlets bieden statistieken over api-aanvraagsnelheid per tijdsinterval per bewerking en schendingen van beperkingen per bewerkingsgroep (beleid):

De API-aanroepstatistieken kunnen een goed inzicht bieden in het gedrag van de client(s) van een abonnement en eenvoudige identificatie van aanroeppatronen mogelijk maken die beperking veroorzaken.

Een beperking van de analyse is voorlopig dat er geen aanvragen voor schijf- en momentopnameresourcetypen worden meegeteld (ter ondersteuning van beheerde schijven). Omdat het gegevens verzamelt uit de telemetrie van CRP, kan het ook niet helpen bij het identificeren van beperkingsfouten van ARM. Maar deze kunnen eenvoudig worden geïdentificeerd op basis van de onderscheidende ARM-antwoordheaders, zoals eerder is besproken.

De PowerShell-cmdlets maken gebruik van een REST-service-API, die eenvoudig rechtstreeks door clients kan worden aangeroepen (hoewel er nog geen formele ondersteuning is). Als u de HTTP-aanvraagindeling wilt zien, voert u de cmdlets uit met de schakeloptie -Foutopsporing of snoop op hun uitvoering met Fiddler.

Aanbevolen procedures

Probeer azure-service-API-fouten niet onvoorwaardelijk en/of onmiddellijk opnieuw. Een veelvoorkomende gebeurtenis is dat clientcode in een snelle lus voor opnieuw proberen komt wanneer er een fout optreedt die niet opnieuw kan worden geprobeerd. Nieuwe pogingen zullen uiteindelijk de toegestane aanroeplimiet voor de groep van de doelbewerking uitputten en van invloed zijn op andere clients van het abonnement.
In gevallen van api-automatisering met grote volumes kunt u overwegen om proactieve zelfbeperking aan de clientzijde te implementeren wanneer het aantal beschikbare aanroepen voor een doelgroep onder een lage drempelwaarde daalt.
Houd bij het bijhouden van asynchrone bewerkingen rekening met de Retry-After headerhints.
Als de clientcode informatie over een bepaalde virtuele machine nodig heeft, voert u rechtstreeks een query uit op die VM in plaats van alle VM's in de resourcegroep of het hele abonnement weer te geven en vervolgens de benodigde VM aan de clientzijde te kiezen.
Als clientcode VM's, schijven en momentopnamen van een specifieke Azure-locatie nodig heeft, gebruikt u de op locatie gebaseerde vorm van de query in plaats van een query uit te voeren op alle abonnements-VM's en vervolgens te filteren op locatie aan de clientzijde: GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30 voer een query uit naar regionale eindpunten van rekenresourceprovider.
Bij het maken of bijwerken van API-resources, met name VM's en virtuele-machineschaalsets, is het veel efficiënter om de geretourneerde asynchrone bewerking tot voltooiing bij te houden dan polling uit te voeren op de resource-URL zelf (op basis van de provisioningState).

Volgende stappen

Zie Richtlijnen voor opnieuw proberen voor specifieke services voor meer informatie over richtlijnen voor opnieuw proberen voor andere services in Azure.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.