Solucionando problemas de erros de limitação da API

Artigo
04/18/2024

As solicitações do Azure Compute podem ser limitadas por assinatura e por região para ajudar no desempenho geral do serviço. Garantimos que todas as chamadas para o Provedor de Recursos de Computação do Azure (CRP), que gerencia recursos no namespace Microsoft.Compute, não excedam a taxa de solicitação de API máxima permitida. Este documento descreve a otimização da API, detalhes sobre como solucionar problemas de limitação e práticas recomendadas para evitar a limitação.

Limitação por Azure Resource Manager vs Provedores de Recursos

Como porta de entrada para o Azure, o Azure Resource Manager faz a autenticação e a validação de primeira ordem e a limitação de todas as solicitações de API recebidas. Os limites de taxa de chamada do Azure Resource Manager e os cabeçalhos HTTP de resposta de diagnóstico relacionados são descritos aqui.

Quando um cliente da API do Azure recebe um erro de limitação, o status HTTP é 429 Too Many Requests. Para entender se a limitação de solicitação é feita pelo Azure Resource Manager ou um provedor de recursos subjacente como CRP, inspecione o x-ms-ratelimit-remaining-subscription-reads para solicitações GET e cabeçalhos de respostax-ms-ratelimit-remaining-subscription-writes para solicitações não GET. Se a contagem de chamadas restantes estiver se aproximando de 0, o limite geral de chamadas da assinatura definido pelo Azure Resource Manager foi atingido. As atividades de todos os clientes de assinatura são contadas juntas. Caso contrário, a limitação vem do provedor de recursos de destino (aquele endereçado pelo segmento /providers/<RP> da URL de solicitação).

Cabeçalhos de resposta informativa de taxa de chamada

Cabeçalho	Formato do valor	Exemplo	Descrição
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet; 159	Contagem restante de chamadas de API para a política de limitação que cobre o depósito de recursos ou o grupo de operações, incluindo o destino desta solicitação
x-ms-request-charge	`<count>`	1	O número de contagens de chamadas "cobradas" para esta solicitação HTTP em relação ao limite da política aplicável. Normalmente é 1. As solicitações em lote, como para dimensionar um conjunto de dimensionamento de máquinas virtuais, podem cobrar várias contagens.

Observe que uma solicitação de API pode estar sujeita a várias políticas de limitação. Haverá um cabeçalho x-ms-ratelimit-remaining-resource separado para cada política.

Aqui está um exemplo de resposta para excluir a solicitação de conjunto de dimensionamento de máquina virtual.

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

Detalhes do erro de limitação

O status HTTP 429 é comumente usado para rejeitar uma solicitação porque um limite de taxa de chamadas foi atingido. Uma resposta típica de erro de limitação do Compute Resource Provider será semelhante ao exemplo abaixo (somente os cabeçalhos relevantes são mostrados):

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

A política com contagem de chamadas restantes igual a 0 é aquela devido à qual o erro de limitação é retornado. Neste caso, é HighCostGet. O formato geral do corpo da resposta é o formato geral de erro da API do Azure Resource Manager (conforme com OData). O código de erro principal, OperationNotAllowed, é aquele que o Fornecedor de Recursos de Computação usa para relatar erros de limitação (entre outros tipos de erros do cliente). A propriedade message do(s) erro(s) interno(s) contém uma estrutura JSON serializada com os detalhes da violação de limitação.

Conforme ilustrado acima, todo erro de limitação inclui o cabeçalho Retry-After, que fornece o número mínimo de segundos que o cliente deve esperar antes de tentar novamente a solicitação.

Taxa de chamada de API e analisador de erros de limitação

Uma versão de visualização de um recurso de solução de problemas está disponível para a API do provedor de recursos Compute. Esses cmdlets do PowerShell fornecem estatísticas sobre a taxa de solicitação de API por intervalo de tempo por operação e violações de limitação por grupo de operação (política):

As estatísticas de chamada de API podem fornecer grande percepção sobre o comportamento do(s) cliente(s) de uma assinatura e permitir a fácil identificação de padrões de chamada que causam limitação.

Uma limitação do analisador por enquanto é que ele não conta solicitações para tipos de recurso de disco e instantâneo (em suporte a discos gerenciados). Uma vez que reúne dados da telemetria do CRP, também não pode ajudar na identificação de erros de limitação do ARM. Mas eles podem ser identificados facilmente com base nos cabeçalhos de resposta distintos do ARM, conforme discutido anteriormente.

Os cmdlets do PowerShell estão usando uma API de serviço REST, que pode ser facilmente chamada diretamente pelos clientes (embora sem suporte formal ainda). Para ver o formato da solicitação HTTP, execute os cmdlets com a opção -Debug ou verifique sua execução com o Fiddler.

Práticas recomendadas

Não repita os erros de API de serviço do Azure incondicionalmente e/ou imediatamente. Uma ocorrência comum é o código do cliente entrar em um loop de repetição rápida ao encontrar um erro que não pode ser repetido. As novas tentativas acabarão esgotando o limite de chamadas permitidas para o grupo da operação de destino e afetarão outros clientes da assinatura.
Em casos de automação de API de alto volume, considere implementar a limitação automática proativa do lado do cliente quando a contagem de chamadas disponíveis para um grupo de operação de destino cair abaixo de um limite baixo.
Ao rastrear operações assíncronas, respeite as dicas de cabeçalho Retry-After.
Se o código do cliente precisar de informações sobre uma máquina virtual específica, consulte essa VM diretamente em vez de listar todas as VMs no grupo de recursos contido ou a assinatura inteira e, em seguida, escolher a VM necessária no lado do cliente.
Se o código do cliente precisar de VMs, discos e instantâneos de um local específico do Azure, use o formulário de consulta com base no local em vez de consultar todas as VMs de assinatura e, em seguida, filtre por local no lado do cliente: GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30 consulta para os pontos finais regionais do Fornecedor de Recursos de Computação.
Ao criar ou atualizar recursos de API em particular, VMs e conjuntos de dimensionamento de máquinas virtuais, é muito mais eficiente rastrear a operação assíncrona retornada até a conclusão do que sondar a própria URL do recurso (com base em provisioningState).

Próximas etapas

Para obter mais informações sobre diretrizes de repetição para outros serviços no Azure, consulte Novas diretrizes para serviços específicos.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.

Share via