Пользовательские метрики в Azure Monitor (предварительная версия)
В Azure доступны некоторые метрики по умолчанию. Их называют стандартными метриками или метриками платформы. Пользовательские метрики — это показатели производительности или бизнес-метрики, которые можно собирать с помощью телеметрии приложения, агента Azure Monitor, расширения диагностика, работающего в ресурсах Azure или внешней системы мониторинга. После публикации пользовательских метрик в Azure Monitor вы можете просматривать, запрашивать и оповещать их вместе со стандартными метриками Azure.
Сейчас пользовательские метрики Azure Monitor находятся на этапе общедоступной предварительной версии.
Способы отправки пользовательских метрик
Пользовательские метрики можно отправлять в Azure Monitor несколькими способами.
- Используйте пакет SDK приложение Azure Insights для инструментирования приложения путем отправки пользовательской телеметрии в Azure Monitor.
- Установите агент Azure Monitor в виртуальной машине Windows или Linux Azure или масштабируемом наборе виртуальных машин и используйте правило сбора данных для отправки счетчиков производительности в метрики Azure Monitor.
- Установите расширение Диагностика Azure на виртуальной машине Azure, масштабируемом наборе виртуальных машин, классической виртуальной машине или классической облачной службе. Затем отправить счетчики производительности в Azure Monitor.
- Установить агент InfluxData Telegraf на виртуальной машине Azure с Linux. Отправить метрики с помощью подключаемого модуля вывода Azure Monitor.
- Отправка пользовательских метрик непосредственно в REST API Azure Monitor.
Модель ценообразования и срок хранения
Как правило, нет затрат на прием стандартных метрик (метрик платформы) в хранилище метрик Azure Monitor, но пользовательские метрики влечет за собой затраты при вводе общего уровня доступности. Запросы к API-интерфейсу метрик приводят к затратам. Дополнительные сведения о включении выставления счетов для пользовательских запросов метрик и метрик см. на странице цен Azure Monitor.
Период хранения пользовательских метрик аналогичен периоду хранения метрик платформы.
Примечание.
Чтобы повысить удобство работы, пользовательские метрики, отправленные в Azure Monitor из классического API Application Insights (SDK), всегда хранятся как в Log Analytics, так и в хранилище метрик. Затраты на хранение этих метрик основаны только на томе, принятым Log Analytics. Дополнительные затраты на данные, хранящиеся в хранилище метрик, не существуют.
Определения пользовательских метрик
Каждая точка данных метрик, опубликованная, содержит сведения о пространстве имен, имени и измерении. При первом создании пользовательской метрики в Azure Monitor автоматически создается определение метрик. Затем это новое определение метрик можно обнаружить на любом ресурсе, из который создается метрика с помощью определений метрик. Нет необходимости определять пользовательскую метрику в Azure Monitor до ее отправления.
Примечание.
Application Insights, расширение системы диагностики Windows Azure, и агент InfluxData Telegraf уже настроены на отправку значений метрик в соответствующую региональную конечную точку, передавая все вышеуказанные свойства при каждой отправке.
Использование пользовательских метрик
После отправки пользовательских метрик в Azure Monitor их можно просмотреть на портале Azure и запросить через REST API Azure Monitor. Также для них можно создать оповещения, чтобы уведомлять об определенных условиях.
Примечание.
Для просмотра пользовательских метрик необходима роль читателя или участника. См. описание роли "Читатель данных мониторинга".
Просмотр пользовательских метрик на портале Azure
- Переход на портал Azure.
- Выберите вкладку Монитор.
- Выберите Метрики.
- Выберите ресурс, с которого отправлялись пользовательские метрики.
- Выберите пространство имен для пользовательской метрики.
- Выберите пользовательскую метрику.
Дополнительные сведения о просмотре метрик в портал Azure см. в обозревателе метрик Azure Monitor.
Задержка и период хранения
Для отображения вновь добавленной метрики или добавленного измерения в метрику может потребоваться до 3 минут. После того как данные попали в систему, они должны появиться менее чем через 30 секунд, 99 % времени.
Удаление метрики или измерения из системы может занять от недели до месяца.
Квоты и ограничения
Azure Monitor налагает указанные ниже ограничения на использование пользовательских метрик.
| Категория | Лимит |
|---|---|
| Общее количество активных временных рядов в подписке на каждый регион | 50,000 |
| Ключи измерений на метрику | 10 |
| Длина строки для имен и пространств имен метрик, а также ключей и имен измерений | 256 символов |
| Объединенная длина всех пользовательских имен метрик с использованием кодировки utf-8 | 64 КБ |
Активная временная серия — это уникальное сочетание метрики, ключа и значения измерения, содержащее значения метрик, опубликованные за последние 12 часов.
Чтобы получить представление об ограничении в 50 000 временных рядов, рассмотрим следующую метрику.
Время ответа сервера с измерениями: Регион, Отдел, Идентификатор клиента
Если у вас есть 10 регионов, 20 отделов и 100 клиентов, которые предоставляют вам 10 x 20 x 100 = 20 000 временных рядов.
Если у вас есть 100 регионов, 200 отделов и 2000 клиентов, вы получите 40 миллионов (100 x 200 x 2000) временных рядов, что значительно превышает предел только для этой метрики.
И снова: это ограничение не относится к отдельным метрикам. Оно действует для суммы всех таких метрик в рамках подписки и региона.
Выполните приведенные ниже шаги, чтобы просмотреть общие текущие метрики активных временных рядов и дополнительные сведения для помощи в устранении неполадок.
- Перейдите к разделу "Монитор" портала Azure.
- Выберите Метрики слева.
- В разделе Выбор области проверьте соответствующую подписку и группы ресурсов.
- В разделе Уточнение области выберите Пользовательское использование метрик и нужное расположение.
- Нажмите кнопку Применить.
- Выберите Активные временные ряды, Ограничение активных временных рядов или Регулируемые временные ряды.
Существует ограничение в 64 КБ на объединенную длину всех пользовательских имен метрик, при условии, что utf-8 или 1 байт на символ. Если превышено ограничение в 64 КБ, метаданные для дополнительных метрик не будут доступны. Имена метрик для дополнительных пользовательских метрик не будут отображаться в портал Azure в полях выбора и не будут возвращены API в запросах на определения метрик. Данные метрик по-прежнему доступны и могут запрашиваться.
Если ограничение превышено, уменьшите количество метрик, которые вы отправляете или сокращаете длину их имен. Затем для отображения новых имен метрик потребуется до двух дней.
Чтобы избежать достижения предела, не включайте переменные или мерные аспекты в имена метрик.
Например, метрики для использованияCPU_server_12345678-319d-4a50-b27e-1234567890ab ЦП сервера и CPU_server_abcdef01-319d-4a50-b27e-abcdef012345 должны быть определены как метрики CPU и измерения Server .
Ограничения и рекомендации по проектированию
Использование Application Insights в целях аудита. Конвейер телеметрии Application Insights оптимизирован для минимизации влияния на производительность и ограничения сетевого трафика от мониторинга приложения. Таким образом, он выполняет регулирование или выборку (принимает только определенный процент телеметрии и игнорирует оставшуюся часть), если исходный набор данных становится слишком большим. В связи с этим его нельзя использовать для целей аудита, так как некоторые записи, скорее всего, будут удалены.
Метрики с переменной в имени. Не используйте переменную как часть имени метрики. Вместо этого используйте константу. Каждый раз, когда переменная изменяет свое значение, Azure Monitor создает новую метрику. Таким образом Azure Monitor быстро достигнет предела числа метрик. Как правило, когда разработчики хотят включить переменную в имя метрики, они на самом деле хотят отслеживать несколько временных рядов в одной метрике и должны использовать измерения вместо переменных имен метрик.
Измерения метрик с высокой кратностью. Метрики со слишком большим количеством допустимых значений в измерении (высокой кратностью) имеют намного большую вероятность достижения ограничения в 50 000. Ни в коем случае не следует использовать постоянно изменяющееся значение в измерении. Например, метка времени никогда не должна быть измерением. Можно использовать сервер, клиент или код продукта, но только если их количество незначительно.
Просто для интереса спросите себя, хотите ли вы отображать эти данные на графике? Если у вас есть 10 или даже 100 серверов, может быть полезно просмотреть все их данные на графе для сравнения. Но если у вас 1000 серверов, чтение данных на итоговом графе, скорее всего, будет трудной или даже невыполнимой задачей. Рекомендуется, чтобы число допустимых значений не превышало 100. Число значений до 300 является некой "серой" или неопределенной зоной. Если необходимо превысить это значение, используйте настраиваемые журналы Azure Monitor.
При наличии переменной в имени или измерении с высокой кратностью могут возникнуть следующие проблемы:
- Метрики становятся ненадежными из-за регулирования.
- Обозреватель метрик не работает.
- Вывод оповещений и уведомлений становится непредсказуемым.
- Затраты могут увеличиваться непредвиденным образом. Корпорация Майкрософт не взимает плату за пользовательские метрики с измерениями, пока эта функция находится в общедоступной предварительной версии. После начала тарификации в будущем вы можете понести непредвиденные расходы. Планируется взимать плату за использование метрик в зависимости от количества отслеживаемых временных рядов и количества выполненных вызовов API.
Если имя метрики или значение измерения по ошибке заполнено идентификатором или измерением с высокой кратностью, можно легко исправить это, удалив переменную часть.
Но если высокая кратность является важной частью вашего сценария, агрегированные метрики, вероятно, не являются правильным решением. Перейдите на использование настраиваемых журналов (то есть вызовов API trackMetric с trackEvent). Однако учтите, что в журналах не выполняется статистическая обработка значений, поэтому сохраняется каждая отдельная запись. В результате большой объем журналов в течение небольшого периода времени (например, 1 млн в секунду) может привести к регулированию полосы пропускания и задержкам приема.
Следующие шаги
Используйте пользовательские метрики из различных служб: