Мониторинг баз данных

Netflix в 2011 году имел 7-часовой outage из-за проблем с БД. После: построили Chaos Engineering практику и comprehensive monitoring. Сегодня их observability платформа мониторит миллионы метрик в реальном времени и автоматически откатывает деплои при аномалиях. Правильный мониторинг = разница между 7 часами и 7 минутами.

• **Cloudflare**: автоматический алерт при cache hit rate < 99% на PostgreSQL - инцидент поднимается автоматически
• **GitHub**: pg_stat_statements для автоматического сравнения производительности запросов до и после деплоя
• **Shopify**: 200+ Grafana дашбордов для PostgreSQL мониторинга в продакшне

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

Мониторинг БД не ограничивается CPU и RAM. Критические DB-специфичные метрики: query latency (P50/P95/P99), connections (active/idle/waiting), cache hit rate, replication lag, lock wait time, autovacuum status. Эти метрики часто предупреждают о проблемах за 30-60 минут до деградации.

• **Latency P99**: медиана скрывает проблемы у 1% самых медленных запросов (worst experience)
• **Connections**: active vs idle in transaction; пул исчерпан = новые запросы не могут подключиться
• **Cache hit rate**: <90% = индексы не помещаются в shared_buffers или много sequential scans
• **Replication lag**: задержка replica от master; растущий lag = проблема с репликацией
• **Deadlocks**: частые deadlocks = проблема с порядком acquire locks в коде

Four Golden Signals (Google SRE): Latency, Traffic, Errors, Saturation. Для БД: Latency (P99 query time), Traffic (queries/sec), Errors (failed queries, deadlocks), Saturation (connections/max_connections, disk utilization).

PostgreSQL pg_stat_* views

PostgreSQL предоставляет богатый набор системных views для мониторинга. pg_stat_activity - текущие соединения и запросы. pg_stat_statements - статистика всех запросов. pg_stat_bgwriter - checkpoint и buffer activity. pg_stat_replication - состояние replicas.

pg_stat_statements - обязательный extension. Включить: shared_preload_libraries = 'pg_stat_statements'. Показывает: каждый уникальный query pattern, количество вызовов, суммарное/среднее время. Cloudflare и GitHub используют pg_stat_statements для автоматического выявления регрессий производительности после деплоя.

Slow Query Log

Slow query log фиксирует запросы дольше threshold. PostgreSQL: log_min_duration_statement = 1000 (1 секунда). MySQL: slow_query_log = ON, long_query_time = 1. Анализ через pgBadger (PostgreSQL) или pt-query-digest (MySQL/Percona).

auto_explain extension: автоматически логирует план запросов для slow queries без явного EXPLAIN. Включить: shared_preload_libraries = 'auto_explain', auto_explain.log_min_duration = 1000. Ideal для production диагностики без изменения кода.

Grafana и мониторинг в продакшне

Стек мониторинга БД в 2024: PostgreSQL exporter (prometheus) -> Prometheus -> Grafana. postgres_exporter собирает метрики из pg_stat_* views и экспортирует в Prometheus формат. Готовые Grafana дашборды: PostgreSQL Overview (dashboard #9628), PgBouncer metrics.

Datadog, New Relic, AWS CloudWatch - managed alternatives к self-hosted Grafana+Prometheus. AWS RDS Performance Insights: детальный query-level мониторинг из коробки. Показывает top SQL, wait events, database load - без дополнительной настройки.

Alerting и SLO

Алерты должны быть actionable: при получении алерта должно быть ясно что делать. SLO (Service Level Objective) - внутренняя цель надёжности. SLA - обязательство перед клиентами. Типичные DB SLO: P99 latency < 100ms, error rate < 0.1%, availability > 99.9%.

Error Budget: если SLO = 99.9% availability, error budget = 0.1% = 43.8 минут простоя в месяц. При превышении error budget - freeze новых фич, работать только над reliability. Концепция Google SRE.

Итоги

• **Four Golden Signals**: Latency (P99!), Traffic, Errors, Saturation - база для любого DB мониторинга
• **pg_stat_views**: pg_stat_statements для топ дорогих запросов, pg_stat_user_tables для seq scan анализа
• **Actionable alerts**: алерт должен содержать что случилось, почему важно, что делать

Связанные темы

Мониторинг связан с оптимизацией и эксплуатацией:

• Connection Pooling — Мониторинг connections/max_connections - ключевая метрика для pooler настройки
• Резервное копирование — Мониторить: последний успешный backup, archive lag, размер WAL очереди
• Оптимизация запросов — Slow query log и pg_stat_statements - входные данные для query optimization

Вопросы для размышления

• Как настроить мониторинг чтобы предупреждение о проблеме приходило за 30 минут до деградации пользовательского опыта?
• P99 latency резко вырос после деплоя. Какой порядок диагностики?
• Разница между метрикой и алертом. Когда метрику стоит превращать в алерт?

Связанные уроки

• sd-22-observability