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

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

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

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

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

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

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

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

Минимальный пример файла, включающего запись всех событий в указанный каталог:

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

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

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

Писать «всё подряд» почти никогда не нужно. Фильтр по событиям задаётся элементами event с условиями eq, like и другими. Для анализа производительности обычно интересны события DBMSSQL или DBPOSTGRS (запросы к СУБД) вместе с контекстом исполнения, для блокировок — события TLOCK, TDEADLOCK, TTIMEOUT, для ошибок — EXCP и EXCPCNTX.

Пример фильтра, который фиксирует только запросы длительнее 10 секунд (длительность указывается в микросекундах):

<event>
  <eq property="name" value="DBMSSQL"/>
</event>
<property name="sql"/>
<property name="Context"/>
<conditions>
  <gt property="duration" value="10000000"/>
</conditions>

Отдельно полезно включить событие SDBL с длительностью — оно показывает обращения к базе на уровне языка запросов 1С, что упрощает сопоставление с кодом конфигурации. Для диагностики аварийных завершений добавьте события CLSTR, PROC и EXCP, а также настройте запись дампов элементом dump.

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

Файлы появляются в каталоге, указанном в атрибуте location. Внутри платформа создаёт подкаталоги по имени процесса (например, rphost) и далее по идентификатору процесса. Имена файлов содержат дату и порядковый номер часа записи, например 24031514.log — файл за 14-й час 15 марта. Каждый процесс пишет свой файл, поэтому для полной картины события из разных файлов сопоставляют по времени.

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

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

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

Формат записи выглядит примерно так: 45:12.345678-123456,DBMSSQL,5,process=rphost,p:processName=...,OSThread=...,t:clientID=...,t:applicationName=...,Sql='SELECT ...',Rows=1,Context='...'. Первая группа — время и длительность в микросекундах, затем имя события, уровень вложенности и список свойств. Ключевые свойства для анализа: duration (длительность), Sql (текст запроса), Context (место в коде конфигурации), t:clientID (связь с сеансом).

Для ручного просмотра подойдёт любой редактор, устойчивый к большим файлам (например, Notepad++), но при регулярном анализе удобнее специализированные инструменты: консольные скрипты разбора, обработки для 1С или средства в составе Центра администрирования и сторонних решений мониторинга. Они группируют события по длительности и контексту, что вручную делать трудоёмко.

Типовые сценарии анализа

Поиск причины медленной операции

Включите события DBMSSQL (или соответствующее вашей СУБД) с условием по длительности, воспроизведите операцию и отсортируйте записи по duration. По свойству Context определите, какой участок кода или отчёт порождает запрос, а по тексту Sql — какие таблицы участвуют. Дальнейшая оптимизация обычно сводится к пересмотру запроса, индексов или логики обхода данных.

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

Событие TDEADLOCK фиксирует факт взаимоблокировки и участвующие сеансы. Сопоставьте записи TLOCK и TDEADLOCK по времени, чтобы понять, какие объекты захватывали конкурирующие транзакции. Частая причина — разный порядок записи связанных объектов в разных участках кода или избыточные управляемые блокировки.

Разбор аварийного завершения

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

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

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

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

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