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

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

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

Материал ниже описывает полный цикл: где разместить конфигурационный файл, какие события включать под разные задачи, как ограничить объём логов и как убедиться, что журнал реально пишется. Инструкция применима к платформе 8.3 в клиент-серверном и файловом вариантах.

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

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

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

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

По умолчанию платформа ищет logcfg.xml в подкаталоге conf каталога установки конкретной версии платформы, например C:\Program Files\1cv8\8.3.22.1750\bin\conf\logcfg.xml на Windows или /opt/1cv8/x86_64/8.3.22.1750/conf/ на Linux. Важный нюанс: при обновлении платформы на новый релиз каталог меняется, и файл нужно переносить, иначе журнал «молча» отключится.

Альтернативный способ — задать собственный путь через реестр Windows: в ветке HKEY_LOCAL_MACHINE\SOFTWARE\1C\1CV8\conf (для 64-разрядной платформы) создаётся строковый параметр conf.location с путём к каталогу, где лежит logcfg.xml. Это удобно, когда на сервере несколько версий платформы и настройка должна быть общей.

Для клиент-серверного режима файл создаётся на сервере 1С (для процессов ragent/rmngr/rphost), а при необходимости логировать клиентскую сторону — и на рабочих местах пользователей. Учётная запись агента сервера 1С (по умолчанию USR1CV8) должна иметь права на чтение файла конфигурации и на запись в каталог логов.

Минимальная рабочая конфигурация

Простейший вариант logcfg.xml, который пишет все события всех процессов в указанный каталог с хранением 24 часа:

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

Здесь location — каталог логов, history — время хранения в часах, по истечении которого старые файлы удаляются автоматически. Пустое условие eq с пустым значением означает «все события». Такой конфиг подходит для кратковременной диагностики, но не для постоянной работы из-за объёма.

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

1. 1
   Создайте каталог для логов, например D:\1clogs, и дайте учётной записи агента сервера права на запись
2. 2
   Создайте файл logcfg.xml в каталоге conf нужной версии платформы или задайте conf.location в реестре
3. 3
   Пропишите в файле секцию log с каталогом, сроком хранения и списком событий
4. 4
   Перезапустите службу агента сервера 1С и клиентские приложения
5. 5
   Проверьте появление подкаталогов ragent, rmngr, rphost с файлами *.log

Какие события включать под конкретную задачу

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

Медленные запросы и производительность

Для анализа производительности включают события DBMSSQL или DBPOSTGRS (запросы к СУБД), DBV8DBEng (файловый вариант), SDBL, CALL, SCOM и EXCP (исключения). Чтобы отсечь быстрые операции, добавляют фильтр по длительности, например записывать только события длиннее 10 000 микросекунд (0,01 секунды):

<event>
<eq property="name" value="DBMSSQL"/>
</event>
<property name="all"/>
<event>
<ge property="duration" value="10000"/>
</event>

Взаимоблокировки

Для расследования взаимоблокировок включают события TLOCK, TDEADLOCK, TTIMEOUT вместе с контекстом DBMSSQL и CONN. По этим записям видно, какие сеансы и на каких таблицах столкнулись, и какой запрос стал жертвой блокировки.

Аварийные завершения и дампы

Если рабочий процесс rphost падает, в конфигурацию добавляют секцию dump: <dump location="D:\1cdumps" create="1" type="3"/>. Параметр type="3" означает полный дамп с дополнительными данными; для экономии места используют тип 0 (мини-дамп), но его часто недостаточно для глубокого анализа. Дампы пригодятся при обращении в поддержку или при самостоятельном разборе в отладчике.

Наборы событий под задачи

Производительность

DBMSSQL/DBPOSTGRS, CALL, EXCP с фильтром по длительности. Подходит для поиска медленных запросов; объём умеренный при правильном пороге.

Взаимоблокировки

TLOCK, TDEADLOCK, TTIMEOUT плюс CONN и DBMSSQL. Включается на время расследования, иначе логи растут быстро.

Аварийные завершения

EXCP, EXCPCNTX плюс секция dump. Требует много места под дампы, но незаменим при падениях rphost.

Полный сбор

Все события без фильтров. Только для кратковременной диагностики на тестовом стенде.

Фильтры и ограничение объёма логов

Фильтры в ТЖ работают на уровне событий и свойств: можно отбирать по имени события (eq, ne, like), по длительности (ge, le), по имени пользователя, имени базы, номеру соединения и другим свойствам. Например, чтобы писать события только конкретной информационной базы, используют условие по свойству p:processName или имени базы в зависимости от события.

Основные инструменты контроля объёма: параметр history (автоудаление старых файлов), фильтры по длительности, отказ от полного сбора событий и вынос каталога логов на отдельный диск. Платформа сама нарезает файлы по времени, поэтому ротация средствами ОС обычно не требуется — достаточно корректного history.

Дополнительно внутри секции log можно ограничить состав записываемых свойств: вместо <property name="all"/> перечисляют только нужные. Это заметно уменьшает размер файлов, но усложняет разбор, если контекст окажется обрезанным.

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

Признак успешной настройки — появление в каталоге логов подкаталогов с именами процессов (ragent_*, rmngr_*, rphost_*) и файлов вида 24010112.log (дата и час). Если каталог пуст через несколько минут после перезапуска службы, проверяйте типовые причины: файл лежит не в том каталоге conf, ошибка в XML (платформа при этом молча игнорирует конфигурацию), нет прав на запись, служба не перезапущена.

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

Контрольные точки

Как проверить результат

Каталог логов

Норма

Появились подкаталоги ragent, rmngr, rphost с файлами *.log

Тревожный признак

Каталог пуст — неверный путь к logcfg.xml, ошибка XML или нет прав

Содержимое файлов

Норма

Записи с нужными событиями (DBMSSQL, EXCP и др.) и корректным временем

Тревожный признак

Файлы есть, но событий нет — фильтры слишком строгие

Рост объёма

Норма

Объём растёт предсказуемо, старые файлы удаляются по history

Тревожный признак

Диск заполняется — событий слишком много, нужны фильтры

Типичные ошибки при настройке

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

Ещё одна группа ошибок связана с фильтрами: условия внутри одного <event> объединяются по «И», а разные секции <event> — по «ИЛИ». Из-за непонимания этого администраторы получают либо пустой лог, либо полный дамп всего подряд. Проверяйте логику на тестовом стенде перед переносом на боевой сервер.

Чем разбирать логи и как выключить журнал

Файлы ТЖ — обычный текст, но объёмы делают ручной разбор неудобным. На практике используют специализированные инструменты: «Технологический журнал» из состава инструментов разработчика, сторонние парсеры логов 1С, а для запросов к MS SQL — выгрузку планов запросов и сопоставление с событиями DBMSSQL по времени. Полезно знать, что свойство Context в событиях содержит фрагмент кода 1С, вызвавшего операцию.

Чтобы отключить журнал, достаточно удалить или переименовать logcfg.xml и перезапустить процессы. Если нужно временно приостановить только часть сбора, закомментируйте соответствующие секции <log> — но помните, что изменения опять же требуют перезапуска. После завершения диагностики отключайте ТЖ, чтобы не тратить ресурсы сервера.

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

Почему технологический журнал включён, но файлы не появляются?

Чаще всего файл logcfg.xml лежит не в том каталоге conf (проверьте версию платформы), содержит ошибку XML, служба агента не была перезапущена или у учётной записи USR1CV8 нет прав на запись в каталог логов. Проверяйте причины именно в этом порядке.

Можно ли настроить журнал только для одной информационной базы?

Да, с помощью фильтров по свойствам событий — например, по имени базы или имени процесса. Однако секция log создаёт отдельный каталог целиком, поэтому удобнее завести отдельную секцию с фильтром и своим каталогом для конкретной базы.

Насколько технологический журнал замедляет работу сервера?

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

Чем технологический журнал отличается от журнала регистрации?

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

Нужно ли переносить logcfg.xml при обновлении платформы?

Да. Каждая версия платформы устанавливается в отдельный каталог со своим подкаталогом conf, поэтому после обновления файл конфигурации нужно скопировать в новый каталог. Альтернатива — задать общий путь через параметр conf.location в реестре.

Как собрать дамп памяти при падении рабочего процесса?

Добавьте в logcfg.xml секцию dump с параметрами location, create="1" и type (0 — мини-дамп, 3 — полный). Убедитесь, что на диске достаточно свободного места: полный дамп рабочего процесса может занимать объём, сопоставимый с потребляемой им памятью.