Как найти контекст выполнения запросов веб-сервиса в технологическом журнале 1С

← На главную

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

Почему контекст отсутствует в вызовах веб-сервисов

Проанализируем архитектуру исполнения кода. Когда обычный пользователь работает в интерактивном режиме (тип приложения 1CV8), платформа автоматически отслеживает стек вызовов от формы до серверного модуля. В случае с веб-сервисами (тип приложения WebServerExtension), точкой входа является метод модуля веб-сервиса. Платформа не всегда считает нужным «пробрасывать» стек вызовов в стандартное свойство Context события CALL, так как клиентской части в привычном понимании не существует. Исполнение начинается сразу на сервере, и контекст может появиться только внутри вложенных вызовов или при обращениях к базе данных.

Метод 1: Использование комментариев в запросах (Query Hints)

Это самый надежный и «чистый» способ идентифицировать запрос. Если мы знаем, что веб-сервис выполняет тяжелые отчеты или выборки, мы можем пометить каждый запрос уникальным комментарием. Рассмотрим пример реализации:


// В модуле веб-сервиса или общем модуле
ТекстЗапроса = 
"// Идентификатор: ОтчетПоПродажам_WebService; Вызов: ПолучитьДанные
|ВЫБРАТЬ
|    ПродажиОбороты.Номенклатура,
|    ПродажиОбороты.КоличествоОборот
|ИЗ
|    РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода) КАК ПродажиОбороты";

Запрос = Новый Запрос(ТекстЗапроса);
// Установка параметров и выполнение

Этот комментарий будет проброшен платформой напрямую в SQL-запрос. Теперь, даже если в событии CALL пусто, мы сможем найти этот текст в событиях DBMSSQL технологического журнала или даже в мониторе SQL-сервера. Это позволит однозначно связать «тяжелый» SQL-запрос с конкретным участком кода в 1С.

Метод 2: Расширенная настройка logcfg.xml

Если проблема уже произошла, а комментарии в код еще не добавлены, проанализируем настройки технологического журнала. Для поиска контекста в веб-сервисах недостаточно собирать только CALL. Нам необходимо связать вызов с операциями базы данных. Настроим logcfg.xml для сбора событий SDBL и DBMSSQL с обязательным указанием свойства Context.


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\LOGS\WEB_SERVICE_ANALYZE" history="24">
        <event>
            <eq property="Name" value="CALL"/>
            <eq property="applicationName" value="WebServerExtension"/>
        </event>
        <event>
            <eq property="Name" value="DBMSSQL"/>
            <gt property="Duration" value="100000"/> <!-- Запросы дольше 0.1 сек -->
        </event>
        <property name="all"/>
    </log>
</config>

Важный момент: контекст часто появляется не в самом CALL, а в дочерних событиях DBMSSQL, которые выполняются в рамках того же SessionID и t:connectID. Выясним причину нагрузки, сопоставив время начала CALL и время выполнения самого долгого SQL-запроса внутри этого сеанса.

Метод 3: Сопоставление через SQL-трассировку

Если технологический журнал 1С не дает полной картины, воспользуемся инструментами SQL-сервера. Проанализируем ситуацию:

Находим на SQL-сервере самый ресурсоемкий запрос (по потреблению CPU или количеству чтений).
В тексте запроса находим имена таблиц (например, _InfoReg1234).
Используя консоль запросов или специальную обработку, выясняем, какому объекту метаданных 1С соответствует эта таблица.
Ищем в конфигурации все места, где происходит обращение к этому регистру или документу внутри методов, вызываемых веб-сервисом.

Посмотрим на пример сопоставления. Если SQL показывает запрос к _AccumRegTotals654, мы понимаем, что это итоги регистра накопления. В сочетании с SessionID из ТЖ это сужает круг поиска до конкретного метода веб-сервиса.

Метод 4: Анализ событий VRSREQUEST и SCALL

Для веб-сервисов крайне полезно включить в сбор события VRSREQUEST и VRSRESPONSE. Они фиксируют сам факт входящего HTTP-запроса, включая его тело (XML или JSON). Проанализируем, как это помогает:

Событие VRSREQUEST покажет нам параметры, с которыми был вызван веб-сервис (например, период отчета или ID контрагента).
Событие SCALL (серверный вызов) может содержать контекст, если внутри веб-сервиса происходит обращение к другим серверным модулям или базам данных.

Метод 5: Логирование через Журнал Регистрации

В условиях сильно «переписанной» УПП 1.3 эффективным методом будет добавление программного логирования в начало каждого метода веб-сервиса. Рассмотрим пример:


Процедура ВыполнитьТяжелыйОтчет(Параметры)
    ЗаписьЖурналаРегистрации("Web-Service.Начало",
        УровеньЖурналаРегистрации.Предупреждение,
        ,
        ,
        "Начало выполнения отчета. Параметры: " + ЗначениеВСтрокуВнутр(Параметры));
    
    // Основной код метода
    
    ЗаписьЖурналаРегистрации("Web-Service.Конец",
        УровеньЖурналаРегистрации.Информационный);
КонецПроцедуры

Сопоставив время записи в Журнале регистрации со временем долгого CALL в технологическом журнале (ориентируясь на SessionID), мы получим точное понимание того, какой программный код инициировал тяжелый запрос.

Резюмируем: отсутствие контекста в ТЖ для веб-сервисов — это особенность платформы. Чтобы решить задачу диагностики, необходимо комбинировать расширенную настройку logcfg.xml (события DBMSSQL, SDBL, VRSREQUEST), маркировку запросов комментариями и сопоставление данных ТЖ с аналитикой SQL-сервера.