Алерт

Алерт — проверка, которая раз в минуту определяет статус по заданным условиям. Для каждого статуса задаются условия: когда они выполняются, алерт переходит в этот статус. В зависимости от типа алерта условия применяются к результатам запросов, показателям SLO или статусам других алертов.

Уведомления о смене статуса отправляются через настроенные каналы.

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

В один обычный алерт или подалерт можно загрузить не более 1 000 метрик. Если метрик больше:

• Создайте мультиалерт, чтобы распределить метрики по подалертам.
• Агрегируйте метрики в приложении перед отправкой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно:

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

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

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

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

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

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

Например, чтобы следить за последним значением метрики, которое было в течение последних 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, чтобы обнаружить ошибку селектора или сбой сбора метрик.

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

• 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. Собственные запросы к метрикам в нем не задаются. Проект SLO может отличаться от проекта алерта. Разложение SLO-алерта по меткам не поддерживается.

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

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

Для статусов Warning и Alarm настраиваются отдельные пороги. Необходимо задать хотя бы один из них. Если заданы оба, значение порога Alarm должно быть меньше значения порога Warning при проверке остатка бюджета и больше — при проверке расхода или Burn Rate.

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

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

Остаток и расход Error BudgetОстаток и расход Error Budget

Для типа Error Budget доступны два метода расчета: Остаток Error Budget и Скорость расхода Error Budget. Пороги обоих методов задаются в процентах бюджета ошибок.

Метод Остаток Error Budget сравнивает средний остаток бюджета за окно вычисления алерта с порогами. Чем меньше остаток, тем выше риск нарушения SLO. Например, при порогах Warning = 20% и Alarm = 10% алерт перейдет в Warning, если средний остаток снизится ниже 20%, и в Alarm — если ниже 10%. Если SLO уже нарушен, остаток бюджета может быть отрицательным.

Метод Скорость расхода Error Budget сравнивает с порогами фактический расход: из остатка бюджета в начале окна вычитается остаток в конце. Например, при окне 1h и пороге Alarm = 5% алерт перейдет в Alarm, если за час израсходовано больше 5% бюджета. Этот метод устойчив к проблеме низкого трафика, поскольку отслеживает фактически израсходованный бюджет.

Burn RateBurn Rate

Burn Rate — коэффициент скорости расхода бюджета ошибок. Он равен отношению доли плохих событий к допустимой доле ошибок:

Burn Rate = (Bad Events / Total Events) / (1 - SLO)

В этой формуле SLO задается долей от нуля до единицы. Например, для SLO 99,9% используется значение 0,999. Коэффициент 1 означает, что доля ошибок равна допустимой, а 2 — что она вдвое выше.

Для работы алерта в исходном SLO должен быть включен расчет Burn Rate. Иначе метрики burn_rate не публикуются и алерт переходит в статус No data. Алерт сравнивает готовые коэффициенты с порогами.

Окна проверкиОкна проверки

Алерт использует длинное и короткое окна. Длинное окно выбирается в настройках алерта, короткое составляет 1/12 длинного. Например, для длинного окна 1h короткое равно 5m.

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

Способы задания пороговСпособы задания порогов

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

Доля израсходованного бюджета = Burn Rate × окно алерта / окно SLO

Оба окна должны быть выражены в одинаковых единицах времени. Например, окно SLO в 30 дней равно 720 часам. Для такого SLO коэффициент 14,4 на окне 1h соответствует доле 14,4 × 1 / 720 = 0,02, то есть расходу 2% бюджета. Коэффициент 6 на окне 6h соответствует расходу 5% бюджета.

При низком трафике Burn Rate может вырасти даже при неизменном количестве ошибок: доля ошибок увеличивается из-за уменьшения общего числа событий. Для снижения шума можно поддерживать фоновую нагрузку синтетическими проверками. Если нужно контролировать уже израсходованный бюджет, используйте метод Скорость расхода Error Budget.

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

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

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

Чтобы создать мультиалерт, укажите в параметре Разложение по меткам одну или несколько меток. Для каждого уникального значения метки или комбинации значений нескольких меток 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. В результате для каждой уникальной комбинации типа и идентификатора ресурса будет создан отдельный подалерт.

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

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

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