Где хранится технологический журнал 1С и как настроить его расположение

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

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

Ниже разобраны стандартные каталоги для Windows и Linux, структура файлов журнала, настройка logcfg.xml, контроль объёма и типичные ошибки, из-за которых журнал либо не создаётся, либо заполняет весь диск.

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

Если в logcfg.xml указан только путь без уточнений, платформа создаёт внутри него структуру подкаталогов. На сервере 1С:Предприятия под Windows типичный путь выглядит так: каталог, заданный в конфигурации, а внутри — папки с именами процессов: rphost, ragent, rmngr. На клиентском компьютере аналогично появляются папки 1cv8, 1cv8c (тонкий клиент) и другие.

Исторически примером пути служит C:\Program Files\1cv8\logs или отдельный каталог вида D:\1c_logs — выбор за администратором. На Linux-сервере распространены варианты /opt/1cv8/logs или /var/log/1c. Платформа не навязывает конкретный путь: она пишет туда, куда укажет параметр location, и создаёт вложенные папки самостоятельно.

Внутри каждой папки процесса журнал разбивается на файлы по периодам. Имя файла включает дату и час в формате вида 24011510.log (год, месяц, день, час). Рядом могут лежать дампы аварийного завершения, если они включены отдельным параметром.

Как задать каталог через logcfg.xml

Файл logcfg.xml — единственный штатный способ включить технологический журнал и определить, где он хранится. На сервере его размещают в каталоге конфигурационных файлов сервера 1С (как правило, рядом с другими файлами настроек кластера, в каталоге вида conf внутри служебной директории сервера), на клиенте — в каталоге conf установленной платформы или в каталоге исполняемых файлов.

Минимальная конфигурация, включающая запись всех событий в указанный каталог, выглядит так:

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

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

Права доступа критичны: служба агента сервера 1С работает под отдельной учётной записью (на Windows обычно USR1CV8, на Linux — usr1cv8), и именно она должна иметь право записи в каталог журнала. Отсутствие прав — самая частая причина «молчания» журнала при корректном logcfg.xml.

1. 1
   Создайте каталог для логов, например D:\1c_logs, и дайте учётной записи службы сервера 1С полный доступ к нему
2. 2
   Создайте файл logcfg.xml с параметром location, указывающим на этот каталог, и разместите его в каталоге conf сервера или клиента
3. 3
   Подождите несколько минут или перезапустите службу агента сервера 1С
4. 4
   Выполните в системе действие, которое нужно зафиксировать
5. 5
   Проверьте, что внутри каталога появились подпапки rphost или 1cv8 с .log-файлами

Структура каталогов и файлов журнала

Понимание структуры помогает быстро найти нужный фрагмент лога. Внутри корневого пути платформа создаёт папку на каждый тип процесса, а в ней — файлы, нарезанные по часам. Рабочий процесс rphost пишет события СУБД и вызовов сервера, ragent — события агента кластера, клиентские процессы — ошибки и события на стороне пользователя.

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

Как не переполнить диск

Полный технологический журнал на нагруженном сервере генерирует гигабайты данных в час. Без ограничений каталог журнала способен заполнить системный диск и остановить работу сервера 1С и СУБД — это реальный аварийный сценарий, а не теоретический риск.

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

Для постоянного мониторинга ошибок достаточно фильтра по событиям EXCP и TLOCK с умеренной глубиной хранения. Полный сбор всех событий включайте только на время диагностики конкретной проблемы и выключайте сразу после сбора данных.

Почему журнал не создаётся: диагностика

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

Где искать журнал в типовых сценариях

Серверная база, ошибка у всех пользователей

Настройте logcfg.xml на сервере 1С, смотрите папки rphost и ragent внутри заданного каталога. Если кластер состоит из нескольких рабочих серверов, журнал включать и анализировать нужно на каждом из них — процессы пишут локально.

Проблема у одного пользователя

Разместите logcfg.xml в каталоге conf на компьютере пользователя и задайте локальный путь, например C:\1c_logs. Ищите папку 1cv8 или 1cv8c. После воспроизведения ошибки заберите файл за соответствующий час и отключите сбор.

Файловая база

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

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