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

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

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

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

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

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

Типовые задачи, для которых включают ТЖ: поиск причин взаимоблокировок (события TLOCK, TDEADLOCK, TTIMEOUT), анализ долгих запросов (DBMSSQL, DBPOSTGRS с длительностью), диагностика аварийных завершений рабочих процессов (EXCP, EXCPCNTX), проверка обращений к СУБД и медленных операций. Для разовой диагностики журнал включают на ограниченный период и затем отключают.

Где разместить файл logcfg.xml

Основное расположение — подкаталог conf в каталоге установки платформы, например C:\Program Files\1cv8\<версия>\bin\conf\logcfg.xml на Windows или /opt/1cv8/x86_64/<версия>/conf/ на Linux. Файл действует на все процессы данной версии платформы на этом компьютере.

Альтернативный путь задаётся параметром реестра Windows ConfLocation в ветке HKEY_LOCAL_MACHINE\SOFTWARE\1C\1CV8\<версия> (или аналогичной для нужной разрядности). Это удобно, когда каталог установки недоступен для записи или нужно централизованно управлять конфигурацией. Проверьте, что у службы агента сервера 1С есть права на чтение файла и на запись в каталог логов — частая причина «молчания» журнала именно в правах.

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

Минимальная конфигурация для запуска

Простейший рабочий вариант logcfg.xml включает запись всех событий в указанный каталог. Структура файла: корневой элемент <config>, внутри — один или несколько элементов <log> с атрибутом location (каталог выгрузки) и вложенными <event> и <property>.

<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>

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

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

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

Диагностика взаимоблокировок

Включите события TLOCK, TTIMEOUT и TDEADLOCK с контекстом. Для MS SQL Server полезно параллельно снимать трассировку, чтобы сопоставить сессии. Событие TDEADLOCK показывает жертву взаимоблокировки и участников конфликта.

Поиск медленных запросов

Включите событие DBMSSQL (или DBPOSTGRS, DBORACLE — по используемой СУБД) и добавьте условие по длительности, например <gt property="duration" value="1000000"/> — длительность указывается в микросекундах, то есть фильтр отсекает всё быстрее 1 секунды. Это самый частый сценарий при жалобах на «торможение» отчётов.

Анализ аварийных завершений

Для падений рабочих процессов включайте EXCP и EXCPCNTX, а также события PROC и MEM по необходимости. Дополнительно в logcfg.xml можно настроить создание дампов аварийных завершений — они нужны при обращении в поддержку.

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

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

После создания файла убедитесь, что сбор реально идёт. В каталоге выгрузки должны появиться подкаталоги вида rphost_<порт>, ragent, rmngr — по одному на каждый процесс платформы, а внутри — файлы с именами по шаблону даты и часа, например 24050813.log.

Если каталог пуст, проверьте по порядку: корректность XML (одна ошибка синтаксиса — и файл игнорируется целиком), расположение файла именно для той версии платформы, которая запущена, права учётной записи службы на чтение конфигурации и запись логов, а также отсутствие опечаток в пути location. Для проверки синтаксиса XML достаточно открыть файл в браузере — он покажет место ошибки.

Разбор содержимого и отключение журнала

Файлы ТЖ — текстовые, их можно смотреть любым редактором, но большие объёмы удобнее разбирать специализированными средствами: например, инструментами разбора технологического журнала из открытых проектов или штатным поиском по именам событий. Каждая строка события содержит время, длительность, имя события и список свойств через запятую; многострочные свойства (тексты запросов, контексты) идут после основной строки.

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

Ограничения и альтернативы

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

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

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