Yandex Cloud
Поиск
Связаться с экспертомПопробовать бесплатно
  • Кейсы
  • Документация
  • Блог
  • Все сервисы
    • Cloud Interconnect
    • Cloud Backup
    • Cloud Registry
    • Yandex AI Studio
    • Compute Cloud
    • Object Storage
    • Managed Service for Kubernetes®
    • Yandex BareMetal
    • Smart Web Security
    • Security Deck
    • Managed Service for PostgreSQL
    • Managed Service for ClickHouse®
    • Monium
    • Cloud CDN
    • Network Load Balancer
    • Virtual Private Cloud
    • Cloud DNS
    • Application Load Balancer
    • Yandex Cloud Video
    • Stackland
    • Yandex Cloud Router
    • Yandex Managed Service for Trino
    • Managed Service for MySQL®
    • Managed Service for Valkey™
    • Managed Service for Apache Spark™
    • Yandex StoreDoc
    • Managed Service for OpenSearch
    • Managed Service for Apache Kafka®
    • Data Transfer
    • Yandex MPP Analytics Engine for PostgreSQL
    • Yandex Managed Service for Apache Airflow®
    • Data Processing
    • Yandex MetaData Hub
    • Managed Service for YDB
    • Managed Service for Sharded PostgreSQL
    • Managed Service for YTsaurus
    • Yandex WebSQL
    • DataLens
    • Yandex Search API
    • SpeechSense
    • SpeechKit
    • DataSphere
    • Vision OCR
    • Translate
    • Yandex Neurosupport
    • VibeCraft
    • Yandex Cloud Detection and Response
    • Yandex Identity Hub
    • Key Management Service
    • Certificate Manager
    • Yandex Lockbox
    • Audit Trails
    • SmartCaptcha
    • Cloud Desktop
    • GOST Gateway
    • Yandex SIEM
    • SourceCraft Code Assistant
    • Container Registry
    • Managed Service for GitLab
    • SourceCraft
    • Managed Service for Prometheus®
    • Cloud Functions
    • API Gateway
    • Yandex Cloud Postbox
    • Message Queue
    • Serverless Integrations
    • IoT Core
    • Data Streams
    • Serverless Containers
    • Cloud Notification Service
    • Yandex Query
    • Identity and Access Management
    • Yandex Cloud Console
    • Resource Manager
    • Yandex Cloud Billing
    • Yandex Cloud Quota Manager
    • Cloud Apps
  • Статус работы сервисов
  • Marketplace
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Искусственный интеллект
    • Безопасность
    • Инструменты DevOps
    • Бессерверные вычисления
    • Управление ресурсами
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Yandex Cloud Trust
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Калькулятор цен
    • Тарифы
    • Акции и free tier
  • Кейсы
  • Документация
  • Блог
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ООО «Яндекс.Облако»
Monium
  • Начало работы
  • Обзор
      • Обзор
      • Алерт
      • Аннотация
      • Канал уведомлений
      • Эскалации
    • Мьюты
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • История изменений
  • Обучающие курсы

В этой статье:

  • Статусы алертов
  • История вычислений алерта
  • Настройки алерта
  • Уровень алерта
  • Запросы
  • Условия срабатывания
  • Прореживание данных
  • Обработка отсутствия данных
  • Отсутствие метрик по селектору
  • Отсутствие точек в окне вычисления
  • Ручная обработка отсутствия данных
  • Уведомления
  • Подавление шума
  • Композитные алерты
  • SLO-алерты
  • Мультиалерты
  • Создание мультиалерта
  • Подалерты
  • Пример мультиалерта
  • Просмотр мультиалерта
  1. Алерты
  2. Концепции
  3. Алерт

Алерт

Статья создана
Yandex Cloud
Обновлена 23 сентября 2026 г.
Открыть в Markdown
  • Статусы алертов
  • История вычислений алерта
  • Настройки алерта
    • Уровень алерта
    • Запросы
    • Условия срабатывания
    • Прореживание данных
  • Обработка отсутствия данных
    • Отсутствие метрик по селектору
    • Отсутствие точек в окне вычисления
    • Ручная обработка отсутствия данных
  • Уведомления
    • Подавление шума
  • Композитные алерты
  • SLO-алерты
  • Мультиалерты
    • Создание мультиалерта
    • Подалерты
    • Пример мультиалерта
    • Просмотр мультиалерта

Алерт — набор последовательных именованных запросов, которые вычисляются один раз в минуту. Полученное значение запроса сравнивается с заданными пороговыми значениями. Если порог достигнут, Monium переводит алерт в статус Alarm или Warning и оповещает пользователя по каналу уведомления.

Мультиалерт — алерт, который создает отдельный подалерт для каждой уникальной комбинации значений выбранных меток метрик. Например, если метрика имеет метку host с тремя значениями (host1, host2, host3), мультиалерт создаст три независимых подалерта — по одному для каждого хоста. Это позволяет отслеживать состояние метрик на разных ресурсах с помощью одного алерта.

Статусы алертовСтатусы алертов

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

Цвет Статус Описание
🟢 OK Значение метрики в пределах установленной нормы.
🟡 Warning Значение метрики достигло порога предупреждения Warning.
🔴 Alarm Значение метрики достигло порога критического статуса Alarm.
🔵 No data Для вычисления функции алерта не хватает данных метрик.
⚪️ Error Значение алерта вычислить невозможно.

Цветовое обозначение алерта передается при уведомлении через Telegram.

История вычислений алертаИстория вычислений алерта

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

Для навигации по истории можно выбрать один из предустановленных масштабов отображения:

  • 1h — 1 час.
  • 1d — 1 день.
  • 1w — 1 неделя.
  • 1m — 1 месяц.

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

При нажатии на столбец загружается информация о настройках алерта в выбранный момент вычисления.

Примечание

При загрузке информации из истории вычисления производится повторный расчет статуса алерта, который отображается в поле Статус вычисления алерта. Статус алерта в истории может не совпадать с текущим результатом вычисления из-за особенностей прореживания исторических данных или задержек при поставке данных в Monium Metrics.

Настройки алертаНастройки алерта

Уровень алертаУровень алерта

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

Доступные уровни:

  • Unspecified — критичность не задана. Например, тестовый алерт без выбранного уровня.
  • Disaster — критический инцидент. Например, сервис недоступен, база не принимает записи, есть риск потери данных.
  • Critical — серьезная проблема. Например, растет задержка API, заканчивается место на диске, недоступна часть инстансов.
  • Info — информационное событие. Например, завершилась плановая операция или сработал тестовый алерт. Значение по умолчанию.

ЗапросыЗапросы

Набор запросов, которые возвращают линию или набор линий.

Можно:

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

Условия срабатыванияУсловия срабатывания

Запрос для проверкиЗапрос для проверки

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

Функция агрегацииФункция агрегации

Функция агрегации применяется к результату вычисления запроса для проверки. Она определяет, какое значение будет сравниваться с порогами Warning и Alarm.

Функция агрегации Описание
Хотя бы одно значение Проверяет, что хотя бы одно значение в окне вычисления достигло порога. Подходит для коротких, но критичных всплесков, например ошибок 5xx или резкого роста задержки API.
Все значения Проверяет, что все значения в окне вычисления достигли порога. Помогает реагировать только на устойчивую проблему, например постоянную высокую загрузку CPU.
Среднее Вычисляет среднее значение в указанном периоде для каждой метрики. Используйте функцию для сглаженных показателей, например средней задержки ответа или средней утилизации CPU.
Количество Вычисляет количество значений метрики в указанном периоде. Функция полезна, когда важен сам факт поступления точек, например количество ошибок или событий за окно.
Последнее значение Использует последнее значение метрики в указанном периоде. Подходит для метрик состояния, например доступности инстанса или результата health check.
Максимум Использует максимальное значение метрики в указанном периоде. Помогает обнаружить пиковые значения, например максимальную задержку запроса или заполнение диска.
Минимум Использует минимальное значение метрики в указанном периоде. Подходит для метрик свободного ресурса, например свободного места на диске или числа доступных реплик.
Сумма Вычисляет сумму значений за указанный период для каждой метрики. Используйте функцию для счетчиков событий, например числа ошибок или перезапусков контейнера.

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

Функция сравненияФункция сравнения

Функция сравнения применяется к результату вычисления функции агрегации и пороговым значениям Warning и Alarm. Если агрегированное значение удовлетворяет заданному условию сравнения, Monium Metrics изменяет статус алерта.

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

WarningWarning

Пороговое значение, при достижении которого алерт перейдет в статус Warning.

AlarmAlarm

Пороговое значение, при достижении которого алерт перейдет в статус Alarm.

Окно вычисленияОкно вычисления

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

При коротком окне алерт быстрее обнаруживает проблему, но чаще реагирует на случайные пики. Длинное окно снижает шум, но увеличивает время реакции. Например, окно 1m подходит для проверки доступности API, а окно 15m — для устойчивого роста задержки или заполнения диска.

Можно выбрать одно из предустановленных значений или задать свое в следующем формате:

  • 1h — 1 час.
  • 1m — 1 минута.
  • 1s — 1 секунда.

Например, значение 3m 45s задает временное окно в 3 минуты 45 секунд.

Задержка вычисленияЗадержка вычисления

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

Задержка полезна для агрегированных метрик, которые поступают позже исходных событий. Например, если приложение отправляет метрики раз в минуту, а агент доставляет их с задержкой до 30 секунд, задайте задержку 30s или больше. Так алерт будет проверять уже заполненное окно, а не последние неполные данные.

Прореживание данныхПрореживание данных

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

Функцию прореживания выбирают по типу метрики:

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

Если алерт должен реагировать на короткий всплеск, не используйте прореживание с усреднением: оно может скрыть пик. Для p95 или p99 задержки чаще выбирают максимум, чтобы сохранить худшие значения. Для счетчиков ошибок выбирают сумму, чтобы не потерять общий объем событий.

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

Обработка отсутствия данныхОбработка отсутствия данных

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

Параметр Применение политик задает, когда использовать выбранные политики:

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

Примечание

Точка данных — значение метрики, собранное на определенном временном периоде. Отсутствие точек данных означает, что в заданном окне вычисления не было собрано ни одного значения метрики, отсутствуют данные для анализа и отображения.

Доступные варианты политик:

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

  • Ok, Warn, Alarm, No data — если в окне вычисления отсутствуют данные хотя бы у одной метрики из запроса, каждая из этих политик автоматически переводит алерт в соответствующий статус. Исторические данные не учитываются. При отсутствии данных в окне вычисления график перестанет отображаться.

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

Вы можете обработать отсутствие метрик или точек во временном окне двумя способами:

  • Сменить статус алерта с помощью политик Отсутствие метрик по селектору или Отсутствие точек в окне вычисления.
  • Обработать вручную.

Примечание

Чтобы алерты переходили в статус No data при отсутствии метрик или точек во временном окне, выставите для всех типов алертов значение политик No data. Использование Default и Manual не рекомендуется, так как это требует дополнительной ручной обработки.

Отсутствие метрик по селекторуОтсутствие метрик по селектору

Политика определяет статус алерта, если хотя бы по одному селектору не было найдено метрик. Например, метрик не существует или они были удалены как устаревшие — TTL.

Такая ситуация отличается от отсутствия точек. Селектор не находит ни одной метрики, если ресурс удалили, изменили лейбл или приложение перестало отправлять метрику. Для важных ресурсов выбирайте No data, чтобы быстро обнаружить ошибку селектора или сбой сбора метрик.

Возможные значения:

  • Default — значение по умолчанию No data для всех типов алертов.
  • Ok — переводит алерт в статус OK.
  • Warn — переводит алерт в статус Warning.
  • Alarm — переводит алерт в статус Alarm.
  • No data — переводит алерт в статус No data.

Отсутствие точек в окне вычисленияОтсутствие точек в окне вычисления

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

Метрика при этом существует, но за выбранное окно не получила новых значений. Причиной может быть задержка агента, редкая отправка метрик, простой приложения или сетевой сбой. Если метрика поступает раз в пять минут, не задавайте окно 1m: алерт будет часто переходить в статус No data.

Для пороговых алертов, настроенных на несколько метрик, предикаты выполняются независимо для каждой метрики. Итоговый статус алерта — агрегация статусов для каждой из метрик в следующем порядке: No data < OK < Warning < Error < Alarm. Если политика Отсутствие точек в окне вычисления переведет такой пороговый алерт, например, в статус Warning из-за отсутствия точек в одной линии, а для другой линии выполнится предикат, переводящий алерт в статус Alarm, то итоговый статус алерта будет Alarm.

Возможные значения:

  • Default — значение по умолчанию No data для всех типов пороговых алертов.
  • Ok — переводит алерт в статус OK.
  • Warn — переводит алерт в статус Warning.
  • Alarm — переводит алерт в статус Alarm.
  • No data — переводит алерт в статус No data.
  • [object Object] — передает управление предикатам или программе алерта для обработки вручную.

Ручная обработка отсутствия данныхРучная обработка отсутствия данных

Если для любой политики указано значение Manual, управление будет передано предикатам алерта или программе.

Не рекомендуется использовать значение Manual — это усложняет программу алерта. В большинстве случаев достаточно воспользоваться значением политики No data.

УведомленияУведомления

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

Подавление шумаПодавление шума

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

Настройка полезна для метрик, которые быстро колеблются около порога. Например, алерт на задержку API может несколько раз перейти из OK в Warning и обратно во время краткого всплеска нагрузки. Без подавления шума дежурный получит несколько уведомлений, с подавлением — одно сообщение после стабилизации статуса.

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

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

Композитные алертыКомпозитные алерты

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

Композитный алерт находит исходные алерты по селектору и применяет к ним выбранную стратегию композиции:

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

Для статусов Warning и Alarm настраиваются отдельные пороги и наборы исходных статусов. Тип порога зависит от стратегии композиции: для стратегии По доле указывается процент, для стратегии По количеству — целое число.

Например, выбрана стратегия По доле, порог Alarm равен 10%, а в вычислении участвуют статусы Warning и Alarm. В этом случае композитный алерт перейдет в статус Alarm, когда не менее 10% найденных по селектору алертов будут находиться в одном из этих статусов.

Дополнительные настройки композитного алерта:

  • Форсировать статус композита в No Data — переводит композитный алерт в статус No data, если хотя бы один исходный алерт находится в этом статусе;
  • Форсировать статус композита в Error — переводит композитный алерт в статус Error, если хотя бы один исходный алерт находится в этом статусе;
  • Приравнивать замьюченные алерты к статусу Ok — учитывает исходные алерты под действием мьюта как алерты в статусе Ok.

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

SLO-алертыSLO-алерты

SLO-алерт — алерт, который отслеживает Error Budget выбранного SLO. Он помогает реагировать не только на отдельные сбои, но и на риск нарушения целевого уровня надежности сервиса.

SLO-алерт использует вычисленные показатели SLO: значение SLI, целевой SLO и остаток Error Budget. Такой алерт полезен, когда нужно контролировать качество пользовательского сценария за период, а не отдельную техническую метрику.

Доступны два типа SLO-алертов:

  • Error Budget — срабатывает, когда остаток Error Budget становится ниже заданного порога. Используйте его, чтобы заранее увидеть риск исчерпания бюджета ошибок.
  • Burn Rate — срабатывает, когда скорость расходования Error Budget за выбранное окно вычисления превышает заданный порог. Используйте его для обнаружения инцидентов, которые быстро ухудшают SLO.

Для статусов Warning и Alarm настраиваются отдельные пороги. Обычно Warning используют для раннего предупреждения, а Alarm — для ситуаций, которые требуют реакции дежурного.

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

Чтобы создать SLO-алерт, следуйте инструкции Создание SLO-алерта.

МультиалертыМультиалерты

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

Создание мультиалертаСоздание мультиалерта

Чтобы создать мультиалерт, укажите в параметре Разложение по меткам одну или несколько меток. Для каждого уникального значения метки или комбинации значений нескольких меток Monium автоматически создаст отдельный подалерт.

Примеры разложения:

  • Если указать метку host, создастся подалерт для каждого хоста.
  • Если указать метку disk, создастся подалерт для каждого диска.
  • Если указать метки host и disk, создастся подалерт для каждой комбинации хоста и диска.

Выбирайте метки, по которым нужна отдельная диагностика или реакция. Например, метка disk помогает получить отдельное срабатывание по заполненному диску, а метка zone — увидеть проблему в конкретной зоне доступности.

Не используйте метки с большим числом уникальных значений, например request_id, trace_id, user_id или динамические идентификаторы контейнеров. Они могут создать много подалертов, усложнить разбор инцидента и увеличить потребление квот на алерты.

ПодалертыПодалерты

Подалерт — автоматически создаваемый алерт, который нельзя редактировать вручную. Его параметры определяются родительским мультиалертом. Каждый подалерт:

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

У подалерта собственный статус и история вычислений. Это помогает быстро найти проблемную сущность: конкретный хост, диск, зону доступности или шард. Если проблема затрагивает только один диск, в статус Alarm перейдет подалерт этого диска, а не все проверки мультиалерта.

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

Пример мультиалертаПример мультиалерта

Чтобы создать мультиалерт для мониторинга использования CPU на ресурсах сервиса Compute Cloud, используйте следующий селектор:

{project = "<project_id>", service = "__compute__", cluster = "default", name = "cpu_usage", resource_id = "*", resource_type = "*"}

Укажите в параметре Разложение по меткам метки resource_id и resource_type. В результате для каждой уникальной комбинации типа и идентификатора ресурса будет создан отдельный подалерт.

Просмотр мультиалертаПросмотр мультиалерта

На странице мультиалерта:

  • В блоке История вычисления алерта отображается сводная информация о количестве подалертов в каждом статусе.
  • В блоке Подалерты показан список подалертов с возможностью фильтрации по значениям меток и статусу.

Была ли статья полезна?

Предыдущая
Обзор
Следующая
Аннотация
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ООО «Яндекс.Облако»