PG Audit

Реальный прогон аудита PostgreSQL

Тестовый стенд: PostgreSQL 16.14, база pg_audit_test 207 МБ. Один цикл: snapshot → отчёт → применение remediation.sql → новый snapshot → сравнение. Пять файлов — можно открыть, посмотреть, скачать. Не UI-имитация.

11
findings в отчёте «ДО»
2 → 0
Critical после SQL
5 / 0
исправлено / новых
9
unique rules triggered
1

ДО

Snapshot и отчёт до применения remediation.sql

JSON · 5.4 KB
audit_data_20260710_144312.json

Сырой snapshot — что собирает Collector

Исходные диагностические данные, которые PG Audit Collector собирает на сервере PostgreSQL. Один файл — ничего больше не передаётся.

PostgreSQL 16.14 · база pg_audit_test · 207 MB · uptime 0.6h

Открыть snapshot
HTML · 39 KB
demo-report-before.html

Полный отчёт «ДО»

Standalone HTML-отчёт: 11 findings (2 Critical, 3 High, 3 Medium, 1 Low, 2 Info), executive summary, Quick Wins, приоритетный план исправлений с оценкой рисков.

Открывается в любом браузере · без зависимостей

Открыть отчёт «ДО»
2

Применение

Готовый SQL под вашу версию PostgreSQL

SQL · 5.4 KB
demo-remediation.sql

Готовый remediation.sql — что получает клиент для исправления

SQL сгруппирован по приоритетам: MUST_FIX (Critical), SHOULD_FIX (High/Medium), OBSERVE. Каждая команда снабжена confidence, risk и комментарием. Idempotent — можно применять многократно. Не выполняется автоматически — клиент сам решает, что и когда применять.

11 команд · 3 уровня риска (LOW / MEDIUM / HIGH) · staging рекомендован

Открыть remediation.sql
3

ПОСЛЕ

Новый snapshot, новый отчёт и сравнение

HTML · 27 KB
demo-report-after.html

Отчёт «ПОСЛЕ» — тот же стенд через 18 минут

5 findings (0 Critical, 2 High, 1 Medium, 1 Low, 2 Info). Подтверждение: Critical устранены, мёртвые кортежи очищены, autovacuum включён, work_mem увеличен.

Uptime 0.9h · тот же сервер, та же база

Открыть отчёт «ПОСЛЕ»
HTML · 4.8 KB
demo-report-comparison.html

Diff «до / после» — для руководства

Сравнение двух snapshot: 5 исправлено, 0 новых проблем. Конкретный список: PK восстановлен, autovacuum включён, dead tuples очищены, work_mem увеличен, log_min_duration_statement установлен.

Идеально для отчёта CTO/CEO · standalone HTML

Открыть сравнение

Что было найдено и исправлено в этом прогоне

Три ключевых findings из отчёта «ДО» — с реальными числами

CRITICALconf: 99%
Нет Primary Key
pgbench_accounts · 1 000 000 строк
✓ Исправлено в ПОСЛЕ
CRITICALconf: 99%
Autovacuum off
Database-level · current_setting = 'off'
✓ Исправлено в ПОСЛЕ
HIGHconf: 95%
Dead tuples 51.7%
pgbench_accounts · 516 957 dead
✓ Исправлено в ПОСЛЕ
HIGHconf: 99%
Нет PK (tellers)
pgbench_tellers · 100 строк
✓ Исправлено в ПОСЛЕ
MEDIUMconf: 95%
work_mem слишком мал
Database · формула work_mem × max_connections ≤ 6 GB
✓ Исправлено в ПОСЛЕ
MEDIUMconf: 95%
log_min_duration_statement
Database · медленные запросы не логируются
✓ Исправлено в ПОСЛЕ

Хотите такой прогон по вашей базе?

Сначала бесплатный чек в браузере по вашему audit_data.json. Затем полный отчёт + готовый remediation.sql за 30 000 ₽. После применения — Repeat Check со сравнением «до / после» за 20 000 ₽.

Бесплатный чекПолучить план — 30 000 ₽
Важное замечание про uptime. Demo snapshot собран на тестовой базе с uptime 0.6h. В отчёте есть предупреждение: статистические выводы (Cache Hit Ratio, dead tuples, unused indexes) на коротком uptime имеют пометку LOW CONFIDENCE и требуют подтверждения. Детерминированные правила (Primary Key, Foreign Key, autovacuum on/off) — не зависят от uptime и являются достоверными всегда. В реальном production-снапшоте с uptime 24h+ статистических данных будет больше, а confidence — выше.