Прямой ответ
Grafana Alerting (unified — единая система с Grafana 9+) — алерты внутри Grafana: правила на любом источнике (Prometheus/Mimir/Loki — стек — одно место вместо «алерты в Prometheus, в Loki свои, в дашбордах legacy» — Alertmanager-контекст — миграция или сосуществование — см. FAQ); архитектура понятий: alert rule (условие+периодичность — «burn rate > 14x — 1 минута» — SLO-алерты), contact point (куда: Slack/Telegram/Email/Webhook (вебхук-механика)/PagerDuty — канал доставки), notification policy (маршрутизация: дерево правил «алерты с team=backend и severity=critical → #oncall-backend + page; severity=warning → тикет-система; остальное → #alerts-общий» — лейбл-селекторы — гибкость Alertmanager-маршрутов в UI), grouping (схлопывание (10 подов горят — одно уведомление «10 инстансов», не 10 сообщений — group_by service — dedup-контекст), silences (плановые окна — деплой/обслуживание — «замолчать на 2 часа по лейблу cluster=staging» — деплой-практика — без silence деплой-алерты будят зря); ключевые практики: (1) алерты как код (provisioning через YAML/файлы в git — rules/contacts/policies — Terraform-grafana-провайдер (terraform) или file-provisioning — ревью изменений алертов (ревью) — «поправил алерт в UI, никто не знает» — легаси-болезнь — git — источник правды — IaC-дисциплина); (2) аннотации с контекстом (summary/description/runbook_url — уведомление отвечает «что/где/что делать» — ссылка на runbook — дежурный не гуглит — Grafana dashboard-ссылка в аннотации — клик в инцидент — дашборды); (3) тестирование алертов (Grafana UI — test rule/contact point; глубже — amtool/promtool test (unit-тесты правил — «условие срабатывает на тестовых данных» — CI — github-actions — тесты-культура — алерт без теста — «сработает ли в инцидент» — лотерея); (4) severity-дисциплина (critical — page (будит), warning — тикет/чат (утром), info — дашборд — fatigue-защита — «всё critical» — page-усталость — маршруты по severity обязательны — oncall); (5) pending-период (for: 5m — «горело 10 секунд» — не будим — flapping-фильтр — баланс: SLO-алерты — короткие for (burn rate), infra — длиннее — метрики-дизайн); self-monitoring алертинга (Grafana-алертинг сам — мета-алерт: «алертинг не отвечает/правила в ошибке» — healthcheck-принцип — dead man's switch — heartbeat-алерт «если тишина 10 минут — что-то умерло» — тишина обманчива — мониторинг-культура).
Практика: миграция и структура правил
Миграция с Prometheus Alertmanager на Grafana Alerting (частый путь): Grafana умеет быть Alertmanager'ом (receiver-конфиг совместим — amtool check-config валидирует — существующие rules-файлы Prometheus конвертируются (grafana-cli/amtool — частично — сложные маршруты — руками); стратегия: параллельно (Grafana-алерты в shadow — дублируют в тест-канал — сравнение срабатываний неделя — миграция-сверка) → переключение каналов → отключение старых; когда НЕ мигрировать: большой зрелый Alertmanager-стек работает — Grafana Alerting не даёт выигрыша — сосуществование нормально (Grafana-правила для Loki/бизнес-метрик, AM — для инфраструктурных — «два алертинга» — осознанно, с документацией — ADR); структура правил-файла (пример дисциплины): папки по командам/сервисам (структура — аналогия), каждое правило: имя-конвенция [сервис] что случилось — симптом («[api] error budget burn 14x» — нейминг — уведомление читается без открытия Grafana), аннотации: summary (что), description (детали+значения — {{ $values.A.Value }} — шаблонизация), runbook_url, dashboard_url; labels: severity/team/service — маршрутизация по ним (политики — дерево notification policies — корневой маршрут (дефолт — #alerts — «ничего не потерялось») → team-маршруты → severity-ветки); contact points: Slack (каналы по командам — форматирование message-шаблонами — Go-templates — «стена текста» против «читаемо» — UX-уведомлений), Telegram (бот-токен — секреты — для малых команд — rate-limit 20 msg/min — группировка критична), Webhook (своя обработка — приём-надёжность — идемпотентность уведомлений — повторы при ретраях Grafana); типичные грабли: время-окна (evaluation interval + for + группировка — суммарная задержка уведомления — «алерт пришёл через 15 минут» — интервалы сложить — SLO-чувствительность), отсутствие тестов-данных (правило «не срабатывало ни разу» — не значит работает — unit-тесты/promtool — проверка — тесты), silence-забывчивость (silence на месяц «временно» — алерт мёртв навсегда — TTL silence + ревизия — техдолг-учёт).
Практический сценарий: алерт-хаос → управляемая система за спринт
Контекст: команда 8 человек, 12 сервисов; алерт-зоопарк: 47 правил в Prometheus-файлах (половина в UI-legacy Grafana), канал #alerts — 200 сообщений/день (fatigue — выключили уведомления «чтобы не мешали» — классика), инциденты узнаются от пользователей (incident-реальность); наведение порядка (спринт): (1) инвентаризация (47 правил — классификация: 12 полезных (срабатывали и вели к действию — по истории канала), 20 мёртвых (ни разу за год — удалить — «алерт, на который не реагируют» — шум), 15 дублей/перекрытий (один симптом — три правила из разных эпох — техдолг — консолидация); (2) дизайн (правило-критерий: «каждый алерт — действие» (SRE-позиция — page только на actionable — остальное — дашборды/тикеты; 22 правила: SLO burn rate ×3 сервиса (SLO), saturation (диск/память/очереди — ёмкость — 70-пороги), ошибки интеграций (вебхуки/платёжка), dead man's switch; severity: 6 critical (page — Telegram+звонок через oncall-бот), 16 warning (тикеты — утренняя очередь); (3) структура (notification policies: team-маршруты (backend/frontend/data — свои каналы), grouping по service (10 подов — 1 сообщение — dedup), корневой маршрут — #alerts-catchall («ничего не теряется» — проверка еженедельная — пустой catchall — маршруты полны); (4) алерты как код (всё в git — provisioning YAML (terraform-провайдер — apply в CI — github-actions — правка алерта — PR+ревью — ревью-чеклист — «алерт-изменения без ревью» — закрыто); (5) проверка (chaos-вечер: убили pod (saturation-алерт ✓), 5xx-инъекция (burn-алерт ✓ за 2 минуты — chaos), отключили Grafana (dead man ✓ — «алертинг умер» виден); amtool-тесты правил в CI (позитив/негатив — тесты); (6) ритуалы (silence — только с TTL и причиной (деплой-окно — авто-silence из CI — CI-интеграция), еженедельный обзор #alerts (10 минут — «на что реагировали, что шум» — лишнее — в тикеты/удаление — fatigue-процесс), постмортем-правило: инцидент без алерта → алерт добавлен (или обосновано «почему нет» — runbook); итоги месяца: 200 сообщений/день → 8 (2 page — оба реальные — время реакции 4 мин против «узнали от клиента»), инциденты — 100% обнаружены мониторингом (3 инцидента — все алертами — первый раз за год); вывод: алертинг-система — продукт с владельцем/ритуалами/кодом — «настроили 47 алертов» — не система, шум — alerting-зрелость.
FAQ
Grafana Alerting или оставить Prometheus Alertmanager? Критерии за Grafana Alerting: мульти-источники (Prometheus+Loki+Mimir+облачные — стек — одни правила/маршруты — UI-управление с кодом позади (provisioning — git — «UI без git» — антипаттерн — раздел выше), малая команда без выделенного SRE (меньше движущихся частей — Grafana и так стоит — дашборды); за Alertmanager: зрелый стек с amtool-процессами/интеграциями (миграция без выигрыша — сосуществование — сценарий-контекст), очень крупные объёмы правил (AM-кластеры проверены масштабированием — ёмкость), Prometheus-пуризм (правила рядом с данными — задержка ниже — алерты на raw-метриках без Grafana-слоя); гибрид-стандарт: критичные infra-алерты — AM (ближе к данным — надёжнее), продуктовые/SLO/Loki — Grafana (удобнее/быстрее итерации — SLO); «переехать, потому что новое» — не аргумент — критерий — где правила живут и кто их правит — мониторинг-выбор.
Как маршрутизировать алерты по командам без путаницы? Модель: лейблы на правилах (team/service/severity — источник — правило знает «чей я» — структура-меток), дерево notification policies (корень — catchall-канал (потерянное — видно — ревизия раз в неделю — «алерт без маршрута» — баг маршрутизации, не тишина), team-уровень (backend→#oncall-backend, data→#data-alerts — continue=false — не дублировать), severity-ветки (critical→page-канал, warning→тикеты — severity-дисциплина); edge-кейсы: общие компоненты (БД/очередь — team=platform — отдельный маршрут — «чей Postgres» — дежурная платформа — онколл-дизайн), кросс-командные инциденты (алерт у backend, корень в data — escalation-политика (15 минут без реакции — на уровень выше — incident-процесс), новые сервисы (забыли лейбл team — catchall поймал — разбор — ревью-чеклист — «новый сервис без team-лейбла» — не мёрж); проверка: тест-алерт на каждый маршрут раз в квартал (chaos-ритуал — сценарий выше — маршрутизация проверяется, не предполагается — тесты).
Как писать уведомления, которые реально читают?
Структура сообщения: первая строка — что случилось и где («[api-prod] error budget сгорает: burn 14x» — без «FIRING alert rule 5» — UX), вторая — значение против порога ({{ $values }} — «error ratio 1.4% против 0.1%» — масштаб понятен), третья — что делать (runbook_url — ссылка, не «разберитесь» — runbook), четвёртая — dashboard-ссылка (Grafana — контекст в один клик); шум-контроль: grouping (сервис-группы — 10 подов — 1 сообщение — dedup), repeat_interval (не «каждые 5 минут до починки» — часы — resolved-уведомление обязательно (закрылся — видно — incident-гигиена); каналы: critical — отдельный канал с @here (звуки/пуши — Telegram-бот (секреты), warning — тихий канал/тикеты (утренняя очередь — fatigue); антипаттерны: графики-скриншоты в сообщении (Grafana image rendering — красиво, но «что делать» важнее — ссылка живее картинки — мобильный дежурный), полный трейс-дамп в сообщении (детали — в дашборде/логах (Loki) — сообщение — указатель, не отчёт — структура-логика).
Что делать с ложными срабатываниями? Цикл (еженедельный ритуал): каждое ложное — инцидент для алерта (разбор: порог неверный (тюнинг — метрики-базлайн — данные за месяц, не ощущения), условие неполное (flapping — for/окна — multiwindow — SLO-паттерн), симптом без действия («диск 75%» — всегда 75% — порог/агрегат — ёмкость-планирование), источник-шум (метрика скачет — recording rules-сглаживание/агрегат — кардинальность-контекст); метрика здоровья алертинга: доля actionable (срабатывания, ведущие к действию — цель >80% для page — fatigue-метрика — дашборд алертинга — Grafana — «алертинг сам под мониторингом» — healthcheck); правило двух ложных: алерт сработал ложно дважды — правка обязательна в этом спринте (техдолг — «потерпим» — путь к выключенным уведомлениям — сценарий выше); «удалить noisy-алерт» — последнее (симптом был неспроста — переписать/перепорожить — удаление — осознанное — ревью — SRE-баланс).
Источники: документация Grafana Alerting (fundamentals, notification policies), Prometheus alerting — ссылки в шапке.