Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В Azure доступны некоторые метрики по умолчанию. Эти метрики называются стандартными или платформенными. Кастомные метрики — это показатели производительности или бизнес-метрики. Их можно собирать с помощью телеметрии приложения. Вы также можете использовать агент Azure Monitor или внешнюю систему мониторинга. После публикации пользовательских метрик в Azure Monitor вы можете просматривать, запрашивать и оповещать их вместе со стандартными метриками Azure.
Замечание
Сейчас пользовательские метрики Azure Monitor находятся на этапе общедоступной предварительной версии. Эта функция не будет предоставлена в режиме GA, так как в настоящее время мы предлагаем улучшенную GA-функцию, которая обеспечивает ту же функциональность и ещё больше возможностей: настраиваемые метрики в рабочих областях Azure Monitor. Помимо пользовательских метрик, также поддерживаются счетчики производительности OpenTelemetry из гостевой ОС виртуальных машин.
Способы отправки пользовательских метрик
Пользовательские метрики можно отправлять в Azure Monitor несколькими способами.
- Используйте Azure Application Insights SDK для инструментирования, отправляя пользовательскую телеметрию в Azure Monitor.
- Установите агент Azure Monitor в виртуальной машине Windows или Linux Azure или масштабируемом наборе виртуальных машин и используйте правило сбора данных для отправки счетчиков производительности в метрики Azure Monitor.
- Установите агент InfluxData Telegraf на виртуальной машине Linux Azure. Отправьте метрики, используя выходной плагин Azure Monitor.
- Отправка пользовательских метрик непосредственно в REST API Azure Monitor.
Модель ценообразования и срок хранения
Как правило, затраты на прием стандартных метрик (метрик платформы) в хранилище метрик Azure Monitor отсутствуют, но пользовательские метрики несут затраты, когда они достигают общего уровня доступности. Запросы к API-интерфейсу метрик приводят к затратам. Для получения подробной информации о том, когда включается выставление счетов за пользовательские метрики и запросы метрик, перейдите на страницу цен Azure Monitor.
Пользовательские метрики сохраняются в течение того же времени, что и метрики платформы.
Определения пользовательских метрик
Каждая точка данных метрик, которую вы публикуете, содержит пространство имен, имя и сведения о измерении. При первом отправке пользовательской метрики в Azure Monitor служба автоматически создает определение метрик. Вы можете обнаружить это новое определение метрики в любом ресурсе, из которого она исходит, используя определения метрик. Вам не нужно предварительно определять пользовательскую метрику в Azure Monitor перед её отправкой.
Замечание
Application Insights и агент Telegraf от InfluxData уже настроены для выдачи значений метрик на правильную региональную конечную точку и содержат все указанные свойства в каждом переданном значении.
Использование пользовательских метрик
После отправки пользовательских метрик в 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 временных рядов, рассмотрим следующую метрику.
Время отклика сервера с измерениями: регион, отдел, CustomerID
Согласно этой метрике, если у вас есть 10 регионов, 20 отделов и 100 клиентов, вы получите 20 000 (10 x 20 x 100) временных рядов.
Если у вас есть 100 регионов, 200 отделов и 2000 клиентов, результат составляет 100 x 200 x 200 x 2000 = 40 миллионов временных рядов. Это число гораздо превышает ограничение для одной метрики.
И снова: это ограничение не относится к отдельным метрикам. Оно действует для суммы всех таких метрик в рамках подписки и региона.
Чтобы просмотреть текущие метрики активных временных рядов и получить дополнительные сведения об устранении неполадок, выполните следующие действия.
- Перейдите к разделу "Монитор" портала Azure.
- Выберите Метрики на левой панели.
- В разделе "Выбор области" проверьте применимые подписки и группы ресурсов.
- В разделе "Уточнение области" выберите "Использование пользовательских метрик " и требуемое расположение.
- Нажмите кнопку "Применить ".
- Выберите Активные временные ряды, Предел активных временных рядов или Ограниченные временные ряды.
Azure Monitor ограничивает общую длину всех наименований пользовательских метрик до 64 КБ при использовании кодировки UTF-8 или 1 байта на символ. Если имена метрик превышают это ограничение, Azure Monitor блокирует доступ к метаданным для других метрик. Портал 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 серверов, может быть полезно просмотреть все их данные на графе для сравнения. Но если у вас 1,000, то итоговый график, скорее всего, будет трудным или даже невозможным для чтения. Рекомендуется, чтобы число допустимых значений не превышало 100. Число значений до 300 является некой "серой" или неопределенной зоной. Если необходимо превысить это значение, используйте настраиваемые журналы Azure Monitor.
При наличии переменной в названии или измерении с высокой кардинальностью могут возникнуть следующие проблемы:
- Метрики становятся ненадежными из-за регулирования.
- Обозреватель метрик не работает.
- Оповещения и уведомления становятся непредсказуемыми.
- Затраты могут увеличиваться непредвиденным образом. Корпорация Майкрософт не взимает плату за пользовательские метрики с измерениями, пока эта функция находится в общедоступной предварительной версии. После начала тарификации в будущем вы можете понести непредвиденные расходы. Планируется взимать плату за использование метрик в зависимости от количества отслеживаемых временных рядов и количества выполненных вызовов API.
Если имя метрики или значение измерения по ошибке заполнено идентификатором или измерением с высокой кратностью, можно легко исправить это, удалив переменную часть.
Но если высокая кратность является важной частью вашего сценария, агрегированные метрики, вероятно, не являются правильным решением. Переключитесь на использование пользовательских журналов (то есть вызовы API trackMetric с trackEvent). Однако учитывайте, что журналы не объединяют значения, поэтому каждая запись хранится. Таким образом, если у вас большой объем журналов в течение небольшого времени (например, 1 миллион в секунду), это может привести к ограничению и задержкам в обработке.
Подсказка
Мониторинг метрик Azure и Рабочая область Azure Monitor получают пользовательские метрики с фиксированным интервалом в 60 секунд. Метрики, отправленные чаще, буфериируются и обрабатываются каждые 60 секунд. Показатели Log Analytics записываются с указанным интервалом отправки, что может привести к увеличению затрат при более коротких интервалах и задержке видимости при более длительных.
Дальнейшие шаги
Используйте пользовательские метрики из различных служб:
- Отправка пользовательских метрик в Azure Monitor с помощью REST API
- Сбор пользовательских метрик из виртуальной машины
- Сбор пользовательских метрик из масштабируемого набора виртуальных машин
- Сбор пользовательских метрик из виртуальной машины Azure (классической)
- Сбор пользовательских метрик из виртуальной машины Linux с помощью агента Telegraf
- Сбор пользовательских метрик из классической облачной службы