Как хранить данные AI-агента и не раздувать диск

Что именно заполняет диск

Начните с политики хранения данных: письменных правил, определяющих, какие данные сохраняются, где они лежат, сколько живут и как удаляются. Без такой политики очистка обычно превращается в аварийное удаление самых крупных файлов.

У AI-агента чаще всего растут четыре категории данных:

• операционные логи — запросы, ошибки, трассировки и вывод инструментов;
• вложения — документы, изображения, аудио и архивы пользователей;
• производные файлы — распознанный текст, превью, индексы и экспортированные отчёты;
• временные данные — промежуточные загрузки, распакованные архивы и незавершённые задания.

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

Шаг 1. Составьте карту данных

Сначала зафиксируйте реальные каталоги приложения. Ниже используется условный пример /srv/agent-data; замените его на проверенный абсолютный путь своего сервера.

sudo du -xhd1 /srv/agent-data
sudo find /srv/agent-data -xdev -type f -printf '%s %p\n' \
  | sort -nr \
  | head -n 30

Первая команда показывает объём каталогов в пределах одной файловой системы. Вторая выводит 30 крупнейших файлов. Обе команды только читают метаданные и ничего не удаляют.

Соберите таблицу решений:

Сроки в таблице — пример, а не универсальная норма. Они зависят от назначения агента, требований пользователей, расследования сбоев и применимых правил обработки данных.

Шаг 2. Ограничьте рост логов

Приложение не должно бесконечно дописывать один файл. Для файловых логов настройте ротацию. Пример конфигурации /etc/logrotate.d/agent:

/srv/agent-data/logs/*.log {
    daily
    rotate 14
    maxsize 100M
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

daily запускает ротацию по дням, rotate 14 оставляет 14 архивов, а maxsize 100M позволяет ротировать слишком большой лог раньше. copytruncate подходит, если процесс не умеет переоткрывать файл, но при копировании возможна потеря небольшой части записей. Предпочтительнее настроить приложение на переоткрытие логов и использовать соответствующий postrotate.

Проверьте конфигурацию в режиме отладки:

sudo logrotate --debug /etc/logrotate.d/agent

Режим --debug не ротирует файлы. Принудительный запуск выполняйте только после проверки путей и понимания поведения работающего процесса.

Если агент пишет в системный журнал, задайте ограничения journald в /etc/systemd/journald.conf.d/agent-limits.conf:

[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=14day

После изменения конфигурации проверьте её и перезапустите journald в плановое окно обслуживания:

systemd-analyze cat-config systemd/journald.conf
sudo systemctl restart systemd-journald
journalctl --disk-usage

Шаг 3. Очищайте временные файлы предсказуемо

Для отдельного временного каталога удобно использовать systemd-tmpfiles. Пример файла /etc/tmpfiles.d/agent.conf:

d /srv/agent-data/tmp 0750 agent agent 1d

Это пример: пользователь и группа agent должны существовать, а путь не должен содержать постоянные данные. Возраст 1d означает, что tmpfiles сможет очищать старое содержимое согласно своим правилам времени доступа и изменения.

До применения проверьте, что выбрали правильный каталог:

sudo stat /srv/agent-data/tmp
sudo find /srv/agent-data/tmp -xdev -mindepth 1 -mtime +1 -print

Команда find выше только показывает кандидатов. Затем можно проверить обработку конфигурации:

sudo systemd-tmpfiles --create /etc/tmpfiles.d/agent.conf
sudo systemd-tmpfiles --clean --dry-run /etc/tmpfiles.d/agent.conf

Поддержка --dry-run зависит от версии systemd. Если параметр не распознаётся, не запускайте очистку вслепую: используйте предварительный список через find или проверьте доступные параметры командой systemd-tmpfiles --help.

Шаг 4. Удаляйте вложения через приложение

Вложение часто связано с записью в базе, задачей обработки и производными файлами. Поэтому удаление должно идти в правильном порядке:

1. выбрать записи, срок хранения которых истёк;
2. пометить их на удаление, чтобы агент перестал выдавать файлы;
3. удалить основной объект и производные данные;
4. зафиксировать результат в базе;
5. повторно обработать ошибки без удаления ещё используемых объектов.

Безопасное задание очистки должно иметь режим предварительного просмотра. Условный интерфейс команды:

agent-maintenance purge-attachments \
  --older-than 30d \
  --status orphaned \
  --dry-run

agent-maintenance purge-attachments \
  --older-than 30d \
  --status orphaned \
  --limit 500

Это пример интерфейса, а не существующая системная утилита. Реализуйте аналогичную команду внутри своего приложения. Она должна проверять ссылки в базе, обрабатывать ограниченное число объектов за запуск и быть идемпотентной: повторный запуск не должен повреждать состояние.

Не используйте rm -rf uploads/* и не удаляйте файлы только по времени изменения, если база может считать их активными.

Шаг 5. Поставьте жёсткие границы

Очистка снижает средний объём, но не защищает от резкого всплеска. Добавьте ограничения на входе:

• максимальный размер одного вложения;
• максимальный суммарный объём задания или диалога;
• ограничение числа параллельных загрузок;
• проверку свободного места до распаковки или преобразования;
• запрет архивов с чрезмерным коэффициентом распаковки;
• отдельный раздел или файловую квоту для данных агента.

Пример порога в конфигурации приложения:

storage:
  root: /srv/agent-data
  max_upload_bytes: 52428800
  min_free_bytes: 5368709120
  temp_ttl_hours: 24
  derived_data_ttl_days: 7

Значения соответствуют 50 МиБ на загрузку и резерву 5 ГиБ. Это пример. В коде проверяйте лимит как до приёма данных, так и во время потоковой записи: заголовку Content-Length нельзя доверять как единственному источнику размера.

Шаг 6. Контролируйте место до аварии

Минимальный контроль включает занятое место, свободные inode и скорость роста. Даже при свободных гигабайтах сервер может перестать создавать файлы, если закончились inode.

df -h /srv/agent-data
df -i /srv/agent-data
du -xsh /srv/agent-data/logs \
        /srv/agent-data/uploads \
        /srv/agent-data/tmp \
        /srv/agent-data/cache

Для автоматического наблюдения настройте две ступени предупреждений, например 75% и 90% заполнения, а также отдельный сигнал при быстром росте. Проценты — пример: на большом разделе последние 10% могут быть значительным запасом, а на маленьком — недостаточным.

Сигнал должен содержать точку монтирования, текущее заполнение и крупнейшую категорию данных. Не включайте в уведомление содержимое пользовательских файлов, запросов или секретов.

Как проверить результат

После настройки выполните проверку без искусственного заполнения рабочего диска:

1. Зафиксируйте исходные значения df -h, df -i и du.
2. Убедитесь, что ротация логов проходит в режиме отладки без ошибок путей и прав.
3. Просмотрите список кандидатов на очистку и вручную проверьте несколько записей.
4. Запустите очистку небольшой порцией, например не более 100–500 объектов.
5. Проверьте, что активные диалоги открывают вложения, а агент продолжает записывать логи.
6. Повторите измерения и сравните объём каждой категории.
7. Проверьте журнал задания очистки и наличие сигнала при его ошибке.

Политика работает, если рост ограничен, старые данные удаляются по расписанию, активные данные доступны, а предупреждение приходит раньше исчерпания места. Однократное уменьшение du ещё не подтверждает устойчивость — наблюдайте как минимум полный цикл выбранного срока очистки.

Типовые ошибки

Удаление открытого лога без перезапуска процесса

Файл исчезает из каталога, но процесс продолжает держать его дескриптор, поэтому место не освобождается. Найти такие файлы помогает sudo lsof +L1.

Очистка по одному только имени каталога

Опечатка или подмена символической ссылкой может направить команду не туда. Используйте абсолютные пути, -xdev, проверку stat и отдельного системного пользователя с минимальными правами.

Одинаковый срок для всех данных

Кэш можно пересоздать, а пользовательское вложение — не всегда. Разделяйте категории по назначению и стоимости восстановления.

Сжатие вместо удаления

Сжатые логи растут медленнее, но всё равно растут. Для архивов нужен конечный срок хранения или лимит объёма.

Очистка без блокировки активных заданий

Фоновая задача может удалить файл, пока агент его обрабатывает. Используйте состояния в базе, аренду задания или атомарное перемещение в карантин.

Проверка только команды df

df показывает файловую систему целиком, но не объясняет источник роста. Сопоставляйте его с du и контролем inode.

Отсутствие резервного пути

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

Ограничения и меры предосторожности

Примеры рассчитаны на Linux-сервер с systemd и файловым хранилищем. Для контейнеров учитывайте лимиты томов и драйвер логирования; для объектного хранилища используйте правила жизненного цикла самого хранилища; для Kubernetes — ограничения ephemeral storage и отдельные постоянные тома.

Автоматическое удаление не заменяет резервное копирование. При этом резервная копия тоже подчиняется отдельному сроку хранения: удаление рабочего файла не гарантирует немедленное исчезновение его копий.

Если данные нужны для аудита, договорных обязательств или расследования, срок нельзя выбирать только по доступному месту. Сначала определите обязательный период и режим блокировки удаления, затем рассчитайте требуемый объём. Не сохраняйте полные запросы и ответы «на всякий случай», если для диагностики достаточно технических метаданных.

Итоговая политика

Практичный минимальный вариант выглядит так:

• данные разделены на логи, вложения, производные и временные файлы;
• для каждой категории задан владелец, срок и способ удаления;
• логи ротируются по времени и размеру;
• временные файлы очищаются штатным планировщиком;
• вложения удаляются через приложение с проверкой ссылок;
• загрузки и распаковка имеют жёсткие лимиты;
• контролируются место, inode, скорость роста и ошибки очистки;
• каждая опасная операция сначала выполняется в режиме просмотра или на малой порции.

Дополнительные эксплуатационные материалы собраны в разделе практических руководств, а определения терминов — в глоссарии.