Как очистить логи 1С на сервере

Логи 1С на сервере растут постоянно: журнал регистрации фиксирует действия пользователей, технологический журнал пишет диагностику, СУБД накапливает собственные журналы транзакций и ошибок, а агент кластера ведёт служебные файлы. Если за ними не следить, диск сервера заполняется, и в какой-то момент база останавливается с ошибкой записи. Очистка логов — регулярная задача администратора, и выполнять её нужно правильно: удалять не всё подряд, а осознанно, с пониманием, что именно вы стираете и какую историю теряете.

Сложность в том, что «логи 1С» — это не один файл, а как минимум пять разных источников: журнал регистрации информационной базы, технологический журнал, журналы СУБД (MS SQL Server или PostgreSQL), логи агента сервера 1С и журналы веб-сервера, если публикация идёт через IIS или Apache. У каждого — своё расположение, свой механизм очистки и свои риски. Универсальной кнопки «очистить всё» не существует.

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

Где на сервере хранятся логи 1С

Прежде чем что-то удалять, нужно точно знать, какие логи существуют и где они лежат. Основные источники:

• Журнал регистрации — файл 1Cv8.lgd в каталоге информационной базы (в клиент-серверном варианте — в каталоге базы внутри srvinfo на сервере 1С) либо таблица в СУБД при новом формате хранения.
• Технологический журнал (TechnoLog) — каталог, заданный в файле logcfg.xml; по умолчанию для Windows это подкаталоги в C:\Program Files\1cv8\<версия>\bin\conf или указанный вами путь.
• Логи агента кластера — каталог srvinfo (обычно C:\Program Files\1cv8\srvinfo) с файлами 1CV8Clst.lst и служебными журналами.
• Журналы СУБД — errorlog и журнал транзакций в MS SQL Server, pg_log и WAL в PostgreSQL.
• Логи веб-сервера — IIS (C:\inetpub\logs\LogFiles) или Apache, если база опубликована через веб.

Быстрый способ найти, что именно съело место — просканировать диск любым анализатором занятого пространства (WinDirStat, TreeSize) или командой поиска крупных файлов. Чаще всего виновниками оказываются журнал регистрации в старом формате .lgf/.lgd, разросшийся технологический журнал, который включили для диагностики и забыли выключить, и журнал транзакций SQL Server в полной модели восстановления без регулярного бэкапа.

Очистка журнала регистрации 1С

Журнал регистрации — единственный лог, который очищается штатными средствами платформы. Откройте конфигуратор под учётной записью с правами администратора, перейдите в меню «Администрирование» → «Настройка журнала регистрации». Здесь есть кнопка «Сократить» — она удаляет события старше указанной даты. Перед сокращением платформа предложит выгрузить удаляемую часть в файл — обязательно соглашайтесь и сохраняйте выгрузку в архив, если история действий пользователей может понадобиться для расследований или аудита.

Важный нюанс: журнал регистрации хранится в двух форматах. Старый формат — файл 1Cv8.lgf, он склонен к повреждениям при больших размерах и плохо переносит параллельную запись. Новый формат — файл 1Cv8.lgd (SQLite-база), более надёжный и быстрый. Переключить формат можно в той же настройке журнала регистрации. Если журнал в старом формате разросся до десятков гигабайт, сокращение может занять часы и потребовать монопольного доступа к базе — планируйте операцию на нерабочее время.

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

1. 1
   Завершите сеансы пользователей через консоль кластера или дождитесь окончания рабочего дня
2. 2
   Сделайте резервную копию информационной базы штатным способом
3. 3
   Откройте конфигуратор: Администрирование → Настройка журнала регистрации
4. 4
   Нажмите «Сократить», укажите дату, старше которой удалять события
5. 5
   Согласитесь на выгрузку удаляемой части в файл и сохраните его в архивное хранилище
6. 6
   Дождитесь завершения операции, не прерывая процесс
7. 7
   Откройте журнал регистрации и убедитесь, что он работает и новые события записываются

Очистка технологического журнала

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

Каталог технологического журнала задаётся в logcfg.xml элементом log location. Найдите этот файл (обычно в каталоге conf внутри bin установленной версии платформы) и проверьте, куда пишутся логи. Очистка выполняется просто: файлы внутри каталога можно удалять напрямую — это обычные текстовые логи, платформа их после записи не блокирует надолго. Но сначала решите, нужна ли вам диагностика дальше.

Если диагностика завершена — удалите или переименуйте logcfg.xml и перезапустите агент сервера 1С: без файла конфигурации технологический журнал не пишется. Если диагностика ещё нужна, настройте в logcfg.xml ротацию: элементы property с ограничением по времени хранения (например, history="24" — хранить логи за сутки). Тогда платформа сама удаляет старые файлы, и ручная чистка больше не понадобится.

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1clogs\technolog" history="24">
    <event><eq property="name" value="DBMSSQL"/></event>
    <property name="all"/>
  </log>
</config>

Обратите внимание: каталог технологического журнала лучше размещать не на системном диске и не на диске с базами, а на отдельном томе. Тогда даже при забытых настройках диагностики переполнение не остановит работу сервера 1С или СУБД.

Очистка журналов СУБД: SQL Server и PostgreSQL

MS SQL Server

В SQL Server проблему обычно создают два объекта: журнал транзакций базы (файл .ldf) и системный errorlog. Журнал транзакций в полной модели восстановления (Full) растёт, пока не выполняется резервное копирование журнала. Если бэкапы журнала не настроены, файл .ldf может превысить размер самой базы в разы.

Если восстановление на произвольный момент времени вам не требуется (а для большинства баз 1С достаточно ежедневного полного бэкапа), переведите базу в простую модель восстановления (Simple) и выполните сжатие журнала. В простой модели журнал усекается автоматически после контрольных точек, но уже разросшийся файл нужно сжать вручную.

ALTER DATABASE [MyBase] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase_log', 1024);
GO

Системный журнал errorlog и журналы агента SQL Server очищаются процедурами sp_cycle_errorlog и sp_cycle_agent_errorlog — они закрывают текущий файл и начинают новый, а старые можно удалить. По умолчанию хранится ограниченное число файлов, но на давно работающих серверах их стоит проверить.

PostgreSQL

В PostgreSQL логи сервера лежат в каталоге, заданном параметром log_directory (обычно log внутри каталога данных). Их можно удалять напрямую, но лучше настроить ротацию в postgresql.conf: параметры log_rotation_age и log_rotation_size заставляют сервер сам закрывать и архивировать старые файлы. WAL-журналы в pg_wal удалять вручную категорически нельзя — это приведёт к повреждению кластера; их размер регулируется настройками архивирования и параметром max_wal_size.

Логи агента сервера 1С и веб-сервера

Каталог srvinfo содержит реестр кластера (1CV8Clst.lst), список информационных баз и служебные журналы сеансов. Сам по себе он обычно не разрастается до критических размеров, но внутри подкаталогов reg_1541 (или другого порта) хранятся каталоги информационных баз — и именно там лежат журналы регистрации в формате .lgd, о которых говорилось выше. Удалять из srvinfo можно только содержимое подкаталогов журналов сеансов и только при остановленном агенте сервера 1С, иначе реестр кластера может повредиться.

Если база опубликована через IIS, логи веб-сервера копятся в C:\inetpub\logs\LogFiles — по папке на каждый сайт, по файлу на каждый день. На активно используемом сервере это сотни мегабайт в месяц. IIS не имеет встроенной автоматической очистки, поэтому старые файлы удаляют вручную или планировщиком задач Windows. Простой вариант — еженедельная задача, удаляющая файлы старше 30 дней.

Get-ChildItem "C:\inetpub\logs\LogFiles" -Recurse -Include *.log | Where-Object {$_.LastWriteTime -lt (Get-Date).AddDays(-30)} | Remove-Item -Force

Для Apache логи публикаций 1С лежат в каталоге logs веб-сервера; ротация настраивается через rotatelogs или внешними средствами ОС.

Автоматизация: как не чистить логи вручную каждый месяц

Разовая очистка решает проблему на недели. Чтобы логи не разрастались снова, настройте ротацию на каждом уровне:

• Журнал регистрации — сокращайте по расписанию, например раз в квартал, через план обслуживания. Автоматического сокращения в платформе нет, но операцию можно выполнять программно через пакетный режим конфигуратора или внешнюю обработку по расписанию.
• Технологический журнал — используйте параметр history в logcfg.xml, чтобы платформа сама удаляла старые файлы.
• SQL Server — настройте план обслуживания: полный бэкап ежедневно, бэкап журнала транзакций (при модели Full) несколько раз в день.
• PostgreSQL — включите log_rotation_age и задайте разумный срок хранения через log_filename и внешнюю очистку старых файлов.
• IIS — задача планировщика Windows с удалением файлов старше заданного срока.

Дополнительно настройте мониторинг свободного места на дисках сервера с оповещением при заполнении выше порога, например 80%. Это даст время отреагировать до того, как база встанет с ошибкой записи.

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

После любой очистки убедитесь, что система работает штатно. Проверьте: база открывается в клиенте, журнал регистрации пишет новые события, сеансы пользователей устанавливаются, в консоли кластера нет ошибок. Для СУБД выполните проверку целостности (DBCC CHECKDB для SQL Server — в нерабочее время) или хотя бы убедитесь, что база в статусе ONLINE и последний бэкап прошёл успешно.

Сверьте освободившееся место с ожидаемым: если вы удалили 50 ГБ технологического журнала, а свободного места прибавилось заметно меньше — возможно, файлы удерживаются открытым процессом, и требуется перезапуск службы агента сервера 1С.

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