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

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

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

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

Что такое технологический журнал и когда его отключают

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

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

Признак того, что журнал включён: в каталоге, указанном в logcfg.xml, появляются папки с именами вида rphost_1234, ragent, 1cv8, внутри которых растут файлы логов. Если место на диске сервера начинает быстро заканчиваться — первым делом проверьте именно этот каталог.

Где находится файл logcfg.xml

Стандартное расположение файла зависит от того, чей журнал вы отключаете. Для сервера 1С на Windows это обычно каталог C:\Program Files\1cv8\<версия платформы>\bin\conf\. Для клиентского приложения — каталог conf в папке установленной платформы, которой запускается клиент.

На Linux-сервере файл ищите в каталоге /opt/1cv8/<архитектура>/<версия>/conf/. Если платформа установлена в нестандартный путь, ориентируйтесь на каталог conf рядом с исполняемыми файлами сервера.

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

Get-ChildItem -Path "C:\Program Files\1cv8" -Recurse -Filter logcfg.xml

Способ 1: полное удаление файла настроек

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

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

1. 1
   Остановите пользователей или предупредите их о кратковременном перезапуске службы
2. 2
   Найдите logcfg.xml в каталоге conf сервера или клиента
3. 3
   Переименуйте файл в logcfg.xml.disabled или переместите его в архив
4. 4
   Перезапустите службу агента сервера 1С (для клиентского журнала — перезапустите клиентские приложения)
5. 5
   Проверьте, что новые файлы в каталоге журнала не создаются
6. 6
   Удалите или заархивируйте старые файлы логов для освобождения места

Для клиент-серверного режима после удаления файла перезапустите службу «Агент сервера 1С:Предприятия». Работающие процессы rphost не перечитывают настройки на лету, поэтому без перезапуска журнал продолжит писаться. В файловом режиме достаточно перезапустить клиентские приложения.

Способ 2: очистка правил внутри файла

Если файл нужно сохранить (например, по регламенту он должен присутствовать), можно оставить его, но убрать все элементы <event> и <property> из секции <log>. Фактически файл останется, но собирать будет нечего.

Пример «пустого» содержимого, при котором журнал не пишется:

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

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

Отключение на клиенте и в файловом режиме

Если журнал настраивался для диагностики ошибок конкретного пользователя, logcfg.xml мог быть размещён на клиентской машине. В этом случае отключать его нужно именно там: найдите каталог conf в папке платформы на рабочей станции и удалите или переименуйте файл.

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

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

Проверка результата и очистка старых логов

После перезапуска службы откройте каталог, который был указан в параметре location внутри logcfg.xml (типичные пути — C:\Program Files\1cv8\srvinfo\logs или отдельный диск, выделенный под логи). В течение 10–15 минут активной работы пользователей новые файлы появляться не должны.

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

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

Типичные ошибки и ограничения

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

Вторая распространённая ситуация — несколько версий платформы на одном сервере. Файл удалён из каталога conf одной версии, а кластер фактически работает на другой. Всегда проверяйте, под какой версией платформы запущена служба агента.

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

Альтернативы полному отключению

Полное отключение — не единственный вариант. Если журнал нужен, но он слишком объёмный, настройте в logcfg.xml глубину хранения через атрибут history секции <log>: платформа будет автоматически удалять файлы старше заданного числа часов. Это защищает диск от переполнения.

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

Часто задаваемые вопросы