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

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

Полностью «встроенной кнопки» отключения в консоли кластера нет: журнал управляется наличием или отсутствием файла logcfg.xml в каталоге конфигурации. Поэтому выключение сводится к удалению или переименованию этого файла, очистке накопленных логов и, при необходимости, отключению записи аварийных дампов.

Как определить, что технологический журнал включён

Прежде чем что-то отключать, убедитесь, что ТЖ действительно активен и именно он создаёт проблему. Косвенные признаки: быстро растёт занятое место на диске сервера, появляются каталоги с именами вроде 1cv8 или reg_1541, внутри которых лежат папки с датами и файлы .log, а пользователи жалуются на замедление работы без видимой причины.

Найдите файл logcfg.xml. На сервере Windows он обычно располагается в каталоге C:\Program Files\1cv8\<версия платформы>\bin\conf или в служебном каталоге кластера srvinfo. На Linux — в каталоге /opt/1cv8/x86_64/<версия>/ или в домашнем каталоге пользователя, под которым работает агент. Для клиентского ТЖ файл размещают в каталоге conf рядом с исполняемыми файлами тонкого или толстого клиента.

Стандартный способ: удаление или переименование logcfg.xml

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

Не удаляйте файл безвозвратно, если он может понадобиться снова: переименуйте его, например, в logcfg.xml.off. Так вы сохраните настройки диагностики и сможете быстро вернуть их, вернув исходное имя.

1. 1
   Остановите работу пользователей или дождитесь минимальной нагрузки
2. 2
   Найдите logcfg.xml в каталоге conf на сервере и на клиентах
3. 3
   Переименуйте файл, например в logcfg.xml.off, или удалите его
4. 4
   Перезапустите службу «Агент сервера 1С:Предприятия» (на Linux — srv1cv8)
5. 5
   Проверьте, что новые файлы .log в каталоге ТЖ больше не появляются

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

Очистка накопленных логов

Отключение записи не освобождает диск: уже созданные файлы остаются на месте. Каталог логов задаётся в logcfg.xml параметром location внутри элемента log. Если файла уже нет, ищите логи в типовых местах: подкаталоги reg_1541 в srvinfo, каталоги вида 1cv8 в профилях пользователей или отдельный диск, выделенный администратором под ТЖ.

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

Отключение аварийных дампов

Отдельный источник больших файлов — дампы памяти при аварийном завершении процессов. Они настраиваются элементом dump в logcfg.xml, а также могут создаваться средствами операционной системы (например, Windows Error Reporting). Дамп одного процесса rphost может занимать объём, сопоставимый с объёмом оперативной памяти.

Если дампы больше не нужны, убедитесь, что после удаления logcfg.xml настройки дампов не остались в реестре Windows или конфигурации ОС. Проверьте каталоги, куда дампы записывались ранее, и удалите накопленные файлы .dmp и .mdmp.

Альтернатива: не выключать, а ограничить объём

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

За глубину хранения отвечает элемент history в настройках log: значение указывается в часах. Небольшое значение (например, сутки-двое) не даст каталогу разрастись бесконечно — платформа сама удалит устаревшие файлы. Такой «лёгкий» ТЖ почти не влияет на производительность, но сохраняет минимальную диагностическую информацию.

Варианты действий с ТЖ

Полное отключение

Подходит после завершения диагностики; минус — нет данных при новых инцидентах

Минимальный ТЖ (только ошибки)

Подходит для постоянной эксплуатации; требует аккуратной правки logcfg.xml

Ограничение history

Подходит как дополнение к любому варианту; не заменяет контроль диска

Проверка результата и типичные ошибки

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

Контрольные точки

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

Каталог логов

Норма

Новые .log не появляются

Тревожный признак

Файлы продолжают расти — logcfg.xml остался где-то ещё

Служба агента

Норма

Работает, в журнале ОС нет ошибок

Тревожный признак

Служба не стартует после перезапуска

Свободное место

Норма

Перестало уменьшаться

Тревожный признак

Диск продолжает заполняться — ищите дампы или другой каталог ТЖ

Частая ошибка — удалить logcfg.xml только на сервере, забыв про клиентские машины или второй рабочий сервер кластера: логи продолжают писаться, и администратор считает, что отключение «не сработало». Вторая ошибка — удалить файл, но не перезапустить агент и не дождаться перечитывания конфигурации, а затем делать поспешные выводы. Третья — по ошибке удалить весь каталог conf или другие файлы конфигурации платформы вместе с logcfg.xml.

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

Нужно ли перезапускать сервер 1С после удаления logcfg.xml?

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

Можно ли отключить технологический журнал через консоль кластера?

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

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

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

Влияет ли отключение ТЖ на журнал регистрации в 1С?

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

Безопасно ли удалять файлы .log из каталога ТЖ вручную?

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

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

Если вы переименовали файл в logcfg.xml.off, достаточно вернуть исходное имя logcfg.xml — настройки подхватятся автоматически. Поэтому удалять файл безвозвратно не рекомендуется.