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