Risoluzione degli errori di limitazione delle API

Articolo
04/18/2024

Le richieste di calcolo di Azure possono essere limitate in base a una sottoscrizione e in base all'area per migliorare le prestazioni complessive del servizio. Garantiamo che tutte le chiamate al Provider di risorse di Calcolo di Azure (CRP), che gestisce le risorse nello spazio dei nomi Microsoft. Compute, non superano la frequenza massima consentita di richieste API. Questo documento descrive la limitazione delle API, i dettagli su come risolvere i problemi di limitazione e le procedure consigliate per evitare di subire limitazioni.

Limitazione da parte di Azure Resource Manager rispetto ai provider di risorse

Come frontdoor di Azure, Azure Resource Manager esegue l'autenticazione, la convalida di primo ordine e la limitazione di tutte le richieste API in ingresso. I limiti di frequenza delle chiamate di Azure Resource Manager e le relative intestazioni HTTP di risposta diagnostica sono descritti qui.

Quando un client API di Azure riceve un errore di limitazione, lo stato HTTP è 429 troppe richieste. Per capire se la limitazione delle richieste viene eseguita da Azure Resource Manager o da un provider di risorse sottostante come CRP, esaminare x-ms-ratelimit-remaining-subscription-reads per le richieste GET e le intestazioni di risposta x-ms-ratelimit-remaining-subscription-writes per le richieste non GET. Se il numero di chiamate rimanenti si avvicina a 0, è stato raggiunto il limite di chiamate generale della sottoscrizione definito da Azure Resource Manager. Le attività di tutti i client in abbonamento vengono conteggiate insieme. In caso contrario, la limitazione proviene dal provider di risorse di destinazione (quello indirizzato dal segmento /providers/<RP> dell'URL della richiesta).

Intestazioni di risposta informative sulla frequenza di chiamata

Intestazione	Formato valore	Esempio	Descrizione
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet; 159	Conteggio delle chiamate API rimanenti per il criterio di limitazione che copre il bucket di risorse o il gruppo di operazioni, inclusa la destinazione di questa richiesta
x-ms-request-charge	`<count>`	1	Il numero di conteggi di chiamata "addebitati" per questa richiesta HTTP rispetto al limite del criterio applicabile. Questo è più tipicamente 1. Le richieste batch, ad esempio per il ridimensionamento di un set di scalabilità di macchine virtuali, possono addebitare più conteggi.

Tieni presente che una richiesta API può essere soggetta a più criteri di limitazione. Ci sarà un'intestazione x-ms-ratelimit-remaining-resource separata per ogni criterio.

Ecco una risposta di esempio per eliminare la richiesta del set di scalabilità di macchine virtuali.

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

Dettagli sull'errore di limitazione

Lo stato HTTP 429 viene comunemente utilizzato per rifiutare una richiesta perché è stato raggiunto un limite di frequenza di chiamata. Una tipica risposta di errore di limitazione da parte di Compute Resource Provider avrà l'aspetto dell'esempio seguente (vengono mostrate solo le intestazioni pertinenti):

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

Il criterio con conteggio delle chiamate rimanenti pari a 0 è quello a causa del quale viene restituito l'errore di limitazione. In questo caso è HighCostGet. Il formato complessivo del corpo della risposta è il formato di errore dell'API di Azure Resource Manager generale (conforme a OData). Il codice di errore principale, OperationNotAllowed, è quello utilizzato dal Provider delle risorse di calcolo per segnalare gli errori di limitazione (tra gli altri tipi di errori del client). La proprietà message degli errori interni contiene una struttura JSON serializzata con i dettagli della violazione della limitazione.

Come illustrato in precedenza, ogni errore di limitazione include l'intestazione Retry-After, che fornisce il numero minimo di secondi che il client deve attendere prima di tentare nuovamente la richiesta.

Tasso di chiamata API e analizzatore di errori di throttling

È disponibile una versione di anteprima di una funzione di risoluzione dei problemi per l'API del provider di risorse di calcolo. Questi cmdlet di PowerShell forniscono statistiche sulla frequenza delle richieste API per intervallo di tempo per operazione e violazioni della limitazione per gruppo operativo (criterio):

Le statistiche delle chiamate API possono fornire informazioni approfondite sul comportamento dei client di un abbonamento e consentire una facile identificazione dei modelli di chiamata che causano il throttling.

Una limitazione dell'analizzatore per il momento è che non conta le richieste per i tipi di risorsa disco e snapshot (a supporto dei dischi gestiti). Poiché raccoglie dati dalla telemetria di CRP, non può nemmeno aiutare a identificare gli errori di throttling da ARM. Ma quelli possono essere identificati facilmente in base alle intestazioni di risposta ARM distintive, come discusso in precedenza.

I cmdlet di PowerShell usano un'API del servizio REST, che può essere facilmente richiamata direttamente dai client (anche se senza ancora supporto formale). Per visualizzare il formato della richiesta HTTP, esegui i cmdlet con l'opzione -Debug o snoop sulla loro esecuzione con Fiddler.

Procedure consigliate

Non ripetere gli errori dell'API del servizio di Azure incondizionatamente e/o immediatamente. È un'occorrenza comune che il codice client entri in un ciclo di nuovi tentativi rapidi quando incontra un errore che non può essere ritentato. I tentativi alla fine esauriranno il limite di chiamate consentito per il gruppo dell'operazione di destinazione e influiranno su altri client dell'abbonamento.
Nei casi di automazione delle API ad alto volume, prendere in considerazione l'implementazione dell'auto-limitazione proattiva lato client quando il conteggio delle chiamate disponibili per un gruppo operativo di destinazione scende al di sotto di una soglia minima.
Quando si tiene traccia delle operazioni asincrone, rispettare i suggerimenti dell'intestazione Retry-After.
Se il codice client necessita di informazioni su una particolare macchina virtuale, eseguire una query direttamente sulla VM invece di elencare tutte le VM nel gruppo di risorse contenente o l'intera sottoscrizione e quindi scegliere la VM necessaria sul lato client.
Se il codice client richiede macchine virtuali, dischi e snapshot da un percorso di Azure specifico, utilizzare il modulo della query basato sul percorso invece di eseguire query su tutte le macchine virtuali della sottoscrizione e quindi filtrare in base al percorso sul lato client: query GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30 agli endpoint regionali del Provider delle risorse di calcolo.
Durante la creazione o l'aggiornamento di risorse API, in particolare macchine virtuali e set di scalabilità di macchine virtuali, è molto più efficiente tenere traccia dell'operazione asincrona restituita fino al completamento piuttosto che eseguire il polling sull'URL della risorsa (in base a provisioningState).

Passaggi successivi

Per altre informazioni sulle indicazioni sui tentativi per altri servizi in Azure, vedere Indicazioni sui tentativi per servizi specifici.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.