Grafana alerting и маршрутизация PagerDuty для небольших команд

Почему alerting быстро превращается в хаос

Alerting начинается с хороших намерений. Команда добавляет одно правило на CPU, одно на ошибки, одно на доступность, и всем кажется, что теперь безопаснее. Через несколько месяцев алерты живут в Grafana, облачном мониторинге, системе ошибок, CI и паре собственных скриптов. Теперь никто не понимает, какие сигналы указывают на реальную проблему, какие заслуживают вызова дежурного, а какие могут подождать до утра.

Именно здесь команды и застревают. Grafana и PagerDuty пересекаются ровно настолько, чтобы возникало желание использовать оба инструмента для всего подряд. Grafana может следить за метриками и замечать проблемы. PagerDuty может разбудить нужного человека, применить расписания и эскалировать вопрос, если никто не отвечает. Когда эти роли смешиваются, правила накапливаются, а схеме всё сложнее доверять.

Смешанные правила быстро путают людей. Один алерт говорит «disk is high», другой — «API latency is up», третий — «service failed health check». Все три относятся к одному и тому же сбою, но приходят разными путями и с разной срочностью. Один человек считает их шумом. Другой думает, что кто-то уже разобрался. Команда теряет главное, что должен давать alerting: понятный следующий шаг.

Слишком много источников вызовов только ухудшает ситуацию. Если Grafana, Sentry, облачный провайдер и cron-задача могут будить людей напрямую, одно замедление базы данных может привести к четырём пробуждениям. После нескольких таких ночей люди перестают верить алертам. Они заглушают каналы, убавляют громкость или игнорируют сообщения, пока проблема не выглядит уже слишком большой. Так команды пропускают именно тот сигнал, который был важен.

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

Небольшие команды чувствуют это раньше крупных. Людей меньше, а систем больше, поэтому каждый ложный вызов отнимает у команды фокус у продуктовой работы на следующий день. Здесь помогает чёткое разделение. Один инструмент должен решать, когда система выглядит нездоровой. Другой — кто, когда и как часто будет отвлечён.

Что должен делать Grafana

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

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

Grafana — хорошее место и для предупреждений, которые можно спокойно разобрать позже, а не считать их экстренной ситуацией. Batch-задача, которая запаздывает, память, растущая в течение недели, или краткая задержка реплики всё ещё важны. Но обычно это не повод звонить человеку посреди ночи.

Практичная настройка Grafana проста. Оставьте панели по здоровью сервиса: ошибки, задержка, трафик и насыщение. Разместите рядом связанные графики и метрику алерта. Сделайте так, чтобы было легко сравнить текущее состояние с последним часом или последним релизом. Когда человек открывает дашборд, он должен сразу видеть, началась ли проблема после выката, росла ли она весь день или совпала со всплеском трафика.

В компактном стеке с Prometheus, Loki и Sentry такой экран экономит реальное время, потому что первые проверки происходят в одном месте. Никому не хочется искать ответ на первый вопрос сразу в пяти инструментах.

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

Что должен делать PagerDuty

PagerDuty должен отвечать за человеческую часть alerting. Grafana может заметить, что что-то не так, но PagerDuty должен решать, кого отвлечь, как быстро поднимать проблему по цепочке и когда несколько отдельных алертов относятся к одному инциденту.

Такое разделение делает слой вызовов проще. Если меняется порог, правьте Grafana. Если меняется график дежурств, кто-то отсутствует или другой команде нужна подстраховка через 10 минут, правьте PagerDuty. Не стоит смешивать логику дашбордов с логикой сна в два часа ночи.

Для большинства небольших команд у PagerDuty короткий список задач. Он управляет расписаниями, исключениями и передачами смены. Он маршрутизирует инциденты к нужному человеку или команде. Он эскалирует проблему, если никто не подтверждает вызов. Он объединяет связанные алерты в один инцидент и ведёт понятную историю реакции.

Группировка важнее, чем многие ожидают. Неудачный деплой может за две минуты вызвать высокую задержку, рост ошибок и увеличение очереди. Если всё это приходит тремя отдельными вызовами, один человек получает три удара за одну и ту же проблему. Более удачная схема открывает один инцидент для этого сервиса и добавляет к нему связанные алерты.

Именно здесь PagerDuty и оправдывает своё место. Ему не нужно хранить десятки пороговых правил. Ему нужно применять правила реакции, которые остаются стабильными даже тогда, когда дашборды меняются каждую неделю.

Простой пример хорошо показывает разделение. Допустим, сервис checkout начал ломаться после релиза. Grafana замечает сбой и отправляет события с именем сервиса, уровнем серьёзности и средой. PagerDuty видит, что это production, вызывает основного инженера, ждёт 10 минут и затем эскалирует к запасному, если никто не ответил. Если ещё три алерта приходят по той же проблеме checkout, PagerDuty складывает их в тот же инцидент вместо того, чтобы будить половину команды.

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

Решите, где живёт каждое правило

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

Одно это решение уже убирает много шума. Команды часто отправляют пороговые предупреждения, проверки ёмкости и капризные симптомные алерты в тот же поток, что и реальные сбои. Потом канал вызовов перестаёт означать «бросай всё» и начинает означать «может, посмотрим позже».

Разделение становится проще, когда у каждого инструмента одна задача. Пусть Grafana обнаруживает условия и создаёт алерты. Пусть PagerDuty решает, кого вызвать, уже после того как алерт прошёл тест на «человеку нужно сейчас».

Хорошее правило легко запомнить. Для вызова берите только user impact, жёсткие отказы и ограничения безопасности. Шумные проверки порогов оставляйте в Grafana, где люди могут смотреть на тренды без пробуждения ночью. Маршрутизируйте по владельцу сервиса, а не по папке дашборда или случайному названию команды, которое было выбрано при создании алерта. У каждого правила вызова должен быть один понятный владелец.

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

Один владелец на одно правило вызова также предотвращает худший сценарий: все думают, что ответит кто-то другой. Если сработал алерт checkout API, за этот вызов должен отвечать один человек или одно расписание. Других людей можно уведомить позже, но первый ответственный никогда не должен быть загадкой.

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

Как разбить настройку по шагам

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

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

Хорошо работает простой план перехода:

1. Проверьте каждый живой алерт. Включите правила Grafana, сервисы PagerDuty, старые контактные точки и разовые уведомления, которые уходят в чат или на почту. Большинство небольших команд быстро находят дубли.
2. Пометьте нужный результат. Используйте простые метки вроде вызов, тикет или дашборд. Полный простой — это вызов. Рост диска в течение месяца — только дашборд. Повторяющиеся сбои деплоя могут уйти в тикет.
3. Перенесите логику эскалации в PagerDuty. Расписания, повторные попытки, задержки и следующий человек в цепочке должны жить там. Не тащите это в Grafana, чтобы не собирать одну и ту же цепочку в нескольких местах.
4. Оставьте сигналы статуса и трендов в Grafana. Графики ёмкости, всплески ошибок, медленный рост памяти и панели здоровья сервиса помогают людям увидеть, что происходит. Им редко нужен телефонный вызов в 2 часа ночи.
5. Сначала протестируйте один сервис. Возьмите сервис, который команда хорошо знает, запустите новую схему на неделю и разберите каждое уведомление. Если нужный человек получил нужный сигнал в нужный момент, переносите этот подход на следующий сервис.

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

В этом и есть цель. Хорошая схема дежурства должна казаться немного скучной. Когда Grafana показывает состояние системы, а PagerDuty занимается маршрутизацией, каждый инструмент остаётся проще, шума становится меньше, а вызовы приходят реже и с понятным следующим шагом.

Простой пример для небольшой команды

Представьте небольшой SaaS-продукт с одним веб-приложением, одной базой данных и маленькой командой, которая дежурит по очереди. Им не нужны десятки правил для вызова. Им нужна схема, которая объясняет, что происходит, не будя человека на каждый скачок.

Grafana сначала отвечает за видимость. Команда держит там графики задержки, ошибок и состояния базы данных, потому что Grafana хорошо показывает тренды. Если время ответа медленно растёт 20 минут, они хотят увидеть это на дашборде и в тихом канале алертов, а не в телефонном вызове.

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

В этой схеме у PagerDuty только два случая для вызова. Первый — сбой checkout. Если платёжный поток ломается на устойчивом отрезке времени, кто-то должен действовать сразу, потому что доход останавливается. Второй — настоящий простой, когда сайт остаётся недоступным достаточно долго, чтобы исключить короткую проблему с деплоем или краткий сетевой сбой.

Хранилище базы данных рассматривается иначе. Если свободного места становится меньше порога предупреждения, Grafana отправляет этот сигнал в очередь задач или чат команды. Никто не получает ночной телефонный алерт только потому, что свободного места стало 18% вместо 30%. Это всё ещё важно, но обычно решается в рабочий день, если падение не резкое и не сильное.

Через неделю команда просматривает все сработавшие алерты. Они задают несколько простых вопросов. Указывал ли этот алерт на проблему для пользователя? Нужно ли было действовать сразу? Повторялся ли алерт, не меняя реакцию? Можно ли было обойтись дашбордом или сообщением в очередь?

Такой разбор быстро убирает шум. Предупреждение о задержке может остаться только в Grafana. Алерту по хранилищу может понадобиться более высокий порог. Правилу для сбоя checkout может понадобиться меньшая задержка, потому что каждая минута имеет значение.

Небольшие команды лучше работают, когда у каждого инструмента одна понятная задача. Grafana объясняет систему. PagerDuty защищает сон и ловит те немногие проблемы, которые не могут ждать.

Ошибки, которые создают шум и пропущенные сигналы

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

Первая ловушка — будить людей на каждом пороге предупреждения. Предупреждение часто означает «посмотри в ближайшее время», а не «разбуди человека прямо сейчас». Если диск заполнен на 75% или очередь чуть медленнее обычного, сначала это место для дашборда или чата. Оставьте вызовы для проблем, которые требуют действия немедленно.

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

Дублирование не менее вредно. Если Grafana создаёт алерт, а PagerDuty делает почти такой же дубль со своей логикой, одна проблема может превратиться в два вызова с чуть разными названиями. Кто-то подтверждает один, думает, что вопрос закрыт, и пропускает второй. Выберите одно место, где определяется триггер. А второй инструмент пусть занимается доставкой, эскалацией или логикой расписаний.

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

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

Перед тем как правило пойдёт в прод, задайте пять вопросов. Должен ли этот сигнал будить человека сейчас или только информировать? Кто владеет этим сервисом сегодня, а не полгода назад? Определено ли это условие один раз, а не дважды в двух инструментах? Есть ли у вызова первый шаг, который можно выполнить спросонья? Проверили ли вы именно ночной и выходной график?

Небольшие команды обычно выигрывают от меньшего числа правил, более ясного владения и прямого текста алертов. Это менее эффектно, но работает заметно надёжнее.

Короткий чек-лист перед переходом

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

Перед тем как что-то переносить, попросите команду прочитать каждое правило вызова вслух одним предложением. «Если ошибки checkout держатся выше 5% 10 минут, вызываем Sam» — такое правило легко доверить. Этот простой тест быстро показывает туманную логику. Он же помогает понять, даёт ли Grafana достаточно контекста, чтобы ответить на базовый вопрос: почему это сработало?

Используйте этот список перед переходом:

• Каждое правило вызова укладывается в одно предложение и говорит, что сломалось, как долго это должно быть сломано и кого вызывают первым.
• У каждого вызова есть один владелец, который может действовать, а не размытая метка команды, из-за которой все ждут друг друга.
• Алерты в Grafana содержат достаточно меток, графиков или заметок, чтобы инженер мог увидеть вероятную причину без долгих поисков.
• Команда проверила эскалации на реальных людях, реальных телефонах и короткой тренировке, а не только на просмотре настроек.
• Старые правила удалены после переноса, чтобы никто не получал дублирующиеся вызовы из-за забытых политик.

Одна из типичных ошибок на бумаге выглядит маленькой. Grafana выдаёт «API latency high», PagerDuty маршрутизирует это в «backend», а дежурный всё равно не понимает, проблема в коде приложения, запросе к базе данных или перегруженном узле. Перепишите правило до миграции. Вызов должен вести к действию, а не начинать спор.

Небольшие команды дважды платят за каждое плохое правило. Сначала кто-то попадает в ложную тревогу. Потом та же команда игнорирует реальный алерт, потому что система приучила её не реагировать. Потратьте 30 минут на этот обзор, уберите лишнее и сделайте каждый вызов легко объяснимым. Уже этого часто хватает, чтобы сократить шум ещё до того, как он доберётся до телефона.

Следующие шаги для более спокойного дежурства

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

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

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

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

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

Когда схема всё ещё кажется запутанной

Некоторые alerting-стэки становятся сложными потому, что их собирали по одному срочному исправлению. Одно правило оставили, потому что инцидент напугал команду. Другое оставили, потому что никто не хотел в него лезть. Через некоторое время система перестаёт быть понятной.

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

Если нужна внешняя помощь, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как Fractional CTO и советник по инфраструктуре и AI first software development. Короткий разбор со стороны помогает гораздо легче заметить дублирующиеся вызовы, неясное владение и запутанные пути эскалации.

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