Обзор метрик в Azure Monitor

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

Типы метрик

Существует несколько типов метрик, поддерживаемых метриками Azure Monitor:

• Собственные метрики используют средства в Azure Monitor для анализа и оповещения.
  • Метрики платформы собираются из ресурсов Azure. Они не требуют конфигурации и не имеют затрат.
  • Пользовательские метрики собираются из разных источников, которые настраиваются, включая приложения и агенты, работающие на виртуальных машинах.
• Метрики Prometheus собираются из кластеров Kubernetes, включая службу Azure Kubernetes (AKS) и используют отраслевые стандартные средства для анализа и оповещения, таких как PromQL и Grafana.

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

сбор данных

Azure Monitor собирает метрики из указанных ниже источников. После сбора метрик в базе данных метрик Azure Monitor их можно оценить вместе независимо от источников.

• Ресурсы Azure — метрики платформы создаются ресурсами Azure и информируют об их работоспособности и производительности. Каждый тип ресурсов создает отдельный набор метрик, который не нужно настраивать. Метрики платформы собираются из ресурсов Azure с частотой раз в минуту, если в определении метрики не указано иное.
• Приложения — служба Application Insights создает метрики для отслеживаемых приложений, что помогает обнаруживать проблемы с производительностью и отслеживать тенденции использования приложений. В числе таких метрик время ответа сервера и исключения браузера.
• Агенты виртуальной машины — метрики собираются из гостевой операционной системы виртуальной машины. Вы можете включить метрики гостевой ОС для виртуальных машин Windows с помощью агента Azure Monitor. Агент Azure Monitor заменяет устаревшие агенты — расширение диагностики Windows и агент Telegraf Для Виртуальных машин Linux.
• Пользовательские метрики — вы можете определить метрики в дополнение к стандартным метрикам, которые доступны автоматически. Вы можете определять пользовательские метрики в своих приложениях, отслеживаемых службой Application Insights. Вы также можете создать пользовательские метрики для службы Azure с помощью API пользовательских метрик.
• Кластеры Kubernetes: кластеры Kubernetes обычно отправляют данные метрик на локальный сервер Prometheus, который необходимо поддерживать. Управляемая служба Azure Monitor для Prometheus предоставляет управляемую службу, которая собирает метрики из кластеров Kubernetes и хранит их в метриках Azure Monitor.

REST API

Azure Monitor предоставляет ИНТЕРФЕЙСы REST API, которые позволяют получать данные из метрик Azure Monitor и из него.

• Пользовательские метрики API - пользовательских метрик позволяют загружать собственные метрики в базу данных метрик Azure Monitor. Затем эти метрики можно использовать теми же средствами анализа, которые обрабатывают метрики платформы Azure Monitor.
• REST API метрик Azure Monitor— позволяет получить доступ к определениям и значениям метрик платформы Azure Monitor. Дополнительные сведения см. в rest API Azure Monitor. Сведения об использовании API см. в пошаговом руководстве по REST API мониторинга Azure.
• API пакетной службы метрик Azure Monitor для пакетной службы Azure Monitor — это API пакетной службы - метрик Azure Monitor, предназначенный для клиентов с большими запросами метрик томов. Это похоже на существующий стандартный REST API метрик Azure Monitor, но предоставляет возможность получить данные метрик для до 50 идентификаторов ресурсов в одной подписке и регионе в одном пакетном вызове API. Это повышает пропускную способность запросов и снижает риск регулирования.

Безопасность

Все обмен данными между подключенными системами и службой Azure Monitor шифруются с помощью протокола TLS 1.2 (HTTPS). Процесс Microsoft SDL следует, чтобы убедиться, что все службы Azure актуальны с последними достижениями в криптографических протоколах.

Безопасное подключение устанавливается между агентом и службой Azure Monitor с помощью проверки подлинности на основе сертификатов и TLS с портом 443. Для создания и обслуживания ключей в Azure Monitor используется секретное хранилище. Закрытые ключи меняются каждые 90 дней, хранятся в Azure и управляются с помощью операций Azure согласно строгим рекомендациям соответствия нормативам и требованиям. Дополнительные сведения о безопасности см. в разделе "Шифрование данных во время передачи", "Шифрование неактивных данных" и "Безопасность данных журналов Azure Monitor"

Обозреватель метрик

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

Дополнительные сведения см. в разделе "Анализ метрик" с помощью обозревателя метрик Azure Monitor.

Структура данных

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

• время получения значения;
• ресурс, с которым связано значение.
• пространство имен, используемое в качестве категории метрики;
• имя метрики;
• само значение.
• измерения метрики при их наличии Пользовательские метрики ограничены 10 измерениями.

Многомерные метрики

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

Измерения метрик — это пары "имя-значение", которые содержат больше данных для описания значения метрик. Например, метрика Доступное место на диске может иметь измерение Диск со значениями C: и D:. Эта метрика позволяет узнать свободное место на каждом диске.

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

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

В следующей таблице показаны примеры данных из немерной метрики, пропускной способности сети. Он может ответить только на базовый вопрос, например "Что было моей пропускной способностью сети в определенное время?"

Пропускная способность сети и два измерения ("IP-адрес" и "Направление")

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

Хранение метрик

Платформы и пользовательские метрики

Платформа и пользовательские метрики хранятся в течение 93 дней со следующими исключениями:

• Классические метрики гостевой ОС. Это счетчики производительности, данные которых собираются с помощью расширения системы диагностики Windows или Linux и передаются в учетную запись хранения Azure. Срок хранения этих метрик составляет не менее 14 дней, но дата окончания этого срока не указывается в учетной записи хранения.

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

• Метрики гостевой ОС, отправляемые в метрики Azure Monitor. Это счетчики производительности, данные которых собираются с помощью расширения системы диагностики Windows и передаются в приемник данных Azure Monitor. Сбор данных также может выполняться с помощью агента InfluxData Telegraf на компьютерах Linux или нового решения — агента Azure Monitor с использованием правил сбора данных. Период хранения этих метрик составляет 93 дней.

• Метрики гостевой ОС, собираемые агентом Log Analytics. Это счетчики производительности, данные которых собираются агентом Log Analytics и передаются в рабочую область Log Analytics. Период хранения этих метрик составляет 31 день, но его можно увеличить до 2 лет.

• Метрики на основе журналов Application Insights. В фоновом режиме метрики на основе журналов преобразовываются в запросы журналов. Период хранения для них может быть разным и соответствует периоду хранения событий в базовых журналах (от 31 дня до 2 лет). Для ресурсов Application Insights журналы хранятся в течение 90 дней.

Хотя платформа и пользовательские метрики хранятся в течение 93 дней, вы можете запрашивать данные только (на плитке метрик ) не более 30 дней на любой отдельной диаграмме. Это ограничение не применяется к метрикам на основе журналов. Если вы видите пустую диаграмму или на ней отображаются неполные данные метрик, убедитесь, что разница между датами начала и окончания в средстве выбора времени не превышает 30 дней. После выбора 30-дневного интервала можно выполнить сдвиг диаграммы, чтобы просмотреть данные за весь период хранения.

Метрики Prometheus

Метрики Prometheus хранятся в течение 18 месяцев, но запрос PromQL может охватывать не более 32 дней.

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

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