Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описаны типы оповещений Azure Monitor, которые можно создать. Это помогает понять, когда следует использовать каждое оповещение. Дополнительные сведения о ценах см. на странице цен.
Типы оповещений:
- Оповещения на основе метрик
- Log search alerts
- Оповещения на основе журнала действий
- Оповещения интеллектуального обнаружения
- Оповещения Prometheus
Типы оповещений Azure Monitor
Тип оповещения | Когда использовать | Сведения о ценах |
---|---|---|
Уведомление о показателе | Данные метрик хранятся в системе, уже предварительно компьютированные. Оповещения о метриках полезны, если вы хотите получать оповещения о данных, с которыми требуется выполнять минимальные действия. Используйте метрические оповещения, если данные, которые вы хотите отслеживать, доступны в метрических данных. | Каждое правило оповещения по метрикам тарифицируется на основе количества временных рядов, которые отслеживаются. |
Log search alert | Вы можете использовать оповещения поиска по журналам для выполнения расширенных операций логики с данными. Если данные, которые требуется отслеживать, доступны в журналах или требуют расширенной логики, можно использовать надежные функции язык запросов Kusto (KQL) для обработки данных с помощью оповещений поиска по журналам. | Each log search alert rule is billed based on the interval at which the log query is evaluated. More frequent query evaluation results in a higher cost. For log search alerts configured for at-scale monitoring using splitting by dimensions, the cost also depends on the number of time series created by the dimensions resulting from your query. |
Простое оповещение о поиске в журнале | Идеально подходит для мониторинга приложений или сетевого трафика, где неагрегированный мониторинг в режиме реального времени и быстрый ответ на инциденты критически важны. Каждая ошибка активирует оповещение, что позволяет выполнять немедленное действие. Например, оповещение о каждом неудавшемся задании резервного копирования или любом другом автоматизированном процессе, способность оповещать о событиях Windows, влияющих на нашу систему как на систему хранения или безопасности. | Каждое простое правило оповещения по журналу тарифицируется так же, как оповещения с частотой 1 минута. |
Предупреждение журнала активности | Журналы действий обеспечивают аудит всех действий, произошедших с ресурсами. Используйте оповещения журнала действий для оповещения, когда определенное событие происходит с ресурсом, например перезапуском, завершением работы или созданием или удалением ресурса. Оповещения о работоспособности службы и ресурса информируют вас о возникновении проблемы с одной из ваших служб или ресурсов. | Дополнительные сведения см. на странице цен. |
Оповещения Prometheus | Оповещения Prometheus используются для предупреждения о метриках Prometheus, хранящихся в управляемых службах Azure Monitor для Prometheus. Правила генерации оповещений основаны на языке запросов с открытым исходным кодом PromQL. | Prometheus alert rules are only charged on the data queried by the rules. Дополнительные сведения см. на странице цен. |
Metric alerts
Правило оповещения по метрике контролирует ресурс, оценивая условия на метриках ресурса с регулярной периодичностью. If the conditions are met, an alert is fired. Временные ряды метрик — это ряд значений метрик, зарегистрированных за определенный период времени.
Вы можете создавать правила с помощью следующих метрик:
- Метрики платформы
- Пользовательские метрики
- Application Insights custom metrics
- Выбранные журналы из рабочей области Log Analytics, преобразованные в метрики
Правила генерации оповещений по метрикам включают следующие функции:
- Для одного ресурса можно использовать несколько условий в правиле генерации оповещений.
- Вы можете детализировать данные с помощью мониторинга нескольких измерений метрик.
- Вы можете использовать динамические пороговые значения, управляемые машинным обучением.
- You can configure if metric alerts are stateful or stateless. Metric alerts are stateful by default.
Целевым объектом правила генерации оповещений по метрикам может быть:
- Один ресурс, например виртуальная машина. Поддерживаемые типы ресурсов см. в разделе "Поддерживаемые ресурсы".
- Несколько ресурсов одного типа в одном регионе Azure, например группа ресурсов.
Applying multiple conditions to a metric alert rule
При создании правила генерации оповещений для отдельного ресурса вы можете применить несколько условий. Например, вы можете создать правило генерации оповещений для отслеживания виртуальной машины Azure и создания оповещения в том случае, когда выполняются условия "Процент ЦП превышает 90 %" и "Длина очереди превышает 300 элементов". When an alert rule has multiple conditions, the alert fires when all the conditions in the alert rule are true and is resolved when at least one of the conditions is no longer true for three consecutive checks.
Узкое определение цели с помощью параметров
Инструкции по использованию размерных параметров в правилах оповещения метрик см. в разделе «Мониторинг нескольких временных рядов в одном правиле оповещения метрик».
Мониторинг одного и того же условия для нескольких ресурсов с помощью разделения по измерениям
Чтобы отслеживать одно условие для нескольких ресурсов Azure, вы можете использовать разделение по измерениям. When you use splitting by dimensions, you can create resource-centric alerts at scale for a subscription or resource group. Оповещения разбиваются на отдельные оповещения путем группирования сочетаний. Разделение столбца идентификатора ресурса Azure делает указанный ресурс целевым объектом оповещения.
Вы также можете не делить, если вы хотите, чтобы условие применилось к нескольким ресурсам в пределах текущего контекста. Например, может потребоваться запустить оповещение, если в области группы ресурсов по крайней мере пять компьютеров имеют использование ЦП более 80 %.
Мониторинг нескольких ресурсов с помощью одного правила генерации оповещений
Вы можете обеспечить отслеживание в большом масштабе, применив одно правило генерации оповещений по метрике к нескольким ресурсам одного типа, которые существуют в одном регионе Azure. Для каждого отслеживаемого ресурса отправляются отдельные уведомления.
Метрики платформы для этих служб поддерживаются в следующих облаках Azure:
Сервис | Поставщик ресурсов | Глобальная среда Azure | Правительство | Китай |
---|---|---|---|---|
Виртуальные машины | "Microsoft.Compute/virtualMachines" | Да | Да | Да |
Базы данных SQL Server | "Microsoft.Sql/servers/databases" | Да | Да | Да |
Эластичные пулы SQL Server | "Microsoft.Sql/servers/elasticpools" | Да | Да | Да |
Пулы ёмкости файлов NetApp | "Microsoft.NetApp/netAppAccounts/capacityPools" | Да | Да | Да |
NetApp files volumes | "Microsoft.NetApp/netAppAccounts/емкостьPools/тома" | Да | Да | Да |
Azure Key Vault | "Microsoft.KeyVault/vaults" | Да | Да | Да |
Кэш Azure для Redis | "Microsoft.Cache/redis" | Да | Да | Да |
Устройства Azure Stack Edge | (Для этого ресурса нет определенного поставщика ресурсов. Из-за работы устройств Stack Edge метрики извлекаются из нескольких поставщиков ресурсов. Дополнительные сведения об оповещениях для этого ресурса см. в этой документации: просмотр оповещений в Azure Stack Edge) | Да | Да | Да |
Recovery Services vaults | "Microsoft.RecoveryServices/Vaults" | Да | Нет | Нет |
Гибкий сервер Базы данных Azure для PostgreSQL | Microsoft.DBforPostgreSQL/flexibleServers | Да | Да | Да |
Bare Metal Machines (Operator Nexus) | "Microsoft.NetworkCloud/bareMetalMachines" | Да | Да | Да |
Устройства хранения (оператор Nexus) | "Microsoft.NetworkCloud/storageAppliances" | Да | Да | Да |
Кластеры (Оператор Nexus) | "Microsoft.NetworkCloud/clusters" | Да | Да | Да |
Сетевые устройства (оператор Nexus) | Microsoft.NetworkCloud/l2Networks, Microsoft.NetworkCloud/l3Networks | Да | Да | Да |
Правила сбора данных | "Microsoft.Insights/datacollectionrules" | Да | Да | Да |
Примечание.
Оповещения по метрикам для нескольких ресурсов не поддерживаются для:
- Alerting on VM guest metrics.
- Оповещения по метрикам сети виртуальной машины (Всего входящего трафика, Всего исходящего трафика, Входящие потоки, Исходящие потоки, Максимальная скорость создания входящих потоков, и Максимальная скорость создания исходящих потоков).
Область мониторинга можно указать с помощью единого правила генерации оповещений по метрике одним из трех следующих способов. Например, с виртуальными машинами можно указать область следующим образом:
- Список виртуальных машин в одном регионе Azure в рамках подписки.
- Все ВМ в одном регионе Azure в одной или нескольких группах ресурсов в подписке.
- Все виртуальные машины в одном регионе Azure в одной подписке.
Применение расширенного машинного обучения с динамическими порогами
Динамические пороговые значения используют расширенное машинное обучение для:
- Узнайте об истории поведения метрик.
- Определите шаблоны и адаптируйтесь к изменениям метрик с течением времени, такими как почасовые, ежедневные или еженедельные шаблоны.
- Распознать аномалии, указывающие на возможные проблемы со службой.
- Вычислите наиболее подходящее пороговое значение для метрики.
Машинное обучение постоянно использует новые данные для получения дополнительных сведений и повышения точности порогового значения. Поскольку система адаптируется к поведению метрик с течением времени и создает оповещения на основе отклонений от их шаблона, вам не нужно знать правильный порог для каждой метрики.
Динамические пороги помогут вам делать следующее:
- Создавать масштабируемые оповещения для сотен серий метрик с одним правилом генерации оповещений. Чем меньше правил генерации оповещений, тем меньше времени вы тратите на их создание и управление ими.
- Создавайте правила без необходимости знать, какое пороговое значение необходимо настроить.
- Настройте оповещения метрик с помощью высокоуровневых концепций без обширных знаний о области метрик.
- Предотвратить использование шумных (низкая точность) или широких (низкая полнота) порогов, которые не имеют ожидаемого образца.
- Обрабатывать шумные метрики (например, использование ЦП или памяти компьютера) и метрики с низкой дисперсией (например, уровень доступности и количество ошибок).
См. динамические пороги для получения подробных инструкций по использованию динамических порогов в правилах оповещений метрик.
Log search alerts
Правило оповещения о поиске по журналам отслеживает ресурс с помощью запроса Log Analytics для оценки журналов ресурса с заданной частотой. If the conditions are met, an alert is fired. Так как вы можете использовать запросы Log Analytics, можно выполнять расширенные логические операции с данными и использовать функции KQL для обработки данных журналов.
Целью правила оповещения поиска в журнале может быть:
- Отдельный ресурс, например виртуальная машина.
- Один контейнер ресурсов, например группа ресурсов или подписка.
- Несколько ресурсов, которые используют запрос по нескольким ресурсам.
Оповещения поиска по журналам могут измерять два разных аспекта, которые можно применять для различных сценариев мониторинга.
- Строки таблицы: количество возвращаемых строк можно использовать для работы с такими событиями, как журналы событий Windows, системный журнал и исключения приложений.
- Вычисление числового столбца: вычисление на основе любого числового столбца, может использоваться для включения любого количества ресурсов. Примером является процент ЦП.
You can configure if log search alerts are stateful or stateless.
Stateful log search alerts have these limitations:
- They can trigger up to 300 alerts per evaluation.
- Вы можете иметь максимум 5 000 оповещений при условии
fired
.
Примечание.
Оповещения поиска по журналам лучше всего работают при попытке обнаружить определенные данные в журналах, а не при попытке обнаружить отсутствие данных в журналах. Because logs are semi-structured data, they're inherently more latent than metric data on information like a VM heartbeat. Чтобы избежать ошибок при попытке обнаружить отсутствие данных в журналах, рассмотрите возможность использования оповещений метрик. Данные можно отправлять в хранилище метрик из журналов с помощью оповещений метрик для журналов.
Мониторинг нескольких экземпляров ресурса с помощью измерений
Вы можете использовать измерения при создании правил оповещения поиска по журналам, чтобы отслеживать значения нескольких экземпляров ресурса с помощью одного правила. Например, вы можете отслеживать использование ЦП на нескольких экземплярах, на которых работает веб-сайт или приложение. Каждый экземпляр отслеживается индивидуально. Уведомления отправляются для каждого экземпляра.
Мониторинг одного и того же условия для нескольких ресурсов с помощью разделения по измерениям
Чтобы отслеживать одно условие для нескольких ресурсов Azure, вы можете использовать разделение по измерениям. При использовании разбиения по измерениям, вы можете создавать ресурсо-ориентированные предупреждения в большом масштабе для подписки или группы ресурсов. Оповещения разделены на отдельные оповещения путем группировки сочетаний с помощью числовых или строковых столбцов. Разделение по столбцу идентификатора ресурса Azure делает из указанного ресурса целевой объект оповещения.
Вы также можете не делить, если вы хотите, чтобы условие применилось к нескольким ресурсам в пределах текущего контекста. Например, может потребоваться запустить оповещение, если в области группы ресурсов по крайней мере пять компьютеров имеют использование ЦП более 80 %.
Используйте API для правил оповещений поиска по логам
Управляйте новыми правилами в рабочих областях с помощью API ScheduledQueryRules.
Примечание.
Оповещения поиска журналов для Log Analytics раньше управлялись с помощью устаревшего API оповещений Log Analytics. Узнайте больше о переключении на текущий API ScheduledQueryRules.
Log search alerts on your Azure bill
Log search alerts are listed under resource provider microsoft.insights/scheduledqueryrules
with:
- Log search alerts on Application Insights are shown with the exact resource name along with resource group and alert properties.
- Оповещения поиска по журналам в Log Analytics отображаются с точным именем ресурса вместе с ресурсной группой и свойствами оповещения, когда они создаются с помощью API scheduledQueryRules.
- Log search alerts created from the legacy Log Analytics API aren't tracked Azure resources and don't have enforced unique resource names. Эти оповещения по-прежнему создаются в виде скрытых ресурсов на
microsoft.insights/scheduledqueryrules
, которые имеют структуру именования ресурсов<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>
. Оповещения поиска по журналам в устаревшем API отображаются с указанным выше скрытым именем ресурса, а также свойствами группы ресурсов и оповещений.
Примечание.
Неподдерживаемые символы ресурсов, такие как <, >%, &, ? и /заменяются символом подчеркивания (_) в скрытых именах ресурсов. Это изменение символа также отражается в сведениях о выставлении счетов.
Оповещения журнала активности
Оповещение журнала действий отслеживает ресурс, проверяя журналы действий на наличие нового события журнала действий, соответствующего определенным условиям.
Для таких типов сценариев может потребоваться использовать оповещения журнала действий:
- При выполнении определенной операции с ресурсами в определенной группе ресурсов или подписке. Например, вам может потребоваться получать уведомления, когда:
- A VM in a production resource group is deleted.
- Новые роли назначаются пользователю в подписке.
- A Service Health event occurs. Service Health events include notifications of incidents and maintenance events that apply to resources in your subscription.
You can create an activity log alert on:
- Any of the activity log event categories, other than on alert events.
- Любое событие журнала действий в свойстве верхнего уровня в объекте JSON.
Правила генерации оповещений журнала действий являются ресурсами Azure, поэтому их можно создать с помощью шаблона Azure Resource Manager. Их также можно создать, обновить или удалить на портале Azure.
Оповещение журнала действий отслеживает события только в той подписке, в которой создается оповещение.
Service Health alerts
Service Health alerts are a type of activity alert. Состояние службы позволяет узнать о сбоях, запланированных мероприятиях по обслуживанию и других уведомлениях о состоянии, так как аутентифицированный интерфейс состояния службы знает, какие службы и ресурсы вы используете в настоящее время.
Лучший способ использовать работоспособность службы — настроить оповещения о работоспособности служб, чтобы уведомить вас с помощью предпочитаемых каналов связи при проблемах службы, плановом обслуживании или других изменениях, которые могут повлиять на используемые службы и регионы Azure.
Оповещения о состоянии ресурсов
Оповещения о состоянии ресурсов — это тип оповещения о действиях. Обзор Работоспособность ресурсов помогает диагностировать и получать поддержку проблем службы, влияющих на ресурсы Azure. Сообщается о текущем состоянии и прошлом состоянии здоровья ваших ресурсов.
Для оценки состояния ресурса в службе "Работоспособность ресурсов" используются сигналы от различных служб Azure. Если ресурс имеет проблемы, служба Resource Health анализирует дополнительную информацию для определения источника проблемы. Он также сообщает о действиях, которые корпорация Майкрософт принимает для устранения проблемы и определяет действия, которые можно предпринять для решения этой проблемы.
Оповещения интеллектуального обнаружения
После настройки Application Insights для вашего проекта и генерации вашим приложением определенного объема данных интеллектуальному обнаружению требуется 24 часа, чтобы изучить нормальное поведение вашего приложения. Производительность вашего приложения демонстрирует типичный шаблон поведения. Некоторые запросы или вызовы зависимостей более подвержены сбоям, чем другие, и общая частота сбоев может увеличиться по мере увеличения нагрузки.
Интеллектуальное обнаружение использует машинное обучение для поиска этих аномалий. Интеллектуальное обнаружение отслеживает данные, полученные от приложения, и, в частности, частоту сбоев. Application Insights автоматически уведомляет вас (почти в реальном времени), если работа веб-приложения сопровождается чрезмерно частыми неудачными запросами.
По мере того как данные входят в Application Insights из веб-приложения, интеллектуальное обнаружение сравнивает текущее поведение с шаблонами, наблюдаемыми за последние несколько дней. Если по сравнению с предыдущими показателями производительности наблюдается чрезмерное увеличение частоты отказов, запускается анализ.
Чтобы помочь вам проанализировать и диагностировать проблему, в подробных сведениях о оповещении представлен анализ характеристик сбоев и связанных данных приложения. Кроме того, даются ссылки на портал Application Insights для дальнейшей диагностики. Эта функция не нуждается в настройке или настройке, так как она использует алгоритмы машинного обучения для прогнозирования нормальной частоты сбоев.
Although metric alerts tell you there might be a problem, smart detection starts the diagnostic work for you. Он выполняет большую часть анализа, который вы иначе должны сделать самостоятельно. Вы получите результаты аккуратно упаковано, что помогает быстро добраться до корня проблемы.
Интеллектуальное обнаружение работает для веб-приложений, размещенных в облаке или на ваших собственных серверах, которые создают запросы к приложению или данные о зависимостях.
оповещения Prometheus
Оповещения Prometheus используются для мониторинга метрик, хранящихся в управляемых службах Azure Monitor для Prometheus. Правила оповещений Prometheus настраиваются как часть групп правил Prometheus. Они запускаются, когда результат выражения PromQL принимает значение true. Fired Prometheus alerts are displayed and managed like other alert types.
Следующие шаги
- Ознакомьтесь с обзором оповещений.
- Создание правила генерации оповещений.
- Дополнительные сведения об интеллектуальном обнаружении.