Хранение данных (retention)

Новое в 2026.1.1

Механизм retention периодически удаляет устаревшие данные из базы данных и файлового хранилища. По умолчанию механизм выключен — без него объём данных будет неограниченно расти. Для production-окружений рекомендуется включить retention с параметрами по умолчанию.

Очистка выполняется фоновыми задачами по расписанию (по умолчанию — ежедневно с 04:10 до 05:00 по локальному времени сервера). Задачи очистки запускаются только при включённом retention; по умолчанию функция выключена.

Как очистка влияет на место на диске - см. Место на диске после очистки.

Параметры конфигурации

Параметр	Docker (`user.ini`)	Kubernetes (`values.yaml`)	По умолчанию	Описание
Включение	`v.common_config.retention.enabled`	`commonConfig.retention.enabled`	`off`	Мастер-переключатель механизма retention
События	`v.common_config.retention.event_days`	`commonConfig.retention.eventDays`	`14`	Записи событий
Агрегаты по дням	`v.common_config.retention.aggregated_data_by_day_days`	`commonConfig.retention.aggregatedDataByDayDays`	`32`	Записи `aggregated_data_by_day`
Агрегаты по неделям	`v.common_config.retention.aggregated_data_by_week_days`	`commonConfig.retention.aggregatedDataByWeekDays`	`378`	Записи `aggregated_data_by_week`
Фоновые задачи	`v.common_config.retention.background_task_days`	`commonConfig.retention.backgroundTaskDays`	`100`	Записи фоновых задач
Scan pipelines	`v.common_config.retention.scan_pipeline_days`	`commonConfig.retention.scanPipelineDays`	`380`	Завершённые scan pipelines
Findings	`v.common_config.retention.finding_num_per_issue`	`commonConfig.retention.findingNumPerIssue`	`100`	Лишние findings на issue — остаются только N последних
Временные файлы оркестрации	`v.common_config.retention.orchestration_tmp_files_days`	`commonConfig.retention.orchestrationTmpFilesDays`	`7`	Архивы репозиториев, результаты сканов, временные конфиги сканеров
Загруженные файлы сканов	`v.common_config.retention.scan_upload_files_days`	`commonConfig.retention.scanUploadFilesDays`	`381`	Файлы, загруженные через scan upload

Значения в колонке «По умолчанию» рассчитаны на типичное production-окружение — рекомендуем включить retention с ними, не переопределяя отдельные параметры. Меняйте сроки хранения только при явной необходимости: требования комплаенса или аудита, нехватка диска, высокая нагрузка на БД или, наоборот, потребность хранить историю дольше обычного.

Retention не удаляет открытые issues и не прерывает активные scan pipelines — очищаются только записи, чей возраст превышает заданный порог (или findings сверх лимита на issue).

Включение для Docker

Добавьте параметры в /opt/hw-vmp/config/user.ini:

v.common_config.retention.enabled = on

Чтобы изменить сроки хранения, добавьте нужные параметры из таблицы выше, например:

v.common_config.retention.event_days = 30
v.common_config.retention.scan_pipeline_days = 180

Примените изменения:

/opt/hw-vmp/bin/reconfig

Полный перечень параметров конфигурации — в Справочнике параметров.

Включение для Kubernetes

Добавьте в файл оверрайдов (например, my-production-config.yaml):

commonConfig:
  retention:
    enabled: "on"

Чтобы изменить сроки хранения:

commonConfig:
  retention:
    enabled: "on"
    eventDays: "30"
    scanPipelineDays: "180"

Примените изменения:

helm upgrade $RELEASE_NAME oci://registry.hexway.io/charts/vampy \
  --version $RELEASE_VERSION \
  -n $RELEASE_NAMESPACE \
  -f my-production-config.yaml

Место на диске после очистки

Retention чистит и файлы, и строки в базе. На диск это влияет по-разному.

Файловое хранилище (временные файлы оркестрации, загруженные файлы сканов): место на томе отдаётся сразу.
PostgreSQL: DELETE только помечает строки как удалённые. Файлы таблиц на диске ОС не сжимаются. Autovacuum и обычный VACUUM возвращают место для повторного использования внутри таблицы. Чтобы вернуть его операционной системе, нужен VACUUM FULL.

VACUUM FULL имеет смысл после первой большой очистки на давно работающей инсталляции или когда том БД близок к заполнению. Для ежедневных небольших удалений обычно достаточно autovacuum.

Оценка мёртвых строк

После очистки посмотрите, сколько мёртвых строк (n_dead_tup) в таблицах ниже:

SELECT
    relname AS table_name,
    n_live_tup,
    n_dead_tup,
    pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_stat_user_tables
WHERE relname IN (
    'event',
    'aggregated_data_by_day',
    'aggregated_data_by_week',
    'background_task',
    'scan_pipeline',
    'scan_finding'
)
ORDER BY n_dead_tup DESC;

Значения оценочные. Если очистка только что закончилась, подождите, пока обновятся статистики, либо выполните ANALYZE по нужной таблице.

Если n_dead_tup невелико относительно n_live_tup, VACUUM FULL не обязателен: место останется внутри таблицы и будет использовано при новых вставках.

Возврат места ОС: VACUUM FULL

Окно обслуживания

VACUUM FULL берёт эксклюзивную блокировку таблицы: чтение и запись этой таблицы недоступны, пока команда не завершится. Запускайте её в период низкой нагрузки, не во время окна очистки retention (по умолчанию 04:10-05:00 по локальному времени сервера) и не на пике сканирования. На время перезаписи нужно свободное место на томе БД примерно с размер сжимаемой таблицы.

Сначала зайдите в psql. Сжимайте только таблицы, где по оценке много мёртвых строк. VACUUM FULL выполняйте отдельной командой, не внутри BEGIN / COMMIT.

Docker (встроенная БД, контейнер по умолчанию hw-vmp-v_postgres-1, пользователь и БД v_server):

docker exec -it hw-vmp-v_postgres-1 psql -U v_server -d v_server

Kubernetes (встроенная БД). Пользователь и имя БД задаются в database.username и database.name (по умолчанию vampy). Заходите в под PostgreSQL, не в PgBouncer:

kubectl exec -it -n $RELEASE_NAMESPACE deploy/${RELEASE_NAME}-v-postgres -- \
  psql -U vampy -d vampy

Внешняя БД: откройте сессию к PostgreSQL своим клиентом, напрямую, не через PgBouncer.

В psql выполните, например:

VACUUM FULL background_task;

Для остальных таблиц из списка выше - то же самое, если там тоже много мёртвых строк. Без имени таблицы VACUUM FULL блокирует всю базу, так лучше не делать.