Прямой ответ
Цепочка оповещений: Prometheus вычисляет alert-правила (PromQL-условие + for — сколько условие должно продержаться, + лейблы severity/описание) → Alertmanager группирует, глушит дубли, маршрутизирует по получателям (Slack/Telegram/email/PagerDuty) и подавляет связанные (incident-дерево: «хост недоступен» глушит десяток алертов его сервисов). Качество системы определяется одним критерием: каждый пейдж требует действий человека — иначе канал игнорируют и настоящий инцидент тонет в шуме (алерт-фатиг — причина смерти мониторинга чаще, чем отсутствие метрик). Правила практики: алертить на симптомы для пользователя (SLO-деградация, ошибки, недоступность — SLO-логика), не на причины (CPU 90% при зелёных SLO — дашборд, не пейдж); for ≥ 2–5 минут против мгновенных всплесков; две категории — page (нужен человек сейчас) и ticket (разобрать в рабочее время — всё остальное); каждое правило — с runbook-ссылкой в аннотации (инцидент-процесс); и регулярная ревизия: правило, на которое месяц никто не действовал, — удаляется или понижается до дашборда.
Alert-правила Prometheus: анатомия и типы
Пример правила: alert: HighErrorRate, expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05, for: 5m, labels: severity: page, annotations: summary + runbook_url. Ключевые решения: expr — доля/скорость, не абсолют (5% ошибок — сигнал при любом трафике; «100 ошибок в минуту» ночью при нулевом трафике — ложняк); for — устойчивость (мгновенный всплеск при деплое — не инцидент: for: 5m отсекает транзиенты; слишком длинный for на критичном — потерянные минуты); severity — маршрутизирующий лейбл (page/ticket/warning — Alertmanager разводит по каналам). Полезные категории правил: симтомные (ошибки, латентность p95, доступность health-эндпоинта — метрики приложения), ресурсные-предиктивные (диск заполнится за 24 ч — predict_linear, память растёт — алерт до падения), процессные (target down, сертификат истекает < 14 дней — Let's Encrypt, backup не выполнялся сутки — «тихие» отказы ловятся отсутствием события: absent()/time-since-last-success паттерн). Антипаттерны: алерт на каждый CPU/диск/процесс без привязки к последствию (классический шум-набор «из коробки» экспортеров — прореживать безжалостно), дубли одного события разными правилами (одно событие — одно правило — одна реакция).
Alertmanager: группировка, подавление, маршруты
Конфиг Alertmanager решает «кто получит и сколько раз»: group_by (десяток алертов одного кластера — одно сообщение, не десять — [ALERT] cluster=prod (11)); route-дерево (severity=page → PagerDuty/телефон дежурному, ticket → Slack-канал команды, warning → дневной дайджест; маршруты по лейблам team/service — каждый сервис алертит своим владельцам — дежурство); repeat_interval (повтор непотухшего алерта — 4h, не 5m: напоминание полезно, пулемёт — нет); inhibit_rules («хост down» подавляет алерты сервисов на нём; «кластер недоступен» глушит всё внутри — дерево причинности вместо шквала); silences (плановые работы — окно тишины по лейблам через UI/API — деплой без фейерверка алертов, деплой-стратегии дружат с автоматическими silence). Отдельно — интеграции: Slack-шаблон с полезными полями (метрика, значение, дашборд-ссылка, runbook — Grafana-линки прямо из алерта экономят минуты в инциденте); HA-пара Alertmanager'ов (дедуплицируют друг друга — алертинг сам не должен быть SPOF).
Алерт-гигиена: метрики самой системы
Алертинг — продукт с пользователями (дежурные) и метриками: доля actionable-пейджей (цель >80%: ниже — правила чистить), MTTA (время до подтверждения — сигнал о качестве маршрутизации/усталости), алертов на инцидент (шторм >10 сообщений — группировка/inhibit недостаточны), ложные срабатывания по правилам (топ-5 шумных правил — ежемесячный разбор: порог, for, или удалить). Процесс ревизии: квартальный обзор — по каждому правилу: сколько сработало, сколько потребовало действий, что меняли; правило без действий — понизить в ticket/warning или удалить («жалко удалять» — правило продолжит шуметь и обесценивать канал). Onboarding новых сервисов — с минимальным алерт-набором (доступность + ошибки + saturating-ресурсы — не копировать 50 правил соседа вслепую). И связка с SLO: лучшие пейдж-правила — burn-rate-алерты бюджета ошибок (многооконная схема) — автоматически балансируют чувствительность и шум.
Практический сценарий: от шквала к рабочему набору
Исходник: команда включила node_exporter + дефолтные правила — 40 алертов в сутки, канал mute'ят через неделю, дежурство фикция. Ревизия: (1) аудит — из 60 правил за месяц сработали 34, действий потребовали 6; (2) чистка — 28 правил удалены/понижены (CPU/нагрузка без последствия — на дашборд), у 12 поднят порог/for (ночные всплески памяти при бэкапах — окно исключено); (3) ядро — 8 пейдж-правил: health-энпоинт down (for 2m), ошибки >5% 5м, p95 >2s 10м, диск-full прогноз 24h, сертификат <14д, backup пропущен, очередь растёт 30м, target down; (4) Alertmanager: page → телефон дежурного, ticket → Slack с repeat 4h, inhibit «хост down → его сервисы», silence-окна на деплой-пайплайн (CI создаёт silence на время выкатки — CI-практика); (5) через месяц метрики: 2.3 пейджа в сутки → 0.4, доля actionable 85%, MTTA 4 минуты; два реальных инцидента (утечка диска, деградация латентности БД — EXPLAIN-разбор по горячим следам) пойманы до жалоб. Вывод: алертинг лечится не добавлением правил, а удалением лишних — чувствительность системы определяется её тихими местами.
FAQ
Alertmanager или Grafana Alerting? Пересечение есть (Grafana умеет алерты по панелям и роутинг); Prometheus+Alertmanager — канон для метрик (правила версионируются в git с PromQL, вычисление на стороне Prometheus — живёт при недоступности Grafana); Grafana-алерты удобны для бизнес-метрик на дашбордах и смешанных источников; два алертинг-стека одновременно — риск расхождения (выбирать один основной).
Как алертить на «событие не произошло» (backup, джоба)?
Паттерны: метка времени последнего успеха + time() - last_success_ts > 86400 (экспортер/pushgateway пишут метку при успехе), absent() по метке живого процесса, healthchecks-пинг-сервисы (нет пинга — алертит сам сервис); «джоба просто не запускалась» — самый частый тихий отказ (таймеры и их тишина).
Что делать с алертами во время деплоя? Silence на окно деплоя (автоматически из пайплайна, с автоистечением — «забытый silence» хуже шквала), либо правила с for переживают транзиенты сами, либо деплой-маркеры в Grafana объясняют всплески; «алерты врут на каждый деплой» — симптом не алертов, а деплоя (graceful-практики убирают всплески ошибок).
Тестировать ли алерты?
Да: promtool check rules + unit-тесты правил (promtool test rules — входные ряды → ожидаемые алерты — регрессия порогов в CI); периодический drill — поднять тестовую нагрузку/уронить тестовый сервис и убедиться, что пейдж дошёл до телефона (маршрутизация, интеграции, дежурный — вся цепочка, не только PromQL).
Источники: документация Prometheus alerting rules, Alertmanager, SRE book (monitoring) — ссылки в шапке.