Мониторинг виртуальных машин с помощью Azure Monitor: сбор данных

Эта статья является частью руководства по мониторингу виртуальных машин и их рабочих нагрузок в Azure Monitor. В нем описывается настройка сбора данных после развертывания агента Azure Monitor в Azure и гибридных виртуальных машинах в Azure Monitor.

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

• Дополнительные сведения об анализе данных телеметрии, собранных с виртуальных машин, см. в статье "Мониторинг виртуальных машин с помощью Azure Monitor: анализ данных мониторинга".
• Дополнительные сведения об использовании телеметрии, собираемой с виртуальных машин для создания оповещений в Azure Monitor, см. в статье "Мониторинг виртуальных машин с помощью Azure Monitor: оповещения".

Правила сбора данных

Сбор данных из агента Azure Monitor определяется одним или несколькими правилами сбора данных (DCR), которые хранятся в подписке Azure и связаны с виртуальными машинами.

Для виртуальных машин правила сбора данных определяют, какие именно данные, такие как события и счетчики производительности, необходимо собирать, и указывают рабочие области Log Analytics, в которые должны быть отправлены эти данные. DCR также может использовать преобразования для фильтрации нежелательных данных и добавления вычисляемых столбцов. Один компьютер может быть связан с несколькими DCR, и один DCR может быть связан с несколькими компьютерами. Контроллеры домена доставляются на все компьютеры, с которыми они связаны, где агент Azure Monitor обрабатывает их.

Просмотр правил сбора данных

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

Создание правил сбора данных

Существует несколько методов создания отчетов по сбору данных в зависимости от сценария сбора данных. В некоторых случаях Azure Portal проводит вас через процесс конфигурации. Другие сценарии требуют непосредственного редактирования DCR. При настройке аналитики виртуальных машин он создает предварительно настроенный DCR для вас автоматически. В следующих разделах описаны общие данные для сбора и настройки сбора данных.

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

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

Управление затратами

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

Типичная виртуальная машина создает от 1 ГБ до 3 ГБ данных в месяц. Этот размер данных зависит от конфигурации компьютера, рабочих нагрузок, выполняемых на нем, и конфигурации ваших DCR. Перед настройкой сбора данных во всей среде виртуальных машин запустите сбор на некоторых репрезентативных компьютерах, чтобы точнее прогнозировать ожидаемые затраты при развертывании в среде. Используйте сведения рабочей области Log Analytics или запросы журналов в объеме данных по компьютеру, чтобы определить объем учитываемых для оплаты данных, собранных для каждого компьютера, и соответствующим образом настройте параметры сбора данных.

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

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

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

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

Сбор данных по умолчанию

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

Метрики платформы

Метрики платформы для виртуальных машин Azure включают важные метрики узлов, такие как ЦП, сеть и использование дисков. Они могут быть следующими:

• Просматривается на странице Обзор.
• Анализируется с помощью Metrics Explorer для машины в портале Azure.
• Используется для метрических оповещений.

Журнал действий

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

Журнал действий можно просмотреть для отдельного компьютера или для всех ресурсов в подписке. Создайте параметр диагностики для отправки этих данных в ту же рабочую область Log Analytics, которая используется агентом Azure Monitor для анализа данных мониторинга, собранных для виртуальной машины. Нет затрат на прием или хранение данных журнала действий.

Сведения о доступности виртуальной машины в Azure Resource Graph

С помощью Azure Resource Graph вы можете использовать тот же язык запросов Kusto, используемый в запросах журналов, для выполнения запросов ваших ресурсов Azure с помощью сложной фильтрации, группировки и сортировки по свойствам ресурсов. ** Используйте аннотации состояния виртуальных машин в Resource Graph для подробной атрибуции сбоев и анализа времени простоя.

Сведения о собранных данных и его просмотре см. в статье "Мониторинг виртуальных машин с помощью Azure Monitor: анализ данных мониторинга".

Аналитика VM

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

• Общие счетчики производительности для клиентской операционной системы отправляются в таблицу InsightsMetrics в рабочей области Log Analytics. Имена счетчиков нормализуются для использования одного и того же общего имени независимо от типа операционной системы.

• Если вы указали процессы и зависимости для сбора, следующие таблицы будут заполнены:

  • VMBoundPort: трафик для открытых портов сервера на компьютере
  • VMComputer: данные инвентаризации для компьютера
  • VMConnection: трафик для входящих и исходящих подключений к компьютеру и с него
  • VMProcess: процессы, выполняемые на компьютере

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

Сбор событий Windows и Системного журнала

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

Инструкции по созданию DCR для сбора событий Windows и Системного журнала см. в разделе "Сбор данных с помощью агента Azure Monitor". Вы можете быстро создать DCR с помощью наиболее распространенных журналов событий Windows и средств системного журнала, фильтрующих по уровню событий.

Для более детальной фильтрации по таким критериям, как идентификатор события, можно создать пользовательский фильтр с помощью запросов XPath. Вы можете дополнительно отфильтровать собранные данные, изменив DCR , чтобы добавить преобразование.

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

Примеры запросов журналов: события Windows

Примеры запросов журнала: события системного журнала

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

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

Существует несколько причин, по которым необходимо создать DCR для сбора гостевой производительности:

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

Рекомендации по созданию DCR для сбора счетчиков производительности см. в статье Сбор событий и счетчиков производительности с виртуальных машин с помощью агента Azure Monitor. Вы можете быстро создать DCR с помощью наиболее распространенных счетчиков. Для более детальной фильтрации по таким критериям, как идентификатор события, можно создать пользовательский фильтр с помощью запросов XPath.

Пример запросов журнала

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

Сбор текстовых логов

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

Пример запросов журнала

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

Сбор журналов IIS

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

Записи из журнала служб IIS хранятся в таблице W3CIISLOG в рабочей области Log Analytics. Прием и хранение этих данных в рабочей области предполагает определенные затраты.

Пример запросов журнала

Мониторинг службы или управляющей программы

Для отслеживания статуса службы Windows или управляющей программы Linux включите решение Отслеживание изменений и инвентаризация в службе автоматизации Azure.

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

Различные параметры для включения решения "Отслеживание изменений на виртуальных машинах" см. в разделе Включение решения "Отслеживание изменений и инвентаризация". Это решение включает методы для настройки виртуальных машин в масштабе. Для поддержки решения необходимо создать учетную запись Azure Automation.

При включении решения "Отслеживание изменений и инвентаризация" в рабочей области Log Analytics создаются две новые таблицы. Используйте эти таблицы для запросов журналов и правил оповещения для поиска журналов.

Пример запросов журнала

• Перечислите все службы и управляющие программы, которые были недавно запущены.

  ConfigurationChange
  | where ConfigChangeType == "Daemons" or ConfigChangeType == "WindowsServices"
  | where SvcState == "Running"
  | sort by Computer, SvcName
  

• Оповещение при остановке определенной службы. Используйте этот запрос в правиле генерации оповещений поиска по журналам.

  ConfigurationData
  | where SvcName == "W3SVC" 
  | where SvcState == "Stopped"
  | where ConfigDataType == "WindowsServices"
  | where SvcStartupType == "Auto"
  | summarize AggregatedValue = count() by Computer, SvcName, SvcDisplayName, SvcState, bin(TimeGenerated, 15m)
  

• Оповещение об остановке одного из наборов служб. Используйте этот запрос в правиле генерации оповещений поиска по журналам.

  let services = dynamic(["omskd","cshost","schedule","wuauserv","heathservice","efs","wsusservice","SrmSvc","CertSvc","wmsvc","vpxd","winmgmt","netman","smsexec","w3svc","sms_site_vss_writer","ccmexe","spooler","eventsystem","netlogon","kdc","ntds","lsmserv","gpsvc","dns","dfsr","dfs","dhcp","DNSCache","dmserver","messenger","w32time","plugplay","rpcss","lanmanserver","lmhosts","eventlog","lanmanworkstation","wnirm","mpssvc","dhcpserver","VSS","ClusSvc","MSExchangeTransport","MSExchangeIS"]);
  ConfigurationData
  | where ConfigDataType == "WindowsServices"
  | where SvcStartupType == "Auto"
  | where SvcName in (services)
  | where SvcState == "Stopped"
  | project TimeGenerated, Computer, SvcName, SvcDisplayName, SvcState
  | summarize AggregatedValue = count() by Computer, SvcName, SvcDisplayName, SvcState, bin(TimeGenerated, 15m)
  

Мониторинг порта

Функция мониторинга портов подтверждает, что компьютер прослушивает определенный порт. Здесь описаны две потенциальные стратегии мониторинга портов.

Таблицы агента зависимости

Если вы используете аналитику виртуальных машин с включенными коллекциями процессов и зависимостей, можно использовать VMConnection и VMBoundPort для анализа подключений и портов на компьютере. Таблица VMBoundPort обновляется каждую минуту с каждым процессом, выполняющимся на компьютере, и портом, который он прослушивает. Вы можете создать оповещение поиска по журналам, аналогичное оповещению об отсутствующем пульсе, чтобы найти остановившиеся процессы или для оповещения, когда компьютер не прослушивает определенный порт.

• Проверьте количество портов, открытых на виртуальных машинах, чтобы оценить, какие виртуальные машины имеют уязвимости конфигурации и безопасности.

  VMBoundPort
  | where Ip != "127.0.0.1"
  | summarize by Computer, Machine, Port, Protocol
  | summarize OpenPorts=count() by Computer, Machine
  | order by OpenPorts desc
  

• Перечислите привязанные порты на виртуальных машинах, чтобы оценить, какие виртуальные машины имеют уязвимости конфигурации и безопасности.

  VMBoundPort
  | distinct Computer, Port, ProcessName
  

• Проанализируйте активность сети по порту, чтобы определить, как настроено приложение или служба.

  VMBoundPort
  | where Ip != "127.0.0.1"
  | summarize BytesSent=sum(BytesSent), BytesReceived=sum(BytesReceived), LinksEstablished=sum(LinksEstablished), LinksTerminated=sum(LinksTerminated), arg_max(TimeGenerated, LinksLive) by Machine, Computer, ProcessName, Ip, Port, IsWildcardBind
  | project-away TimeGenerated
  | order by Machine, Computer, Port, Ip, ProcessName
  

• Проверьте статистику отправленных и полученных байтов для ваших виртуальных машин.

  VMConnection
  | summarize sum(BytesSent), sum(BytesReceived) by bin(TimeGenerated,1hr), Computer
  | order by Computer desc
  | render timechart
  

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

  VMConnection
  | where Computer == <replace this with a computer name, e.g. 'acme-demo'>
  | extend bythehour = datetime_part("hour", TimeGenerated)
  | project bythehour, LinksFailed
  | summarize failCount = count() by bythehour
  | sort by bythehour asc
  | render timechart
  

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

  VMConnection
  | where Computer == <replace this with a computer name, e.g. 'acme-demo'>
  | summarize dcount(LinksEstablished), dcount(LinksLive), dcount(LinksFailed), dcount(LinksTerminated) by bin(TimeGenerated, 1h)
  | render timechart
  

Диспетчер соединений

Функция Монитор подключений в Наблюдателе за сетями используется для проверки подключений к порту на виртуальной машине. Тест служит для подтверждения того, что компьютер прослушивает порт и доступен в сети.

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

При использовании диспетчера соединений предполагаются дополнительные затраты. Для получения дополнительной информации см. цены на Network Watcher.

Запуск процесса на локальном компьютере

Для мониторинга некоторых рабочих нагрузок требуется локальный процесс. В качестве примера можно привести скрипт PowerShell, выполняемый на локальном компьютере для подключения к приложению и получения или обработки данных. Можно использовать гибридный агент Runbook, который является частью службы автоматизации Azure, чтобы выполнить локальный скрипт PowerShell. За гибридный рабочий агент Runbook прямая плата не взимается, но за каждый использованный им runbook взимается плата.

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

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

• Анализ данных мониторинга, собираемых для виртуальных машин
• Создание оповещений на основе собранных данных