Problemen met API-beperkingsfouten oplossen

Artikel
07/30/2024

Van toepassing op: ✔️ Virtuele Linux-machines ✔️ van Windows

Azure rekenaanvragen kunnen worden beperkt voor een abonnement en op een per regio-baisis om te helpen bij de algehele prestaties van de service. We zorgen ervoor dat alle oproepen naar de Azure Compute-resourceprovider (CRP), waarmee resources onder Microsoft.Compute-naamruimte worden beheerd, 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 er wordt beperkt.

Beperking door Azure Resource Manager versus resourceproviders

Als voordeur naar Azure voert Azure Resource Manager de verificatie en validatie en eerste ordervalidatie en beperking van alle binnenkomende API-aanvragen uit. Http-headers voor aanroepen van Azure Resource Manager en gerelateerde HTTP-headers voor diagnostische antwoorden 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 aanvraag voor GET-aanvragen en x-ms-ratelimit-remaining-subscription-writes antwoordheaders voor niet-GET-aanvragen. Als het resterende aantal aanroepen 0 nadert, is de algemene oproeplimiet van het abonnement bereikt die is gedefinieerd door Azure Resource Manager. Activiteiten van alle abonnementsclients worden samen geteld. Anders komt de beperking van de doelresourceprovider (die is geadresseerd door het /providers/<RP> segment van de aanvraag-URL).

Kopteksten voor informatie over gespreksfrequentie

Koptekst	Waardenotatie	Voorbeeld	Beschrijving
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet; 159	Resterende AANTAL API-aanroepen voor het beperkingsbeleid voor de resourcebucket of bewerkingsgroep, inclusief het doel van deze aanvraag
x-ms-request-charge	`<count>`	1	Het aantal aanroepen 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 wordt een afzonderlijke x-ms-ratelimit-remaining-resource header voor elk beleid weergegeven.

Hier volgt een voorbeeldantwoord voor het verwijderen van een aanvraag voor virtuele-machineschaalsets.

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 beperkingsfouten

De HTTP-status 429 wordt vaak gebruikt om een aanvraag te weigeren, omdat een oproepfrequentielimiet is bereikt. Een typische reactie van een beperkingsfout van de Compute-resourceprovider ziet eruit 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, OperationNotAllowedis de resourceprovider die wordt gebruikt voor het rapporteren van beperkingsfouten (onder andere typen clientfouten). De message eigenschap van de interne fout(en) bevat een geserialiseerde JSON-structuur met de details van de schending van de beperking.

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.

Foutanalyse voor API-aanroepsnelheid en beperking

Er is een preview-versie van een functie voor probleemoplossing beschikbaar voor de API van de compute-resourceprovider. Deze PowerShell-cmdlets bieden statistieken over api-aanvraagsnelheid per tijdsinterval per bewerking en beperkingsschendingen 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 oproeppatronen die beperking veroorzaken.

Een beperking van de analyse voor de tijd is dat aanvragen voor schijf- en momentopnameresourcetypen niet worden geteld (ter ondersteuning van beheerde schijven). Omdat er gegevens worden verzameld 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 besproken.

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

Best practices

Probeer geen voorwaardelijke en/of onmiddellijk azure-service-API-fouten opnieuw. Een veelvoorkomende gebeurtenis is dat clientcode een snelle lus voor opnieuw proberen krijgt wanneer er een fout optreedt die niet opnieuw kan worden geprobeerd. Nieuwe pogingen zullen uiteindelijk de toegestane oproeplimiet voor de groep van de doelbewerking uitputten en invloed hebben op andere clients van het abonnement.
In grote gevallen van API-automatisering kunt u overwegen om proactieve zelfbeperking aan de clientzijde te implementeren wanneer het beschikbare aantal aanroepen voor een doelbewerkingsgroep onder een lage drempelwaarde daalt.
Bij het bijhouden van asynchrone bewerkingen moet u de hints voor opnieuw proberen na headers respecteren.
Als de clientcode informatie nodig heeft over een bepaalde virtuele machine, voert u een query uit op die VM in plaats van alle VM's in de resourcegroep of het hele abonnement op te geven en vervolgens de benodigde VIRTUELE machine 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 query uitvoeren op regionale eindpunten van de 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 bij te houden voor voltooiing dan polling uitvoeren op de resource-URL zelf (op basis van het provisioningState).

Volgende stappen

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

Contact met ons opnemen voor ondersteuning

Als u vragen hebt of hulp nodig hebt, maakt u een ondersteuningsaanvraag of stelt u ondersteuning voor de Azure-community. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.

Delen via