Комментарии 18
А как формулируется цель этой действительно нетривиальной работы? И есть какие-то способы, быстро и точно понять, что всё опять не "сползает в бездну"? Может, метрики, аналитика, дашборды. Как они помогают понять, что сформулированная цель всё ещё достигается?
Если можно, раскройте на какие индикаторы смотрите: количество false positives/negatives, удовлетворённость дежурных своим сном, что-то посложнее: свойства "трассировок" эскалаций, оценки правильности агрегаций алертов, считающихся связанными и т. п.?
тоже было бы интересно узнать как ведется мониторинг в целях "неразрастания" для таких объемов
у нас для неразрастания (хотя конкретно такой цели не ставилось, это была обычная работа над продом)
для новых алертов должно было быть объяснено и записано: почему это надо алертить и кто ответственный за конкретно этот момент. Если никто не берет ответственность (даже если реакция первая должна быть от дежурного - дежурный не эксперт, эксперт - владелец сервиса) то на гильдиях (платформа для инфраструктурных сервисов, дев для сервисов приложения) ищем кто заберет себе. Тот же процесс для легаси алертов, созданных в до введения данного правила: оценка, описание, поиск владельца
для существующих критов и ворнингов - статистика и еженедельная презентация на RnD(все команды продукта), с объяснением что происходило в продукте и какие критические алерты сработали в областях (если что-то было). Отчеты по инцидентам опять же там же
Увеличение количества ворнингов в конкретной области - требовало расследования от команды и тюнинга либо алерта либо починки сервиса. Ибо вроде мелочь, но может привести к неприятным последствиям
Криты - отражение состояния продукта, если в сервисе много критов но с сервисом все хорошо - значит что-то не так с алертом, тоже править или уровень срабатывания или вообще приоритет
Большое колиство инцидентов или валидных критов в конкретной области - сигнал что что-то не так в принципе и надо менять приоритеты команды ответственной за область\сервис на исправление данной ситуации
Спасибо вообще тем командам(а так же менеджерам): брали в относительно ближайшие спринты всё это править )
Вообще, получалось держать руку на пульсе, но у нас не было "N тысяч алертов в секунду" - поэтому интересно. Вообще, тысячи алертов в секунду это больно - никто на такое не отреагирует физически. Старались заводить только алерты на которые надо реагировать и воспринимать остальное как информационный шум. Интересный, но все таки шум
Grafana Oncall облачная?
Берём список лучших алертов из open-source решений
Поделитесь пожалуйста :)
https://samber.github.io/awesome-prometheus-alerts/ можно начинать отсюда, адаптируя под свои нужды. Также много есть просто поиском на github. Флоу простой: смотрите какие метрики экспортер отдает и ищите в github примеры алертов
Наверное, погорячился
Grafana OnCall потеряет какую либо поддержку в начале 2026 года. Вы уже планируете ей замену и если да, то на что?
Возможно, это не тема данной статьи, но, кажется, нужно было раскрыть тему и про этапы калибровки алертов и тестирования. Это всё важные этапы спокойствия дежурных на oncall
Использовали такие приоритеты:
Incident - инцидент =), сразу запускается процесс обработки инцидента в продукте (не такой продвинутый, как описанный, конечно). Алерт требует немедленной обработки с оповещениями и подключениями всех заинтересованных согласно процессу.
Critical - алерт должен обработать дежурный, или по цепочке эскалации он уйдет команде ответственной за область (всем, на удачу - вдруг кто-то доступен), затем менеджеру команды, затем техдиру (и тогда будет больно всем). Требует немедленной обработки.
Warning. Работало как High из статьи - Требует обработки, но достаточно и next business day. Кроме того эти алерты зачастую закрываются сами. И их количество тоже мониторилось и в статистике отображалось - если было слишком много от команды в чьей области они происходили требовалось провести работу по снижению (или алерт править или продукт)
А вот Info (непонятно, равнозначен ли он Warning из статьи), просто не пускали даже в общий пайплайн. Этот приоритет был для разработчика. Хочет он помониторить что-то в уже опубликованном коде - может накрутить себе алерт и пустить в слак\тимс канал или вообще себе на почту. Мне немного непонятна разница между Warning и High из статьи
Таким образом три первых приоритета проходили отбор еще при создании алерта: все что требует обработки должно алертиться. И идти по соответствующим каналам и эскалациям, исключающим захламление алертами. Хотя так и не доделали группировку, и это мешало, когда о существовании проблемы уже известно - система не прекращала флудить.
Для инцидента не связанного с алертами был специальный механизм "Аларм" канала. Когда происходит инцидент, дежурный его подтверждает и пишет сообщение в "Аларм" канал об этом - для оповещения всех заинтересованных людей (суппорта, продакта, техдиров, техлидов и т.п.), подписанных на данный канал. Добавление упоминания @alarm бота создавало алерт в системе алертов.
Уведомления должны быть читаемыми и понятными сразу, без необходимости разбираться в технических деталях
Золотые слова. Мне так и не удалось донести до наших алертописателей смысл этого, поэтому некоторые алерты были в стиле "Метрика Х на сервисе Y равна 50%"
Интересная практика. У иностранцев в промышленности есть такая процедура ARS (alarm racionalization system), очень похоже.
Поделитесь стеком: мониторинг, cmdb? Какие приложения используете?
А есть какая-то гуишка где смотрите/видите текущие алерты? Или они в текстовом виде в чате?
Как жить, когда у тебя N тысяч алертов в секунду