Мониторинг производительности PostgreSQL и MySQL

Базы данных часто становятся узким местом системы. Даже при нормальной нагрузке именно DB может упираться в CPU, диск или блокировки.

Чтобы этого избежать, нужен системный мониторинг. В этой статье разберём, какие метрики важно отслеживать и как настроить сбор через exporters для Prometheus.

Почему мониторинг БД важен

Проблемы с базой редко проявляются сразу как падение сервиса. Чаще это:

• рост latency запросов
• периодические таймауты
• деградация под нагрузкой

Без метрик вы увидите только симптомы, но не причину.

Ключевые метрики PostgreSQL

1. Connections

• pg_stat_activity
• количество активных соединений
• idle / idle in transaction

Важно отслеживать:

• приближение к max_connections
• зависшие транзакции

2. Locks

• блокировки таблиц и строк

Проблемы:

• long-running transactions
• deadlocks

3. Query performance

• slow queries
• execution time
• количество запросов

Полезно:

• включить pg_stat_statements

4. Buffers и cache hit ratio

• shared_buffers
• cache hit ratio

Формула:

• чем выше hit ratio, тем меньше обращений к диску

5. WAL (Write-Ahead Log)

• скорость генерации WAL
• задержки репликации

Ключевые метрики MySQL

1. Connections

• Threads_connected
• Threads_running

2. Slow queries

• slow query log
• время выполнения

3. InnoDB metrics

• buffer pool usage
• buffer pool hit ratio

4. Locks и contention

• row locks
• ожидания

5. Disk I/O

• reads/writes
• fsync latency

Exporters и настройка Prometheus

Чтобы собирать метрики, используются exporters — небольшие сервисы, которые конвертируют метрики БД в формат Prometheus.

У нас в блоге уже есть подробная статья об использовании exporters.

PostgreSQL exporter

Популярный вариант: postgres_exporter

Запуск:

docker run -d \
  -e DATA_SOURCE_NAME="postgresql://user:pass@localhost:5432/db?sslmode=disable" \
  -p 9187:9187 \
  prometheuscommunity/postgres-exporter

Метрики доступны:

http://localhost:9187/metrics

MySQL exporter

docker run -d \
  -e DATA_SOURCE_NAME="user:pass@(localhost:3306)/" \
  -p 9104:9104 \
  prom/mysqld-exporter

Добавляем в prometheus.yml:

scrape_configs:
  - job_name: 'postgres'
    static_configs:
      - targets: ['localhost:9187']
 
  - job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']

Полезные алерты и визуализация

PostgreSQL

• слишком много соединений:

pg_stat_activity_count > max_connections * 0.9

• долгие запросы:

pg_stat_activity_max_tx_duration > 60

MySQL

• высокий CPU:

rate(mysql_global_status_queries[1m]) > threshold

• заполнение buffer pool:

mysql_global_status_innodb_buffer_pool_pages_free < threshold

Для визуализации используются готовые дашборды:

• PostgreSQL dashboard
• MySQL dashboard

Они показывают:

• нагрузку
• запросы
• блокировки
• I/O

Statuser

Хотя Statuser не является системой мониторинга баз данных, его можно использовать как дополнительный слой наблюдаемости.

Например:

• отслеживать доступность API, зависящего от БД
• фиксировать деградации (рост времени ответа)
• использовать вебхуки для уведомлений при проблемах

Таким образом, Statuser помогает увидеть проблему снаружи (симптомы), а Prometheus + exporters — внутри (причину).

Практические советы

1. Не мониторьте всё подряд
   • выберите ключевые метрики
2. Настройте алерты
   • заранее определите пороги
3. Используйте профилирование
   • PostgreSQL: pg_stat_statements
   • MySQL: slow query log
4. Следите за трендами
   • рост нагрузки важнее разовых пиков

Итог

Мониторинг БД — это основа стабильности системы.

• PostgreSQL и MySQL имеют разные метрики, но схожие проблемы
• exporters позволяют интегрировать их в Prometheus
• Grafana даёт визуализацию

А внешние инструменты вроде Statuser помогают увидеть влияние проблем на пользователей.

Комбинируя эти подходы, можно быстро находить и устранять узкие места в базе данных.