← вся теориятеория к собесу · Мониторинг и логи

Алерты и дежурство без шума

Алерты и дежурство

Алерт - это автоматический сигнал, который зовёт живого человека: пишет в чат или звонит дежурному, то есть тому, кто в эту ночь отвечает за сервис. Сделал сигнал, который гуляет вокруг порога: доля ошибок то около 3%, то около 8%. Порог поставил на 5% и посчитал по реальным собранным данным. Алерт без выдержки сработал бы 2 раза за 140 секунд наблюдения. Тот же алерт с выдержкой 30 секунд - 1 раз. С выдержкой 2 минуты - НИ РАЗУ, потому что ни один всплеск не продержался так долго.

Стержень: алерт нужен на то, что заметил пользователь, и с выдержкой, отсекающей короткие всплески; всё остальное - шум, который выключают через месяц дежурств.

// Формулировки: «на что вешать алерты?», «как бороться с шумом?», «чем алерт отличается от графика?»

Симптом вместо причины

Алерт на причину - это «процессор загружен на 90%», «памяти осталось 10%», «очередь длиннее тысячи». Проблема в том, что все эти состояния бывают штатными: сервис может спокойно работать при загруженном процессоре, а очередь на тысячу - нормальный вечерний пик. Дежурного будят, он смотрит и ничего не делает. Через месяц такие сигналы перестают читать.

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

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

алерт на симптом: срабатывает на то, что заметил пользователь
алерт на причину: срабатывает на внутреннее состояние; часто ложный

Выдержка и шум

Выдержка - это требование, чтобы условие держалось непрерывно заданное время, и только тогда алерт срабатывает. Мой замер показывает, зачем она: на мигающем сигнале без выдержки было 2 срабатывания, с выдержкой 30 секунд - 1, с выдержкой 2 минуты - 0.

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

// Дальше идут два механизма против шума. Группировка: если упала база, то каждый из тридцати сервисов зажжёт свой алерт, и дежурный получит тридцать сообщений об одной аварии - группировка сводит их в одно. И подавление: пока горит алерт «дата-центр недоступен», алерты про отдельные сервисы в нём молчат. Без этих двух вещей дежурство превращается в разгребание почты.

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

Куда идёт алерт и что в нём написано

У алерта есть уровень назначения. Разбудить дежурного ночью - это одно, написать в рабочий чат - другое, завести задачу - третье. Если всё едет одним потоком, то ночные звонки перемешиваются с «диск заполнен на 70%», и человек перестаёт различать.

В самом сообщении должно быть четыре вещи: что случилось словами пользователя, насколько плохо (число и порог), ссылка на график и ссылка на инструкцию. Инструкция - это не «перезагрузите сервис», а конкретные шаги проверки для этого конкретного алерта. Её пишет тот, кто заводил алерт, и без неё алерт не принимается.

// Проверять алерты надо так же, как код. Самый частый провал - алерт, который никогда не срабатывал, потому что запрос в нём написан с ошибкой и всегда возвращает пусто. Лечится учениями: искусственно ломают сервис и смотрят, зажёгся ли сигнал и дошёл ли до человека.

уровень назначения: будить человека, писать в чат или заводить задачу
инструкция к алерту: конкретные шаги проверки, написанные автором алерта

Как отвечать: «Дежурные жалуются на шум от алертов. Что делать?»

Сначала посчитать, а не чинить наугад: взять срабатывания за месяц и разложить по алертам и по тому, потребовали ли они действия. Обычно выясняется, что три-четыре правила дают почти весь поток и почти все ложные. Дальше по порядку. Первое: перевести алерты с причин на симптомы - будить надо на то, что заметил пользователь, а загрузку процессора оставить на графике. Второе: поставить выдержку. Я это мерил на мигающем сигнале: без выдержки два срабатывания, с выдержкой в полминуты одно, с выдержкой в две минуты ни одного, потому что ни один всплеск столько не держался. Третье: группировка и подавление, чтобы одна авария давала одно сообщение, а не тридцать. И проверка на будущее: если на алерт нет инструкции с конкретными шагами, он не заводится - значит, действия по нему всё равно нет.

Ответ начинается с подсчёта, а не с рецепта, и даёт три рычага в порядке эффекта. Требование инструкции к алерту показывает опыт настоящего дежурства.

На чём валятся

−Вешают алерты на загрузку процессора и память и будят людей на штатные состояния.
−Не ставят выдержку и получают срабатывание на каждый двухсекундный всплеск.
−Шлют всё одним потоком: ночные звонки и «диск на 70%» вперемешку.
−Заводят алерт без инструкции, и в три ночи никто не знает, что с ним делать.
−Никогда не проверяют, что алерт вообще способен сработать.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 7, остальные разбираются в тренажёре.

#dvo_alerting1 / 5
Упала нода — дежурному прилетело сорок уведомлений за минуту. Чем это лечится в Alertmanager?
A)Группировкой по общим лейблам и правилами подавления
B)Увеличением интервала опроса целей до минуты
C)Переносом части правил в отдельный экземпляр Prometheus
D)Отключением уведомлений в ночные часы по расписанию
показать ответ и разбор
+A)Группировкой по общим лейблам и правилами подавления
// разбор: Alertmanager собирает срабатывания в группы по лейблам (кластер, сервис, нода) и шлёт одно уведомление на группу, а правилами inhibit гасит следствия при активной причине: если горит «нода недоступна», не будят по каждому поду на ней. Плюс silence на время работ. Цель — чтобы дежурный получал по одному сообщению на инцидент, иначе алерты начинают игнорировать все подряд.
#dvo_alerting2 / 5
Дежурные жалуются, что тонут в оповещениях и начали пропускать важные. В чём корень проблемы с алертами?
A)Мало каналов оповещения, часть алертов не доходит
B)Слишком много шумных алертов, их игнорируют
C)Порог алертов задран, срабатывают редко
D)Дежурных мало, нужно расширить график дежурств
показать ответ и разбор
+B)Слишком много шумных алертов, их игнорируют
// разбор: Корень — alert fatigue: когда будят на всё подряд (в том числе на то, с чем не надо ничего делать), люди притупляются и пропускают реально важное. Лечится дисциплиной: страничат (будят) только на симптомы, требующие немедленного действия; остальное — в тикеты/дашборды/предупреждения без пейджа. Каждый пейдж должен иметь понятное действие и рунбук. Меньше шума — выше реакция на настоящее.
#dvo_alerting3 / 5
Экспортёр метрик сервиса тихо умер, метрики перестали поступать — и алерты по ним просто не срабатывают. Как ловить такое?
A)Понизить порог существующих алертов на всякий случай
B)Чаще скрейпить, тогда пропажа заметится сама
C)Алерт на отсутствие данных: up==0 или absent() (dead man's switch)
D)Добавить второй такой же алерт по тем же метрикам
показать ответ и разбор
+C)Алерт на отсутствие данных: up==0 или absent() (dead man's switch)
// разбор: Если цель отвалилась, обычные пороговые алерты молчат — данных для срабатывания просто нет, и слепая зона выглядит как «всё хорошо». Поэтому заводят алерты на отсутствие сигнала: up == 0 (цель не скрейпится), absent(metric) (метрика пропала), и dead man's switch — постоянно активный алерт, чьё молчание означает, что сломался сам мониторинг/доставка. Так ловят немой отказ телеметрии.
#dvo_alerting4 / 5
Хотят будить по нарушению SLO, но статический порог «ошибки > 1%» то молчит на медленной деградации, то поднимает по мелкому всплеску. Что зрелее?
A)Поднять статический порог до 5%, чтобы не шумел
B)Слать алерт на каждый одиночный запрос с ошибкой
C)Мерить только суточное среднее ошибок
D)Алерт на burn rate бюджета в нескольких окнах
показать ответ и разбор
+D)Алерт на burn rate бюджета в нескольких окнах
// разбор: Статический порог по ошибкам плохо привязан к SLO: слишком чувствителен к всплескам и слеп к медленному, но устойчивому выгоранию бюджета. Зрелый подход — алерты на burn rate: как быстро расходуется бюджет ошибок относительно допустимого. Комбинируют несколько окон (быстрое + медленное), чтобы короткий острый сбой и долгая слабая деградация оба ловились, а разовый всплеск — нет. Так пейджи коррелируют с реальным риском нарушить SLO.
#dvo_alerting5 / 5
Что такое алерт в системе мониторинга?
A)Отметка о плановых работах на сервисе
B)График значения метрики за период
C)Запись об ошибке в журнале приложения
D)Оповещение по сработавшему условию
показать ответ и разбор
+D)Оповещение по сработавшему условию
// разбор: Правило описывает условие, а система сама шлёт оповещение, когда оно держится нужное время. Ключевое требование к алерту — чтобы на него было что делать: оповещения, на которые не реагируют, быстро начинают игнорировать все подряд.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: Мониторинг и логи