Устранение ошибок регулирования API

Статья
04/18/2024

Запросы вычислений Azure могут регулироваться в подписке и для каждого региона, чтобы помочь с общей производительностью службы. Мы гарантируем, что все вызовы к поставщику вычислительных ресурсов Azure (CRP), который управляет ресурсами в пространстве имен Microsoft.Compute, не превышают максимально допустимую частоту запросов API. В этом документе описывается регулирование API, сведения об устранении неполадок с регулированием и рекомендации по предотвращению регулирования.

Регулирование между azure Resource Manager и поставщиками ресурсов

Как входная дверь в Azure, Azure Resource Manager выполняет проверку подлинности, проверку первого порядка и регулирование всех входящих запросов API. Здесь описаны ограничения частоты вызовов Azure Resource Manager и связанные заголовки HTTP ответов диагностики.

Когда клиент API Azure получает ошибку регулирования, состояние HTTP равно 429 Слишком много запросов. Чтобы понять, выполняется ли регулирование запросов azure Resource Manager или базовым поставщиком ресурсов, таким как CRP, проверьте x-ms-ratelimit-remaining-subscription-reads на наличие запросов GET и x-ms-ratelimit-remaining-subscription-writes заголовков ответов для запросов, отличных от GET. Если оставшееся число вызовов приближается к 0, достигнуто общее ограничение на вызовы подписки, определенное azure Resource Manager. Действия всех клиентов подписки учитываются вместе. В противном случае регулирование поступает от целевого поставщика ресурсов (адреса /providers/<RP> в сегменте URL-адреса запроса).

Заголовки информационных ответов о частоте вызовов

Заголовок	Формат значения	Пример	Описание
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet; 159	Количество оставшихся вызовов API для политики регулирования, охватывающей контейнер ресурсов или группу операций, включая целевой объект этого запроса.
x-ms-request-charge	`<count>`	1	Количество вызовов, взимаемых за этот HTTP-запрос, учитывается в соответствии с ограничением применимой политики. Чаще всего это 1. Пакетные запросы, например для масштабирования масштабируемого набора виртуальных машин, могут взиматься по нескольким счетчикам.

Обратите внимание, что запрос API может подвергаться нескольким политикам регулирования. Для каждой политики будет отдельный x-ms-ratelimit-remaining-resource заголовок.

Ниже приведен пример ответа на удаление запроса масштабируемого набора виртуальных машин.

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

Сведения об ошибке регулирования

Состояние HTTP 429 обычно используется для отклонения запроса, так как достигнуто ограничение скорости звонков. Типичный ответ об ошибке регулирования от поставщика вычислительных ресурсов будет выглядеть так, как показано в приведенном ниже примере (показаны только соответствующие заголовки):

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

Политика с оставшимся числом вызовов 0 — это политика, из-за которой возвращается ошибка регулирования. В данном случае это HighCostGet. Общий формат текста ответа — это общий формат ошибки API Resource Manager Azure (соответствующий OData). Main код ошибки, OperationNotAllowed, является поставщиком вычислительных ресурсов, который используется для сообщения об ошибках регулирования (среди других типов ошибок клиента). Свойство message внутренних ошибок содержит сериализованную структуру JSON с подробными сведениями о нарушении регулирования.

Как показано выше, каждая ошибка регулирования включает Retry-After заголовок, который предоставляет минимальное количество секунд, которое клиент должен ждать перед повтором запроса.

Анализатор ошибок частоты вызовов API и регулирования

Предварительная версия функции устранения неполадок доступна для API поставщика вычислительных ресурсов. Эти командлеты PowerShell предоставляют статистику о частоте запросов API за интервал времени для каждой операции и о нарушениях регулирования для каждой группы операций (политики):

Статистика вызовов API позволяет получить подробные сведения о поведении клиентов подписки и легко определить шаблоны вызовов, вызывающие регулирование.

Ограничение анализатора в настоящее время заключается в том, что он не подсчитывает запросы для дисков и snapshot типов ресурсов (для поддержки управляемых дисков). Так как он собирает данные из телеметрии CRP, он также не может помочь в выявлении ошибок регулирования из ARM. Но их можно легко определить на основе отличительных заголовков ответов ARM, как обсуждалось ранее.

Командлеты PowerShell используют API службы REST, который можно легко вызвать напрямую клиентами (хотя и без официальной поддержки). Чтобы просмотреть формат HTTP-запроса, выполните командлеты с параметром -Debug или просмотрите их выполнение с помощью Fiddler.

Лучшие методики

Не повторяйте ошибки API службы Azure без каких-либо условий и (или) немедленно. Обычно клиентский код попадает в цикл быстрых повторных попыток при обнаружении ошибки, которая не поддерживает повторную попытку. Повторные попытки в конечном итоге исчерпывают допустимое ограничение на вызовы для группы целевой операции и влияют на других клиентов подписки.
В случаях автоматизации API большого объема рекомендуется реализовать упреждающее самостоятельное регулирование на стороне клиента, когда доступное число вызовов для целевой группы операций падает ниже некоторого низкого порогового значения.
При отслеживании асинхронных операций учитывайте указания заголовков Retry-After.
Если коду клиента требуются сведения о конкретной виртуальной машине, запросите ее напрямую вместо перечисления всех виртуальных машин в содержащейся группе ресурсов или всей подписке, а затем выберите необходимую виртуальную машину на стороне клиента.
Если клиентскому коду требуются виртуальные машины, диски и моментальные снимки из определенного расположения Azure, используйте форму запроса на основе расположения вместо запроса ко всем виртуальным машинам подписки и последующей фильтрации по расположению на стороне клиента: GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30 запрос к региональным конечным точкам поставщика вычислительных ресурсов.
При создании или обновлении ресурсов API, в частности виртуальных машин и масштабируемых наборов виртуальных машин, гораздо эффективнее отслеживать возвращаемую асинхронную операцию до завершения, чем опрашивать сам URL-адрес ресурса (на provisioningStateоснове ).

Дальнейшие действия

Дополнительные сведения о руководстве по повторным попыткам для других служб в Azure см. в статье Руководство по повторным попыткам для конкретных служб.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.