Настройка технологического журнала 1С: от базовых правил до профилирования

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

Грамотная настройка этого инструмента требует понимания архитектуры процесса и осторожности, так как включение избыточного количества событий может привести к резкому падению быстродействия и переполнению дискового пространства за считанные часы.

В этой статье мы детально разберем структуру файла конфигурации, выберем оптимальные параметры для различных сценариев диагностики и научимся анализировать полученные логи без лишнего шума.

Архитектура и назначение технологического журнала

Технологический журнал представляет собой механизм логирования, встроенный непосредственно в ядро платформы. Он позволяет фиксировать события на уровне процессов rphost, rmngr и клиентских приложений. Основная цель использования ТЖ — выявление узких мест в работе системы, таких как долгие запросы к базе данных или блокировки.

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

Важно понимать, что ТЖ работает асинхронно. Это означает, что запись событий происходит в фоновом режиме, но при высокой интенсивности событий буфер может переполняться. Именно поэтому критически важно правильно настроить уровни детализации и фильтры.

⚠️ Внимание: Никогда не оставляйте файл logcfg.xml с включенными событиями уровня all или debug на боевом сервере в штатном режиме. Это гарантированно приведет к отказу в обслуживании из-за нагрузки на дисковую подсистему.

События в журнале делятся на несколько ключевых категорий:работа с базой данных (DB), блокировки (Lock), вызовы внешних источников данных (V8DB) и внутренние процессы сервера. Для эффективной диагностики обычно достаточно отслеживать только одну или две категории.

Структура файла конфигурации logcfg.xml

Файл конфигурации имеет строгую XML-структуру, несоблюдение которой приведет к игнорированию настроек платформой. Корневой элемент содержит глобальные параметры, такие как путь к файлам логов и максимальный размер одного файла.

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

Рассмотрим базовый шаблон корректного файла. Обратите внимание на атрибут name, который определяет тип события, и атрибут level, задающий порог записи.

<config xmlns="http://www.1c.ru/etv/java/tcfg" >
<log dir="c:\logs" history="Y" maxsize="100M" maxhistory="10" />
<event name="DBMSSQL" level="5" />
<event name="LOCK" level="5" />
</config>

Параметр maxsize ограничивает размер одного файла лога, а maxhistory определяет количество хранимых архивных файлов. Это реализует механизм ротации логов, предотвращая бесконечный рост занимаемого места.

Для сложных сценариев можно использовать вложенные теги property, позволяющие фильтровать события по имени пользователя, компьютеру или конкретному сеансу. Это особенно полезно при диагностике проблем у одного конкретного сотрудника.

Настройка уровней детализации и фильтрация событий

Уровень детализации (Level) является критическим параметром, определяющим объем записываемой информации. В 1С используется шкала от 0 до 5, где 0 означает отключение события, а 5 — максимальную подробность.

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

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

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

<event name="DBMSSQL" level="5">
<property name="duration" op=">" value="1000" />
</event>

Такая настройка позволит игнорировать все запросы, которые выполняются быстрее 1000 миллисекунд. Это существенно снижает нагрузку на систему и упрощает последующий анализ логов.

Диагностика производительности и анализ SQL-запросов

Одной из самых частых задач при работе с ТЖ является поиск медленных SQL-запросов. Для этого используется событие DBMSSQL (для MS SQL) или DBPOSTGR (для PostgreSQL). Анализ этих логов позволяет понять, какие операции нагружают сервер баз данных.

При анализе обращайте внимание не только на время выполнения, но и на текст самого запроса. Часто причиной тормозов являются отсутствие индексов или неоптимальные планы выполнения, сгенерированные СУБД.

Для интерпретации данных полезно сопоставлять время выполнения запроса с количеством обработанных строк. Если запрос выбирает миллионы строк за долю секунды, это нормально. Если же он выбирает десять строк, но выполняется пять секунд — это явная проблема.

Ниже приведена таблица основных событий, используемых для диагностики производительности:

Событие	Описание	Рекомендуемый уровень
DBMSSQL	Выполнение запросов к MS SQL Server	4-5 (с фильтром по времени)
LOCK	Операции блокировок объектов	5 (только при проблемах)
CALL	Вызов методов внешних компонентов	3-4
EXCP	Возникновение исключительных ситуаций	5

Использование события LOCK требует особой осторожности. Оно генерирует огромный объем данных даже при штатной работе, так как блокировки создаются и снимаются постоянно. Включайте его только на короткое время для воспроизведения конкретной проблемы.

Как читать план выполнения в ТЖ?

В логах ТЖ план выполнения может быть представлен в сжатом виде. Для детального анализа лучше скопировать текст запроса из лога и выполнить его непосредственно в инструментах СУБД (например, SSMS), включив отображение плана выполнения.

Анализ блокировок и взаимоблокировок (Deadlock)

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

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

При анализе логов на предмет deadlock ищите записи, где один и тот же ресурс фигурирует в контексте разных сеансов с противоположными операциями (например, один пишет, другой читает с блокировкой).

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

⚠️ Внимание: Интерфейсы и внутренняя логика работы механизмов блокировок могут изменяться в новых версиях платформы 1С. Всегда сверяйте актуальные параметры событий в официальной документации фирмы "1С" для вашей конкретной версии релиза.

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

Автоматизация сбора и анализа логов

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

Стандартная поставка 1С не включает удобного графического анализатора для ТЖ, поэтому администраторы часто используют сторонние инструменты или пишут собственные парсеры на Python или PowerShell.

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

• 🔍 Используйте утилиту 1CLogAnalyzer или аналоги для визуализации графов вызовов и временных диаграмм.
• ⚙️ Настройте задачу в планировщике Windows или cron в Linux для автоматической очистки старых логов старше 7 дней.
• 📊 Экспортируйте данные из ТЖ в CSV формат для дальнейшего анализа в Excel или системах BI.

Интеграция сбора логов с системами мониторинга (например, Zabbix или Prometheus) позволяет отслеживать появление критических ошибок в реальном времени и получать уведомления на почту или в мессенджер.

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

Где хранятся логи в Linux?

В операционных системах семейства Linux пути к логам часто зависят от прав доступа пользователя, под которым запущен сервер 1С. Стандартный путь может быть в домашней директории пользователя или в /var/log/1c.

Где именно находится файл logcfg.xml для сервера 1С?

Для клиент-серверного варианта файл должен находиться в каталоге установки платформы (например, C:\Program Files\1cv8\8.3.xx.xxx\bin) или в профиле пользователя, от имени которого запущена служба сервера 1С. Для файловой базы файл лежит в корне папки базы данных.

Как включить ТЖ только для одного конкретного пользователя?

В файле конфигурации внутри тега события нужно добавить свойство <property name="p:UserName" value="ИвановИИ" />. Это позволит записывать события только для сеансов, запущенных под указанным именем пользователя.

Можно ли писать логи ТЖ прямо в базу данных?

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

Почему файл logcfg.xml игнорируется платформой?

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

Влияет ли ТЖ на скорость работы базы в режиме предприятия?

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