Интерфейс метрик для виртуальных машин в Azure Monitor

При включении расширенного мониторинга для виртуальных машин Azure или серверов с поддержкой Arc в Azure Monitor можно выбрать два способа сбора и визуализации данных о производительности из гостевой операционной системы: мониторинг на основе метрик (предварительная версия) и мониторинг на основе журналов (классическая модель). В этой статье описываются различия между этими интерфейсами и приводятся рекомендации по выбору.

Сравнение возможностей

В следующей таблице сравниваются возможности мониторинга на основе OpenTelemetry и журналов для виртуальных машин Azure в Azure Monitor.

Функция На основе метрик (предварительная версия) На основе логов (классическая модель)
хранилище данных Рабочая область Azure Monitor Рабочая область Log Analytics
Относится к Виртуальные машины Azure
Серверы с поддержкой Arc		 Виртуальные машины Azure
Серверы с поддержкой Arc
Масштабируемые наборы виртуальных машин
Модель данных Системные метрики OpenTelemetry с согласованными кроссплатформенными именами Счетчики производительности для конкретной платформы
Язык запросов PromQL (язык запросов Prometheus) KQL (язык запросов Kusto)
Задержка Почти в режиме реального времени с низкой задержкой Обычно 1–3 минуты
Cost Бесплатные метрики по умолчанию Стандартные затраты на прием и хранение Log Analytics
Многовидовые представления виртуальных машин В настоящее время ограничено Полные панели мониторинга и книги для аналитики виртуальных машин с несколькими виртуальными машинами
Корреляция с журналами Требуются отдельные запросы Одна рабочая область для метрик и журналов обеспечивает корреляцию в одном запросе.

Когда необходимо включить интерфейс на основе журналов

Вы должны включить интерфейс на основе метрик во всех случаях, так как коллекция метрик по умолчанию бесплатна. Выберите также включить метрики на основе журналов, если:

  • Необходимо отслеживать масштабируемые наборы виртуальных машин.
  • Требуются встроенные панели мониторинга мульти-ВМ и трендовые представления.
  • Необходимо сопоставить метрики и журналы в одном запросе.
  • Вы уже используете запросы, панели мониторинга или оповещения, основываясь на таблице InsightsMetrics.

Преимущества OpenTelemetry

Возможность наблюдения за несколькими ОС
Семантическое соглашение OpenTelemetry для системных метрик оптимизирует опыт конечного пользователя на разных ОС, объединяя счетчики производительности Windows и Linux в единое согласованное соглашение об именовании и модель метрик. Это упрощает управление всеми виртуальными машинами с одним набором запросов, используемых для операционных систем Windows или Linux. Те же методы развертывания конфигурации как кода и те же запросы PromQL можно использовать для любого ресурса размещения, который принимает системные метрики OpenTelemetry.

Дополнительные счетчики производительности
Приемник метрик OpenTelemetry Collector Host собирает больше счетчиков производительности, чем доступно для сбора на основе журналов в Azure Monitor. Например, можно отслеживать использование ЦП для каждого процесса, операций ввода-вывода диска и использования памяти.

Упрощенная модель метрик

Во многих сценариях несколько показателей производительности сопоставляются с одной системной метрикой OpenTelemetry (OTel), включающей измерения метрик, которые также называются атрибутами ресурсов. Это упрощает сбор и запросы.

Например, OTel включает метрику system.cpu.time . Вы можете отфильтровать измерение для таких значений State , как пользователь, система и бездействия. При использовании коллекции на основе журналов необходимо собирать и запрашивать следующие счетчики производительности.

  • Windows: \Processor Information(_Total)\% Processor Time, \Processor Information(_Total)\% Privileged Time, \Processor Information(_Total)\% User Time
  • Linux: Cpu/usage_user, Cpu/usage_systemCpu/usage_idleCpu/usage_activeCpu/usage_niceCpu/usage_iowaitCpu/usage_irq

Преимущества рабочих областей Azure Monitor

Метрики, хранящиеся в рабочих областях Azure Monitor, дешевле и быстрее запрашиваются, чем те же данные, хранящиеся в рабочих областях Log Analytics, так как рабочие области Azure Monitor оптимизированы для получения временных рядов. Использование метрик OTel в рабочей области Azure Monitor также позволяет избежать нескольких схем, используемых в коллекции на основе журналов. Метрики на основе журналов по умолчанию хранятся в InsightsMetrics таблице, а дополнительные включенные метрики хранятся в Perf таблице, которая использует другую схему.

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

Ограничения коллекции на основе метрик

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

Подсказка

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

Связанный контент

  • Last updated on