Troubleshooting API throttling errors (Устранение ошибок регулирования API)

Применимо к: ✔️ виртуальным машинам Linux ✔️ виртуальным машинам Windows

Сводка

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

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

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

Когда клиент 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-адреса запроса).

Заголовки ответов, содержащие сведения о частоте вызовов

Обратите внимание, что запрос 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 Azure Resource Manager (совместим с OData). Основной код ошибки (OperationNotAllowed) — это код, используемый поставщиком вычислительных ресурсов для сообщения об ошибках регулирования (среди других типов ошибок клиента). Свойство внутренних ошибок message содержит сериализованную структуру файла JSON со сведениями о нарушении регулирования.

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

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

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

• Export-AzLogAnalyticRequestRateByInterval
• Export-AzLogAnalyticThrottledRequest

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

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

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

Лучшие практики

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

Следующие шаги

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