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

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

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

Важно понимать: полный сбор событий создаёт большой объём данных и ощутимо нагружает дисковую подсистему. Поэтому журнал включают либо точечно (только нужные события), либо на ограниченное время — для расследования конкретной проблемы.

Что такое logcfg.xml и где он должен лежать

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

Стандартное расположение файла зависит от операционной системы и разрядности платформы:

• Windows (сервер и клиент): C:\Program Files\1cv8\<версия платформы>\bin\conf\logcfg.xml
• Windows (32-битная платформа на 64-битной ОС): C:\Program Files (x86)\1cv8\<версия>\bin\conf\logcfg.xml
• Linux: /opt/1cv8/<архитектура>/<версия>/conf/logcfg.xml

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

Минимальная конфигурация: включаем журнал за 5 минут

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

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

Разберём элементы. Атрибут location задаёт каталог, куда будут писаться файлы журнала — каталог должен существовать, и у учётной записи службы сервера 1С (обычно USR1CV8) должны быть права на запись в него. Атрибут history определяет, сколько часов хранить логи: по истечении срока платформа автоматически удаляет старые файлы.

Условие <eq property="name" value=""/> с пустым значением означает «все события». Элемент <property name="all"/> включает запись всех свойств событий, включая тексты запросов и контексты.

1. 1
   Создайте каталог для логов, например C:\1c_logs, и дайте учётной записи службы сервера 1С полные права на него
2. 2
   Создайте файл logcfg.xml с нужной конфигурацией в каталоге conf платформы
3. 3
   Перезапустите службу агента сервера 1С (или клиентское приложение для файлового режима)
4. 4
   Выполните в 1С действия, которые нужно зафиксировать
5. 5
   Проверьте, что в каталоге логов появились подкаталоги с файлами .log
6. 6
   После сбора данных переименуйте или удалите logcfg.xml и снова перезапустите службу

Настройка событий: что именно фиксировать

Запись всех событий подряд — крайняя мера. На практике журнал настраивают под конкретную задачу, указывая конкретные типы событий. Наиболее востребованные:

• DBMSSQL, DBPOSTGRS, DBORACLE, DB2 — запросы к соответствующей СУБД с текстом и длительностью;
• EXCP — исключения (ошибки платформы);
• EXCPCNTX — контекст исключений;
• TLOCK, TDEADLOCK, TTIMEOUT — управляемые блокировки, взаимоблокировки и таймауты;
• CALL, SCALL — вызовы (клиентские и серверные);
• PROC, CLSTR — события процессов и кластера;
• MEM — события, связанные с памятью;
• LEAKS — утечки памяти.

Пример конфигурации для поиска медленных запросов к MS SQL Server — фиксируются только запросы длительностью от 10 секунд (длительность указывается в микросекундах, поэтому 10000000 = 10 с):

<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\1c_logs" history="48">
<event>
<eq property="name" value="DBMSSQL"/>
</event>
<property name="all"/>
</log>
<plansql/>
<dbmslocks/>
</config>

Для фильтрации по длительности используются условия вида <ge property="duration" value="10000000"/> внутри элемента event. Операторы сравнения: eq (равно), ne (не равно), gt (больше), ge (больше или равно), lt, le, like (по маске).

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

Настройка для сервера, клиента и файлового режима

Клиент-серверный режим

В клиент-серверной архитектуре большая часть полезных событий (запросы к СУБД, серверные вызовы, блокировки) генерируется на сервере 1С. Поэтому logcfg.xml размещают в каталоге conf на сервере, а после изменения файла перезапускают службу «Агент сервера 1С:Предприятия».

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

Файловый режим

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

Несколько версий платформы

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

Проверка результата и анализ логов

После перезапуска службы и выполнения действий в 1С проверьте каталог логов. Внутри должны появиться подкаталоги с именами процессов (rphost, rmngr, 1cv8, 1cv8c и т.д.), а в них — файлы вида YYMMDDHH.log. Формат имени: год, месяц, день, час создания. Каждый час создаётся новый файл.

Формат строки журнала: мм:сс.микросекунды-длительность,СОБЫТИЕ,процесс:поток,свойства. Свойства записываются парами «имя=значение» через запятую. Для событий СУБД среди свойств будут Sql (текст запроса), Duration (длительность), Rows и другие.

Вручную разбирать большие логи неудобно. Для анализа применяют специализированные инструменты: консоль технологического журнала, обработки-анализаторы ТЖ, а также штатный «Центр администрирования» и внешние решения, которые парсят файлы и строят статистику по длительности запросов, ошибкам и блокировкам. Для разового анализа подойдёт и поиск по файлам по имени события (например, «EXCP») в любом текстовом редакторе, поддерживающем большие файлы.

Риски, ограничения и типичные ошибки

Главный риск технологического журнала — исчерпание дискового пространства. Полный сбор событий на загруженном сервере может генерировать гигабайты данных в час. Если диск переполнится, пострадает не только журнал, но и работа сервера в целом. Всегда задавайте атрибут history, размещайте логи на отдельном диске и следите за свободным местом.

Второй риск — снижение производительности. Запись событий с полными свойствами (особенно планов запросов и контекстов) добавляет накладные расходы. На продуктивной системе включайте полный сбор только на время воспроизведения проблемы.

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

Отключение журнала и хранение данных

Чтобы выключить технологический журнал, удалите или переименуйте logcfg.xml (например, в logcfg_off.xml — так удобно включать его повторно) и перезапустите службу агента сервера 1С или клиентское приложение. Уже собранные файлы при этом не удаляются.

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

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

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