Как почистить логи в 1С 8.3

Логи 1С 8.3 — это журнал регистрации внутри информационной базы и технологический журнал на уровне сервера. Оба со временем разрастаются: журнал регистрации замедляет вход в базу и увеличивает размер файла 1Cv8.1CD или объём таблиц SQL, а технологический журнал способен заполнить диск сервера сотнями гигабайт текстовых файлов. Чистить их нужно регулярно и правильными инструментами, иначе можно потерять историю действий пользователей или остановить работу сервера.

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

Какие логи есть в 1С 8.3 и где они хранятся

Прежде чем чистить, важно понять, что именно вы собираетесь удалять. В платформе 1С 8.3 существует несколько независимых механизмов протоколирования, и у каждого своё место хранения и свой способ очистки.

Журнал регистрации — встроенный механизм фиксации событий: входы и выходы пользователей, изменение данных, ошибки, фоновые задания. В файловой базе он хранится внутри каталога базы в подкаталоге 1Cv8Log (файлы в формате LGD/LGP), в клиент-серверном варианте — в таблицах СУБД.

Технологический журнал (ТЖ) — низкоуровневый лог работы платформы: запросы к СУБД, вызовы, ошибки, блокировки. Включается конфигурационным файлом logcfg.xml и пишется в каталог, указанный администратором. По умолчанию без logcfg.xml платформа пишет только дампы аварийных завершений в каталог dumps.

Дополнительно существуют логи сервера 1С (каталог srvinfo с файлами регистрации событий кластера) и логи СУБД (например, журнал транзакций MS SQL), но это уже отдельная тема администрирования серверной инфраструктуры.

Как сократить журнал регистрации через конфигуратор

Штатный и безопасный способ почистить журнал регистрации — функция «Сократить» в конфигураторе. Она удаляет события старше заданной даты и физически уменьшает объём, занимаемый журналом.

1. 1
   Сделайте резервную копию базы (выгрузку в dt или копию каталога при монопольном доступе).
2. 2
   Откройте конфигуратор, перейдите в меню Администрирование → Настройка журнала регистрации.
3. 3
   Нажмите кнопку «Сократить».
4. 4
   Укажите дату, до которой удаляются события, и обязательно задайте файл для сохранения удаляемой части журнала.
5. 5
   Подтвердите операцию и дождитесь завершения — на больших журналах это может занять продолжительное время.
6. 6
   Проверьте, что журнал открывается и содержит события после указанной даты.

Обратите внимание на поле «Сохранять удаляемые события в файл». Если оставить его пустым, старая история будет удалена безвозвратно. Для баз, где журнал нужен для аудита или расследования инцидентов, всегда сохраняйте выгрузку в отдельный файл и убирайте его в архив.

Для клиент-серверных баз сокращение журнала лучше выполнять в период минимальной нагрузки: операция блокирует часть операций с журналом и при большом объёме может идти долго. Пользователям на это время желательно завершить работу, хотя строгого монопольного режима сама операция не требует.

Настройка уровня регистрации событий

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

Разделение журнала регистрации по периодам

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

Чтобы включить разделение, откройте конфигуратор: Администрирование → Настройка журнала регистрации → кнопка «Изменить» в группе «Разделять хранение журнала по периодам». После смены режима платформа создаст новый файл журнала, а старый останется рядом — его можно заархивировать или удалить, если история не нужна.

Если журнал уже разделён по периодам, чистка сводится к простому действию: завершите работу всех пользователей с базой, откройте каталог базы, перейдите в 1Cv8Log и удалите или переместите файлы старых периодов. Текущий период трогать нельзя — база должна видеть актуальный файл журнала.

Как почистить технологический журнал

Технологический журнал очищается не из конфигуратора, а средствами операционной системы. Файлы ТЖ хранятся в каталоге, заданном параметром Location в logcfg.xml, внутри — подкаталоги по именам процессов (rphost, ragent, rmngr) с текстовыми файлами вида .log и .txt.

Порядок очистки зависит от того, идёт ли сбор прямо сейчас. Если ТЖ включён постоянно, сначала отключите его или ограничьте в logcfg.xml, иначе платформа продолжит писать в те же файлы. Затем удалите старые каталоги с датами в именах — активные файлы текущего сеанса работы процессов удалить не получится или делать этого не стоит.

Пример команды для Linux, удаляющей файлы ТЖ старше 7 дней:

find /var/log/1c/technological_journal -type f -mtime +7 -delete

На Windows аналогичную задачу решает планировщик заданий со скриптом PowerShell, удаляющим файлы старше заданного срока. Главное — не задать слишком короткий срок хранения: при расследовании инцидента логи за последние несколько дней часто оказываются решающими.

Ограничение объёма ТЖ через logcfg.xml

Правильная профилактика — не ручная чистка, а настройка ротации. В logcfg.xml для элемента log задаются параметры history (срок хранения в часах) — платформа сама удаляет устаревшие файлы. Пример фрагмента конфигурации:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs" history="72">
    <event><eq property="name" value="EXCP"/></event>
    <property name="all"/>
  </log>
</config>

В этом примере журнал хранится 72 часа и пишет только исключения (ошибки). Чем шире набор событий, тем быстрее растёт объём: полный сбор с событиями DBMSSQL и CALL на нагруженном сервере может генерировать десятки гигабайт в сутки, поэтому включайте детальный ТЖ только на время диагностики.

Очистка журнала регистрации в клиент-серверной базе

В клиент-серверном варианте журнал регистрации хранится в таблицах СУБД, и сокращение через конфигуратор работает так же, но с нюансами. Удаление строк из таблиц журнала не всегда автоматически уменьшает размер файлов базы данных на диске — в MS SQL может потребоваться сжатие (shrink) файлов, в PostgreSQL — обслуживание таблиц.

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

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

После очистки убедитесь, что всё работает штатно: журнал регистрации открывается из конфигуратора и из режима предприятия, в нём присутствуют события после даты сокращения, новые действия пользователей фиксируются. Для ТЖ проверьте, что каталог не растёт неконтролируемо и параметр history в logcfg.xml применён.

Чтобы вопрос чистки не возникал в авральном режиме, встройте обслуживание в регламент: сокращение журнала регистрации раз в квартал с сохранением архива, автоматическая ротация ТЖ через history, мониторинг свободного места на дисках сервера. Для файловых баз с активной работой пользователей имеет смысл сразу включить разделение журнала по периодам.

Частые вопросы