Пользовательские метрики в Azure Monitor (Предварительная версия)

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

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

Azure Monitor пользовательские метрики в настоящее время доступны в общедоступной предварительной версии.

Способы отправки пользовательских метрик

Пользовательские метрики можно отправлять в Azure Monitor несколькими способами.

Модель ценообразования и срок хранения

Дополнительные сведения о том, когда выставление счетов будет включено для пользовательских метрик и запросов метрик, см. на странице цен на Azure Monitor. В целом, нет затрат на прием стандартных метрик (метрики платформы) в хранилище метрик Azure Monitor, но пользовательские метрики потребуют затрат, когда они поступают в общую доступность. Запросы к API метрик вызывают затраты.

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

Примечание

Счета за метрики, отправляемые Azure Monitor через пакет SDK для Application Insights, выставляются как за принятые данные журнала. плата взимается за дополнительные метрики только в том случае, если выбрана функция Application Insights включить оповещения для пользовательских измерений метрик . Этот флажок отправляет данные в базу данных метрик Azure Monitor с помощью API настраиваемых метрик, что позволяет создавать более сложные предупреждения. Узнайте больше о модели ценообразования Application Insights и ценах в вашем регионе.

Отправка пользовательских метрик

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

Аутентификация

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

  • Управляемые удостоверения для ресурсов Azure. Управляемое удостоверение можно использовать для предоставления ресурсам разрешений на выполнение определенных операций. Пример разрешает ресурсам выдать собственные метрики. ресурсу или управляемому удостоверению можно предоставить метрики мониторинга Publisher разрешения на другом ресурсе. С этим разрешением управляемое удостоверение может также выдавать метрики для других ресурсов.

  • Субъект-служба Azure AD. В данном случае приложению или службе AAD можно назначить разрешения на отправку метрик ресурса Azure. Для проверки подлинности запроса с помощью открытых ключей AAD Azure Monitor проверяет маркер приложения. Существующая роль Издатель метрик мониторинга имеет это разрешение, доступное на портале Azure. Доступно на портале Azure.

    Субъекту-службе (в зависимости от того, для каких ресурсов будут отправляться пользовательские метрики) можно предоставить роль Издатель метрик мониторинга в необходимой области. Например, в подписке, группе ресурсов или в ресурсе.

Совет

При запросе маркера Azure AD для получения настраиваемых метрик убедитесь, что аудитория или ресурс, для которых запрашивается маркер, имеет значение https://monitoring.azure.com/ . Обязательно включите косую черту в конце.

Тема

Свойство Subject захватывает идентификатор ресурса Azure, для которого сообщается настраиваемая метрика. Эти сведения будут закодированы в URL-адресе вызова API. Каждый API может отправлять значения метрик только для одного ресурса Azure.

Примечание

Отправить пользовательские метрики с помощью идентификатора группы ресурсов или подписки невозможно.

Регион

Свойство Region захватывает регион Azure, в котором развернут ресурс, для которого вы отправляете метрики. Метрики должны выдаваться той же Azure Monitor региональной конечной точки, что и регион, в котором развернут ресурс. Например, пользовательские метрики для виртуальной машины, развернутой в регионе "Западная часть США", должны отправляться в конечную точку Azure Monitor региона "Западная часть США". Сведения о регионе также кодируются в URL-адресе вызова API.

Примечание

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

Timestamp

Каждая точка данных, отправляемая в Azure Monitor, должна быть отмечена временной меткой. Эта метка времени фиксирует дату и время, когда измеряется или собирается значение метрики. Azure Monitor принимает данные метрик с метками времени до 20 минут назад и до 5 минут вперед. Метка времени должна быть указана в формате ISO 8601.

Пространство имен

При помощи пространств имен можно классифицировать или группировать похожие метрики. Они позволяют обеспечить изоляцию между группами метрик, которые смогут собирать разные аналитические сведения или индикаторы производительности. Например, у вас есть пространство имен с именем contosomemorymetrics, отслеживающее метрики использования памяти, которые профилируют приложения. Другое пространство имен, которое называется contosoapptransaction, может отслеживать все метрики о пользовательских транзакциях в приложении.

Имя

Свойство Name — это имя метрики, о которой сообщается. Как правило, оно является достаточно описательным, чтобы указать измеряемый показатель. Примером является метрика, которая измеряет количество байтов памяти, используемых на виртуальной машине. Например, имя метрики Используемые байты памяти.

Ключи измерений

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

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

Измерения являются необязательными, а не все метрики имеют размеры. У пользовательской метрики может быть до 10 измерений.

Значения измерений

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

  • имя метрики — Используемые байты памяти;
  • ключ измерения — Процесс;
  • значение измерения — ContosoApp.exe.

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

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

Значения метрик

Azure Monitor сохраняет все метрики с интервалами гранулярности в 1 минуту. В течение данной минуты для метрики может потребоваться выборка несколько раз. Примером может служить загрузка ЦП. Или метрику может потребоваться измерение для нескольких дискретных событий, например задержки транзакций при входе.

Чтобы ограничить количество необработанных значений, которые необходимо выпустить и оплатить в Azure Monitor, можно локально выполнить предварительную статистическую обработку и выпустить значения:

  • Минимум — минимальное наблюдаемое значение из всех образцов или измерений за минуту.
  • Максимум — максимальное наблюдаемое значение из всех образцов или измерений за минуту.
  • Сумма — сумма всех наблюдаемых значений из всех образцов или измерений за минуту.
  • Количество — число образцов или измерений за минуту.

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

Транзакция 1 Транзакция 2 Транзакция 3 Транзакция 4
7 мс 4 мс 13 мс 16 мс

Результаты публикации метрики в Azure Monitor будут следующими:

  • "Минимум": 4;
  • "Максимум": 16;
  • "Сумма": 40;
  • "Количество": 4.

Если приложение не может выполнить предварительную статистическую обработку локально и при этом необходимо создать каждый дискретный выбор или событие сразу после сбора, можно создать необработанные значения меры. Например, при каждой транзакции входа в приложении метрика будет публиковаться в Azure Monitor только с одним измерением. Так что для транзакции входа, которая заняла 12 миллисекунд, публикация метрики будет выглядеть следующим образом:

  • "Минимум": 12;
  • "Максимум": 12;
  • "Сумма": 12;
  • "Количество": 1.

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

Пример публикации пользовательской метрики

В приведенном ниже примере создается пользовательская метрика под названием Используемые байты памяти в пространстве имен Профиль памяти для виртуальной машины. У этой метрики есть одно измерение с именем Процесс. Для отметки времени значения метрик создаются для двух процессов.

{
    "time": "2018-08-20T11:25:20-7:00",
    "data": {

      "baseData": {

        "metric": "Memory Bytes in Use",
        "namespace": "Memory Profile",
        "dimNames": [
          "Process"
        ],
        "series": [
          {
            "dimValues": [
              "ContosoApp.exe"
            ],
            "min": 10,
            "max": 89,
            "sum": 190,
            "count": 4
          },
          {
            "dimValues": [
              "SalesApp.exe"
            ],
            "min": 10,
            "max": 23,
            "sum": 86,
            "count": 4
          }
        ]
      }
    }
  }

Примечание

Application Insights, расширение системы диагностики Windows Azure, и агент InfluxData Telegraf уже настроены на отправку значений метрик в соответствующую региональную конечную точку, передавая все вышеуказанные свойства при каждой отправке.

Определения пользовательских метрик

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

Примечание

Azure Monitor пока не поддерживает определение единиц измерения для пользовательских метрик.

Использование пользовательских метрик

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

Примечание

Для просмотра пользовательских метрик необходимо иметь роль читателя или участника. См. описание роли "Читатель данных мониторинга".

Просмотр пользовательских метрик на портале Azure

  1. Перейдите на портал Microsoft Azure.
  2. Выберите вкладку Монитор.
  3. Выберите Метрики.
  4. Выберите ресурс, для которого были созданы пользовательские метрики.
  5. Выберите пространство имен для пользовательской метрики.
  6. Выберите пользовательскую метрику.

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

Поддерживаемые регионы

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

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

Регион Azure Префикс региональной конечной точки
Все регионы действия общедоступного облака https://<azure_region_code>.monitoring.azure.com

Задержка и период хранения

Для отображения вновь добавленной метрики или добавленного измерения в метрику может потребоваться до 3 минут. После того как данные находятся в системе, они должны отображаться менее чем за 30 секунд, 99% времени.

Удаление метрики или измерения из системы может занять от недели до месяца.

Квоты и ограничения

Azure Monitor налагает указанные ниже ограничения на использование пользовательских метрик.

Категория Ограничение
Общее количество активных временных рядов в подписке во всех регионах, на которые вы развернули 50 000
Ключи измерений на метрику 10
Длина строки для имен и пространств имен метрик, а также ключей и имен измерений 256 символов

Активная временная серия — это уникальное сочетание метрики, ключа и значения измерения, содержащее значения метрик, опубликованные за последние 12 часов.

Чтобы определить ограничение в 50 000 для временных рядов, учитывайте следующую метрику.

Время ответа сервера с измерениями: Регион, Отдел, Идентификатор клиента

С этой метрикой, если у вас 10 регионов, 20 отделов и 100 клиентов, вы получите 10 x 20 x 100 = 2 000 временных рядов.

Если у вас есть 100 регионов, 200 и 2 000 клиентов, вы получите 100 x 200 x 2 000 = 40 000 000, что значительно превышает ограничение только для этой метрики.

И снова: это ограничение не относится к отдельным метрикам. Он соответствует сумме всех таких метрик в рамках подписки и региона.

Ограничения и рекомендации по проектированию

использование Application Insights в целях аудита. конвейер телеметрии Application Insights оптимизирован для минимизации влияния на производительность и ограничения сетевого трафика от мониторинга приложения. Таким образом, он выполняет регулирование или выборку (принимает только определенный процент телеметрии и игнорирует оставшуюся часть), если исходный набор данных становится слишком большим. Из-за этого поведение нельзя использовать для целей аудита, так как некоторые записи, скорее всего, будут удалены.

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

Измерения метрик высокой кратности. Метрики с слишком большим количеством допустимых значений в измерении ( большое количество элементов) гораздо более подвержены достижении ограничения в 50 000. Ни в коем случае не следует использовать постоянно изменяющееся значение в измерении. Например, отметка времени не должна быть измерением. Можно использовать сервер, клиент или идентификатор продукта, но только при наличии меньшего числа каждого из этих типов.

Просто для интереса спросите себя, хотите ли вы отображать эти данные на графике? Если у вас есть 10 или даже 100 серверов, может быть полезно просмотреть все их данные на графе для сравнения. Но если у вас 1 000, полученный граф, скорее всего, будет трудно или невозможно считать. Рекомендуется не допустить, чтобы в нем было менее 100 допустимых значений. Число значений до 300 является некой "серой" или неопределенной зоной. Если необходимо превысить это значение, используйте настраиваемые журналы Azure Monitor.

Если у вас есть переменная в имени или измерении с высоким количеством элементов, может произойти следующее:

  • Метрики становятся ненадежными из-за регулирования.
  • Обозреватель метрик не будет работать.
  • Оповещения и уведомления становятся непредсказуемыми.
  • Затраты могут увеличиваться непредвиденным образом. Корпорация Майкрософт не заряжается за пользовательские метрики с измерениями, пока эта функция находится в общедоступной предварительной версии. Однако после того, как оплата начнется в будущем, будет взиматься непредвиденная плата. План предусматривает оплату за потребление метрик на основе числа отслеживаемых временных рядов и количества вызовов API.

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

Но если высокая кратность является важнейшей для вашего сценария, агрегированные метрики, вероятно, не являются верными. Переключитесь на использование настраиваемых журналов (то есть вызовов API trackMetric с trackEvent). Однако учтите, что в журналах не выполняется статистическая обработка значений, поэтому сохраняется каждая отдельная запись. В результате при наличии большого объема журналов в течение небольшого периода времени (например, 1 000 000 секунды) это может привести к задержкам регулирования и приема.

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

Используйте пользовательские метрики из различных служб: