Технологический журнал и журнал регистрации на сервере 1С: что выключить, а что только урезать

Технологический журнал сервера 1С отключают в файле logcfg.xml: удалите из него элементы <log> или переименуйте сам файл. Платформа перечитывает настройки примерно раз в минуту, поэтому служба продолжает работать, перезапускать её не нужно. Журнал регистрации информационной базы так не выключается. Его ограничивают уровнем в Конфигураторе: Администрирование → Настройка журнала регистрации.

Типичная ситуация: на сервере кончается место на диске C:, а в каталоге логов лежат десятки гигабайт. Кто-то полгода назад включил технологический журнал «на всё» для разбора одной ошибки и забыл про него. Ниже показано, как найти, что именно пишет сервер, отключить лишнее и оставить минимум для диагностики.

Какие логи пишет сервер 1С и где они лежат

Под словом «логи» на сервере 1С скрываются три разные вещи. Настраиваются они в разных местах.

Начните с поиска файла logcfg.xml. Он лежит в каталоге conf платформы. Какой именно это каталог, подсказывает файл conf.cfg в папке bin\conf установленной версии: в нём параметр ConfLocation. В стандартной установке это обычно:

• Windows: C:\Program Files\1cv8\conf\ или C:\Program Files\1cv8\<версия>\bin\conf\;
• Linux: /opt/1cv8/conf/ или conf внутри каталога конкретной версии в /opt/1cv8/x86_64/.

Откройте найденный logcfg.xml в блокноте. По содержимому сразу видно, насколько журнал «тяжёлый»:

• 🔴 <property name="all"/> и нет фильтров по событиям — пишется всё подряд;
• 🟠 события DBMSSQL, DBPOSTGRS, SDBL — каждый запрос к базе, это гигабайты в час на нагруженном сервере;
• 🟢 только EXCP и ADMIN — исключения и действия администратора, объём небольшой.

Атрибут history у элемента <log> задаёт срок хранения в часах. Значение history="720" означает, что платформа держит логи за 30 суток.

Журнал регистрации ищите в каталоге кластера. По умолчанию для Windows это C:\Program Files\1cv8\srvinfo\reg_1541\. Внутри — папки с GUID баз. Какой GUID у какой базы, видно в файле 1CV8Clst.lst в том же каталоге: откройте его блокнотом и найдите имя базы.

Отключение технологического журнала в logcfg.xml

Перед правкой сохраните копию файла рядом, например logcfg.xml.bak. Пригодится, если понадобится снова включить диагностику с теми же настройками.

Способ 1. Полностью убрать запись ТЖ

1. Откройте logcfg.xml от имени администратора.
2. Удалите все блоки <log> … </log> или закомментируйте их через <!-- -->.
3. Оставьте только корневой элемент:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
</config>

4. Сохраните файл в кодировке UTF-8.
5. Подождите 1–2 минуты и проверьте, что в каталоге логов перестали появляться новые часовые файлы.

Вариант проще — переименовать файл в logcfg.xml.off. Нет файла — нет журнала. Минус в том, что отключается и настройка дампов, если она была в этом же файле.

Способ 2. Отключить дампы

Дампы .mdmp при частых падениях рабочих процессов быстро занимают место: один полный дамп rphost весит столько же, сколько память процесса. Чтобы платформа их не создавала, добавьте в logcfg.xml строку:

<dump create="false"/>

Отключайте дампы только осознанно. Без них при повторном падении процесса разбирать причину будет не по чему. Разумнее перенести их на другой диск атрибутом location и периодически чистить.

А что с параметрами агента сервера

Параметры службы агента (ragent) задаются в командной строке службы: порт, диапазон портов, каталог srvinfo, ключ -debug. Отдельного переключателя «логировать / не логировать» среди них нет, технологический журнал управляется только через logcfg.xml.

Связанное с нагрузкой здесь одно: ключ -debug. Он включает отладку на сервере. В рабочей среде его стоит убрать из строки запуска службы. Изменение вступит в силу только после перезапуска службы, а перезапуск обрывает сеансы всех пользователей. Делайте это вне рабочего времени, предупредив людей.

Как включать ТЖ на время разбора и не забыть выключить

Чаще всего гигабайты логов появляются не из-за плохой настройки, а из-за забытой. Чтобы так не вышло, договоритесь о простом порядке:

1. Готовьте «тяжёлый» вариант logcfg.xml заранее и храните его под другим именем, например logcfg_debug.xml.
2. На время разбора копируйте его поверх рабочего, а в заметке на сервере пишите дату и причину.
3. Ставьте history не больше 24–48 часов: даже если про журнал забудут, он не съест диск.
4. После разбора возвращайте лёгкий вариант из копии.

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

Журнал регистрации: снизить уровень, но не выключать

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

Через Конфигуратор

1. Откройте базу в Конфигураторе.
2. Выберите Администрирование → Настройка журнала регистрации.
3. В группе уровней выберите, что регистрировать.

Программно

Тот же уровень можно поставить из кода, например обработкой, которую запускает администратор. Методы платформы УстановитьИспользованиеЖурналаРегистрации() и ПолучитьИспользованиеЖурналаРегистрации() принимают и возвращают массив значений УровеньЖурналаРегистрации:

Уровни = Новый Массив;
Уровни.Добавить(УровеньЖурналаРегистрации.Ошибка);
Уровни.Добавить(УровеньЖурналаРегистрации.Предупреждение);
УстановитьИспользованиеЖурналаРегистрации(Уровни);

Выполнять это нужно под пользователем с правом администрирования. Удобно, когда баз на сервере много и обходить каждую в Конфигураторе долго.

Ротация и архивация логов сервера

Отключать журналы целиком приходится редко. Чаще достаточно ограничить, сколько они хранятся и где лежат.

Технологический журнал

ТЖ ротируется сам. Каждый процесс пишет в свою подпапку вида rphost_4512, файлы в ней называются по часу: 24101612.log — это 16 октября 2024 года, 12 часов. Старше значения history файлы платформа удаляет сама.

Пример «лёгкой» настройки, которую можно держать включённой постоянно:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_logs\tj" history="72">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="ADMIN"/>
    </event>
    <property name="all"/>
  </log>
  <dump location="D:\1c_logs\dumps" create="true"/>
</config>

Что здесь сделано:

• 📁 логи вынесены на диск D: — системный диск не переполнится;
• ⏳ хранение 72 часа — трое суток хватает, чтобы разобрать вчерашний сбой;
• 🎯 пишутся только исключения и действия администратора.

Журнал регистрации

Здесь ротации «по часам» нет, но есть два инструмента.

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

Формат журнала видно по расширению в папке 1Cv8Log: файл .lgd — одна база SQLite, файлы .lgf и .lgp — последовательный формат, где события лежат в отдельных файлах по периодам.

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

Linux

Логику ротации ТЖ на Linux менять не нужно, history работает так же. Чистку старых дампов можно повесить на cron, например раз в сутки удалять файлы старше 7 дней:

find /var/log/1c/dumps -name "*.mdmp" -mtime +7 -delete

Путь замените на свой каталог из location.

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

Пишущий ТЖ отнимает ресурсы трёх видов: диск, процессор и место.

Цифры ориентировочные: зависят от числа пользователей и того, чем они заняты.

Признаки, что тормоза вызывает именно журнал:

• 📈 в диспетчере задач высокая активность диска у процессов rphost при обычной работе;
• 💾 свободное место на диске с каталогом ТЖ уменьшается на глазах;
• ⏱ после переименования logcfg.xml через пару минут всё ускоряется.

Журнал регистрации нагружает меньше, но на уровне «Примечания» в большой базе с сотней пользователей тоже раздувается. Для .lgd-журналов размером в десятки гигабайт тормозит уже не запись, а открытие самого журнала регистрации для просмотра.

Если ТЖ нужен постоянно (например, для мониторинга блокировок), держите его на отдельном быстром диске, а не там же, где файлы СУБД.

Логи не пишутся: что проверить

Обратная ситуация: журнал нужен для разбора ошибки, а файлов нет. Пройдите по симптомам.

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