Мониторы и оповещения

Понятия и названия в АМ

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

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

Алертинг

alert

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

  • алертинг - это процесс отправки оповещений через email, мессенджеры, sms и голосовые сервисы. Принято и устоялось с давних времён от Prometheus Alertmanager.

  • алерт - это подсвеченная строка в интерфейсе пользователя системы мониторинга, которая, когда её увидят, заставляет тревожиться дежурных

  • alert - это более высокий уровень критичности по сравнению с Warning, иногда используется как синоним Critical

Из-за такой размытости понимания алерта, мы стараемся вообще его не использовать, но иногда он всё же может встречаться в значении Critical.

Оповещения уведомления сообщения

notifications

Это, как сказано выше, оповещения через email, мессенджеры, sms и голосовые сервисы. Оба названия мы используем взаимозаменяемо. Сообщение - это то, что приходит в оповещении.

Состояние критичность статус

severity/state vs status

С ними, как и с алертингом, тоже много путаницы. Мы приняли такое разделение:

  • состояние (state) = критичность может ещё называться Severity

  • статус (status) = актуальность Что это либо активно и в работе или отправлено в архив и уже никак не будет изменяется, так сказать дело былых времён.

В АМ всего три или четыре, в зависимости от режима No data, состояния/критичности Critical, Warning, OK и No data. Для проблем только так - всего четыре цвета, однако для событий, которые не имеют состояния, сделано исключение. У них есть ещё циановоый цвет INFO. Статус же в первую очередь относится к проблемам и имеет всего два значения Активна и Закрыта.

Важно

No data в парадигме АМ - это полноценная отдельная критичность наравне с Warn, Crit и OK и все срабатывания в неё подчиняются тем же основным правилам. Нужно только помнить, что в режимах Show last known и Show OK для монитора этой критичности как и состояния просто не предусмотрено. Никогда не будет серго цвета в полосах диаграммы групп, как и такой критичности у проблем - они никогда не бывают серыми в вышеназванных режимах.

Событие

event

В нашем понимании событие:

  • не изменяемая впоследствии журнальная запись, это констатация случая

  • производится по факту перехода объекта наблюдения монитора в другое состояние

  • принципиально не содержит информации откуда происходит переход

  • содержит префикс, который с критичностью имеет совпадение только в двух вариантах Warning и No data, а в оставшихся двух имеет свои собственные соответствующие категории - Triggered (Critical), Recovered (OK)

Примечание

Почему не сделали одинаковые названия и для критичностей и для префиксов событий? Тут нет строгого обоснования, просто мы посчитали логичным их разделить. Ведь критичность это пребывание в состоянии, а событие, даже с его характеристикой серьёзности и цветом, это всё таки не состояние, а как бы свойство случая. Поэтому для проблем критичность звучит как «Хорошее состояние», «Предупреждающее состояние», «Критичное состояние», «Состояние нет данных». А для событий - как:

  • Triggered - сработало/перешло в critical (в alert)

  • Warn - сработало/перешло в warning

  • No data - сработало/перешло в состояние No data

  • Recovered - восстановилось в OK.

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

Проблема

problem

По факту любого срабатывания монитора из состояния OK делается запись события в журнал и тут же создаётся проблема. Объект внутри монитора может затем переключаться между не ОК состояниями и синхронно будет меняться критичность проблемы. Таким образом проблема является индикатором текущего состояния, к ней привязан список событий в журнале. В концепции АМ проблема похожа на упрощённый аналог инцидента в ITSM системах. Её cмогут подтверждать acknowledge, брать в собственность own, назначать пользователям и группам assign, добавлять к ней комментарии и многое другое. Проблема в течение жизни меняется и обрастает данными, а событие нет. Поэтому проблемы живут в RDBS PostgreSQL, а события в колоночной базе данных ClickHouse. Как только объект восстанавливается в OK, проблема не зеленеет, она остаётся в последней прижизненной её критичности и ей выставляется флаг закрыта. Как уже было сказано, после этого проблему изменять нельзя, но использовать для отчётов и в аналитике сколько угодно.  Помните! Не бывает зелёных проблем, потому что, если стало ОК то проблемы больше нет. Закрытые не удаляются из базы, но легко убираются с глаз долой из интерфейса дежурной смены SHFT-DUTY, ведь у них на виду должны быть проблемы предполагающие активные по ним действия actionable.

Группа монитора vs Объект мониторинга

При настройке механизмов сбора данных мониторинга мы неизбежно имеем дело с физическими объектами на которых расположены агенты. Но мы не хотим использовать понятие объекта мониторинга в рассказе про мониторы. Звучит странно, но, если называть вещи своими именами и исходить из того, как это работает, для монитора не существует никаких объектов. Он работает с числами, которые получает в ответ на запрос к базе с данными мониторинга. Само выражение query полностью определяет, что монитор получит в ответ, но это всегда набор лейблов и число. Выражение запрос должно иметь тип Instant vector, то есть выдавать «одну строчку» с числом для каждой уникальной комбинации лейблов. Запросы Range типа используется для графиков, они здесь не годятся. Имея перед глазами лейблы с их значениями в ответе на наше выражение, мы должны принять важное решение, какой из этих лейблов или какую комбинацию лейблов взять за шаблон будущего имени группы. Почему группы? Потому что если внутри выбранного нами для имени уникального сочетания лейблов окажется несколько строк, то все они будут обязательно сгруппированы и все «конфликтующие лейблы» естественно будут отброшены. Подробное описание принципа работы группировки в АМ ждёт нас дальше, но сейчас нужно только согласиться, что в глазах монитора объектом мониторинга будет никакой не объект, а уникальное сочетание лейблов определённых значений. Само это сочетание это не группа, а группа это всё то, что было усреднено под ним. В динамическом режиме, из возвращаемых разных данных монитор создаёт группы и в дальнейшем контролирует их здоровье, сравнивая с установленными порогами, удаляет по истечении заданного времени при отсутствии данных от них. Принятие названия группа за объект мониторинга позволит легко понять принцип действия группировки оповещений. Подводя итог, мы видим только временные ряды и на их основе динамически создаём сущности мониторинга и лучшего и более точно передающего смысл названия кроме как группа монитора придумать не получается.  Говорим группа, понимаем что это нечто, что монитор различает и знает по имени.

Язык запросов

PromQL и MetricsQL

Язык имени монитора и его описания

Для задания имени монитора и описания используется стандартный шаблонизатор go для HTML кода - https://pkg.go.dev/html/template