Чистим журнал регистрации сервера 1С и возвращаем место на диске

То, что на сервере 1С разрастается и что администраторы между собой называют «сообщениями», почти всегда — это журнал регистрации: файлы с событиями, ошибками и предупреждениями по каждой информационной базе. Чистят его не в SQL и не утилитой rac, а штатно — в Конфигураторе, командой «Сократить» в разделе Администрирование → Журнал регистрации.

Главное, что стоит знать сразу: очистка журнала не трогает документы, справочники и проводки. Это отдельное файловое хранилище событий, поэтому сокращать его можно спокойно — предупредив разве что тех, кому старые записи нужны для разбора инцидентов.

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

Что именно копится на сервере и где это лежит

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

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

<каталог кластера>\reg_1541\<идентификатор базы>\1Cv8Log\

Каталог кластера (srvinfo) задаётся при запуске агента сервера ragent. Папка reg_1541 соответствует кластеру на порту 1541, внутри — подкаталоги с GUID по числу баз, и в каждом — папка 1Cv8Log с самим журналом.

Папок с GUID внутри reg_1541 столько же, сколько баз в кластере, и по самому идентификатору не понять, какая из них разрослась. Сопоставить GUID с именем базы помогает утилита rac:

rac infobase summary list --cluster <uuid-кластера>

В выводе рядом с именем базы будет её идентификатор — он и есть имя папки в reg_1541. Дальше достаточно сравнить размеры подкаталогов 1Cv8Log в проводнике, чтобы найти виновника.

Форматов хранения два:

• 📄 Один файл SQLite — 1Cv8.lgd. Формат по умолчанию на актуальных платформах, компактнее и быстрее.
• 🗂 Набор файлов старого формата — индекс .lgf и фрагменты .lgp по периодам. Встречается на базах, которые давно не переводили на новый формат.

Именно эти файлы и «весят». Их не редактируют вручную — платформа держит их открытыми и сама управляет структурой. Правильный способ уменьшить объём — сокращение штатными средствами, о нём ниже.

Что проверить до очистки, чтобы не оборвать работу

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

Перед большой уборкой держите в голове три вещи:

1. Решите границу по дате — записи до какого числа удаляются. Разумный горизонт для большинства баз — хранить журнал за последние 2–3 месяца.
2. Если планируете выгрузить старые события в файл (для аудита) — заранее выберите, куда его положить.
3. Операцию лучше запускать в период низкой нагрузки: на огромном журнале сокращение идёт долго и даёт дополнительную нагрузку на диск.

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

Это основной штатный способ. Работает и для клиент-серверной, и для файловой базы.

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

После сокращения размер файла 1Cv8.lgd уменьшается не всегда сразу: SQLite освобождает место внутри файла, но на диске он может остаться прежним до уплотнения. Это нормально — свободное место внутри переиспользуется, и дальше файл расти перестанет.

Очистка по расписанию: пакетный режим Конфигуратора

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

Схема рабочая и проверенная:

• На сервере создаётся задание в Планировщике задач Windows (или cron под Linux).
• Задание запускает Конфигуратор в пакетном режиме с параметром сокращения журнала и нужной датой.
• Запуск ставят на ночь — скажем, раз в неделю.

Пакетный режим — это тот же 1cv8 с ключом запуска Конфигуратора (DESIGNER), строкой подключения к серверной базе и параметром, который сокращает журнал до указанной даты. Точное имя и синтаксис параметра сверьте в документации по пакетному запуску Конфигуратора (раздел про параметры командной строки) — у разных версий платформы формулировка ключа и порядок аргументов отличаются, и выдумывать их на память не стоит.

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

Почему rac и прямые SQL-запросы здесь не помогут

Частая ошибка — искать очистку журнала в утилите администрирования кластера или прямо в базе СУБД. Ни то, ни другое для этой задачи не предназначено.

Утилита rac управляет кластером: список баз, сеансы, соединения, блокировки, профили безопасности. Команды журнала регистрации у неё нет. Что rac действительно умеет и что рядом полезно:

rac cluster list
rac session list --cluster <uuid-кластера>
rac connection list --cluster <uuid-кластера>

Этим смотрят активные сеансы и соединения — например, перед обслуживанием, чтобы понять, кто работает. Полный перечень команд и параметров — в rac help; подкоманды «очистить сообщения» среди них нет.

Прямые SQL-запросы тоже мимо. Журнал регистрации не хранится в базе SQL Server или PostgreSQL — он лежит в файлах каталога кластера (1Cv8Log). Удалять через DELETE там нечего. Новый формат 1Cv8.lgd — это файл SQLite, и теоретически его можно открыть сторонним редактором, но:

Сводка по способам:

Настройка, чтобы журнал не разрастался снова

Сократили один раз — хорошо, но через месяц он снова наберёт объём. Чтобы рост замедлить, настройте сам журнал в Конфигураторе: Администрирование → Настройка журнала регистрации.

Два рычага, которые реально помогают:

• 🎚 Уровень регистрируемых событий. Можно выбрать, какие события писать: ошибки, предупреждения, информацию, примечания. Если отключить запись информационных событий и примечаний, оставив ошибки и предупреждения, журнал растёт в разы медленнее, а для разбора проблем остаётся главное.
• 🗓 Разделение хранения по периодам (не разделять / день / неделя / месяц). Разделение по месяцам упрощает и ускоряет последующее сокращение: платформа работает с меньшими кусками, а не с одним гигантским файлом.

Дополнительно стоит завести простой контроль размера: периодически смотреть объём папки 1Cv8Log на сервере или включить мониторинг свободного места на диске. Разросшийся журнал — частая причина того, что на сервере внезапно «кончается место», хотя сама база невелика. Удобно вынести каталог кластера на отдельный диск или раздел: тогда переполнение журнала не затронет системный диск и не остановит работу других служб.

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

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

Если место на диске сервера тает подозрительно быстро — проверьте, не остался ли включённым технологический журнал (ТЖ). Это отдельный от журнала регистрации механизм, и его часто принимают за «сообщения, которые завалили сервер».

Разница простая:

• Журнал регистрации — бизнес-события базы (входы, ошибки, действия пользователей). Нужен постоянно, растёт предсказуемо.
• Технологический журнал — подробная техническая трассировка работы платформы (запросы, блокировки, исключения). Его включают точечно для диагностики, и он пишет данные гораздо интенсивнее.

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

Технологический журнал настраивается файлом logcfg.xml в каталоге конфигурации сервера (папка conf рядом с исполняемыми файлами платформы). Чтобы остановить разрастание:

1. Откройте logcfg.xml и уберите или ограничьте активные настройки сбора (либо замените файл на пустой с корневым элементом конфигурации — трассировка перестанет писаться).
2. Удалите уже накопленный каталог с дампами, путь к которому задан в этом же файле.
3. Убедитесь, что после изменения новые файлы в каталоге трассировки больше не появляются.

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