Поделиться через

Выбор правильного типа правила генерации оповещений

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

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

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

Тип оповещения Когда использовать Сведения о ценах
Уведомление о показателе Данные метрик хранятся в системе, уже предварительно компьютированные. Оповещения о метриках полезны, если вы хотите получать оповещения о данных, с которыми требуется выполнять минимальные действия. Используйте метрические оповещения, если данные, которые вы хотите отслеживать, доступны в метрических данных. Каждое правило оповещения по метрикам тарифицируется на основе количества временных рядов, которые отслеживаются.
Оповещение поиска журналов Вы можете использовать оповещения поиска по журналам для выполнения расширенных операций логики с данными. Если данные, которые требуется отслеживать, доступны в журналах или требуют расширенной логики, можно использовать надежные функции язык запросов Kusto (KQL) для обработки данных с помощью оповещений поиска по журналам. Правило оповещения для поиска по журналам тарифицируется в зависимости от интервала, с которым оценивается запрос к журналу. Более частое вычисление запросов приводит к более высокой стоимости. Для предупреждений поиска логов, настроенных для масштабного мониторинга с использованием разделения по измерениям, стоимость также зависит от количества временных рядов, создаваемых измерениями в результате вашего запроса.
Простое оповещение о поиске в журнале Идеально подходит для мониторинга приложений или сетевого трафика, где неагрегированный мониторинг в режиме реального времени и быстрый ответ на инциденты критически важны. Каждая ошибка активирует оповещение, что позволяет выполнять немедленное действие. Например, возможность оповещать при сбое каждого задания, будь то задание резервного копирования или любое другое автоматизированное действие, а также оповещать о событиях Windows, влияющих на нашу систему в качестве хранилища или для обеспечения безопасности. Каждое простое правило оповещения по журналу тарифицируется так же, как оповещения с частотой 1 минута.
Предупреждение журнала активности Журналы действий обеспечивают аудит всех действий, произошедших с ресурсами. Используйте оповещения журнала действий для оповещения, когда определенное событие происходит с ресурсом, например перезапуском, завершением работы или созданием или удалением ресурса. Оповещения о работоспособности службы и ресурса информируют вас о возникновении проблемы с одной из ваших служб или ресурсов. Дополнительные сведения см. на странице цен.
Оповещения Prometheus Оповещения Prometheus используются для предупреждения о метриках Prometheus, хранящихся в управляемых службах Azure Monitor для Prometheus. Правила генерации оповещений основаны на языке запросов с открытым исходным кодом PromQL. Правила оповещений Prometheus взимаются только за запрашиваемые правилами данные. Дополнительные сведения см. на странице цен.

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

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

Вы можете создавать правила с помощью следующих метрик:

Правила генерации оповещений по метрикам включают следующие функции:

Целевым объектом правила генерации оповещений по метрикам может быть:

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

При создании правила генерации оповещений для отдельного ресурса вы можете применить несколько условий. Например, вы можете создать правило генерации оповещений для отслеживания виртуальной машины Azure и создания оповещения в том случае, когда выполняются условия "Процент ЦП превышает 90 %" и "Длина очереди превышает 300 элементов". Если правило генерации оповещений имеет несколько условий, оповещение создается, когда все условия в правиле генерации оповещений верны, и сбрасывается, если хотя бы одно из условий перестаёт выполняться в течение трёх последовательных проверок.

Узкое определение цели с помощью параметров

Инструкции по использованию размерных параметров в правилах оповещения метрик см. в разделе «Мониторинг нескольких временных рядов в одном правиле оповещения метрик».

Мониторинг одного и того же условия для нескольких ресурсов с помощью разделения по измерениям

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

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

Мониторинг нескольких ресурсов с помощью одного правила генерации оповещений

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

Метрики платформы для этих служб поддерживаются в следующих облаках Azure:

Сервис Поставщик ресурсов Глобальная среда Azure Правительство Китай
Виртуальные машины Microsoft.Compute/virtualMachines Да Да Да
Базы данных SQL Server "Microsoft.Sql/servers/database" Да Да Да
Эластичные пулы SQL Server Microsoft.Sql/servers/elasticpools Да Да Да
Пулы ёмкости файлов NetApp Microsoft.NetApp/netAppAccounts/capacityPools Да Да Да
Файловые тома NetApp "Microsoft.NetApp/netAppAccounts/емкостьPools/тома" Да Да Да
Azure Key Vault Microsoft.KeyVault/vaults Да Да Да
Кэш Azure для Redis Microsoft.Cache/redis Да Да Да
Устройства Azure Stack Edge (Для этого ресурса нет определенного поставщика ресурсов. Из-за работы устройств Stack Edge метрики извлекаются из нескольких поставщиков ресурсов. Дополнительные сведения об оповещениях для этого ресурса см. в этой документации: просмотр оповещений в Azure Stack Edge) Да Да Да
Хранилище Сервисов восстановления Microsoft.RecoveryServices/Vaults Да Нет Нет
Гибкий сервер Базы данных Azure для PostgreSQL Microsoft.DBforPostgreSQL/flexibleServers Да Да Да
вычислительные машины на чистом железе (Оператор Nexus) "Microsoft.NetworkCloud/bareMetalMachines" Да Да Да
Устройства хранения (оператор Nexus) Microsoft.NetworkCloud/storageAppliances Да Да Да
Кластеры (Оператор Nexus) "Microsoft.NetworkCloud/clusters" Да Да Да
Сетевые устройства (оператор Nexus) Microsoft.NetworkCloud/l2Networks, Microsoft.NetworkCloud/l3Networks Да Да Да
Правила сбора данных "Microsoft.Insights/datacollectionrules" Да Да Да

Примечание.

Оповещения по метрикам для нескольких ресурсов не поддерживаются для:

  • Оповещение по метрикам гостевой операционной системы виртуальной машины.
  • Оповещения по метрикам сети виртуальной машины (Всего входящего трафика, Всего исходящего трафика, Входящие потоки, Исходящие потоки, Максимальная скорость создания входящих потоков, и Максимальная скорость создания исходящих потоков).

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

  • Список виртуальных машин в одном регионе Azure в рамках подписки.
  • Все ВМ в одном регионе Azure в одной или нескольких группах ресурсов в подписке.
  • Все виртуальные машины в одном регионе Azure в одной подписке.

Применение расширенного машинного обучения с динамическими порогами

Динамические пороговые значения используют расширенное машинное обучение для:

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

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

Динамические пороги помогут вам делать следующее:

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

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

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

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

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

  • Отдельный ресурс, например виртуальная машина.
  • Один контейнер ресурсов, например группа ресурсов или подписка.
  • Несколько ресурсов, которые используют запрос по нескольким ресурсам.

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

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

Можно настроить, являются ли оповещения поиска по журналам с отслеживанием состояния или без.

Оповещения поиска в журналах с отслеживанием состояния имеют следующие ограничения:

  • Они могут вызывать до 300 оповещений за оценку.
  • Вы можете иметь максимум 5 000 оповещений при условии fired.

Примечание.

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

Мониторинг нескольких экземпляров ресурса с помощью измерений

Вы можете использовать измерения при создании правил оповещения поиска по журналам, чтобы отслеживать значения нескольких экземпляров ресурса с помощью одного правила. Например, вы можете отслеживать использование ЦП на нескольких экземплярах, на которых работает веб-сайт или приложение. Каждый экземпляр отслеживается индивидуально. Уведомления отправляются для каждого экземпляра.

Мониторинг одного и того же условия для нескольких ресурсов с помощью разделения по измерениям

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

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

Используйте API для правил оповещений поиска по логам

Управляйте новыми правилами в рабочих областях с помощью API ScheduledQueryRules.

Примечание.

Оповещения поиска журналов для Log Analytics раньше управлялись с помощью устаревшего API оповещений Log Analytics. Узнайте больше о переключении на текущий API ScheduledQueryRules.

Поиск оповещений в журнале вашего счета Azure

Оповещения поиска по журналам перечислены у поставщика ресурсов microsoft.insights/scheduledqueryrules:

  • Оповещения поиска журналов в Application Insights отображаются с точным названием ресурса, включая группу ресурсов и свойства оповещения.
  • Оповещения поиска по журналам в Log Analytics отображаются с точным именем ресурса вместе с ресурсной группой и свойствами оповещения, когда они создаются с помощью API scheduledQueryRules.
  • Оповещения поиска журналов, созданные из устаревшего API Log Analytics, не отслеживаются как ресурсы Azure и не имеют обязательных уникальных имен ресурсов. Эти оповещения по-прежнему создаются в виде скрытых ресурсов на microsoft.insights/scheduledqueryrules, которые имеют структуру именования ресурсов <WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>. Оповещения поиска по журналам в устаревшем API отображаются с указанным выше скрытым именем ресурса, а также свойствами группы ресурсов и оповещений.

Примечание.

Неподдерживаемые символы ресурсов, такие как <, >%, &, ? и /заменяются символом подчеркивания (_) в скрытых именах ресурсов. Это изменение символа также отражается в сведениях о выставлении счетов.

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

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

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

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

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

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

Для таких типов сценариев может потребоваться использовать оповещения журнала действий:

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

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

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

Правила генерации оповещений журнала действий являются ресурсами Azure, поэтому их можно создать с помощью шаблона Azure Resource Manager. Их также можно создать, обновить или удалить на портале Azure.

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

Оповещения о состоянии служб

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

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

Оповещения о состоянии ресурсов

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

Для оценки состояния ресурса в службе "Работоспособность ресурсов" используются сигналы от различных служб Azure. Если ресурс имеет проблемы, служба Resource Health анализирует дополнительную информацию для определения источника проблемы. Он также сообщает о действиях, которые корпорация Майкрософт принимает для устранения проблемы и определяет действия, которые можно предпринять для решения этой проблемы.

Оповещения интеллектуального обнаружения

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

Интеллектуальное обнаружение использует машинное обучение для поиска этих аномалий. Интеллектуальное обнаружение отслеживает данные, полученные от приложения, и, в частности, частоту сбоев. Application Insights автоматически уведомляет вас (почти в реальном времени), если работа веб-приложения сопровождается чрезмерно частыми неудачными запросами.

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

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

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

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

Оповещения Prometheus

Оповещения Prometheus используются для мониторинга метрик, хранящихся в управляемых службах Azure Monitor для Prometheus. Правила оповещений Prometheus настраиваются как часть групп правил Prometheus. Они запускаются, когда результат выражения PromQL принимает значение true. Оповещения Prometheus отображаются и управляются так же, как и другие типы оповещений.

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