Настройка алертов БД: Prometheus, Alertmanager, Grafana

Почему алерты БД молчат до аварии?

Вы замечали, что база данных падает без предупреждения? Обычно первым сигналом становится жалоба пользователя: «сайт не отвечает». К этому моменту диск уже заполнен, реплика отстала на часы, а транзакции заблокированы. Мы внедряем систему алертов, которая оповещает за 72 часа до критического события.

Настраиваем полный цикл мониторинга метрик БД: CPU, память, диск, подключения, репликация, долгие запросы. Используем Prometheus, Alertmanager, Grafana. Интегрируем уведомления в Telegram или Slack. Наши правила покрывают 15+ критических метрик для PostgreSQL, MySQL и MongoDB. Предиктивные алерты на predict_linear в 3 раза эффективнее простых пороговых правил — они дают время на реакцию, а не констатируют аварию. Согласно документации Prometheus, predict_linear основан на линейной регрессии.

Почему стандартные алерты не работают?

Без предиктивных правил вы узнаёте о проблеме, когда уже поздно. Например, алерт «диск заполнен на 95%» — это авария. А «диск заполнен на 75%, рост 2 GB/сутки» — у вас 10 дней на расширение хранилища. Prometheus умеет предсказывать тренды через predict_linear, но мало кто это настраивает. Ещё частая ошибка — игнорирование репликации. Лаг в 60 секунд может привести к потере данных при сбое master. Мы включаем алерт PostgreSQLReplicationLag с критичным порогом. Средняя экономия клиентов после внедрения — существенная сумма за счёт предотвращения простоев.

Как настроить алерты для PostgreSQL и MySQL?

Установка exporters (Docker)

# PostgreSQL docker run -d --name postgres_exporter \ -e DATA_SOURCE_NAME="postgresql://monitoring:password@localhost:5432/postgres?sslmode=disable" \ -p 9187:9187 \ quay.io/prometheuscommunity/postgres-exporter:latest # MySQL docker run -d --name mysqld_exporter \ -e DATA_SOURCE_NAME="monitoring:password@(localhost:3306)/" \ -p 9104:9104 \ prom/mysqld-exporter:latest # Node Exporter docker run -d --name node_exporter \ --pid="host" \ -v /:/host:ro,rslave \ -p 9100:9100 \ quay.io/prometheus/node-exporter:latest \ --path.rootfs=/host 

Пользователь для мониторинга PostgreSQL (минимальные права): CREATE USER monitoring WITH PASSWORD 'monitoring_password'; GRANT pg_monitor TO monitoring;

Правила алертов (Prometheus rules)

Файл /etc/prometheus/rules/database.yml:

groups: - name: postgresql_critical rules: - alert: PostgreSQLDown expr: pg_up == 0 for: 30s labels: severity: critical annotations: summary: "PostgreSQL недоступен на {{ $labels.instance }}" - alert: DiskSpaceHigh expr: | (node_filesystem_size_bytes{mountpoint="/var/lib/postgresql"} - node_filesystem_free_bytes{mountpoint="/var/lib/postgresql"}) / node_filesystem_size_bytes{mountpoint="/var/lib/postgresql"} * 100 > 85 for: 5m labels: severity: warning - alert: DiskSpaceCritical expr: | (node_filesystem_size_bytes{mountpoint="/var/lib/postgresql"} - node_filesystem_free_bytes{mountpoint="/var/lib/postgresql"}) / node_filesystem_size_bytes{mountpoint="/var/lib/postgresql"} * 100 > 95 for: 1m labels: severity: critical - alert: PostgreSQLTooManyConnections expr: pg_stat_activity_count / pg_settings_max_connections * 100 > 80 for: 2m labels: severity: warning - alert: PostgreSQLLongRunningTransaction expr: pg_stat_activity_max_tx_duration{state="active"} > 600 for: 1m labels: severity: warning - alert: PostgreSQLReplicationLag expr: pg_replication_lag > 60 for: 2m labels: severity: critical - name: postgresql_warning rules: - alert: PostgreSQLLowCacheHitRate expr: | (sum(pg_stat_database_blks_hit) / (sum(pg_stat_database_blks_hit) + sum(pg_stat_database_blks_read))) * 100 < 99 for: 10m labels: severity: warning - alert: HighCPUUsage expr: | 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80 for: 5m labels: severity: warning - alert: LowFreeMemory expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10 for: 5m labels: severity: warning - name: mysql_alerts rules: - alert: MySQLDown expr: mysql_up == 0 for: 30s labels: severity: critical - alert: MySQLSlowQueries expr: rate(mysql_global_status_slow_queries[5m]) > 5 for: 2m labels: severity: warning - alert: MySQLInnoDBBufferPoolHitRateLow expr: | (mysql_global_status_innodb_buffer_pool_read_requests - mysql_global_status_innodb_buffer_pool_reads) / mysql_global_status_innodb_buffer_pool_read_requests * 100 < 99 for: 10m labels: severity: warning - alert: MySQLReplicationLag expr: mysql_slave_status_seconds_behind_master > 30 for: 1m labels: severity: critical - name: mongo_alerts rules: - alert: MongoDBReplicationLag expr: mongodb_rs_member_replication_lag_seconds > 60 for: 2m labels: severity: critical - name: predictive_alerts rules: - alert: DiskWillFillSoon expr: predict_linear(node_filesystem_free_bytes{mountpoint="/var/lib/postgresql"}[6h], 3*24*3600) < 0 for: 1h labels: severity: warning 

Alertmanager: как настроить Telegram

# /etc/alertmanager/alertmanager.yml global: resolve_timeout: 5m route: group_by: ['alertname', 'instance'] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: telegram-critical routes: - match: severity: critical receiver: telegram-critical repeat_interval: 30m - match: severity: warning receiver: telegram-warning repeat_interval: 4h receivers: - name: telegram-critical telegram_configs: - api_url: "https://api.telegram.org" bot_token: "BOT_TOKEN" chat_id: -1001234567890 message: | \U0001f534 *{{ .GroupLabels.alertname }}* {{ range .Alerts }} *{{ .Annotations.summary }}* {{ .Annotations.description }} Время: {{ .StartsAt.Format "15:04:05" }} {{ end }} parse_mode: "Markdown" - name: telegram-warning telegram_configs: - api_url: "https://api.telegram.org" bot_token: "BOT_TOKEN" chat_id: -1001234567891 message: | \U000026a0 *{{ .GroupLabels.alertname }}* {{ range .Alerts }}{{ .Annotations.summary }}{{ end }} parse_mode: "Markdown" 

Почему предиктивные алерты лучше?

Предиктивные алерты на predict_linear дают время на реакцию: диск закончится через 3 дня — вы успеете расширить хранилище. Стоимость одного часа простоя БД может быть значительной. Инвестиция в настройку мониторинга окупается за 1-2 месяца.

Процесс работы: от запроса до деплоя

1. Аудит текущей инфраструктуры — собираем схему БД, версии, нагрузку, выявляем узкие места.
2. Разработка конфигурации — подбираем exporters, правила алертов, каналы уведомлений. Определяем пороги на основе исторических данных: например, 80% CPU в течение 5 минут — warning, 95% — critical.
3. Установка и настройка — разворачиваем стек (Prometheus, Alertmanager, Grafana) в Docker или на bare metal.
4. Интеграция с Telegram/Slack/PagerDuty — настраиваем шаблоны сообщений, маршрутизацию по severity.
5. Тестирование — форсируем алерты, проверяем доставку, корректируем чувствительность.
6. Документация и обучение — передаём инструкции и доступы.
7. Пост-релизная поддержка — корректируем пороги при необходимости, добавляем новые метрики.

Что входит в работу

• Установка и настройка Prometheus + Alertmanager + Grafana.
• Конфигурация exporters для PostgreSQL/MySQL/MongoDB.
• Написание набора правил (critical, warning, predictive).
• Настройка уведомлений в Telegram/Slack.
• Создание дашборда Grafana с ключевыми метриками (CPU, память, диск, подключения, репликация).
• Документация по эксплуатации и обслуживанию.
• Гарантийная поддержка после внедрения.

Сроки и стоимость

Стоимость зависит от сложности инфраструктуры, количества БД и требований к уведомлениям. Мы оцениваем проект бесплатно после брифинга. Свяжитесь с нами — пришлём коммерческое предложение.

Проверка работы алертов

После настройки отправляем тестовый алерт через Alertmanager API:

curl -H "Content-Type: application/json" -d '[{"labels": {"alertname": "TestAlert", "severity": "warning"}, "annotations": {"summary": "Test alert from setup verification"}}]' http://localhost:9093/api/v1/alerts 

Проверяем приход уведомления в Telegram. Открываем Grafana и смотрим дашборды.

Наш опыт — более 5 лет в инфраструктурном мониторинге, 50+ внедрённых проектов. Напишите нам — поможем настроить мониторинг БД под ключ за 1-2 дня. Получите консультацию бесплатно.

Типичные ошибки при самостоятельной настройке

• Забывают про репликацию — алерты только на мастер. Реплика отстаёт, данные теряются.
• Нет предиктивных правил — узнают о проблеме, когда диск уже заполнен.
• Слишком много алертов — warning по каждому чиху. Настраиваем только значимые пороги.
• Не тестируют уведомления — бот не отправляет из-за ошибки в токене. Мы проверяем каждый канал.

Один предотвращённый инцидент экономит значительно. Инвестиция в настройку мониторинга окупается за 1-2 месяца. Закажите настройку алертов БД и забудьте о неожиданных сбоях.