Condividi tramite

Istruzioni per le richieste con limitazioni in Azure Resource Graph

Quando si usano i dati di Azure Resource Graph in modo programmatico, è importante considerare come la limitazione delle risorse influisca sui risultati delle query. La modifica del modo in cui vengono richiesti i dati può aiutare l'utente e l'organizzazione a evitare problemi di limitazione delle richieste e gestire tempestivamente il flusso di dati sulle risorse di Azure.

Questo articolo illustra quattro aree e modelli correlati alla creazione di query in Azure Resource Graph:

  • Informazioni sulle intestazioni di limitazione delle richieste.
  • Raggruppamento di query.
  • Distribuzione di query.
  • Effetto della paginazione.

Informazioni sulle intestazioni di limitazione delle richieste

Azure Resource Graph alloca un numero di quota per ogni utente in base a un intervallo di tempo. Ad esempio, un utente può inviare al massimo 15 query all'interno di ogni intervallo di 5 secondi senza limitazioni. Il valore della quota è determinato da molti fattori ed è soggetto a modifiche.

In ogni risposta alle query, Azure Resource Graph aggiunge due intestazioni di limitazione delle richieste:

  • x-ms-user-quota-remaining (int): la quota di risorse rimanenti per l'utente. Questo valore è associato al conteggio delle query.
  • x-ms-user-quota-resets-after (hh:mm:ss): la durata temporale fino alla reimpostazione del consumo della quota dell'utente.

Quando un'entità di sicurezza ha accesso a più di 10.000 sottoscrizioni all'interno dell'ambito di query del tenant o del gruppo di gestione, la risposta è limitata alle prime 10.000 sottoscrizioni e l'intestazione x-ms-tenant-subscription-limit-hit viene restituita come true.

Per illustrare il funzionamento delle intestazioni, viene ora esaminata una risposta di query con l'intestazione e i valori di x-ms-user-quota-remaining: 10 e x-ms-user-quota-resets-after: 00:00:03.

  • Nei prossimi 3 secondi, è possibile inviare al massimo 10 query senza limitazioni.
  • In 3 secondi, i valori di x-ms-user-quota-remaining e x-ms-user-quota-resets-after vengono reimpostati rispettivamente su 15 e 00:00:05.

Per un esempio dell'uso delle intestazioni per il backoff delle richieste di query, vedere l'esempio in Query in parallelo.

Raggruppamento delle query

Il raggruppamento delle query in base alla sottoscrizione, al gruppo di risorse o a una singola risorsa è più efficiente della parallelizzazione delle query. Il costo della quota di una query di dimensioni maggiori è spesso inferiore al costo della quota di molte query piccole e mirate. È consigliabile che le dimensioni del gruppo siano inferiori a 300.

  • Esempio di approccio scarsamente ottimizzato.

    // NOT RECOMMENDED
var header = /* your request header */
var subscriptionIds = /* A big list of subscriptionIds */

foreach (var subscriptionId in subscriptionIds)
{
    var userQueryRequest = new QueryRequest(
        subscriptions: new[] { subscriptionId },
        query: "Resources | project name, type");

    var azureOperationResponse = await this.resourceGraphClient
        .ResourcesWithHttpMessagesAsync(userQueryRequest, header)
        .ConfigureAwait(false);

// ...
}

  • Esempio di approccio di raggruppamento ottimizzato.

    // RECOMMENDED
var header = /* your request header */
var subscriptionIds = /* A big list of subscriptionIds */

const int groupSize = 100;
for (var i = 0; i <= subscriptionIds.Count / groupSize; ++i)
{
    var currSubscriptionGroup = subscriptionIds.Skip(i * groupSize).Take(groupSize).ToList();
    var userQueryRequest = new QueryRequest(
        subscriptions: currSubscriptionGroup,
        query: "Resources | project name, type");

    var azureOperationResponse = await this.resourceGraphClient
        .ResourcesWithHttpMessagesAsync(userQueryRequest, header)
        .ConfigureAwait(false);

  // ...
}

  • Esempio di un approccio di raggruppamento ottimizzato per ottenere più risorse in un'unica query.

    Resources | where id in~ ({resourceIdGroup}) | project name, type

    // RECOMMENDED
var header = /* your request header */
var resourceIds = /* A big list of resourceIds */

const int groupSize = 100;
for (var i = 0; i <= resourceIds.Count / groupSize; ++i)
{
    var resourceIdGroup = string.Join(",",
        resourceIds.Skip(i * groupSize).Take(groupSize).Select(id => string.Format("'{0}'", id)));
    var userQueryRequest = new QueryRequest(
        subscriptions: subscriptionList,
        query: $"Resources | where id in~ ({resourceIdGroup}) | project name, type");

    var azureOperationResponse = await this.resourceGraphClient
        .ResourcesWithHttpMessagesAsync(userQueryRequest, header)
        .ConfigureAwait(false);

  // ...
}

Scaglionamento delle query

A causa del modo in cui viene applicata la limitazione delle richieste, è consigliabile scaglionare le query. Ad esempio, anziché inviare contemporaneamente 60 query, scaglionare le query in quattro finestre di 5 secondi.

  • Pianificazione delle query non scaglionate.

    Conteggio delle query 60 0 0 0
    Intervallo di tempo (s) 0-5 5-10 10-15 15-20

  • Pianificazione delle query scaglionate.

    Conteggio delle query 15 15 15 15
    Intervallo di tempo (s) 0-5 5-10 10-15 15-20

Il codice seguente è un esempio di rispetto delle intestazioni di limitazione delle richieste durante l'esecuzione delle query su Azure Resource Graph.

while (/* Need to query more? */)
{
    var userQueryRequest = /* ... */
    // Send post request to Azure Resource Graph
    var azureOperationResponse = await this.resourceGraphClient
        .ResourcesWithHttpMessagesAsync(userQueryRequest, header)
        .ConfigureAwait(false);

    var responseHeaders = azureOperationResponse.response.Headers;
    int remainingQuota = /* read and parse x-ms-user-quota-remaining from responseHeaders */
    TimeSpan resetAfter = /* read and parse x-ms-user-quota-resets-after from responseHeaders */
    if (remainingQuota == 0)
    {
        // Need to wait until new quota is allocated
        await Task.Delay(resetAfter).ConfigureAwait(false);
    }
}

Query in parallelo

Anche se è consigliabile eseguire il raggruppamento piuttosto che la parallelizzazione, in alcuni casi non è possibile raggruppare facilmente le query. In questi casi, è possibile eseguire query in Azure Resource Graph inviando più query in modo parallelo. Nell'esempio seguente viene illustrato come eseguire il backoff in base alle intestazioni di limitazione delle richieste.

IEnumerable<IEnumerable<string>> queryGroup = /* Groups of queries  */
// Run groups in parallel.
await Task.WhenAll(queryGroup.Select(ExecuteQueries)).ConfigureAwait(false);

async Task ExecuteQueries(IEnumerable<string> queries)
{
    foreach (var query in queries)
    {
        var userQueryRequest = new QueryRequest(
            subscriptions: subscriptionList,
            query: query);
        // Send post request to Azure Resource Graph.
        var azureOperationResponse = await this.resourceGraphClient
            .ResourcesWithHttpMessagesAsync(userQueryRequest, header)
            .ConfigureAwait(false);

        var responseHeaders = azureOperationResponse.response.Headers;
        int remainingQuota = /* read and parse x-ms-user-quota-remaining from responseHeaders */
        TimeSpan resetAfter = /* read and parse x-ms-user-quota-resets-after from responseHeaders */
        if (remainingQuota == 0)
        {
            // Delay by a random period to avoid bursting when the quota is reset.
            var delay = (new Random()).Next(1, 5) * resetAfter;
            await Task.Delay(delay).ConfigureAwait(false);
        }
    }
}

Paginazione

Siccome Azure Resource Graph restituisce un massimo di 1.000 voci in una singola risposta di query, potrebbe essere necessario paginare le query per ottenere il set di dati completo desiderato. Tuttavia, alcuni client di Azure Resource Graph gestiscono la paginazione in modo diverso rispetto ad altri.

Quando si usa l’SDK ResourceGraph, è necessario gestire la paginazione passando lo skip token restituito dalla risposta della query precedente alla query paginata successiva. Ciò implica che è necessario raccogliere i risultati di tutte le chiamate paginate e combinarli insieme alla fine. In questo caso, ogni query paginata inviata prende una quota di query.

var results = new List<object>();
var queryRequest = new QueryRequest(
  subscriptions: new[] { mySubscriptionId },
  query: "Resources | project id, name, type");
var azureOperationResponse = await this.resourceGraphClient
  .ResourcesWithHttpMessagesAsync(queryRequest, header)
  .ConfigureAwait(false);
while (!string.IsNullOrEmpty(azureOperationResponse.Body.SkipToken))
{
  queryRequest.Options ??= new QueryRequestOptions();
  queryRequest.Options.SkipToken = azureOperationResponse.Body.SkipToken;
  var azureOperationResponse = await this.resourceGraphClient
      .ResourcesWithHttpMessagesAsync(queryRequest, header)
      .ConfigureAwait(false);
  results.Add(azureOperationResponse.Body.Data.Rows);

// Inspect throttling headers in query response and delay the next call if needed.
}

ARG GET / LIST API

ARG introduce un approccio alternativo alle chiamate API GET e List esistenti del piano di controllo di Azure che migliorano la scalabilità e le prestazioni, risolvendo al tempo stesso i problemi di limitazione per i clienti di Azure. Questa API è attualmente supportata solo per le risorse nella tabella resources e nella tabella computeresources.

L'API GET/LIST di ARG è destinata agli scenari in cui è necessaria una ricerca di una singola risorsa in base all'ID oppure si elencano le risorse con lo stesso tipo e all'interno di un determinato ambito (sottoscrizione, gruppo di risorse o risorsa padre).

È consigliabile prendere in considerazione l'API GET/LIST di ARG se il servizio rientra in una o più delle categorie seguenti:

  • Il servizio esegue un volume elevato di chiamate GET per recuperare i dati per una risorsa destinata a una singola sottoscrizione o a un singolo RG e non richiede batch di record da più sottoscrizioni tramite filtri o join complessi.

  • Il servizio genera un volume elevato di richieste GET ed è a rischio di:

    • Affrontare limitazioni.
    • Concorrenza per la limitazione della quota con altri clienti.
    • Il tuo servizio potrebbe essere soggetto a un grande numero di richieste GET simultanee in un breve periodo di tempo.

  • Il servizio richiede disponibilità elevata e prestazioni più veloci per le richieste GET, per la gestione delle singole risorse o l'enumerazione di un elenco di risorse all'interno di un determinato ambito.

  • È necessaria la visualizzazione completa delle istanze delle macchine virtuali e delle macchine virtuali del set di scalabilità di macchine virtuali in modalità di orchestrazione Uniform e Flex.

    Annotazioni

    L'API GET/LIST di ARG non supporta lo stato di integrità delle VM e delle VMSS, né lo stato di esecuzione delle estensioni in instanceView. Per altre informazioni sui limiti dell'API GET/LIST di ARG, vedere le limitazioni note.

Se la risorsa a cui si è interessati, si trova nella tabella o computeresources nella resources tabella e rientra in una delle categorie precedenti, usare l'API GET/LIST di ARG.

Le richieste vengono ancora limitate?

Se sono state usate le raccomandazioni di questo articolo, si è tentata la soluzione API GET/LIST di Azure Resource Graph e le query di Azure Resource Graph continuano a essere limitate, contattare il team di Azure Resource Graph. Il team supporta Azure Resource Graph, ma non supporta la limitazione delle richieste di Microsoft Graph.

Specificare questi dettagli quando si contatta il team di Azure Resource Graph:

  • Il caso d'uso specifico e le esigenze aziendali per cui è necessario un limite superiore per la limitazione delle richieste.
  • A quante risorse si ha accesso? Quante di esse vengono restituite da una singola query?
  • Quali tipi di risorse sono rilevanti?
  • Il modello di query usato. X query per Y secondi, e così via.

Passaggi successivi