Мониторинг нормализованных единиц запросов в секунду для контейнера Azure Cosmos DB или учетной записи

Область применения: Nosql Mongodb Кассандра Гремлин Таблица

Azure Monitor для Azure Cosmos DB предоставляет представление метрик для мониторинга учетной записи и создания панелей мониторинга. Эта функция не требует явного включения или настройки каких-либо параметров — данные метрик Azure Cosmos DB собираются по умолчанию.

Определение метрики

Метрика нормализованного потребления ЕЗ — это метрика от 0 до 100 %, которая используется для измерения показателя использования подготовленной пропускной способности в базе данных или контейнере. Метрика создается с интервалами в одну минуту и определяется как максимальное использование ЕЗ/с во всех диапазонах ключей секций за интервал времени. Каждый диапазон ключей секций сопоставляется с одной физической секцией и назначается для хранения данных для диапазона возможных значений хэша. Как правило, чем выше процент нормализованных ЕЗ, тем больше вы использовали подготовленной пропускной способности. Кроме того, метрику можно использовать для просмотра использования отдельных диапазонов ключей секций в базе данных или контейнере.

Например, предположим, что у вас есть контейнер, в котором вы устанавливаете максимальную пропускную способность автомасштабирования в 20 000 ЕЗ/с (масштабирование от 2000 до 20 000 ЕЗ/с), и у вас есть два диапазона ключей секций (физические секции) P1 и P2. Так как Azure Cosmos DB распределяет подготовленную пропускную способность одинаково по всем диапазонам ключей секций, P1 и P2 могут масштабироваться в диапазоне от 1000 до 10 000 ЕЗ/с. Предположим, что за одну минуту в определенную секунду P1 потреблял 6000 единиц запросов, а P2 — 8000 единиц запросов. Нормализованное потребление ЕЗ составляет 60 % для P1 и 80 % для P2. Общее нормализованное потребление ЕЗ для всего контейнера — MAX(60%, 80%) = 80%.

Если вам нужно просматривать показатель потребления ЕЗ с интервалом в одну секунду вместе с типом операции, вы можете использовать подключаемую функцию Журналы диагностики и запросить данные таблицы PartitionKeyRUConsumption. Чтобы получить общий обзор операций и кода состояния приложения, выполняемого в ресурсе Azure Cosmos DB, можно использовать встроенную метрику "Всего запросов Azure Monitor" (API для NoSQL), "Запросы Mongo", "Gremlin Requests" или "Cassandra Requests". Позже можно будет отфильтровать эти запросы по коду состояния 429 и разделить их по типу операции.

Ожидаемые последствия и необходимые меры при высоких нормализованных значениях ЕЗ/с

Когда нормализованное значение ЕЗ достигает 100 % для заданного диапазона ключей секций, а клиент по-прежнему выполняет запросы в этом временном окне, равном 1 секунде, для этого конкретного диапазона ключей секций, он получает сообщение об ошибке, связанной с ограничением частоты (429).

Это не обязательно означает, что с вашим ресурсом возникла проблема. По умолчанию клиентские пакеты SDK для Azure Cosmos DB и инструменты импорта данных, такие как Фабрика данных Azure и библиотека массового исполнителя, автоматически повторяют запросы на 429. Повторная попытка обычно не превышает 9 раз. В результате, несмотря на то, что в метриках может появиться число 429, эти ошибки могут быть даже не возвращены в приложение.

Как правило, для рабочей нагрузки, предназначенной для рабочей среды, если для 1–5 % запросов отображаются коды 429 и ваша сквозная задержка является приемлемой, это верный признак того, что ЕЗ/с используются полностью. В этом случае метрика нормализованного потребления ЕЗ, которая приближается к показателю 100 % означает только то, что как минимум один диапазон ключей секций использовал всю подготовленную пропускную способность. Это приемлемо, так как общий показатель кодов 429 по-прежнему низок. В дальнейших действиях нет необходимости.

Чтобы определить, какой процент запросов к базе данных или контейнеру привел к поступлению кодов 429, в колонке учетной записи Azure Cosmos DB перейдите к разделу Аналитика>Запросы>Total Requests by Status Code (Всего запросов по коду состояния). Фильтр по конкретной базе данных и контейнеру. Для API для Gremlin используйте метрику запросов Gremlin.

Если метрика нормализованного потребления ЕЗ постоянно составляет 100 % в нескольких диапазонах ключей секций, а показатель кодов 429 превышает 5 %, рекомендуется увеличить пропускную способность. Вы можете узнать, какие операции имеют большое значение и каков показатель их пикового использования, с помощью метрик и журналов диагностики Azure Monitor. Следуйте инструкциям из статьи Рекомендации по масштабированию подготовленной пропускной способности (ЕЗ/с).

То, что нормализованный показатель ЕЗ достиг 100 %, не обязательно является причиной поступления сообщения об ошибке ограничения скорости 429. Причина в том, что нормализованный показатель ЕЗ — это одно значение, которое представляет максимальное использование по всем диапазонам ключей секций. Один диапазон ключей секций может быть занят, но другие диапазоны ключей секций могут без проблем обслуживать запросы. Например, если одна операция, такая как хранимая процедура, использует все ЕЗ/с в диапазоне ключей секций, это приведет к непродолжительному пику в метрике нормализованного потребления ЕЗ. В таких случаях ошибки, приводящие к ограничению скорости, отображаться не будут, пока общая частота запросов остается низкой или пока запросы выполняются к другим секциям в разных диапазонах ключей секций.

См. дополнительные сведения об интерпретации и отладке ошибок ограничения скорости 429.

Как отслеживать горячие секции

Метрику нормализованного потребления ЕЗ можно использовать для отслеживания наличия горячей секции рабочей нагрузки. Горячая секция возникает в момент, когда один или несколько ключей логических разделов потребляют непропорционально большое количество единиц запросов в секунду из-за большего объема запроса. Это может быть вызвано тем, что ключ раздела не распределяет запросы равномерно. В результате многие запросы направляются на небольшое подмножество логических секций (а следовательно, и диапазонов ключей секций), которые становятся "горячими". Так как все данные логической секции находятся в одном диапазоне ключей секций, а общий объем ЕЗ в секунду равномерно распределяется между всеми диапазонами ключей секций, то наличие горячего раздела может приводить к возникновению ошибок 429 и неэффективному использованию пропускной способности.

Как определить наличие горячей секции

Для проверки наличия горячей секции перейдите в раздел Аналитика>Пропускная способность>Нормализованное потребление на единицу запроса (%) по PartitionKeyRangeID. Фильтр по конкретной базе данных и контейнеру.

Каждое значение PartitionKeyRangeId соответствует одному физическому разделу. В случае наличия одной секции PartitionKeyRangeId, у которой нормализованное потребление на ЕЗ значительно выше, чем у других (например, одна постоянно загружена на 100 %, а другие — на 30 % или меньше), это может быть признаком горячей секции.

Чтобы определить логические секции, которые используют больше всего ЕЗ/с, а также рекомендуемые решения, ознакомьтесь со статьей Диагностика и устранение неполадок в Azure Cosmos DB: исключения из-за слишком высокой частоты запросов (429).

Нормализованное потребление ЕЗ и автомасштабирование

В метрике нормализованного потребления ЕЗ будет отображаться показатель 100 %, если как минимум один диапазон ключей секций использует все выделенные ЕЗ/с в любую взятую секунду в определенном интервале времени. Часто возникает вопрос, почему нормализованное потребление ЕЗ составляет 100 %, но служба Azure Cosmos DB не масштабировала ЕЗ/с до максимальной пропускной способности с использованием автомасштабирования?

Примечание.

Приведенные ниже сведения касаются текущей реализации автомасштабирования и в будущем могут быть изменены.

При использовании автомасштабирования Azure Cosmos DB масштабирует число ЕЗ/с до максимальной пропускной способности, только если нормализованный показатель потребления ЕЗ для длительного непрерывного периода с интервалом в пять секунд составляет 100 %. Это обеспечивает экономичную логику масштабирования для пользователя, так как гарантируется, что отдельные пиковые скачки не будут приводить к ненужному масштабированию и повышению затрат. При пиковых скачках система обычно масштабируется до значения, превышающего значение, установленное ранее для масштабирования ЕЗ/с, но меньшего, чем максимальное число ЕЗ/с.

Предположим, что у вас есть контейнер с максимальной пропускной способностью автомасштабирования в 20 000 ЕЗ/с (масштабирование от 2000 до 20 000 ЕЗ/с) и два диапазона ключей секций. Каждый диапазон ключей секций может масштабироваться от 1000 до 10 000 ЕЗ/с. Так как функция автомасштабирования подготавливает все необходимые ресурсы заранее, вы можете в любое время использовать до 20 000 ЕЗ/с. Предположим, что наблюдается скачок трафика, при котором показатель использования одного из диапазонов ключей секций за одну секунду составляет 10 000 ЕЗ/с. В следующие секунды использование возвращается к показателю 1000 ЕЗ/с. Так как метрика нормализованного потребления ЕЗ показывает самый высокий показатель использования за период во всех секциях, будет отображаться показатель 100 %. Но, так как показатель использования 100 % наблюдался только в течение одной секунды, функция автомасштабирования не будет выполнять автоматическое масштабирование до максимального показателя.

В результате, несмотря на то что автомасштабирование не было выполнено до максимального показателя, вы по-прежнему могли использовать общее число доступных ЕЗ/с. Чтобы проверить потребление ЕЗ/с, вы можете использовать подключаемую функцию "Журналы диагностики", чтобы запросить общее потребление единиц запросов в секунду во всех диапазонах ключей секций.

CDBPartitionKeyRUConsumption
| where TimeGenerated >= (todatetime('2022-01-28T20:35:00Z')) and TimeGenerated <= todatetime('2022-01-28T20:40:00Z')
| where DatabaseName == "MyDatabase" and CollectionName == "MyContainer"
| summarize sum(RequestCharge) by bin(TimeGenerated, 1sec), PartitionKeyRangeId
| render timechart

В общем для рабочей нагрузки с использованием автомасштабирования, выполняемой в рабочей среде, если от 1 до 5 % запросов сопровождаются кодом 429 и сквозная задержка приемлема, это верный признак того, что ЕЗ/с используются полностью. Даже если уровень нормализованного потребления ЕЗ иногда достигает 100 %, а автомасштабирование не выполняется до максимального показателя ЕЗ/с, это нормально, так как общий процент кодов 429 небольшой. Предпринимать какие-либо действия не требуется.

Совет

Если при использовании функции автомасштабирования нормализованное потребление ЕЗ постоянно находится на уровне 100 % и непрерывно выполняется автомасштабирование до максимального показателя ЕЗ/с, это означает, что использование пропускной способности, настраиваемое вручную, может быть более экономичным. Чтобы определить, что больше подойдет для вашей рабочей нагрузки (автомасштабирование или настройка пропускной способности вручную), ознакомьтесь со статьей Как сделать выбор между стандартной (ручной) и автомасштабируемой подготовленной пропускной способностью. Azure Cosmos DB также отправляет рекомендации Помощника по Azure на основе шаблонов рабочей нагрузки, чтобы рекомендовать пропускную способность вручную или автомасштабирования.

Просмотр метрики потребления нормализованных единиц запросов

1. Войдите на портал Azure.

2. На панели навигации слева выберите пункт Монитор, а затем выберите Метрики.

   

3. В области Метрики щелкните >Выбрать ресурс> и выберите требуемые подписку и группу ресурсов. Для типа ресурса выберите учетные записи Azure Cosmos DB, выберите одну из существующих учетных записей Azure Cosmos DB и нажмите кнопку "Применить".

   

4. Далее можно выбрать метрику из списка доступных метрик. Вы можете выбрать метрики, связанные с единицами запросов, хранилищем, задержкой, доступностью, Cassandra и т. д. Подробные сведения о всех доступных метриках в списке см. в статье с перечнем метрик по категориям. Давайте в этом примере выберем метрику потребления нормализованных единиц запросов и Максимум в качестве значения агрегата.

   Помимо этих сведений, можно также выбрать диапазон времени и степень детализации времени для метрик. Вы можете просмотреть метрики максимум за последние 30 дней. После применения фильтра отображается диаграмма на его основе.

   

Фильтры для метрики нормализованного потребления ЕЗ

Можно также отфильтровать метрики и отображаемую диаграмму по определенному значению CollectionName, DatabaseName, PartitionKeyRangeID и Region. Чтобы отфильтровать метрики, щелкните Добавить фильтр, а затем выберите требуемое свойство, например CollectionName и соответствующее значение, которое вас интересует. После этого на графе отобразится метрика нормализованного потребления ЕЗ для контейнера за выбранный период.

Метрики можно группировать с помощью параметра Применить разделение. Для баз данных с общей пропускной способностью метрика нормализованных единиц запросов показывает данные только со степенью детализации базы данных и не отображает данные в каждой коллекции. Таким образом, для базы данных с общей пропускной способностью вы не будете видеть данные при применении разделения по имени коллекции.

Метрика потребления нормализованных единиц запросов для каждого контейнера отображается, как показано на следующем рисунке.

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

• Мониторинг данных Azure Cosmos DB с помощью параметров диагностики в Azure.
• Аудит операций уровня управления Azure Cosmos DB
• Диагностика и устранение неполадок в Azure Cosmos DB: слишком большая частота запросов (429) исключений