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

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.