Alertmanager объявлен единственным путём доставки: встроенный алертинг Grafana выключен явно #3481

Merged

lekss361 merged 1 commit from chore/3158-grafana-alerting-off into main

2026-09-12 11:08:11 +00:00

lekss361 commented

2026-09-12 11:04:16 +00:00

Owner

Закрывает #3158, пункт из #3471. Владелец выбрал вариант А.

Что было

На живом API Grafana 12.09: правил алертинга ноль, единственный контакт-поинт — стоковый grafana-default-email с адресом <example@email.com>, переменные SMTP не заданы. Раздел Alerting в интерфейсе при этом есть и выглядит рабочим. Правило, заведённое там человеком, ушло бы в стоковый почтовый контакт и потерялось молча.

Это ровно тот вид «выглядит настроенным», из-за которого никто не идёт проверять второй путь.

Решение

Дублирующий путь на том же датасорсе надёжности не добавляет: он зависит от того же Prometheus, что и основной. А стоимость поддержки удваивает. Поэтому тревоги живут в Prometheus и Alertmanager, а Grafana здесь только рисует.

GF_UNIFIED_ALERTING_ENABLED: "false" в секции grafana. Имя переменной сверено с документацией для той версии образа, что реально стоит в compose, а не взято по памяти: в 11.x существует только секция unified_alerting, легаси-секция удалена ещё в 9.0. Флаг убирает раздел Alerting из интерфейса и не поднимает движок правил.

Отдельно чистить контакт-поинт не потребовалось: каталога provisioning/alerting/ не существовало, стоковый контакт — дефолт свежей установки, а не что-то заведённое нами. При выключенном движке провижининг правил и контактов Grafana просто не читает.

Чтобы следующий не начал заново

Новый ops/metrics/grafana/provisioning/alerting/README.md фиксирует решение прямо там, куда человек полезет провижинить правила, и объясняет, почему каталог пуст намеренно.

Конфигурация провалидирована через docker compose config.

Закрывает #3158, пункт из #3471. Владелец выбрал вариант А. ## Что было На живом API Grafana 12.09: правил алертинга ноль, единственный контакт-поинт — стоковый `grafana-default-email` с адресом `<example@email.com>`, переменные SMTP не заданы. Раздел Alerting в интерфейсе при этом есть и выглядит рабочим. Правило, заведённое там человеком, ушло бы в стоковый почтовый контакт и потерялось молча. Это ровно тот вид «выглядит настроенным», из-за которого никто не идёт проверять второй путь. ## Решение Дублирующий путь на том же датасорсе надёжности не добавляет: он зависит от того же Prometheus, что и основной. А стоимость поддержки удваивает. Поэтому тревоги живут в Prometheus и Alertmanager, а Grafana здесь только рисует. `GF_UNIFIED_ALERTING_ENABLED: "false"` в секции grafana. Имя переменной сверено с документацией для той версии образа, что реально стоит в compose, а не взято по памяти: в 11.x существует только секция `unified_alerting`, легаси-секция удалена ещё в 9.0. Флаг убирает раздел Alerting из интерфейса и не поднимает движок правил. Отдельно чистить контакт-поинт не потребовалось: каталога `provisioning/alerting/` не существовало, стоковый контакт — дефолт свежей установки, а не что-то заведённое нами. При выключенном движке провижининг правил и контактов Grafana просто не читает. ## Чтобы следующий не начал заново Новый `ops/metrics/grafana/provisioning/alerting/README.md` фиксирует решение прямо там, куда человек полезет провижинить правила, и объясняет, почему каталог пуст намеренно. Конфигурация провалидирована через `docker compose config`.

lekss361 added 1 commit 2026-09-12 11:04:16 +00:00

chore(ops): выключить встроенный Grafana Alerting, единственный путь — Alertmanager

CI Trade-In / changes (pull_request) Successful in 10s

Details

CI / changes (pull_request) Successful in 14s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

93451fae08

Проверка живого API Grafana 12.09.2026: правил алертинга ноль, контакт-поинт
единственный и стоковый — grafana-default-email на example@email.com,
GF_SMTP_* не заданы. Интерфейс выглядит настроенным, кнопка "New alert rule"
работает, а результат молча уходит в никуда — ровно тот случай, из-за
которого никто не проверяет второй, настоящий путь доставки.

Дублирующий движок на том же датасорсе Prometheus надёжности не добавляет
(общая точка отказа), а поддержку удваивает. Решение: Alertmanager —
единственный путь доставки тревог, Grafana только рисует.

GF_UNIFIED_ALERTING_ENABLED: "false" в docker-compose.metrics.yml (секция
grafana) — единственная официальная секция [unified_alerting] в Grafana 11.x,
легаси-[alerting] удалён из Grafana ещё в 9.0 (сверено с grafana.com/docs/
grafana/v11.5/setup-grafana/configure-grafana/#unified_alerting). Разом
убирает Alerting из UI и глушит движок правил, так что искать и вычищать
стоковый контакт-поинт отдельно не требуется.

ops/metrics/grafana/provisioning/alerting/README.md — явная отметка для
следующего человека: провижинить contact points/rules в эту папку не нужно,
Grafana её при выключенном unified alerting не читает.

Closes #3158, refs #3471