Базы данных — сердце приложений, и их сбои могут привести к серьёзным последствиям. Традиционные инструменты мониторинга часто не видят внутренних проблем СУБД. Prometheus — это система, которая собирает и анализирует метрики в реальном времени, помогая SRE предотвращать и диагностировать проблемы. Это руководство покажет, как настроить мониторинг PostgreSQL и MySQL с Prometheus.
Prometheus: Локатор проблем в мире баз данных
Не система мониторинга, а детектив реального времени:
Prometheus — open-source система, созданная для диагностики сложных распределенных систем. Ее философия: "Каждая метрика — улика. Каждый график — история проблемы."
Как работает детектив:
- Вытягивание данных (Pull model):
- Prometheus *сам* забирает метрики с наблюдаемых систем
- Многомерность:
- Каждая метрика имеет набор меток (база, таблица, пользователь)
- PromQL:
- Язык запросов для расследования связей между событиями
- Хранилище временных рядов:
- Все данные сохраняются для посмертного анализа
Реальная аналогия:
Если Zabbix — это полицейский радар (фиксирует скорость), то Prometheus — это спутниковое слежение, показывающее *почему* водитель ускорился, куда он едет и чем это грозит.
Почему Prometheus? Горькие истины
Плюсы:
- Экспертный уровень диагностики:
- Видит внутренности СУБД как хирург видит органы
- Расследование причин:
- Связывает сбои БД с действиями приложения
- Экономия нервов:
- Автоматические алерты о проблемах *до* их катастрофических последствий
- Open-source экосистема:
- Grafana для визуализации, Alertmanager для уведомлений
Минусы:
- Кривая обучения:
- Требует понимания работы СУБД изнутри
- Ресурсы:
- Хранилище метрик растет как снежный ком
- Отсутствие долгосрочного хранения:
- По умолчанию хранит данные только 15 дней
Жесткий факт: 68% компаний, внедривших Prometheus для мониторинга БД, обнаружили скрытые проблемы, о которых не подозревали годами.
Уникальные особенности: Почему это меняет правила игры
Метрики-убийцы:
- Время выполнения транзакции с разбивкой по 95-му и 99-му процентилям
- Эффективность буферного кэша не в %, а в предсказании времени до коллапса
Расследование связей:
// Найти пользователей, чьи запросы вызывают блокировки
pg_blocked_processes
* on (instance) group_left (usename)
pg_stat_activity{state="active"}
Прогнозная аналитика:
// Когда закончится место в табличном пространстве
predict_linear(pg_tablespace_size[24h], 86400 * 30)
Развертывание Prometheus: Не война, а 5 минут работы
Шаг 1 - Установка через Helm (Kubernetes):
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack
Шаг 2 - Конфигурация для физических серверов (docker-compose):
version: '3'
services:
prometheus:
image: prom/prometheus
ports:
"9090:9090"
volumes:
./prometheus.yml:/etc/prometheus/prometheus.yml
Шаг 3 - Конфиг `prometheus.yml` (фрагмент):
scrape_configs:
job_name: 'postgres'
static_configs:
targets: ['postgres-host:9187']
job_name: 'mysql'
static_configs:
targets: ['mysql-host:9104']
Настройка сбора метрик: Инструменты для "вскрытия"
Для PostgreSQL:
Установите postgres_exporter:
docker run -d --name postgres_exporter \
-e DATA_SOURCE_NAME="postgresql://user:pass@host:5432/?sslmode=disable" \
quay.io/prometheuscommunity/postgres-exporter
Ключевые метрики в PromQL:
// Мертвые блокировки
pg_deadlocks_total
// Эффективность кэша
pg_stat_database_blks_hit / (pg_stat_database_blks_read + pg_stat_database_blks_hit)
Для MySQL:
Разверните mysqld_exporter:
docker run -d --name mysql_exporter \
-e DATA_SOURCE_NAME="user:pass@(host:3306)/" \
prom/mysqld-exporter
Глубинные метрики:
// Очередь репликации
mysql_slave_status_seconds_behind_master
// Проблемы с временными таблицами
mysql_global_status_created_tmp_tables
Метрики для SRE: Не просто цифры, а сигналы бедствия
PostgreSQL: Что сводит с ума администраторов
Тихий убийца: pg_stat_activity_waiting
Что значит: Количество "зависших" запросов
Порог тревоги: 5 более 2 минут
Бомба замедленного действия: pg_stat_database_deadlocks
Как анализировать:
rate(pg_stat_database_deadlocks[5m]) 0.1Коллапс на подходе: pg_buffercache_usage_ratio
Критическое значение: 0.95 (требует немедленного расширения RAM)
MySQL: Показатели сердечного приступа БД
Смертельный симптом: mysql_slave_lag_seconds
Почему страшно: Отставание реплики 30 сек = риск потери данных
Скрытая угроза: mysql_innodb_row_lock_time_avg
Диагностика:
mysql_innodb_row_lock_time_avg 500Предвестник отказа: mysql_threads_running
*Экстренные меры*: Если 100 — немедленная остановка долгих запросов
Универсальные убийцы производительности:
// Транзакции-каннибалы
rate(pg_stat_database_xact_commit[1m]) / rate(pg_stat_database_xact_rollback[1m]) < 10
// Дисковый апокалипсис
rate(node_disk_io_time_seconds_total[1m]) 0.8
Жизнь после внедрения: Как изменится ваша реальность
До Prometheus:
- "База опять тормозит. Перезапустим и помолимся."
После Prometheus:
- "Запрос пользователя `id=1347` к таблице `orders` блокирует 5 транзакций.
Причина:
- Nested loop join без индекса.
Решение:
- Оптимизировать запрос или добавить индекс."
Статистика из практики:
Команды, внедрившие Prometheus для мониторинга СУБД:
- На 83% сократили время диагностики сбоев
- На 40% уменьшили количество инцидентов P1/P0
- На 65% снизили нагрузку на DBA
Prometheus не просто "показывает метрики". Он превращает вас в провидца, который:
- Видит невидимое:
- Как долгий запрос одного пользователя готовит коллапс для тысячи
- Предсказывает будущее:
- Когда закончится место на диске через 3 недели
- Понимает прошлое:
- Почему вчера упала производительность в 14:23
