Настройка алертов Grafana с нуля в 2026 году: практическое руководство

В этом руководстве настроим Grafana Alerting с нуля: создадим первое правило для CPU, обработаем состояния No Data и Error, подключим Telegram, Slack и Email, а затем настроим группировку и маршрутизацию уведомлений для production. Материал подойдет DevOps-инженерам и системным администраторам, которым нужно быстро получить рабочую систему алертов Grafana без алертного шторма.

Инструкции и примеры проверены на актуальных версиях Grafana 11.x и 12.x. Названия пунктов интерфейса могут немного отличаться в зависимости от версии, но логика настройки Grafana Alerting, Alert rules, Notification Policies и Contact Points остается одинаковой.

Что настроим:

Рабочее правило алерта для CPU и примеры для памяти.
Обработку состояний No Data и Error.
Уведомления в Telegram, Slack и Email.
Группировку и маршрутизацию алертов по меткам severity и командам.
Проверку системы перед запуском в production.

Подготовка инфраструктуры: без этого алертинг не заработает

Алертинг в Grafana зависит от корректно настроенных источников данных. Если источник данных недоступен, правила будут показывать состояние "No Data", и система не сработает. Этап подготовки предотвращает типичные ошибки соединения и проблемы с TLS.

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

Проверка источника данных: почему алерт видит 'No Data'?

Самая частая причина состояния "No Data" - ошибки подключения к источнику данных. Например, при настройке Jaeger как источника данных для трейсов можно столкнуться с ошибкой "404 Not Found". Согласно документации Grafana, пересмотренной в марте 2026 года, эта ошибка часто возникает из-за указания лишнего пути в URL.

Некорректный URL: http://jaeger-host:16686/api/traces. Корректный URL: http://jaeger-host:16686.

Используйте этот чек-лист для диагностики любого источника данных:

Запущен ли сервис? Проверьте, что служба (Prometheus, Jaeger, база данных) работает на целевом хосте.
Корректен ли URL и порт? Убедитесь, что адрес и порт в настройках источника данных в Grafana совпадают с реальными настройками сервиса. Избегайте лишних путей в URL.
Открыты ли порты в firewall? Проверьте правила межсетевого экрана на хосте с источником данных и на хосте с Grafana. Распространенная ошибка - "Connection refused".
Работает ли reverse proxy? Если доступ к источнику данных идет через обратный прокси (Nginx, Apache), проверьте его конфигурацию и логи.

Безопасное подключение: TLS, сертификаты и Grafana Cloud

Для защищенного соединения, особенно при использовании Grafana Cloud, требуется корректная настройка TLS. Ошибки сертификатов блокируют получение данных.

В настройках источника данных в Grafana есть поле "CA certificate". Укажите в нем сертификат вашего приватного центра сертификации, если вы используете внутренние TLS-сертификаты. Для Grafana Cloud, подключающейся к приватному Jaeger через Private data source connect, это поле обязательно.

Опция Skip TLS Verify предназначена только для тестирования в изолированных средах. Не используйте ее в production, так как это отключает проверку подлинности сервера и делает соединение уязвимым.

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

Типовые ошибки при подготовке источников и уведомлений

No Data: проверьте URL, порт, наличие метрик и доступность сервиса с хоста Grafana.
404 Not Found: удалите лишний путь из URL источника, если сервис ожидает адрес корня.
Connection refused: проверьте, запущен ли сервис и разрешено ли соединение в firewall.
Ошибка TLS: укажите корректный CA certificate; не включайте Skip TLS Verify в production.
Уведомление не отправляется: проверьте Contact Point, тестовую отправку и соответствие меток правила условиям политики.

Практика: создаем первое правило алерта Grafana

Сначала создадим рабочее правило для мониторинга загрузки CPU. Это позволяет проверить весь путь алерта: запрос, условие, состояния Pending и Alerting, а также дальнейшую доставку уведомления.

В интерфейсе Grafana перейдите в раздел "Alerting" → "Alert rules" и нажмите "Create alert rule".

Пишем запрос и задаем условия: пример для мониторинга сервера

Настройте правило по этому образцу:

Название: HighCPUUsage
Запрос (PromQL): 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100). Этот запрос возвращает среднюю загрузку CPU в процентах по каждому инстансу.
Условие: Выберите функцию last() от запроса A и оператор Above значения 80.
Интервалы: Установите "Evaluate every" = 30s, "For" = 2m. Это значит: проверять каждые 30 секунд и переводить в "Alerting", если условие значение больше 80 держится 2 минуты (4 цикла оценки). Состояние "Pending" будет длиться эти 2 минуты.

Добавьте метки (Labels) для лучшей маршрутизации:

severity: warning
team: infra
instance: "{{ $labels.instance }}"

Добавьте аннотации (Annotations) для информативного уведомления:

summary: "Высокая загрузка CPU на {{ $labels.instance }}"
description: "Средняя загрузка CPU составляет {{ $values.A }}%. Проверьте процессы на инстансе."
runbook_url: "https://ваш-wiki/runbooks/high-cpu"

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

Архитектура Grafana Alerting: как устроена система оповещений

Понимание архитектуры помогает осознанно настраивать систему. Grafana Alerting состоит из связанных компонентов, которые преобразуют условие в метрике в уведомление в нужном канале.

Основной поток: Alert Rules (Правила) → Evaluation (Оценка) → States (Состояния) → Notification Policies (Политики) → Contact Points (Точки контакта).

Alert Rules и Evaluation: от метрики до состояния 'Alerting'

Alert Rule - это ядро системы. Оно определяет, за какой метрикой следить и при каких условиях генерировать алерт.

Запрос (Query): Выражение на PromQL, SQL или встроенном языке запросов источника данных, которое возвращает числовое значение или временной ряд.
Условие (Condition): Логическое правило, например, "значение больше 80" или "последнее значение равно 0".
Интервал оценки (Evaluate every): Как часто Grafana проверяет правило. Например, каждые 30 секунд.

Процесс Evaluation запускается по расписанию. Система вычисляет запрос, проверяет условие и присваивает правилу одно из состояний:

OK: Условие не выполнено.
Pending: Условие выполнено, но длится меньше времени, указанного в параметре "For". Это состояние предотвращает ложные срабатывания при кратковременных скачках.
Alerting: Условие выполнено дольше времени, указанного в "For". Правило активировано, система передает алерт в модуль уведомлений.
No Data: Запрос не вернул данных. Это состояние может означать падение экспортера метрик.

Обработка состояний No Data и Error

Отсутствие данных - это тоже инцидент. Создайте отдельное правило для отслеживания состояния "No Data" от ключевых экспортеров.

Запрос: Используйте функцию last() от вашей основной метрики.
Условие: Выберите специальное состояние "No Data" и настройте период, например, "For" = 5m. Это позволит избежать ложных срабатываний при кратковременных сетевых проблемах.
Метки: Присвойте метку severity: critical, так как отсутствие данных часто критично.

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

Notification Policies и Contact Points: маршрутизация уведомлений

Когда правило переходит в состояние "Alerting", в дело вступают политики уведомлений. Они решают, куда отправить оповещение.

Notification Policies: Набор правил маршрутизации. Политика сопоставляет алерты по меткам (labels) и направляет их на определенную контактную точку. Вы можете создать дерево политик: от общей (default) до специфичных для команды или уровня критичности.
Contact Points: Конечные каналы для отправки уведомлений. Это интеграции с Telegram, Slack, Email, Webhook и другими системами.

Ключевая функция политик - группировка (group by). Она объединяет несколько связанных алертов в одно сообщение. Например, если на одном инстансе одновременно сработали алерты на высокую CPU и память, вы получите одно уведомление, а не два.

Если вы сомневаетесь в выборе между встроенным алертингом Grafana и Prometheus Alertmanager, вам поможет практическое руководство по выбору системы алертинга.

Настройка уведомлений в Telegram, Slack и по Email (Contact Points)

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

Telegram Bot: быстрое подключение и полезный шаблон сообщения

Telegram - самый быстрый способ получить персональное оповещение.

Создайте бота через @BotFather в Telegram. Получите токен.
Начните диалог с созданным ботом.
Получите Chat ID: отправьте любое сообщение боту, затем выполните запрос https://api.telegram.org/bot<ВАШ_ТОКЕН>/getUpdates. В ответе JSON найдите chat.id.
В Grafana: "Alerting" → "Contact points" → "Add contact point".
Выберите тип "Telegram". Вставьте URL: https://api.telegram.org/bot<ВАШ_ТОКЕН>/sendMessage и укажите "Chat ID".

Используйте этот шаблон сообщения для читаемости:

🚨 *{{ .Status | toUpper }}: {{ .Labels.alertname }}*

*Инстанс:* {{ .Labels.instance }}
*Серьезность:* {{ .Labels.severity }}

{{ .Annotations.summary }}

{{ .Annotations.description }}

[Дашборд]({{ .GeneratorURL }})

Slack Webhook и Email: для командной работы и критических инцидентов

Slack: Идеален для командных каналов.

В Slack: зайдите в "Settings & administration" → "Manage apps" → "Incoming Webhooks".
Добавьте новый вебхук для нужного канала и скопируйте URL.
В Grafana создайте Contact Point типа "Slack". Вставьте URL вебхука.

Email: Канал для критических алертов и архивных уведомлений.

В Grafana: "Alerting" → "Contact points" → "Add contact point" → "Email".
Заполните настройки SMTP: адрес сервера (например, smtp.gmail.com:587), пользователь, пароль (часто требуется пароль приложения).
Укажите адреса получателей. Задайте понятного отправителя (From), например, grafana-alerts@ваша-компания.com.

Создайте отдельную политику уведомлений, которая будет отправлять все алерты с меткой severity: critical на Email. Перед запуском проверьте тестовую отправку из каждого Contact Point.

Сборка системы: политики уведомлений, группировка и тестирование

Теперь соберем компоненты в целостную систему, которая отправляет правильные уведомления правильным людям.

Создание дерева политик: направляем алерты нужным людям

Политики уведомлений работают по принципу специфичности. Grafana проверяет политики сверху вниз и применяет первую, условия которой совпали.

Пример дерева политик:

Критические алерты в Telegram и Email:
- Matchers: severity=critical
- Contact Point: Ваш Telegram и Email.
- Группировка: group_by: [alertname, instance]
Алерты команды БД в Slack:
- Matchers: team=database
- Contact Point: Slack-канал DBA.
Алерты команды фронтенд в Slack:
- Matchers: team=frontend
- Contact Point: Slack-канал фронтенд-разработчиков.
Default policy (все остальное):
- Matchers: (пусто - совпадает со всем)
- Contact Point: Общий Email-лист для инцидентов.
- Группировка: group_by: [...] - настройте по необходимости.

Группировка по alertname и instance объединяет все срабатывания одного правила для одного инстанса в одно уведомление в пределах интервала группировки.

Тестирование и запуск в production: чек-лист перед включением

Перед тем как считать систему готовой к работе, выполните этот чек-лист:

Источники данных: Проверены, данные поступают без ошибок.
Тестовое правило: Создано и протестировано на тестовом инстансе. Используйте искусственную нагрузку (например, stress-ng --cpu 4 --timeout 3m), чтобы вызвать срабатывание.
Уведомления: Приходят во все настроенные каналы (Telegram, Slack, Email). Сообщения читаемы и содержат нужную информацию.
Обработка No Data: Правило создано и протестировано, например временной остановкой экспортера метрик.
Группировка: Несколько алертов объединяются в одно сообщение.

Итог: Система не создаст алертный шторм в первый день работы и будет реагировать на реальные проблемы.

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

После настройки базового алертинга вы можете углубиться в тонкости настройки связки Prometheus и Alertmanager. В руководстве по настройке оповещений в Zabbix разобраны готовые конфигурации правил и механизмы подавления ложных срабатываний.

Готовая система Grafana Alerting автоматически отслеживает ключевые метрики, обрабатывает состояния No Data и Error, группирует события и доставляет уведомления в нужные каналы. После проверки в тестовой среде конфигурацию можно адаптировать под требования вашего production.