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

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

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

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

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

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

Типовые задачи, которые решают с помощью ТЖ:

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

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

Где размещается файл конфигурации logcfg.xml

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

Для сервера 1С:Предприятия файл размещают в подкаталоге conf каталога установки платформы, например: C:\Program Files\1cv8\<версия>\bin\conf\logcfg.xml в Windows или /opt/1cv8/x86_64/<версия>/conf/logcfg.xml в Linux. Этот файл управляет логированием процессов ragent, rmngr и rphost.

Для толстого или тонкого клиента, запущенного вне сервера, logcfg.xml кладут в каталог conf рядом с исполняемым файлом клиента либо указывают через параметр. На терминальных сценариях чаще всего достаточно серверного ТЖ, так как основная нагрузка происходит в rphost.

Чтобы один и тот же файл не пришлось копировать при каждом обновлении платформы, можно использовать каталог с общими настройками: платформа также читает logcfg.xml из каталога конфигурации, общего для всех версий (например, C:\ProgramData\1C\1CEStart\logcfg.xml в Windows). Это удобно, когда версий платформы несколько.

Структура logcfg.xml: каталоги, события и свойства

Корневой элемент файла — config, внутри него один или несколько элементов log. Каждый log описывает отдельный набор: куда писать, какие события собирать и какие свойства выводить. Несколько элементов log позволяют, например, писать ошибки в один каталог постоянно, а подробные запросы — в другой, временно.

Минимальный рабочий пример, который пишет все события с полным набором свойств:

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

Здесь location — каталог логов (он должен существовать и быть доступен на запись учётной записи службы сервера 1С), history — глубина хранения в часах. Событие с пустым условием eq означает «все события». Такой вариант подходит только для кратковременной диагностики: объём данных будет очень большим.

Практичный вариант для постоянного мониторинга ошибок:

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

Фильтрация событий выполняется элементами eq (равно), ne (не равно), like (по маске), gt/lt (больше/меньше — удобно для отбора по длительности, например только запросы длиннее 10 секунд: <gt property="duration" value="100000"/>, длительность указывается в микросекундах).

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

Настройка сбора дампов при аварийных завершениях

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump location="D:\1c_dumps" type="3" externaldump="1" prntscrn="0"/>
</config>

Параметр type определяет размер дампа: 0 — без дампа, 1 — минидамп, 2 — дамп с дополнительной информацией, 3 — полный дамп. Полный дамп рабочего процесса может занимать объём, сопоставимый с потребляемой процессом памятью (единицы гигабайт), поэтому заранее убедитесь в наличии свободного места на диске.

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

Применение настроек и проверка, что журнал пишется

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

Порядок проверки:

1. Создайте каталог логов и убедитесь, что у учётной записи службы агента сервера (по умолчанию USR1CV8) есть права на запись в него.
2. Разместите logcfg.xml в каталоге conf и подождите 1–2 минуты.
3. Проверьте, что в каталоге появились подкаталоги с именами процессов (rphost_*, ragent_*) и внутри — файлы вида YYMMDDHH.log.
4. Откройте свежий файл и убедитесь, что события пишутся и содержат нужные свойства.
5. Выполните проблемное действие в системе и найдите соответствующие события в логе по метке времени.

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

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

Как читать и анализировать записи журнала

Формат строки события: метка времени в формате ММ:СС.микросекунды-длительность, имя события, имя процесса, затем пары «свойство=значение» через запятую. Например, событие DBMSSQL содержит текст запроса (Sql), число обработанных строк (Rows), длительность и контекст исполнения.

Ключевые события для диагностики:

Для разбора больших логов вручную файлы неудобны. Используют специализированные инструменты: консоль анализа технологического журнала (обработки с портала 1С:ИТС), «Центр администрирования», либо парсинг скриптами (PowerShell, Python) с группировкой по длительности и тексту запроса. Практичный приём — отфильтровать события DBMSSQL с длительностью выше порога и сгруппировать их по шаблону запроса: так быстро находятся самые затратные места.

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

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

Вторая группа ошибок связана с объёмами. Администраторы включают полный сбор «на всякий случай» и забывают выключить: логи заполняют системный диск, и сервер падает уже по причине отсутствия места. Всегда задавайте history, размещайте логи на отдельном диске и назначайте ответственного за отключение сбора после диагностики.

Ограничения, о которых нужно помнить: ТЖ не подменяет мониторинг СУБД (план выполнения запроса смотрят средствами самой СУБД), не показывает прикладной логики (для этого есть журнал регистрации и замеры производительности), а в кластере из нескольких рабочих серверов logcfg.xml нужно размещать на каждом сервере отдельно.

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

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

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

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

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