Налаштування алертів БД: 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 дні. Отримайте консультацію безкоштовно.

Типові помилки при самостійному налаштуванні

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

Один запобіглий інцидент економить значно. Інвестиція в налаштування моніторингу окупається за 1-2 місяці. Замовте налаштування алертів БД і забудьте про несподівані збої.