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

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

В этом сценарии описывается, как реализовать полный мониторинг среды Azure и гибридной виртуальной машины:

• Чтобы приступить к наблюдению за первой виртуальной машиной Azure, см. статью Мониторинг виртуальных машин Azure.

• Чтобы быстро включить рекомендуемый набор оповещений, см . статью "Включить рекомендуемые правила генерации оповещений" для виртуальной машины Azure.

сбор данных

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

Рекомендуемые правила генерации оповещений

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

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

Типы оповещений

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

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

Оповещения по метрикам

Распространённые варианты использования оповещений по метрикам:

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

Источники данных для оповещений на основе метрик:

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

Оповещения для поиска по журналам

Распространенные способы использования оповещений поиска по журналам:

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

Источники данных для оповещений поиска по журналам:

• Все данные, собранные в рабочей области Log Analytics

Масштабирование правил генерации оповещений

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

Правила оповещений по метрикам

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

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

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

• Свести к минимуму количество правил генерации оповещений, которым необходимо управлять.
• Убедитесь, что они автоматически применяются к любым новым компьютерам.

Правила генерации оповещений для поиска по журналам

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

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

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

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

Измерения

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

Динамические пороги

Еще одним преимуществом использования правил генерации оповещений поиска по журналам является возможность включения сложной логики в запрос для определения порогового значения. Жестко закодировать пороговое значение, применить его ко всем ресурсам или вычислить его динамически на основе определенного поля или вычисляемого значения. Пороговое значение применяется только к ресурсам в соответствии с конкретными условиями. Например, вы можете создать оповещение на основе доступной памяти, но только для компьютеров с определенным объемом общей памяти.

Стандартные правила генерации оповещений

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

Доступность компьютера

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

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

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

Пульс агента

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

И метрика Heartbeat, и таблица журналов Heartbeat основаны на одном и том же ежеминутном сигнале Heartbeat, который агент Azure Monitor отправляет в рабочую область Log Analytics. Агент записывает запись в таблицу журнала Heartbeat каждую минуту. Затем метрика Heartbeat формируется из этих данных журнала с помощью автоматического преобразования журналов в метрики, что делает её доступной в хранилище метрик рабочей области для оповещений, близких к реальному времени. Разница между двумя типами оповещений заключается в том, как каждый использует эти данные:

• Оповещения по метрикам используют преобразованную метрику Heartbeat. Они работают почти в реальном времени, с сохранением состояния (уведомление отправляется один раз при срабатывании и один раз при устранении проблемы) и имеют встроенную поддержку таких измерений, как имя компьютера. Оповещения метрик рекомендуется использовать при обнаружении отсутствия пульса.
• Оповещения поиска по журналам выполняют запросы к таблице Heartbeat напрямую. По своей природе они работают с большей задержкой, поскольку анализируют журнальные данные с заданной частотой. Оповещения на основе поиска по логам могут быть с сохранением состояния или без сохранения состояния и поддерживают гибкую фильтрацию на основе KQL, но они менее эффективны для обнаружения отсутствия данных.

Оповещения пульса агента зависят от передачи данных телеметрии из агента Azure Monitor через конвейер приема до закрытия окна оценки оповещений. Кратковременная задержка на стороне агента или при приёме данных может привести к тому, что записи heartbeat поступят после окна оценки, из-за чего сработает оповещение, даже если виртуальная машина исправна, а агент отправляет данные в обычном режиме.

Если ваша цель — определить, работает ли виртуальная машина Azure, используйте оповещение на основе метрики доступности виртуальной машины, которое оценивается платформой Azure и не подвержено задержкам агента или задержкам при приеме журналов.

Используйте оповещение о пульсе агента, если ваша цель — именно проверить состояние агента (например, на гибридных компьютерах или чтобы убедиться, что телеметрия рабочей нагрузки поступает). При использовании оповещений на основе сигналов проверки работоспособности учитывайте типичную задержку поступления данных при выборе окна оценки и порогового значения. Чтобы диагностировать задержку в таблице Heartbeat, см. примеры запросов в разделе Запросы для таблицы Heartbeat и Время приема данных журналов в Azure Monitor.

Правила оповещений по метрике пульса агента

Каждая рабочая область Log Analytics включает метрику с именем Heartbeat. Каждая виртуальная машина, подключённая к этой рабочей области, каждую минуту отправляет значение метрики heartbeat. Так как компьютер является измерением метрики, задайте оповещение, если любой компьютер не сможет отправить пульс. Задайте для параметра Тип агрегирования значение Количество, а для параметра Пороговое значение — значение, соответствующее степени детализации оценки.

Правила генерации оповещений поиска журнала для пульса агента

Оповещения поиска по журналам используют таблицу Heartbeat, которая должна иметь запись пульса каждую минуту от каждого компьютера.

Используйте правило со следующим запросом:

Heartbeat
| summarize TimeGenerated=max(TimeGenerated) by Computer, _ResourceId
| extend Duration = datetime_diff('minute',now(),TimeGenerated)
| summarize MinutesSinceLastHeartbeat = min(Duration) by Computer, bin(TimeGenerated,5m), _ResourceId

Оповещения о ЦП

Настройте оповещение о высокой загрузке процессора с помощью метрики узла или счётчиков производительности гостевой системы.

Правила генерации оповещений по метрикам для ЦП

Правила оповещений для поиска по журналам для процессора

Загрузка ЦП

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "Processor" and Name == "UtilizationPercentage"
| summarize CPUPercentageAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId

Оповещения о памяти

Настройте оповещение о низком объеме доступной памяти с помощью метрики хоста или счетчиков производительности гостевой ОС.

Правила генерации оповещений по метрикам памяти

Правила оповещений на основе поиска по журналам для памяти

Доступная память в МБ

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "Memory" and Name == "AvailableMB"
| summarize AvailableMemoryInMBAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId

Доступная память в процентах

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "Memory" and Name == "AvailableMB"
| extend TotalMemory = toreal(todynamic(Tags)["vm.azm.ms/memorySizeMB"]) | extend AvailableMemoryPercentage = (toreal(Val) / TotalMemory) * 100.0
| summarize AvailableMemoryInPercentageAverage = avg(AvailableMemoryPercentage) by bin(TimeGenerated, 15m), Computer, _ResourceId  

Оповещения о загрузке диска

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

Правила оповещений по метрикам для диска

Правила оповещений для поиска по журналам для диска

Используемый логический диск — все диски на каждом компьютере

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "LogicalDisk" and Name == "FreeSpacePercentage"
| summarize LogicalDiskSpacePercentageFreeAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId 

Используемый логический диск — отдельные диски

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "LogicalDisk" and Name == "FreeSpacePercentage"
| extend Disk=tostring(todynamic(Tags)["vm.azm.ms/mountId"])
| summarize LogicalDiskSpacePercentageFreeAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, Disk 

IOPS логического диска

InsightsMetrics
| where Origin == "vm.azm.ms" 
| where Namespace == "LogicalDisk" and Name == "TransfersPerSecond"
| extend Disk=tostring(todynamic(Tags)["vm.azm.ms/mountId"])
| summarize DiskIOPSAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, Disk 

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

InsightsMetrics
| where Origin == "vm.azm.ms" 
| where Namespace == "LogicalDisk" and Name == "BytesPerSecond"
| extend Disk=tostring(todynamic(Tags)["vm.azm.ms/mountId"])
| summarize DiskBytesPerSecondAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, Disk 

Сетевые оповещения

Задайте оповещение о пропускной способности сети с помощью счетчиков производительности узла или гостевой производительности.

Правила оповещений по метрикам для сети

Правила оповещений для поиска по журналам сети

Количество полученных байт по всем сетевым интерфейсам

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "Network" and Name == "ReadBytesPerSecond"
| summarize BytesReceivedAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId  

Количество полученных байт по отдельным сетевым интерфейсам

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "Network" and Name == "ReadBytesPerSecond"
| extend NetworkInterface=tostring(todynamic(Tags)["vm.azm.ms/networkDeviceId"])
| summarize BytesReceievedAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, NetworkInterface 

Байты, отправленные через сетевые интерфейсы — все интерфейсы

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "Network" and Name == "WriteBytesPerSecond"
| summarize BytesSentAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId 

Количество байт, отправленных через отдельные сетевые интерфейсы

InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "Network" and Name == "WriteBytesPerSecond"
| extend NetworkInterface=tostring(todynamic(Tags)["vm.azm.ms/networkDeviceId"])
| summarize BytesSentAverage = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, NetworkInterface 

События Windows и Linux

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

• Создание правила генерации оповещений для определенного события Windows. В этом примере показано событие в журнале приложений. Укажите пороговое значение 0 и число последовательных нарушений больше 0.

  Event 
  | where EventLog == "Application"
  | where EventID == 123 
  | summarize NumberOfEvents = count() by Computer, bin(TimeGenerated, 15m)
  

• Создание правила генерации оповещений для событий Syslog с определенным уровнем серьезности. В следующем примере показаны события ошибок авторизации. Укажите пороговое значение 0 и число последовательных нарушений больше 0.

  Syslog
  | where Facility == "auth"
  | where SeverityLevel == "err"
  | summarize NumberOfEvents = count() by Computer, bin(TimeGenerated, 15m)
  

настраиваемые счетчики производительности;

• Создание оповещения по достижении максимального значения счетчика.

  Perf 
  | where CounterName == "My Counter" 
  | summarize AggregatedValue = max(CounterValue) by Computer
  

• Создание оповещения по достижении среднего значения счетчика.

  Perf 
  | where CounterName == "My Counter" 
  | summarize AggregatedValue = avg(CounterValue) by Computer
  

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

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