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

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

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

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

ТЖ фиксирует низкоуровневые события платформы, недоступные через журнал регистрации. Ключевые группы событий: ошибки платформы (EXCP), взаимоблокировки и таймауты (DBLOCK, TLOCK, TTIMEOUT, TDEADLOCK), запросы к СУБД (DBMSSQL, DBPOSTGRS, DBORACLE, DB2), вызовы и контексты (CALL, SCALL), события памяти (MEM, LEAKS), соединения (CONN, PROC).

Типовые ситуации, когда без ТЖ не обойтись: пользователи получают ошибку «Конфликт блокировок», но непонятно кто с кем конфликтует; отчёт формируется 10 минут вместо 10 секунд; рабочий процесс rphost падает или съедает всю память; регламентное задание завершается с ошибкой без внятного описания.

Включение и настройка через logcfg.xml

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

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

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

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

Структура каталогов и формат записей

В указанном каталоге платформа создаёт подкаталоги по имени процесса: rphost (рабочие процессы сервера), ragent (агент), rmngr (менеджер кластера), 1cv8c (клиент). Внутри — текстовые файлы вида 24010112.log, где имя кодирует дату и час создания. Каждый час начинается новый файл.

Формат строки: минуты:секунды.микросекунды-длительность,ИМЯ_СОБЫТИЯ,процесс,свойства. Например:

15:42.183005-15234,DBMSSQL,2,process=rphost,p:processName=Base1,t:clientID=481,t:applicationName=BackgroundJob,Usr=ИвановИА,Sql='SELECT ...',Rows=5

Длительность указывается в микросекундах — это ключевое поле при поиске медленных операций. Свойства записываются парами «имя=значение»; важнейшие для анализа: Usr (пользователь), t:clientID (номер соединения, связывает события), Sql (текст запроса), Context (контекст кода 1С), Descr и Err (описание ошибки).

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

Если пользователи получают «Конфликт блокировок при выполнении транзакции», включите события TDEADLOCK, TTIMEOUT и DBLOCK. В событии TDEADLOCK платформа записывает участников взаимоблокировки: какие сеансы, какие таблицы и какие запросы участвовали. По t:clientID и времени найдите соответствующие события DBMSSQL — увидите конкретные запросы обеих сторон конфликта.

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

Поиск медленных запросов и узких мест производительности

Для диагностики «тормозов» включите события DBMSSQL (или соответствующее вашей СУБД) и CALL с фильтром по длительности. В logcfg.xml можно задать условие, чтобы записывались только события длиннее порога — например, 1 000 000 микросекунд (1 секунда). Это радикально сокращает объём логов.

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

1. 1
   Включите ТЖ с фильтром DBMSSQL по длительности от 1 секунды
2. 2
   Воспроизведите проблему и зафиксируйте точное время
3. 3
   Найдите события в файле соответствующего часа по времени и пользователю
4. 4
   Извлеките текст запроса и проверьте план выполнения в СУБД
5. 5
   Проверьте наличие индексов по полям условий и актуальность статистики
6. 6
   Отключите или сузьте сбор после получения данных

Инструменты для чтения больших логов

Вручную читать файлы по несколько гигабайт нереально. Практикуемые подходы: текстовый редактор с поиском по большим файлам (Notepad++, FAR), фильтрация через findstr или grep по имени события и пользователю, специализированные обработки-парсеры ТЖ, которые загружают логи в таблицу и позволяют строить отборы и группировки.

findstr /C:"TDEADLOCK" /C:"EXCP" D:\1clogs\rphost_*\*.log > errors.txt

Для регулярного мониторинга удобно выгружать логи в СУБД или использовать централизованные системы сбора логов с индексацией. Это позволяет строить запросы вида «все события длиннее 5 секунд за сутки по базе X» вместо ручного перебора файлов.

Проверка результата и ограничения метода

ТЖ показывает симптомы на уровне платформы и СУБД, но не объясняет бизнес-логику: почему код сформировал именно такой запрос, придётся разбирать в конфигураторе по контексту. Для анализа на стороне СУБД ТЖ стоит дополнять штатными средствами СУБД — профилировщиком, extended events, pg_stat_statements. Также помните: события клиентских процессов пишутся только при наличии logcfg.xml на стороне клиента, серверный конфиг их не включает.

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