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

Область применения: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows

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

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

Azure Resource Manager в качестве "входной двери" Azure выполняет аутентификацию и первоочередную проверку, а также регулирование всех входящих запросов 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-адреса запроса).

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

Обратите внимание, что запрос 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/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30.
• При создании или обновлении ресурсов API, в частности виртуальных машин и масштабируемого набора виртуальных машин, гораздо более эффективно отслеживать завершение возвращаемой асинхронной операции, а не опрашивать URL-адрес ресурса (на основе provisioningState).

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

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

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

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