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

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

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

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

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

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

Обращаться к ТЖ стоит в нескольких ситуациях: пользователи жалуются на зависания в определённое время, происходят взаимоблокировки с ошибкой «Конфликт блокировок при выполнении транзакции», рабочий процесс аварийно завершается, либо нужно понять, какой именно запрос формирует тяжёлый отчёт. Для разовой диагностики достаточно сбора на 15–60 минут; для периодических проблем журнал включают на сутки с ротацией.

Включение сбора: файл logcfg.xml

Конфигурация задаётся XML-файлом logcfg.xml. На сервере 1С его размещают в каталоге conf рядом с исполняемыми файлами платформы (например, C:\Program Files\1cv8\<версия>\bin\conf) или в каталоге служебных данных кластера. Для сбора событий на клиенте файл кладут в каталог conf клиентской установки. Платформа подхватывает файл без перезапуска в течение примерно минуты.

Минимальный файл содержит узел log с указанием каталога (location), глубины хранения (history, в часах) и списка событий. Ниже пример конфигурации для диагностики медленных запросов и блокировок на MS SQL Server.

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

Каталог для логов создайте заранее и проверьте, что у учётной записи, под которой работает агент сервера 1С, есть права на запись. Имена событий зависят от СУБД: для PostgreSQL используется DBPOSTGRS, для Oracle — DBORACLE, для IBM Db2 — DBDB2. Универсальное событие DBV8DBEng фиксирует запросы на уровне платформы независимо от СУБД.

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

Главный принцип — собирать только то, что отвечает на вопрос диагностики. Избыточный сбор замедляет сервер и усложняет разбор. Ниже — типовые соответствия задач и событий.

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

Как читать и анализировать собранные логи

Логи ТЖ — это текстовые файлы, сгруппированные по процессам и часам: внутри каталога сбора создаются подкаталоги вида rphost_, а в них файлы по часовым интервалам. Каждая строка содержит время с точностью до микросекунд, длительность, имя события, имя процесса и пары «свойство=значение»: Sql, Context, Usr, Trans, WaitConnections и другие.

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

Вручную большие логи разбирать тяжело, поэтому применяют вспомогательные средства: поиск по файлам с фильтрацией по длительности (grep, PowerShell), парсеры ТЖ в составе инструментов разработчика, либо штатную Центр администрирования / ЦКК (центр контроля качества) из поставки корпоративного инструментального пакета, которая автоматически собирает ТЖ и строит отчёты по длительным запросам и блокировкам.

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

Типовой разбор: медленный запрос и взаимоблокировка

Поиск медленного запроса

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

Разбор взаимоблокировки

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

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

Признак корректной работы ТЖ — появление в указанном каталоге подкаталогов процессов с файлами логов в течение 1–2 минут после создания logcfg.xml. Если каталог пуст, проверьте: валидность XML, права на запись, правильность пути, тот ли это сервер (в кластере с несколькими рабочими серверами настраивать нужно каждый).

У метода есть ограничения. ТЖ показывает симптомы на уровне платформы, но не заменяет мониторинг СУБД: для глубокого анализа планов, ожиданий и статистики используйте штатные средства MS SQL Server или PostgreSQL. События CALL и DBMSSQL сильно нагружают дисковую подсистему, поэтому постоянный полный сбор на продуктиве не практикуют — для непрерывного контроля предназначена ЦКК с выборочными настройками.

Контрольные точки

Как проверить результат

Появление логов

Норма

В каталоге сбора появились папки rphost_* с файлами за текущий час

Тревожный признак

Каталог пуст спустя 2–3 минуты — ошибка в XML или нет прав на запись

Полнота данных

Норма

В логах есть события за период воспроизведения проблемы с нужными именами событий

Тревожный признак

Логи есть, но нужного интервала или событий нет — неверный фильтр или не тот сервер

Влияние на систему

Норма

Нагрузка на диск и отзывчивость сервера не изменились заметно

Тревожный признак

Растёт очередь диска, пользователи жалуются — сократите набор событий или остановите сбор

Исправление

Норма

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

Тревожный признак

Длительность не изменилась — причина не найдена, нужен повторный анализ

Частые вопросы о технологическом анализе в 1С

Нужно ли перезапускать сервер 1С после создания logcfg.xml?

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

Как собрать ТЖ только для одного пользователя или информационной базы?

В logcfg.xml поддерживаются условия отбора по свойствам событий: можно фильтровать по имени пользователя (Usr) или имени базы. Это резко сокращает объём логов при диагностике проблемы конкретного сотрудника.

Чем технологический журнал отличается от журнала регистрации?

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

Можно ли анализировать ТЖ без сторонних инструментов?

Да: логи — обычный текст, их разбирают поиском по файлам, PowerShell или grep с фильтрацией по длительности и именам событий. Сторонние парсеры и ЦКК лишь ускоряют работу с большими объёмами.

Сколько места резервировать под логи технологического журнала?

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

Что делать, если проблема возникает редко и непредсказуемо?

Включите ТЖ с узким набором событий (EXCP, TDEADLOCK, TTIMEOUT) и длительным сроком хранения history на несколько суток. Такой сбор почти не нагружает сервер и позволяет дождаться редкого события, после чего сузить диагностику по времени инцидента.