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

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

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

Ниже разобрано, как включить сбор событий, где искать файлы журнала на Windows и Linux, как читать записи и какие настройки помогают не перегрузить диск. Материал рассчитан на администраторов и разработчиков, работающих с клиент-серверными и файловыми базами.

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

Технологический журнал (ТЖ) — это механизм платформы 1С:Предприятие, который фиксирует низкоуровневые события: выполнение запросов к базе данных (DBMSSQL, DBPOSTGRS, DBORACLE), длительные вызовы (CALL), исключения (EXCP), взаимоблокировки (TDEADLOCK, TLOCK), утечки памяти (LEAKS), события кластера и другие. Каждое событие записывается с длительностью, контекстом и служебными свойствами.

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

Как включить журнал через logcfg.xml

Единственный штатный способ включения — создать файл logcfg.xml в каталоге conf. Для сервера 1С это каталог conf внутри каталога установки агента сервера (например, C:\Program Files\1cv8\<версия>\bin\conf или /opt/1cv8/x86_64/<версия>/conf в Linux). Для толстого клиента и файловой базы файл кладётся в conf рядом с клиентскими исполняемыми файлами. После создания файла платформа подхватывает настройки без перезапуска — обычно в течение минуты.

Минимальный пример logcfg.xml, который пишет все события в каталог C:\1clogs с хранением 24 часа:

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

Атрибут location задаёт каталог логов (он должен существовать и быть доступен на запись учётной записи службы агента сервера, например USR1CV8), history — время хранения логов в часах. Запись <eq property="name" value=""/> означает «все события». Такой полный вариант подходит только для кратковременной диагностики: на нагруженной системе он создаст десятки гигабайт логов за день.

Настройка фильтров: собираем только нужное

В реальной диагностике почти никогда не нужны все события. Чтобы снизить нагрузку, фильтруйте по имени события и длительности. Например, для поиска медленных запросов к MS SQL Server достаточно собирать DBMSSQL длительностью более 1 000 000 микросекунд (1 секунда):

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

Для отсечения коротких событий добавляют условие по длительности, например <gt property="duration" value="1000000"/> внутри блока event. Длительность в ТЖ указывается в микросекундах, это частая причина ошибок при настройке порогов. Дополнительно можно ограничивать сбор по свойствам процесса, пользователя или имени базы через соответствующие property.

Где искать и как открыть файлы журнала

После включения платформа создаёт в указанном location дерево каталогов: по имени процесса (rphost, ragent, rmngr, 1cv8, 1cv8c) и далее файлы вида YYMMDDHH.log — один файл на каждый час. Если платформа работает, а файлов нет, проверяйте: лежит ли logcfg.xml именно в conf нужного экземпляра платформы, есть ли у службы права записи в каталог логов и не содержит ли XML синтаксических ошибок (невалидный файл просто игнорируется).

Открыть лог можно любым текстовым редактором, устойчивым к большим файлам. Для регулярного анализа удобнее специализированные средства просмотра технологического журнала: они группируют события, показывают длительность в читаемом виде, строят дерево вызовов и позволяют фильтровать по свойствам. Записи в файле идут парами «начало события — конец события» (например, DBMSSQL с длительностью фиксируется одной строкой с указанием времени).

1. 1
   Создайте каталог для логов и дайте права на запись учётной записи службы сервера 1С
2. 2
   Создайте logcfg.xml в каталоге conf нужного экземпляра платформы
3. 3
   Задайте location, history и фильтры событий
4. 4
   Подождите 1–2 минуты и убедитесь, что появились каталоги процессов и файлы логов
5. 5
   Воспроизведите проблему (медленную операцию, ошибку)
6. 6
   Откройте файл лога за нужный час и найдите события по времени и контексту
7. 7
   После диагностики отключите или урежьте сбор, удалив/изменив logcfg.xml

Как читать записи: основные события

Каждая строка ТЖ имеет формат: минуты:секунды.микросекунды-длительность,ИмяСобытия,уровень,свойства. Например, запись 45:12.345678-1500000,DBMSSQL,2,process=rphost,p:processName=...,Sql='SELECT ...',Rows=100 означает запрос к MS SQL длительностью 1,5 секунды. Свойства записываются парами «имя=значение» через запятую.

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

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

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

Вторая группа ошибок — перегрузка системы: сбор всех событий без фильтров на продуктивном сервере, слишком большой history, размещение логов на том же диске, что и база данных. Логи лучше писать на отдельный быстрый диск с запасом места и регулярно контролировать заполнение. Также помните, что ТЖ пишется каждым процессом (rphost, ragent) отдельно — для полной картины на кластере смотрите каталоги всех рабочих процессов.

Альтернативы и дополнительные инструменты

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

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

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