Мониторинг виртуальных машин с помощью Azure Monitor: сбор данных
Эта статья является частью руководства по мониторингу виртуальных машин и их рабочих нагрузок в Azure Monitor. В нем описывается настройка сбора данных после развертывания агента Azure Monitor в Azure и гибридных виртуальных машинах в Azure Monitor.
В этой статье приводятся рекомендации по сбору наиболее распространенных типов телеметрии с виртуальных машин. Точная конфигурация зависит от рабочих нагрузок, выполняемых на компьютерах. В каждом разделе приведены примеры оповещений поиска по журналам, которые можно использовать с данными.
- Дополнительные сведения об анализе данных телеметрии, собранных с виртуальных машин, см. в статье "Мониторинг виртуальных машин с помощью Azure Monitor: анализ данных мониторинга".
- Дополнительные сведения об использовании телеметрии, собираемой с виртуальных машин для создания оповещений в Azure Monitor, см. в статье "Мониторинг виртуальных машин с помощью Azure Monitor: оповещения".
Примечание.
В этом сценарии описывается, как реализовать комплексный мониторинг среды виртуальных машин в Azure и гибридном окружении. Чтобы приступить к наблюдению за первой виртуальной машиной Azure, см. статью Мониторинг виртуальных машин Azure.
Правила сбора данных
Сбор данных из агента Azure Monitor определяется одним или несколькими правилами сбора данных (DCR), которые хранятся в подписке Azure и связаны с виртуальными машинами.
Для виртуальных машин контроллеры домена определяют такие данные, как события и счетчики производительности для сбора и указания рабочих областей Log Analytics, в которых должны отправляться данные. DCR также может использовать преобразования для фильтрации нежелательных данных и добавления вычисляемых столбцов. Один компьютер может быть связан с несколькими контроллерами домена, а один DCR может быть связан с несколькими компьютерами. Контроллеры домена доставляются на все компьютеры, с которыми они связаны, где агент Azure Monitor обрабатывает их.
Просмотр правил сбора данных
Вы можете просмотреть контроллеры домена в подписке Azure из правил сбора данных в меню "Монитор" в портал Azure. Контроллеры домена поддерживают другие сценарии сбора данных в Azure Monitor, поэтому все контроллеры домена не обязательно для виртуальных машин.
Создание правил сбора данных
Существует несколько методов создания контроллеров домена в зависимости от сценария сбора данных. В некоторых случаях портал Azure проходит по конфигурации. Другие сценарии требуют непосредственного редактирования DCR. При настройке аналитики виртуальных машин он создает предварительно настроенный DCR для вас автоматически. В следующих разделах описаны общие данные для сбора и настройки сбора данных.
В некоторых случаях для добавления функций может потребоваться изменить существующий DCR . Например, можно использовать портал Azure для создания DCR, который собирает события Windows или Syslog. Затем необходимо добавить преобразование в этот DCR, чтобы отфильтровать столбцы в событиях, которые не нужно собирать.
По мере того как среда зрела и растет сложность, следует реализовать стратегию организации контроллеров домена, чтобы помочь их управлению. Рекомендации по различным стратегиям см. в рекомендациях по созданию правил сбора данных и управлению ими в Azure Monitor.
Управление затратами
Так как затраты Azure Monitor зависят от объема собираемых данных, убедитесь, что вы не собираете больше, чем вам нужно выполнить требования к мониторингу. Конфигурация — это баланс между бюджетом и объемом аналитических сведений о работе виртуальных машин.
Совет
Стратегии снижения затрат Azure Monitor см. в статье "Оптимизация затрат" и Azure Monitor.
Типичная виртуальная машина создает от 1 ГБ до 3 ГБ данных в месяц. Этот размер данных зависит от конфигурации компьютера, рабочих нагрузок, работающих на нем, и конфигурации контроллеров домена. Перед настройкой сбора данных во всей среде виртуальной машины запустите сбор на некоторых репрезентативных компьютерах, чтобы лучше прогнозировать ожидаемые затраты при развертывании в среде. Используйте аналитику рабочей области Log Analytics или запросы журналов в томе данных на компьютере , чтобы определить объем оплачиваемых данных, собранных для каждого компьютера, и соответствующим образом настроить их.
Оцените собранные данные и отфильтруйте все, что соответствует следующим критериям, чтобы сократить затраты. Каждый собранный источник данных может иметь другой метод фильтрации нежелательных данных. Дополнительные сведения о каждом из общих источников данных см. в разделах ниже.
- Не используется для оповещения.
- Неизвестное судебно-диагностическое значение или диагностическое значение.
- Не требуется регуляторам.
- Не используется в каких-либо панелях мониторинга или книгах.
Вы также можете использовать преобразования для реализации более детализированной фильтрации, а также для фильтрации данных из столбцов , которые предоставляют малое значение. Например, событие Windows, представляющее ценность для целей оповещения, может содержать столбцы с избыточными или ненужными данными. Вы можете создать преобразование, которое позволит собирать это событие с одновременным удалением этих чрезмерных данных.
Чтобы избежать потенциальной платы за фильтрацию слишком большого объема данных с помощью преобразований, отфильтруйте данные как можно больше, прежде чем отправлять их в Azure Monitor. Используйте преобразования для фильтрации записей с помощью сложной логики и фильтрации столбцов с данными, которые не требуются.
Сбор данных по умолчанию
Azure Monitor автоматически выполняет следующую коллекцию данных, не требуя другой конфигурации.
Метрики платформы
Метрики платформы для виртуальных машин Azure включают важные метрики узлов, такие как ЦП, сеть и использование дисков. Они могут быть следующими:
- Просматривается на странице обзора.
- Анализируется с помощью обозревателя метрик для компьютера в портал Azure.
- Используется для оповещений метрик.
Журнал действий
Журнал действий собирается автоматически. Он включает в себя последнее действие компьютера, например любые изменения конфигурации, а также время его остановки и запуска. Вы можете просмотреть метрики платформы и журнал действий, собранные для каждого узла виртуальной машины в портал Azure.
Журнал действий можно просмотреть для отдельного компьютера или для всех ресурсов в подписке. Создайте параметр диагностики для отправки этих данных в ту же рабочую область Log Analytics, которая используется агентом Azure Monitor для анализа данных мониторинга, собранных для виртуальной машины. Нет затрат на прием или хранение данных журнала действий.
Сведения о доступности виртуальной машины в Azure Resource Graph
С помощью Azure Resource Graph можно использовать те же язык запросов Kusto, которые используются в запросах журналов для запроса ресурсов Azure в масштабе с помощью сложной фильтрации, группировки и сортировки по свойствам ресурсов. Заметки о работоспособности виртуальных машин можно использовать в Resource Graph для подробного анализа ошибок и простоя.
Сведения о собранных данных и его просмотре см. в статье "Мониторинг виртуальных машин с помощью Azure Monitor: анализ данных мониторинга".
Аналитика виртуальных машин
При включении аналитики виртуальных машин создается DCR с префиксом MSVMI, который собирает следующие сведения. Этот же DCR можно использовать с другими компьютерами в отличие от создания нового для каждой виртуальной машины.
Общие счетчики производительности для клиентской операционной системы отправляются в таблицу Аналитика Метрики в рабочей области Log Analytics. Имена счетчиков нормализуются для использования одного и того же общего имени независимо от типа операционной системы. Список собранных счетчиков производительности см. в статье "Как запрашивать журналы из аналитики виртуальных машин".
Если вы указали процессы и зависимости для сбора, заполните следующие таблицы:
- V МБ oundPort: трафик для открытых портов сервера на компьютере
- VMComputer: данные инвентаризации для компьютера
- Виртуальная машина Подключение ion: трафик для входящих и исходящих подключений к компьютеру и с него
- VMProcess: процессы, выполняемые на компьютере
По умолчанию аналитика виртуальных машин не включает сбор процессов и зависимостей для экономии затрат на прием данных. Эти данные необходимы для функции map, а также развертывают агент зависимостей на компьютере. Включите эту коллекцию , если вы хотите использовать эту функцию.
Сбор событий Windows и Системного журнала
Операционная система и приложения на виртуальных машинах часто записываются в журнал событий Windows или системный журнал. Вы можете создать оповещение сразу после того, как одно событие найдено или подождите ряд соответствующих событий в течение определенного периода времени. Вы также можете собирать события для последующего анализа, например определение конкретных тенденций с течением времени или выполнение устранения неполадок после возникновения проблемы.
Инструкции по созданию DCR для сбора событий Windows и Системного журнала см. в статье Сбор событий и счетчиков производительности с виртуальных машин с помощью агента Azure Monitor. Вы можете быстро создать DCR с помощью наиболее распространенных журналов событий Windows и средств системного журнала, фильтрующих по уровню событий.
Для более детальной фильтрации по таким критериям, как идентификатор события, можно создать пользовательский фильтр с помощью запросов XPath. Вы можете дополнительно отфильтровать собранные данные, изменив DCR , чтобы добавить преобразование.
Используйте следующее руководство в качестве рекомендуемой отправной точки для сбора событий. Измените параметры DCR, чтобы отфильтровать ненужные события и добавить другие события в зависимости от ваших требований.
| Оригинал | Стратегия |
|---|---|
| События Windows | Сбор по крайней мере критических, ошибок и предупреждений для журналов системы и приложений для поддержки оповещений. Добавьте события сведений для анализа тенденций и поддержки устранения неполадок. Подробные события редко полезны и обычно не должны собираться. |
| события системного журнала; | Сбор по крайней мере LOG_WARNING событий для каждого объекта для поддержки оповещений. Добавьте события сведений для анализа тенденций и поддержки устранения неполадок. LOG_DEBUG события редко полезны и обычно не должны собираться. |
Примеры запросов журналов: события Windows
| Query | Description |
|---|---|
Event |
Все события Windows |
Event | where EventLevelName == "Error" |
Все события Windows с серьезностью ошибки |
Event | summarize count() by Source |
Количество событий Windows по источнику |
Event | where EventLevelName == "Error" | summarize count() by Source |
Количество событий ошибок Windows по источнику |
Примеры запросов журнала: события системного журнала
| Query | Description |
|---|---|
Syslog |
Все системные журналы |
Syslog | where SeverityLevel == "error" |
Все записи системного журнала с серьезностью ошибки |
Syslog | summarize AggregatedValue = count() by Computer |
Количество записей системного журнала по компьютеру |
Syslog | summarize AggregatedValue = count() by Facility |
Количество записей системного журнала по объекту |
Сбор данных счетчиков производительности
Данные о производительности клиента можно отправлять в метрики Azure Monitor или журналы Azure Monitor, а обычно отправлять их в оба назначения. Если вы включили аналитику виртуальных машин, общий набор счетчиков производительности собирается в журналах для поддержки диаграмм производительности. Этот набор счетчиков нельзя изменить, но можно создать другие контроллеры домена для сбора дополнительных счетчиков и отправки их в разные места назначения.
Существует несколько причин, по которым необходимо создать DCR для сбора гостевой производительности:
- Вы не используете аналитику виртуальных машин, поэтому данные о производительности клиента еще не собираются.
- Соберите другие счетчики производительности, которые аналитика виртуальных машин не собирает.
- Сбор счетчиков производительности из других рабочих нагрузок, работающих на клиенте.
- Отправьте данные о производительности в метрики Azure Monitor, где их можно использовать с оповещениями обозревателя метрик и метрик.
Рекомендации по созданию DCR для сбора счетчиков производительности см. в статье Сбор событий и счетчиков производительности с виртуальных машин с помощью агента Azure Monitor. Вы можете быстро создать DCR с помощью наиболее распространенных счетчиков. Для более детальной фильтрации по таким критериям, как идентификатор события, можно создать пользовательский фильтр с помощью запросов XPath.
Примечание.
Вы можете объединить коллекцию событий и производительности в одном DCR.
| Назначение | Description |
|---|---|
| Метрики | Метрики узлов автоматически отправляются в метрики Azure Monitor. Для сбора клиентских метрик можно использовать DCR, чтобы их можно было анализировать вместе с обозревателем метрик или использовать с оповещениями метрик. Эти данные хранятся в течение 93 дней. |
| Журналы | Данные о производительности, хранящиеся в журналах Azure Monitor, могут храниться в течение длительных периодов. Данные можно анализировать вместе с данными о событиях с помощью запросов журналов с помощью оповещений log Analytics или оповещений поиска по журналам. Кроме того, можно сопоставить данные с помощью сложной логики на нескольких компьютерах, регионах и подписках. Данные о производительности отправляются в следующие таблицы: — аналитика виртуальных машин: Аналитика Метрики - Другие данные о производительности: Perf |
Пример запросов журнала
В следующих примерах используется таблица с пользовательскими данными Perf о производительности. Сведения о данных о производительности, собранных аналитикой виртуальных машин, см. в статье "Как запрашивать журналы из аналитики виртуальных машин".
| Query | Description |
|---|---|
Perf |
Все данные о производительности. |
Perf | where Computer == "MyComputer" |
Все данные о производительности с определенного компьютера |
Perf | where CounterName == "Current Disk Queue Length" |
Все данные о производительности с определенного счетчика |
Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" and InstanceName == "_Total" | summarize AVGCPU = avg(CounterValue) by Computer |
Средний объем использования ЦП на всех компьютерах |
Perf | where CounterName == "% Processor Time" | summarize AggregatedValue = max(CounterValue) by Computer |
Максимальный объем использования ЦП на всех компьютерах |
Perf | where ObjectName == "LogicalDisk" and CounterName == "Current Disk Queue Length" and Computer == "MyComputerName" | summarize AggregatedValue = avg(CounterValue) by InstanceName |
Средняя длина текущей дисковой очереди по всем экземплярам заданного компьютера |
Perf | where CounterName == "Disk Transfers/sec" | summarize AggregatedValue = percentile(CounterValue, 95) by Computer |
95-й процентиль для обращений к диску/с на всех компьютерах |
Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" | summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 1h), Computer |
Средняя почасовая нагрузка на ЦП по всем компьютерам |
Perf | where Computer == "MyComputer" and CounterName startswith_cs "%" and InstanceName == "_Total" | summarize AggregatedValue = percentile(CounterValue, 70) by bin(TimeGenerated, 1h), CounterName |
Почасовые 70-е процентили по каждому процентному счетчику для конкретного компьютера |
Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" and Computer == "MyComputer" | summarize ["min(CounterValue)"] = min(CounterValue), ["avg(CounterValue)"] = avg(CounterValue), ["percentile75(CounterValue)"] = percentile(CounterValue, 75), ["max(CounterValue)"] = max(CounterValue) by bin(TimeGenerated, 1h), Computer |
Почасовые средние, минимальные, максимальные значения и 75-е процентили по загрузке ЦП для конкретного компьютера |
Perf | where ObjectName == "MSSQL$INST2:Databases" and InstanceName == "master" |
Все данные производительности из объекта производительности базы данных master именованного экземпляра SQL Server (INST2). |
Perf | where TimeGenerated >ago(5m) | where ObjectName == "Process" and InstanceName != "_Total" and InstanceName != "Idle" | where CounterName == "% Processor Time" | summarize cpuVal=avg(CounterValue) by Computer,InstanceName | join (Perf| where TimeGenerated >ago(5m)| where ObjectName == "Process" and CounterName == "ID Process" | summarize arg_max(TimeGenerated,*) by ProcID=CounterValue ) on Computer,InstanceName | sort by TimeGenerated desc | summarize AvgCPU = avg(cpuVal) by InstanceName,ProcID |
Среднее значение ЦП за последние 5 минут для каждого идентификатора процесса. |
Сбор текстовых журналов
Некоторые приложения записывают события, записанные в текстовый журнал, хранящийся на виртуальной машине. Создайте настраиваемую таблицу и DCR для сбора этих данных. Вы определяете расположение текстового журнала, его подробную конфигурацию и схему настраиваемой таблицы. Прием и хранение этих данных в рабочей области предполагает определенные затраты.
Пример запросов журнала
Имена столбцов, используемые здесь, являются только примерами. Скорее всего, имена столбцов для журнала будут отличаться.
| Query | Description |
|---|---|
MyApp_CL | summarize count() by code |
Подсчитайте количество событий по коду. |
MyApp_CL | where status == "Error" | summarize AggregatedValue = count() by Computer, bin(TimeGenerated, 15m) |
Создание правила генерации оповещений для любого события ошибки. |
Сбор журналов IIS
Службы IIS, работающие на компьютерах Windows, записывают журналы в текстовый файл. Настройте коллекцию журналов IIS с помощью сбора журналов IIS с помощью агента Azure Monitor. Прием и хранение этих данных в рабочей области предполагает определенные затраты.
Записи из журнала служб IIS хранятся в таблице W3CIISLOG в рабочей области Log Analytics. Прием и хранение этих данных в рабочей области предполагает определенные затраты.
Пример запросов журнала
| Query | Description |
|---|---|
W3CIISLog | where csHost=="www.contoso.com" | summarize count() by csUriStem |
Подсчитывать записи журнала IIS по URL-адресу для www.contoso.com узла. |
W3CIISLog | summarize sum(csBytes) by Computer |
Проверьте общее число байтов, полученных каждым компьютером IIS. |
Мониторинг службы или управляющей программы
Для отслеживания статуса службы Windows или управляющей программы Linux включите решение Отслеживание изменений и инвентаризация в службе автоматизации Azure.
Azure Monitor не может самостоятельно отслеживать состояние службы или управляющей программы. Доступно несколько методов, например поиск событий в журнале событий Windows, однако этот метод является ненадежным. Вы также можете искать процесс, связанный со службой, работающей на компьютере, из таблицы VMProcess , заполненной аналитикой виртуальных машин. Эта таблица обновляется только каждый час, что обычно недостаточно, если вы хотите использовать эти данные для оповещения.
Примечание.
Решение "Отслеживание изменений и анализ" отличается от функции Анализ изменений в службе аналитики виртуальных машин. Эта функция доступна в общедоступной предварительной версии и еще не включена в этот сценарий.
Различные параметры для включения решения "Отслеживание изменений на виртуальных машинах" см. в разделе Включение решения "Отслеживание изменений и инвентаризация". Это решение включает методы для настройки виртуальных машин в масштабе. Для поддержки решения необходимо создать учетную запись служба автоматизации Azure.
При включении решения "Отслеживание изменений и инвентаризация" в рабочей области Log Analytics создаются две новые таблицы. Используйте эти таблицы для запросов журналов и правил генерации оповещений поиска журналов.
| Таблицу | Description |
|---|---|
| ConfigurationChange | Изменения в данных конфигурации в гостевой системе |
| ConfigurationData | Последний полученный статус отчета о данных конфигурации в гостевой системе |
Пример запросов журнала
Перечислите все службы и управляющие программы, которые были недавно запущены.
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)
Мониторинг порта
Функция мониторинга портов подтверждает, что компьютер прослушивает определенный порт. Здесь описаны две потенциальные стратегии мониторинга портов.
Таблицы агента зависимостей
Если вы используете аналитику виртуальных машин с включенными коллекциями процессов и зависимостей, можно использовать виртуальную машину Подключение ion и V МБ oundPort для анализа подключений и портов на компьютере. Таблица 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.
При использовании диспетчера соединений предполагаются дополнительные затраты. Дополнительные сведения см. в Наблюдатель за сетями ценах.
Запуск процесса на локальном компьютере
Для мониторинга некоторых рабочих нагрузок требуется локальный процесс. В качестве примера можно привести скрипт PowerShell, выполняемый на локальном компьютере для подключения к приложению и получения или обработки данных. Можно использовать гибридную рабочую роль Runbook, которая входит в службу автоматизации Azure, для выполнения локального скрипта PowerShell. Плата за гибридную рабочую роль Runbook не взимается, но для каждого модуля Runbook, который он использует, взимается плата.
Модуль Runbook может получить доступ к любым ресурсам на локальном компьютере для сбора необходимых данных. Он не может отправлять данные непосредственно в Azure Monitor или создавать оповещения. Чтобы создать оповещение, напишите запись модуля Runbook в пользовательский журнал. Затем настройте этот журнал для сбора Azure Monitor. Создайте правило генерации оповещений поиска по журналам, которое запускается в этой записи журнала.