Alertmanager: настройка алертов и маршрутизация уведомлений

Alertmanager — компонент экосистемы Prometheus, который принимает алерты от Prometheus, группирует их, убирает дубликаты и отправляет уведомления в нужные каналы: Telegram, Slack, email, PagerDuty и другие. Его главная задача — не просто «слать тревоги», а делать это управляемо и без шума.

Зачем нужен Alertmanager

• дедупликация одинаковых алертов
• группировка событий по сервису, хосту, namespace
• маршрутизация по командам и уровням критичности
• подавление уведомлений во время известных инцидентов
• настройка повторных отправок и эскалаций

Как работает связка с Prometheus

1. В Prometheus создаются alert rules.
2. При срабатывании правило отправляет событие в Alertmanager.
3. Alertmanager проверяет маршруты, inhibition, silences.
4. Уведомление уходит в нужный receiver.

Базовая структура конфигурации

Ключевые блоки в alertmanager.yml:

• route — логика маршрутизации
• receivers — куда отправлять уведомления
• group_by — по каким меткам объединять алерты
• group_wait — сколько ждать перед первой отправкой
• group_interval — интервал для новых алертов в группе
• repeat_interval — когда повторять уведомление

Пример логики:

• critical-алерты → дежурной команде в Telegram/Slack
• warning → в общий канал мониторинга
• алерты по БД → только команде DBA

Практические рекомендации

• ✅ Используйте метки severity, team, service, env — без них маршрутизация быстро превращается в хаос.
• ✅ Разделяйте warning и critical: не все проблемы должны будить ночью.
• ✅ Настраивайте group_by, чтобы не получать 50 сообщений по одному инциденту.
• ✅ Добавляйте silences для плановых работ и деплоев.
• ✅ Используйте inhibition rules, чтобы вторичные алерты не дублировали основной. Пример: если упал сервер целиком, можно подавить алерты отдельных сервисов на нем.

Частые ошибки

• слишком общие маршруты без разделения по severity
• отсутствие grouping — как итог, спам в чатах
• нет repeat-настроек, и критичный алерт теряется
• не настроены шаблоны сообщений, поэтому уведомления неинформативны
• нет тестирования правил после изменений

Что должно быть в хорошем уведомлении

• что сломалось
• где сломалось
• насколько критично
• когда началось
• ссылка на дашборд, runbook или график

Пример полезного сообщения:

[CRITICAL] API latency > 2s в prod, service=payments, instance=api-03

Итог

Alertmanager — это не просто «доставка алертов», а центр управления инцидентами в мониторинге. Грамотная настройка маршрутов, группировки и подавления шума помогает команде быстрее реагировать на реальные проблемы и не выгорать от бесконечных уведомлений 🔍🛠️

Подборку каналов про IT — с DevOps, мониторингом, SRE и инфраструктурой — стоит посмотреть отдельно 👀

🗣 Подборки каналов 🧠 Каталог ботов и приложений 🗺 Навигация