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

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

Включение сводится к созданию файла logcfg.xml в специальном каталоге conf сервера 1С. В этом файле описывается, какие события фиксировать, куда складывать логи и как долго их хранить. Никаких настроек в консоли кластера для этого не предусмотрено — вся конфигурация выполняется только через XML-файл.

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

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

Технологический журнал — это текстовые логи, которые процессы платформы (ragent, rmngr, rphost) пишут по заданным правилам. Каждый процесс ведёт свой подкаталог внутри общего каталога логов, а события записываются с точностью до микросекунд. Это позволяет восстановить последовательность действий сервера при расследовании инцидентов.

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

Куда помещать файл logcfg.xml

Файл logcfg.xml должен лежать в каталоге conf внутри каталога установки сервера 1С. Для Windows типичный путь выглядит так: C:\Program Files\1cv8\8.3.22.1750\bin\conf\logcfg.xml (номер версии подставьте свой). Для Linux — /opt/1cv8/x86_64/8.3.22.1750/conf/logcfg.xml.

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

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

Минимальная конфигурация: пример logcfg.xml

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1clogs" history="72">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <property name="all"/>
  </log>
</config>

Разберём параметры. Атрибут location задаёт каталог логов, history — срок хранения в часах (72 часа = 3 суток). Внутри тега event перечисляются события: EXCP — исключения и ошибки, TDEADLOCK — взаимоблокировки, TTIMEOUT — таймауты, TLOCK — управляемые блокировки. Тег property со значением all включает запись всех свойств событий.

Для анализа медленных запросов добавьте события DBMSSQL (или DBPOSTGRS, DBORACLE в зависимости от СУБД) с фильтром по длительности. Например, событие DBMSSQL в паре с событием EXCP и свойством duration позволяет фиксировать только запросы дольше заданного порога — для этого используется условие вида <gt property="duration" value="10000000"/> (длительность указывается в микросекундах, 10 000 000 = 10 секунд).

1. 1
   Определите каталог установки работающей версии сервера 1С
2. 2
   Создайте каталог для логов на диске с запасом свободного места
3. 3
   Создайте logcfg.xml в подкаталоге conf и заполните список событий
4. 4
   Проверьте права: чтение файла и запись в каталог логов для учётной записи службы
5. 5
   Подождите 1–2 минуты и убедитесь, что в каталоге логов появились подкаталоги процессов
6. 6
   Воспроизведите проблемную операцию и проверьте, что события записались

Настройка под конкретную задачу

Диагностика медленной работы

Включайте события DBMSSQL (запросы к MS SQL Server), SCALL и CALL (вызовы), EXCP и обязательно ограничивайте по длительности, иначе объём логов будет огромным. Практичный подход — писать только обращения к СУБД дольше 5–10 секунд. После сбора данных за период жалоб пользователей логи анализируют вручную или специализированными инструментами разбора ТЖ.

Расследование аварийного завершения rphost

Добавьте событие PROC (старт и завершение процессов) и EXCP, а также убедитесь, что включено формирование дампов: за это отвечает отдельная настройка в том же logcfg.xml — элемент dump с атрибутом location и типом дампа. Дампы аварийного завершения складываются в указанный каталог и вместе с логами дают полную картину сбоя.

Анализ блокировок

Для блокировок достаточно событий TDEADLOCK, TTIMEOUT и TLOCK. Событие TLOCK пишется часто, поэтому включайте его на ограниченное время — например, на период воспроизведения проблемы, а затем убирайте из конфигурации.

Проверка, что журнал заработал

Через пару минут после сохранения файла загляните в каталог логов. Внутри должны появиться подкаталоги с именами процессов — ragent, rmngr, rphost_, а в них — файлы вида ГГММДДЧЧ.log. Если каталоги есть, а файлы пустые — события, заданные фильтром, просто ещё не происходили.

Для проверки спровоцируйте событие: выполните в базе операцию, которая гарантированно даст запись (например, длительный запрос, если включён фильтр по DBMSSQL с низким порогом). Откройте свежий лог текстовым редактором и найдите строку с нужным событием. Формат строки: время с микросекундами, длительность, имя события, процесс и свойства через запятую.

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

Самая частая причина «неработающего» журнала — файл размещён не в том каталоге conf (например, в каталоге другой версии платформы) или назван с ошибкой (logcfg.xml.txt при скрытых расширениях в Проводнике). Вторая по частоте — ошибка в XML: незакрытый тег или неверный регистр имени события, из-за чего платформа игнорирует файл целиком.

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

После завершения диагностики не забудьте убрать или закомментировать лишние события в logcfg.xml, оставив минимальный набор (например, только EXCP) либо удалив файл полностью. Это снимет лишнюю нагрузку на дисковую подсистему сервера.

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