Агрегирование и отображение метрик в Azure Monitor объяснено

В этой статье объясняется агрегирование метрик в базе данных временных рядов, которая поддерживает метрики платформы Azure Monitor и пользовательские метрики. Эта статья также относится к стандартным метрикам Application Insights.

Информация в этой статье сложна и предоставляется для тех, кто хочет глубже разобраться в системе метрик. Для эффективного использования Azure Monitor метрик не нужно понимать.

Общие сведения и термины

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

Для начала следует дать четкое определение нескольким терминам:

• Значение метрики — единственное значение измерения, полученное для определенного ресурса.
• База данных временных рядов — база данных , оптимизированная для хранения и извлечения точек данных, содержащих значение и соответствующую метку времени.
• Период времени — общий промежуток времени.
• Интервал времени — период времени между получением двух значений метрики.
• Диапазон времени — период времени, отображаемый на диаграмме. Стандартное значение по умолчанию — 24 часа. Доступны только определенные диапазоны.
• Степень детализации времени или интервал времени — период времени, используемый для агрегирования значений вместе, чтобы разрешить их отображение на диаграмме. Доступны только определенные диапазоны. Текущее минимальное значение составляет одну минуту. Степень детализации времени должна быть меньше, чем выбранный диапазон времени, чтобы ее можно было использовать, иначе будет отображаться только одно значение для всей диаграммы.
• Тип агрегирования — тип статистики, рассчитанный на основе нескольких значений метрики.
• Агрегирование — процесс принятия нескольких входных значений и их последующего использования для получения одного выходного значения с помощью правил, определенных типом агрегирования. Например, получение среднего значения для нескольких значений.

Обзор процесса агрегирования метрик

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

Типы агрегата

В обозревателе метрик доступны пять основных типов агрегирования. Обозреватель метрик скрывает агрегаты, которые не имеют значения и не могут использоваться для данной метрики.

• Sum — сумма всех значений, отсканированных на протяжении интервала агрегирования. Иногда этот тип также называется общим агрегированием.
• Count — количество измерений, отсканированных на протяжении интервала агрегирования. Количество не учитывает значение измерения, а только число записей.
• Average — среднее значение метрик, отсканированных на протяжении интервала агрегирования. Для большинства метрик это значение является суммой или количеством.
• Min — наименьшее значение, отсканированное на протяжении интервала агрегирования.
• Max — наибольшее значение, отсканированное на протяжении интервала агрегирования.

Например, предположим, что на диаграмме отображается метрика суммарного исходящего трафика для виртуальной машины с использованием агрегата SUM в течение последнего 24-часового интервала времени. Диапазон времени и степень детализации можно изменить в правом верхнем углу диаграммы, как показано на следующем снимке экрана.

Для степени детализации времени задано значение 30 минут, а для диапазона времени — 24 часа:

• Диаграмма составлена из 48 точек данных. Это 24 часа, умноженные на 2 точки данных в час (1 точка каждые 30 минут), агрегированные в виде 1-минутных точек данных.
• Линейный график соединяет 48 точек в области построения диаграммы.
• Каждая точка данных представляет собой сумму всех исходящих сетевых байтов, отправленных в течение каждого из соответствующих 30-минутных периодов времени.

Щелкайте изображения в этом разделе, чтобы просматривать их увеличенные версии.

Если задать степень детализации времени в 15 минут, диаграмма будет содержать 96 агрегированных точек данных. То есть 60/15 мин = 4 точки данных в час x 24 часа.

При степени детализации времени в 5 минут диаграмма будет содержать 24 x (60/5) = 288 точек.

При степени детализации времени, равной 1 минуте (наименьшее возможное значение на диаграмме), диаграмма будет содержать 24 x 60/1 = 1440 точек.

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

Степень детализации времени позволяет настроить на диаграмме соотношение "сигнал — шум". Высокие уровни агрегации удаляют шум и сглаживают пики. Обратите внимание на варьирования в нижней части 1-минутной диаграммы и на то, как они сглаживаются при переходе к более высоким значениям степени детализации.

Это поведение сглаживания важно при отправке этих данных в другие системы, такие как оповещения. Как правило, вы не хотите быть оповещены короткими пиками времени ЦП более 90%. Однако, если в течение пяти минут нагрузка процессора остается на уровне 90 %, это, скорее всего, важно. Если вы настроили правило генерации оповещений для ЦП (или любой метрики), увеличение степени детализации времени может уменьшить количество получаемых ложных предупреждений.

Важно установить", что "нормально" для рабочей нагрузки, чтобы узнать, какой интервал времени лучше всего подходит. Это одно из преимуществ динамических оповещений, что является отдельной темой, не рассматриваемой в этой статье.

Как система получает метрики

Сбор данных зависит от определенной метрики.

Частота сбора измерений

Существует два типа периодов сборов:

• Регулярный — метрика собирается в постоянный интервал времени, который не меняется.

• На основе действий — метрика собирается в зависимости от того, когда происходит транзакция определенного типа. Каждая транзакция имеет запись метрики и отметку времени. Они не собираются с регулярными интервалами, поэтому за заданный период времени существует разное количество записей.

Степень детализации

Наименьший интервал времени составляет 1 минуту, однако базовая система может сканировать данные быстрее в зависимости от метрики. Например, процент загрузки ЦП для виртуальной машины Azure сканируется с интервалами в 15 секунд. Поскольку сбои HTTP отслеживаются как транзакции, их количество может легко стать больше одного в минуту. Другие метрики, такие как служба хранилища SQL, фиксируются каждые 20 минут. Этот выбор зависит от конкретного поставщика и типа ресурса. Большинство старается обеспечить как можно меньший интервал.

Измерения, разделение и фильтрация

Метрики сканируются для каждого отдельного ресурса. Однако уровень, на котором метрики собираются, хранятся и могут быть отображены на диаграмме, может быть разным. Этот уровень представлен другими метриками, доступными в метрических измерениях. Каждый отдельный поставщик ресурсов сам определяет, насколько подробными будут собираемые им данные. Azure Monitor всего лишь определяет, как такие данные должны быть представлены и сохранены.

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

Например, Microsoft.ApiManagement/service использует для многих метрик в качестве измерения Расположение.

• Одна из таких метрик — емкость. Наличие измерения Расположение означает, что базовая система хранит запись метрики для вместимости каждого расположения, а не только одну запись метрики для суммарного значения. Извлеките или разбиите эти сведения на диаграмме метрик.

• При просмотре Общей длительности запросов шлюза можно заметить 2 измерения, Расположение и Имя узла, что опять же позволяет узнать расположение длительности, а также имя хоста, из которого она поступила.

• Одна из более гибких метрик, Запросы, имеет 7 различных измерений.

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

Используйте разделение и фильтрацию вместе, чтобы разобраться в проблеме. Ниже приведен пример графика, отображающего среднее количество байтов записи на Диске для группы виртуальных машин в группе ресурсов. У нас есть сводка всех виртуальных машин с этой метрикой, но нам может потребоваться выяснить, какие машины вызывают пики около 6 утра. Являются ли они одной и той же машиной? Сколько компьютеров в этом задействовано?

Щелкайте изображения в этом разделе, чтобы просматривать их увеличенные версии.

При применении разделения можно увидеть базовые данные, однако они немного запутанные. Оказывается, на приведенной выше диаграмме агрегировано 20 виртуальных машин. В данном случае мы использовали мышь, чтобы навести курсор на большую пиковую нагрузку, что произошла в 6 утра. В результате мы узнали, что ее причиной является CH-DCVM11. Но невозможно увидеть остальные данные, связанные с этой виртуальной машиной, из-за других виртуальных машин, загромождающих диаграмму.

С помощью фильтрации можно очистить диаграмму, чтобы увидеть, что происходит на самом деле. Проверьте или снимите флажок виртуальных машин, которые вы хотите просмотреть. Обратите внимание на точечные линии. Раздел NULL и ноль значений далее в этой статье объясняет, что представляют эти пунктирные строки.

Дополнительные сведения о том, как отображать данные разделения измерений на диаграмме обозревателя метрик, см. в разделе "Использование фильтров измерений" и разделения.

NULL и нулевые значения

Если система ожидает данные метрики от ресурса, но не получает их, она записывает значение NULL. Значение NULL отличается от нулевого значения. Это особенно важно при вычислении агрегатов и построении диаграмм. Значения NULL не считаются допустимыми измерениями.

Различные диаграммы отображают NULLs разными способами. Точечные графики не отображают точку на диаграмме. В столбчатых диаграммах не отображается столбец. На линейных диаграммах значение NULL может отображаться как пунктирные или пунктирные линии, например пунктирные линии в диаграмме с разделенными и отфильтрованными байтами диска, показанной ранее в этой статье. При вычислении средних значений, включающих NULLs, система использует меньше точек данных для получения среднего значения. Это поведение иногда может привести к неожиданному падению значений на диаграмме, хотя меньше, чем если значение было преобразовано в ноль и использовалось в качестве допустимой точки данных.

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

В оповещениях Azure Monitor используются значения, которые поставщик ресурсов записывает в базу данных метрик, поэтому важно знать, как поставщик ресурсов обрабатывает значения NULL, предварительно просмотрев данные.

Как работает агрегирование

Диаграммы метрик, показанные ранее в этой статье, отображают различные типы агрегированных данных. Система предварительно агрегирует данные, чтобы запрашиваемые диаграммы отображались быстрее без множества повторяющихся вычислений.

В этом примере:

• Вы собираете фиктивную метрику транзакций, называемую сбоями HTTP.
• Сервер — это измерение для метрики Сбои HTTP.
• У нас есть 3 сервера — сервер A, B и C.

Чтобы упростить объяснение, мы начнем с типа агрегирования «СУММ».

Агрегирование от менее чем 1 минуты до 1 минуты

Во-первых, система собирает необработанные данные метрик и сохраняет его в базе данных метрик Azure Monitor. В этом случае система сохраняет записи транзакций с меткой времени для каждого сервера, так как сервер является измерением. Так как наименьший период времени, доступный клиентам, составляет одну минуту, система объединяет эти метки времени в одноминутные значения метрик для каждого отдельного сервера. На следующем рисунке показан процесс агрегирования для серверов B. Серверы A и C используют один и тот же процесс, но имеют разные данные.

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

Агрегирование измерений

Затем 1-минутные вычисления сворачиваются по отдельным измерениям и снова сохраняются в виде отдельных записей. В этом случае все данные со всех отдельных серверов агрегируются в метрику с 1-минутным интервалом и сохраняются в базе данных метрик для использования в последующих агрегациях.

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

Выше показано только одно измерение, однако тот же процесс агрегирования и хранения происходит для всех измерений, поддерживаемых метрикой.

• Собирайте значения в 1-минутные агрегированные наборы по этому измерению. Сохраните эти значения.
• Свернуть измерение в 1 минуту агрегированной суммы. Сохраните эти значения.

Рассмотрим еще одно измерение сбоев HTTP, именуемое NetworkAdapter. Допустим, у нас есть разное количество адаптеров на каждый сервер.

• Сервер A имеет один адаптер
• Сервер B имеет два адаптера
• Сервер С имеет три адаптера

Мы соберем данные для следующих транзакций отдельно. Они будут помечены:

• Время
• Значение
• Сервер, с которого поступила транзакция
• Адаптер, из которого поступила транзакция

Затем каждый из этих субминутных потоков будет агрегирован в виде 1-минутного значения временного ряда и сохранен в базе данных метрик Azure Monitor:

• Сервер A, адаптер 1
• Сервер B, адаптер 1
• Сервер B, адаптер 2
• Сервер C, адаптер 1
• Сервер C, адаптер 2
• Сервер C, адаптер 3

Кроме того, будут сохранены следующие свернутые агрегации.

• Сервер A, адаптер 1 (поскольку нечего сворачивать, он будет зафиксирован заново)
• Сервер B, адаптер 1+2
• Сервер C, адаптер 1+2+3
• Все серверы, все адаптеры

Это показывает, что метрики с большим количеством измерений имеют большее число агрегатов. Здесь не так важно знать все перестановки, главное — уловить суть. Для системы важно, чтобы как отдельные, так и агрегированные данные хранились для получения быстрого доступа к любой диаграмме. Система выбирает либо наиболее подходящую сохраненную агрегацию, либо базовые необработанные данные, в зависимости от вашего выбора отображения.

Агрегирование без измерений

Так как эта метрика имеет сервер измерений, разделение и фильтрация предоставляют базовые данные для серверов A, B и C, как описано ранее в этой статье. Если метрика не имеет сервера в качестве измерения, вы можете получить доступ только к агрегированным 1-минутным суммам, отображаемым в черном виде на схеме. То есть значения 3, 6, 6, 9 и т. д. Система также не агрегирует разделенные значения, которые обозреватель метрик не отображает, а REST API метрик не возвращает.

Просмотр временной детализации выше 1 минуты

Если вы запрашиваете метрики с более грубой детализацией, система использует агрегированные суммы за 1 минуту для вычисления сумм для более крупной временной детализации. Ниже точечными линиями показан метод суммирования для 2-минутной и 5-минутной степени детализации времени. Опять же, мы показываем только тип агрегирования СУММ для простоты.

Для 2-минутной степени детализации времени.

Для 5-минутной степени детализации времени.

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

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

Пример агрегирования с несколькими типами и значениями NULL

Ниже приведен более крупный пример, в котором используются значения фиктивной метрики, называемой временем ответа HTTP в миллисекундах. Здесь мы представляем другие уровни сложности.

1. Показаны агрегирование для суммы, количества, наименьшего и наибольшего значения, а также расчет среднего значения.
2. Отображены также значения NULL и их влияние на вычисления.

Рассмотрим следующий пример. Поля и стрелки показывают примеры агрегирования и расчета значений.

Тот же 1-минутный процесс предварительного агрегирования, который описан в предыдущем разделе, выполняется для суммы, количества, наибольшего и наименьшего значения. Тем не менее среднее значение не является предварительно агрегированным. Он пересчитывается с помощью агрегированных данных, чтобы избежать ошибок вычисления.

Рассмотрим минуту 6 для агрегирования за одну минуту, как выделено на предыдущей схеме агрегирования. В эту минуту сервер B перешел в автономный режим и перестал передавать данные, скорее всего, из-за перезагрузки.

Для минуты 6 из приведенного выше примера вычисленные типы 1-минутного агрегирования такие:

Красным цветом текста отмечены значения, которые можно считать выходящими за пределы нормы, а также показано, как они распространяются (или не распространяются) по мере увеличения степени детализации времени. Обратите внимание, что значения Min и Max указывают на наличие базовых аномалий, а Average и Sums теряют эту информацию по мере увеличения степени детализации времени.

NULLs также дают лучшее вычисление среднего, чем если бы вместо этого использовались нули.

Дальнейшие шаги

• Анализ метрик с помощью обозревателя метрик Azure Monitor