О продукте PG Audit
Специализированный инструмент аудита PostgreSQL. Не «универсальный мониторинг», не «AI-аналитика» — узкий, технически обоснованный набор проверок, каждая из которых опирается на конкретный источник.
Что такое PG Audit
PG Audit — это связка из двух компонентов. Collector — Python-скрипт с открытым кодом, который запускается локально на сервере PostgreSQL, подключается read-only и собирает технические метаданные в один JSON-файл. Analyzer — закрытый анализатор, который превращает JSON в HTML-отчёт и готовый remediation.sql под конкретную версию PostgreSQL.
Принципиальное отличие от «обычного DBA-аудита»: данные не покидают инфраструктуру клиента. Collector работает локально, JSON можно проанализировать в браузере (через Express Audit — без отправки на сервер) или передать только диагностический файл — без доступа к БД, без пароля, без содержимого таблиц.
Состав продукта
- Collector — Python, open-source на GitHub
- JSON-формат — стандартизованный, можно анализировать любыми инструментами
- Express Audit — браузерный анализатор, JSON не покидает клиент
- Full Audit Analyzer — полный анализ с генерацией remediation.sql
- Repeat Check — отдельный режим для сравнения «до / после»
На чём основаны правила
Каждое из 24+ правил аудита опирается на конкретный источник — официальную документацию PostgreSQL, wiki, рекомендации postgresql.org или production-практику. Никаких «авторских эвристик» без обоснования.
PostgreSQL Official Documentation
Разделы Maintenance, Routine Vacuuming, Routine Database Indexing, Performance Tips. Базовые пороги и рекомендации по work_mem, autovacuum, индексам.
postgresql.org/docsPostgreSQL Wiki
Разделы Performance Insulation, SlowQueryQuestions, Diagnostics. Кумулятивный опыт сообщества postgresql-hackers и DBA production-кластеров.
wiki.postgresql.orgpg_stat_user_tables / pg_stat_user_indexes
Системные представления PostgreSQL. Правила dead tuples, unused indexes, seq scan — напрямую из этих catalog views с интерпретацией порогов.
Monitoring StatisticsProduction practice
Полевой опыт администрирования PostgreSQL в B2B-проектах: что реально ломается на production, какие пороги критичны, какие рекомендации дают максимальный эффект.
Реальный кейс на demoКак верифицируется корректность
Каждое правило в аудиторе размечено по confidence — степени уверенности в finding. Confidence 99% получают детерминированные правила (нет PK, autovacuum off — это можно проверить однозначно). Confidence 60-95% получают статистические правила, зависящие от uptime и нагрузки (dead tuples, cache hit ratio, unused indexes).
Если uptime БД меньше 24 часов, все статистические finding получают пометку LOW CONFIDENCE и предупреждение «требует подтверждения». Это честно: на коротком uptime статистика ещё не накопилась, и выводы могут быть некорректными. Детерминированные правила остаются достоверными всегда.
Примеры confidence
- Нет Primary Key99% · deterministic
- Autovacuum off99% · deterministic
- Dead tuples 51.7%95% · statistical
- Cache Hit Ratio 82%60% · uptime-dependent
- Unused index95% · statistical
- Seq scan на большой таблице95% · statistical
Severity, приоритеты и зоны риска
Базовая целостность БД нарушена. Нет PK на больших таблицах, autovacuum off, checksum failures. Действовать сразу.
Существенный impact на производительность. Dead tuples, missing indexes на больших таблицах, work_mem критично мал. Планировать в этом спринте.
Не срочно, но стоит иметь в виду. Логирование, настройки таймаутов, кандидаты на партиционирование. Можно в backlog.
Зоны риска SQL-команд
CREATE INDEX CONCURRENTLY, ALTER SYSTEM + pg_reload_conf. Можно применять сразу на production.
Изменение настроек work_mem, log_min_duration_statement. Сначала staging, проверка под нагрузкой.
Изменение структуры таблиц, удаление индексов. Только staging + резервная копия + окно обслуживания.
Поддерживаемые версии PostgreSQL
Правила аудитора используют только catalog views и settings, доступные во всех перечисленных версиях. Если какая-то проверка не применима к конкретной версии (например, checksums появились позже), она пропускается с пометкой N/A — без ложных срабатываний.
Где работает Collector
Collector — Python-скрипт с минимальными зависимостями (только psycopg2). Запускается где угодно, где есть Python 3.8+ и сетевой доступ к PostgreSQL через Unix-socket или TCP.
Не требует установки systemd-unit, не требует root, не модифицирует систему. Можно запускать из любой директории, можно одноразово — результат всегда один JSON-файл.
Поддерживаемые ОС
- Linux — Ubuntu, Debian, CentOS, RHEL, Alpine (любая дистрибуция с Python 3.8+)
- macOS — для локальной разработки и тестирования
- Windows — через WSL или нативный Python (с psycopg2-binary)
- Docker — Collector запускается внутри контейнера PG или рядом
- Cloud — AWS RDS, Cloud SQL, Azure, Yandex Managed PostgreSQL (через SSL)
Кто делает PG Audit
PG Audit разрабатывает небольшая команда PostgreSQL-инженеров с production-опытом в B2B-проектах. Мы не маркетинговое агентство и не «AI-стартап» — мы инженеры, которые устали видеть одни и те же проблемы на разных проектах и решили стандартизировать их обнаружение.
Сам продукт создан по принципу «как бы я хотел, чтобы аудитор работал с моей production-базой»: без доступа к данным, без пароля, без удалённого подключения, с открытым кодом коллектора, который можно прочитать и проверить перед запуском.
Принципы
- Безопасность прежде всего. Данные не покидают клиента. Это не маркетинг — это архитектура.
- Открытый коллектор. Код Collector на GitHub. Можно ревьюить перед запуском на production.
- Честный confidence. Если данных недостаточно — говорим LOW CONFIDENCE, а не делаем вид, что уверены.
- Измеримый результат. Repeat Check — не допродажа, а доказательство, что рекомендации сработали.
- SQL не выполняется автоматически. Клиент сам контролирует применение. Мы только рекомендуем.
Посмотрите, как это работает на реальной базе
Полный цикл аудита: snapshot → отчёт → SQL → повтор → сравнение. Все файлы открыты для просмотра и скачивания.